Application-Driven Programmable Networking Pursuing Deeper Programmability Aki Nakao (The University of Tokyo 2014/7/31 1 SDN Architecture Applications Network Applications North Bound Interface (NBI) Control Plane Control-Plane Elements South Bound Interface (SBI) Data Plane Data-Plane Elements 2 Application Driven Thinking Applications Control Plane Data Plane Current SDN (bottom up) Network Applications Control-Plane Elements Data-Plane Elements Future SDN should be (top down) 3 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 4 Lets start with an example application! Next-Gen MVNO 5 MVNO Flexible Subscription An ICustomers SP needs aNeed pp sMore pecific traffic control bandwidth Bandwidth Control According to Apps ! High Speed Mode (pay as you go) 150kbps Standard Mode (flat rate) App-specific traffic control enables more fine-grained subscription 6 plans that can get an MVNO out of the ever-lower-cost competition Our Proposal SDN Controller FLARE（Deeply Programmable Node) Parse and remove trailers and map between flows and apps Header Traffic Engineering based on headers Header Payload Payload Parse and Remove Trailers SDN Controller Packet Marking Gateway Smartphones FLARE Network (SDN/NFV Enabled) NTT Docomo MVNO Backhaul Smartphones (wearables) Add app/device information to packet trailers Header Payload Packet The Internet Trailer App/Device Informa@on Smartphones aGach app/device informa@on to packets FLARE detects app/device informa@on and creates mapping between flows and apps/devices 7 App-Specific Traffic Control Remote console of programmable network node (FLARE) Smartphone connected to our MVNO 8 Frequency (Accesses/sec) Demo 9 App-Specific QoS （FLARE API） DefineAct(appt, org.mozilla.firefox block, com.google.android.apps.maps block, nc output 6, com.google.android.youtube output 1, org.android.chrome output 5, orig.android.mediaserver output 5, unknown output 0, backproc output 0); ctt::GetAppName(APPTABLE appt); pa::ProcessApp(APPTABLE appt); pa[1] pa[2] pa[3] pa[4] pa[5] ->Queue(1000)->RatedUnqueue(50)->NB; ->Queue(1000)->RatedUnqueue(80)->NB; ->Queue(1000)->RatedUnqueue(100)->NB; ->Queue(1000)->RatedUnqueue(200)->NB; ->NB; 10 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) 11 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 12 Application Driven SDN Some ISPs need more direct SDN Southbound Interface • Flow abstraction in Southbound Interface is for operators <Flow Pattern> <Action> <Stat> • App/Device abstraction is useful and intuitive <App/Device> <Action><Stat> 13 Application Driven SDN QoS Bandwidth Control According to Apps ! FLARE Smartphone App Deeply programmable network node With soSware defined data plane Packet Chrome : Pass Thru Firefox: Block YouTube: Rate Limit 14 We won the best demo award! GEC20@UC Davis 15 Software Defined Data Plane Applications Network Applications Packet Process North-Bound Interface (NBI) Control Plane Control-Plane Elements Packet Process Publish API Data Plane Programmable Data-Plane Elements E.g. OpenFlow Switches 16 Innovation Cycle Operation and Evaluation Feedback Network Applications Southbound Interface Data-Plane Elements Application Driven Thinking 17 ITU-T Y.3300 (Y.SDN-FR) Framework of software-defined networking, 18 Example 19 Sliceable Software Defined Data Planes Applications Network Applications Packet Process North-Bound Interface (NBI) Control Plane Control-Plane Elements Packet Process Publish API Data Plane Programmable Programmable Programmable Data-Plane Programmable Data-Plane Data-Plane Elements Data-Plane Elements Elements Elements E.g. OpenFlow Switches 20 SDN data plane and NFV could be unified SDN for Network Control Network Applications Applications Packet Process NFV for Data Processing Orchestrator North-Bound Interface (NBI) Control Plane Data Plane Control-Plane Elements Packet Process Programmable Programmable E.g. OpenFlow Data-Plane Programmable Switches Data-Plane Elements Programmable Data-Plane Elements Data-Plane Elements Elements Control-Plane Elements Programmable Programmable Data-Plane Programmable Data-Plane Elements Programmable Data-Plane Elements Data-Plane Elements Elements 21 FLARE (Unifying SDN Software Defined Data Plane and NFV) Physical Resources: CPU + NPU White Box CPU Intel x86 Data Bus NPU(s) PCIe Gen3 Tilera NIF 22 FLARE Physical Resources: CPU + NPU (+ GPU) GPU Intel Phi Data Bus PCIe Gen3 CPU Intel x86 Data Bus PCIe Gen3 NPU(s) NIF Tilera 23 FLARE Virtualization ( Resource Container ) -> Slices of Resources Slices (Virtual Resource Containers) Physical Resources GPU Data Bus CPU Data Bus NPU(s) NIF Sliceable ! 24 FLARE Slices (Virtual Resource Containers) Physical Resources GPU Data Bus CPU Data Bus NPU(s) NIF 25 FLARE NFV Sliceable Programmable D-plane or SDN Programmable Control Plane SDN Sliceable Programmable D-plane Slices (Virtual Resource Containers) Physical Resources GPU Data Bus CPU Data Bus NPU(s) NIF 26 FLARE Node Implementation x86 Processor Many Core Processor (board designed by NakaoLab) 3672 cores Hierarchical Resource Management • General Purpose Processor(s) • Network Processor(s) • ...and more types of processors 27 The University of Tokyo Confidential (upto 100-200 cores in future) 27 Programming Model Toy-Block Networking 28 2 Toy-Block Networking GUI 29 Summary Missing from the current landscape of SDN and NFV • Application Driven Thinking • Top-down, dynamic update of software • User, app, device, service oriented modeling • Deep (Data Plane) Programmability • SDN data plane as a network function in NFV • Data plane slicing (virtualization) • Evolve-able APIs • New protocol handling • Programming Model • Toy-Block Networking • Accommodate a wide range of programmers • Marketing of reusable network function blocks 30
© Copyright 2024 ExpyDoc
