The AES67 standard is sometimes misunderstood as the specifications on how all professional digital audio gear is supposed to work and interconnect. In fact, AES67 simply defines the requirements for high-performance AoIP (Audio-over-IP) interoperability. A manufacturer can implement AES67 anyway they see fit.
AES67 is a standard for high-performance audio-over-IP interoperability. When a manufacturer follows the standards definitions and requirements, devices that adhere to other AoIP protocols that do not interoperate with each other (i.e. Dante, Livewire, QLAN or RAVENNA) can become interoperable.
AES67 is designed to run on standard packet switching networks over a COTS (Commercial Off-The-Shelf) infrastructure. If configured properly, the same network can be shared with other traffic without degrading the audio streaming performance.
AES67 builds on these fundamental principles:
2-Multicast packet transport
3-Quality of Service
While other AoIP solutions offer enhanced functionality, such as stream and device discovery, GPIO transport, among others, AES67 has deliberately not defined any requirements in this respect, because they are not required to establish interoperability at the most basic level. Furthermore, various industry standards covering these functions already exist or are emerging and can be implemented if applicable.
The first fundamental principles are Synchronization, network synchronization is based on distribution of a common wall clock time to all participating nodes with sufficient precision. AES67 specifies that the IEEE1588-2008 standard (also known as PTPv2 - Precision Time Protocol version 2) be used for time distribution. PTPv2 includes a Best Master Clock Algorithm (BMCA), which ensures that the best available master clock is elected to serve as the Grandmaster for all participating AES67 nodes.
Once a node is synchronized to the wall clock time served by the Grandmaster, any desired media clock can be generated locally. If the synchronization precision is accurate enough, all locally generated media clocks will have the same frequency (i.e. 48 kHz) and they may even be accurately phase-locked to each other. Part 2 of this series will examine system planning with tips on how the Grandmaster selection process can be modified, if required.
With PTP it is possible to achieve accuracy in the sub-microseconds range (deviation of local clock with respect to the Grandmaster). However, in most cases this requires the deployment of PTP
aware switches. Fortunately, for most audio applications, single-digit microsecond accuracy is good enough, which usually is achievable with standard, non-PTP-aware switches.
The second fundamental principle is Multicast packet transport. AES67 requires multicast support for audio stream packets. While basically any Commercial Off-The-Shelf switches supports multicast traffic, only managed switches provide multicast management to effectively avoid network flooding. Unmanaged switches, or improperly configured managed switches, will treat multicast traffic like broadcast traffic, forwarding any incoming multicast packet to all switch ports. With high levels of audio stream traffic this will result in network flooding causing a total network lock-up.
Managed switches provide multicast management through IGMP (Internet Group Management Protocol) snooping support. With IGMP snooping, only those multicast packets that have been registered through IGMP are forwarded to their designated ports. Consequently, all AES67 nodes are required to support IGMPv2, which is used to tell the network which streams are to be forwarded.
The IGMP (join) requests need to be updated periodically to maintain the multicast forwarding. This is ensured by enabling the IGMP querier function in one of the participating switches. The periodic IGMP queries trigger the nodes to renew their IGMP requests. Once a stream connection is ended, an IGMP leave request is sent to terminate a multicast flow to that node.
One of the benefits of managed multicast traffic is its scalability. Any multicast flow is only sent once by a sender into the network. If more than one receiver requests the same flow, the network switches will clone packets as required. With IGMP, the network inherently optimizes the traffic, so that a multicast flow will be present just once on any involved link.
Quality of Service (QoS) is the third fundamental principle the AES67 network must support. Again, this is only available with managed switches. Proper QoS configuration ensures that the most critical packets – PTP and audio stream traffic – receive prioritized forwarding on their way through the network. AES67 mandates support of Differentiated Services (DiffServ), a QoS scheme where different types of traffic can be categorized into service classes. DiffServ works with 64 different priority tags – DSCP values – that can be applied to individual IP packets.
AES67 supports QoS parameters. Even so, proper utilization requires the use of DiffServ and priority tags to make this happen.
End nodes can apply different tags to packets belonging to different traffic classes; switches can then examine the individual priority tags and forward packets on a preferred basis. Put simply, with DiffServ a network resembles the boarding procedure at airports. Priority passengers (first and business class) board the plane first (and at any time), while economy class passengers have to wait in line as long as priority passengers are still queuing up.
However, while recommendations exist in the standards on how to assign DSCP values to certain types of traffic, a network administrator is free to configure these values according to the individual application requirements. In larger networks that may carry a variety of shared traffic classes, QoS configuration requires special attention.
AES67 requires the use of three traffic classes and recommends certain DSCP values:
PTP traffic should be tagged with DSCP EF (48), translating into expedited forwarding, receiving the highest forwarding priority (first class passengers)
RTP traffic (audio packets) should be tagged with AF41 (34), translating into advanced forwarding with the second-highest forwarding priority (business class passengers)
All remaining traffic should have lower or no specific priority tagging, which by default which is BE (0) for best effort (economy class)
Because the network may be used to transport other types of traffic that needs certain prioritization, (i.e. voice data or video), the network administrator may have to change these values or adjust the switch configuration accordingly. Because not all AES67 devices support DSCP reconfiguration, or even don't use the recommended default values, other strategies may need to be applied.
One of the benefits of managed multicast traffic is its scalability.
To connect to an available stream and process its audio data, a node needs technical information about the stream. This is called session description data (SDP). It contains the multicast address of the stream, the encoding format and packet set-up (i.e. bits per sample, sampling frequency, number of channels in stream, number of samples in packet) and its relationship to the reference time. Without this information, a receiver cannot connect to the stream and decode the packet.
While AES67 clearly defines any required SDP attribute and their allowed parameter ranges, it is silent on the required method to convey this information. Session discovery (which would allow for system-inherent detection of available streams) has also been deliberately excluded from the standard requirements. While several protocols exist to announce available streams and transport the related SDP data, the creators of the AES67 standard felt that it would have been too stringent to mandate a specific method. Instead, the standard writers decided to just mention some of the widely used protocols and to leave it to the device manufacturer to select a method that works for them.
While most devices support mDNS/RTSP * (the default RAVENNA method) and SAP (Dante devices in AES67 mode), not all devices support both methods, and some don’t even offer manual read-out/ SDP data entry. In cases where there is no common method of sharing the required SDP information between two devices, stream connection set-up may be impossible or at least very difficult.
*(In computer networking, the multicast Domain Name System (mDNS), also known as Bonjour, resolves host names to IP addresses within small networks that do not include a local name server. Real Time Streaming Protocol is used to establish and control media sessions between end points.)
Please follow the link below for the AES Web-page for the AES67 Publication: