IEEE 802-2011 pdf free download – IEEE Standard for Local and metropolitan area networks— A udio Video Bridging (AVB) Systems.
Given the Bridge architectural model for points of attachment for higher layer entities, as illustrated in Figure 8-11 of IEEE Std 802.1Q, any higher layer entities within a Bridge are not subject to this restriction on the use of flow control protocols. However, where the implementation makes use of the same MAC interface to support relayed frames and also higher layer protocol operation, and where the implementation supports other MAC control protocols that are not subject to relay by the Bridge, all transmitted frames that are not relayed by the Bridge shall be subject to the same transmission selection algorithms as relayed frames, in order to ensure that stream traffic latency is not adversely affected.
6.3 Frame sizes
The performance characteristics of an AVB network are sensitive to the data frame sizes that are used in the network, both for the stream data and for any non-AV data frames that are carried on the network. A conformant AVB system shall therefore adhere to the maximum frame size rules that apply to IEEE 802.3 frames, regardless of the medium type that is in use, on Ports that support AV traffic. This means that, on Ports that support AV traffic, the maximum data payload carried in a frame is 1500 octets, and the maximum frame size including headers, tags, etc., is 2000 octets. For the purposes of latency calculations (6.5), SRP can take into account the maximum frame size that is present on a given Port. For example, for Ethernet, if nothing but the basic IEEE 802.3 headers are being used with an IEEE 802.1Q C-VLAN tag, then the maximum frame size on this interface is 1522 octets.
Different media will have different maximum frame sizes. If a device is configured to support MAC PDU sizes larger than 2000 octets on one or more Ports, then those Ports shall be considered not to be AVB capable from the point of view of the operation of SRP. 6.4 Detection of AVB domains IEEE Std 802.1Q defines an SRP domain as a connected set of devices and LANs that support SRP with the same priority per SR class, and IEEE Std 802.1AS defines a generalized precision time protocol (gPTP) domain as a connected set of devices that support gPTP. SRP domains are determined by the operation of the MSRP protocol defined in Clause 35 of IEEE Std 802.1Q; gPTP domains are determined by the operation of gPTP. As the availability of both SRP and gPTP is considered to be a requirement for the support of AVB functionality in the profiles described in this standard, an AVB domain, that is, a connected set of devices and LANs within which AVB operation is supported, is the intersection of an SRP domain and a gPTP domain.
The operation of MSRP allows a Port to make a declaration on its attached LAN of the SR classes that it supports, and for each supported SR class, the priority code point value that it associates with that SR class. By comparing its own supported SR classes and priority values with those received from a neighboring device attached to the Port, a determination can be made as to whether the Port is at the boundary of the SRP domain for a given SR class or not. That information is then used to set the value of the SRPdomainBoundaryPort parameter (6.6.4 of IEEE Std 802.1Q) for that SR class. If the Port is an SRP domain boundary port for a given SR class, then for that SR class, the operation of the MAP function in SRP is such that any Talker Advertise declarations for that SR class that would otherwise be propagated through that Port are converted to Talker Failed declarations with a failure code (IEEE Std 802.1Q Table 35-6) of 8, meaning “Egress port is not AVB-capable”.
The consequence of this behavior is that stream reservations can only be established in circumstances where the Talker and the Listener(s) for the stream are located within the same SRP domain. gPTP detects the existence of LANs or devices that cannot support time synchronization; for example, LANs that cause excessively large transmission delay variation caused by the presence of non-standard devices (and detected by the measurement of a transmission delay that exceeds the value of neighborPropDelayThresh for the Port, as defined in IEEE Std 802.1AS), or LANs that do not support the time-stamping mechanisms required by gPTP. A port that has been determined not to be capable of supporting IEEE 802.1AS is labelled as such by gPTP setting the asCapable variable FALSE for that port.IEEE 802 pdf download.