This document aims to help the user in configuring network switches for operating in AES67 compliant environments when Barix audio devices are used in AES67 mode mixed or not with Dante compatible equipment.
For small networks where a limited amount of nodes (network devices interconnected) are deployed, traditional COTS switches might do the job, but for heavily loaded networks, where the traffic is shared with other equipment it's important to consider few adjustments that will ensure a smooth operation of your real-time audio over IP flow.
Initial Recommendations for Dante & AES67
For getting a stable audio transport among Dante and/or AES67 devices in a network, it is recommended that switches are:
- Managed - This means that they offer the user an interface to control their configuration, either through a web interface or through a console. Particularly when it comes to AES67 and Dante networks, it's important to tweak the following in a switch:
- Quality of Service - The ability from the switch to inspect the packet's headers and forward first those with a higher priority "ticket" namely: Time packets (PTP) and Audio packets (RTP)
- IGMP or Internet Group Management Protocol - The ability to "snoop" packets and forward them only to devices that joined the same multicast group
- Non-Blocking - Almost every switch nowadays is non blocking, meaning that all ports can run at full speed without loosing data packets. The switch can handle the total bandwidth on all ports, establishing routing to any free output port without interfering with other traffic
- Rated for Gigabit operations - It is not a strict requirement in small networks, where a Fast Ethernet switch could operate fine, but highly suggested for larger ones where traffic is shared among devices of different nature.
- Not Eco friendly - Most of the switches nowadays can operate in "Eco Mode" or "Green mode", saving energy. While this is very good for the planet, it is bad for AES67. The issue with these operational modes is that they save energy trying to "accumulate" more packets before sending them out to a port, this could create undesired delays for a stream that is assumed to be real-time.
Quality of Service: an in-depth look
AES67 and Dante operates in a way that their transmitters ( a device that is injecting a stream in the network ) add what are known as DSCP tags in the header of the packets.
What DSCP stands for?
Differentiated Service Code Points. It is a type of Quality of Service management that your switch should ideally allows you to modify to adjust the priority of the traffic fitting your needs. AES67 and Dante devices place a specific code in the header that the switch will read and, if the said DSCP code has been prioritized it will be forwarded to its destination before all other packets. Note that not all the managed switches out there support DSCP QoS managemen, some might support only other types of quality of services that will not do the job for setting up the DSCP tags accommodating AES67 and Dante requirements.
Below are the tables illustrating the DSCP tags used by Dante (1) and AES67 (2):
|DANTE QoS Management|
|IMPORTANCE||USAGE||DSCP CODE||DSCP N°|
|1- High||Clock Synchronization (PTP)||CS7||56|
|2- Medium||Audio Transport (RTP)||EF||46|
|4- None||Other Traffic||Best-Effort||0|
|AES67 QoS Management|
|IMPORTANCE||USAGE||DSCP CODE||DSCP N°|
|1- High||Clock Synchronization (PTP)||EF||46|
|2- Medium||Audio Transport (RTP)||AF41||34|
|3- None||Other Traffic||Best-Effort||0|
When mixing AES67 and Dante networks it is always better to use the configuration exposed in Table 1. What's important is that the clock synchronization packets always have the highest priority.
Example: switch QoS configuration
In the below screen it is shown how a D-Link DGS 1210 10P switch is configured to handle a Dante - AES67 mixed network, using its web interface.
Note the priority numbers assigned to the DSCP values (7 is the highest priority). The QoS mode is set to "DSCP".
While in the following screen the same configuration is done on a Cisco SG-300 10.
Again we can see the priority assignments (output queue) attached to the DSCP values (Ingress DSCP).
While all switches manufacturer have their own way of allowing to tweak the DSCP tags, there is not much difference between one or the other. Simply make sure to purchase a switch that offers DSCP QoS management mode.
An AES67 transmitter uses RTP Multicast to send the audio stream to one or multiple receivers. Dante on the other hand could support both Unicast and Multicast.
For getting the most out of your network configuration and don't waste bandwidth it is important that the switches used supports IGMP, or Internet Group Management Protocol. Briefly this is a communication protocol that is used to handle the membership of devices into specific multicast groups and that allows the switch to direct packets only to devices that requested them, thus only to devices part of the same multicast group.
IGMP Snooping is a feature supported by the switches that allows the "snooping" of the information related to the multicast transactions so that only the devices part of the same group are involved in the communication. Without this function any multicast packet reaching the switch will be broadcast to all ports, this could be an issue for those devices not capable of handling a high amount of incoming data packet.
For the purpose of a stable IGMP Snooping operation, an IGMP Snooping Querier must also be enabled. The aim of a querier is to keep the table with all the multicast group memberships up to date. It sends out IGMP queries on a timed interval to all members belonging to the IP multicast group. All devices wishing to remain in the group must reply to the query with a confirmation. Those devices that do not respond within a defined amount of time will be removed from the group’s table and will no longer be forwarded those multicast streams.
Below is an example of a D-Link DGS 1210 10P switch IGMP configuration. Note the querier state is Enabled.
The same switch allows the possibility to view the single multicast groups available and their members (port numbers).
NOTE: 18.104.22.168 is the multicast group used by Dante devices in AES67 mode to provide the Clock Synchronization through PTP. The Multicast group 22.214.171.124 is the known group used by Dante devices in AES67 mode to provide the RTP audio stream.
From the below example is clearly visible that the packets will flow only to the member ports that subscribed to that multicast group. This avoids flooding networks with packets and working in a more efficient environment.
When planning large AES67 and Dante systems is important to consider the network topology. Although daisy chaining might seem more suitable, long chains add more nodes from one end to the other, more nodes means more delay and a greater potential of loosing connection from a large number of devices (if one brakes all the others down the chain will loose connectivity). For this reason a "hub & spoke" or "star" configuration is recommended. This topology allows for easy expansion just by concatenating "stars" between them.