Video S ervices over Software- Defined Networks

1. Video Services over Software-DefinedNetworks A. Murat Tekalp • December 6, 2013

2. Outline • RecentTrends in Video • High-definition, Ultra-highdefinition • 3D Video • RecentTrends in Networking • P2P Video • OpenFlow-based QoSarchitecturesfor Video • Implementation and Test Network • Open Problems

3. RecentTrends in Video • High-definition Video • ITU-R BT.709-5 1920 x 1080 x 50/60i (Full HD) • Ultra highdefinition video • ITU-R BT.2020 3840 x 2160 x 50/60p • ITU-R BT.2020 7680 x 4320 x 50/60p • Stereo video • Multi-view video • 45 - 200 views

4. Multi-view Video

5. RecentTrends in Networking • Peer-to-Peer (P2P) Networking • P2P video-on-demand • P2P real-time broadcasting • Software-Defined Networking (SDN) • OpenFlow is the first successful implementation of SDN developed by Stanford University • Started to be deployed throughout the world. • Video withend-to-endquality of service (QoS)

6. P2P Multicast 3DTV Distribution Network • An independent overlay tree for each stream. • Clients subscribe only to overlay trees for the streams they want to receive. • Synchronizationwith DVB-stereo broadcast 3DTV Clients Main 3DTV Server Overlay Multicast Content Distribution Peers FP6 NoE 3DTV FP7 Project DIOMEDES

7. WhyOpenFlow? • Centralizednetwork managementandcontrol • complete, end-to-end network resourcevisibility • Programmability • Abstraction of theunderlying network • OpenFlow’sadvanced network managementcapabilitiesallowssophisticatednetworkingsolutions • Network Virtualization • End-to-endQuality of Service (QoS) • Applications in • Data centers • Cloudservices

8. Existing QoS Mechanisms • Several QoS mechanismshavebeenproposed • IntServ • Diffserv • MultiprotocolLabelSwitching (MPLS) • Problem: They are built on current Internet’s distributed (hop-by-hop) architecture which cannot haveend-to-end network resource information

9. OpenFlow-basedQuality of Service • We propose two solutions for enabling QoS: • priority queuing and • dynamic QoS routing (shall be triggered when the QoS requirements are not met by queuemanagement) • OpenFlow’s role • providing complete network resource visibility • instant management over network devices seamlessly adapting end-to-end network behavior • differentiate packet types on a per-flow basis

10. Open Problem • OpenFlow(v.1.2) onlysupportsinglecontroller • Singlecontrollerdoes not scaleforlargeandmulti-domain OpenFlow networks: • single controller may not be able to update flow tables in timedue to • limited processing power • latency introduced by physically distantforwarders • there would be a large volume of traffic towards the controller due to messagingbetween controller and all forwarders.

11. Distributed QoS ArchitectureforLarge-Scale OpenFlow Networks • For network scalability topologyaggregation • Inourdistributedarchitecture: • Theoverall network is dividedintocontroldomains. • Eachcontrol domain is managedbyone (ormore) controller, • Each controller is responsible for • its dedicated intra-domain routing • exchangingaggregatedinformationwith other controllers to help inter-domainrouting. • Controllers form a logicallycentralizedcontrolplaneusingthecontroller-controllerinterface.

12. OpenFlow-based QoS architecture MultimediaServices • Controller – ControllerInterfaceallows controllers toshare the necessary information to cooperatively manage the whole network in a scalablemanner.The single controller architecture does notscale well when the network is large. • Controller – Service Interfaceallows service providers to set flow definitions for new data partitions and even to define new forwardingrules associated with these partitions Service Layer Controller – Service Interface Controller – ControllerInterface Controller – ControllerInterface Controller ControlLayer Controller – ForwarderInterface Forwarders ForwardingLayer 13

13. OpenFlow-based QoS architecture FlowManagement CallAdmission TrafficPolicing • TopologyManagementfunction is responsible for discovering and maintainingnetwork connectivity through data received from forwarders. • ResourceManagementfunction is responsible for determining the availabilityand collectingup-to-date network stateinformation to aid the route calculationand/orqueuemanagement. • Queue Managementfunction provides QoS support based on prioritization of queues. One (or more) queues can be attached to a forwarder's physical port, and this function maps flows to pre-configured queues. • Flow Managementfunction is responsible for collecting the flow definitions received from the service provider through the controller-service interface, and may allow efficient flow management by aggregating flow definitions. • Route Calculation function is responsible fordetermining routes (e.g. shortest path and QoS routes) for different types of flows. Several routing algorithms can run in parallel to meet the performance requirements and objectives of different flows. Controller – ControllerInterface Controller – ControllerInterface Standard Controller TopologyManagement ResourceManagement RouteCalculation QueueManagement ControlLayer Controller – ForwarderInterface ForwardingLayer Forwarders 14

14. Controller-ControllerInterface • Features: • It opens a semi-permanent TCP connection between controllers to shareaggregated inter-domainrouting information, • Reachability • QoS parameters • Link status • In the case of link failure or congestion, the interfaceinformsothercontrollersactively. • It periodically collects aggregatedtopology/state information, distributes and keepthem in sync.

15. ControlPlaneDesigns • FullyDistributedControlPlane • HierarchicallyDistributedControlPlane

16. FullyDistributedControlPlane Controller Controller Controller Forwarding Domain Forwarding Domain Forwarding Domain • Controllers • areresponsible for both intra-domain and inter-domain routing • advertises the aggregated routing information of its domain to other controllers • eachcontrollerdeterminesitsowninter-domain routestoforwardnext domain

17. s FullyDistributedControlPlane • Controller t s t

18. Hierarchically DistributedControlPlane Controller Controller Controller SuperController Forwarding Domain Forwarding Domain Forwarding Domain • SuperController • determinesinter-domain routing • pushes inter-domain routing decisions tocontrollers • Controllers • areonlyresponsible for intra-domain routing • forinter-domain routingeachcontrolleradvertises the aggregated routing information to thesuper controller

19. s • Hierarchically DistributedControlPlane • Supercontroller’s • topologicalview t s s • Controller t

20. s DistributedOptimization of QoS Routing • Problem instance: t s t

21. ApplicationtoScalable Video andMulti-View Video Streaming • Videosareencodedintolayers; • one base layer, • one or more enhancement layers. • Baselayer is importantthanenhancementlayers: • Withoutbaselayerswecannotwatch video, since thevideo’senhancementlayersdepends on baselayer. • Assumingwegetbaselayerpackets, themoreenhancementlayersweget, thebetter video qualitywereceive.

22. OpenQoSControllerImplementation • OpenQoS is implemented as an extension of an open-soucecontroller : Floodlight. • Floodlight is written in Java, provides a modularprogrammingenvironment. • OpenQoS controller: • periodicallycollectsinfo on available bandwidth on all links • runs LARAC algorithmtofindbestroutetocarry video traffic

23. OpenFlow Test Network • 3 ProntoSwitches 24

24. KOC-ARGELA Network OpenFlow connections ÖZYEĞİN UNIVERSITY VPN connections Data links Host ARGELA COMPANY Host Host Controller KOÇ UNIVERSITY

25. Conclusions:OpenProblems • DistributedarchitecturesforOpenFlow-based end-to-end QoS by dynamically optimizing queuemanagementand/ortraffic re-routing. • Distributed optimization frameworkforabovearchitectures • Controller-to-controllerinterfaceandcontroller software to implement the proposed frameworkwith minimum messaging • P2P architecturesoverOpenFlownetworks • Deployment of anactual OpenFlow test network