Skip to main content

Can Ethernet SRP Support Production?

Wes Simpson

Audio Video Bridging technology is being considered for use in high-performance Ethernet networks as a potential replacement for SDI video infrastructure in the studio. The standards that make up AVB cover precision timing, end-to-end system performance and queue management within network devices.

Of these, one of the most important is the Stream Reservation Protocol, which provides a way for devices to allocate dedicated bandwidth across Layer 2 networks. SRP potentially could play a role in the upcoming reference architecture discussions of the Joint Task Force on Networked Media, a working group formed by the Video Services Forum, SMPTE and the EBU.

The main benefit of SRP is ensuring that a path with enough bandwidth is available along the entire path from a Talker (source) to a Listener (destination) through one or more Bridges (Ethernet switches). The bandwidth is then reserved for the exclusive use of that video/audio stream in each network segment along the route, to prevent it from being used by other signals. SRP streams are further restricted to flow only over the negotiated pathways, thereby protecting the rest of the network from being flooded by unneeded streams. SRP uses a series of messages sent both upstream and downstream to distribute information about each stream and confirm availability of the bandwidth before the stream begins to flow. To enable SRP, all of the Talkers and Bridges in a network must support the protocol, although there are some provisions to work with non-SRP Listeners.

Fig. 1: SRP process showing success (Listener A) and failure (Listener B). Talkers are responsible for creating advertisement messages about the streams that they can generate. These messages are propagated through the network to inform Listeners and Bridges about the available streams, including data about the amount of bandwidth required by the stream, the stream’s priority/rank, and the Stream ID. Talkers are also responsible for generating streams once the appropriate messages have been exchanged and the paths have been configured.

Listeners can request to receive any of the streams that are advertised, even if there is not enough bandwidth to receive the stream. Listener requests are propagated back to Talkers, which only will send streams to Listeners that have adequate bandwidth paths available.

Bridges look at messages from both Talkers and Listeners to determine if adequate bandwidth exists on their input and output ports, as well as through their switch fabric. If bandwidth is available, Talker Advertise and Listener Ready messages are propagated upstream and downstream. If bandwidth is lacking, failure messages are sent out in both directions. One key aspect of SRP is that bandwidth is only reserved when an end-to-end path exists and a stream is actually going to flow.

Fig.1 shows the SRP process in action for a single Talker and two Listeners. The Talker begins by sending out a Talker Advertise message (1). Bridge 1 has enough bandwidth to accommodate the request, and passes Talker Advertise message (2) along to two output ports. Listener A sends a Listener Ready message (3) back towards the Talker, indicating that it wants the stream.

Meanwhile, Bridge 2 does not have enough bandwidth to handle the stream (4) and forwards a Talker Failed message via its output (5). When Listener B receives the Talker Failed message, it sends out Listener Asking Failed message (6) towards the Talker because it wants the stream but did not get a valid Talker Advertise message. Bridge 2 propagates the Listener Asking Failed message (7) back towards the Talker. Bridge 1 sees both the Listener Ready Message (from A) and the Listener Asking Failed (from B) and creates a Listener Ready Failed message (8) to send towards the Talker.

In addition, Bridge 1 allocates bandwidth between its input that is connected towards the talker and its output connected towards Listener A. When the Talker receives the Listener Ready Failed message, it knows that at least one listener (in this case, A) is ready to receive the stream, and that all of the Bridges between the Talker and the Listener (in this case Bridge 1) have reserved bandwidth adequate to handle the stream. So, the Talker will therefore proceed to send out the stream (9) towards the Listener.

One crucial aspect of SRP is that any bandwidth that is allocated to streams is not available for other “Best Efforts” traffic. Thus, it is considered good practice to avoid allocating all of a link’s bandwidth, with one recommendation to limit SRP to 75 percent of each link’s total capacity, leaving 25 percent available for best efforts traffic. If this rule of thumb was followed for uncompressed video streams, a 10 Gig Ethernet link would only be able to carry two 1080p59.94 signals, and no more than five 720p or 1080i streams.

SRP is a key element of the Audio/ Video Bridging protocol set, which is being viewed as a potential solution to support video production over an Ethernet studio network. SRP has been shown to work well for professional audio over Gigabit Ethernet, which makes sense when considering that a single GigE link can support hundreds of uncompressed audio signals. Given the much higher bandwidths employed for video signals, larger capacity Ethernet systems—40 or 100 Gig—will most likely be required. Also, most Ethernet switches on the market today do not support SRP and the other AVB protocols. Another practical issue to be considered is the amount of time required to set up and tear down SRP paths, which can be several milliseconds, making real-time video switching difficult.

Overall, SRP is a well-defined protocol that is already beginning to penetrate the pro audio market. As Ethernet link bandwidths increase and more broadcasters look to migrate to all-IP infrastructure, SRP could potentially play a role in studios of the future.

Wes Simpson is an industry consultant and author of “Video Over IP, Second Edition,” from Focal Press. Your comments are welcome Thanks to Rob Milner of ARG ElectroDesign for his helpful comments.