From 3bcfdfe719ae07ef2747b42b69bb1e7840daf619 Mon Sep 17 00:00:00 2001 From: "Bozawglanian, Hagop (hb755d)" Date: Mon, 8 Oct 2018 22:59:16 +0000 Subject: VNFRQTS - Updating hierarchy of guidelines Changing the hierarchy to remove redundancy as well as add new theme for local changes. Issue-ID: VNFRQTS-462 Change-Id: Ifa54877fe48572ea24768b9e4b68f9f0ed5438ae Signed-off-by: Bozawglanian, Hagop (hb755d) --- conf.py | 493 ++++++++++ docs/ONAP_VNF_Control_Loop.jpg | Bin 0 -> 51913 bytes docs/VNF_Lifecycle.jpg | Bin 0 -> 16839 bytes docs/VNF_VNFC_Relation.jpg | Bin 0 -> 454310 bytes docs/_static/css/ribbon.css | 63 ++ docs/_static/favicon.ico | Bin 0 -> 2102 bytes docs/_static/logo_onap_2017.png | Bin 0 -> 6980 bytes docs/_templates/layout.html | 19 + docs/index.rst | 9 +- docs/vnf_guidelines.rst | 1224 +++++++++++++++++++++++++ docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg | Bin 51913 -> 0 bytes docs/vnf_guidelines/VNF_Lifecycle.jpg | Bin 16839 -> 0 bytes docs/vnf_guidelines/VNF_VNFC_Relation.jpg | Bin 454310 -> 0 bytes docs/vnf_guidelines/index.rst | 25 - docs/vnf_guidelines/vnf_guidelines.rst | 1223 ------------------------ etc/requirements.txt | 12 +- 16 files changed, 1815 insertions(+), 1253 deletions(-) create mode 100644 conf.py create mode 100644 docs/ONAP_VNF_Control_Loop.jpg create mode 100644 docs/VNF_Lifecycle.jpg create mode 100644 docs/VNF_VNFC_Relation.jpg create mode 100644 docs/_static/css/ribbon.css create mode 100755 docs/_static/favicon.ico create mode 100755 docs/_static/logo_onap_2017.png create mode 100644 docs/_templates/layout.html create mode 100644 docs/vnf_guidelines.rst delete mode 100644 docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg delete mode 100644 docs/vnf_guidelines/VNF_Lifecycle.jpg delete mode 100644 docs/vnf_guidelines/VNF_VNFC_Relation.jpg delete mode 100644 docs/vnf_guidelines/index.rst delete mode 100644 docs/vnf_guidelines/vnf_guidelines.rst diff --git a/conf.py b/conf.py new file mode 100644 index 0000000..b5f690d --- /dev/null +++ b/conf.py @@ -0,0 +1,493 @@ +# -*- coding: utf-8 -*- +# +# ONAP documentation build configuration file, created by +# sphinx-quickstart on Wed Jul 19 16:25:31 2017. +# +# This file is execfile()d with the current directory set to its +# containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +import sys +import os +import shlex +#import sphinx_bootstrap_theme + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +#sys.path.insert(0, os.path.abspath('.')) + +# -- General configuration ------------------------------------------------ + +# If your documentation needs a minimal Sphinx version, state it here. +needs_sphinx = '1.5.3' + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = [ + 'sphinx.ext.autodoc', + 'sphinx.ext.doctest', + 'sphinx.ext.graphviz', + 'sphinx.ext.todo', + 'sphinx.ext.imgmath', + 'sphinx.ext.viewcode', + 'sphinxcontrib.blockdiag', + 'sphinxcontrib.needs', + 'sphinxcontrib.nwdiag', + 'sphinxcontrib.seqdiag', + 'sphinx.ext.ifconfig', + 'sphinx.ext.todo', + 'sphinxcontrib.plantuml', + 'sphinxcontrib.swaggerdoc' +] + +# Font path for seqdiag +seqdiag_fontpath = '/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf' +nwdiag_fontpath = '/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf' + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix(es) of source filenames. +# You can specify multiple suffix as a list of string: +# source_suffix = ['.rst', '.md'] +source_suffix = '.rst' + +# The encoding of source files. +#source_encoding = 'utf-8-sig' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = u'' +copyright = u'2018 ONAP. Licensed under Creative Commons Attribution 4.0 International License' + + +author = u'Open Network Automation Platform' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# The short X.Y version. +version = 'master branch' +# The full version, including alpha/beta/rc tags. +release = 'master branch' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +# +# This is also used if you do content translation via gettext catalogs. +# Usually you set "language" from the command line for these cases. +language = None + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +#today = '' +# Else, today_fmt is used as the format for a strftime call. +#today_fmt = '%B %d, %Y' + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +exclude_patterns = [ + '_build' + ] + +# The reST default role (used for this markup: `text`) to use for all +# documents. +#default_role = None + +# If true, '()' will be appended to :func: etc. cross-reference text. +#add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +#add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +#show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# A list of ignored prefixes for module index sorting. +#modindex_common_prefix = [] + +# If true, keep warnings as "system message" paragraphs in the built documents. +#keep_warnings = False + +# If true, `todo` and `todoList` produce output, else they produce nothing. +todo_include_todos = True + + +# -- Options for HTML output ---------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +#html_theme = 'classic' +html_theme = 'sphinx_rtd_theme' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +#html_theme_options = {} + +# Add any paths that contain custom themes here, relative to this directory. +#html_theme_path = sphinx_bootstrap_theme.get_html_theme_path() + +# The name for this set of Sphinx documents. If None, it defaults to +# " v documentation". +#html_title = None + +# A shorter title for the navigation bar. Default is the same as html_title. +#html_short_title = None + +# The name of an image file (relative to this directory) to place at the top +# of the sidebar. +html_logo = '_static/logo_onap_2017.png' + +# The name of an image file (within the static path) to use as favicon of the +# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# pixels large. +html_favicon = '_static/favicon.ico' + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +html_static_path = ['_static'] + +# Add any extra paths that contain custom files (such as robots.txt or +# .htaccess) here, relative to this directory. These files are copied +# directly to the root of the documentation. +#html_extra_path = [] + +# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, +# using the given strftime format. +html_last_updated_fmt = '%d-%b-%y %H:%M' + +# If true, SmartyPants will be used to convert quotes and dashes to +# typographically correct entities. +#html_use_smartypants = True + +# Custom sidebar templates, maps document names to template names. +#html_sidebars = {} + +# Additional templates that should be rendered to pages, maps page names to +# template names. +#html_additional_pages = {} + +# If false, no module index is generated. +#html_domain_indices = True + +# If false, no index is generated. +#html_use_index = True + +# If true, the index is split into individual pages for each letter. +#html_split_index = False + +# If true, links to the reST sources are added to the pages. +#html_show_sourcelink = True + +# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. +html_show_sphinx = False + +# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. +#html_show_copyright = True + +# If true, an OpenSearch description file will be output, and all pages will +# contain a tag referring to it. The value of this option must be the +# base URL from which the finished HTML is served. +#html_use_opensearch = '' + +# This is the file name suffix for HTML files (e.g. ".xhtml"). +#html_file_suffix = None + +# Language to be used for generating the HTML full-text search index. +# Sphinx supports the following languages: +# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja' +# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr' +#html_search_language = 'en' + +# A dictionary with options for the search language support, empty by default. +# Now only 'ja' uses this config value +#html_search_options = {'type': 'default'} + +# The name of a javascript file (relative to the configuration directory) that +# implements a search results scorer. If empty, the default will be used. +#html_search_scorer = 'scorer.js' + +# Output file base name for HTML help builder. +htmlhelp_basename = 'ONAPdoc' + +# -- Options for LaTeX output --------------------------------------------- + +latex_elements = { +# The paper size ('letterpaper' or 'a4paper'). +#'papersize': 'letterpaper', + +# The font size ('10pt', '11pt' or '12pt'). +#'pointsize': '10pt', + +# Additional stuff for the LaTeX preamble. +#'preamble': '', + +# Latex figure (float) alignment +#'figure_align': 'htbp', +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, +# author, documentclass [howto, manual, or own class]). +latex_documents = [ + (master_doc, 'ONAP.tex', u'ONAP Documentation', + u'ONAP Contributors', 'manual'), +] + +# The name of an image file (relative to this directory) to place at the top of +# the title page. +#latex_logo = None + +# For "manual" documents, if this is true, then toplevel headings are parts, +# not chapters. +#latex_use_parts = False + +# If true, show page references after internal links. +#latex_show_pagerefs = False + +# If true, show URL addresses after external links. +#latex_show_urls = False + +# Documents to append as an appendix to all manuals. +#latex_appendices = [] + +# If false, no module index is generated. +#latex_domain_indices = True + + +# -- Options for manual page output --------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + (master_doc, 'onap', u'ONAP Documentation', + [author], 1) +] + +# If true, show URL addresses after external links. +#man_show_urls = False + + +# -- Options for Texinfo output ------------------------------------------- + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + (master_doc, 'ONAP', u'ONAP Documentation', + author, 'ONAP', 'Open Network Automation Platform', + 'Platform'), +] + +# Documents to append as an appendix to all manuals. +#texinfo_appendices = [] + +# If false, no module index is generated. +#texinfo_domain_indices = True + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#texinfo_show_urls = 'footnote' + +# If true, do not generate a @detailmenu in the "Top" node's menu. +#texinfo_no_detailmenu = False + + +# -- Options for Epub output ---------------------------------------------- + +# Bibliographic Dublin Core info. +epub_title = project +epub_author = author +epub_publisher = author +epub_copyright = copyright + +# The basename for the epub file. It defaults to the project name. +#epub_basename = project + +# The HTML theme for the epub output. Since the default themes are not optimized +# for small screen space, using the same theme for HTML and epub output is +# usually not wise. This defaults to 'epub', a theme designed to save visual +# space. +#epub_theme = 'epub' + +# The language of the text. It defaults to the language option +# or 'en' if the language is not set. +#epub_language = '' + +# The scheme of the identifier. Typical schemes are ISBN or URL. +#epub_scheme = '' + +# The unique identifier of the text. This can be a ISBN number +# or the project homepage. +#epub_identifier = '' + +# A unique identification for the text. +#epub_uid = '' + +# A tuple containing the cover image and cover page html template filenames. +#epub_cover = () + +# A sequence of (type, uri, title) tuples for the guide element of content.opf. +#epub_guide = () + +# HTML files that should be inserted before the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_pre_files = [] + +# HTML files shat should be inserted after the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_post_files = [] + +# A list of files that should not be packed into the epub file. +epub_exclude_files = ['search.html'] + +# The depth of the table of contents in toc.ncx. +#epub_tocdepth = 3 + +# Allow duplicate toc entries. +#epub_tocdup = True + +# Choose between 'default' and 'includehidden'. +#epub_tocscope = 'default' + +# Fix unsupported image types using the Pillow. +#epub_fix_images = False + +# Scale large images. +#epub_max_image_width = 0 + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#epub_show_urls = 'inline' + +# If false, no index is generated. +#epub_use_index = True + +# Patterns to ignore in linkcheck builder +linkcheck_ignore = [ + r'http://$', + r'http:/$', + r'http://10\.', + r'http://127\.', + r'http://172\.[123]', + r'http://app_host:port/', + r'http://app-host:port/', + r'http://ESR_SERVICE_IP', + r'http://ESR_SERVER_IP', + r'http://hostIP:\d+/', + r'http://load-balanced-address:\d+/', + r'http://localhost', + r'http://\$msb_address/', + r'http://\$MSB_SERVER_IP:\d+/', + r'http://msb_docker_host_ip:\d+/', + r'http://MSB_IP:MSB_PORT/', + r'http://msb.onap.org', + r'http://MSB_SERVER_IP:\d+/', + r'http://org.openecomp.', + r'http://{PDP_URL}:\d+/', + r'http://servername.domain.com', + r'http://.*simpledemo.openecomp.org', + r'http://.*simpledemo.onap.org', + r'http://.*test.att.com:\d+/', + r'http://we-are-data-router.us', + r'http://we-are-message-router.us:\d+/' + r'http://www.\[host\]:\[port\]/', + r'http://yourhostname', + r'https://$', + r'https:/$', + r'https://10\.', + r'https://127\.', + r'https://172\.[123]', + r'https://aaf.onap.org', + r'https://\$CBAM_IP', + r'https://ESR_SERVICE_IP', + r'https://ESR_SERVER_IP', + r'https://msb.onap.org', + r'https://my-subscriber-app.dcae', + r'https://\$CBAM_IP:\d+/', + r'https://load-balanced-address:\d+/', + r'https://prov.datarouternew.com:8443', + r'https://.*simpledemo.openecomp.org', + r'https://.*simpledemo.onap.org', + r'https://.*test.att.com:\d+/', + r'https://we-are-data-router.us', + r'https://we-are-message-router.us:\d+/' + ] + +from docutils.parsers.rst import directives + +needs_extra_options = { + "target": directives.unchanged, + "keyword": directives.unchanged, + "introduced": directives.unchanged, + "updated": directives.unchanged, + "impacts": directives.unchanged, + "validation_mode": directives.unchanged, + "validated_by": directives.unchanged, + "test": directives.unchanged, + "test_case": directives.unchanged, + "test_file": directives.unchanged, + "notes": directives.unchanged, +} + +needs_id_regex = "^[A-Z0-9]+-[A-Z0-9]+" +needs_id_required = True +needs_title_optional = True + +needs_template_collapse = """ +.. _{{id}}: + +{% if hide == false -%} +.. role:: needs_tag +.. role:: needs_status +.. role:: needs_type +.. role:: needs_id +.. role:: needs_title + +.. rst-class:: need +.. rst-class:: need_{{type_name}} + +.. container:: need + + `{{id}}` - {{content|indent(4)}} + + .. container:: toggle + + .. container:: header + + Details + +{% if status and status|upper != "NONE" and not hide_status %} | status: :needs_status:`{{status}}`{% endif %} +{% if tags and not hide_tags %} | tags: :needs_tag:`{{tags|join("` :needs_tag:`")}}`{% endif %} +{% if keyword %} | keyword: `{{keyword}}` {% endif %} +{% if target %} | target: `{{target}}` {% endif %} +{% if introduced %} | introduced: `{{introduced}}` {% endif %} +{% if updated %} | updated: `{{updated}}` {% endif %} +{% if impacts %} | impacts: `{{impacts}}` {% endif %} +{% if validation_mode %} | validation mode: `{{validation_mode}}` {% endif %} +{% if validated_by %} | validated by: `{{validated_by}}` {% endif %} +{% if test %} | test: `{{test}}` {% endif %} +{% if test_case %} | test case: {{test_case}} {% endif %} +{% if test_file %} | test file: `{{test_file}}` {% endif %} +{% if notes %} | notes: `{{notes}}` {% endif %} + | children: :need_incoming:`{{id}}` + | parents: :need_outgoing:`{{id}}` +{% endif -%} +""" + +def setup(app): + app.add_stylesheet("css/ribbon.css") diff --git a/docs/ONAP_VNF_Control_Loop.jpg b/docs/ONAP_VNF_Control_Loop.jpg new file mode 100644 index 0000000..bc2d101 Binary files /dev/null and b/docs/ONAP_VNF_Control_Loop.jpg differ diff --git a/docs/VNF_Lifecycle.jpg b/docs/VNF_Lifecycle.jpg new file mode 100644 index 0000000..45419e6 Binary files /dev/null and b/docs/VNF_Lifecycle.jpg differ diff --git a/docs/VNF_VNFC_Relation.jpg b/docs/VNF_VNFC_Relation.jpg new file mode 100644 index 0000000..0457e86 Binary files /dev/null and b/docs/VNF_VNFC_Relation.jpg differ diff --git a/docs/_static/css/ribbon.css b/docs/_static/css/ribbon.css new file mode 100644 index 0000000..6008cb1 --- /dev/null +++ b/docs/_static/css/ribbon.css @@ -0,0 +1,63 @@ +.ribbon { + z-index: 1000; + background-color: #a00; + overflow: hidden; + white-space: nowrap; + position: fixed; + top: 25px; + right: -50px; + -webkit-transform: rotate(45deg); + -moz-transform: rotate(45deg); + -ms-transform: rotate(45deg); + -o-transform: rotate(45deg); + transform: rotate(45deg); + -webkit-box-shadow: 0 0 10px #888; + -moz-box-shadow: 0 0 10px #888; + box-shadow: 0 0 10px #888; + +} + +.ribbon a { + border: 1px solid #faa; + color: #fff; + display: block; + font: bold 81.25% 'Helvetica Neue', Helvetica, Arial, sans-serif; + margin: 1px 0; + padding: 10px 50px; + text-align: center; + text-decoration: none; + text-shadow: 0 0 5px #444; + transition: 0.5s; +} + +.ribbon a:hover { + background: #c11; + color: #fff; +} + + +/* override table width restrictions */ +@media screen and (min-width: 767px) { + + .wy-table-responsive table td, .wy-table-responsive table th { + /* !important prevents the common CSS stylesheets from overriding + this as on RTD they are loaded after this stylesheet */ + white-space: normal !important; + } + + .wy-table-responsive { + overflow: visible !important; + } +} + +@media screen and (max-width: 767px) { + .wy-table-responsive table td { + white-space: nowrap; + } +} + +/* fix width of the screen */ + +.wy-nav-content { + max-width: none; +} diff --git a/docs/_static/favicon.ico b/docs/_static/favicon.ico new file mode 100755 index 0000000..cb712eb Binary files /dev/null and b/docs/_static/favicon.ico differ diff --git a/docs/_static/logo_onap_2017.png b/docs/_static/logo_onap_2017.png new file mode 100755 index 0000000..9f63444 Binary files /dev/null and b/docs/_static/logo_onap_2017.png differ diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html new file mode 100644 index 0000000..5784529 --- /dev/null +++ b/docs/_templates/layout.html @@ -0,0 +1,19 @@ +{# Import the theme's layout. #} +{% extends "!layout.html" %} + +{# Custom CSS override for warning banner #} +{% set css_files = css_files + ['_static/css/ribbon.css'] %} + +{# Ribbon #} +{% block content %} +
+ + Report Issue + +
+ {{ super() }} +{% endblock %} diff --git a/docs/index.rst b/docs/index.rst index 34a44e8..7ad0126 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -13,11 +13,12 @@ limitations under the License. -VNF Guidelines Documentation ----------------------------- +VNF Guidelines +============== .. toctree:: - :titlesonly: + :maxdepth: 2 + :numbered: - vnf_guidelines/index + vnf_guidelines diff --git a/docs/vnf_guidelines.rst b/docs/vnf_guidelines.rst new file mode 100644 index 0000000..f083dd1 --- /dev/null +++ b/docs/vnf_guidelines.rst @@ -0,0 +1,1224 @@ +.. Modifications Copyright © 2017-2018 AT&T Intellectual Property. + +.. Licensed under the Creative Commons License, Attribution 4.0 Intl. + (the "License"); you may not use this documentation except in compliance + with the License. You may obtain a copy of the License at + +.. https://creativecommons.org/licenses/by/4.0/ + +.. Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + +.. contents:: Table of Contents + :depth: 3 + :backlinks: entry + + +VNF/PNF Guidelines +================== + + +**Purpose** +------------------------ +- This document focuses on setting and evolving VNF/PNF standards that + will facilitate industry discussion, participation, alignment and evolution + towards comprehensive and actionable VNF/PNF best practices and standard + interface. +- The goal is to accelerate adoption of VNF/PNF best practices which will + increase innovation, minimize customization needed to onboard VNFs/PNFs as + well as reduce implementation complexity, time and cost for all impacted + stakeholders. +- The intent is to drive harmonization of VNFs/PNFs across VNF/PNF providers, + Network Cloud Service providers (NCSPs) and the overall Network Function + Virtualization (NFV) ecosystem by providing both long term vision as well + as short tem focus and clarity. + +**Scope** +-------------------- +- The audience for this document are VNF/PNF providers, NCSPs and other + interested 3rd parties who need to know the design, build and lifecycle + management requirements for VNFs/PNFs to be compliant with ONAP. +- These guidelines describe VNF environment and provide an overview of + what the VNF developer needs to know to operate and be compliant with ONAP. +- These guidelines contains high level expectations and references to + specific requirements documentation for VNFs/PNFs which are applicable + to the current release of ONAP. +- Part of the guidelines also contains visionary recommendations for + future functionality that could be desirable for ONAP future releases. +- Conformance requirements are in the `VNF/PNF Requirements + document `_. + +**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 + `_ 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 `_ + +.. [6] + `OpenStack `_ + +.. [7] + `OpenDaylight `_ + +.. [8] + `OPNFV `_ + +.. [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 diff --git a/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg b/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg deleted file mode 100644 index bc2d101..0000000 Binary files a/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg and /dev/null differ diff --git a/docs/vnf_guidelines/VNF_Lifecycle.jpg b/docs/vnf_guidelines/VNF_Lifecycle.jpg deleted file mode 100644 index 45419e6..0000000 Binary files a/docs/vnf_guidelines/VNF_Lifecycle.jpg and /dev/null differ diff --git a/docs/vnf_guidelines/VNF_VNFC_Relation.jpg b/docs/vnf_guidelines/VNF_VNFC_Relation.jpg deleted file mode 100644 index 0457e86..0000000 Binary files a/docs/vnf_guidelines/VNF_VNFC_Relation.jpg and /dev/null differ 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 `_. - -**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 - `_ 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 `_ - -.. [6] - `OpenStack `_ - -.. [7] - `OpenDaylight `_ - -.. [8] - `OPNFV `_ - -.. [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 diff --git a/etc/requirements.txt b/etc/requirements.txt index 377b7cd..db5c4ac 100644 --- a/etc/requirements.txt +++ b/etc/requirements.txt @@ -15,10 +15,20 @@ ############################################################################# tox -Sphinx==1.3.1 +Sphinx==1.7 doc8 docutils +docopt==0.6.2 setuptools six +sphinx_rtd_theme +sphinxcontrib-blockdiag sphinxcontrib-httpdomain +sphinxcontrib-needs>=0.2.4 sphinx_bootstrap_theme>=0.4.11 +sphinxcontrib-nwdiag +sphinxcontrib-seqdiag +sphinxcontrib-swaggerdoc +sphinxcontrib-plantuml +xlwt==1.3.0 +PyYAML>=3.10,<4 -- cgit 1.2.3-korg