Skip to content

AES67 and the Sienda TSN Stack

Abstract

Sienda and users of the Sienda Stack have identified a need for products in the ProAV space to support both AVB/Milan and AES67. Reasons include:

  • interoperability with AES67 compatible devices
  • less reliance on suppliers of particular AES67 compatible components
  • de-risking transition from 'over-IP' solutions to AVB/Milan

The hardware requirements for an AES67 device are generally quite similar to that of an AVB device, so most AVB devices using the Sienda Stack would be able to support AES67 with just a firmware update. (There are some considerations however, noted later.)

With this in mind, Sienda would like to add AES67 support to the Sienda Stack. This document details the evaluation phase already completed, and the next steps.

Evaluation

An evaluation study has already been undertaken, to determine the technical requirements for adding AES67 support, estimate of work, and possible considerations for customers wishing to utilise the AES67 addition in their products. The results of this evaluation are detailed below.

Software additions to the Stack

AES67 support will be added to the stack in two stages, the second of which will only be completed if/when required by a customer:

  • implement required modifications to allow AES67 compliant streams to traverse and egress AVB networks
  • if required, add support for SIP, SAP, DHCP, ARP, and PTPv2 to increase interoperability and so that AES67 may function on non-AVB networks

A note on PTP

The AES67 standard specifies (section 4.0) that:

Synchronization of a common clock shall be achieved using IEEE 1588-2008 Precision Time Protocol (PTP).

[snip]

Devices, with the exception of certain AVB devices (see below), shall support the IEEE 1588-2008 default profiles. Devices supporting the default profiles shall use IPv4 encapsulation as described in IEEE 1588-2008 annex D. As a single exception, devices that use the AVB synchronization mechanism described in 4.3, and that need to be connected to an AVB network in order to accomplish media streaming, are not required to implement the IEEE 1588-2008 default profiles.

Section 4.3 and annex D then go on to describe how AVB devices may use 802.1AS instead of PTPv2 default or Media profile. With this in mind, Sienda plan to offer (initially) AES67 compatibility using the existing 802.1AS (gPTP) implementation. This is fully compliant with the AES67 spec and is allowed for AVB devices, but does have the requirement that users of AES67 products based on the Sienda Stack will, in the first instance, still have to use 'AVB switches' (or other switches supporting 802.1AS). This is not anticipated to be a major problem as most of these devices will primarily be AVB/Milan devices and will run on an AVB network, but it should be noted that such an AVB device cannot be connected directly (or via a non-AVB network) to an AES67 device, as the two devices will be talking a different variants of PTP and will not sync. It should also be noted that if AES67 interoperability between an AVB device and non-AVB AES67 device is required, there must be PTP/gPTP bridge on the network. In many networks this may be an infrastructure bridge/switch which supports both PTP and gPTP and can present itself as GrandLeader through both PTP variants.


If a customer has a requirement for supporting PTPv2 then we may consider implementing a PTPv2 service in the Stack at a later date.

AES67 (de)packetiser

It is relatively trivial to add a AES67 packetiser and depacketiser to the stack. The de(packetiser) will work with both 125uS 'packet time' (AES67 parlance), and the default 1ms packet time. When using 1ms packet time, the packetiser will append 125uS (the AVB class A interval) of samples to the in-memory packet, and every 8 intervals (125uS * 8 = 1ms) the packet will be dispatched. On the listener side, the depacketiser will run whenever a valid AES67 packet is received. It is worth noting that packetising AES67 packets will load the CPU/MPU core about the same as an equivalent AVB stream, but depacketising AES67 packets with 1ms packet time will result in a slightly different CPU loading, as each AES67 packet will contain eight times as much audio data to be marshalled (but will be processed with 1/8 of the frequency). This is not anticipated to cause any major problems on most systems, but low power devices that are already running near 100% cpu load may not be able to handle as many AES67 streams as they can AVB streams (particularly if they are simultaneously streaming AVB streams). On the other hand, with a 1ms packet time, there is less work for the ethernet subsystem to do, so in fact the overall CPU loading may be decreased. Only profiling on the target platform will reveal the true cost of streaming AES67 vs. AVB.

ATDECC Control of AES67 streams

AES67 specifies the streaming of audio packets, but does not specify any particular control mechanism for stream control or connection management other than suggesting that AES67 devices may use SIP (and curiously in section 10.1 that all receivers shall support SIP), but it's not known how many 'AES67' devices in the field actually support SIP, nor is it detailed in AES67 how SIP should be used. The omission of a requirement for senders to support SIP also makes SIP a rather incomplete solution for AES67 connection management. Furthermore, SIP (RFC3261) requires both UDP and TCP implementations, requiring that SIP devices support a full TCP/IP stack. As the Sienda Stack already has a robust and feature rich ATDECC implementation, it makes absolute sense to use ATDECC to configure and control AES67 streams.

ATDECC makes this easy as it already has the concept of vendor specific stream formats. Sienda will create a set of ATDECC vendor specific stream formats representing supported AES67 formats. The Sienda tsnControllerLibrary (and any controller based on it such as the Sienda cliController) will be able to enumerate devices supporting AES67 streams, configure stream endpoints to use AES67, and start and stop those streams.

The AES67 specification makes mention of VLAN membership for AES67 streams, and also of the possibility of using MSRP and MVRP on AVB networks to reserve bandwidth for AES67 streams, but since no known shipping AES67 devices support this, this will not be implemented. It is expected that if users wish to take advantage of AVB networks, they will simply use AVB streams instead of AES67 streams. If in the future use-cases arise for sending AES67 streams over AVB networks (for example, sending a stream across an AVB network which is then destined for routing across a non-AVB segment or the internet) then the Stack can be modified to support this later.

IGMP and SAP

IGMPv2 or IGMPv3 (version tbd) will be implemented to ensure that AES67 streams reach the listener devices. As IGMP is a direct IP protocol (no TCP required) it fits well with the architecture of the stack. When an AES67 listener (receiver) stream is started, IGMP will be activated for the stream instead of MSRP (which would be used for an AVB listener stream).

The Session Announcement Protocol (SAP) would be a nice feature to have for AES67 talker (sender) streams, as this would announce the stream (session) to other devices and controllers supporting SAP. The AES67 streams would appear (for example) in the VLC media player, and AES67 controllers and devices utilising SAP would become aware of the stream and could start listening to it. As a UDP protocol this could integrate seamlessly with the Stack without requiring TCP/IP.

Session Initiation Protocol

The Session Initiation Protocol (SIP) is stated as a requirement of AES67 for receiver devices. This poses a problem, as SIP specifies operation over both UDP and TCP. Sienda aim to keep TCP out of the stack for as long as possible, as it's not required for any AVB protocol, nor the majority of the AES67 standard. As there is no de-facto AES67 controller (in fact the term 'AES67 controller' is somewhat an oxymoron as AES67 doesn't detail control mechanisms in the same way that AVB does), it is not currently deemed important to support SIP. Therefore, SIP will NOT be implemented in the first stage, and feedback will be obtained from customers and users during the rollout as to whether it's required at all in the future.

mDNS-SD

mDNS and DNS-SD support would be another nice feature, so that the devices could be discovered by DNS-SD. This will not be implemented in the first stage, but will be considered for future work.

Curiously, none of the protocols required for the first stage of AES67 implementation (IGMP, SAP, multicast streaming) need an IP address to function, as the device itself will never be addressed by its IP address. (All the protocols are multicast). It is however bad practice to send an IP packet with an invalid source IP address, and so some means of (auto)configuring the IP address of each device is required. ATDECC provides a IP address control, which can be used to manually assign a static IP address via controller software, and this will be implemented. For the case where manual static IP address configuration is not desired, DHCP and/or link-local auto addressing must be supported. It is uncertain yet whether DHCP, ARP and link-local address selection will be implemented directly in the stack, or via an existing library such as lwIP. Some customers may already have (or plan to have) a lwIP or other TCP/IP stack in their products, so it may be more appropriate to leave IP address allocation out of the Sienda stack and provide instead an API method for the device to pass an IP address into the Sienda stack. Feedback on this is welcome.

Implementation Details

During the course of adding AES67 to the Sienda Stack some implementation objectives must be met:

  • the Stack must optionally support AES67, as a build time configuration. This is important to ensure that the library size increase does not impact memory constrained AVB devices. Customers currently using the Stack can rest assured that if they don't require the AES67 features, then a library build will still be available without the extra bloat.
  • the layer 2 packet API will remain for as long as possible. The objective is to keep TCP/IP out of the stack. The code and runtime memory requirements of a full TCP/IP stack would overflow the memory budgets of some constrained AVB devices.

Hardware considerations

While AVB and AES67 share many requirements in terms of hardware support, there are a couple of notable differences.

Memory requirements

AVB listener devices are required to provide 2ms of audio buffering. The low latency guarantees and 125uS transmit interval of AVB mean that 2ms is sufficient. In contrast AES67 uses a default 'packet time' (transmit interval) of 1ms, and as these packets may have very sloppy transmit timing and have no guarantee of arrival time the receiver buffering requirements are much greater. The AES67 specification states:

Receivers shall have a buffer capacity at least 3 times the packet time. Receivers should have a buffer capacity at least 20 times the packet time or 20 ms whichever is smaller.

We can take this to mean that AES67 devices using a 1ms packet time must have 3ms buffering (50% greater than AVB) but should have 20ms (10 times greater than similar AVB devices). This may pose a problem if currently shipping AVB devices with memory constraints wish to additionally support AES67.

Marvell 88e series PTP modes

Many shipping AVB devices utilise the Marvell 88e series of ethernet switch ICs, either to increase port count, or to provide PTP and/or 802.1Q traffic shaping features to SoCs/MCUs that have no such support. All Marvell 88e ICs which can support AVB can also support AES67, but they cannot reliably support both variants of PTP (gPTP and PTPv2) on the same port at the same time. There is a configuration setting 'Trans Spec' to select between timestamping of ieee1588 or 802.1AS frames, and while this can be disabled on some 88e parts (via DisTSpecCheck bit) there are not enough rx or tx timestamp registers to capture both gPTP and PTPv2 frames at the same time. Due to the nature of PTP it is highly likely that arriving gPTP sync messages would be correlated with arriving PTPv2 frames, and so there is a high chance that the timestamps from one PTP variant would overwrite the timestamps from the other variant causing one of the variants to fail. This condition could be identified (by disabling timestamp overwriting and checking the dropped timestamps counters) but no standards compliant recovery could be made.

The outcome of this is that while the Sienda Stack may in the future support ieee1588 (PTPv2) as well as 802.1AS (gPTP), Marvell hardware may restrict supporting this in devices. It should be possible to support gPTP on some ports and PTPv2 on other ports. This would allow (for example) a PTP bridging device to be created, or a multi port device supporting AES67 on some ports and AVB on other ports. But supporting gPTP and PTPv2 simultaneously on the same port in devices depending on the 88e for hardware timestamping is not going to work.

If a design incorporates an 88e and a PTP capable SoC/MCU then it may be possible to support gPTP on the 88e, and PTPv2 on the SoC. This would be complex as host port packets are usually DSA tagged and so the SoC would have to be able to identify and timestamp DSA tagged PTP packets, possibly from multiple ports. This is outside the scope of the Sienda Stack, but the PTP API to the Stack should not prohibit this should a stack licensee wish to try.

Implementation steps and time estimates

Sienda will undertake the development of AES67 features according to the following plan:

  • create vendor unique AVB stream formats for AES67 stream formats
  • provide IP address configuration control via ATDECC entity model, and IP address setter via API for devices already supporting IP
  • implement AES67 packetisation and depacketisation
  • update the Controller Library and cliController application to support the new AES67 stream formats and the IP address control
  • adjust connection management (ACMP) to detach MVRP and MSRP, so streams start immediately and don't declare or wait for MSRP attribute registration
  • implement IGMP and tie it into ACMP for AES67 streams.

At this stage, AES67 should be functional.

Further optional steps:

  • implement SAP, SIP and/or mDNS-SD
  • implement PTPv2
  • implement ARP and DHCP

This work is currently being carried out as back-burner project, meaning that it is being fitted around client projects. Sienda is currently very busy with client projects and so there is no ETA on this work being completed. If any particular client(s) has an urgent requirement for AES67 then please contact Sienda about the possibly of supporting this development.