Networking

Video: Deterministic Video Switching in IP Networks

Posted on by Russell Trafford-Jones

The broadcast industry spent a lot of time getting synchronous cuts working in analogue and SDI. Now IP is being used more and more, there’s a question to be asked about whether video switching should be done in the network itself or at the video level within the receiver. Carl Ostrom from the VSF talks us through the pros and cons of video switching within the network itself along with Brad Gilmer

First off, switching video at a precise point within the stream is known as ‘deterministic switching’. The industry has become used to solid-state crosspoint switching which can be precisely timed so that the switch happens within the vertical blanking interval of the video providing a hitless switch. This isn’t a hitless switch in the meaning of SMPTE ST 2022-7 which allows kit to switch from one identical stream to another to deal with packet loss, this is switching between two different streams with, typically, different content. With the move to ST 2110, we have the option of changing the destination of packets on the fly which can achieve this same switching with the benefit of saving bandwidth. For a receiving device to do a perfect switch, it would need to be receiving both the original video and next video simultaneously, doubling the incoming bandwidth. Not only does this increase the bandwidth, but it can also lead to uneven bandwidth.

 

 

Carl’s open question to the webinar attendees is whether network switching is needed and invites Thomas Edwards from the audience to speak. Thomas has previously done a lot of work proposing switching techniques and has also demonstrated that the P4 programming language for switches can actually successfully manipulate SMPTE ST 2110 traffic in real-time as seen in this demo. Thomas comments that bandwidth within networks built for 2110 doesn’t seem to a problem so subscribing to two streams is working well. We hear further comments regarding network-based switching and complexity. possibly also driving up the costs of the switches themselves. Make before break can also be a simpler technology to fault find when a problem occurs.

Watch now!
Speakers

Carl Ostrom Carl Ostrom
Vice President,
VSF
Brad Gilmer Brad Gilmer
Executive Director, Video Services Forum
Executive Director, Advanced Media Workflow Association (AMWA)

Video: The Future Impact of Moore’s Law on Networking

Posted on by Russell Trafford-Jones

Many feel that Moore’s law has lost its way when it comes to CPUs since we’re no longer seeing a doubling of chip density every two years. This change is tied to the difficulty in shrinking transistors even more when their size is already close to some of the limits imposed by physics. In the networking world, transistors are bigger so which is allowing significant growth in bandwidth to continue. In recent years we have tracked the rise of 1GbE which made way for 10GbE, 40GbE and 100 Gigabit networking. We’re now seeing general availability of 400Gb with 800Gb firmly on the near-term roadmaps as computation within SFPs and switches increases.

In this presentation, Arista’s Robert Welch and Andy Bechtolsheim, explain how the 400GbE interfaces are made up, give insight into 800GbE and talks about deployment possibilities for 400GbE both now and in the near future harnessing in-built multiplexing. It’s important to realise that high capacity links we’re used to today of 100GbE or above are delivered by combining multiple lower-bandwidth ethernet links, known as lanes. 4x25GbE gives a 100GbE interface and 8x50GbE lanes provides 400GbE. The route to 800GbE is, then to increase the number of lanes or bump the speed of the lanes. The latter is the chosen route with 8x100GbE in the works for 2022/2023.

 

 

One downside of using lanes is that you will often need to break these out into individual fibres which is inconvenient and damages cost savings. Robert outlines the work being done to bring wavelength multiplexing (DWDM) into SFPs so that multiple wavelengths down one fibre are used rather than multiple fibres. This allows a single fibre pair to be used, much simplifying cabling and maintaining compatibility with the existing infrastructure. DWDM is very powerful as it can deliver 800GB over distances of over 5000km or 1.6TB for 1000km, It also allows you to have full-bandwidth interconnects between switches. Long haul SFPs with DWDM built in are called OSFP-LS transceivers.

Cost per bit is the religion at play here with the hyperscalers keenly buying into the 400Gb technology because this is only twice-, not four-, times the price of the 100Gb technology it’s replacing. The same is true of 800Gb. The new interfaces will run the ASICs faster and so will need to dissipate more heat. This has led to two longer form factors, the OSFP and QSFP-DD. The OSFP is a little larger than the QSFP but an adaptor can be used to maintain QSFP-form factor compatibility.

Andy explains that 800Gb Ethernet has been finished by the Ethernet Technology Alliance and is going into 51,2t silicon which will allow channels of native 800Gb capacity. This is somewhat in the future, though and Andy says that in the way 25G has worked well for us the last 5 years, 100gig is where the focus is for the next 5. Andy goes on to look at what future 800G chassis might loo like saying that in 2U you would expect 64 800G OSFP interfaces which could provide 128 400G outputs or 512 100G outputs with no co-packaged optics required.

Watch now!
Speakers

Robert Welch Robert Welch
Technical Solutions Lead,
Arista
Andy Bechtolsheim Andy Bechtolsheim
Chairman, Chief Development Officer and Co-Founder,
Arista Networks

Video: PTP Over Wan

Posted on by Russell Trafford-Jones

Work is ongoing in the IPMX project to reduce SMPTE ST 2110’s reliance on PTP, but the reality is that PTP is currently necessary for digital audio systems as well as for most ST 2110 workflows. There are certainly challenges in deploying PTP from an architectural standpoint with some established best practices, but these are only useful when you have the PTP signal itself. For the times when you don’t have a local PTP clock, delivery over a WAN may be your only solution. With PTP’s standards not written with a WAN in mind, can this be done and what are the problems?

 

 

Meinberg’s Daniel Boldt describes the work he’s been involved with in testing PTP delivery over Wide Area Networks (WANs) which are known for having higher, more variable latency than Local Area Networks (LANs) which are usually better managed with low latency which users can interrogate to understand exactly how traffic is moving and configure it to behave as needed. One aspect that Daniel focuses on today is Packet Delay Variation (PDV) which is a term that describes the difference in time between the packets which arrive the soonest and those that arrive last. For accurate timing, we would prefer overall latency to be very low and for each packet to take the same amount of time to arrive. In real networks, this isn’t what happens as there are queuing delays in network equipment depending on how busy the device is both in general and on the specific port being used for the traffic. These delays vary from second to second as well as throughout the day. Asymmetry can develop between send and receive paths meaning packets in one direction take half the time to arrive than those in the other. Finally, path switching can create sudden step changes in path latency.

Boundary Clocks and Transparent Clocks can resolve some of this as they take in to account the delays through switches. Over the internet, however, these just don’t exist so your options are to either build your own WAN using dark fibre or to deal with these problems at the remote site. If you are able to have a clock at the remote site, you could use the local GNSS-locked clock with the WAN as a backup feed to help when GNSS reception isn’t available. But when that’s not possible due to cost, space or inability to rack an antenna, something more clever is needed.

Lucky Packet Filter
Source: Meinberg

The ‘lucky packet filter’ is a way of cleaning up the timing packets. Typically, PTP timing packets will arrive between 8 and 16 times a second, each one stamped with the time it was sent. When received, its propagation time can be easily calculated and put in a buffer. The filter can look at the statistics then throw away any packets which took a long time to arrive. Effectively this helps select for those packets which had the least interference through the network. Packets which got held a long time are not useful for calculating the typical propagation time of packets so it makes sense to discard them. In a three-day-long test, Meinberg used a higher transmit rate of 64 packets per second saw the filter reduced jitter from 100 microseconds to an offset variation of 5 microseconds. When this was fed into a high-quality clock filter, the final jitter was only 300ns which was well within the 500ns requirement of ST 2059-2 used for SMPTE ST 2110.

Daniel concludes the video by showing the results of a test with WDR where a PTP Slave gateway device was fed with 16 packets a second from a master PTP switch over the WAN. The lucky packet filter produced a timing signal within 500ns and after going through an asymmetry step detection process in the clock produced a signal with an accuracy of no more than 100ns.

Watch now!
Speaker

Daniel Boldt Daniel Boldt
Meinberg

Video: Proper Network Designs and Considerations for SMPTE ST-2110

Posted on by Russell Trafford-Jones

Networks from SMPTE ST 2110 systems can be fairly simple, but the simplicity achieved hides a whole heap of careful considerations. By asking the right questions at the outset, a flexible, scalable network can be built with relative ease.

“No two networks are the same” cautions Robert Welch from Arista as he introduces the questions he asks at the beginning of the designs for a network to carry professional media such as uncompressed audio and video. His thinking focusses on the network interfaces (NICs) of the devices: How many are there? Which receive PTP? Which are for management and how do you want out-of-band/ILO access managed? All of these answers then feed into the workflows that are needed influencing how the rest of the network is created. The philosophy is to work backwards from the end-nodes that receive the network traffic.

Robert then shows how these answers influence the different networks at play. For resilience, it’s common to have two separate networks at work sending the same media to each end node. Each node then uses ST 2022-7 to find the packets it needs from both networks. This isn’t always possible as there are some devices which only have one interface or simply don’t have -7 support. Sometimes equipment has two management interfaces, so that can feed into the network design.

PTP is an essential service for professional media networks, so Robert discusses some aspects of implementation. When you have two networks delivering the same media simultaneously, they will both need PTP. For resilience, a network should operate with at least two Grand Masters – and usually, two is the best number. Ideally, your two media networks will have no connection between them except for PTP whereby the amber network can benefit from the PTP from the blue network’s grandmaster. Robert explains how to make this link a pure PTP-only link, stopping it from leaking other information between networks.

Multicast is a vital technology for 2110 media production, so Robert looks at its incarnation at both layer 2 and layer 3. With layer 2, multicast is handled using multicast MAC addresses. It works well with snooping and a querier except when it comes to scaling up to a large network or when using a number of switches. Robert explains that this because all multicast traffic needs to be sent through the rendez-vous point. If you would like more detail on this, check out Arista’s Gerard Phillips’ talk on network architecture.

Looking at JT-NM TR-1001, the guidelines outlining the best practices for deploying 2110 and associated technologies, Robert explains that multicast routing at layer 3 works much increases stability, enables resiliency and scalability. He also takes a close look at the difference between ‘all source’ multicasting supported by IGMP version 2 and the ability to filter for only specific sources using IGMP version 3.

Finishing off, Robert talks about the difficulties in scaling PTP since all the replies/requests go into the same multicast group which means that as the network scales, so does the traffic on that multicast group. This can be a problem for lower-end gear which needs to process and reject a lot of traffic.

Watch now!
Speaker

Robert Welch Robert Welch
Technical Solutions Lead
Arista Networks