Transcript Software Defined Networking SDN on 5G Network

James Won-Ki Hong
Department of Computer Science and
Engineering
POSTECH, Korea
[email protected]
POSTECH
CSED702Y: Software Defined Networking
1/35
Outline
 OpenFlow Use Cases
 VLAN, MPLS
 Wireless and Mobile SDN
 SDN in 5G Network
 Other SDNs
 LISP
 SDN Standardization
 Research Challenges
POSTECH
CSED702Y: Software Defined Networking
2/35
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
POSTECH
CSED702Y: Software Defined Networking
3/35
MPLS using OpenFlow
 Implementation of MPLS and Load Balancing
Flow table 0 , Match field
Match field
Phy.
Port
MAC
src
*
*
Flow table 0 , Match field
MAC MPLS
dst
label
*
IP
src
*
Actions
IP dst
*
Phy.
Port
10.10. Push MPLS
1.2 label 100
MA MAC MPL
C
dst
S
src
label
*
*
*
IP
src
IP
dst
*
*
100
Output port3
AB Company
1
PC_A
OFSW_1
MPL
S
label
IP
src
*
*
*
*
*
IP
dst
Actions
10.10 Set dst_MAC
.1.2 c
Output Port 2
Data Center C
1
2
OFSW_5
2
1
3
2
3
PC_B
1
Flow table 0 , Match field
Flow table 0 , Match field
MACIP=10.10.1.
MAC MPL1, MAC=b
IP
IP
src
dst
S
label
src
dst
*
*
*
*
*
Actions
Phy. MAC
Port src
Group
100
Group ID
type
Counter
Action bucket
100
select
999
Output port2
Output port3
1
3
2
4
OFSW_4
2
OFSW_6
Data Center D
1
IP
src
IP
dst
*
100
*
*
Flow table 1, Match field
Actions
MAC
src
MAC
dst
MPLS IP src IP dst
label
*
a
*
*
*
*
Output Port 3
*
b
*
*
*
*
Output Port4
Svr_D
IP=10.10.1. 2, MAC=d
Pop MPLS
label
Phy.
Port
2
OFSW_7
Actions
MPLS
label
Svr_C
IP=10.10.1. 2, MAC=c
2
MAC
dst
*
*
Group table
POSTECH
MAC
dst
Output Port
2
OFSW_2
1
1
MA
C
src
OFSW_3
IP=10.10.1. 1, MAC=a
Phy.
Port
Actions
Phy.
Port
Flow table 0 , Match field
Phy.
Port
MAC
src
MAC
dst
*
*
*
CSED702Y: Software Defined Networking
MPLS IP src IP dst
label
*
*
Actions
10.10. Set dst_MAC
1.2 d
Output Port 2
4/35
VLAN using OpenFlow
 VLAN
…
VLAN Tag Type/Length
Data
…
 VLAN is used to isolate networks
• Uses VLAN tag or switch port number
• Isolate L2 broadcast domain per user
TPID
Priority
CFI
VLAN ID
 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
VxLAN/NVGRE
Virtual Switch
POSTECH
VM3
VM1
VM2
VM3
VxLAN/NVGRE
Virtual Switch
CSED702Y: Software Defined Networking
5/35
VLAN using OpenFlow
 VLAN Implementation with OpenFlow
 OpenFlow can identify Virtual Networks only with source &
destination 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
TOR
A
MPLS
MAC
Internet
TOR
MPLS
B
MAC
POSTECH
CSED702Y: Software Defined Networking
6/35
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
MPLS TE/VPN config Application
SanJose
RSVP-TE
LMP
MP-BGP
OSPF-TE
LDP
i-BGP
PE
RSVP-TE
LMP
MP-BGP
OSPF-TE
LDP
i-BGP
New York
PE
IGP
IGP
Paris
San Jose
Houston
San Francisco
RSVP-TE
LMP
MP-BGP
OSPF-TE
LDP
i-BGP
RSVP-TE
OSPF-TE
POSTECH
LMP
LDP
MP-BGP
RSVP-TE
LMP
MP-BGP
OSPF-TE
LDP
i-BGP
i-BGP
CSED702Y: Software Defined Networking
7/35
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
MPLS TE/VPN config GUI
Fast-failover
CSPF routing
Auto-route
Discovery
NOX
controller
VRF
Mgmt.
Label
Distribution
Network Map
Video
Push /swap / pop
VoIP
HTTP
POSTECH
CSED702Y: Software Defined Networking
8/35
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
dedicated optical cables
• Large-scale investment, but 30~40% link utilization
Google Data Centers
POSTECH
28 Tera bps cable
(6 companies including Google, KDDI invested, 2010 open)
CSED702Y: Software Defined Networking
9/35
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
POSTECH
CSED702Y: Software Defined Networking
10/35
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
priority
• 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=
POSTECH
CSED702Y: Software Defined Networking
11/35
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
20G, w=1
5G, w=0.5
9.5 G
0.5 G
8.5 G
1.5 G
2G
3G
POSTECH
CSED702Y: Software Defined Networking
12/35
Data Center SDN
 Data Center Topologies
 To build Tera bit level Data Center Network
 Proposes Fat-Tree, Dcell, Bcube, … etc, to rebuild current
Hierarchical network
DCell
Bcube,
n=2, k=2
Jellyfish
n=2, k=2
Fat-tree, k=4
POSTECH
Elastic-tree, k=4
CSED702Y: Software Defined Networking
13/35
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)
k
#servers
48 …
256
16 128 1,024 8,192 27,648 …
4.2M
4
8
16
32
k=4
 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
POSTECH
CSED702Y: Software Defined Networking
14/35
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
Banking/
e-approval
Mail
Other subscribers  Wi-Fi
Banking/
e-approval
Video
Mail
Video
Rule
Manager
Limited
bandwidth
Low
Security
Internet
3G/LTE
Internet
3G/LTE
Switchover by
User
by Manager
WiFi
Rule
POSTECH
CSED702Y: Software Defined Networking
WiFi
Embedded
OF switch
15/35
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
Diameter (Sp)
HSS
OFCS
SPR
Diameter
(S6a)
S1-AP
(S1-MME)
GTP’ (Gz)
MME
GTP-C
(S11)
Diameter
(Gx)
GTP-C/U
(S5)
S-GW
POSTECH
Diameter
(Gy)
PCRF
GTP-U
(S1-U)
LTE-Uu
UE
OCS
IP
(SGi)
P-GW
eNodeB
CSED702Y: Software Defined Networking
PDN
16/35
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
PGW
controller
PGWs
OpenFlow ++
PGW bearer
PGW bearer
PGW bearer
PGW bearer
 MobileFlow PoC by Huawei
 DEMOed in year 2012
 Sepration of control plane from eNB, SGW and PGW
 100 ~ 200Mbps 3G/LTE access
POSTECH
CSED702Y: Software Defined Networking
17/35
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
Many DPIs may be
deployed in S1-U
HSS
MME
POSTECH
IP
(SGi)
GTP-C/U
(S5)
LTE-Uu
UE
Traffic is not
evenly distributed
in middleboxes
GTP-U
(S1-U)
S-GW
P-GW
eNodeB
CSED702Y: Software Defined Networking
PDN
18/35
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
delays and higher packet loss rates
 OpenFlow as a common control protocol
• Minimize setup delay, and so less packet loss
4
6
ACR
5
LMA
3
LMA
ACR
Policy
802.16 BS
(RAS)
Router
MN
2
OpenFlow++
controller
2
1
1
WiMax  WLAN Handover
POSTECH
Router
802.11 A
P
802.11 A
P
MN
802.16 BS
(RAS)
WiMax  WLAN Handover
CSED702Y: Software Defined Networking
19/35
SDN on 5G Network (5/6)
 Simplified Handover
Global
View
OpenFlow++
controller
S5 GTP
tunnel
SGW
S5 GTP
tunnel
Internet
SGW
PGW
Wi-Fi
Wi-Fi
 Inter-cell Interference Management
Internet
PGW
Reconfigure
the changed
tunnel only
 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
POSTECH
CSED702Y: Software Defined Networking
20/35
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
Operation Mode
Switch
Port
MAC
src
MAC
dst
Ether
type
VLAN
ID
Src
IP
Dst
IP
Proto
No.
Firewall
*
*
*
*
*
*
*
*
*
QoS
*
0800
*
5.2.3.4 1.2.3.9
4
*
Meter table
Meter 1
00:30.. 00:2e..
Policy
TCP
TCP
S_port D_port
Action
Counter
22
Drop
544
*
Meter 1
1364
drop
1000 kbps
233
OpenFlow++
controller
SGW
PGW
POSTECH
IP
CSED702Y: Software Defined Networking
21/35
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 Applications
Mobile Svc
Subscription
Info
Usage
Info
Policy
Subscriber
Information
base
Roaming
Info
Device
Info
OpenFlow
protocol
Monitoring
IP
SGW
PGW
POSTECH
CSED702Y: Software Defined Networking
22/35
Requirements for SDN on 5G Network
 OpenFlow ++ Switch
 Cellular data networks face significant scalability challenges
• Large number of subscribers, frequent changes in user location, accesscontrol 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
Mode
DPI
POSTECH
Switch MAC
Port
src
*
MAC Ether VLAN
dst type
ID
00:30.. 00:2e.. 0800
*
Src
IP
Dst
IP
5.2.3.4
*
Proto TCP TCP
Action Counter
No. S_port D_port
4
*
*
DPI 1
*torrent*
meter 1
3344
Meter 1
drop
100 kbps
1364
CSED702Y: Software Defined Networking
DPI 1
5555
23/35
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
BGP RIB Entries
500000
400000
300000
200000
100000
0
1990
 LISP
1994
• Separate the roles of locator and identity from original IP address
•
1998
2002
Year
2006
2010
2014
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
POSTECH
CSED702Y: Software Defined Networking
24/35
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)
EID-to-RLOC
mapping
• A router that encapsulates packets
working as the tunnel start point
EID Space
 Egress Tunnel Router (ETR)
• A router that accepts an IP packet
working as the tunnel endpoint
RLOC
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
MS/MR
xTR
Non-LISP
 xTR: ITR + ETR
 Mapping Database
• EID-RLOC mapping for local LISP site
EID
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
Prefix
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
Next-hop
e.f.g.h
e.f.g.h
e.f.g.h
e.f.g.h
PxTR
 Mapping Cache
RLOC Space
xTR
xTR
EID Space
• EID-RLOC mapping for remote sites
POSTECH
CSED702Y: Software Defined Networking
25/35
Other SDNs – LISP (3/6)
 LISP IPv4 EID in IPv4 RLOC Packet Header
IPv4 Outer Header:
ITR supplies RLOCs
UDP Header:
LISP Header:
IPv4 Inner Header:
Host supplies EIDs
 Other LISP Data Packet Headers
IPv4
Outer
Header
UDP
LISP
IPv6
Outer
Header
IPv6
Outer
Header
IPv6
Inner
Header
UDP
LISP
IPv4
Inner
Header
UDP
LISP
IPv4 in IPv6
IPv6 in IPv4
IPv6
Inner
Header
IPv6 in IPv6
POSTECH
CSED702Y: Software Defined Networking
26/35
Other SDNs – LISP (4/6)
 LISP Data Plane
PI EID-prefix 1.0.0.0/8
PI EID-prefix 2.0.0.0/8
ITR
Provider A
10.0.0.0/8
S1
S
ETR
Provider X
12.0.0.0/8
D1
ITR
ETR
S2
Provider B
11.0.0.0/8
D2
Provider Y
13.0.0.0/8
1.0.0.1 -> 2.0.0.2
1.0.0.1 -> 2.0.0.2
11.0.0.1 -> 12.0.0.2
11.0.0.1 -> 12.0.0.2
1.0.0.1 -> 2.0.0.2
DNS entry:
D.abc.com A 2.0.0.2
EID-prefix: 2.0.0.0/8
Mapping
Legend:
EIDs -> Blue
Locators -> Red
POSTECH
D
Entry
1.0.0.1 -> 2.0.0.2
Locator-set:
12.0.0.2, priority: 1, weight: 50 (D1)
13.0.0.2, priority: 1, weight: 50 (D2)
CSED702Y: Software Defined Networking
27/35
Other SDNs – LISP (5/6)
 LISP Control Plane
Mapping System
EID-prefix
240.0.0.0/24
?
11.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
?
ITR
?
240.0.0.1 -> 240.1.1.1
ETR
EID-prefix
240.1.1.0/24
< - 240.1.0.0/16
ALT-rtr
ALT-rtr
240.0.0.1 -> 240.1.1.1
ETR
ITR
ALT-rtr
ALT-rtr
EID-prefix
240.1.2.0/24
ALT
Legend:
EIDs -> Blue
Locators -> Red
GRE Tunnel
Low Opex
Data Packet
Map-Reply
POSTECH
EID-prefix
240.2.1.0/24
240.0.0.1 -> 240.1.1.1
Physical link
Map-Request
ETR
11.0.0.1 -> 1.1.1.1
?
1.1.1.1 -> 11.0.0.1
CSED702Y: Software Defined Networking
28/35
Other SDNs – LISP (6/6)
1. Traffic Engineering
2. Vertical Hanover
EID 1.1.1.1
xTR1
xTR1 Map Cache
xTR1
FTP Server
EID
11.0.0.1
EID 1.1.1.1
2.1.1.0/24
RLOC
Priority/Weight
State
15.0.0.1
1/100
Up
11.0.0.1
…
EID
EID
1.1.1.0/24
RLOC
Priority/Weight
State
11.0.0.1
1/50
Up
12.0.0.1
1/50
Up
xTR2
RTR Map Cache
xTR2
12.0.0.1
1.1.1.0/24
12.0.0.1
RLOC
Priority/Weight
State
11.0.0.1
1/100
Up
EID
RLOC
Priority/Weight
State
21.0.0.1
1/100
Up
EID
EID
Mapping
System
1.1.1.0/24
RLOC
Priority/Weight
State
11.0.0.1
1/90
Up
12.0.0.1
1/10
Up
Client
3. VM Mobility
IPv4 EID
IPv6 EID
RLOC
V6
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
15.0.0.x
DB
libvirt
IPv4 EID
IPv6 EID
RLOC
V6
Flag
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
새로 추가 됨
①
IPv6 EID
RLOC
V6
Flag
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.0.0/24 (IPv4)
②
192.168.0.1/32
SRC HYP
11.0.0.101
SRC xTR
IPv4 Network
⑤
libvirt
Priority/Weight
State
11.0.0.1
1/100
Up
EID
Internet
22.0.0.1
21.0.0.1
WiFi
LTE
2.1.1.0/24
RLOC
Priority/Weight
State
22.0.0.1
1/100
Up
EID 2.1.1.1
Mobile Client
Data Center 1
DB
cache
11.0.0.1
xTR2
DB
cache
12.0.0.1
EID 1.1.1.1
13.0.0.101
DST xTR
⑤
xTR1
EID 1.1.1.1
Map Cache & DB of DST xTR
IPv4 EID
Client xTR
⑥
Live Migration 요청
RLOC
KVM
Terminal
1.1.1.0/24
Map Cache & DB of Client xTR
192.168.2.0/24 (IPv4)
cache
RTR
Mapping
System
4. Disaster Recovery
Client Site
Map Cache & DB of SRC xTR
15.0.0.1
2.1.1.0/24
④
xTR6
libvirt
KVM
16.0.0.1
DST HYP
KVM
2001::ab/64 (IPv6)
4to6 SM 컨트롤 메시지
가상 머신 마이그레이션 데이터
POSTECH
Source Site
Map Server/Resolver
DR Center
Destination Site
CSED702Y: Software Defined Networking
Mapping
System
Client
29/35
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
POSTECH
CSED702Y: Software Defined Networking
30/35
Research Challenges in SDN (1/6)
1
Research
Issues in
SDN
Controller Design
3
4
5
POSTECH
Traffic Engineering
2
Debugging, Testing
Security
Failover
CSED702Y: Software Defined Networking
31/35
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 Controllers:
Control
Plane
ControlControl
Plane Plane
Data Plane
POSTECH
Data Plane Extensions:
Control Plane
Data Plane
CSED702Y: Software Defined Networking
32/35
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
Idle
Congestions
Idle
Pod 0
POSTECH
Idle
Pod 1
CSED702Y: Software Defined Networking
Pod 2
Pod 3
33/35
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
POSTECH
CSED702Y: Software Defined Networking
34/35
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
IDS/IPS
Web
Server
OF Switch
POSTECH
CSED702Y: Software Defined Networking
35/35
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)
SRC
A
DST
B
OP
OF Controller
2
3
1
SRC
DST
W_OP
B_OP
A
B
3
2
2
1
3
A
POSTECH
OF Controller
2
3
Restoration
B
A
CSED702Y: Software Defined Networking
Protection
B
36/35
Q&A
POSTECH
CSED702Y: Software Defined Networking
37/35