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 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

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.

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).

VM

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

Virtual network

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

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. L3VPN Use Cases
    • 2.1.1. Any-to-Any Base Case
      • 2.1.1.1. Description
      • 2.1.1.2. Derrived Requirements
      • 2.1.1.3. Current implementation
      • 2.1.1.4. Gaps in the current solution
      • 2.1.1.5. Conclusion
    • 2.1.2. ECMP Load Splitting Case (Anycast)
      • 2.1.2.1. Description
      • 2.1.2.2. Derrived Requirements
      • 2.1.2.3. Current implementation
      • 2.1.2.4. Gaps in the current solution
      • 2.1.2.5. Conclusion
    • 2.1.3. Hub and Spoke Case
      • 2.1.3.1. Description
      • 2.1.3.2. Derrived Requirements
  • 2.2. Port Abstraction
    • 2.2.1. Description
    • 2.2.2. Requirements
      • 2.2.2.1. Data model
      • 2.2.2.2. Northbound API
      • 2.2.2.3. Orchestration
      • 2.2.2.4. Dependencies on other resources
    • 2.2.3. Implementation Proposal
  • 2.3. Programmable Provisioning of Provider networks
    • 2.3.1. Description
    • 2.3.2. Derrived Requirements
      • 2.3.2.1. Northbound API / Workflow
      • 2.3.2.2. Data model objects
    • 2.3.3. Current implementation
    • 2.3.4. Potential implementation
  • 2.4. Georedundancy
    • 2.4.1. Connection between different OpenStack cells
      • 2.4.1.1. Description
      • 2.4.1.2. Derrived Requirements
      • 2.4.1.3. Current implementation
      • 2.4.1.4. Gaps in the current solution
    • 2.4.2. Connection between different OpenStack regions or cloud instances
      • 2.4.2.1. Description
      • 2.4.2.2. Derrived Requirements
      • 2.4.2.3. Current implementation
      • 2.4.2.4. Gaps in the current solution
    • 2.4.3. Conclusion
• 3. Summary