Once it's established that a device is an AVB talker, and that the port used to connect that to the rest of the network is AVB-capable, it's necessary to know if an AVB listener can be reached. The listener might be on another port on the same AVB bridge (Layer-2 switch) or it might be separated by two (or more) switches. This is where 802.1Qat comes in to play - it's the process by which the participating devices determine whether or not AVB connections can be made all the way from talker to listener. Stream Reservation Protocol (SRP) is used for this. A talker will send a "talker advertise" message, which includes QoS requirements (we'll talk about those a little later), a stream ID made up of the talker's MAC address, a talker-specific 16-bit ID, the MAC address of the listener (which implies that the talker knows all potential listeners before streams are established), and accumulated latency (how long it takes for messages to propagate between the talker and the bridge).
When an AVB bridge receives this advertisement, it checks to see whether or not the necessary requirements for the proposed stream are in fact available. If they are, then the talker advertisement is propagated outbound on the appropriate port. If they are not available, then a 'talker fail' message is sent back towards the originator. Included in that message will be a failure code along with an AVB bridge ID that will allow the higher-layer applications (that are using AVB to talk between devices) to know where the issue is.
When a listener receives a talker-advertisement, it is known then that the intermediate points (AVB bridge ports) are ready for the stream to pass through. It will then send an acknowledgment message back towards the talker. As the intermediate bridges receive this message, they reserve the appropriate resources for the passage of this stream by making entries in their forwarding databases. (In other words, as they receive a particular stream, they will guarantee its priority and bandwidth.) When the talker finally receives the message back from the listener, the stream can start up.
While the stream is being sent, both the talker and listener will send periodic messages indicating to the intermediate bridges that the resources are still needed. When they are no longer needed (for whatever reason, the stream has ended) both ends will send a specific de-register message that will allow the intermediate bridges to release the resources. If the bridges don't hear the periodic messages, they'll 'age-out' the resources themselves.
Let's get in to the advantages that AVB provides: quality of service, and precision timing.
802.1Qav for AVB provides for what I think can best be described as an automatic, dynamic QoS mechanism that is hidden from the end-user. This QoS is ensured by traffic shaping, and admission controls (described above). Traffic shaping is a method by which the frames of the particular stream are regulated in the sense that they are being sent on a smooth basis (as opposed to bunches) very purposefully. Additionally the frames are tagged with a high-priority and as such will receive the necessary consideration from the forwarding database in the AVB bridge. All the best-effort traffic will essentially take a back-seat to the streaming traffic.
In a non-AVB system, the bridges (or Layer-2 switches) would have to be configured and support QoS all the way through the network, and this takes a certain amount of expertise that not everyone has.
- continued on page 3