docs/overview/overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) Open Platform for NFV Project, Inc. and its contributors
   4
   5 ============
   6 Introduction
   7 ============
   8
   9 Network Functions Virtualization (NFV) is transforming the networking industry via
  10 software-defined infrastructures and open source is the proven method for developing
  11 software quickly for commercial products and services that can move markets.
  12 Open Platform for NFV (OPNFV) facilitates the development and evolution of NFV
  13 components across various open source ecosystems. Through system level integration,
  14 deployment and testing, OPNFV constructs a reference NFV platform to accelerate the
  15 transformation of enterprise and service provider networks.
  16 As an open source project, OPNFV is uniquely positioned to bring together the work
  17 of standards bodies, open source communities, and commercial suppliers to deliver a
  18 de facto NFV platform for the industry.
  19
  20 By integrating components from upstream projects, the community is able to conduct performance
  21 and use case-based testing on a variety of solutions to ensure the platform’s suitability for
  22 NFV use cases. OPNFV also works upstream with other open source communities to bring both contributions
  23 and learnings from its work directly to those communities in the form of blueprints, patches,
  24 and new code.
  25
  26 OPNFV initially focused on building NFV Infrastructure (NFVI) and Virtualised Infrastructure
  27 Management (VIM) by integrating components from upstream projects such as OpenDaylight,
  28 OpenStack, Ceph Storage, KVM, Open vSwitch, and Linux.
  29 More recently, OPNFV has extended its portfolio of forwarding solutions to include fd.io and ODP,
  30 is able to run on both Intel and ARM commercial and white-box hardware, and includes
  31 Management and Network Orchestration MANO components primarily for application composition
  32 and management in the Colorado release.
  33
  34 These capabilities, along with application programmable interfaces (APIs) to other NFV
  35 elements, form the basic infrastructure required for Virtualized Network Functions (VNF)
  36 and MANO components.
  37
  38 Concentrating on these components while also considering proposed projects on additional
  39 topics (such as the MANO components and applications themselves), OPNFV aims to enhance
  40 NFV services by increasing performance and power efficiency improving reliability,
  41 availability and serviceability, and delivering comprehensive platform instrumentation.
  42
  43 ===========================
  44 OPNFV Platform Architecture
  45 ===========================
  46
  47 The OPNFV project addresses a number of aspects in the development of a consistent virtualisation
  48 platform including common hardware requirements, software architecture, MANO and applications.
  49
  50
  51 OPNFV Platform Overview Diagram
  52
  53 .. image:: ../images/opnfvplatformgraphic.png
  54    :alt: Overview infographic of the opnfv platform and projects.
  55
  56
  57 To address these areas effectively, the OPNFV platform architecture can be decomposed
  58 into the following basic building blocks:
  59
  60 * Hardware: with the Infra working group, Pharos project and associated activities
  61 * Software Platform: through the platform integration and deployment projects
  62 * MANO: through the MANO working group and associated projects
  63 * Applications: which affect all other areas and drive requirements for OPNFV
  64
  65 OPNFV Lab Infrastructure
  66 ========================
  67
  68 The infrastructure working group oversees such topics as lab management, workflow,
  69 definitions, metrics and tools for OPNFV infrastructure.
  70
  71 Fundamental to the WG is the `Pharos Project <https://www.opnfv.org/developers/pharos>`_
  72 which provides a set of defined lab infrastructures over a geographically and technically
  73 diverse federated global OPNFV lab.
  74
  75 Labs may instantiate bare-metal and virtual environments that are accessed remotely by the
  76 community and used for OPNFV platform and feature development, build, deploy and testing.
  77 No two labs are the same and the heterogeneity of the Pharos environment provides the ideal
  78 platform for establishing hardware and software abstractions providing well understood
  79 performance characteristics.
  80
  81 Community labs are hosted by OPNFV member companies on a voluntary basis.
  82 The Linux Foundation also hosts an OPNFV lab that provides centralized CI
  83 and other production resources which are linked to community labs.
  84 Future lab capabilities will include the ability easily automate deploy and test of any
  85 OPNFV install scenario in any lab environment as well as on a nested "lab as a service"
  86 virtual infrastructure.
  87
  88 OPNFV Software Platform Architecture
  89 ====================================
  90
  91 The OPNFV software platform is comprised exclusively of open source implementations of
  92 platform component pieces.  OPNFV is able to draw from the rich ecosystem of NFV related
  93 technologies available in open-source then integrate, test, measure and improve these
  94 components in conjunction with our source communities.
  95
  96 While the composition of the OPNFV software platform is highly complex and constituted of many
  97 projects and components, a subset of these projects gain the most attention from the OPNFV community
  98 to drive the development of new technologies and capabilities.
  99
 100 ---------------------------------
 101 Virtual Infrastructure Management
 102 ---------------------------------
 103
 104 OPNFV derives it's virtual infrastructure management from one of our largest upstream ecosystems
 105 OpenStack.  OpenStack provides a complete reference cloud management system and associated technologies.
 106 While the OpenStack community sustains a broad set of projects, not all technologies are relevant in
 107 an NFV domain, the OPNFV community consumes a sub-set of OpenStack projects where the usage and
 108 composition may vary depending on the installer and scenario.
 109
 110 For details on the scenarios available in OPNFV and the specific composition of components
 111 refer to the OPNFV installation instruction:
 112 http://artifacts.opnfv.org/opnfvdocs/colorado/3.0/docs/installationprocedure/index.html
 113
 114 -----------------
 115 Operating Systems
 116 -----------------
 117
 118 OPNFV currently uses Linux on all target machines, this can include Ubuntu, Centos or SUSE linux. The
 119 specific version of Linux used for any deployment is documented in the installation guide.
 120
 121 -----------------------
 122 Networking Technologies
 123 -----------------------
 124
 125 SDN Controllers
 126 ---------------
 127
 128 OPNFV, as an NFV focused project, has a significant investment on networking technologies
 129 and provides a broad variety of integrated open source reference solutions.  The diversity
 130 of controllers able to be used in OPNFV is supported by a similarly diverse set of
 131 forwarding technologies.
 132
 133 There are many SDN controllers available today relevant to virtual environments
 134 where the OPNFV community supports and contributes to a number of these.  The controllers
 135 being worked on by the community during this release of OPNFV include:
 136
 137 * Neutron: an OpenStack project to provide “network connectivity as a service” between
 138   interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova).
 139 * OpenDaylight: addresses multivendor, traditional and greenfield networks, establishing the
 140   industry’s de facto SDN platform and providing the foundation for networks of the future.
 141 * ONOS: a carrier-grade SDN network operating system designed for high availability,
 142   performance, scale-out.
 143
 144 .. OpenContrail SDN controller is planned to be supported in the next release.
 145
 146 Data Plane
 147 ----------
 148
 149 OPNFV extends Linux virtual networking capabilities by using virtual switching
 150 and routing components. The OPNFV community proactively engages with these source
 151 communities to address performance, scale and resiliency needs apparent in carrier
 152 networks.
 153
 154 * FD.io (Fast data - Input/Output): a collection of several projects and libraries to
 155   amplify the transformation that began with Data Plane Development Kit (DPDK) to support
 156   flexible, programmable and composable services on a generic hardware platform.
 157 * Open vSwitch: a production quality, multilayer virtual switch designed to enable
 158   massive network automation through programmatic extension, while still supporting standard
 159   management interfaces and protocols.
 160
 161 Deployment Architecture
 162 =======================
 163
 164 A typical OPNFV deployment starts with three controller nodes running in a high availability
 165 configuration including control plane components from OpenStack, SDN, etc. and a minimum
 166 of two compute nodes for deployment of workloads (VNFs).
 167 A detailed description of the hardware requirements required to support the 5 node configuration
 168 can be found in pharos specification: http://artifacts.opnfv.org/pharos/colorado/3.0/docs/specification/index.html
 169
 170 In addition to the deployment on a highly available physical infrastructure, OPNFV can be
 171 deployed for development and lab purposes in a virtual environment.  In this case each of the hosts
 172 is provided by a virtual machine and allows control and workload placement using nested virtualization.
 173
 174 The initial deployment is done using a staging server, referred to as the "jumphost".
 175 This server-either physical or virtual-is first installed with the installation program
 176 that then installs OpenStack and other components on the controller nodes and compute nodes.
 177 See the `OPNFV User Guide`_ for more details.
 178
 179 ===========================
 180 The OPNFV Testing Ecosystem
 181 ===========================
 182
 183 The OPNFV community has set out to address the needs of virtualization in the carrier
 184 network and as such platform validation and measurements are a cornerstone to the
 185 iterative releases and objectives.
 186
 187 To simplify the complex task of feature, component and platform validation and characterization
 188 the testing community has established a fully automated method for addressing all key areas of
 189 platform validation. This required the integration of a variety of testing frameworks in our CI
 190 systems, real time and automated analysis of results, storage and publication of key facts for
 191 each run.
 192
 193
 194 Release Verification
 195 ====================
 196
 197 The OPNFV community relies on its testing community to establish release criteria for each OPNFV
 198 release. Each release cycle the testing criteria become more stringent and better representative
 199 of our feature and resiliency requirements.
 200
 201
 202 As each OPNFV release establishes a set of deployment scenarios to validate, the testing
 203 infrastructure and test suites need to accommodate these features and capabilities. It’s not
 204 only in the validation of the scenarios themselves where complexity increases, there are test
 205 cases that require multiple datacenters to execute when evaluating features, including multisite
 206 and distributed datacenter solutions.
 207
 208 The release criteria as established by the testing teams include passing a set of test cases
 209 derived from the functional testing project ‘functest,’ a set of test cases derived from our
 210 platform system and performance test project ‘yardstick,’ and a selection of test cases for
 211 feature capabilities derived from other test projects such as bottlenecks, vsperf, cperf and
 212 storperf. The scenario needs to be able to be deployed, pass these tests, and be removed from
 213 the infrastructure iteratively (no less that 4 times) in order to fulfill the release criteria.
 214
 215 --------
 216 Functest
 217 --------
 218
 219 Functest provides a functional testing framework incorporating a number of test suites
 220 and test cases that test and verify OPNFV platform functionality.
 221 The scope of Functest and relevant test cases can be found in its
 222 `user guide <http://artifacts.opnfv.org/functest/colorado/3.0/docs/userguide/index.html>`_.
 223
 224 Functest provides both feature project and component test suite integration, leveraging
 225 OpenStack and SDN controllers testing frameworks to verify the key components of the OPNFV
 226 platform are running successfully.
 227
 228 ---------
 229 Yardstick
 230 ---------
 231
 232 Yardstick is a testing project for verifying the infrastructure compliance when running VNF applications.
 233 Yardstick benchmarks a number of characteristics and performance vectors on the infrastructure making it
 234 a valuable pre-deployment NFVI testing tools.
 235
 236 Yardstick provides a flexible testing framework for launching other OPNFV testing projects.
 237
 238 There are two types of test cases in Yardstick:
 239
 240 * Yardstick generic test cases and OPNFV feature test cases;
 241   including basic characteristics benchmarking in compute/storage/network area.
 242 * OPNFV feature test cases include basic telecom feature testing from OPNFV projects;
 243   for example nfv-kvm, sfc, ipv6, Parser, Availability and SDN VPN
 244
 245 System Evaluation and compliance testing
 246 ========================================
 247
 248 The OPNFV community is developing a set of test suites intended to evaluate a set of reference
 249 behaviors and capabilities for NFV systems developed externally from the OPNFV ecosystem to
 250 evaluate and measure their ability to provide the features and capabilities developed in the
 251 OPNFV ecosystem.
 252
 253 The Dovetail project will provide a test framework and methodology able to be used on any NFV platform,
 254 including an agreed set of test cases establishing an evaluation criteria for exercising
 255 an OPNFV compatible system. The Dovetail project has begun establishing the test framework
 256 and will provide a preliminary methodology for the Colorado release. Work will continue to
 257 develop these test cases to establish a stand alone compliance evaluation solution
 258 in future releases.
 259
 260 Additional Testing
 261 ==================
 262
 263 Besides the test suites and cases for release verification, additional testing is performed to validate
 264 specific features or characteristics of the OPNFV platform.
 265 These testing framework and test cases may include some specific needs; such as extended measurements,
 266 additional testing stimuli, or tests simulating environmental disturbances or failures.
 267
 268 These additional testing activities provide a more complete evaluation of the OPNFV platform.
 269 Some of the projects focused on these testing areas include:
 270
 271 ------
 272 VSPERF
 273 ------
 274
 275 VSPERF provides a generic and architecture agnostic vSwitch testing framework and associated tests.
 276 This serves as a basis for validating the suitability of different vSwitch implementations and deployments.
 277
 278 -----------
 279 Bottlenecks
 280 -----------
 281
 282 Bottlenecks provides a framework to find system limitations and bottlenecks, providing
 283 root cause isolation capabilities to facilitate system evaluation.
 284
 285
 286 .. _`OPNFV Configuration Guide`: http://artifacts.opnfv.org/opnfvdocs/colorado/3.0/docs/configguide
 287 .. _`OPNFV User Guide`: http://artifacts.opnfv.org/opnfvdocs/colorado/3.0/docs/userguide
 288 .. _Dovetail project: https://wiki.opnfv.org/display/dovetail