Ethernet flow control

An overwhelmed network node can send a pause frame, which halts the transmission of the sender for a specified period of time. A media access control (MAC) frame (EtherType 0x8808) is used to carry the pause command, with the Control opcode set to 0x0001 (hexadecimal).^[1] Only stations configured for full-duplex operation may send pause frames. When a station wishes to pause the other end of a link, it sends a pause frame to either the unique 48-bit destination address of this link or to the 48-bit reserved multicast address of 01-80-C2-00-00-01.^{[2]:Annex 31B.3.3} The use of a well-known address makes it unnecessary for a station to discover and store the address of the station at the other end of the link.

Otra ventaja de usar esta dirección de multidifusión radica en el control de flujo entre conmutadores de red. La dirección de multidifusión específica se selecciona de un rango de direcciones reservadas por el estándar IEEE 802.1D , que especifica el funcionamiento de los conmutadores utilizados para la interconexión . Normalmente, una trama con destino de multidifusión enviada a un conmutador se reenvía a todos los demás puertos del mismo. Sin embargo, este rango de direcciones de multidifusión es especial y no será reenviado por un conmutador compatible con 802.1D. En cambio, las tramas enviadas a este rango se interpretan como tramas destinadas a ser procesadas únicamente dentro del conmutador.

Un marco de pausa incluye el período de tiempo de pausa solicitado, en forma de un entero sin signo de dos bytes (16 bits) (de 0 a 65535). Este número es la duración solicitada de la pausa. El tiempo de pausa se mide en unidades de cuantos de pausa , donde cada cuanto es igual a 512 veces el valor de un bit .

Para 1999, varios proveedores admitían la recepción de tramas de pausa, pero menos implementaban su envío. ^{[ 3 ] [ 4 ]}

Una de las motivaciones originales para la trama de pausa era manejar los controladores de interfaz de red (NIC) que no tenían suficiente almacenamiento en búfer para manejar la recepción a máxima velocidad. Este problema se ha vuelto menos común con los avances en las velocidades de bus y los tamaños de memoria. Un escenario más probable es la congestión de la red dentro de un conmutador. Por ejemplo, un flujo puede ingresar a un conmutador por un enlace de mayor velocidad que el de salida, o varios flujos pueden ingresar por dos o más enlaces que suman más del ancho de banda de un enlace de salida. Estos eventualmente agotarán cualquier cantidad de almacenamiento en búfer en el conmutador. Sin embargo, bloquear el enlace de envío provocará que todos los flujos sobre ese enlace se retrasen, incluso aquellos que no estén causando ninguna congestión. Esta situación es un caso de bloqueo de cabecera de línea (HOL) y puede ocurrir con más frecuencia en los conmutadores de red centrales debido a la gran cantidad de flujos que generalmente se agregan. Muchos conmutadores utilizan una técnica llamada colas de salida virtuales para eliminar el bloqueo HOL internamente, por lo que nunca enviarán tramas de pausa. ^{[ 4 ]}

En marzo de 2004 se inició otro esfuerzo, que en mayo del mismo año se convirtió en el Grupo de Trabajo de Gestión de Congestión IEEE P802.3ar. En mayo de 2006, se revisaron los objetivos del grupo de trabajo para especificar un mecanismo que limitara la tasa de datos transmitidos a una granularidad de aproximadamente el 1 %. La solicitud se retiró y el grupo de trabajo se disolvió en 2008. ^{[ 5 ]}

El control de flujo Ethernet altera la clase de servicio Ethernet (definida en IEEE 802.1p ), ya que los datos de todas las prioridades se detienen para limpiar los búferes existentes, que también pueden contener datos de baja prioridad. Como solución a este problema, Cisco Systems definió su propia extensión de control de flujo de prioridad para el protocolo estándar. Este mecanismo utiliza 14 bytes del relleno de 42 bytes en una trama de pausa regular. El código de operación de control MAC para una trama de pausa de prioridad es 0x0101. A diferencia de la pausa original, la pausa de prioridad indica el tiempo de pausa en cuantos para cada una de las ocho clases de prioridad por separado. ^{[ 6 ]} La extensión fue posteriormente estandarizada por el proyecto Priority-based Flow Control (PFC), autorizado el 27 de marzo de 2008, como IEEE 802.1Qbb. ^{[ 7 ]} El borrador 2.3 se propuso el 7 de junio de 2010. Claudio DeSanti de Cisco fue el editor. ^{[ 8 ]} El esfuerzo formó parte del grupo de trabajo de interconexión de centros de datos , que desarrolló Fibre Channel over Ethernet . ^{[ 9 ]}