nfv open stack-shuo-yang

Shuo Yang Principal Architect of Cloud Computing, US R&D Center

OpenStack and NFV: Convergence of IT and CT Infrastructure

1

Agenda

Challenges and Opportunities

Relevant Industry Trends

Telco Operator Perspective

1

2

3

2

Software-Defined Everything

SDN, SDS, SDDC…

Cloud – a Software-defined Resource Pool

Virtualizing the underlying components and making it accessible through an API

Abstraction, aggregation(pooled), and automation via API

What has been done for compute is being repeated for network and

storage

Virtualization and consolidation

Programmatic provision, orchestration

Scale-out

Commoditization (standard components)

Virtual

Machines

Compute API

Virtual

Storage

Storage API

Virtual

Networks

Network API

3

OpenStack – a 10,000 Feet View

OpenStack Mission

To produce the ubiquitous Open Source cloud computing platform that will meet the

needs of public and private cloud providers regardless of size…

Common Interest from IT Vendors

Oct. 2010, first design summit held in Austin

No single dominant vendor, avoid vendor lock-in

Linux for cloud

API Driven Architecture

Proven architecture model used by the largest public clouds and made it accessible to

masses for use on commodity hardware

4

NFV – a 10,000 Feet View

NFV Mission

Replace purposely-built hardware with standard hardware for better price

performance ratio

Common Interest from Telco Service Providers

Born in Oct. 2012 by a list of top Telco service providers

No vendor lock-in

Apache family for network applications

Adding API to Control Network Functionality

use IT methodology to solve CT problems

Functionalities L4-L7

5

Agenda




1

2

3

6

NFV – a Carrier-lead Initiative

Benefit of NFV Initiative

Reduction of Capex

Reduction of Opex

Faster time-to-market

Agility and Flexibility of Delivering Network

Functionality

Source: NFV_White_Paper

7

Execution reference points

Main NFV reference points Other reference points

Source: NFV GS NFV-0010 V0.1.6 2013/8

VNF: Virtual Network Function

OSS/BSS：Traditional OSS/BSS (Operations/Business Support Systems)

EMS : Traditional EMS (Element Management System )

NFVI: NFV Infrastructure 1

2

3

4

Computing Hardware

Storage Hardware

Network Hardware

Hardware resources

Virtualisation Layer

Virtualised

Infrastructure

Manager(s)

VNF Manager(s)

VNF 2

Orchestrator

OSS/BSS

NFVI

VNF 3

VNF 1

Virtual Computing

Virtual Storage

Virtual Network

EMS 2

EMS 3

EMS 1

Service, VNF and Infrastructure Description

Or-Vi

Or-Vnfm

Vi-Vnfm

Os-Ma

Se-Ma

Ve-Vnfm

Nf-Vi

Vn-Nf

Vl-Ha

1

2

3

4 5

MANO: Management and Orchestration 5 MANO

NFV Reference Architecture

NFV E2E Reference Architecture

8

DC/Rack

BOX Software Model

Decoupling between software(Telecom App) and hardware Standardized interface between NFV elements and infrastructure Telco network/element deployment automation, roll-out efficiency Resource pools cover all segment networks from access network, GW,

core networks, to OSS/BSS and application

LBS App 2 App 2 App 3 App 4

Switch Fabric Controller

ATCA

Ap

p 1

LBS

Co

ntro

ller

Ap

p 2

Ap

p 2

Ap

p 4

Ap

p 3


IP/Ethernet Fabric

VM VM VM VM VM

VM

Controller

Physical Server Physical Server

EMS/NMS Consistent app

and physical resource view

No change to the EMS Physical and app, 1:1 mapping

Cloud – Perfect Platform for NFV

NFV Software Model

Chassis

ATCA

DC/Rack

9

BBU SRC RNC

PCRF SGSN MME

SDN Contro

ller &APPs

IMS BSS OSS EMS …… Third-Party APP

Office GGSN EPC FW DPI SBC

BRAS

OpenStack+ API

ESX/Hyper-

V KVM/XEN

Server Server Storage Server

OVS/VGW

Switch/GW Server

OpenStack

Nova Cinder Neutron

VNF Managers & MANO

NFVI managers

Virtualization Layer

COTS Hardware

NFV on OpenStack

IT Middleware

CT Middleware

Ceph

Server

ICT DevOps Tool Sets

NFV is expected to realize the many benefits of cloud

10

Agenda




1

2

3

11

Differences Between NFV Wants and Cloud Provides

Computation vs. Connectivity

Compute-centric cloud platform vs. connect-centric NFV workload

Small App vs. Big App

Cloud enable multiple tenants with many relatively small VMs to share compute, storage,

and connect resources in a cost- and energy-efficient manner while NFV need to scale

network functions to serve millions and even tens of millions of subscribers for one or a few

large operators

Virtual and Physical Separation

Cloud decouple the virtual and physical domains while NFV want orderly handoffs between

definitive segments and service boundaries

12

Problems Observed with NFV Migration

DC/Rack

BOX Software Model

The BOX based application relied on network fabrics that is not provided by the best efforts cloud network

The lack of the connected view of the physical and virtual alarms/events makes EMS impossible to function


Switch Fabric Controller

ATCA

Ap

p 1

LBS

Co

ntro

ller

Ap

p 2

Ap

p 2

Ap

p 4

Ap

p 3


IP/Ethernet Fabric

VM VM VM VM VM

VM

Controller

Physical Server Physical Server

EMS/NMS Consistent app

and physical resource view

No change to the EMS Physical and app, 1:1 mapping

NFV Software Model

Chassis

ATCA

zero loss, low latency control link

Dedicated bandwidth Separation of

the VM and physical infrastructure mgmt

Overlay tunnel, no QoS or BW assurance

DC/Rack

?

?

13

NFV Challenges for OpenStack

Cross-DC Hierarchy Resource Scheduling

Single telecom app instance spread across multiple DCs for resilience/performance

Operator wants to treat DCs as one when deploying such apps

Affinity Scheduling

Telecom apps have multiple, tightly coupled VMs, and heavy Inter-VM traffic

High availability requirements (99.999%)

Policies govern redundancy & performance relationships

• Cross Version Upgrade

Telco apps have large data-plane traffic, often use SR-IOV & H/W accelerators

Redundancy mechanisms adopted to protect against hardware failures

Traditionally upgrades are coordinated with app

14

Cross-DC Hierarchy Resource Scheduling

• Stack DCs into Tree Hierarchy

• Each DC can operate independently but also be managed by a higher level DC

• Tenant requests resources from the “root” DC, which coordinates everything else

• Use only standard OpenStack REST interfaces between DCs

• Child is not aware it is being managed

• Cells Provide Tree-only for Nova, Don’t Work Well with Multiple DCs

• Need to configure firewalls for inter-cell, non HTTP traffic

• Other services in each DC need to be coordinated

• Each DC still needs to function independently

15

NE005

Manually (pre) partition the site into AvailabilityZones and host aggregates

Use same/different hostAggregate/AZ/... policies Deploy VMs into batches of "compatible VMs”

Deploy batches in (right) sequence. Can lead to “unemployable” VMs.

Create batches of VMs with different properties. Specify constraints between VMs

Within a batch & between batches. Capture available bandwidth info & bandwidth

requirements for use as scheduling constraints. Use linear programming to provide optimal

solutions

HOST Aggregate2

HOST Aggregate1

HOST1 HOST2 HOST3 HOST4

` diff host

diff AZ same host aggregate

same host aggregate

？

Affinity Scheduling Enhancement

(Short term) solution

(Long term) solution

NE005

HOST Aggregate1 HOST Aggregate2

16

Service Container Based Resource Allocation Each service container encapsulated all the apps of a BOX The service container will be allocated/scaled as an inseparable resource unit A lightweight Linux container (LXC) based app will further reduce the computing overhead

The Subscriber Flow-based Load Balance Direct Flow to Service Containers, the Containers Are Added to Scale the Entire Systems Capability

DC/Rack

Service Container

Service Container

Service Container

Service Container

Sub aware

LBS

Function wise equivalent of a BOX

EMS/NMS Consistent app and physical resource

view

EMS sees multiple BOXes which is consistent as pre-NFV DC/Rack


vSwitch

VM VM VM VM VM

VM

Controller

Physical Server

Inter VM traffic is essentially “memory copy”

Hypervisor

Service Container Based Resource Allocation DC/Rack

17

Application-Centric Networking Platform App Container on Provisioning and Management

Linux container, server template App configuration management

AWS OpsWork/formation, OpenStack Heat,

App Level HA and Data Protection Application-aware infrastructure DR (data recovery) strategy

App Level Monitoring and SLA

App-driven dynamic resource scheduling

NFV Needs an App-Centric Architecture in Cloud

18

Together, We Can Make a History

• Fear Not, Facing Challenges is the Only Constant in Our Industry

• Telcos Service Providers Define/Understand NFV Real Needs with Decades of

Operational Experience

• Telco Solution Vendors, such as Huawei, Understand Telcos Networking

Stacks with Decades of Engineering Exercise

• OpenStack Provides a Common Platform to Start our Common Journey

• No Vendor Lock-in

• Create/Provide New Values on Top of Cloud Architecture

Copyright©2013 Huawei Technologies Co., Ltd. All Rights Reserved.

The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and operating results, future product

portfolio, new technology, etc. There are a number of factors that could cause actual results and developments to differ materially from those expressed or implied in the predictive

statements. Therefore, such information is provided for reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time

without notice.

20

Challenges on Current Cloud Platforms

Parity issues with existing NFs

Manageability, performance, reliability, integration, and maintainability

Existing operation tools not longer meet the needs

Auto deployment and configuration in cloud platform

Operation monitoring especially networking

Troubleshooting across physical and virtual world

Lack of app-level infrastructure support

Only VM or platform level, if any, but on big app that has dependent modules

Resource provisioning

Resource pooling and scale-out

App-level policy support: dependency, sequencing, HA and SLA

nfv open stack-shuo-yang

Technology