Removal of the rememberance of Al
[opnfvdocs.git] / docs / release / overview.rst
index b6c3db5..6dd65cc 100644 (file)
@@ -4,9 +4,11 @@
 .. SPDX-License-Identifier: CC-BY-4.0
 .. (c) Open Platform for NFV Project, Inc. and its contributors
 
-===============
-OPNFV Overview
-===============
+NOTE: This Document will be updated for Anuket in the Lakelse Release.
+
+=================
+Platform overview
+=================
 
 Introduction
 ============
@@ -28,20 +30,16 @@ NFV use cases. OPNFV also works upstream with other open source communities to b
 and learnings from its work directly to those communities in the form of blueprints, patches, bugs,
 and new code.
 
-OPNFV initially focused on building NFV Infrastructure (NFVI) and Virtualised Infrastructure
-Management (VIM) by integrating components from upstream projects such as OpenDaylight,
-OpenStack, Ceph Storage, KVM, Open vSwitch, and Linux.
-More recently, OPNFV has extended its portfolio of forwarding solutions to include fd.io and ODP,
-is able to run on both Intel and ARM commercial and white-box hardware, support VM, Container and
-BareMetal workloads, and includes Management and Network Orchestration MANO components primarily
-for application composition and management in the Danube release.
+OPNFV focuses on building NFV Infrastructure (NFVI) and Virtualized Infrastructure Management (VIM) by
+integrating components from upstream projects such as OpenDaylight, OVN, OpenStack, Kubernetes,
+Ceph Storage, KVM, Open vSwitch, Linux, DPDK and FD.io. OPNFV- is able to run on both Intel and
+ARM commercial and white-box hardware, support VM, Container and BareMetal workloads.
 
 These capabilities, along with application programmable interfaces (APIs) to other NFV
 elements, form the basic infrastructure required for Virtualized Network Functions (VNF)
 and MANO components.
 
-Concentrating on these components while also considering proposed projects on additional
-topics (such as the MANO components and applications themselves), OPNFV aims to enhance
+Concentrating on these components, OPNFV aims to enhance
 NFV services by increasing performance and power efficiency improving reliability,
 availability and serviceability, and delivering comprehensive platform instrumentation.
 
@@ -55,17 +53,17 @@ platform including common hardware requirements, software architecture, MANO and
 
 OPNFV Platform Overview Diagram
 
-.. image:: ../images/opnfvplatformgraphic.png
+.. image:: ../images/hunter.png
    :alt: Overview infographic of the opnfv platform and projects.
 
 
 To address these areas effectively, the OPNFV platform architecture can be decomposed
 into the following basic building blocks:
 
-* Hardware: with the Infra working group, Pharos project and associated activities
-* Software Platform: through the platform integration and deployment projects
-* MANO: through the MANO working group and associated projects
-* Applications: which affect all other areas and drive requirements for OPNFV
+* Hardware: Infrastructure working group, Pharos project and associated activities
+* Software Platform: Platform integration and deployment projects
+* Tooling and testing: Testing working group and test projects
+* Applications: All other areas and drive requirements for OPNFV
 
 OPNFV Lab Infrastructure
 ========================
@@ -74,7 +72,7 @@ The infrastructure working group oversees such topics as lab management, workflo
 definitions, metrics and tools for OPNFV infrastructure.
 
 Fundamental to the WG is the
-`Pharos Specification <https://wiki.opnfv.org/display/pharos/Pharos+Specification>`_
+`Pharos Specification <http://artifacts.opnfv.org/pharos/docs/pharos-spec.html>`_
 which provides a set of defined lab infrastructures over a geographically and technically
 diverse federated global OPNFV lab.
 
@@ -87,49 +85,46 @@ performance characteristics.
 Community labs are hosted by OPNFV member companies on a voluntary basis.
 The Linux Foundation also hosts an OPNFV lab that provides centralized CI
 and other production resources which are linked to community labs.
-Future lab capabilities will include the ability easily automate deploy and test of any
-OPNFV install scenario in any lab environment as well as on a nested "lab as a service"
-virtual infrastructure.
+
+The Lab-as-a-service (LaaS) offering provides developers to readily access NFV infrastructure on demand.
+Ongoing lab capabilities will include the ability to easily automate deployment and test of any OPNFV install
+scenario in any lab environment using a concept called “Dynamic CI”.
 
 OPNFV Software Platform Architecture
 ====================================
 
 The OPNFV software platform is comprised exclusively of open source implementations of
 platform component pieces.  OPNFV is able to draw from the rich ecosystem of NFV related
-technologies available in open-source then integrate, test, measure and improve these
-components in conjunction with our source communities.
-
-While the composition of the OPNFV software platform is highly complex and constituted of many
-projects and components, a subset of these projects gain the most attention from the OPNFV community
-to drive the development of new technologies and capabilities.
+technologies available in open source communities, and then integrate, test, measure and improve these
+components in conjunction with our upstream communities.
 
 ---------------------------------
 Virtual Infrastructure Management
 ---------------------------------
 
-OPNFV derives it's virtual infrastructure management from one of our largest upstream ecosystems
-OpenStack.  OpenStack provides a complete reference cloud management system and associated technologies.
-While the OpenStack community sustains a broad set of projects, not all technologies are relevant in
-an NFV domain, the OPNFV community consumes a sub-set of OpenStack projects where the usage and
-composition may vary depending on the installer and scenario.
+OPNFV derives its Virtual Infrastructure Management from OpenStack and Kubernetes. OpenStack provides a
+complete reference cloud management system and associated technologies. While the OpenStack community
+sustains a broad set of projects, not all technologies are relevant in the NFV domain, the OPNFV community
+consumes a sub-set of OpenStack projects and the usage and composition may vary depending on the installer and scenario.
+Additionally, OPNFV also uses Kubernetes, the popular Container Orchestration Engine. Kubernetes is intended to be a VIM for
+Cloud Native Network Functions (CNFs).
 
 For details on the scenarios available in OPNFV and the specific composition of components
-refer to the :ref:`OPNFV User Guide & Configuration Guide <opnfv-user-config>`
+refer to the :ref:`OPNFV User Guide & Configuration Guide <opnfv-user-config>`.
 
 -----------------
 Operating Systems
 -----------------
 
-OPNFV currently uses Linux on all target machines, this can include Ubuntu, Centos or SUSE linux. The
+OPNFV currently uses Linux on all target machines. The
 specific version of Linux used for any deployment is documented in the installation guide.
 
------------------------
 Networking Technologies
------------------------
+=======================
 
+---------------
 SDN Controllers
 ---------------
-
 OPNFV, as an NFV focused project, has a significant investment on networking technologies
 and provides a broad variety of integrated open source reference solutions.  The diversity
 of controllers able to be used in OPNFV is supported by a similarly diverse set of
@@ -140,34 +135,33 @@ where the OPNFV community supports and contributes to a number of these.  The co
 being worked on by the community during this release of OPNFV include:
 
 * Neutron: an OpenStack project to provide “network connectivity as a service” between
-  interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova).
+  interface devices (e.g., vNICs) managed by other OpenStack services (e.g. Nova).
 * OpenDaylight: addresses multivendor, traditional and greenfield networks, establishing the
   industry’s de facto SDN platform and providing the foundation for networks of the future.
-* ONOS: a carrier-grade SDN network operating system designed for high availability,
-  performance, scale-out.
-
-.. OpenContrail SDN controller is planned to be supported in the next release.
+* OVN: a distributed control-plane on top of the popular Open vSwitch (OVS) offers network virtualization
+  services.
 
+----------
 Data Plane
 ----------
-
 OPNFV extends Linux virtual networking capabilities by using virtual switching
-and routing components. The OPNFV community proactively engages with these source
+and routing components. The OPNFV community proactively engages with the following open source
 communities to address performance, scale and resiliency needs apparent in carrier
 networks.
 
-* FD.io (Fast data - Input/Output): a collection of several projects and libraries to
-  amplify the transformation that began with Data Plane Development Kit (DPDK) to support
-  flexible, programmable and composable services on a generic hardware platform.
-* Open vSwitch: a production quality, multilayer virtual switch designed to enable
-  massive network automation through programmatic extension, while still supporting standard
-  management interfaces and protocols.
+* OVS (Open vSwitch): a production quality, multilayer virtual switch designed to enable massive
+  network automation through programmatic extension, while still supporting standard management interfaces and protocols.
+* FD.io (Fast data - Input/Output): a high performance alternative to Open vSwitch, the core engine of
+  FD.io is a vector processing engine (VPP). VPP processes a number of packets in parallel instead of one at
+  a time thus significantly improving packet throughput.
+* DPDK:  a set of libraries that bypass the kernel and provide polling mechanisms, instead of interrupt based operations,
+  to speed up packet processing. DPDK works with both OVS and FD.io.
 
 Deployment Architecture
 =======================
 
 A typical OPNFV deployment starts with three controller nodes running in a high availability
-configuration including control plane components from OpenStack, SDN, etc. and a minimum
+configuration including control plane components from OpenStack, SDN controllers, etc. and a minimum
 of two compute nodes for deployment of workloads (VNFs).
 A detailed description of the hardware requirements required to support the 5 node configuration
 can be found in pharos specification: `Pharos Project <https://www.opnfv.org/developers/pharos>`_
@@ -202,30 +196,23 @@ Release Verification
 ====================
 
 The OPNFV community relies on its testing community to establish release criteria for each OPNFV
-release. Each release cycle the testing criteria become more stringent and better representative
-of our feature and resiliency requirements.
-
-
-As each OPNFV release establishes a set of deployment scenarios to validate, the testing
-infrastructure and test suites need to accommodate these features and capabilities. It’s not
-only in the validation of the scenarios themselves where complexity increases, there are test
-cases that require multiple datacenters to execute when evaluating features, including multisite
-and distributed datacenter solutions.
+release. With each release cycle the testing criteria become more stringent and better representative
+of our feature and resiliency requirements. Each release establishes a set of deployment scenarios to validate,
+the testing infrastructure and test suites need to accommodate these features and capabilities.
 
 The release criteria as established by the testing teams include passing a set of test cases
 derived from the functional testing project ‘functest,’ a set of test cases derived from our
 platform system and performance test project ‘yardstick,’ and a selection of test cases for
 feature capabilities derived from other test projects such as bottlenecks, vsperf, cperf and
 storperf. The scenario needs to be able to be deployed, pass these tests, and be removed from
-the infrastructure iteratively (no less that 4 times) in order to fulfil the release criteria.
+the infrastructure iteratively in order to fulfill the release criteria.
 
 --------
 Functest
 --------
-
 Functest provides a functional testing framework incorporating a number of test suites
 and test cases that test and verify OPNFV platform functionality.
-The scope of Functest and relevant test cases can be found in the :ref:`Functest User Guide <Functest-UserGuide>`
+The scope of Functest and relevant test cases can be found in the :ref:`Functest User Guide <functest-userguide>`
 
 Functest provides both feature project and component test suite integration, leveraging
 OpenStack and SDN controllers testing frameworks to verify the key components of the OPNFV
@@ -234,7 +221,6 @@ platform are running successfully.
 ---------
 Yardstick
 ---------
-
 Yardstick is a testing project for verifying the infrastructure compliance when running VNF applications.
 Yardstick benchmarks a number of characteristics and performance vectors on the infrastructure making it
 a valuable pre-deployment NFVI testing tools.
@@ -248,6 +234,9 @@ There are two types of test cases in Yardstick:
 * OPNFV feature test cases include basic telecom feature testing from OPNFV projects;
   for example nfv-kvm, sfc, ipv6, Parser, Availability and SDN VPN
 
+With the addition of the Network Service Benchmarking (NSB) initiative, it is possible to use Yardstick NSB
+for benchmarking the performance of VNFs and Network Services.
+
 System Evaluation and compliance testing
 ========================================
 
@@ -256,12 +245,9 @@ behaviors and capabilities for NFV systems developed externally from the OPNFV e
 evaluate and measure their ability to provide the features and capabilities developed in the
 OPNFV ecosystem.
 
-The Dovetail project will provide a test framework and methodology able to be used on any NFV platform,
+The Dovetail project provides a test framework and methodology able to be used on any NFV platform,
 including an agreed set of test cases establishing an evaluation criteria for exercising
-an OPNFV compatible system. The Dovetail project has begun establishing the test framework
-and will provide a preliminary methodology for the Danube release. Work will continue to
-develop these test cases to establish a stand alone compliance evaluation solution
-in future releases.
+an OPNFV compatible system.
 
 Additional Testing
 ==================
@@ -274,21 +260,33 @@ additional testing stimuli, or tests simulating environmental disturbances or fa
 These additional testing activities provide a more complete evaluation of the OPNFV platform.
 Some of the projects focused on these testing areas include:
 
+-----------
+Bottlenecks
+-----------
+Bottlenecks provides a framework to find system limitations and bottlenecks, providing
+root cause isolation capabilities to facilitate system evaluation.
+
+--------
+NFVBench
+--------
+NFVbench is a lightweight end-to-end dataplane benchmarking framework project.
+It includes traffic generator(s) and measures a number of packet performance related metrics.
+
+--------
+Storperf
+--------
+Storperf measures the performance of external block storage. The goal of this project is
+to provide a report based on SNIA’s (Storage Networking Industry Association) Performance Test Specification.
+
 ------
 VSPERF
 ------
-
 VSPERF provides an automated test-framework and comprehensive test suite for measuring data-plane
 performance of the NFVI including switching technology, physical and virtual network interfaces.
 The provided test cases with network topologies can be customized while also allowing individual
 versions of Operating System, vSwitch and hypervisor to be specified.
 
------------
-Bottlenecks
------------
 
-Bottlenecks provides a framework to find system limitations and bottlenecks, providing
-root cause isolation capabilities to facilitate system evaluation.
 
 
 .. _`OPNFV Configuration Guide`: `OPNFV User Guide & Configuration Guide`