Designing IP Broadcast Systems: Addressing & Packet Delivery

How layer-3 and layer-2 addresses work together to deliver data link layer packets and frames across networks to improve efficiency and reduce congestion.

When IP first made its appearance in the guise of the internet in homes in the 1990’s, making the modem connections operate reliably was no easy task. But as technology progressed, then so did the ease with which internet connectivity could be established. And these experiences are not too different from where the broadcast industry is now.

Traditional SDI and AES broadcast networks provide point-to-point connectivity that guarantees bandwidth and latency, the disadvantage of these circuits is that they are fixed and don’t easily lend themselves to scalability. But they are relatively easy to design, configure and fault find should a failure occur. Routing the signals requires a circuit switched fabric that is managed by a software controller where the source and destination information is provided by the engineer or technician operating the system.

By contrast, IP networks distribute and multiplex packets of data that automatically route within the network based on the source and destination addresses in the packet header. There are some important differences in terminology between broadcast and IT as routing in IT strictly means routing layer-3 packets, whereas switching in IT refers to switching layer-2 frames. The discrepancy occurs because IP packets are data link agnostic, that is, they can travel over any data link, such as ethernet, Wi-Fi and HDLC, whereas a layer-2 data link is fixed for a specific domain.  An ethernet frame can only natively traverse an ethernet network and not a Wi-Fi or HDLC.

A fundamental difference between layer-2 and layer-3 is defined by the bounds of the network. A layer-2 ethernet network is one which shares the same broadcast address.  This is a specific address (hex value - FF:FF:FF:FF:FF:FF) that is received by all devices on the network. If a device on network segment 1 sends a broadcast message, then all devices on segment 1 will receive it. If a device on ethernet segment 2 needs to receive this message, then it must be joined by an ethernet (layer-2) bridge. In this case, when the device on segment 1 sends a broadcast message, then all devices on segment 1 and segment 2 will receive the message. It soon becomes clear that a layer-2 network could easily become congested with broadcast messages, hence the reason layer-2 networks are segmented using domains and VLANs.

If a layer-2 network can switch packets between different networks then this begs the question, why bother with IP? Why not just switch all data frames in the layer-2 domain? This can and is achieved using networks such as AVB (Audio Video Bridging) IEEE 802.1BA1-2011. As layer-2 switching is fast, then the latency is much lower, however, the size of the network is restricted, and this is especially important when sending data to external networks as the broadcaster has no or little control over them.

Every ethernet connected device has a specific MAC address issued by the IEEE so frame address ghosting should be impossible. This means that a broadcaster employing a layer-2 network in their operation can be certain that if they send data frames from a camera at an OB to the studio production switcher, then the ethernet MAC addresses will be unique so no address translation is needed. The challenges occur when we look at the data link between the OB and the production switcher in the studio. It’s entirely possible that the broadcaster may have commissioned a layer-2 data link, but it’s also possible that the link may be satellite, microwave or fiber etc., in other words, the data link is not layer-2, so protocol and even hardware layer conversion will need to be performed, and this will probably result in the loss of the original MAC address information, which may well require the implementation of a custom protocol – which is exactly what we don’t want as this will remove the flexibility that provided the original motivation to moving to IP.

By using IP (layer-3) then connectivity between remote devices becomes much easier and provides greater flexibility when choosing data link connectivity. As IP datagrams are data link agnostic, the underlying MAC addresses will change, but this doesn’t matter from the point of view of the sender. For example, if an IP video stream is sent from the camera at the OB to the production switcher in the studio, then the connectivity in the OB and studio will usually be ethernet, but the intermediate link may well be a fiber link. The IP datagram has a source and destination IP address, and as the IP datagram leaves the camera it has a source and destination MAC address associated with it, where the IP source address will be the IP address of the camera, and the IP destination address will be the IP address of the production switcher in the studio. The router transferring the camera IP datagrams to the link is known as a gateway and will have a MAC address for each port, so the destination MAC layer-2 address of the camera will be the MAC port address of the gateway. The gateway will then remove the ethernet frame wrapper and add the wrapper of the data link it is connected to. When the OB cameras IP datagram reaches the studio, the studio gateway will remove the data links wrapper and add another ethernet wrapper specific to the studio. The ethernet frames source MAC address will be that of the studio gateway port and the destination MAC address will be that of the production switcher.

Figure 1 –  When a camera sends its IP datagram to the production switcher, the production switchers IP address will be known, but its MAC address will not. The OB Gateway provides a destination MAC address for the camera IP datagram so the OB Gateway will receive the ethernet frame (containing the camera IP datagram) and forward it across the data link to the Studio Gateway, which in turn changes the destination MAC address in the ethernet frame to that of the production switcher. The IP addresses do not change (assuming there is no address network translation – NAT), but the MAC addresses do.

Figure 1 – When a camera sends its IP datagram to the production switcher, the production switchers IP address will be known, but its MAC address will not. The OB Gateway provides a destination MAC address for the camera IP datagram so the OB Gateway will receive the ethernet frame (containing the camera IP datagram) and forward it across the data link to the Studio Gateway, which in turn changes the destination MAC address in the ethernet frame to that of the production switcher. The IP addresses do not change (assuming there is no address network translation – NAT), but the MAC addresses do.

The action of adding and removing the data link frame wrappers, and the adding and removing the ethernet MAC addresses is relatively straightforward and automated. Protocols such as ARP (Address Resolution Protocol) allows a sending device, such as the camera, to determine the receivers MAC address (it already knows its own MAC address, and hence the source MAC address, as this is set in the factory). The act of sending an ARP message requires the setting of the destination MAC address in the ARP message to the ethernet broadcast message (hex - FF:FF:FF:FF:FF:FF) so that all devices in the network will receive it. The ARP message effectively asks “who has the MAC address for the device with IP address nnn?” and the device with this IP address will reply to the query with its MAC address, thus allowing the sender to populate the destination MAC address. In the case of the camera at the OB, when it issues an ARP request “who has the IP address of the production switcher in the studio?”, the OB gateway will respond as it has been configured by the system administrator to “know” (via the gateways forwarding tables and subnets) that it is a route, or gateway, to the studio’s production switcher and will respond with its own MAC address, thus providing the camera with a layer-2 local destination.

Routers and gateways are similar in that they both link different networks together, but gateways differ as they often act as layer-2 protocol conversion devices. In the camera OB and production switcher example, the gateway will be used to convert from ethernet to fiber at the perimeter of the OB and studio’s networks. Linking networks together within a facility employing the same layer-2 transport mechanism, e.g., ethernet, can be achieved using a layer-2 bridge, but using a router separates the network’s so broadcast messages are not exchanged between the network segments thus reducing congestion, and this further provides levels of security so that networks can be physically separated.

Although this example assumes a unicast method, multicast follows a similar pattern as the ARP broadcast message identifies the ports of the layer-2 switches for delivery of the streamed video and audio IP packets.

This mapping between the layer-3 IP datagram and the layer-2 ethernet frame is the fundamental method of operation for all devices connected to home and enterprise networks and allows layer-3 IP datagrams to be transferred on any layer-2 data link (not just ethernet). The difference being that they often employ a system called DHCP (Dynamic Host Control Protocol) where the IP addresses are dynamically allocated to the computer or mobile device as it is presented to the network. This method could also be employed in broadcast facilities but for now we mainly statically allocate IP addresses to keep things simple.

All this layer-3 packet routing, layer-2 frame switching and protocol MAC address changing is going on in broadcast IP networks, but the IP address configuration requires manual intervention. This both improves reliability and keeps systems secure, but as we progress on our IP journey then these systems will be automated like the automation in enterprise and home networks.

Part of a series supported by

You might also like...

The Big Guide To OTT: Part 10 - Monetization & ROI

Part 10 of The Big Guide To OTT features four articles which tackle the key topic of how to monetize OTT content. The articles discuss addressable advertising, (re)bundling, sports fan engagement and content piracy.

Video Quality: Part 2 - Streaming Video Quality Progress

We continue our mini-series about Video Quality, with a discussion of the challenges of streaming video quality. Despite vast improvements, continued proliferation in video streaming, coupled with ever rising consumer expectations, means that meeting quality demands is almost like an…

2024 BEITC Update: ATSC 3.0 Broadcast Positioning Systems

Move over, WWV and GPS. New information about Broadcast Positioning Systems presented at BEITC 2024 provides insight into work on a crucial, common view OTA, highly precision, public time reference that ATSC 3.0 broadcasters can easily provide.

Next-Gen 5G Contribution: Part 2 - MEC & The Disruptive Potential Of 5G

The migration of the core network functionality of 5G to virtualized or cloud-native infrastructure opens up new capabilities like MEC which have the potential to disrupt current approaches to remote production contribution networks.

The Streaming Tsunami: Securing Universal Service Delivery For Public Service Broadcasters (Part 3)

Like all Media companies, Public Service Broadcasters (PSBs) have three core activities to focus on: producing content, distributing content, and understanding (i.e., to monetize) content consumption. In these areas, where are the best opportunities for intra-PSB collaboration as we…