Presentation on theme: "Video Services over Software-Defined Networks 1 A. Murat Tekalp December 6, 2013."— Presentation transcript:
Video Services over Software-Defined Networks 1 A. Murat Tekalp December 6, 2013
Outline Recent Trends in Video – High-definition, Ultra-high definition – 3D Video Recent Trends in Networking – P2P Video – OpenFlow-based QoS architectures for Video – Implementation and Test Network Open Problems 2
Recent Trends in Video High-definition Video – ITU-R BT.709-5 1920 x 1080 x 50/60i (Full HD) Ultra high definition 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 3
Multi-view Video 4
Recent Trends 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 with end-to-end quality of service (QoS) 5
P2P Multicast 3DTV Distribution Network Main 3DTV Server Overlay Multicast Content Distribution Peers 3DTV Clients An independent overlay tree for each stream. Clients subscribe only to overlay trees for the streams they want to receive. Synchronization with DVB- stereo broadcast FP6 NoE 3DTV FP7 Project DIOMEDES
SDN 7 Open Networking Foundation has been found in 2011 for standardization and commercialization of SDN. Decoupling control and forwarding layers of routing.
Why OpenFlow? Centralized network management and control – complete, end-to-end network resource visibility – Programmability – Abstraction of the underlying network OpenFlows advanced network management capabilities allows sophisticated networking solutions – Network Virtualization – End-to-end Quality of Service (QoS) Applications in – Data centers – Cloud services 8
Existing QoS Mechanisms Several QoS mechanisms have been proposed IntServ Diffserv Multiprotocol Label Switching (MPLS) Problem: They are built on current Internets distributed (hop-by-hop) architecture which cannot have end-to-end network resource information 9
OpenFlow-based Quality of Service 10 We propose two solutions for enabling QoS: 1)priority queuing and 2)dynamic QoS routing (shall be triggered when the QoS requirements are not met by queue management) OpenFlows 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
11 Open Problem OpenFlow (v.1.2) only support single controller Single controller does not scale for large and multi- domain OpenFlow networks: 1.single controller may not be able to update flow tables in time due to limited processing power latency introduced by physically distant forwarders 2.there would be a large volume of traffic towards the controller due to messaging between controller and all forwarders.
12 Distributed QoS Architecture for Large-Scale OpenFlow Networks For network scalability topology aggregation In our distributed architecture: 1)The overall network is divided into control domains. 2)Each control domain is managed by one (or more) controller, 3)Each controller is responsible for its dedicated intra-domain routing exchanging aggregated information with other controllers to help inter-domain routing. 4)Controllers form a logically centralized control plane using the controller-controller interface.
13 OpenFlow-based QoS architecture 13 Controller Multimedia Services Forwarders Service Layer Control Layer Forwarding Layer Controller – Service Interface Controller – Forwarder Interface Controller – Controller Interface Controller – Controller Interface allows controllers to share the necessary information to cooperatively manage the whole network in a scalable manner. The single controller architecture does not scale well when the network is large. Controller – Service Interface allows service providers to set flow definitions for new data partitions and even to define new forwarding rules associated with these partitions
14 OpenFlow-based QoS architecture 14 Standard Controller Forwarders Control Layer Forwarding Layer Controller – Forwarder Interface Topology Management Resource Management Route Calculation Flow Management Call Admission Traffic Policing Controller – Controller Interface Queue Management Topology Management function is responsible for discovering and maintaining network connectivity through data received from forwarders. Resource Management function is responsible for determining the availability and collecting up-to-date network state information to aid the route calculation and/or queue management. Queue Management function 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 Management function 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 for determining 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.
15 Controller-Controller Interface Features: It opens a semi-permanent TCP connection between controllers to share aggregated inter-domain routing information, Reachability QoS parameters Link status In the case of link failure or congestion, the interface informs other controllers actively. It periodically collects aggregated topology/state information, distributes and keep them in sync.
16 Control Plane Designs Fully Distributed Control Plane Hierarchically Distributed Control Plane
17 Fully Distributed Control Plane Controllers are responsible for both intra-domain and inter-domain routing advertises the aggregated routing information of its domain to other controllers each controller determines its own inter-domain routes to forward next domain Controller Forwarding Domain Controller Forwarding Domain Controller Forwarding Domain
18 t s s t Fully Distributed Control Plane Controller
19 Hierarchically Distributed Control Plane Controller Forwarding Domain Controller Forwarding Domain Controller Forwarding Domain Super Controller determines inter-domain routing pushes inter-domain routing decisions to controllers Controllers are only responsible for intra-domain routing for inter-domain routing each controller advertises the aggregated routing information to the super controller
20 s s t Hierarchically Distributed Control Plane s t Super controllers topological view Controller
21 Distributed Optimization of QoS Routing Problem instance: s t s t
22 Application to Scalable Video and Multi-View Video Streaming Videos are encoded into layers; one base layer, one or more enhancement layers. Base layer is important than enhancement layers: Without base layers we cannot watch video, since the videos enhancement layers depends on base layer. Assuming we get base layer packets, the more enhancement layers we get, the better video quality we receive.
23 OpenQoS Controller Implementation OpenQoS is implemented as an extension of an open-souce controller : Floodlight. Floodlight is written in Java, provides a modular programming environment. OpenQoS controller: periodically collects info on available bandwidth on all links runs LARAC algorithm to find best route to carry video traffic
24 OpenFlow Test Network 3 Pronto Switches
KOC-ARGELA Network 25 Host Controller KOÇ UNIVERSITY ARGELA COMPANY ÖZYEĞİN UNIVERSITY Host OpenFlow connections VPN connections Data links
Distributed architectures for OpenFlow-based end-to-end QoS by dynamically optimizing queue management and/or traffic re-routing. Distributed optimization framework for above architectures Controller-to-controller interface and controller software to implement the proposed framework with minimum messaging P2P architectures over OpenFlow networks Deployment of an actual OpenFlow test network 26 Conclusions: Open Problems