Converged networks with Fibre Channel over Ethernet and Data Center Bridging

12
Figure 7. Example of an Enhanced Transmission Selection (ETS) configuration
Also in Figure 7, note that TC2 has priority queues 2 and 3. The ETS standard suggests that frames transmit
from TC2 queues in strict priority order. In this example, the device sends any frames in the queue for
priority 3 before any frames in the queue for priority 2. Again, the standard leaves the implementation of
scheduling for these intra-TC queues to device vendors. Vendors might use the two traffic classes scheduled
in strict priority order or in round robin. Some implementations may be configurable to allow either mode.
The FCoE protocol requires DCB-enabled Ethernet devices to support at least two TCs that support ETS
scheduling algorithms: one to support traditional data communication traffic and one to support FCoE
traffic. Many devices on the market only support two TCs with ETS capability. In future generations of
hardware, devices should support more TCs capable of ETS bandwidth scheduling, but this is not required
for basic FCoE transport over DCB-enabled Ethernet links.
Those who adopt of this technology must clearly understand another important aspect of ETS performance.
ETS bandwidth allocation is merely the best effort specification of minimum bandwidth guarantee. Many
factors can limit the effectiveness of a device to meet these bandwidth requirements consistently. The
bandwidth consumed by the strict priority queues can directly affect the amount of bandwidth available for
ETS traffic classes. When a port receives a per priority pause frame (PPP) from its link partner, all
transmission from that traffic class or priority queue within the traffic class stops for the duration of the
pause. This could dramatically reduce the effective throughput of that traffic class. Finally, implementing
congestion notification can also affect the amount of data transmitted from a traffic class, but not as severely
as PFC’s effect on ETS.
Quantized Congestion Notification
The IEEE 802.1Qau standard specifies a protocol called Quantized Congestion Notification (QCN). The
QCN protocol supports end-to-end flow control in large, multi-hop, DCB-enabled, switched Ethernet
infrastructures. It is one of the most significant standards for enabling converged network deployments in
moderate to large data centers. PFC protects against occasional bursty congestion on a single link between
DCB-enabled devices. QCN protects larger multi-hop or end-to-end converged networks from persistent or
chronic congestion. These multi-hop networks are susceptible to congestion because typical tree-like network
architectures tend to have choke points where multiple sources of data compete for network resources and
bandwidth to reach a smaller number of destinations. Typical shared storage traffic patterns especially
compound this issue. QCN does not guarantee a lossless environment in the DCB-enabled LAN. You must