NetReady: Network Readiness

Project:

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

Editors:

TBD

Authors:

Georg Kunz (Ericsson), <add your name here>

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 SDOs and communities use different terminology related to NFV/Cloud/SDN. This list tries to define an OPNFV terminology, mapping/translating the OPNFV terms to terminology used in other contexts.

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 (re-)creating 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.2. ECMP Load Splitting Case (Anycast)
      • 2.1.2.1. Description
      • 2.1.2.2. Derrived Requirements
    • 2.1.3. Hub and Spoke Case
      • 2.1.3.1. Description
      • 2.1.3.2. Derrived Requirements
  • 2.2. Shared Service Functions
    • 2.2.1. Description
    • 2.2.2. Requirements
      • 2.2.2.1. Northbound API
      • 2.2.2.2. Data models
      • 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.2.3. Orchestration
      • 2.3.2.4. Dependencies on compute services
      • 2.3.2.5. Potential implementation
  • 2.4. Georedundancy Use cases (Draft)
    • 2.4.1. Connection between different OpenStack cells
      • 2.4.1.1. Description
      • 2.4.1.2. Derrived Requirements
    • 2.4.2. Connection between different OpenStack regions or cloud instances
      • 2.4.2.1. Description
      • 2.4.2.2. Derrived Requirements
  • 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.2. ECMP Load Splitting Case (Anycast)
      • 2.1.2.1. Description
      • 2.1.2.2. Derrived Requirements
    • 2.1.3. Hub and Spoke Case
      • 2.1.3.1. Description
      • 2.1.3.2. Derrived Requirements
• 3. Current solutions
• 4. Gap analysis
• 5. Architecture
• 6. Implementation
• 7. Summary