Designing IP Broadcast Systems: Routing

IP networks are wonderfully flexible, but this flexibility can be the cause of much frustration, especially when broadcasters must decide on a network topology.

To the untrained eye, it might appear that layer-3 routers and layer-2 switches achieve the same objectives, that is, to deliver IP packets to their destination. Although to be pedantic, layer-2 delivers frames which may or may not contain IP packets, and layer-3 delivers packets. These distinctions are important when we consider the underlying data link layer.

IP packets do not have their own data link layer, that is, the IP specification provides no inherent method of distributing an IP packet as no physical layer is specified, IP is purely a software protocol. To achieve delivery, we need a data link layer that transports the IP packet, and this is where the layer-2 frame comes into play. Although in many enterprise and broadcast applications the layer-2 frame is ethernet, it doesn’t have to be so and could equally be fiber or WIFI, or one of the many other layer-2 specifications.

In its physical sense, a computer network is where two or more computers are connected with one another with the intention of sharing data. In the broadcast and enterprise sense, networks are huge consisting of many interconnected layers.

When designing networks, we’re constantly balancing five requirements: data resilience, data throughput, latency, ease of access, and security. Increasing one often has a detrimental effect on the other. For example, increasing data resilience may have a negative effect on latency, and increasing ease of access may impact security. Consequently, there is no one-size-fits all and broadcasters must prioritize their needs during the design process.

For broadcast infrastructures layer-2 switches are at the core of any design and are configured in such a way to provide localized networks. It is possible to build an entire network using a spine-leaf topology that serves the complete infrastructure, and some broadcasters do this, but the costs involved may be prohibitive due to the size and complexity of the core switches. But even with spine-leaf, the network must be logically separated using VLANs to separate the complete network into sub-networks and improve security. Localized networks serving a single studio or other facility such as the editing suites may provide a better option, especially if the infrastructure is hybrid and needs to be transitioned to IP function by function.

Whether using spine-leaf or distributed topologies, all sub-networks need to communicate with each other. At the layer-2 level this becomes problematic as the broadcast messages needed to resolve the IP devices MAC address will soon have a detrimental impact on network congestion. Also, network security could be compromised as the network expands, and this is just within the broadcaster’s estate.

One solution is to use layer-3 routers as they allow networks to be connected together but improve security and reduce the possibility of congestion. And this is where the concept of routing becomes apparent.

Broadcasters should be using layer-2 managed switches as they significantly reduce network congestion and provide a single collision domain. When used in a point-to-point configuration, for example connecting a camera ST2110 video output to a switch port, then there should be no collisions and therefore no congestion. The managed switch determines the connected devices source MAC address when it receives layer-2 frames from the device and so can build a switching table. This table will have a list of all the known MAC addresses so the switch will efficiently switch on the layer-2 frames to the necessary ports.

Figure 1 – Connecting studio 1’s layer-2 spine-leaf network to studio 2’s layer-2 spine-leaf network requires a router to route any traffic between the two (solid line). However, the two spine-leaf networks can be connected together using a bridge (dashed line), but this will result in increased traffic and possible congestion due to the increased number of broadcast messages. Also, there is no extra security between the two networks when bridging layer-2, however, using the router will increase the level of security as the traffic can be filtered and managed.

Figure 1 – Connecting studio 1’s layer-2 spine-leaf network to studio 2’s layer-2 spine-leaf network requires a router to route any traffic between the two (solid line). However, the two spine-leaf networks can be connected together using a bridge (dashed line), but this will result in increased traffic and possible congestion due to the increased number of broadcast messages. Also, there is no extra security between the two networks when bridging layer-2, however, using the router will increase the level of security as the traffic can be filtered and managed.

Routers do not have the advantage of automatically knowing which devices are connected to their ports as there could be any number of multiple cascading routers all connecting different networks. It would be almost impossible for every device on the network to signal its existence to every other device. Therefore, a router must build its own routing table. And to achieve this, routers must exchange information between routers to advise each other of the potential routes available to the destination. These can either be built manually or automatically configured using protocols such as IGP (Interior Gateway Protocol) or BGP (Border Gateway Protocol).

To route traffic the public internet works on the principle of autonomous systems (a large network or group of networks that has a controllable and well defined and understood routing policy). Each of these autonomous systems (ASes) has knowledge of the other ASes but does not understand their network topology or routing policy. Connecting the ASes requires the BGP, and this provides the core of the internet. This is one of the reasons it’s so difficult to guarantee latency and bandwidth for internet routes as the AS you are connected to, which will probably be your ISP, has no knowledge of the inner workings of the other ASes that are needed to route through to get to the destination. The whole idea behind BGP is that the routing policies are advertised, that is the metrics and destinations, so that the AS can determine the fastest route to the destination (as there may be other AS options), but the inner workings and routings remain a secret. In other words, the internet can be thought of as a public connection of many private networks.

Although it’s important to be aware of the BGP, it’s rarely something broadcasters or users in general will get involved with at a studio and infrastructure level.

IGP on the other hand is used extensively within private enterprise networks to provide dynamic routing and automatic updating of the router’s tables. This is achieved using the next-hop method so that each router only needs visibility of the path to the next router in the chain. Each router measures the path distance and speed from the ports connected to the next router and then provides a metric that is advertised to the other routers through IGP. That way, each router determines the optimum path for the IP packet delivery. These routes are being constantly updated as new devices are added and removed. And if a router was to fail or a path becomes congested or broken, then IGP gives routers the opportunity to re-route the packets.

One of the challenges of dynamic routing, as provided by IGP, is that the latency of the link between the source and the destination becomes unpredictable. As the router tables are being updated, then the paths they define also change. Therefore, IGP and dynamic routing may not be the best option. Instead, manual entries into the routing table might be the best alternative. This presents a real challenge for network architects as the latency vs reliability decision comes into account. If manual entry into the routing tables is employed, then latency becomes much more predictable. However, the network potentially becomes less reliable as a broken path or router would need the network architect to update all the routes in the connected router tables, potentially causing many problems.

Manual routing may not be as arduous as it sounds as SDNs are effectively providing updates to the routing tables and this can be achieved automatically by the SDN controller. The SDN has a whole view over the network and will know, through its configuration, how to update tables to take into consideration broken or congested paths and failed routing devices. This hierarchy of automation will free manual intervention and maintain predictable latency and bandwidths. It’s entirely possible that the latency may change if the SDN controller must step in, but once the change has been made, the latency will once again become predictable.

You might also like...

AI In The Content Lifecycle: Part 2 - Gen AI In TV Production

This series takes a practical, no-hype look at the role of Generative AI technology in the various steps in the broadcast content lifecycle – from pre-production through production, post, delivery and in regulation/ethics. Here we examine how Generative AI is b…

Managing Paradigm Change

When disruptive technologies transform how we do things it can be a shock to the system that feels like sudden and sometimes daunting change – managing that change is a little easier when viewed through the lens of modular, incremental, and c…

AI In The Content Lifecycle: Part 1 - Pre-Production

This is the first of a new series taking a practical, no-hype look at the role of Generative AI technology in the various steps in the broadcast content lifecycle – from pre-production through production, post, delivery and in regulation/ethics. Here w…

Audio For Broadcast: Cloud Based Audio

With several industry leading audio vendors demonstrating milestone product releases based on new technology at the 2024 NAB Show, the evolution of cloud-based audio took a significant step forward. In light of these developments the article below replaces previously published content…

Designing IP Broadcast Systems: Why Can’t We Just Plug And Play?

Plug and play would be an ideal solution for IP broadcast workflows, however, this concept is not as straightforward as it may first seem.