From 817350884b80263fb7ea1b56d5ce74ee79401afd Mon Sep 17 00:00:00 2001 From: "stark, steven" Date: Thu, 2 Aug 2018 13:07:54 -0700 Subject: [VNFRQTS] Adding HPA definition to glossary Change-Id: Idd106c831648ece7665d66ed061b0bd1833658df Issue-ID: VNFRQTS-234 Signed-off-by: stark, steven --- docs/vnf_guidelines/vnf_guidelines.rst | 104 +++++++++++++++++++-------------- 1 file changed, 61 insertions(+), 43 deletions(-) diff --git a/docs/vnf_guidelines/vnf_guidelines.rst b/docs/vnf_guidelines/vnf_guidelines.rst index 5fd9f85..d7e411a 100644 --- a/docs/vnf_guidelines/vnf_guidelines.rst +++ b/docs/vnf_guidelines/vnf_guidelines.rst @@ -38,8 +38,8 @@ VNF/PNF Guidelines to the Beijing 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). +- Conformance requirements are in the `VNF/PNF Requirements + document `_. **Introduction** ------------------------------- @@ -114,9 +114,9 @@ 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 +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. +guidelines to meet the industry's collective needs. **Other interested parties** @@ -130,7 +130,7 @@ 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 +white box hardware on customer's premises – such functionality may be of particular interest to enterprises supporting similar infrastructure. Program and Document Structure @@ -200,7 +200,7 @@ 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 +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 @@ -238,7 +238,7 @@ and improved cycle time through careful design. **Efficiency via Automation** -reliant on human labor for critical operational tasks don’t scale. By +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 @@ -266,7 +266,7 @@ and NCSPs. **Improved Cycle Time through Careful Design** -Today’s fast paced world requires businesses to evolve rapidly in order +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 @@ -365,7 +365,7 @@ 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 +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 @@ -425,7 +425,7 @@ 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 +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. @@ -494,9 +494,9 @@ model. Reusability ++++++++++++++++++++++++ -Properly (de)composing a VNF requires thinking about “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 +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 @@ -581,7 +581,7 @@ 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 +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. @@ -609,7 +609,7 @@ triggered or managed via ONAP: ONAP Ready ^^^^^^^^^^^^^^^^^^^^^^ -ONAP 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. ONAP is critical in achieving the objectives to increase the value of the Network Cloud to customers by rapidly on-boarding new services, @@ -645,7 +645,7 @@ Design Definition ~~~~~~~~~~~~~~~~~ Onboarding automation will be facilitated by applying standards-based -approaches to VNF packaging to describe the VNF’s infrastructure +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. @@ -772,7 +772,7 @@ 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 +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 @@ -786,7 +786,7 @@ 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. +follow Service Provider's hardware upgrade processes and procedures. Managing State ^^^^^^^^^^^^^^^^^ @@ -808,7 +808,7 @@ 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 +such as methods for migrating traffic between PNF's and draining traffic from a PNF. DevOps @@ -834,7 +834,7 @@ 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 +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 @@ -863,7 +863,7 @@ 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 +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 @@ -967,10 +967,14 @@ Glossary | | applications using a declarative template format | | | through an OpenStack-native REST API. | +--------------------+-------------------------------------------------------+ -| TOSCA | Topology and Orchestration Specification for Cloud | -| | Applications (OASIS spec) | +| 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 | +--------------------+-------------------------------------------------------+ -| Network Clouds | Network Clouds are built on a framework containing | +| 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,| @@ -984,11 +988,25 @@ Glossary | | availability; and increasing competencies in software | | | integration and a DevOps operations model. | +--------------------+-------------------------------------------------------+ -| Network Cloud | Network Cloud Service Provider (NCSP) is a company or | -| Service Provider | organization, making use of a communications network | +| 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 | @@ -1006,7 +1024,10 @@ Glossary | | 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. | +| | 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 | @@ -1035,10 +1056,7 @@ Glossary | | | | | |image2| | +--------------------+-------------------------------------------------------+ -| PNF | PNF is a vendor-provided Network Function(s) | -| | implemented using a bundled set of hardware and | -| | software. | -+--------------------+-------------------------------------------------------+ + References ^^^^^^^^^^^^^ @@ -1058,7 +1076,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 ONAP 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 @@ -1096,7 +1114,7 @@ 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 + "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. @@ -1122,12 +1140,12 @@ 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.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 + 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. @@ -1157,12 +1175,12 @@ but also include additional attributes. and methods. .. [2] - “ Virtual Network Functions Architecture” ETSI GS NFV-SWA 001 v1.1.1 + "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 + European Telecommunications Standards Institute or `ETSI + `_ is a respected standards body providing standards for information and communications technologies. .. [4] @@ -1170,16 +1188,16 @@ but also include additional attributes. be needed to support traditional IT like workloads. .. [5] - xRAN (http://www.xran.org/) + `xRAN `_ .. [6] - OpenStack (http://www.openstack.org) + `OpenStack `_ .. [7] - OpenDaylight (http://www.opendaylight.org) + `OpenDaylight `_ .. [8] - OPNFV (http://www.opnfv.org) + `OPNFV `_ .. [9] See, e.g., Figure 3 of GS NFV 002, Architectural Framework -- cgit 1.2.3-korg