Skip to main content

AIMS IP Oktoberfest: How to Plan and Deploy a SMPTE ST 2110 Network

(Image credit: SMPTE)

To move forward with the design and deployment of a SMPTE ST 2110 network, Robert Welch, technical solutions lead at Arista, has a simple piece of advice: work backwards.

“Try to figure out what you are trying to do with it [the network], and then go in reverse,” said Welch during his “Proper Network Design and Considerations for SMPTE ST 2110” presentation, the final session at the virtual AIMS (Alliance for IP Media Solutions) IP Oktoberfest 2020.

Asking questions up front is the key to succeeding. “I want to understand what’s going on because I am building the network based on the end nodes, not the other way around,” he said. “You don’t decide the network first and then figure out what to do with it.”

Robert Welch

Robert Welch (Image credit: Arista)

During his 30-minute presentation, Welch examined a variety of questions that must be answered. The first set of questions pertained to determining the connectivity requirements of end nodes, including whether there is an out-of-band management interface, whether there is a specific interface for control or multiple interfaces—if the latter, do they share the same IP address, and which interface or interfaces is PTP (Precision Time Protocol) on?

”As a network architect, what you are trying to do is reduce constraints—constraints in learning, constraints in bandwidth, constraints in deployment [and] constraints in knowledge,” he said.

Welch also discussed non-blocking and blocking architectures, beginning with a description of spine-leaf network architecture.

“The spine is typically just an interchange,” he said. “So it’s really just a connect between the other leafs. Or, do you connect other high-bandwidth devices to it? This is one of those decisions you have to make.”

Drilling down into the details, Welch talked about PTP and doing it right to keep it protected. “It is the most valued transport that you have,” he said.

When architecting a network, do not “link routes from blue to amber or amber to blue,” he explained. “You don’t want the PTP-only links to carry the multicast streams, or even control or monitoring, things like that” he said.

Welch laid out a couple of ways to keep PTP separate, including creating an unused VLAN with no traffic other than PTP as well as making it a routing interface without an IP address.

Another practice to avoid is “overflowing your bandwidth,” and Welch illustrated the point with an example based on the Imagine SNP (Selenio Network Processor) with two 100 Gb/s ports.

“For every 100 Gig link.. go[ing] to a leaf, I’m going to need 100 Gig link going to a spine. In fact, I would venture to say if I had four links of 100 Gig, I would need five or more links between these leafs and the spine,” he said.

This approach is very costly and amounts to oversubscribing. It also raises the question of why there’s a non-blocking fabric in play at all, he said.

“You want everything [in the network] being active and use what you have, OK?” he said. “And not worry about the constraints.”

One solution is thinking about the spine-leaf being internal to the switch. “The switch has multiple network processors—or ASICs—on it, and internal to it is a fabric,” he said.

(Image credit: AIMS)

“There’s two types of fabric. There’s one that’s more crossbar-oriented where flows can get pinned, and there’s another type that turns each individual flow into multiple cells. It breaks it up so you’re not using the entire fabric.”

“What you want to do as an architect is figure out what the flows are and can you do line-break flows of 100 Gig and multiple 100 Gigs using one architecture or the other,” he explained.

For the network architect, it’s necessary to think about capacity, node connectivity and constraints up front to avoid overflow, he said.

Welch also discussed the difference between the three types of network traffic: unicast—one-to-one initiated by a client and connected to a service; broadcast—one-to-everything on the VLAN; and multicast—one-to-“wherever you want do the join,” he said.

“This is where it [multicast] comes in,” he said. “You could have a transmitter that doesn’t have a receiver until it’s needed—like the output of multiple cameras.”

However, without a querier and querier IP address, what results is “flooding,” said Welch. “Your multicast becomes a flood.”

In essence, the multicast becomes a broadcast without a querier and querier IP address on the switch, he added.

Understanding the different types of multicast is also important to being able to figure out how to diagnose problems that may arise, he explained.

Welch recommended network architects make wise choices about network typology, understand end node requirements from “a physical, logical and flow perspective” as well as a security perspective, and the holistic aspect of architecting the network up front.

“If you do that, and do that well, you are going to be a hero and make people happy,” he concluded.