1. technology and computing
2. mp3 and midi

Video Services over
Software-Defined Networks
A. Murat Tekalp
December 6, 2013
1
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
<
180
encoder
decoder
45 Virtual Intermediate Views
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
• An independent overlay tree
for each stream.
3DTV Clients
• Clients subscribe only to
overlay trees for the streams
they want to receive.
• Synchronization with DVBstereo broadcast
Main 3DTV
Server
FP6 NoE 3DTV
FP7 Project DIOMEDES
Overlay Multicast
Content
Distribution Peers
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
8
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
9
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
10
Open Problem
• OpenFlow (v.1.2) only support single controller
• Single controller does not scale for large and multidomain 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.
11
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.
12
OpenFlow-based QoS architecture
Multimedia Services
Service Layer
Controller – Controller
Interface
Control Layer
Controller – Service
Interface
Controller
Controller – Controller
Interface
Controller – Forwarder
Interface
Forwarders
Forwarding Layer
•
•
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
13
Flow
Management
Call
Admission
Traffic
Policing
Standard Controller
Topology
Management
Control Layer
Forwarding Layer
Resource
Management
Route
Calculation
Queue
Management
Controller – Controller
Interface
Controller – Controller
Interface
OpenFlow-based QoS architecture
Controller – Forwarder
Interface
Forwarders
•
•
•
•
•
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.
14
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.
15
Control Plane Designs
• Fully Distributed Control Plane
• Hierarchically Distributed Control Plane
16
Fully Distributed Control Plane
Controller
Controller
Controller
Forwarding
Domain
Forwarding
Domain
Forwarding
Domain
• 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
17
Fully Distributed Control Plane
t
s
Controller
t
s
18
Hierarchically Distributed Control Plane
Super Controller
Controller
Controller
Controller
Forwarding
Domain
Forwarding
Domain
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
19
Hierarchically Distributed Control Plane
Super controller’s
topological view
t
s
t
s
Controller
s
20
Distributed Optimization of QoS
Routing
Problem instance:
t
t
s
s
21
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.
22
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
23
OpenFlow Test Network
• 3 Pronto Switches
24
KOC-ARGELA Network
OpenFlow connections
VPN connections
Data links
ÖZYEĞİN UNIVERSITY
Host
Controller
KOÇ UNIVERSITY
Host
ARGELA COMPANY
Host
25
Conclusions:
Open Problems
• 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