NetReady: Network Readiness

Project:

NetReady, https://wiki.opnfv.org/display/netready/NetReady

Editors:

TBD

Authors:

Bin Hu (AT&T), Gergely Csatari (Nokia), Georg Kunz (Ericsson) and others

Abstract:

OPNFV provides an infrastructure with different SDN controller options to realize NFV functionality on the platform it builds. As OPNFV uses OpenStack as a VIM, we need to analyze the capabilities this component offers us. The networking functionality is provided by a single component called Neutron, which hides the controller under it, let it be Neutron itself or any supported SDN controller. As NFV wasn’t taken into consideration at the time when Neutron was designed we are already facing several bottlenecks and architectural shortcomings while implementing our use cases.

The NetReady project aims at evolving OpenStack networking step-by-step to find the most efficient way to fulfill the requirements of the identified NFV use cases, taking into account the NFV mindset and the capabilities of SDN controllers.

History:

Date	Description
22.03.2016	Project creation
19.04.2016	Initial version of the deliverable uploaded to Gerrit
22.07.2016	First version ready for sharing with the community

Definition of terms

Different standards developing organizations and communities use different terminology related to Network Function Virtualization, Cloud Computing, and Software Defined Networking. This list defines the terminology in the contexts of this document.

API

Application Programming Interface.

Cloud Computing

A model that enables access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services, that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Edge Computing

Edge computing pushes applications, data and computing power (services) away from centralized points to the logical extremes of a network.

Instance

Refers in OpenStack terminology to a running VM, or a VM in a known state such as suspended, that can be used like a hardware server.

NFV

Network Function Virtualization.

NFVI

Network Function Virtualization Infrastructure. Totality of all hardware and software components which build up the environment in which VNFs are deployed.

SDN

Software-Defined Networking. Emerging architecture that decouples the network control and forwarding functions, enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services.

Server

Computer that provides explicit services to the client software running on that system, often managing a variety of computer operations. In OpenStack terminology, a server is a VM instance.

vForwarder

vForwarder is used as generic and vendor neutral term for a software packet forwarder. Concrete examples includes OpenContrail vRouter, OpenvSwitch, Cisco VTF.

VIM

Virtualized Infrastructure Manager. Functional block that is responsible for controlling and managing the NFVI compute, storage and network resources, usually within one operator’s Infrastructure Domain, e.g. NFVI Point of Presence (NFVI-PoP).

Virtual network

Virtual network routes information among the network interfaces of VM instances and physical network interfaces, providing the necessary connectivity.

VM

Virtual Machine. Virtualized computation environment that behaves like a physical computer/server by modeling the computing architecture of a real or hypothetical computer.

VNF

Virtualized Network Function. Implementation of an Network Function that can be deployed on a Network Function Virtualization Infrastructure (NFVI).

WAN

Wide Area Network.

• 1. Introduction
  • 1.1. Scope
  • 1.2. Problem Description
  • 1.3. Goals
• 2. Use cases
  • 2.1. Multiple Networking Backends
    • 2.1.1. Description
    • 2.1.2. Requirements
    • 2.1.3. Current Implementation
      • 2.1.3.1. Core and ML2 Plugins
      • 2.1.3.2. Neutron Service Plugins
    • 2.1.4. Gaps in the current solution
      • 2.1.4.1. [MB-GAP1] Limited support for multiple back-ends
    • 2.1.5. Conclusion
  • 2.2. L3VPN Use Cases
    • 2.2.1. Any-to-Any Base Case
      • 2.2.1.1. Description
      • 2.2.1.2. Derived Requirements
      • 2.2.1.3. Current implementation
      • 2.2.1.4. Gaps in the current solution
    • 2.2.2. L3VPN: ECMP Load Splitting Case (Anycast)
      • 2.2.2.1. Description
      • 2.2.2.2. Current implementation
      • 2.2.2.3. Gaps in the current solution
      • 2.2.2.4. Conclusions
    • 2.2.3. Hub and Spoke Case
      • 2.2.3.1. Description
      • 2.2.3.2. Derived Requirements
    • 2.2.4. Conclusion
  • 2.3. Service Binding Design Pattern
    • 2.3.1. Description
    • 2.3.2. Requirements
      • 2.3.2.1. Data model
      • 2.3.2.2. Northbound API
      • 2.3.2.3. Orchestration
      • 2.3.2.4. Dependencies on other resources
    • 2.3.3. Current Implementation
    • 2.3.4. Conclusions
  • 2.4. Programmable Provisioning of Provider Networks
    • 2.4.1. Description
    • 2.4.2. Derived Requirements
      • 2.4.2.1. Northbound API / Workflow
      • 2.4.2.2. Data model objects
    • 2.4.3. Current implementation
    • 2.4.4. Potential implementation
  • 2.5. Georedundancy
    • 2.5.1. Connection between different OpenStack cells
      • 2.5.1.1. Description
      • 2.5.1.2. Derived Requirements
      • 2.5.1.3. Current implementation
      • 2.5.1.4. Gaps in the current solution
    • 2.5.2. Connection between different OpenStack regions or cloud instances
      • 2.5.2.1. Description
      • 2.5.2.2. Derived Requirements
      • 2.5.2.3. Current implementation
      • 2.5.2.4. Gaps in the current solution
    • 2.5.3. Conclusion
• 3. Summary and Conclusion