ECMP Load Balancing

Load-balancing takes IP network efficiency to a higher level as it allows the packets between a source and destination to be routed evenly between two or more hops. For example, if Hop-A and Hop-B for a flow with the same IP source and destination addresses both had the same routing metric, then the router, using ECMP could send alternate packets between the two links, in effect balancing the load of the flow over two different links. This is a major advantage for IP networks as not only is there inbuilt resilience in the network, but the packets are balanced throughout the network so that greater efficiency can be achieved.

Combining multicasting, ECMP and the router’s ability to measure UDP/IP flows (as well as other protocols), an improved version of multicasting emerges. Multicast load balancing can be achieved with ECMP built into the routers; however, the protocols are tuned to operate with TCP/IP as this is the dominant protocol in enterprise networks and the internet. Broadcasters favor UDP/IP, but the ECMP algorithms are often sub-optimal, so a better solution is required, and this has been provided by Cisco and their NBM (Non-Blocking Multicast).

Introducing NBM

In the case of video and audio streaming across IP networks, the option of providing NBM greatly improves data throughput and reduces latency. For example, four video servers each sending a 12Gbps UHD video stream, and 200Mbps of audio and metadata, all going to the same destination router via the same core router with three 40G links between them, could easily find that all the video flows are routed across one 40G link, thus flooding it and causing congestion, while the other two 40G links are significantly under-utilized. In the case of the PIM ECMP multicast, the router has no knowledge of the datarate of the video, audio, and metadata flows and effectively treats them equally as they have the same IP source and destination addresses. Adding NBM fixes this as it does have knowledge of the datarate of the individual flows, even if the IP source and address destinations are the same, so is able to balance them across the three 40G links so that link oversubscription does not occur. NBM is bandwidth aware.

One of the challenges broadcasters face with bandwidth aware systems is that it implies a certain amount of reliance on a specific vendors solution. NBM is proprietary to Cisco, however it is backwards compatible with PIM/ECMP and has an open API that provides an interface to NBM.

Justification For Proprietary Solutions

Broadcasters often try and avoid vendor lock-in, and to a certain extent this is to be applauded. But the world is far from perfect and if a vendor does provide a solution that solves a specific problem, then it should certainly be considered. To truly understand why broadcasters avoid vendor lock-in then we must scratch below the surface of our assumptions.

When broadcasters were transitioning from analog to SDI, understanding how specific products worked was challenging but achievable, even more so when the product needed to be integrated into the mission critical workflow of a broadcast facility. Custom control proved difficult to achieve but Systems Integrators often extracted enough information from vendors allowing them to build the necessary interface, or even reverse-engineering protocols.

This may have been the situation during the analog-to-SDI revolution, where circuit switched networks were relatively easy to document and understand, but the new IP packet switched networks are completely different.

Networks have at their core advanced statistical methods to route and optimize IP flows, to incorporate resilience, and keep latency low. Many of the inner workings of the routing algorithms have been the result of multiple PhD theses and deep academic research. It’s quite unreasonable to expect the average broadcast engineer to understand the inner workings of a complex routing and load balancing algorithm. Just measuring the datarate in a router relies on using sampling and estimation techniques based on advanced probability concepts.

Broadcast engineers need to focus on their core skills, that is, delivering video, audio, and metadata to enhance the immersive experience for the viewer, not be bogged down with determining, measuring, and estimating uncertainty in a network to reduce latency as the huge R&D departments from vendors such as Cisco have already done this. Consequently, there is a place for vendor specific products in the broadcast industry.

Treating subcomponents in a system as a black box often fills the average systems engineer with dread due to the lack of visibility of how it operates. However, this does not need to be the case, especially if all the necessary information is provided using opensource interfaces, or in the case of a network controller, an API. Well designed and documented opensource RESTful APIs solve many problems and challenges. If an engineer can fathom everything they need to from the API, then understanding the complexities of the underlying algorithms becomes irrelevant.

NBM Integration

NBM can operate in both active and passive mode. As NBM brings bandwidth awareness to PIM, it can use active mode to achieve load balancing for the flows and make sure that all the paths are fully utilized so that over subscription is avoided. In the NBM active mode, the responsibility of bandwidth management and network utilization is with the switches themselves. However, in passive mode, the open API is exposed providing all the networks link and flow metrics and establishing a gateway for switching information from the SDN controller.

Using open APIs such as the one designed by Cisco for NBM abstracts a level of configuration away from the broadcast engineers. They no longer need to get involved with CLI configuration or reach for the calculator to rapidly do their bandwidth sums every time a new route is required. Interoperability is not only possible with open APIs, but it is embraced by the vendors so that third-party integration is now a seamless reality.

The opportunities for third party integration and SDN control are colossal. Through the API, a control system can have full top-down visibility of the entire network, all it’s connected devices, and the flow bandwidth of every stream.

Using open APIs such as the one designed by Cisco for NBM abstracts a level of configuration away from the broadcast engineers. They no longer need to get involved with CLI configuration or reach for the calculator to rapidly do their bandwidth sums every time a new route is required. Interoperability is not only possible with opensource APIs, but it is embraced by the vendors so that third-party integration is now a seamless reality.

Building on this, advanced monitoring and packet switching systems that meet the very special needs of broadcasters can be provided, especially when looking at high-bandwidth continuous flows with the associated PTP timing characteristics. The opensource API combined with NBM provides a level of systems integration that allows broadcasters to now look at the detail of their IP network operation to expose the kind of visibility they have become accustomed to with SDI and AES.