sdn and nfv - skkumonet.skku.edu/wp-content/uploads/2016/09/sdn_nfv.pdf · 2017-12-05 ·...

Networking Laboratory 1/82

Sungkyunkwan University

Copyright 2000-2017 Networking Laboratory

SDN and NFV

Prepared by S. M. Raza, P. Thorat, R. Challa, and H. Choo


Presentation Outline (1/2)

Software Defined Networking (SDN)

► Past, Present and Future

► SDN Concept and Architecture

► SDN Case Studies

► SDN Controllers

► OpenFlow

► Mininet

► SDN Testbeds

► Network Virtualization with SDN (OVX)

► SDN in Different Networks

► SDN Use-cases

► Research Areas in SDN

► Ongoing Projects


Presentation Outline (2/2)

Network Function Virtualization (NFV)

► Introduction

► Practical Examples

► NFV Architectural Framework

► RouteFlow (RF)

► RouteFlow Architecture

► Benefits of SDN and NFV Combined

► References Web links

► Standardization Activities


Video: SDN Functioning and Benefits

Contents

► Definition of a Software Defined Network (SDN)

► The control and data components in a SDN and how they work with one

another

► Connections establishment in a scalable enterprise architecture

► The features and benefits of SDN

Duration

► 5 minutes and 21 seconds


Past, Present and Future

Past

► Combined control and data plan

► Limited performance and capability

► Restricted pace of innovation

Present

► Decoupled control and data plans

► High throughput and scalability

► Pace of innovation limited to pace of

network element innovation

► Restricted by hardware innovation

Future

► Separate network and control element

► Powerful computers accelerate control plan

innovation

► Very simple data plan


Future: Software Defined Networking


SDN Concept

SDN concept

► Separates the data plane from

the control plane

► SDN controller in the controller

layer controls the data plane

► Different applications run on

top of the SDN controller

Whitepaper by ONF, “SDN Architecture-A Primer”


SDN Architecture

Wikipedia: Software-defined networking


Case Study: Google B4 (1/3)General Description

In 2013 Google deploy OpenFlow based SDN WAN, called ‘B4’

It is among the •first and largest SDN/OpenFlow deployments (G-

scale)

B4 is utilized for inter-datacenter communication

B4 deployment took three years, and now carries more traffic

than Google’s public facing WAN

B4 has both standard routing protocols and centralized traffic

engineering SDN application

S. Jain, A. Kumar, S. Mandal, J. Ong, et al. “B4: Experience with a Globally-Deployed Software Defined WAN,” ACM SIGCOMM, August 2013


Case Study: Google B4 (2/3)Operational Mode

Thousands of individual applications running across B4 target

network


Case Study: Google B4 (3/3)Deployed Equipment

Built from the merchant silicon

► 100s of port with non blocking 10 GE

support

► Custom hardware running Linux

OpenFlow support

Open source routing stacks

► Quagga BGP1 stack

► IS-IS2/BGP for internal connectivity

Features

► Fault tolerant

► Scale to multiple Tbps

► Support programming for traffic

engineering

1. Boarder Gateway Protocol (BGP)

2. Intermediate System to Intermediate System (IS-IS)


Case Study: NTT SD-WAN (1/2)General Description

In June 2017, NTT communications corporation launches its SD-

WAN service portfolio

NTT SD-WAN is based on a architecture that is distributed

around the world via 75+ local cloud centers (LCCs)

SD-WAN is optimized for network, mobility and security services

Software defined network provides NTT Com with

unprecedented flexibility and speed to launch new services

http://www.ntt.com/en/about-us/press-releases/news/article/2017/0620.html


Case Study: NTT SD-WAN (2/2)Operations

SD-WAN routers create

an overlay network across

available underlay

network to provide optimal

mix of bandwidth and cost

Underlay networks can be

chosen from private

MPLS or VPLS, Public

Internet, or 4G mobile

SD-WAN overlay network

supports Quality of

Service for multiple traffic

typesNTT SD-WAN Platform


SDN Controllers (1/4) OpenDaylight (ODL)

OpenDaylight was founded in April 2013

OpenDaylight is a collaborative project at The Linux Foundation

OpenDaylight is an open platform for network programmability to

enable SDN

OpenDaylight is a combination of components including a

pluggable controller, interfaces, plugins and applications

With this common platform both customers and vendors can

innovate and collaborate in order to commercialize SDN- and

NFV-based solutions

https://www.opendaylight.org


SDN Controllers (2/4) Open Network Operating System (ONOS)

ONOS was first launched in December 2014

ONOS is an open source project under The Linux Foundation,

lead by ON.LAB and industry partners like AT&T

ONOS is the first open source SDN network operating system

targeted specifically at the Service Provider Networks

The major goals of ONOS are:

► Carrier grade features (scalability, availability, and performance) in the

control plane

► Web style agility

► Migration of existing networks to white boxes

► Innovation in both network hardware and software, independent of their own

time scales

https://onosproject.org/


SDN Controllers (3/4) RYU

Ryu was launched back in 2012

Ryu is developed and lead by NTT Software Innovation Center

Ryu means "flow" in Japanese

Ryu is a component-based software defined networking

framework

Ryu supports various protocols for managing network devices,

such as OpenFlow, Netconf, OF-config, etc.

Ryu fully supports OpenFlow 1.0, 1.2, 1.3, 1.4, 1.5 and Nicira

Extensions

Ryu uses Python for development

https://osrg.github.io/ryu/


SDN Controllers (4/4) Floodlight

Floodlight was launched in 2012

Floodlight is developed and lead by Big Switch Networks

The Floodlight is an open enterprise-class, Java-based

OpenFlow Controller

Floodlight offers a module loading system that make it simple to

extend and enhance

Floodlight can handle mixed OpenFlow and non-OpenFlow

networks – it can manage multiple “islands” of OpenFlow

hardware switches

Floodlight is designed to be high-performance – is multithreaded

from the ground uphttp://www.projectfloodlight.org/floodlight/


OpenFlow (1/4)

OpenFlow is an open API that provides a standard interface for

programming the data plane switches

Provides open interface to “black box” networking node (i.e.

Routers, L2/L3 switch) to enable visibility and openness in

network

OpenFlow Specification v1.5OpenFlow Switch


OpenFlow (2/4)Flow Table and Flow Entries (1/3)

An entry in the Flow-Table has three fields:

► Rule: Defines the flow, and rule consists of mainly field in the packet

header

► Action: Defines how the packets should be processed

► Statistics: Count the number of packets and bytes for each flow, and the

time since the last packet matched the flow

OpenFlow Specification v1.5 Elements of Flow Table



Flow table pipeline in OpenFlow switch, where packets are matched against multiple tables in the pipeline

Per-table packet processing

Find highest-priority matching flow entry

Apply instructions:

I. Modify packet and update match fields

(apply actions instruction)

II. Update action set (clear actions and/or write

actions instructions)

III. Update metadata

Send match data and action set to next table

1

2

3


How OpenFlow works

Upon arrival on the OpenFlow switch, the packet will be matched

against a Flow Entry in the Flow Table

Action (specified in the action field) is executed if the header field

is matched, and the counter is updated

If the packet doesn’t match any flow entry, it is sent to the

controller

Functioning of OpenFlow


Introduction to Mininet (1/3)

Mininet was first presented in 2010

A virtual network environment that can run on a single PC

► Mininet uses lightweight virtualization to make a single system look like a

complete network

► Runs real kernel, switch, and application code on a single machine

► Internally uses Linux containers to emulate hosts, switches, and links

Command-line, UI, Python interfaces

Many OpenFlow features are built-in

B. Lantz, B, Heller, and N. McKeown, “A Network in a Laptop: Rapid Prototyping for Software-Defined Networks,” ACM Workshop on Hot Topics in

Networks, October 2010.



Platform Advantages Disadvantages

Hardware Testbed

realityaccurate: "ground truth"

expensiveshared resourcehard to reconfigurehard to change

Simulator inexpensive, flexibledetailed (or abstract!)virtual time (can be "faster" than reality)

may require app changesmight not run OS codemay not be "believable"may be slow/non-interactive

Emulator inexpensive, flexiblereal codereasonably accuratefast/interactive usage

slower than hardwareexperiments may not fitpossible inaccuracy



Why Use Mininet

► Fast

► Possible to create custom topologies

► Can run real programs (anything that can run on Linux can run on a Mininet

host)

► Programmable OpenFlow switches

► Easy to use

► Open source

Alternatives to Mininet and their limitations

► Real system: Pain to configure

► Networked VMs: Scalability

► Simulator: No path to hardware deployment


SDN Testbeds (1/3)GENI

GENI is an open infrastructure for at-scale networking and

distributed systems research and education that spans the US

M. Berman, J. S. Chase, L. Landweber, A. Nakao, M. Ott, D. Raychaudhuri, R. Ricci, I. Seskar, “GENI: A federated testbed for innovative network

experiments”, Journal of Computer Networks, 2014


SDN Testbeds (2/3)OFELIA

OFELIA – Pan-European OpenFlow Testbed

• Berlin, Germany (TUB)

• Ghent, Belgium (IBBT)

• Zurich, Switzerland (ETH)

• Barcelona, Spain (i2CAT)

• Bristol, UK (UNIVBRIS)

• Catania, Italy (CNIT)

• Rome, Italy (CNIT)

• Trento, Italy (CREATE-NET)

• Pisa, Italy (CNIT, 2 locations)

• Uberlândia, Brazil (UFU)

• Castelldefels, Spain (CTTC)

M. Suñé, L. Bergesio, H. Woesner, T. Rothe, A. Köpsel, et al., “Design and implementation of the OFELIA FP7 facility: The European OpenFlow

testbed”, Journal of Computer Networks, 2014


SDN Testbeds (3/3)KOREN

A multi purpose Korean

backbone network,

connecting 8 metropolitan

areas (Seoul, Suwon,

Daejeon, Gwangju,

Daegu, Busan, Gangwon,

Jeju) from 10Gbps to

160Gbps

Korea Advance Research Network,

http://www.koren.kr/koren/eng/net/natworkmap.html?cate=3&menu=1

http://www.koren.kr/koren/eng/net/natworkmap.html?cate=3&menu=1


Network Virtualization with SDN (1/4)

Network Virtualization

► The goal of network virtualization is to improve speed, automation and

network management by adding new software elements

► It divides a network into multiple segments or create software-only networks

between virtual machines (VMs)

► It's clear that network virtualization and SDN technologies share common

elements

► Whether network virtualization is a subset of SDN or SDN is a subset of

network virtualization, the two have overlapping sets of technologies with

similar goals


Network Virtualization with SDN (2/4)

Virtualization Platform

Physical Network

Virtual Networks


Network Virtualization with SDN (3/4)OpenVirteX (OVX) (1/2)

Network virtualization allows multiple tenants to occupy the same

network infrastructure

Each tenant has an illusion that they have a full network

OVX achieves this by giving each tenant access to a virtualized

network topology

OVX sits between the network and the tenant’s controller

OVX rewrites OpenFlow messages to translate between what a

tenant’s controller sends and receives from its virtual network

A. Al-Shabibi, M. D. Leenheer, A. Koshibe, G. Parulkar, B. Snow, M. Gerola and E. Salvadori, “OpenVirteX: Make Your Virtual SDNs Programmable”,

ACM Hot topics in software defined networking, August 2014.


Network Virtualization with SDN (4/4)OpenVirteX (OVX) (2/2)

Mapping between

them and the

physical and

virtual network

Virtual topologies

Physical switches


► Abstracts all radio resources

of a geographical area (cell)

► Suggests moving base

station closer to mobile client

SDN in Cellular Networks (1/4)

A. Gudipati, D. Perry, L. E. Li and S. Katti, “SoftRAN: software defined radio access network,” ACM SIGCOMM workshop on Hot topics in software

defined networking, August 2013.

SoftRAN – Improved RAN (Radio Access Network) Design

SoftRAN Architecture

► Improved radio resource management while maintaining connectivity for

the users



CellSDN is an effort to improve the cellular network using SDN

► Current cellular networks consist of Base Stations (BS)

► BS connects to mobility manager and Serving Gateway (S-GW)

L. E. Li, Z. M. Mao, and J. Rexford, “Toward Software-Defined Cellular Networks,” European Workshop on Software Defined Networking, October 2012

CellSDN Architecture



Legends:

MME:

Mobility Management Entity

GW-C:

Gateway Control Part

SGW:

Serving gateway

PGW:

Packet data network Gateway

VPN:

Virtual Private Network

MPLS:

Multiprotocol Label Switching

K. Pentikousis, Y. Wang and W. Hu, “Mobileflow: Toward software-defined mobile networks", IEEE Communication Magazine, July 2013.



Future Trends - SDN in Cellular Networks, SDN in 5G

► SDN based control plane in 5G

► Handling of Increased Mobile traffic volume using SDN paradigm

► 3GPP CUPS - Enabling Software Defined Networking to deliver user

plane data more efficiently

► QoE Management Framework for Internet Services in mobile networks

► SDN driven load balancing in 5G networks

► Low latency MEC framework for SDN-based mobile networks

► SDN assisted data offloading for 5G networks

3GPP CUPS - TS 29.244 Interface between the Control Plane and the User Plane of EPC Nodes


OpenFlow Wireless envisage a future where end user is free

from worrying about which wireless network is serving him/her

OpenFlow in Wireless Networks (1/2)

K. K. Yap, M. Kobayashi, R. Sherwood, T.Y. Huang, M. Chan, N. Handigol and N. McKeown, “OpenRoads: Empowering Research in Mobile Networks,”

ACM Sigcomm Computer Communication Review, January 2010.

OpenRoads’ Architecture


OpenFlow in Wireless Networks (2/2)

Aeroflux improvised Odin by proposing a two tier control plane

► Near-Sight Controller (NSC): Frequent events (latency critical tasks)

► Global Controller (GC) – Network monitoring or load balancing

► Radio Agent exposes all functionalities

Light Virtual AP (LVAP) abstraction

Handling WiFi data path entries

Provide interface for statistic collection

J. Schulz-Zander, N. Sarrar, S. Schmid, “AeroFlux: A Near-Sighted Controller

Architecture for Software-Defined Wireless Networks,” Open Networking

Summit, March 2014


Mesh Networks

► Feasibility study of OpenFlow in Wireless Mesh Network

► Primary challenge is frequently changing topology

► All nodes are OpenFlow enabled mesh routers. Each wireless interface is

used for both control and data traffic

SDN in Multi-hop Wireless Networks (1/2)

P. Dely, A. Kassler, and N. Bayer, “OpenFlow for Wireless Mesh Networks,” International Conference on Computer Communications and Networks

(ICCCN), August 2011


A Multi-channel time-scheduled protocol for real-time data

Collection (MCC) in WSNs

► Centralized channel allocation and time scheduling to address co-channel

interference

SDN in Multi-hop Wireless Networks (2/2)

Y. Chen, P. H. Gomes and B. Krishnamachari, “Multi-channel Data Collection for Throughput Maximization in Wireless Sensor Networks,” IEEE

International Conference on Mobile Ad Hoc and Sensor Systems (MASS), October 2014

► Centralized network topology

information to configure the

transmission and routing

decisions for all nodes


SDN can be used effectively for traffic engineering

Load balancing is a classical application of SDN traffic

engineering

SDN Use-cases (1/5)Traffic Engineering in SDN Based Wireless Networks

S. Agarwal, M. Kodialam, and T. Lakshmana, “Traffic engineering in software defined networks,” IEEE Infocom, April 2013.


SDN Use-cases (2/5)Autonomic Computing (1/4)

The function of any autonomic capability is a control loop that

collects details from the system and acts accordingly

Autonomic systems is a self-managing autonomous environment

that completely hides its complexity and provides the user with

an interface that exactly meets his needs

Four aspects of self-management often cited by IBM are,

► Self-Configuring: The ability to readjust itself “on-the fly”

► Self-Protecting: Anticipate, detect, identify, and protect itself from attacks

► Self-Optimizing: Maximize resource utilization to meet end-user needs

► Self-Healing: Discover, diagnose, and react to disruptions

IBM, “White Paper: An Architectural Blueprint for Autonomic Computing,” [Online At]

https://www-03.ibm.com/autonomic/pdfs/AC%20Blueprint%20White%20Paper%20V7.pdf


SDN Use-cases (3/5)Autonomic Computing (Self-healing) (2/4)

It is described as a combination of self-diagnosing and self-

repairing system from malfunctions

Research on self-healing systems has its origin in fault-tolerant

and self-stabilizing systems research

Fault-tolerant systems handle transient and mask permanent

failures in order to return to a valid state

These systems have two distinct properties.

► The system is guaranteed to return to a legal state in a finite amount of time

regardless of interferences

► Once in legal state it tries to remain in the same



H. Psaier and S. Dustdar, “A survey on self-healing systems: approaches and systems,” In the Journal of Computing. Vol. 91, No. 1, January 2011



Self-healing system for SDN which is capable of optimally

handling the failures in SDN

SDN Controller (NOX)

Rapid

Recovery

Module

Flow

Management

Action

Management

Resource

Management

Co

ntr

ol P

lan

e

Da

ta

Pla

ne

Optimized

Self-healing

Management

Topology

Discovery &

Management

Policy

Management

Load

Balancing

Routing

Management

Netw

ork

Ma

nag

em

en

t

Ap

plic

atio

n

Sw

itch

Lev

el

Mg

mt.

Network

Statistics

Management

Forwarding

Information

Base

OpenFlow

Notification

Module


In Nutshell: Research Areas in SDN (1/4)

Controller and switch design

► SDN has significant scalability, performance, robustness, and security

challenges.

Scalability and performance in SDN

► Decentralized, like the Internet, call for a control plane that is logically

distributed (in order to boost Scalability).

Controller-service interfacing (North Bound Interfaces)

► Various controllers exist but their application interfaces are still in the early

stages and independent from each other. (Frenetic, Procera, Nettle, …).


In Nutshell: Research Areas in SDN (2/4)

Virtualization and Cloud service applications

► High demand for virtualization and cloud services. The challenges include

rapid provisioning and efficient resource management.

Huawei Cloud Platform: http://forum.huawei.com/enterprise/thread-196541-1-1.html


Video: Benefits of SDN-based Cloud

Content

► Why SDN and Cloud

► Features and benefits of SDN-based Cloud

► How it works

Duration



In NutShell: Research Areas in SDN (3/4)

Information Centric Networking (ICN)

► Internet is information-driven, yet networking technology is still focused on

the idea of location-based addressing and host-to-host communication

► Shift from “named hosts” based architecture to “named data”

https://arxiv.org/ftp/arxiv/papers/1301/1301.5933.pdf

CONET Architecture


In NutShell: Research Areas in SDN (4/4)

Enabling heterogeneous networking with SDN

► A major challenge is efficient utilization of resources (Capacity, Radio)

► The heterogeneous characteristics of the underlying networks and nodes

must be considered for routing and resource allocation

► SDN techniques largely target infrastructure–based networks, which

requires centralized control mechanism


SDN Current Projects

Central Office Re-architected as a Datacenter (CORD)

► Lead by ON.LAB under Open Networking Foundation and Linux Foundation

► Combines NFV, SDN, and the elasticity of commodity clouds to bring

datacenter economics and cloud agility to the Telco Central Office. CORD

lets the operator manage their Central Offices using declarative modeling

languages for agile, real-time configuration of new customer services

Open Networking Automation Platform (ONAP)

► Lead by AT&T with 33 other operators worldwide

► An widely anticipated open source project/platform for orchestration and

automation of telecom networks, that inherently integrates a diverse set of

standards, open source projects, and reference architectures

https://opencord.org/

https://www.onap.org/


Network Function Virtualization (NFV) (1/5)

Network Functions Virtualization (NFV) is an initiative to

virtualize network functions, previously carried out by dedicated

hardware

Decreases the amount of proprietary hardware that's needed to

launch and operate network services

Allows the network services like Firewall, Load balancer, TCP

Proxy, Deep packet inspection, Intrusion detection system etc…

to be hosted on virtual machines

Reduces the CAPEX (Capital Expense) and OPEX (Operating

Expense)



▪ Reduced Power

▪ Lower CapEx and OpEx

▪ Reduced Time To Market

▪ Open Market to SW Suppliers

▪ Flexible

▪ Standard Hardware


Network Function Virtualization (NFV) (4/5)Practical Example (1/2)

Traditional CPE implementations Possible CPE implementation with NFV

R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. D. Truck, R. Boutaba, “Network Function Virtualization: State-of-the-Art and Research Challenges,”

IEEE Communications Survey & Tutorials. Vol. 18, issue. 1, September 2015


Network Function Virtualization (NFV) (5/5)Practical Example (2/2)

Source: Vmware presentation in OVNC 2015.

USDA

Another practical example of NFV and SDN

Industry is moving towards Software Defined Data Center

(SDDC)


Video: Values of SDDC Transformation

Contents

► Why SDDC?

► Features and Benefits of SDDC

► How to transform to SDDC?

Duration



NFV Architectural Framework (1/3)

NFV Management and Orchestration (MANO)

Legends:

EMS:

Element Management System

VNF:

Virtual Network Function

NFV:

Network Function Virtualization

OSS:

Operations Support System

BSS:

Business Support System

European Telecommunications Standards Institute (ETSI), “Network Functions Virtualization (NFV); Management and Orchestration,” ETSI GS NFV-

MAN 001 V1.1.1 (2014-12)



VNF Manager

► Manages a VNF or multiple VNFs

► Life cycle management of VNF instances

► Can do the same functions as EMS but through open interface/reference

point (Ve-Vnfm)

VIM (Virtualized Infrastructure Manager)

► The management system for Network Function Virtualization Infrastructure

(NFVI)

► Responsible for controlling and managing the NFVI compute, network and

storage resources within one operator’s infrastructure domain

► Responsible for collection of performance measurements and events



NFV Orchestrator

► Generates, maintains and tears down network services of VNF themselves

► If there are multiple VNFs, orchestrator will enable creation of end to end

service over multiple VNFs

► Responsible for global resource management of NFVI resources. For

example managing the NFVI resources i.e. compute, storage and

networking resources among multiple VIMs in network

► Performs its functions by NOT talking directly to VNFs but through VNFM

and VIM


RouteFlow (RF) (1/8)

Provides virtualized IP routing service over OpenFlow enabled

hardware:

► OpenFlow hardware needs Flow tables to make forwarding decisions

► Linux based routing engines populate the Forwarding Information Base

(FIB), used for destination lookup

► Provided mechanism to convert the FIB entries to OF Flow table entries

► https://www.youtube.com/watch?v=YduxuBTyjEw

M. R. Nascimento,C. E. Rothenberg, M. R. Salvador, C. N. A. Corrêa, S. C. de Lucena, and M. F. Magalhães, “Virtual Routers as a Service: The

RouteFlow Approach Leveraging Software-Defined Networks,” International Conference on Future Internet Technologies, June 2011

https://www.youtube.com/watch?v=YduxuBTyjEw



Virtual network environment:

► Each VM maps to one OF HW

► Server virtualization technique used to create Virtual Machine (VM) to

reproduce the connectivity of a physical infrastructure

► Each VM runs one instance of IP routing engine (e.g. Linux-based

Quagga)

► All state information (e.g. routing tables) are exchanged in the virtual

network by the routing engines

► Linux Containers (LXC) used as the virtualization mechanism as it is a

lightweight mechanism.




Video: Route Flow Operation (4/8)

Contents

► Introduction of Route Flow

► Introduction of different components in Route Flow

► Working of Route Flow

Duration



RouteFlow (RF) (5/8)Architecture(1/4)

Key Features:

► Separation of data and control planes

► Loosely coupled architecture

► Three RouteFlow (RF) Components

Controller, Server and Slaves

► Unmodified routing protocol stacks

► Portable to multiple controllers

RF-Controller acts as “Proxy” app

► Multi-virtualization technologies

► Multi-vendor data plane hardware


RouteFlow (RF) (6/8) Architecture (2/4)

RF Server:

► The “brain” of RF

► Manages available Virtual Machine (VM)

► Configures the virtual environment

► Receives events from RF-Controller

► Associates VMs and OF switches

► Determines packet delivery from/to VMs

► Requests flow installation / modification

in OF switches


RouteFlow (RF) (7/8)Architecture (3/4)

RF-Controller:

► App on NOX controller

► Sends packets and events it receives

from OF- Switch and OF HW to RF

Server

► Sends packets it receives from RF

Server to OF-Switch (control packets) or

OF HW (to deal with flow additions /

deletions)

► Provides and interface to the rest of the

framework to the OF HW


RouteFlow (RF) (8/8)Architecture (4/4)

RF-Slave:

► Runs as a daemon in Linux-based VM

► Registers the VM with RF-Server

► Configures the VM (e.g. interfaces)

► Listens to ARP and IP table updates via

Linux Netlink events

► Translates routing updates into flow

rules

► Translates ARP entries into flow rules

► Sends flow update commands to RF-

Server

► Agnostic to the Routing Engine


Video: SDN and NFV Better Combined

Contents

► Why and how to combine SDN and NFV

► Features and benefits of SDN and NFV

► How it works

Duration



SDN and NFV (1/2)

Issue NFV (Telecom Networks) Software Defined Networking

Approach Service/Function Abstraction

Network Abstraction

Formalization ETSI ONF

Advantage Promises to bring flexibilityand cost reduction

Promises to bring unified programmable control and open interfaces

Protocol Multiple control protocols (e.g. SNMP, NETCONF)

OpenFlow is de-facto standard

Applications run Commodity servers and switches

Commodity servers for control plane and possibility for specialized hardware for data plane

Leaders Mainly Telecom services providers

Mainly networking software and hardware vendors

Business Initiator

Telecom service providers Born on the campus, matured in the date centre


SDN and NFV (2/2)

Research Areas / Challenges:

► Two major aspects of SDN needs improvement to meet the requirements

of NFV: Southbound APIs (mainly OpenFlow), and controller designs

► OpenFlow supports only L2-L4 flow handling. L5-L7 are required to support

by NFV

► Improve SDN by considering distributed architectures


Some Useful References ONF – [https://www.opennetworking.org]

OMG – [http://sdn.omg.org]

ITU-T – [http://itu.int/en/ITU-T/Pages/default.aspx]

TTA – [http://www.tta.or.kr/English/index.jsp]

IEEE – [http://sdn.ieee.org/standardization]

BBF – [https://www.broadband-forum.org]

MEF – [https://www.mef.net/ ]

ODCA – [http://www.opendatacenteralliance.org]

OIF – [http://www.oiforum.com]

3GPP – [http://www.3gpp.org]

ODL – [http://www.opendaylight.org]

ONOS – [http://onosproject.org]

Floodlight – [http://www.projectfloodlight.org/floodlight]

OpenStack – [http://www.openstack.org]

https://www.opennetworking.org/

http://sdn.omg.org/

http://itu.int/en/ITU-T/Pages/default.aspx

http://www.tta.or.kr/English/index.jsp

http://sdn.ieee.org/standardization

https://www.broadband-forum.org/

https://www.mef.net/

http://www.opendatacenteralliance.org/

http://www.oiforum.com/

http://www.3gpp.org/

http://www.opendaylight.org/

http://www.3gpp.org/

http://www.projectfloodlight.org/floodlight/

http://www.openstack.org/


Standardization Activities (1/4)

ONF

► A user-driven organization for SDN standardization. ONF working groups

analyze SDN requirements, evolve the OpenFlow Standard and research

new SDN standards

OMG

► SDN Working Group for vendor neutral Global Standard

TTA

► A non-profit organization provides certification services to establish new

standards for the ICT industry in Korea

ONF: Open Network Foundation

OMG: Object Management Group

TTA: Telecommunication Technology Association



ITU-T Study Groups (SG) work

► SG11- develops signaling requirements and protocols for SDN

► SG13- develops the SDN framework, as baseline of all ITU-T SDN

standardization

► SG15- lays recommendations for "Architecture for SDN control of

Transport Networks"

► SG16- governs the OpenFlow based Virtual Content Delivery Networks

► SG17- security aspects of SDN

ITU-T: International Telecommunication Union - Telecom Standard Sector



MEF

► This forum focuses on defining service orchestration with APIs for existing

networks

ODCA

► An organization working on unifying data center in the migration to cloud

computing environments through interoperable solutions

OIF

► Goal is to describe the features / functionalities needed to support the

deployment of SDN capabilities in carrier transport networks

MEF: The Metro Ethernet Forum

ODCA: Open Data Center Alliance

OIF: Optical Internetworking Forum



3GPP

► The mobile networking industry 3GPP consortium is studying the

management of virtualized networks, an effort aligned with the ETSI NFV

architecture to leverage SDN

IEEE (P802.1CF project)

► SDN standardization project to drive the functionality and interoperability

of SDN

BBF

► Objective is to release recommendations for supporting SDN in multi-

service broadband networks

3GPP: 3rd Generation Partnership Project

IEEE: Institute of Electrical and Electronics Engineers

BBF: Broadband Forum

sdn and nfv - skkumonet.skku.edu/wp-content/uploads/2016/09/sdn_nfv.pdf · 2017-12-05 ·...

Documents