ONOS-Based VIM Implementation

OPNFV VIM integrates control and management components from upstream projects such as openstack, ONOS, ODL, etc. While huge success has been achieved in OPNFV for integration, automated build and deployment, the performance of VIM for controlling and managing virtual network has received little attention. This presentation is to address the VIM performance related to the network part of the infrastructure. Based on a Telco use case, we define performance metrics for SDN controller, northbound communication channels, and network provisioning. ONOSFW and OpenStack are two components for VIM. Test data is collected and analyzed for performance evaluation and suggestions for future improvements. China Unicom, ON.LAB and Huawei jointly define the use case and methodology, do analysis, and produce results.

1. ONOS-based VIM
implementation
XongYan Tang China Unicom
Patrick Liu Huawei Technologies Inc
Brian O’Connor ON.LAB

2. 2
Overview
Requirement and Use Case
Architecture
ONOS
VTN
SFC
Demo
Next Steps

3. 3
China Unicom New Generation Network
Architecture: CUBE-Net 2.0
Application
Component Application layer
API
Data-oriented Network (DoN)
Cloud
Interconnection
Customer-oriented Network (CoN)
NaaS
……
NaaS
API
Service Collaboration and Orchestration
Application
Component
Application
Component
Basic
NE
Southbound Control
East-West Integration
Northbound Openness
East-West Integration
Internet-oriented
Network (IoN)
IP + Optical network
bearing plane
① Cloud Service Access ① Ubiquitous-Broadband Access ③ Ultra-Broadband Elastic Pipe
Base DC Base DC
Base DC Base DC
Regional DC
Regional DC
MAN aggregation
Mobile backhaul
Edge DC
Fixed
broadband
Ubiquitous

Access

Wireless
broadband
Mobile
broadband
④ Cloud-enabled Network
Service Platform
Virtual
Network
Resource
Management
Network
Control
Cloud
Service

4. 4
CUBE-Net: Cloud and Network Collaboration
E2E Network and Cloud Orchestration (ICT Orchestration)
SDN
Orchestrator
NFV
Orchestrator
Cloud/DC
Orchestrator
Legacy network
Orchestrator
SDN Controller VNFM VIM（NFV&DC） EMS Cloud


VM
Switch/vSwitch
Router/vRouter
Service route




Access
(SDN)
Service route




WAN
(SDN)
IP Core
(SDN)
VM
API API
Application
Component Application layer
Application
Component
Application
Component
Northbound interface for capability opening
Deployment
collaboration

Management collaboration

Service
collaboration

Service chain Service chain
Edge Cloud (NFV) Regional Cloud (NFV & Cloud)
Base Cloud + Third-party Cloud

5. 5
CUBE-Net: On-demand NFV Services based on
Cloud
vCPE, vBNG, vEPC, vCDN
vIMS, Video, vVAS, APP
vBBU, vOLT
VNFM, VIM, EMS
IP
device

Backbone
IP
device

IP
device

Base DC

Optical
transmission
Metro
Regional DC
Compute Network






Storage
CPE
MxU
ONT
RRU
OLT
User-oriented
VNF
Control-oriented
VNF
Application-oriented
VNF
Edge DC
Management cloud
Function cloud
Service cloud
Control cloud
vSwitch, vRouter
ICT Service Orchestrator
OSS, BSS, Big Data
CPE, IPRAN/ME, TSDN
controller
IP + Optical, DCI, DC
controller
1. Flattened: ultra-broadband access, one-hop reach 3. Intensive: service provisioning and orchestration 2. Decoupling: control and management
Optical
transmission
Optical
transmission
Optical
transmission
IP
device

Compute Network






Storage
Compute Network






Storage

6. 6
Our view on NFV VIM
NFV
VIM
Scalability Open
Reliability Automatic

7. 7
ONOS Distributed Architecture
NB Core API
Distributed Core
(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Providers
Protocols
Providers
Protocols
Providers
Protocols
Providers
Apps Apps

8. 8
ONOS Distributed Architecture
NB Core API
Distributed Core
(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Providers
Protocols
Providers
Protocols
Providers
Protocols
Providers
Apps Apps
Distributed Core
(state management, notifications, high-availability & scale-out)
SB Core API
NB Core API
Providers Providers Providers Providers
Protocols Protocols Protocols Protocols

9. 9
Architectural Tenets
•High-availability, scalability and performance
•required to sustain demands of service provider & enterprise networks
•Strong abstractions and simplicity
•required for development of apps and solutions
•Protocol and device behavior independence
•avoid contouring and deformation due to protocol specifics
•Separation of concerns and modularity
•allow tailoring and customization without speciating the code-base

10. 10
ONOS Flow and Intent Throughput
Linear Scale out
Characteristics i
Linear Scale out
Characteristics in
North bound
Source: ONOS white paper on performance
High performance
As demands on the SDN control plane grow, either due to an increase in the size of the network or due
to an increase in the number of network control applications, ONOS can scale by adding additional
instances to the cluster. (linear scale-out characteristics in both the southbound and northbound)

11. 11
ONOS Topology (Switch, Port) Event Latency
50 and 60 ms
1 and 3 ms
5 and 7 ms
3 and 4 ms

12. 12
ONOS based VIM Architecture
OVS (br-int)
Service VM
(FW)
VM
Compute Node
OVS (br-int)
VM VM
Compute Node
OVS (br-int)
VM VM
Compute Node
Neutron
ML2 Plugin L3 Plugin
Nova
OVSDB OF1.3
SFC Manager
Neutron API
SFC Plugin
VTN Manager
Distributed
VTN store
VTN
Overlay Net
Topology
Device
(OVS)
Host (VM)
Link
(VxLAN)
Flow Rule
Tunnel Packet Stats Master
OVS (br-int)
DHCP
Network Node
DHCP
VxLAN VxLAN
Tunnel
Port
Ingress
SF Port
CORE
Provider
Egress
SF Port
Single Bridge br-int in Network and
Compute node
OF based L3 Forwarding (No DVR)
Ex Traffic is forwarded and received
directly by compute node.
ARP proxy on each compute node

Physical and Overlay Network
Flow Rule management
Full Mesh Overlay network with two
variations:
1.create two tunnel-ports per
VxLAN;
2.Create only one tunnel-ports per
OVS, which shared by all of the
VxLANs
VTN is a Application
Distributed VTN Stores
Multiple bundles
Mastership
Port
External
Port

13. 13
Service Function Chaining For ONOS
OVS(Classifier/SFF)
Service VM
(FW)
Service VM
(IDS)
Compute Node
OVS
VM VM
Compute Node
OVS
VM VM
Compute Node
OVS
VM VM
Compute Node
Swift
Neutron
SFC Driver Mgr SFC Driver API
ONOS SFC Driver
Nova
SFC Plugin
OVSDB
South Bound : Use IETF Standard based NSH
header for changing the flow on device
Device, Host, Link, Topology, Intent, Resource, Flow, Packet, …
OF1.3
SFC Manager
Flow Classifier, L4-L7 Support
SFC API
Model: Port-pair, Port-pair-group,
Port-Path; Classifier
Use OpenStack Neutron as the
main driver of SFC.
OVS: classifier; SFF;
NSH header is removed by last SFF

14. 14
Flow Classifier
Destination
N-Tuple
Port-Pair-Group Sequence
Neutron Port Chain API Extension
Source N-
Tuple
Port Pair for
IPS1
Neutron Port
for FW1
Neutron Port
for Video
Optimizer1
Neutron Port
for FW2
Neutron Port
for FW3
Traffic
Destination
Video
Optimizer
FW
IPS
Traffic
Source
Port Pair for
IPS2
Neutron Port
for Video
Optimizer2
Port-Pair-Group1 Port-Pair-Group2 Port-Pair-Group3
Neutron-ONOS SFC Interface
Source: OpenStack Service Chaining Project

15. 15
Demo 1: VTN Management and Scalability
Swift Neutron
Plugins
Nova
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
OVS
Server Server Server
Full Mesh

Container
OVS
VTN Tunnel FlowR
OVSDB OF1.3
Topo

16. 16
Demo 2: High Availability
Swift Neutron
Plugins
Nova
OVS 1
VM VM
OVS 2
VM VM
OVS 3
VM VM

Node 1 Node 2 Node 3
Master
Standby

17. 17
Demo 3: Host Live Migration
OVS OVS
VM2 VM3 VM4 VM1
Swift Neutron
Plugins
Nova

18. Copyright©2015 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.