Overview: IEEE AVB, ARINC664, and IEEE DCB
IEEE AVB is a group of amandments to 802.1Q, designed to support audio/video applications over Ethernet. IEEE AVB includes the system synchronization 802.1AS (useful for synchronization and alignment of applications), and 802.1Qat Stream Reservation Protocol, used for setting up AV streams in the network dynamically. Its rate-constrained service is defined in 802.1Qav "Forwarding and Queuing Enhancements for Time-Sensitive Streams".
ARINC 664 has been designed as Avionics Full-Duplex Ethernet, for use in integrated avionics systems, where the determinism and maximum latency must be defined and guaranteed for all virtual links (VL). There is no synchronization capability in ARINC 664. ARINC 664-Part7 focuses on rate-constrained communication. This standard does not allow use of best-effort traffic. ARINC664 is designed for operation in closed redundant networks designed for critical applications.
IEEE DCB is a group of amandments to 802.1Q, designed to support lossless low-latency communication and integration of SAN and LAN networks. It was designed as a first step toward convergence-enhanced Ethernet networks. The communicaton rate in this standard is not based on the temporal control of latency - it balances sender output by signalling switch buffer status for specified traffic class. For high-priority treffic classes this will result in the lowest possible communication latency. In addition, every link has also limited bandwidth, which can be dynamically updated. High-priority IEEE DCB traffic can have exceptional latency performance ocassionaly, but it is not focusing on bounded latency.
Prerequisites for reliable operation of time-sensitive communication with latency bounds
Rate-constrained services rely on statistical multiplexing and there are several considerations which must be fulfilled by network devices in order to model this type of traffic properly, so that the model fits the network's real-life behavior. This is essential for implemetation of Ethernet network devices used in time-sensitive applications, otherwise the temporal properties cannot be guaranteed.
The following considerations should be taken into account when designing switches and network devices:
- store-and-forward switches
- constant switching (packet forwarding) latency independant of traffic profile and buffer memory use
- shaped traffic with maximum allowable bandwidth use and strictly defined periodicity
- robust policing and/or shaping to prevent temporal misbehavior
- lower-priority (or prohibition!) for any time-insensitive traffic
Traffic shaping or policing?
Traffic shaping is required on sender side in any case, and policing and/or shaping are required on network devices (switches, NICs). Depending on the use case specific properties can be emphasized.
In general policing at incoming ports will ensure that any temporal deviations are detected immediately, while shaping on incoming ports will add some delay before the buffers are overflowed or packets are dropped.
Traffic shaping can "polish"(reduce) the jitter in a message stream, but it increases the total stream latency.
In order to reduce the stream latency, shaping can be used only at traffic source, and the policing can be applied on every switch. In open networks, shaping and policing may be required to guarantee temporal boundaries. In closed networks the traffic shaping can be conducted only at the sender, to simplify design of switching network devices.
More information on traffic policing and shaping can be found here.
Rate-constrained traffic in IEEE AVB
The objective was to have a network which can guarantee max. 2ms delay over 7 hops (switches). This standard allows a portion of bandwidth to be used by best effort traffic, assuming it is not influencing time-sensitive traffic. 802.1Qav introduces new traffic classes which are higher priority than other traffic, and guarantees maximum latency of 125µs (CLASS A) or 250µs (CLASS B) per hop.
While egress (outbound port) traffic shaping adds latency, it also reduces jitter and differences between maximum and minimum latency oscillation.
Rate-constrained traffic in ARINC 664-P7
ARINC664 standard simply assumes that all virtual links are a part of "equal" traffic class, and the standard does not allow lower-priority traffic classes (e.g. best effort traffic). However, it still uses virtual link prioritization (not a traffic class prioritization!), just to ensure correct statistical multiplexing, temporal behavior and packet scheduling of virtual links. Traffic shaping is conducted only once on the packet source (sender).
ARINC664 (AFDX) uses traffic policing on inbound ports for every virtual link separately and drops packets violating the prescribed periodicity. Bandwidth Allocation Gap (BAG) with periods of 1, 2, 4, 8, ... 128ms and maximum defined message size for each period. The policing ensures that all the network traffic (VLs) can arrive to recepients within the given bounded latency, as planned at design time, independant of the virtual link (VL) property violations on the path to the recepient. The policing ensures that the temporal performance for VLs is correct from the source to the target, otherwise the packet is dropped.
Different variations of ARINC664-P7 (AFDX) with improved real-time behavior can be defined by limiting the number of endsystems (nodes) in the system, and by limiting messages size and minimum periodicity to e.g. 500µs and 250µs.
The distinctive feature of this Ethernet standard used in avionics applications is that it requires redundant communication, and takes the first valid message from two redundant virtul links (VLs) passing through redundant paths. This means that higher layers need to take care of message "generations" and adjustments of channels, which leads to slightly different temporal behavior of channels in redundant and non-redundant network operation.
Bandwidth use and Efficency: IEEE AVB, ARINC664, and IEEE DCB
Time-sensitive asynchronous communication can safely reach upto 20% of bandwidth use without violations of guaranteed maximum latencies. With bandwidth use above 25-30%, the latency will start quickly growing above prescribed limits (e.g. 250µs per hop in AVB, in ARINC664-P7 the specified maximum latency for configured virtual links should be increased to avoid packet loss). The side effect in both cases is that the switch (bridge) in this requires large amount of buffer memory to avoid packet losses. The longer the maximum latency and the need to avoid dataloss, the larger packet buffer memory will be required.
So this is a trade-off with different parameters. In real applications, only a fraction of bandwidth will be used to enable updates, system growth, extensions and updates.
In IEEE DCB, this effect will not exist as there is a mechanism for dynamic shaping of source traffic in case the buffer memory is filling to fast. It is clear that the latency of lower priority packet streams will rise, but the packets will not be lost. While there is no time-sensitive component in DCB traffic, there will be some topology and line speed dependancy.
