AVB terms and definitions.

AVB terms and definitions.

What is gPTP and why is it important in an AVB network?

PTP  (Precision Time Protocol) is designed to synchronize clocks in a network with high precision, typically in the sub-microsecond range.    

gPTP, or Generalized Precision Time Protocol, is defined in IEEE standard 802.1AS-2011 which in turn defines a specific profile of IEEE 1588-2008 (PTPv2) with additional timing features which greatly improve timing accuracy and lock time.  So it is important to keep in mind that PtPv2 and gPTP are not the same.

For AVB, gPTP plays a crucial role in ensuring tight synchronization among networked audio devices. AVB relies on synchronized clocks across all devices to ensure that audio streams are transmitted and received without excessive jitter and latency or synchronization issues.

Here's how gPTP handles synchronization within an AVB network:

Clock Synchronization: gPTP enables all devices within the AVB network to synchronize their clocks to a common time reference. This synchronization ensures that all devices perceive time uniformly, allowing them to transmit and receive data packets precisely timed according to the network's timing domain.

Precise Timing Messages: gPTP facilitates the exchange of precise timing messages between devices to adjust their clocks and maintain synchronization. These messages include Sync messages, Follow-Up messages, Delay Request messages, and Delay Response messages which are exchanged between the devices in the network.

Best Master Clock Algorithm (BMCA): gPTP implements the BMCA to elect the Grandmaster Clock among all devices in the network that can act as a clock. The Grandmaster Clock provides the authoritative time reference for the entire network. BMCA takes in account factors such as clock accuracy, stability and priority to select the most suitable Grandmaster Clock on the network.

Where should the Grandmaster Clock be positioned in an AVB network?
It is good practice to place the Grandmaster clock as centrally as possible in your AVB network. So either a central switch should be the Grandmaster clock, or the Grandmaster Clock device should be connected directly to a central switch. This will limit the total propagation delay, a sum of the link delay between switches  and the resident times of each switch, and will also lead to a more uniform delay from the Grandmaster clock to each device in the network. The Grandmaster Clock device should also be a "stable" device in the sense that it is a permanent part of the network. Ideally, it should be equipped with redundant power supplies, as the loss of he Grandmaster clock can have serious consequences for the audio signal on the network.

What are streams, talkers and listeners on an AVB network?

AVB data traffic is Layer 2 multicast.
Audio data is combined in groups of 1 up to 64 channels per stream, depending on the AVB implementation. (1,2,4,6 or 8 channels per stream for AVB-Milan)
Up to 150 streams can be available on the network, the limitation being the network bandwidth.

In an AVB network a Talker is a device that act as the source for an AVB stream, sending out audio onto the network.
An AVB Listener is a device that is the destination for the streams sent out by the Talkers.
In practice, many devices can be both Talker and Listener at the same time.
An AVB Controller is a device that takes care of the routing, clock, and other settings for AVB devices using ATDECC. Most of the time this will be a separate computer, but this can also be integrated in a mixing console for example.
ATDECC stands for AVB/TSN Discovery, Enumeration, Connection management and Control. It defines operations to discover device addition and removal, retrieve device entity model, connect and disconnect streams, manage device and connection status, and remote control devices. (https://grouper.ieee.org/groups/1722/1/web/index.html)
Previously this was known as AVDECC  (Audio Video Discovery Enumeration Connection management and Control)
HIVE is an example of an ATDECC controller. It can be downloaded here : https://github.com/christophe-calmejane/Hive/releases
MILAN Manager is an ATDECC application developed by L'acoustics and D&B : Free Audio Application for Professional Sound Systems | Milan Manager (l-acoustics.com)

So what is the difference between AVB and Milan?

AVB is a broad set of technical standards developed by the IEEE 802.1 working group. It ensures synchronized, low-latency audio and video streaming over Ethernet networks. AVB does not inherently guarantee interoperability between different manufacturers’ devices.

Milan is a standards-based interoperability solution built on top of AVB technology. It was developed by the Avnu Alliance, a consortium of professional audio, video, and IT companies, mainly focused on professional audio applications such as concert sound systems, broadcast studios, and professional audio equipment. https://avnu.org/milan/
Milan focusses on the following features :  

Interoperability: Milan ensures interoperability between devices from different manufacturers by defining a clear set of requirements and a certification process.
Deterministic Network: Provides guaranteed performance with predictable latency, essential for professional audio/video production.
Ease of Use: Designed to be more user-friendly with plug-and-play functionality, reducing the complexity of network setup.

What is MSRP and how does is work?

In an AVB network, Multiple Stream Reservation Protocol (MSRP) is used as a key mechanism to allow endpoints (Talkers, Listeners) to reserve network resources (bandwidth) to guarantee the transmission of the data streams on the network with the necessary Quality Of Service. AVB will reserve up to a maximum of 75% of the available bandwidth to leave enough space for other protocols.

The MSRP protocol operates in the following sequence:

1.    Advertise stream from Talkers and allow Listeners to discover an register to these streams.

2.    Establishes a path through between a Talker and one or more Listeners

3.    Calculate the worst-case latency

4.    Create an AVB media clock domain

5.    Reserve the bandwidth for the stream

The sum of the worst-case latencies per hop (in most cases a switch is a hop) should result in an overall talker to listener latency of maximum 2ms for SR-Class A and maximum 50ms for SR-Class B. Typically, an AVB setup with a maximum of 7 hops (for 100Mbps networks) or 13 hops (for 1Gbps networks) from talker to listener will stay below these latency requirements.

Based on the worst-case latency targets of the traffic from talker to listener, AVB defines Class A and Class B as time-sensitive streams. On an outbound queue, credit based traffic shaping is used to shape the sending of these streams matching with the bandwidth that has been reserved to reach the targeted latency.
The credit based traffic shaping also protects the "best effort" traffic on the network from being starved by AVB traffic. However, sufficient bandwidth is still needed when combining AVB with other protocols on the network.

What is MVRP?

Multiple VLAN Registration Protocol (MVRP)  is a Layer 2 messaging protocol that automates the creation and management of virtual LANs.
AVB capable switches will automatically assign ports to a dedicated VLAN (VLAN 2 by default, so VLAN id 2 should not be used on a switch that is also being used for AVB).

AVB and redundancy.

Setting up a network with a redundant trunk or redundant ring configuration will NOT produce a redundant AVB setup. As an interruption in the redundant path might lead to a topology change that in turn causes the MSRP to define a new optimal path. This could take a few seconds.
To ensure true redundancy, the AVB audio devices should have a primary and secondary ethernet interface, each in turn connected to a completely separate network, resulting in a true A/B redundant network setup. The primary/secondary redundancy failover upon loss on one of the interfaces will be managed in the AVB audio device.

Talker Failed
When a Talker Advertise for some reason cannot propagate on the network, it will change to Talker Failed with an error code which corresponds to an error message that can be found in the table below. 
Code      Description of cause
1 Insufficient bandwidth
2 Insufficient Bridge resources
3 Insufficient bandwidth for traffic class
4 StreamID in use by another Talker
5 Stream destination address already in use
6 Stream preempted by higher rank
7 Reported latency has changed
8 Egress Port is not AVB capable a
9 Use a different destination address (i.e. MAC DA hash table full)
10 Out of MSRP resources
11 Out of MMRP resources
12 Cannot store destination_address (i.e. Bridge is out of MAC DA resources)
13 Requested priority is not an SR Class (3.262) priority
14 MaxFrameSize is too large for media
15 msrpMaxFaninPorts limit has been reached
16 Changes in FirstValue, other than AccumulatedLatency, for a registered StreamID
17 VLAN is blocked or filtered on this egress Port
18 VLAN tagging is disabled on this egress Port (untagged set)
19 SR class priority mismatch
20 Enhanced feature cannot be propagated to original Port
21 MaxLatency exceeded
22 Nearest Bridge cannot provide network identification for stream transformation
23 Stream transformation not supported
24 Stream identification type not supported for stream transformation
25 Enhanced feature cannot be supported without a CNC





    • Related Articles

    • AVB / Milan

      GigaCore switches support AVB / Milan. In the current firmware versions (as of writing: GigaCore v1.4.1 of gen2 and GigaCore v3.1.0 for gen1), AVB is enabled by default on all ports. Enabling AVB on GigaCore To enable AVB on second generation ...
    • MILAN stream format

      As many of you already know, the MILAN standard uses a specific AVB stream format in order to facilitate interoperability. Here is a link to a document from MILAN lisiting the specifications of that stream format. ...
    • Using AVB on Luminex Switches - New GigaCore line

      No additional service charges or licenses are required to enable the AVB feature-set. This article applies to the following models : GigaCore 10i GigaCore 10t GigaCore 16i GigaCore 16t GigaCore 18t GigaCore 20t GigaCore 30i Prerequisites Luminex ...
    • Using AVB on Luminex Switches - Original GigaCore line

      Luminex GigaCore switches are Avnu Certified with firmware version 2.8.0 and later. All GigaCore switches, including legacy devices already installed in the field, will be capable of receiving this firmware update. No additional service charges or ...
    • QoS : DSCP Mapping Table

        AVB Enabled       AVB Disabled       DSCP/Class   Queue   DSCP/Class   Queue   AVB Class A   7           AVB Class B   6           gPTP   5         MRP 63   4 63   7 62   4 62   7 61   4 61   7 60   4 60   7 59   4 59   7 58   4 58   7 57   4 57   ...