postech 1/35 csed702y: software defined networking james won-ki hong department of computer science...

POSTECH 1/35CSED702Y: Software Defined Networking

Software Defined Networking:SDN Applications & Research Challenges

James Won-Ki Hong

Department of Computer Science and Engineering

POSTECH, Korea

[email protected]


Outline OpenFlow Use Cases

VLAN, MPLS

Wireless and Mobile SDN SDN in 5G Network Other SDNs

LISP

SDN Standardization Research Challenges


OpenFlow applications & use cases SDN separates control plane and data plane

from traditional networking equipment OpenFlow is one of the SDN protocols for

controlling data flows There are many applications that can be built

on top of OpenFlow and the following are some popular examples MPLS MPLS-TE VLAN


MPLS using OpenFlow Implementation of MPLS and Load Balancing

PC_A

PC_B

OFSW_3

OFSW_2

OFSW_4

IP=10.10.1. 1, MAC=a

Match fieldActions

Phy.Port

MAC src

MAC dst

MPLS label

IP src

IP dst

* * * * * 10.10.1.2

Push MPLS label 100Output port3

1

OFSW_11

2 3 12

3

2

OFSW_5

Data Center C

OFSW_7

1 2

1

2

3

4

2

2

1

1

Svr_C

Svr_D

Data Center D

OFSW_6

AB Company

IP=10.10.1. 1, MAC=b

IP=10.10.1. 2, MAC=c

IP=10.10.1. 2, MAC=d

Flow table 0 , Match fieldActions

Phy.Port

MAC src

MAC dst

MPLS la-bel

IP src

IP dst

1 * * * * * Group 100

Group table

Group ID type Counter Action bucket

100 select 999 Output port2Output port3


Phy.Port

MAC

src

MAC dst

MPLS

label

IP src

IP dst

* * * 100 * * Output Port 2


Phy.Port

MAC src

MAC dst

MPLS label

IP src

IP dst

* * * 100 * * Pop MPLS label

Flow table 1, Match fieldActions

Phy.Port

MAC src

MAC dst

MPLS label

IP src IP dst

* a * * * * Output Port 3

* b * * * * Output Port4


Phy.Port

MAC

src

MAC dst

MPLS la-bel

IP src

IP dst

* * * * * 10.10.1.2

Set dst_MAC cOutput Port 2


Phy.Port

MAC src

MAC dst

MPLS label

IP src IP dst

* * * * * 10.10.1.2

Set dst_MAC dOutput Port 2


VLAN using OpenFlow VLAN

VLAN is used to isolate networks• Uses VLAN tag or switch port number• Isolate L2 broadcast domain per user

Problems• VLAN ID = 212 = 4,096 Multi-tenants problem in Cloud Computing env.

Solutions• VxLAN (CISCO, VMWare), NVGRE(M$), extends VLAN ID to 224

• Installed in Virtual Switches in Hypervisor• VMware vSphere 5.x & CISCO Nexus 1000v VEM (Virtual Ethernet Switch)

support VxLAN• Microsoft Hyper-V supports NVGRE

VM1

VM2

VM3

VxLAN/NVGREVirtual Switch

VM1

VM2

VM3

VxLAN/NVGREVirtual Switch

VLAN Tag Type/Length Data ……

TPID Priority CFI VLAN ID


VLAN using OpenFlow VLAN Implementation with OpenFlow

OpenFlow can identify Virtual Networks only with source & destina-tion MAC address without the need of VLAN IDs

If MPLS labels are used with MAC addresses, then more Virtual Networks can be supported• MPLS label = I/F name + label number (20bits)

• Static: 0 – 1023

• Dynamic: 1024 - 1048575

MAC

MPLS

MPLS

MAC

A

B

Internet

TOR

TOR


MPLS-TE using OpenFlow (1/2) MPLS-TE

MPLS network uses OSPF(IS-IS), LDP, RSVP-TE, I-BGP, MP-BGP Distributed routing protocols cause adverse effect when there are

frequent changes in the network state• Send excessive update messages• Result in large convergence time, routing loop while converging• MPLS-TE uses more information about networks more control messages

OpenFlow controller maintains a centralized map of the network• The functionalities of distributed protocols can be implemented as a simple S/W

modules that work on the network map

New YorkSanJose

San Francisco

PE PE

OSPF

OSPF

IGP IGP

HoustonSan Jose Paris

OSPF-TE

RSVP-TE LMP

i-BGP

MP-BGP

LDP

MPLS TE/VPN config Application

OSPF-TE

RSVP-TE LMP

i-BGP

MP-BGP

LDPOSPF-TE

RSVP-TE LMP

i-BGP

MP-BGP

LDP

OSPF-TE

RSVP-TE LMP

i-BGP

MP-BGP

LDPOSPF-TE

RSVP-TE LMP

i-BGP

MP-BGP

LDP


MPLS-TE using OpenFlow (2/2) MPLS-TE with OpenFlow

Initially implemented by Stanford University• 4,500 lines of code (legacy MPLS lines of code is more than 100 k)• Tested using NOX, OpenFlow 1.1 on Mininet

OpenFlow switch support MPLS label push/swap/pop actions MPLS-TE features

• CSPF(Constrained SPF), B/W allocation, Auto-route, LSP priority

NOXcontroller

CSPF routing

Fast-failover Auto-route

Label Distri-butionDiscovery

MPLS TE/VPN config GUI

VRF Mgmt.

Network Map

Push /swap / pop

Video

VoIP

HTTP


Google SDN Google SDN

Google IP Traffic• Increases 40~45% every year

• 8~12% of total Internet traffic

36 Google Data Centers in the World• 3 DCs under construction

• USA, Taiwan,… $600M/DC, 60 staff/DC

DCs connected with submarine cables and long distance dedi-cated optical cables• Large-scale investment, but 30~40% link utilization

28 Tera bps cable(6 companies including Google, KDDI invested, 2010 open)

Google Data Centers


Google SDN Problems

WAN Routers treat all bits the same WANs links are provisioned to 30% ~ 40% average utilization

• To protect against failures and packet loss… Multi-vendor routers and switches Commercial HE/HA Routers

• Traffic increases need expensive Tera bit routers• Per port Router cost• switch failures typically result from software

Adoption of SDN and TE Commercial routers cannot follow the increase of

Google traffic volume As a solution for IP based WAN technology

problems


Google SDN Design of B4 SDN

Thousands of individual applications categorized into three classes: • user data copies (e.g., e-mail, documents, audio/video files) to remote

data centers for availability/durability latency sensitive highest prior-ity

• remote storage access for big data analysis• large-scale data push synchronizing state across multiple data centers

Design of Centralized Traffic Engineering System• Assign relative application priority and control burst at the edge

Development of OpenFlow Switch No existing platform could

satisfy Google’s requirements 10G x 128 ports Installation of OpenFlow Agent

Chip 24개

8 x 16=


Google SDN Design

Traffic Engineering System• For scalability, TE cannot operate at the granularity of individual applications• TE maps FGs to tunnels and corresponding weights• Uses ECMP

Network Control System (NCS) (3 replicas)• OpenFlow controller

• Modified Nicira’s ONIX (distributed OF control platform to support large scale network)

• Manages flow tables and ECMP group table

• Quagga stack• Support BGP/IS-IS, exchange routing protocol information among switches

• Paxos• Detect the failure and elects one of the available NCS

9.5 G20G, w=1

5G, w=0.58.5 G

2 G

0.5 G

1.5 G

3 G


Data Center SDN Data Center Topologies

To build Tera bit level Data Center Network Proposes Fat-Tree, Dcell, Bcube, … etc, to rebuild current Hierar-

chical network

DCelln=2, k=2

Bcube, n=2, k=2

Fat-tree, k=4

Jellyfish

Elastic-tree, k=4


Data Center SDN Fat-Tree

Fat-tree with k ort switches accommodate k3/4 severs K=48 27,648 servers K=48 Hierarchical N/W = $37M, Fat-Tree = $8.64M ($3,000/switch)

Researches focused on building Fat-tree with OpenFlow switches• OpenFlow forward traffic with Flows• Two level Table loopup can be implemented with OpenFlow priority features

k=4

k 4 8 16 32 48 … 256

#servers 16 128 1,024 8,192 27,648 … 4.2M


Wireless SDN OpenFlow Switch Embedding Smart PAD

Developed by NEC Traffic offload

• Enterprise or mobile operator controls the access network type per application• Video streaming Wi-Fi Email, twitter, facebook, banking 3G/LTE

• SLA based network type selection in congested case• Premium subscribers 3G/LTE Other subscribers Wi-Fi

Internet

3G/LTE

WiFi

Banking/e-approval Mail Video

Switchover byUser

Limitedbandwidth Low Se-

curityInternet

3G/LTE

WiFiby Manager

Rule Manager

Embedded OF switch

Rule

Banking/e-approval Mail Video


SDN on 5G Network (1/6) Limitation of Long Term Evolution (LTE)

LTE control plane is too distributed• Monitoring, terminal IP allocation, QoS and billing functions are centralized at

Packet Gateway (P-GW)• Expensive CISCO P-GW over $ 6M

• All traffic pass through P-GWs difficult to host popular contents• Hardware middle boxes

No clear separation of control plane and data plane

S-GW P-GW

MME

SPRHSS

PCRF

OCSOFCS

LTE-UuGTP-U(S1-U)

GTP-C/U(S5)

GTP-C(S11)

S1-AP(S1-MME)

Diameter(S6a)

Diameter (Sp)

GTP’ (Gz)

Diameter(Gy)

IP(SGi)

UEeNodeB PDN

Diameter(Gx)


SDN on 5G Network (2/6) Requirements for Cellular SDN

Greater control over data plane and simpler network management Equipment cost down through separation of control and data plane Provides scalability to Evolved Packet Core (EPC) equipment

MobileFlow PoC by Huawei DEMOed in year 2012 Sepration of control plane from eNB, SGW and PGW 100 ~ 200Mbps 3G/LTE access

PGW bearer PGW bearer PGW bearer PGW bearer

PGW con-troller

OpenFlow ++

PGWs


SDN on 5G Network (3/6) SDN Controller Applications

Need fine grained control of middlebox traffic• Current cellular networks do not provide fine-grained control over routing direct

excess traffic to some middleboxes and use many tunnels• SDN provides fine-grained packet classifier and flexible routing, which can easily

direct traffic through a lightly-loaded middlebox

Monitoring for traffic control and billing• Additional equipment (Deep Packet Inspection: DPI) that captures all packets in

each Serving Gateway (S-GW) Hundreds of DPIs• OpenFlow flow table counter

• Efficiently monitor traffic and detailed billing information

S-GW P-GW

MMEHSS

LTE-Uu

GTP-U(S1-U)

GTP-C/U(S5)

IP(SGi)

UE eNodeB PDN

Traffic is not evenly distributed

in middleboxes

Many DPIs may be deployed in S1-U


SDN on 5G Network (4/6) Vertical Handover

Traffic offload, quality and billing optimization No common protocols for controlling forwarding across different

wireless technologies (3G, LTE, WiMAX, Wi-Fi)• Handover across technologies needs complex procedures that lead to longer de-

lays and higher packet loss rates

OpenFlow as a common control protocol• Minimize setup delay, and so less packet loss

802.16 BS(RAS)

802.11 AP

MN

Router

LMA

ACR 5

1

2

4

36

WiMax WLAN Handover

OpenFlow++ controller

802.16 BS(RAS)

802.11 AP

MN

Router

LMA

ACR

1

2

WiMax WLAN Handover

Policy


SDN on 5G Network (5/6) Simplified Handover

Inter-cell Interference Management Inter-cell interference management is done among adjacent eNBs

• Suboptimal graph coloring algorithm• Due to the lack of a global view, and with a limited number of rounds are highly

suboptimal limited computing power

SDN controller as a global view• current power and subcarrier allocation profile of all

base stations • SDN controller running on a cloud servers have

more powerful computing resources than eNBs

S5 GTP tunnel

S1 GTP

tunnel

Wi-Fi

SGW PGW

Internet

S5 GTP tunnel

Wi-Fi

SGW PGW

Internet

Reconfigure the changed tunnel only


Global View


SDN on 5G Network (6/6) Policy Enforcement

P-GW is the central point enforcement and charging SDN enables the distributed enforcement of QoS and ACL policies

using centralized logical view• Relives the policy enforcement burden from the expensive middleboxes

SwitchPort

MACsrc

MACdst

Ethertype

VLANID

SrcIP

DstIP

ProtoNo.

TCPS_port

TCPD_port Action CounterOperation Mode

* 00:30.. 00:2e.. 0800 * 5.2.3.4 1.2.3.9 4 * * Meter 1 1364QoS

* * * * * * * * * 22 Drop 544Firewall

Meter table Meter 1 1000 kbps 233drop


Policy

IP

SGW

PGW


Requirements for SDN on 5G Network

OpenFlow ++ Controller Controller applications need to apply policies based on the properties

of cellular subscribers • Subscription type: usage cap, parental controls, etc.

• when an user is exceeding the usage cap priority control or rate limit

• Device type: display and camera resolution, transcoding, echo cancellation • Cellular provider information: roaming…

Controller changes policy into switch tables• Flow, Group, Meter… tables, and some more New tables

Controller Mobile ApplicationsController Mobile Applications

OpenFlow protocol

Mobile SvcSubscription

Info

Mobile SvcSubscription

Info

Usage Info

Usage Info

Device Info

Device Info

RoamingInfo

RoamingInfo

IPSGW

PGW

Policy Monitoring

SubscriberInformation

base


Requirements for SDN on 5G Network

OpenFlow ++ Switch Cellular data networks face significant scalability challenges

• Large number of subscribers, frequent changes in user location, access-con-trol and QoS policies, and real-time adaptation to network conditions

Simple and repetitive measurement and control functions local agent • Line card protocols• Periodic polling of traffic counters • Notifying the threshold alarm to controller…

Need for developing more new tables• Cellular N/W uses many DPI appliances to classify applications and provide security

• TCP/UDP port numbers are no longer a sufficiently reliable way

• DPI rule table • Add and remove rules where the pattern is a regular expression

SwitchPort

MACsrc

MACdst

Ethertype

VLANID

SrcIP

DstIP

ProtoNo.

TCPS_port

TCPD_port

Action CounterMode

* 00:30.. 00:2e.. 0800 * 5.2.3.4 * 4 * * DPI 1 5555DPI

DPI 1 meter 1 3344*torrent*

Meter 1 100 kbps 1364drop


Other SDNs – LISP (1/6) Locator/Identifier Separation Protocol (LISP)

Motivation• An IP address “overloads” location and identity

• IP is used both as identity and routing locator

• Route scaling issues drive system costs higher• Storing Routing Information Base (RIB) entries

requires expensive memory

LISP• Separate the roles of locator and identity from original IP address

• Separate of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme

• Support incremental deployment• Only require to change the edge router

• No core router and host changes are needed

• Support network virtualization• Support address family traversal

• IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6

• BGP-free multihoming• Support traffic engineering• Support IP mobility

1990

1992

1994

1996

1998

2000

2002

2004

2006

2008

2010

2012

2014

0

100000

200000

300000

400000

500000

Year

BG

P R

IB E

ntr

ies


Other SDNs – LISP (2/6) LISP Namespaces

Endpoint IDentification (EID)• The address of a host which is used for identifying a host

Routing LOCator (RLOC)• IP address of LISP router for routing the packets between hosts

EID-to-RLOC mapping• Distributed architecture that maps EIDs to RLOCs

Ingress Tunnel Router (ITR)• A router that encapsulates packets

working as the tunnel start point

Egress Tunnel Router (ETR)• A router that accepts an IP packet

working as the tunnel endpoint

xTR: ITR + ETR Mapping Database

• EID-RLOC mapping for local LISP site

Mapping Cache• EID-RLOC mapping for remote sites

Prefix Next-hopw.x.y.1 e.f.g.hx.y.w.2 e.f.g.hz.q.r.5e.f.g.hz.q.r.5e.f.g.h

Non-LISP

RLOC Space

EID-to-RLOC mapping

EID-to-RLOC mapping

EID SpacexTR

xTR

MS/MR

PxTR

xTR

EID RLOCa.a.a.0/24 w.x.y.1b.b.b.0/24 x.y.w.2c.c.c.0/24 z.q.r.5d.d.0.0/16 z.q.r.5EID SpaceEID Space


Other SDNs – LISP (3/6)

LISP IPv4 EID in IPv4 RLOC Packet Header

Other LISP Data Packet Headers

IPv4 Outer Header: ITR supplies RLOCs

IPv4 Inner Header:Host supplies EIDs

LISP Header:

UDP Header:

IPv6 in IPv4

IPv6 Outer

Header

IPv4 Inner

Header

UDPLISP

IPv4 in IPv6

IPv4 Outer

Header

IPv6 Inner

Header

UDPLISP

IPv6 in IPv6

IPv6 Outer

Header

IPv6 Inner

Header

UDPLISP



LISP Data Plane

Provider A10.0.0.0/8

Provider B11.0.0.0/8

S

ITR

DITR

ETR

ETR

Provider Y13.0.0.0/8

Provider X12.0.0.0/8S1

S2

D1

D2

PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8

DNS entry:D.abc.com A 2.0.0.2 EID-prefix: 2.0.0.0/8

Locator-set:

12.0.0.2, priority: 1, weight: 50 (D1)

13.0.0.2, priority: 1, weight: 50 (D2)

Mapping

Entry

1.0.0.1 -> 2.0.0.2

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

Legend:

EIDs -> Blue

Locators -> Red

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

1.0.0.1 -> 2.0.0.2

12.0.0.2

13.0.0.2

10.0.0.1

11.0.0.1



LISP Control Plane

Legend:

EIDs -> Blue

Locators -> Red

GRE Tunnel

Low Opex

Physical link

Data Packet

Map-Request

Map-Reply

ETR

ETR

ETR

ITR

EID-prefix 240.1.2.0/24

ITREID-prefix 240.1.1.0/24

ALT

EID-prefix 240.2.1.0/24

240.0.0.1 -> 240.1.1.1

1.1.1.

1

2.2.2.2

3.3.3.3

240.0.0.1 -> 240.1.1.1EID-prefix 240.0.0.0/24

1.1.1.1 -> 11.0.0.1

240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 1.1.1.1

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr12.0.0.1

11.0.0.1

?

240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 240.1.1.1

? 240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 240.1.1.1

?<- 240.1.1.0/24

<- 240.1.2.0/24

< - 240.1.0.0/16

?

Mapping System



EID 1.1.1.0/24

RLOC Priority/Weight State

11.0.0.1 1/90 Up

12.0.0.1 1/10 Up

xTR2

12.0.0.1

Mapping System

xTR1

11.0.0.1

Client

EID 1.1.1.0/24


11.0.0.1 1/50 Up

12.0.0.1 1/50 Up

EID 1.1.1.1

FTP Server

4. Disaster Recovery3. VM Mobility

1. Traffic Engineering 2. Vertical Hanover

WiFi LTE

xTR2

12.0.0.1

Mapping System

xTR1

11.0.0.1

EID 1.1.1.1

Internet

RTR

Mobile Client

EID 2.1.1.1

EID 2.1.1.0/24


15.0.0.1 1/100 Up

…

EID 1.1.1.0/24


11.0.0.1 1/100 Up

EID 2.1.1.0/24


21.0.0.1 1/100 Up

xTR1 Map Cache

RTR Map Cache

21.0.0.122.0.0.1

15.0.0.1

EID 1.1.1.0/24


11.0.0.1 1/100 Up

EID 2.1.1.0/24


22.0.0.1 1/100 Up

xTR2

12.0.0.1

Mapping System

xTR1

11.0.0.1

xTR6

DR Center

16.0.0.1

EID 1.1.1.1

EID 1.1.1.1

Data Center 1

Client

libvirt

KVM

libvirt

KVM

Terminal

Live Migration 요청

libvirt

KVM

15.0.0.x

11.0.0.101 13.0.0.101IPv4 Network

IPv4 EID IPv6 EID RLOCV6 Flag

192.168.0.0/24 N/A 11.0.0.101 N/A

192.168.2.0/24 NULL 15.0.0.101 0

192.168.0.1/32 2001::ab::c0a8:1 13.0.0.101 1


192.168.1.0/24 N/A 13.0.0.101 N/A

192.168.0.1/32 2001::ab::c0a8:1 13.0.0.101 1

192.168.2.0/24 NULL 15.0.0.101 0


192.168.2.0/24 N/A 15.0.0.101 N/A

192.168.0.0/24 NULL 11.0.0.101 0

192.168.0.1/32 2001::ab::c0a8:1 13.0.0.101 1

15.0.0.101

Map Cache & DB of SRC xTR

cache

DB

Map Cache & DB of Client xTR

DB

Map Cache & DB of DST xTR

Client Site

Source Site

Destination Site

cache

DB

192.168.2.0/24 (IPv4)

cache

192.168.0.0/24 (IPv4)

192.168.0.1/32

Map Server/Resolver

새로 추가 됨새로 추가 됨

새로 추가 됨

2001::ab/64 (IPv6)

SRC HYP

DST HYP

①

②

③

④⑤⑤

⑥

4to6 SM 컨트롤 메시지가상 머신 마이그레이션 데이터

SRC xTR DST xTR

Client xTR


SDN Standardization Standard Organizations

ONF• OpenFlow specification OpenFlow 1.0 ~ 1.5• Efforts to develop commercial solutions• Google + Stanford graduate / vendors + Datacenter operators

IETF• SDN RG, I2RS WG, Segment Routing, and etc.• Cisco, Juniper + existing IETF member companies

IEEE• SDN4FNS (SDN for Future Network and Services)• Academia, Vendors, Operators


Research Challenges in SDN (1/6)

ResearchIssues in

SDN

1 Controller Design

Traffic Engineering2

3 Debugging, Testing

Security4

5 Failover


Research Challenges in SDN (2/6) Controller Design

Centralized management scheme suffers from scalability issue• Frequent events stress the control plane

Two overheads during SDN communication• Flow setup

• ASIC switching rate: 5 us latency, 300 Gbps throughput

• ASIC CPU: incurs 0.5 ms latency, 80 Mbps throughput

• CPU controller: incurs 2 ms latency, 17 Mbps throughput

• Gathering statistics• Counters (e.g., packets, bytes, duration)

• Pull-based implementation

• Controller has to periodically fetch the stat. info.

• More frequent polling more overhead

• Larger flow table size more information more overhead

Distributed Con-trollers: Data Plane Extensions:

Control Plane Control Plane Control Plane

Data Plane

Control Plane

Data Plane


Research Challenges in SDN (3/6) Traffic Engineering

Lack of efficiency• Average utilization of busy links over time is only 30 ~ 50%

• CAPEX: over provisioning under utilization of links

• OPEX: network fabrics are always on energy wastage

Poor in resource allocation• Legacy protocols adopt greedy resource allocation scheme

• E.g., ECMP greedily selects shortest path cause link congestion

SDN Approach Provide logically centralized control with traffic engineering Dynamically allocate network resource based on the network status

Pod 0 Pod 1 Pod 2 Pod 3

Congestions

Idle

Idle Idle


Research Challenges in SDN (4/6) Debugging & Testing

Network debugging is difficult!• Forwarding state is hard to analyze

• Distributed across multiple tables and boxes

• Written to network by multiple independent writers

• Centralized SDN management eases the network debugging

Bugs can be anywhere in the SDN stack• Event disorder, wrong control logic and etc.

Testing OpenFlow Applications is challenging• Behavior of a program depends on the larger environment

• End-host application (sends packet), switch (handling packets), controller (installing rules)

• Bugs are typically not replayable

.

.

.

Rule

Rule

Rule

.

.

.

Rule

Rule

.

.

.

Rule

Rule

Rule

Rule

Source: P. Kazemian, Stanford


Research Challenges in SDN (5/6) Security

Challenging to detect and resolve the potential conflicting flow rules imposed by dynamic SDN apps• SDN apps can compete, contradict, override one another, incorporate vulnerabilities

Too much overhead to perform DPI in every packets in network• Need to find a way to perform DPI to a set of suspicious packets• SDN allows to perform DPI in dynamic manner

• Detour network packets to be inspected by pre-installed network security device

Synthesized control message from malicious controller• Need to have strict authentication and authorization mechanisms

Web Server

OF Switch

IDS/IPS


Research Challenges in SDN (6/6) Reliability

Some applications require short failover time• E.g., voice traffic requires failover time < 50 ms

Restoration• Centralized controller has to determine the alternative path• The new paths preserve (semi-)optimality• Show relatively long recovery time (>200ms)

Protection• Use pre-configured backup path to redirect flows in distributed manner• Cannot handle multiple failures, cannot choose the optimal paths • Show fast failure recovery time (<50ms)

OF Controller

Restoration

SRC DST OP

1 2

3

A B 3A B 2OF Controller

Protection

SRC DST W_OP B_OP

A B 3 2

1 2

3

A B A B


Q&A

postech 1/35 csed702y: software defined networking james won-ki hong department of computer science...

Documents