1

Video Services over Software-Defined Networks

A. Murat TekalpDecember 6, 2013

2

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

3

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

4

Multi-view Video

< 180�

45 Virtual Intermediate Views

encoder

decoder

5

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)

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 3DTVFP7 Project DIOMEDES

8

Why OpenFlow?• Centralized network management and control– complete, end-to-end network resource visibility– Programmability– Abstraction of the underlying network

• OpenFlow’s advanced network management capabilities allows sophisticated networking solutions– Network Virtualization– End-to-end Quality of Service (QoS)

• Applications in– Data centers – Cloud services

9

Existing QoS Mechanisms

• Several QoS mechanisms have been proposed IntServ Diffserv Multiprotocol Label Switching (MPLS)

• Problem: They are built on current Internet’s distributed (hop-by-hop) architecture which cannot have end-to-end network resource information

10

OpenFlow-based Quality of Service

• 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)

• 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

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

• 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 LayerForwarding Layer

Controller – Forwarder Interface

Topology Management

Resource Management

Route Calculation

Flow Management

Call Admission

Traffic Policing

Controller – Controller Interface

Cont

rolle

r – C

ontr

olle

r In

terf

ace

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

tss

t

Fully Distributed Control Plane

Controller

19

Hierarchically Distributed Control Plane

Controller

Forwarding Domain

Controller

Forwarding Domain

Controller

Forwarding Domain

Super Controller

• 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

ss

t

Hierarchically Distributed Control Plane

st

Super controller’stopological view

Controller

21

Distributed Optimization of QoS Routing

Problem instance:

st

st

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 video’s

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

2424

OpenFlow Test Network

• 3 Pronto Switches

25

KOC-ARGELA Network

Host

Controller

KOÇ UNIVERSITY ARGELA COMPANY

ÖZYEĞİN UNIVERSITY

Host

Host

OpenFlow connections

VPN connections Data links

26

• 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

Conclusions:Open Problems