Audio Video Bridging for IE9300

PDF

Audio Video Bridging for IE9300

Introduction to audio video bridging networks

Want to summarize with AI?

Log in

Explains how Audio Video Bridging (AVB) networks enable synchronized, reliable transmission of audio and video streams over Ethernet. These networks utilize specific IEEE standards to ensure high-quality media delivery.


This document provides an overview of the fundamental concepts and standards governing Audio Video Bridging (AVB) network operations.


Audio video bridging

Audio and video bridging (AVB) is an IEEE 802.1BA standard that

  • enables high-quality audio and video streaming over Ethernet for both consumer and professional applications,

  • allows endpoints and network equipment to operate together for interoperable deployments, and

  • replaces traditional analog single-purpose point to point one way, simplifying cabling and network management.

AVB deployment requirements and limitations

AVB deployments have specific requirements and limitations:

  • AVB is supported on SKUs running Network Advantage license.

  • AVB is supported on a total of 16 ports (12 downlinks and 4 uplinks) and on an STP enabled network.

  • Currently, AVB operates only with MSTP and RSTP.

  • AVB is supported only when the MTU is set to 1500. AVB is not supported when the MTU is configured higher than 1500 or in SD-Access deployments.

  • All switches between the talkers and listeners must be AVB aware for the MSRP streams to be established.

  • MVRP is an optional protocol, but it is recommended because it automatically manages the VLANs across all AVB nodes.

  • The switch supports a maximum of 256 streams; the exact number is limited by a bandwidth reservation of 75 percent on each port.

  • AVB Class-A and Class-B reservations occur on a first-come, first-served basis. If a Class-B reservation occurs when bandwidth is limited, and a Class-A request comes later, the Class-A reservation is rejected.

  • The PTPv1 clock must be in forward mode if it is in use.

AVB is not supported for these configurations:

  • On 2.5-gigabit (multi-gigabit) ports.

  • On ports where copper SFP is used.

  • Not supported with interface speed of 10 or 100 Mbps.

  • On stacked systems.

  • On Port-Channel interfaces.

  • Does not interoperate with redundancy protocols such as REP, PRP, and others.


Audio video bridging supported platforms

AVB is supported on the Network Advantage license.

Table 1. Supported platforms for AVB:

PID ID

Product ID

No. of ports * Speed

Downlinks

AVB support

1

IE-9310-26S2C

1G SFP/ 4 ports/ 25 - 28

1G SFP/ 22 ports / 1 - 22

Yes. First 12 downlink ports and 4 uplink ports.

1G Combo/ 2 ports / 23 -24

2

IE-9320-26S2C

1G SFP/4 X 1Gig SFP (Ports 25-28)

1G SFP/ 20 ports / 1 - 20

No AVB Support.

1G SFP/ 2 ports / 21- 22

1G Combo/ 2 ports / 23-24

3

IE-9320-22S2C4X

10G SFP+/ 4 X 10 Gig SFP/ 25 - 28

1G SFP/ 22 ports / 1 - 22

No AVB Support.

1G Combo/ 2 ports / 23 -24

4

IE-9320-24T4X

10G SFP+/ 4 ports/ 25 - 28

1G Copper/24 port/1-24

Yes. First 12 downlink ports and 4 uplink ports.

5

IE-9320-24P4X

10G SFP+/ 4 ports/ 25 - 28

1G Copper/24 port/1-24

Yes. First 12 downlink ports and 4 uplink ports.

6

IE-9320-16P8U4X

10G SFP+/ 4 ports/ 25 - 28

1G Copper/16 port/1-16

Yes. First 12 downlink ports and 4 uplink ports.

2.5G Copper/8 port/17-24

No support on multi-gigabit ports.

7

IE-9320-24P4S

1G SFP/ 4 ports/ 25 - 28

1G Copper/24 port/1-24

Yes. First 12 downlink ports and 4 uplink ports.


Audio video bridging benefits

Audio video bridging benefits are advantages of a mechanism that enables Ethernet based audio-video transmission with

  • guaranteed maximum latency

  • time synchronized operations

  • bandwidth guaranteed transmission, and

  • professional-grade quality.


Components of audio video bridging network

An Audio Video Bridging (AVB) network is a communication system that

  • operates only in domains where every device is AVB capable

  • comprises AVB talkers, AVB listeners, AVB switches, and the grandmaster clock source, and

  • provides deterministic streaming of audio and video data using IEEE 802.1 AVB standards.

AVB network component types

The AVB network consists of four primary component types:

  • AVB Talker: An AVB end station that is the source or producer of a stream. Examples include microphones and video cameras.

  • AVB Listener: An AVB end station that is the destination or consumer of a stream. Examples include speakers and video screens.

  • AVB Switch: An Ethernet switch that complies with IEEE 802.1 AVB standards (IE-9300).

  • AVB stream: A data stream associated with a stream reservation compliant with the Stream Reservation Protocol (SRP).

    Note

    In some instances, the word bridge is used. In this context, it refers to a switch.

The IEEE 802.1BA specification requires that an AVB talker must be grandmaster capable. In a typical deployment a network node can also be the grandmaster, provided it can either source or derive timing from a grandmaster capable device and provide the timing to the AVB network using IEEE 802.1AS.

AVB network configurations

This figure shows a simple illustration of AVB network with different components.

Figure 1. AVB network

AVB Network

In many instances, the audio or video end points (Microphone, speaker, and so on) are analog devices. AVB end-point vendors introduce Digital Signal Processors (DSP) and I/O devices that provide extensive audio or video processing and aggregate the end-points into an AVB Ethernet interface, as illustrated in the figure.

Figure 2. Vendor audio I/O system



Generalized precision time protocol

Generalized Precision Time Protocol (gPTP) is an IEEE 802.1AS standard that

  • provides a mechanism to synchronize clocks of the bridges and endpoint devices in an AVB network,

  • defines the mechanism to elect the grandmaster clock (using the Best Master Clock Algorithm, or BMCA) among time-aware bridges, talkers, and listeners, and

  • establishes a timing hierarchy where the grandmaster distributes time to downstream nodes to enable synchronization.

gPTP synchronization process

Time synchronization requires determining the link delay and switch delays in the network nodes. A gPTP switch is an IEEE 1588 boundary clock, which also determines the link delay using the peer-to-peer delay mechanism. The delays computed are included in the correction field of the PTP messages and relayed to the endpoints. Devices such as talkers and listeners use this gPTP time as a shared clock reference to relay and recover media clocks. Currently, gPTP defines only domain 0, which is what supported switches use.

The peer-to-peer delay mechanism operates even on STP-blocked ports, although other PTP messages are not sent over blocked ports.

In a PTP domain, the BMCA organizes clocks and ports hierarchically, assigning the following roles:

Clocks:

  • Grandmaster GM or Grandmaster Clock (GM or GMC)

  • Boundary Clock (BC)

Port states:

  • Master (M)

  • Slave (S)

  • Passive (P)


Multiple stream reservation protocol

Multiple Stream Reservation Protocol (MSRP) is a network protocol that

  • provides a mechanism that allows end stations to reserve network resources. These resources guarantee the transmission and reception of data streams across a network with the requested QoS.

  • serves as one of the core protocols required on an AVB device, such as a talker, listener, or switch

  • allows talkers to advertise streams across a network of AVB switches and listeners to register for receiving the streams.

MSRP functions

MSRP is the key software protocol module for supporting AVB. This protocol enables stream establishment and teardown and provides the following functions:

  • Interfaces with gPTP to update the latency information for the streams.

  • Interfaces with the QoS module to set up the hardware resources that would guarantee requested bandwidth for the streams.

  • Provides the QoS shaping parameters required for the credit-based shaper.


Functions of multiple stream reservation protocol

MSRP performs these functions:

  • Allows talkers to advertise streams and listeners to discover and register for streams.

  • Establishes a path through an Ethernet between a talker and one or more listeners.

  • Provides guaranteed bandwidth for AVB streams.

  • Guarantees an upper bound on latency.

  • Discovers and reports the worst-case end-to-end latency between the talker and each of its listeners.

  • Reports failure reason and location when a path between the talker and a listener cannot satisfy bandwidth requirements.

  • Supports multiple classes of traffic with different latency targets.

  • Protects best effort traffic from starvation by limiting AVB traffic.

  • MSRP does not forward Talker declarations along STP blocked ports. When an STP TCN notification occurs, MSRP generates declarations to tear down, change, or set up streams.


Hierarchical QoS

Hierarchical QoS is a two-level parent-child policy framework that

  • segregates audio and video traffic streams (SR-Class A, SR-Class B) and network control packets from standard best-effort Ethernet traffic (Non-SR),

  • provides granular traffic management at multiple policy levels, and

  • allows parent classes to shape multiple queues in child policies while applying specific actions on aggregate and class-specific traffic.

AVB stream classes and latency targets

AVB networks guarantee bandwidth and minimum bounded latency for the time-sensitive audio and video streams. AVB defines Class A and Class B as the time-sensitive streams, based on the worst-case latency targets of the traffic from talker to listener.

The latency targets for the two streams are as follows:

  • SR-Class A: 2 milliseconds

  • SR-Class B: 50 milliseconds

The sum of the worst-case latency contributions per hop should result in an overall end-to-end latency of 2 milliseconds or less for SR-Class A and 50 milliseconds or less for SR-Class B. A typical AVB deployment of 7 hops from talker to listener meets these latency requirements.

The priority code points map the traffic to the specific stream. Frame forwarding behavior is based on this priority. A credit-based shaper is used to shape the transmission of these streams in accordance with the bandwidth that has been reserved on a given outbound queue so that the latency targets are met.

You can use hierarchical policies to:

  • Allow a parent class to shape multiple queues in a child policy.

  • Apply specific policy map actions on the aggregate traffic.

  • Apply class-specific policy map actions.

You can modify only ingress and egress HQoS child policy's class-map and its actions using policy-map AVB-Output-Child-Policy and policy-map AVB-Input-Child-Policy command.

Note

You should not modify the PCP in child policy to map with the PCP configured in the Parent Policy, for example, SR Class A with CoS 3 and SR Class B with CoS 2.

Hierarchical policing

Hierarchical policing is supported on ingress and egress interfaces. Hierarchical QoS separates the SR and Non-SR class related rules into parent and child policies respectively. AVB SR classes are completely controlled by MSRP client and hence, parent policies containing SR class attributes are governed by MSRP. The end user has complete control over child policies which contain Non-SR class attributes and can modify only the child policies.

AVB HQoS child policies are user modifiable and NVGENed to preserve the configuration if user saves the configuration to the startup-config. As a result, AVB HQoS child policy configurations are retained even after a reload.


Multiple VLAN registration protocol

Multiple VLAN Registration Protocol (MVRP) is an application based on MRP that

  • provides a mechanism for dynamic maintenance of the contents of dynamic VLAN registration entries for each VLAN ID.

  • propagates VLAN information to other bridges, and

  • allows MVRP-aware devices to dynamically establish and update their knowledge of the set of VLAN IDs associated with VLANs that currently have active members.

MVRP implementation requirements

MVRP has specific implementation requirements based on the network context:

  • MVRP is mandatory on the talkers and the listeners from an AVB perspective.

  • On VLAN-aware switches, MVRP is required by IEEE 802.1Q, regardless of AVB.

  • You can implement AVB by manually configuring VLANs on the switches.

Note

VTP must be disabled or set to transparent mode for MVRP to function properly.