OPNFV: Open Source Carrier Networking Panel

NFV Track: OPNFV Open
Source Carrier Networking
Panel

OPNFV is a carrier-grade,
integrated, open source
platform to accelerate the
introduction of new NFV
products and services.

OPNFV Membership List
Platinum Members
Silver Members
2015-06-24 OPNFV Introduction 4

OPNFV Open Source Carrier Networking
Panelists
• Heather Kirksey, Director, OPNFV (Moderator)
• Chris Donley: Director, SDN, NFV, Home Networking, IPv6, Metro Ethernet,
CableLabs
• Ashiq Khan: Assistant Manager, NTT DOCOMO
• Dirk Kutscher: Chief Researcher & SDN Architect, NEC Laboratories
Europe
2015-06-24

6© Cable Television Laboratories, Inc. 2015. Do not share this material with anyone other than CableLabs Members, and vendors under CableLabs NDA if applicable.© Cable Television Laboratories, Inc. 2015. Do not share this material with anyone other than CableLabs Members, and vendors under CableLabs NDA if applicable.
Open Source Carrier Networking
Chris Donley
Director, Virtualization and Network Evolution

• R&D Consortium chartered to foster innovation in
the cable industry
– 58 member MSOs worldwide
– 150+ million subscribers
• Vendor-neutral R&D/lab facilities in Louisville, CO and
Sunnyvale, CA
– Best known for DOCSIS® specifications
• Extensive research into SDN & NFV with active participation
from cable operators and vendors
– ETSI NFV ISG – NOC Chair
– OPNFV – Founding member, Silver End-User Director
About CableLabs
7

• Started SDN research in 2012
– ON.Lab
• Pox/mininet/FlowVisor experimentation
– MSO and vendor use case analysis
• SDN is promising, but need to move beyond OpenFlow in access network
• Began NFV research in 2013
• Experimenting with Open Daylight in August ‘13
– PacketCable Multimedia plugin – COPS protocol to control legacy CMTSs
– Documentation was non-existant…
– …code/interfaces kept changing…
– …but we still had a working demo in 6 weeks
• Continuing approach with use case analysis, architecture design, and prototyping
– PCMM plugin (Helium) -> enhancing in Lithium
• Expanding Open Source engagement through OPNFV
– Virtual Business CPE (MEF services)
– Intent networking
CableLabs involvement with SDN & NFV
8

9© Cable Television Laboratories, Inc. 2015. Do not share this material with anyone other than CableLabs Members, and vendors under CableLabs NDA if applicable.© Cable Television Laboratories, Inc. 2014. Do not share this material with anyone other than CableLabs Members, and vendors under CableLabs NDA if applicable.9
VNE Architecture
Portal
Platform Orchestration APIs
Network
Services
Infrastructure Control APIs
Network Compute Storage
VNFs
SaaS
Applications
Custom
Application
Metro
Ethernet*
RTC Backup
IaaS
PaaS
Physical Access APIs
Physical Resources
Legacy
Order
BSS/OSSAPIs
User
Usage
Firewall
Cloud Services
Physical Resources

VNE Network Focus
Deep dive on network
CMTS/CCAP
Orchestrator
Controller
Metro Ethernet ServiceService
CCAP Management &
Abstraction
DOCSIS®
(legacy)
Prov.
EPON
ONU
Access Protocol Adaptation (Virtual Network Abstractions)
Wireless
eRouter
Ex:
OpenStack
Ex:
OpenDaylight

CableLabs VNE – Current Focus
CMTS/CCAP
Orchestrator
Controller
Metro Ethernet ServiceService
CCAP Management &
Abstraction
DOCSIS®
(legacy)
Prov.
EPON
ONU
Access Protocol Adaptation (Virtual Network Abstractions)
Wireless
eRouter
Ex:
OpenStack
Ex:
OpenDaylight

Virtualizing CPE Functions
Subscriber Home
Cable
Gateway
Mobile
STB – Linear & DVR
PC
Tablet
Open
Daylight
MSO
API
Open
Stack
Neutron
Subscriber VM
Parental
controls
Network Address
Translation
BW on
Demand
Customer
Portal Analytics
provisioning
routing
firewall
VNF
VNF

CableLabs OpenDaylight Development
13
DLUX
VTN
Coordinator
OpenStack
Neutron
SDNI
Wrapper
DDoS
Protection
Network Applications
Orchestrations & Services
AAA – AuthN Filter
OpenDaylight APIs (REST)
Base Network Service Functions
Topology
Manager
Stats
Manager
Switch
Manager
FRM
Host
Tracker
Service Abstraction Layer (SAL)
(Plugin Manager, Capability Abstractions, Flow Programming, Inventory, etc.)
OpenStack Service
VTN
Manager
OVSDB
Neutron
MEF
Service
Controller Platform
GBP Renderers
OpenFlow
1.0 1.3 TTP
OVSDB NETCONF
PCMM/
COPS
SNBI LISP BGP SNMP Etc.
Southbound Interfaces
& Protocol Plugins
Etc.
OpenFlow Enabled
Devices
Open
vSwitches
Additional Virtual
& Physical Devices
Data Plane Elements
(Virtual Switches, Physical Device
Interfaces)
Source: http://www.opendaylight.org/project/technical-overview
Helium/Lithium
Proposing OPNFV co-
development project
(currently Java shim on
top of ODL)
Used in our
prototypes

Continuous Integration Environment
• Continuous Integration tool chain speeds development
and facilitates collaboration
– Gerrit – code review tool
– GitHub - code repository
– Jenkins – automated build tool
– Maven – code build
– Ansible – code deployment tool
– Vagrant – deployment to VMs

• Open source speeds up development and provides a new way to
achieve interoperability
• Rapid prototypes are a great way to show SDN/NFV value
• Developer ramp-up time is challenging, but once integrated, we can
make rapid progress
• A common CI environment facilitates sharing between projects
• Cadence, short iteration cycles, fast feedback
Key Takeaways
15

Questions?

© 2015, NTT DOCOMO. INC. All Rights Reserved. ONS 2015
OPNFV Open Source Carrier Networking
Ashiq Khan, PhD
Open Networking Summit 2015
DOCOMO R&D
NTT DOCOMO, INC.
TSC Member
Open Platform for NFV
17

Contents
 Telco virtualization and NFV
 Why open source
 Open Platform for NFV
18

Lesson learned … Mar 2011
source: http://www.soumu.go.jp/menu_news/s-news/01kiban02_02000043.html
Massive number of call attempts (roughly 60-fold increase) were made. Call restriction control were in place.
Call Restriction Call Restriction
15:00, Mar. 11 – 2:00, Mar. 12 6:00, Mar.12 – 1:00, Mar. 13
The number of call attempts were
increased roughly 60-fold in outgoing and
40-fold in incoming.
<Massive Congestion>
Earthquake
14:46 Mar.11
12.6-fold
7.9-fold
Thenumberofcalls
Friday, Mar.11 Saturday, Mar.12
After the
disaster
A week
ago
out
in
out
in
Deploying resources to process such load is practically impossible
19

Enter virtualization
 We need a mean to do resource sharing
Normal At disaster
Mail
Rich
Media
(Video
etc.)
Voice
More on highly demanded
Internet access (Rich media
Contents) than voice calls
More on voice calls etc. to
confirm safety of relatives
and friends
This is a joint research work supported by "Experimental challenges for dynamic virtualized
networking resource control over an evolved mobile core network - a new approach to reduce
massive traffic congestion after a devastating disaster" of the Ministry of Internal Affairs and
Communications, Japan.
20

Nation-wide experiment
 Resource sharing among services
Access
Tohoku University
Load Generator (Terminals)
VM VM
IMS EPC
VM
EPC
VM
EPC
Access
Yokosuka CenterStandard Facilities
Virtualized Facilities
Load Generator (Terminals)
Tohoku
L2/L3 Networks
Access
L2/L3 Networks
IMS
Mail
EPC Video
IMS: IP Multi-media Subsystem, EPC: Evolved Packet Core
Site C
VMVM
IMS
VMVM
EPC
VMVM
EPC
VMVM
EPC
Access
Site D
JGN-X
Access
Legacy HW Legacy HW
Server
Server
96 Blade Servers
96 Blade Servers
8 OpenFlow
Switches
8 OpenFlow
Switches
5 OpenFlow
Switches5 OpenFlow
Switches
4 OpenFlow
Switches
4 OpenFlow
Switches
Site A
Site B
This is a joint research work supported by "Experimental challenges for dynamic virtualized networking resource control
over an evolved mobile core network - a new approach to reduce massive traffic congestion after a devastating
disaster“ and “Research and development of network conversion of communication processing functions in large-scale
communication congestion” of the Ministry of Internal Affairs and Communications, Japan.
21

Result 2012
 Virtualization can enable us to do resource sharing
562.5K
135K
E-mail
（0.54M/h）
135K
585K
135K
112.5K
Normal
（Total Capacity: 832.5K）
Packet
<4-fold increase>
Estimated peak demand during the
disaster
25% accepted
25% accepted
6% accepted
Reallocation
Rich
Media
（2.34M/h）
5% accepted
25% accepted
25% accepted
Voice
<50-fold increase>
Call completion
rate
5%
Call completion
rate
25%
After reallocation
（Total Capacity: 832.5K）
Voice
（2.25M/h）
This is a joint research work supported by "Experimental
challenges for dynamic virtualized networking resource
control over an evolved mobile core network - a new
approach to reduce massive traffic congestion after a
devastating disaster" of the Ministry of Internal Affairs
and Communications, Japan.
22

400 km
Sendai
DOCOMO
R&D
 Feasibility of resource sharing over geographically dispersed area
Inter-site
Voice:
300000
Packet:
840000
Voice:
170000
Packet:
450000
Congested region
virtual
network
Distant site
Before sharing
reallocate
After sharing
Result 2013
Virtualization can give a good amount of resource flexibility to mobile telecom operators
This is a joint research work supported by “Research and
development of network conversion of communication
processing functions in large-scale communication congestion”
of the Ministry of Internal Affairs and Communications, Japan.
23

Virtualization in mobile network 2015
24
https://www.nttdocomo.co.jp/english/info/media_center/pr/2015/0302_00.html

Telco node virtualization
 Its different than everything you see in the clouds now …
MME SGW
PGW
eNB eNB
External networks
Size: 377944 sq. km
Population: 126 mil
Penetration rate: 112%
deployme
nt
Each EPC node supports few hundred thousands subscribers
25
SGW
PGW
SGW

Challenges
 Lack of commercial virtualization-based solution
– gaps exist between standards and what is available
 Don’t have a reference platform
– Can’t compare if an offered platform is good enough
We need a way for fast implementation, start with what is common to everyone.
We have heard that ‘opensource’ is pretty fast ….
26

Standard and Opensource
 Open Platform for NFV started in Oct. 2014
 Use cases and requirements
 Architecture
 High-level specifications
Open Platform for NFV
A Linux Foundation Collaborative Project
 Reference implementation
 Interoperability tests
 Validating specifications
requirements
solutions
27
Network Functions Virtualisation (NFV)
Industry Specification Group (ISG)
What we want and the
interoperability requirements
We quickly know what
is missing, what is right

Contribution of Opensource
 De-facto implementation
– Opensource projects can provide fast solutions becoming de-facto/standards later
 Validity and compliance
– detects issues in standards through implementation, provide common codebase to test
compliance to the standards
 Reduce development burden
– vendors can build on existing code base rather than creating it from scratch
28

Open Platform for NFV (OPNFV)
 Lets make a common platform for NFV using opensource
Computing
Hardware
Storage
Hardware
Network
Hardware
Hardware resources
Virtualisation Layer
Virtualised
Infrastructure
Manager(s)
VNF
Manager(s)
NFV
Orchestrator
OSS/BSS
NFVI
VNF 3VNF 1
Execution reference points Main NFV reference pointsOther reference points
Virtual
Computing
Virtual
Storage
Virtual
Network
EM 2 EM 3EM 1
Or-Vi
Or-Vnfm
Vi-Vnfm
Os-Ma
Ve-Vnfm
Nf-Vi
Vn-Nf
Vl-Ha
Service, VNF and
Infrastructure
Description
VNF 2
Hypervisor
Cloud
Management
System
(OpenStack)
OpenDaylight
virtualized telecom nodes
See https://www.opnfv.org/developers/technical-project-governance/tsc-policy
29

OPNFV members
 A Linux Foundation collaborative project
Platinum Platinum Strategic End Users Silver Silver (continued) Silver Strategic End Users
Brocade AT&T 6WIND Dialogic CableLabs
Cisco China Mobile ADVA Dorado Software CenturyLink
Dell DOCOMO Alcatel-Lucent ENEA Software KT
EMC Telecom Italia Altera H3C Ooredoo
Ericsson Vodafone ARM Ixia Orange
HP Array Networks Metaswitch SK Telecom
Huawei Brain4Net Midokura Sprint
IBM Broadcom Mirantis
Intel Canonical Overture Networks
Juniper Cavium Networks Qosmos
NEC Ciena Sandvine
Nokia Citrix Sonus Networks
Red Hat ClearPath Networks Spirent
ZTE ConteXtream Stratus
Coriant VMWare
Cyan Wind River
Xilinx
as of May 2015
A strong presence of Operators/Service providers. What do they do in an
Opensource community???
30

Project categories in OPNFV
 Target is to reach upstream
OPNFV accommodates a variety of telecom and IT industry players
Collaborative Development
Project
………
Requirements Project
Testing & Integration Project Documentation Project
Upstream communities
31

Filling out gaps case study-1
 DOCTOR: requirement project on fault management
– Don’t hide everything
ACT nodeSBY node
Node manager/VNFM
Hardware
Hypervisor
Hardware
Hypervisor
Hardware
Hypervisor
OpenStack
X detect
 Hardware is not completely
decoupled from software
 telco-nodes have five 9s
availability requirement
 Don’t take unilateral recovery action
 inform the manager first
Three blueprints accepted in the last OpenStack summit on Liberty release
see https://wiki.opnfv.org/doctor
VM VM
32
switch over

Filling out gaps case study-2
 Promise: requirement project on resource reservation
– Reservation feature not available in OpenStack
OpenStack
Promise plug-in
see https://wiki.opnfv.org/promise
6 contributions were made to ETSI NFV. Prototyping underway.
33

Summary
 Telco nodes need ‘some’ attention in virtualization.
 reliability, high availability required, but not from the hardware per-say.
 OPNFV is a fast-growing opensource community driving speedy development of a reference NFV
platform.
 heavy presence of telco players. Seeing success already.
 Speed matters
 That’s a big expectation.
 Follow standards. Standard is necessary in Telecom.
 Interoperability, backward compatibility, vendor-independence, contention resolution.
34
Early engagement with the Operators/Service Providers creates a Win-Win relationship

Ashiq Khan <khan@nttdocomo.com>

Open Source
Carrier Networking
Dirk Kutscher
Chief Researcher
NEC Laboratories Europe

© NEC Corporation 2015
Open Source Carrier Networking
▌Different objectives for Open Source projects
1. Disseminate and test new ideas  Research collaboration
2. Validate and demonstrate technology and standards  PoCs
3. Open Source industry platforms  large-scale projects

NEC – Communications and IT Solutions
▌Cloud Infrastructure
▌Telecom networks and services
▌Leading OpenFlow products
▌World‘s first commercial LTE deployment
▌World‘s first commercial vEPC deployment
▌Linux- (and generally OSS)-based product range

NEC NFV Solutions History
Linux-based ATCA systems
First-generation of virtualized
systems with proprietary resource
manager
OpenStack-based VIM and
orchestration systems
OPNFV-based solutions

Requirements from a Telecommunications Perspective
▌General objectives for NFV-based networks
1. Automation (deployment, life-cycle management, elasticity)
2. Flexbility – adding/removing new features fast
3. Cost efficiency (consolidation of functions onto fewer physical boxes)
Specific Requirements
▌ Availability and Fault Management
 Faults can happen
 Detecting root-causes reliably and react quickly
 Minimizing downtime
▌ Performance
 Balance virtualization with optimal resource usage
▌ Multi-domain operation
 Extending NFV domains across DC boundaries

Previous Development Cycle
Customer Requirements Development Product Release

Open Source, Open Loop
Requirements & Blueprints Artifacts Release
Testing

Experience: Development
▌Modularity in OSS projects
 Designed for multi-partner collaboration and extensibility
 Component-based architectures, well-defined APIs
 Large active communities  dynamic system
▌Example: NEC NFV OpenStack development
 NEC extension modules for NFV use cases and requirements
 Development (including research and QA) completed in 8 months
▌Lesson: Flexibility, modular design a key enabler for fast
customization and extension

Experience: Troubleshooting NFV
▌NEC telco support business
 Strong (legal) requirements for high availability
 Root cause analysis for effective fault management
 NFV: high degree of consolidation makes this difficult
▌Example: service outage in customer network
 Network service application failure
 Reproduced problem locally and identified bug by adding diagnostics into
 KVM/qemu
▌Lesson: White box (OSS) approach enables effective debugging and
hardening of critical systems

Experience: Paddling Upstream
▌From adaptation to upstream integration
 First generation of OSS-based products were based on many specific
features, proprietary extensions
 Doable for single development – not maintainable in the long run
▌Upstream first instead of forking and expensive re-integration
 NEC develops use cases, requirements and feature designs
 Close collaboration with partners to integrate features in a timely manner
 We (and rest of the industry) can leverage those features in products
▌Lesson: Minimize development and maintenance cost
by upstream first approach

Current Work: Transport-SDN with ONOS
Flexible and easy-to-use multi-layer/multi-domain/multi-device view/control of
transport network which consists of legacy and pure-SDN domains
Packet-transport
domain
Optical network
domain
Mobile backhaul
domain
OpenFlow
domain
OpenFlow
domain
OpenFlow
domain
ODENOS (Network abstraction)
ONOS
ONOS ONOS
NMS
NMS
NMS
OpenFlow
domain
ONOS
Leveraging high
performance and
scalability
Global/Local view
& control
Customer-domain
view & control
Protocol layer
view & control
Optical driver
Mobile backhaul
driver
Packet-transport
driver
ONOS driver
Inter-domain path
restoration

Outlook: OpenFlow in Carrier Networks
▌After first wave of NFV-based softwarization, we see more demand
for true Software-Defined Networking
 Commoditizing forwarding elements further
 Enhanced programmability and proper policy abstractions
▌New abstractions and
programmability models
for OpenFlow
▌Powerful policy
frameworks
▌Network redesign

NEC
NFV Platform

Get Involved With OPNFV
• Website: http://www.opnfv.org/
• Wiki: https://wiki.opnfv.org/
• Arno: https://www.opnfv.org/arno
• Join the conversation on mailing lists and social media
• Join as a member
• Developers: Download Arno, join approved projects, propose a project, write
documentation, contribute use cases, define tests, analyze requirements,
build upstream relationships, contribute code, contribute upstream code,
define processes, resource a community lab, answer questions, give
training, evangelize
2015-06-24

OPNFV: Open Source Carrier Networking Panel

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to OPNFV: Open Source Carrier Networking Panel (20)

More from OPNFV (20)

OPNFV: Open Source Carrier Networking Panel