Software-Defined Networking (SDN)

(1)

Delivering the Moment

Software-Defined

Networking (SDN)

John Mailhot, System Architecture

Presented at CCBE Horseshoe Valley Resort 25-SEP-2015 by Randy Conrod, Product Manager – Digital Products

(2)

(3)

 IP Networks work GREAT – every office has at least one

• When you use it in a simple, standard way, with Gateway Routing and NAT

(4)

 But we’ve always had some challenges with IP networks, when we want more • Where is the network sending my packets? Why did the network do what it did?

• What path is my data taking right now? How do I make it do what I wanted?

(5)

 But we’ve always had some challenges with IP networks, when we want more • Where is the network sending my packets? Why did the network do what it did?

• What path is my data taking right now? How do I make it do what I wanted?

 But virtualized datacenters bring even bigger challenges

• If I move this virtual machine from one server to another, how do I get all the right network connections to follow it?

• Can I write a script (triggered by a web services engine) that turns up a VM and creates all the network connections to/from it?

(6)

(7)

 Researchers at UC Berkeley and Stanford wanted to do research on new network protocols and routing algorithms

• But they couldn’t make the switches they had do what they wanted

• What they really wanted was to

– turn off the intelligence “in” the switches, and

– have their own software program the forwarding tables, then

– have the switches act on the tables they made

(8)

 This grew into the “OpenFlow” whitepaper in March, 2008

– Co-Authors from Stanford, MIT, UC Berkeley, Washington University, and Princeton

(9)

 This grew into the “OpenFlow” whitepaper in March, 2008

– Co-Authors from Stanford, MIT, UC Berkeley, Washington University, and Princeton

 This also marked the beginning of the OpenFlow consortium to develop and maintain the standards and coordinate interoperability tests

(10)



Separate switch ports into “normal” ports and

“openflow” ports



Use a secure channel to connect an external

controller (with research software) to the

standard switch



Provide a (vendor independent) control schema

for the external controller to program the flow

table matching engine of the openflow ports.



More bluntly: Separate the Smart Management

away from the high-volume packet processing

through a common (secure) interface.

(11)



If a packet comes in port P1,

and “looks like” Y,

optionally modify it, and

send it out port(s) P2, P3…



The “Looks Like” criteria are a matching filter on:

• Source & Destination MAC address

• (802.1Q) VLAN ID

• EtherType

• Source & Destination IPv4 Address

• IPv4 Protocol (TCP, UDP, …)

• Source Port, Destination Port

What kinds of things can the Flow Table Entries do?

Table 1 P1 P1 Table 2 P2 P2 Table 3 P3 P3 In ter conne ct Fabric Table N PN PN CTRL CTRL

(12)



They are, but they are quite powerful



Anything the existing protocol processing in the switches can do, is done

through tables that look roughly like that

• Can do classical IP routing with this structure

• Can do VLAN “pegboarding” with this structure – assembling private Ethernet networks easily and arbitrarily

• Can do IGMP snooping or special multicast forwarding with this structure

(13)

(14)



The researchers were happy, and went on to do good research

(15)



The researchers were happy, and went on to do good research



The Switching Industry business dynamics got more “complicated”

• Fancy Routing Protocol Processing is a differentiator among vendors

• New “white-box” switches emerged that do nothing except OpenFlow

• Switch Makers talk about supporting OpenFlow on more models soon

(16)



The researchers were happy, and went on to do good research



The Switching Industry business dynamics got more “complicated”



The DataCenter Industry uses these techniques to provide virtual hosting

services, virtual machine redundancy and clustering, and virtual private

clouds

(17)



The researchers were happy, and went on to do good research



The Switching Industry business dynamics got more “complicated”



The DataCenter Industry uses these techniques to provide virtual hosting

services, virtual machine redundancy and clustering, and virtual private

clouds



Large Data Enterprises (Google, Amazon, PayPal, etc) use it daily

(18)

 Network Configuration Driven by High-Level Application  SDN Controller has visibility of the whole network  Multiple switches, geo-diverse, with common control structures

(19)

Assuming I’m not writing it, where does that “SDN

Control Software” Come From?

(20)



Many, Many Open Source Projects:

• Beacon, Floodlight [Floodlight is fairly popular]

• POX, IRIS, MUL

• Loads of others that came and went

Assuming I’m not writing it, where does that “SDN

Control Software” Come From?

(21)



Many, Many Open Source Projects:

• POX, IRIS, MUL



Vendor Offerings:

• Each vendor has some proprietary system that offers SDN-like functionality packaged as a commercial offering (generally leveraging proprietary features)

Assuming I’m not writing it, where does that “SDN

Control Software” Come From?

(22)



Many, Many Open Source Projects:

• POX, IRIS, MUL



Vendor Offerings:

• Each vendor has some proprietary system that offers SDN-like functionality packaged as a commercial offering (generally leveraging proprietary features)



Open Daylight Project

• A Funded-Multi-Vendor-Collaboration – Producing open source

Assuming I’m not writing it, where does that “SDN

Control Software” Come From?

(23)

(24)



Networking is one part of a larger business challenge:

How to operate a multi-tenant hosting datacenter with

high reliability, application-level redundancy, and scale?



The datacenter industry (led by rackspace.com) funded an opensource

project to develop solutions for this larger problem

• http://www.openstack.org/



OpenStack has several inter-related software projects

• Computing, Storage, Networking, Orchestration, Dashboard, Identity, etc.

• Over 180 companies contributing time and effort

(25)

(26)

(27)



Stand up your own “private Cloud” and host applications on it

• Manage multiple tenants, with quotas and permissions

• Arrange Networking between the applications, and storage for the apps

(28)



Stand up your own “private Cloud” and host applications on it



Run applications in one of several “public clouds” like AWS

(29)



Stand up your own “private Cloud” and host applications on it



Run applications in one of several “public clouds” like AWS



Monitor and Manage the running hosted applications through a

dashboard system

(30)

(31)

How does any of this apply to video?

The

“Broadcast

Equipment”

Economic

Ecosystem

The

“Telecom

Infrastructure”

Economic

Ecosystem

The

“Information Technology”

Economic Ecosystem

Standard Platforms

Virtual Machines

IP/Ethernet Networks

(32)

How does that play out in practice?

HDSDI I/O

For Audio Console

$4399

(33)

How does that play out in practice?

PC

HDSDI I/O

~$1000

HDSDI I/O

For Audio Console

$4399

(34)

How does that play out in practice?

Dual 10 GBE NIC

$434

PC

HDSDI I/O

~$1000

HDSDI I/O

For Audio Console

$4399

(35)

Will IP [SMPTE-2022-6] Replace Coaxial Cable?

256x256 HDSDI Router

15RU Fully Non-Blocking

384 Gbits/sec throughput

COTS Ethernet Switch/Router

48x10GBE (full duplex)

4x40GBE (full duplex)

1RU Fully Non-Blocking

640 Gbits/sec throughput

(36)

 Enables Application-Specific knowledge to decide which signals go where, instead of relying on the code in the COTS switches to decide

 Enables use of Commercial Datacenter-Grade Switches for Broadcast Video

Software-Defined Networking (SDN) in a Video Context

(37)

 Control System for Hybrid SDI/IP Facilities

• Makes everything “look like a router”

• Take Source to Destination – Simple

• Control through current routing protocols

• Compatible with Automation, Tally, MV, …  Software-Defined Workflows (SDW)

spin up new channels fast  Works with Compressed and

Uncompressed Signals Equally

 Supports Traditional and Virtual Processing Functions in the same workflows

 SDN Orchestrator Controls and Monitors the Virtual Plant, providing operations visibility

Video-Specific Features of an SDN Orchestrator

(38)

 SDI Router in the core, with a few IP things translated back to SDI

• Low-risk, add IP only as devices natively speak it

• Requires translation where IP meets baseband

• Difficult endgame

Signal Topologies of the Future Plant

Translate to/from IP

(39)

 IP Switches in the middle, everything converged to IP

• Best-cost approach as more and more devices natively speak IP

• Works well with top-of-rack architecture signal management

• Requires translation for baseband devices to get to IP

• Wire-level redundancy available for maintenance and uptime

Signal Topologies of the Future Plant

A Switch

B Switch

(40)

 IP Switches in the middle, everything converged to IP

• Best-cost approach as more and more devices natively speak IP

• Works well with top-of-rack architecture signal management

• Requires translation for baseband devices to get to IP

• Wire-level redundancy available for maintenance and uptime  Hybrid Core – Baseband plus IP

• Best of Both Worlds – baseband for baseband, IP for IP

• Translators as tie-lines – automatically allocated and routed

• Most cost-effective in the “Middle zone” of the crossover

• Clear path to the all-IP endgame

Signal Topologies of the Future Plant

(41)

Hybrid SDI/IP Networking – Distributed Top-Of-Rack

A Switch Processing Ingest/Playout Other traditional SDI/HDSDI equip B Switch Blade Servers Software-Based Virtualized Devices Processing

Ingest & Playout Other traditional SDI/HDSDI equip

Processing Ingest & Playout Other traditional SDI/HDSDI equip

Contrib & Distrib Processing Ingest & Playout Other traditional SDI/HDSDI equip Satellite RX Processing Other traditional SDI/HDSDI equip

(42)

Delivering the Moment

Software-Defined

Networking (SDN)

John Mailhot, System Architecture

Presented at Montreal SMPTE Section meeting Nov. 24, 1014 by Randy Conrod, Product Manager – Digital Products

(43)



McKeown et al.

OpenFlow: Enabling Innovation in Campus Networks

(March 14, 2008)

http://archive.openflow.org/documents/openflow-wp-latest.pdf



https://www.opennetworking.org/sdn-resources/sdn-library



http://www.techcentral.ie/software-defined-networking/



http://www.openstack.org/



http://www.opendaylight.org/

Resources

(44)



Question:

• So if I understand the problem with the infrastructure you are trying to solve with an orchestrator, the control software, how would the Open Daylight do it ?



Answer:

• They’ve written a nice orchestrator that works for the data center model and it probably can be extended to do some video things.

• It’s probably part of a solution for some class of problems, but is optimized around host and multi tenancy and hosting situations.

• There are elements that will work for the broadcast space.

(45)

 Question:

• Can you view a HD-SDI source, it’s sync and it’s network routing as an Open Daylight “gadget”.

 Answer:

• Potentially.

(46)

 Corresponding Question:

• How much of the code can you borrow or do you have to start code development from scratch ?

(47)

 Answer:

• It’s between those two extremes right now.

• There’s a couple different interrelated challenges.

• If all we are going to do is say we still going to still have SDI devices but were going to put this IP switching in the middle then it’s not really worth doing, the economics don’t work.

• If you don’t start having devices that actually natively speak IP, you are just translating at either end and move the cost out of the switches but put it in translators on either side.

• The economics start to actually shift when you have devices that natively speak IP.

• If you take apart a NEXIO server or for that matter, an Omneon server and you look at it, it’s a commercial off the shelf computer inside.

• A nice one, but still a commercial off the shelf computer.

(48)

 Answer continued:

• The custom item in it is the HD-SDI IO card and the reference input and a couple of other things to tie it to the legacy broadcast industry standards.

• As soon as we can move away from that and use SMPTE ST 2059 PTP timing instead of color black and SMPTE ST 2022-6 instead of HD-SDI, the economics change for everybody involved.

• They change for you as a customer because you are working on 10 gigabit Ethernet instead of SDI.

• It’s a harder cable to fabricate, but is an easier cable to buy.

• There is higher signal density instead of having one signal per cable, you’ve got twelve signals per cable.

• Fundamentally, one of the things the orchestrator has to do is turn up and down these software apps the way you want them and then the other things is has to do is set up connections.

• The turning up and down and redundancy management are borrowed straight from open sources and open collaboration projects out there.

• It’s when you get into the specifics of how and why the signals are routed that the broadcast industry has a very different use model than what the IT industry uses right now.

(49)



Question:

• When do you see this rolling out and becoming a viable way to start designing facilities and taking advantage of this ?



Answer:

• There are working prototypes now in our labs now but I wouldn’t start putting live signals through it today.

• We’re engaging lead customers now as are Evertz and Belden and others and will become standard shipping items in the next years.

(50)

 Question:

• Do you see camera manufacturers getting involved with this.

• Facilities that are file based can leverage this, will the camera will have an IP an ethernet connection off the side as opposed to a video connection of the side ?

 Answer:

• Sony says this will happen.

• They turned on a dime at NAB .

• If you asked Sony a year ago about IP, they said no; but now they are quite open about putting gig E on the camera.

• They are in the camp of compressing the signal before they put it on IP and that makes sense in some domains.

• The camera manufacturers are looking to move to IT based technology because again they can leverage the cost point and price using chips that do IP a lot

cheaper that making their own silicon for everything.

(51)

 Question:

• Since media companies value their media assets, how do you dispel their concerns over open source code ?

 Answer:

• As an example, they already run Linux.

• However, you still have a challenge with network security as you do already with file based workflows.

• The network is separated by proper firewalls, but as an industry, there will be developments to design for techniques to ensure that we have asset protection and security.

• The challenge of open source code is that you didn’t control its development and nor did your vendor necessarily control its development.

• The benefit is that the code is open and you can fix it or add the feature you want, but the curse is that you might actually have to do that.

• Somebody could bury a Trojan horse inside the Open Daylight code using a password and someone could hack in and delete all your files or do something more interesting with them.

• It’s always a possibility in small open source code projects.

• Open Daylight created a follow on to all these separate little open source projects.

• It now has enough participation from the A list vendors and data centers that there are eyes on it to make sure that this doesn’t happen.

• The open source projects you need to worry about only are the ones that really have a small number of developers.

• If a open source project has a community of five hundred developers or a thousand developers, there’s a little more people watching each other.

(52)



Question:

• Is there latency issues ?



Answer:

• There’s always latency issues ?



Corresponding question:



How consistent is the latency ?

• There’s like a whole another talk to be had about timing on all of this.

• There are different latency issues than using SDI not that SDI is without

latency issues and you have to manage the manage the latency through the system

(53)



Question:

• Are VLANS are a component of SDN or a different animals ?



Answer:

• VLANS are one of many constructions in ethernet so you can organize virtual LANS on a physical LAN.

• It’s 16 more bits in the ethernet header that can use to say I have all kinds of different ethernet networks stacked up in this one physical wire.

• SDN can use VLANS and both exist in the same space.