...

Overview

Presentation

SDI over IP

Traditional broadcast Infrastructure built with SDI Baseband Base-band Routers, coaxial cables and BNC connectors is transitioning to Ethernet using off-the-shelf network switches and SDN control. The increasing speeds supported by Ethernet Switches and the corresponding improvement in aggregate non-blocking switch and network throughput has paved the way for the use of IP/Ethernet to transport critical broadcast applications in a cost-effective manner, while delivering the same robustness and stability of legacy SDI and MADI router operations – all with greatly increased agility and flexibility to meet ever evolving media formats.

Broadcast Topology

Following is a sample simple topology of broadcast using IP NW.

Image RemovedImage Added

Features

Fault tolerance & Robustness

...

One of the most important feature to have in controller, should have following capabilities:

...

But even if we modify ONOS to create multiple paths for a pair of source and destination traffic will always be flowing which will be a waste of BW.

To over-come that, backup flows with arbitrary but unique matching criteria will be created which will not be matched to any traffic in network while a flow is a backup path not the active path but as soon as there is a failure in active path or user want to switch the path intentionally then packet header will be updated with arbitrary match criteria to match new active path, this packet processing will be done either in P4 or using OF experimenters in switch.

This procedure if of generating arbitrary match criteria and modifying packet header is similar to one also used in switching of RTP streams section below. This mechanism can evolve as an generic framework for packet processing.

ONOS also support clusteringsupports clustering so requirement for HA is met.

Support for LAG is not present in the ONOS at the moment, it is to be implemented. NOS like Pica8 support it we need to interface with it. 

Traffic Engineering

Controller should have a mechanism by which it is able to choose and setup best available intents according to specific traffic type. To achieve this controller should be able to determine:

• Latency and Bandwidth of intents– With the known latency and bandwidth properties, controller should be able to determine which intents (more than one) to deploy for a specific traffic types(traffic types like live audio, video, logging are identified by vlan in most cases) with their priorities (in case of failure priority helps to choose for next intent) i.e. For a real time audio stream, latency of path is a priority than its bandwidth (for sure there should be minimum bandwidth available to carry voice stream), for a normal video file play latency may not a priority and it can take longer path, for an HD video file transfer high bandwidth can be a priority rather than latency.

Solution

To calculate latency :

1. Controller need to discover possible links(more than one intents) between two hosts comprise of flows which have a unique matching criteria so that it is impossible to match this criterion with real network traffic.
2. Then send a packet (e.g. UDP packet, which matches the unique matching criteria) from controller to the port connecting source host and redirect to controller as soon as it reaches the destination port i.e. the port where destination host is connected. Time difference between sending and receiving the packet can be considered as latency. This latency also contains the time between controller and switches to be more accurate, a P4 program or experimenters implementation in OF can be used to notify controller about the time when this special packet entered source port and got out from destination port.  

Real time bandwidth usage is available in ONOS which can be used in combination with port capacity can be used to know the actual available BW.

Switching of RTP streams

This is another important requirement to have in Broad-cast controller. Switching of RTP streams can occur in various scenarios like:

...

Actually, it is to be switched within 0.000001991 sec. to ensure 0 packet loss, otherwise buffering of incoming packets will be required until the flow is deployed. And at high scale buffering is not efficient as switching devices have really small buffers another is, a delay is always added to a stream on each switch.

Solution

[1] RTP packet must be processed and marker bit should be identified and only then the new flow should be active independent of when they were created how much time did it take to be deployed in data plane.

...

The actual processing of the RTP packets is to be done in HW, Controller should be able to deploy this packet processing logic on switch i.e. this packet processing can be done using P4 and experimenters in switch, in either case ONOS can deploy the logic on switch using P4Runtime or Extension framework.

Latency and bandwidth monitoring

Following Latency and Bandwidth information is to be available for user for monitoring purpose:

• Quality of Link in terms of latency and bandwidth – Controller should be able to suggest available links (more than one intent) with their quality i.e. latency and bandwidth. Latency is time delta between receiving a packet on a host and sent out from another. Similarly, total bandwidth available for these intents based on current traffic and port capacity.
• Stream Switching latency – Time required to switch a stream from different sources.

Solution

Link latency can be accounted by calculating time between sending a packet from a host and receiving it at another host over that link, to achieve this controller need to identify possible links(intents) between two hosts and then flows of these intents will have unique matching criteria so that it is impossible to match this criterion with real network traffic. Then send a packet (e.g. UDP) from controller to the port connecting source host and redirect to controller while reached the destination port i.e. the port where destination host is connected. A P4 program or experimenters implementation can be used to notify controller about the time when this special packet entered source port and got out from destination port for latency calculation.  

Real time bandwidth usage is available in ONOS which can be used in combination with port capacity can be used to know the actual available BW.

...

.

QOS & Metering Support

Apply QOS and Metering on Ports.

...

There are few more requirements which are worth mentioning:

• Full port Port configuration like port speed, VLan, trunk, bridge etc.
• Handling of SDI and IP NW together.
• Interact with AMWA NMOS database.
• Security - access security i.e. prevent unwanted devices and packet security i.e. packet encryption.
• NAT (Network Address Translation) - it is already supported in OpenFlow rule instructions in ONOS.

Discussion

References

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.673.7881&rep=rep1&type=pdf

...

[4] https://www.thebroadcastbridge.com/content/entry/7722/transition-strategies-sdi-to-ip

[5] https://www.thebroadcastbridge.com/content/entry/7646/the-changing-face-of-broadcast-from-virtualization-to-the-cloud