Our biggest competitor: an unmanaged IP network

 

In the field of technology, we’re a big believer in the idea that ‘the whole is bigger than the sum of its parts’.

Because at SDNsquare, our purpose is about more than securing the next client, the next big sale, the personal dividends of our own little piece of the puzzle. Instead, it’s about standing at the forefront of a technology we truly believe in, and working to push the boundaries of the broadcast industry as a whole. It’s about championing SDN above all else. It’s about contributing to that bigger whole.

Which means that when it comes to competition in the field of Software Defined Network management for broadcast, our biggest competitors aren’t other SDN providers in the field. Instead, our biggest competitor is ignorance. We don’t lose out when another firm implements a solution for a client, we lose out – and by that ‘we’, we mean ‘we’ as a collective industry – when a potential broadcast client doesn’t even know that such a solution exists. A lack of knowledge regarding the huge potential that SDNs can bring in terms of efficiency, reliability, security and cost reductions is a loss for everybody; a squandered opportunity, and a big step backwards.

Which is why first and foremost we at SDNsquare have to work as ‘SDN evangelists’. We champion the concept of SDNs in general as much as we do our own specific solution (though there are a multitude of reasons why our GRID represents one of the most powerful, effective offerings out there). Ultimately, truth be told, we’d rather a broadcaster ‘sees the light’ of SDN as a technological concept, even if it means they end up engaging the services of a direct competitor. Rather that than have them maintain an unmanaged network and languish in the dark ages. No one wins then.

Because ultimately, technology really shouldn’t be seen as zero-sum game. What benefits individual operators benefits the field as a whole. In a symbiotic industry such as that of broadcast the interdependence of every single player is incredibly high; so it’s all of competitors in the field of SDN competitors driving progress, it’s every single operator in the field of IP generally, driving technologies that relate to production, ingest, contribution, monitoring, playout, network management, playout… the list is practically endless. And when we work together in an odd kind of ‘competitively collaborative’ way, then we drive awareness, investment and innovation in the field of IP generally, and the net result is a benefit for everyone; from innovators to manufacturers to resellers to the audiences themselves.

So with that evangelist mission statement in mind, here are some of the key things we think you need to know about IP production environments, and the potential that SDNs can bring to them.

 

Why IP is perfect for Media transport. But also terrible for it…

It was 2015 when the whisper in the IBC halls began to grow: ‘SDI is dead’ the masses were murmuring. Seven years later and it’s more than a whisper, it’s a reality. Not that we want to dance on any gravestones…

But if SDI is dead, who – or what – killed it? Most fingers point towards IP. IP just offered so many immediate, obvious benefits that SDI simply couldn’t keep up with. Dynamic, scalable, efficient and utterly unphased by distance – it is IP which is bringing about the potential for real-time, live, remote broadcast; creating opportunities, harmonizing operations, reducing infrastructure, equipment and operational costs. It seems like the wunderkind of the modern broadcast era.

But we’ll share a secret truth with you. IP is kind of terrible for broadcast. Or at least, in its raw form without some clever management, it’s less than ideal. Why?

Well, IT protocols and standards were not developed with deterministic multicast routing in mind. Moreover, IP Networks are traditionally static in nature, not constantly being reconfigured to provide new deterministic routing paths for dynamically changing traffic flows. In essence, IT-based IP networks are based on a lot of assumptions about the way that data can and does flow – assuming particularly that it should expect TCP-based, low bandwidth streams where packet loss from congestion can be dealt with through restart and retransmission. ‘Best effort’ historically was always going to be enough in terms of Quality of Service (QoS), to meet the needs of IT-based IP deployments; because the nature of the data always meant that connectivity rather than QoS was the priority.

But that won’t work with media; a vastly different data beast – one that occupies a fairly constant high-bandwidth flow based on UDP protocol, and which absolutely cannot tolerate any packet loss at all. When it comes to media, the QoS demanded is absolute.

So, how to get IP – which in its IT usages had been geared towards the former data criteria, to deal adequately with these very different demands arising from media data? The answer is: with a bit of clever management – management that comes in the form of a Software Defined Network tool.

 

Before order, there was chaos (kind of)

Before we explain exactly how SDN takes the IT-centric structure of IP and makes it work for media data, let’s first look at what would occur with this data if it were left unmanaged. In essence, a traditionally designed IT network behaves like an autonomous system. That is, a traditional IT network makes any switching and routing decisions on its own without interference from any outside system or application. It provides a plug and play character. This is actually what makes Ethernet/IP networks so popular.

Network switches thus ‘auto-learn’ all the information they need from the passing traffic and from routing protocol exchanges between the switches themselves to make any forwarding or routing decision to send a packet through the network. The knowledge of what to do essentially comes from within the data as it moves. But since it moves in quite variable ways, it can be hard for the system to acquire any concrete knowledge: it has no ‘external’ awareness of bandwidth or the nature of an individual ‘flow’ (since it can think only in terms of sources).

The system therefore performs autonomously based on what is going on within it, in the moment. And that can certainly be very useful. But it also means that it lacks foresight, coordination or the ability to gaze into a crystal ball and anticipate how data demands might be about to fluctuate, and how they can be most effectively accommodated as a result.

 

This certainly can – and does – work in a great number of instances and applications; that’s why IP has been the network mechanism at the heart of all kinds of operations long before broadcast decided to jump on the bandwagon. But here’s the rub: the switches that sit at the heart of the whole operation aren’t born equal. A switch is not a switch. That’s because – returning to the point about best effort – CotS (Commercial-off-the-shelf) switches tend to be configured to achieve best effort, rather than ensure Quality of Service. And as we established above, absolute QoS is the lynchpin of moving media data properly.

 

So that means if you want the switches you already have to work for media, you’re going to have break them, tame them and train them to work in a way that suits media data better (OK, we’re being a bit dramatic here – they’re not lions. But it’s still quite the undertaking, from a technical standpoint. But it’s what we’re specialists at here at SDNsquare).

 

Taking control

The SDN concept is traditionally rather cryptically described as ‘separating the control plane from the data plane’. What this actually means is that it seeks to control the traffic-path by an external application. It overrides the autonomous decisions that would normally be taken in-the-moment based on the data that is flowing.

Simple, right?

Well as an idea – the idea of maintaining a holistic overview of the network and devolving (or perhaps, evolving?) control of the data from the nature of the data itself – sure, it’s simple. But you’ll be unsurprised to hear, achieving this division is a more complex and technical undertaking. We won’t bore you with the details of it here, but we do have quite a cool White Paper which explains it in more detail, if that’s your cup of tea.

Going with the flow

We must make a confession – SDN is not the only way to go about managing a network and avoiding the quasi-chaos that can come from allowing data to flow on the basis of autonomous, internally driven regulation. Open Flow is another option. Indeed, it’s often the solution that many are most familiar with.

In essence an early control mechanism, it was based upon the same principle as SDN in the sense that it sought to regulate the control of the data as a separate exercise to the data movement itself. Thus, Open Flow, the standard southbound protocol that is used between the SDN controller and the switch, essentially provides rule tables for switches to operate according to – giving them a set of instructions based on a specific set of occurrences. The rules (control) are separate from the data.

And that’s an important first step. We are grateful to Open Flow concepts for the groundwork they laid. But in the grand scheme of things, it’s still very primitive and there are some crucial things it can’t achieve. Firstly, it does nothing to deal with the absolute Quality of Service needs that sit at the heart of media data transfer. Secondly, it is entirely switch and switch vendor dependent, which means it’s cumbersome to implement and lacking in flexibility when there’s an infrastructure switch-up (excuse the pun). And finally, its scalability is limited to say the least.

 

And so, to the point…

This all brings us what SDNsquare GRID can do.

As with all SDNs, SDNsquare GRID is based on the same basic principle: it takes control from the outside, and it does so whilst avoiding all the pitfalls, problems and complexities we’ve talked about so far, when either IT-based, unmanaged IP networks or Open Flow controlled networks try to accommodate media data.

Basically, SDNsquare GRID has two distinct networking APIs: northbound and southbound. OpenFlow is only a southbound API.

First and foremost then, SDNsquare grid deals with the main need of media data; it prioritises QoS – meaning that things get where they’re meant to go, and turn up in the form they were meant to as a whole. Every. Single. Time.

More than this, SDNsquare’s GRID allows this to happen no matter how much you fiddle around with your network. Change switches, add auxiliary components, throw variable data demands at it; doesn’t matter, the SDN is adaptive, flexible, scalable and proactive in how it deals with the specific demands of media data.

This doesn’t just mean your network operates more reliably (though that’s a crucial benefit). It also means that it operates more efficiently, using switches and network components only when they’re needed. Lower energy consumption is both good for the business bottom line and the environment, with as much as 45% less energy consumption in studios that are operating on a 27/4 basis.

And perhaps most significantly – with SDNsquare, all of this is adaptable, flexible and scalable. New items on the network can be accommodated quickly, without fuss, and without compromise to the efficiency of data flows being achieved, across a vast range of existing network topologies and switch types GRID allows this all to be done intuitively – using a straight-forward, easy-to-use GUI and a number of comprehensive wizards and auto-configuration tools.

Moreover, the security of the network is ensured regardless of how it is expanded or adapted. In the case of live and remote production, with constantly changing network topologies that need to be added and subtracted from at a moment’s notice, and which must maintain absolute security in its communications with the central studio, this functionality is all vital.

It’s pretty clear, whichever way you look at it, GRID brings all of SDNsquare’s immense understanding of media flows over IP networks, and makes them easy to manage – driving efficiency, effectiveness, reliability, lowered costs, reduced maintenance, improved results and ultimately, a huge source of competitive advantage for those that implement it on their network.

 

Better something than nothing 

But you know what? If you don’t choose SDNsquare’s GRID in the end, we won’t mind. We won’t hold it against you. All we ask is that you analyse both your needs and objectives, and after researching the market you get to pick an SDN to manage your network. ANY SDN. Because our collective technological progress as IP practitioners is the thing that matters the most. Implementing best practice (and trust us, SDN GRID is best practice when it comes to managing IP networks) benefits us all. We’re all in it together.