OPNFV: Open Source Carrier Networking Panel

NFV Track: OPNFV Open Source Carrier Networking Panel

What is OPNFV?

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

2023-04-15 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

2023-04-15

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

IaaSPaaS

Physical Access APIs

Physical Resources

Leg

acy

Order

BS

S/O

SS

AP

Is

User

UsageFirewall

Cloud Services

Physical Resources

Service catalog


VNE Network FocusDeep 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

Support for Legacy

Virtual CPEEx: OpenStack

Ex: OpenDaylight


Virtualizing CPE Functions

Subscriber Home

Cable Gateway

Mobile

STB – Linear & DVR

PC

Tablet

OpenDaylight

MSO

APIOpenStack

Neutron

Subscriber VM

Parental controls

Network Address

Translation

BW on Demand

Customer Portal Analytics

provisioning

routing

firewall

VNF

VNF


CableLabs OpenDaylight Development

13

DLUX VTNCoordinator

OpenStackNeutron

SDNIWrapper

DDoSProtection

Network Applications Orchestrations & Services

AAA – AuthN Filter

OpenDaylight APIs (REST)

Base Network Service FunctionsTopologyManager

StatsManager

Switch Manager FRM Host

Tracker

Service Abstraction Layer (SAL)(Plugin Manager, Capability Abstractions, Flow Programming, Inventory, etc.)

OpenStack Service

VTNManager

OVSDBNeutron

MEF Service

Controller Platform

GBP Renderers

OpenFlow1.0 1.3 TTP

OVSDB NETCONF PCMM/COPS SNBI LISP BGP SNMP Etc.

Southbound Interfaces& Protocol Plugins

Etc.

OpenFlow EnabledDevices

OpenvSwitches

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&DNTT DOCOMO, INC.

TSC MemberOpen Platform for NFV

17

https://wiki.opnfv.org/start


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>

Earthquake14:46 Mar.11

12.6-fold

7.9-fold

The

num

ber o

f cal

ls

Friday, Mar.11 Saturday, Mar.12

After the disaster

A week ago

outinoutin

Deploying resources to process such load is practically impossible19


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)Load Generator (Terminals)

VMVM VMVMIMS EPC

VMVMEPC

VMVMEPC

Access

Yokosuka CenterStandard FacilitiesVirtualized Facilities

Load Generator (Terminals)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

VMVMVMVMIMS

VMVMVMVMEPC

VMVMVMVMEPC

VMVMVMVMEPC

AccessSite D

JGN-X

Access

Legacy HW Legacy HW

Server

Server96 Blade Servers

96 Blade Servers

8 OpenFlow Switches

8 OpenFlow Switches

5 OpenFlow Switches5 OpenFlow

Switches

4 OpenFlow Switches

4 OpenFlow Switches

Site ASite 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% acceptedReallocation

Rich Media

（ 2.34M/h ）

5% accepted

25% accepted

25% accepted

Voice<50-fold increase>

Call completion rate5%

Call completion rate25%

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 kmSendai

DOCOMOR&D

Feasibility of resource sharing over geographically dispersed area

Inter-site

Voice:300000Packet:840000

Voice:170000Packet:450000

Congested region

virtualnetworkDistant 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

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.imprimalia3d.com/noticias/2014/09/24/003247/mapas-braille-impresos-3d-invidentes&ei=AP5jVdPNKYLv8gWe7IOIBQ&psig=AFQjCNH803plMn9mYNc4n8bHfSivM1DCjQ&ust=1432702713362663


Virtualization in mobile network 2015

Does not necessarily mean that th

ere is no technical challenge left

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. kmPopulation: 126 milPenetration rate: 112%

deployme

nt

Each EPC node supports few hundred thousands subscribers 25

SGW

PGW

SGW

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.imprimalia3d.com/noticias/2014/09/24/003247/mapas-braille-impresos-3d-invidentes&ei=AP5jVdPNKYLv8gWe7IOIBQ&psig=AFQjCNH803plMn9mYNc4n8bHfSivM1DCjQ&ust=1432702713362663

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.iconshock.com/img_jpg/SUPERVISTA/security/jpg/256/server_icon.jpg&imgrefurl=http://www.iconshock.com/icons/super-vista/security/server-icon.html&usg=__gw74guM0UTJobTrj5KtPQE8sc7w=&h=256&w=256&sz=44&hl=nl&start=14&zoom=1&tbnid=4fhH25u4FR8phM:&tbnh=111&tbnw=111&ei=4WQVUKn-LrDPmAXL0IHwBg&prev=/images?q=server+icon&hl=nl&newwindow=1&sa=N&gbv=2&ie=UTF-8&tbm=isch&itbs=1&ei=8PdjVY6bIIu78gWF-4PQDA&bvm=bv.93990622,d.dGY&psig=AFQjCNEu4bumq3u0pMZ46dlqt4rR6U1JuQ&ust=1432701220951686




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

ComputingHardware

StorageHardware

NetworkHardware

Hardware resources

Virtualisation LayerVirtualised

InfrastructureManager(s)

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

DescriptionVNF 2

HypervisorCloud

Management System

(OpenStack)

OpenDaylight

virtualized telecom nodes

See https://www.opnfv.org/developers/technical-project-governance/tsc-policy29


OPNFV members

A Linux Foundation collaborative projectPlatinum Platinum Strategic End Users Silver Silver (continued) Silver Strategic End Users

Brocade AT&T 6WIND Dialogic CableLabsCisco China Mobile ADVA Dorado Software CenturyLinkDell DOCOMO Alcatel-Lucent ENEA Software KTEMC Telecom Italia Altera H3C OoredooEricsson Vodafone ARM Ixia OrangeHP Array Networks Metaswitch SK TelecomHuawei Brain4Net Midokura SprintIBM Broadcom MirantisIntel Canonical Overture NetworksJuniper Cavium Networks QosmosNEC Ciena SandvineNokia Citrix Sonus NetworksRed 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 DevelopmentProject

………

Requirements Project Testing & Integration Project Documentation Project

OPNFV Platform

Upstream communities

31

http://openvswitch.org/


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

HypervisorOpenStack

X detect

notify 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

https://wiki.opnfv.org/_detail/requirements_projects/fig_1.png?id=promise


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 <[email protected]>


Open SourceCarrier 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 networks1. 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 costby 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 driverMobile backhaul

driverPacket-transport

driverONOS 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 modelsfor OpenFlow

▌Powerful policy frameworks

▌Network redesign

BACKUP

49


NECNFV 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

2023-04-15

http://www.opnfv.org/

http://www.opnfv.org/

https://wiki.opnfv.org/

https://wiki.opnfv.org/

https://www.opnfv.org/arno

Questions?

OPNFV: Open Source Carrier Networking Panel

Documents

Transcript of OPNFV: Open Source Carrier Networking Panel