Software-Defined Data Plane Enhancing SDN and...
Transcript of Software-Defined Data Plane Enhancing SDN and...
Software-Defined Data Plane Enhancing SDN and NFV
Aki Nakao The University of Tokyo
GSC 18 2014/7/22
1
2
Control-Plane Elements
Network Applications
Data-Plane Elements
Applications (NFV)
Control Plane
Data Plane
SDN Architecture
North Bound Interface (NBI)
South Bound Interface (SBI)
3
Control-Plane Elements
Network Applications
Data-Plane Elements
Applications (NFV)
Control Plane
Data Plane
Application Driven Thinking
Current SDN (bottom up)
Future SDN should be (top down)
4
Application-Driven Thinking Premise: Programmable networking has been enabled by SDN and NFV App-Driven Thinking: • Think of “(killer) applications” first and then design network functions and interfaces APIs for SDN and NFV
• Not just OPEX/CAPEX reduction but create new values via SDN and NFV
Lets start with an example application!
“Next-Gen MVNO”
5
An ISP needs app specific traffic control
Standard Mode (flat rate)
High Speed Mode (pay as you go)
bandwidth
150kbps
Bandwidth Control According to Apps !
6
MVNO Customers Need More Flexible Subscription
App-specific traffic control enables more fined grained subscription plans that can get an MVNO out of the “low cost” competition
Application Driven SDN
• The current SDN is targeted at network operators (researchers) and not at application developers
• Flow abstraction in Southbound Interface is for operators <Flow Pattern> <Action> <Stat>
• App/Device abstraction is useful and intuitive for application developers
<App/Device> <Action><Stat>
Solution: Application-Driven Software Defined Networking 7
There is a gap between application developers and SDN’s programming interface
GENI Engineering Conference 20 Demo: App-‐Driven SDN QoS
Smartphone FLARE (Data Plane Programmable)
Chrome : Pass Thru Firefox: Block YouTube: Rate Limit
App Packet
8
Smartphones
Packet Marking
The Internet FLARE Network (SDN/NFV Enabled)
Header Payload
Add app/device information to packet trailers
Trailer
App/Device InformaTon
Smartphones (wearables)
Header Payload
Parse and remove “trailers” and map between flows and apps
FLARE(Deeply Programmable Node)
Header Payload
Traffic Engineering based on headers
SDN Controller
NTT Docomo
Our Proposal
SDN Controller
9
Gateway
MVNO Backhaul
Packet
Parse and Remove Trailers
Smartphones aWach app/device informaTon to packets FLARE detects app/device informaTon and creates mapping between flows and apps/devices
Freq
uency (Accesses/sec)
10
Demo
11
Demo
12
We won the best demo award! GEC20@UC Davis
13
Benefits • Application Specific Traffic Engineering for MVNO • Application Name Based • Application Process Based(Fore/Background) • Device Type Based • Device State Based (Context / Location Aware) • Parental Control • Not by apps on devices, but by networking • Additional Value-Add services for specific applications • Differentiation for competing apps (e.g., Chrome vs. Firefox)
14
Contributions
• Insert application information in trailers of packets (e.g., TCP SYN) • Extensible to other protocols than TCP • Similar to “Google Fast TCP Open” but for different purpose • More bits usable than TCP/IP options • Determine applications with 100% Accuracy • Cooperation between end-systems and programmable nodes • Extensible to supervised learning without app • Machine learning using sampled data with app
Software Defined Data Plane
15
Control-Plane Elements
Network Applications
Programmable Data-Plane Elements
Applications
Control Plane
Data Plane
North-Bound Interface (NBI)
E.g. OpenFlow Switches
Packet Process
Packet Process
Publish API
Accelerate SDN Standardization
16
Network Applications Data-Plane
Elements
Southbound Interface
Application Driven Thinking
Operation and Evaluation Feedback -> Accelerate Standardization
Example
17
Sliceable Software Defined Data Planes
18
Control-Plane Elements
Network Applications
Programmable Data-Plane Elements
Applications
Control Plane
Data Plane
North-Bound Interface (NBI)
E.g. OpenFlow Switches
Packet Process
Packet Process
Publish API
Programmable Data-Plane Elements Programmable Data-Plane Elements Programmable Data-Plane Elements
19
Control-Plane Elements
Network Applications
Programmable Data-Plane Elements
Applications
Control Plane
Data Plane
North-Bound Interface (NBI)
E.g. OpenFlow Switches
Packet Process
Packet Process
Programmable Data-Plane Elements Programmable Data-Plane Elements Programmable Data-Plane Elements
SDN for Network Control NFV for data processing
Programmable Data-Plane Elements Programmable Data-Plane Elements Programmable Data-Plane Elements Programmable Data-Plane Elements
SDN data plane and NFV could be unified
Control-Plane Elements
Orchestrator
(Unifying SDN Software Defined Data Plane and NFV)
20
Physical Resources: CPU + NPU
CPU NPU(s) Data Bus
NIF
White Box
Intel x86 Tilera PCIe Gen3
FLARE
FLARE
21
Physical Resources: CPU + NPU (+ GPU)
CPU NPU(s) Data Bus
NIF
GPU Data Bus
Intel Phi Intel x86 Tilera PCIe Gen3
PCIe Gen3
22
GPU CPU NPU(s) Data Bus
Data Bus
NIF
Physical Resources
Slices (Virtual Resource Containers)
Virtualization ( Resource Container ) -> Slices of Resources
Sliceable !
FLARE
23
GPU CPU NPU(s) Data Bus
Data Bus
NIF
Physical Resources
Slices (Virtual Resource Containers)
FLARE
24
GPU CPU NPU(s) Data Bus
Data Bus
NIF
Physical Resources
Slices (Virtual Resource Containers)
SDN Sliceable Programmable D-plane
NFV Sliceable Programmable D-plane
SDN Programmable Control Plane
or
FLARE
FLARE Node Implementation
36-72 cores (upto 100-200 cores in future)
(board designed by NakaoLab)
x86 Processor
Many Core Processor
The University of Tokyo Confidential
Hierarchical Resource Management • General Purpose Processor(s) • Network Processor(s) • ...and more types of processors
25
FLARE-EX Prototype (32x10Gbps)
26
27
Toy-Block Networking
ToyBlock Networking GUI
Standardization Possibility
29
• Deep (Data Plane) Programmability • Slicing (Virtualization) • Evolvable APIs • Viewed as extension to SDN • Also viewed as extension to NFV • Rethinking architecture of SDN/NFV for enabling “Deep programmability”
• Application Driven Thinking • Top-Down approach is necessity
• Toy Block Networking • Accommodate a wide range of programmers • Marketing of reusable network function “Toy Blocks”
“Software Eats Everything”
“Application Driven Thinking empowered with
Software Defined Data Plane will extend SDN/NFV further and accelerate standardization!”
30
Conclusion