Control de flujo de Ethernet - Ethernet flow control

Captura de pantalla de Wireshark de un marco de "Pausa" de Ethernet

El control de flujo de Ethernet es un mecanismo para detener temporalmente la transmisión de datos en las redes informáticas de la familia Ethernet . El objetivo de este mecanismo es evitar la pérdida de paquetes en presencia de congestión en la red .

El primer mecanismo de control de flujo, el marco de pausa , fue definido por el estándar IEEE 802.3x . El control de flujo basado en prioridad de seguimiento , como se define en el estándar IEEE 802.1Qbb , proporciona un mecanismo de control de flujo a nivel de enlace que se puede controlar de forma independiente para cada clase de servicio (CoS), según lo definido por IEEE P802.1py es aplicable a las redes de puenteo de centros de datos (DCB) y para permitir la priorización de voz sobre IP (VoIP), video sobre IP y tráfico de sincronización de base de datos sobre el tráfico de datos predeterminado y transferencias de archivos masivas.

Descripción

Una estación emisora ​​(computadora o conmutador de red ) puede estar transmitiendo datos más rápido de lo que el otro extremo del enlace puede aceptarlos. Usando el control de flujo , la estación receptora puede enviar una señal al remitente solicitando la suspensión de las transmisiones hasta que el receptor se ponga al día. El control de flujo en Ethernet se puede implementar en la capa de enlace de datos .

El primer mecanismo de control de flujo, el marco de pausa , fue definido por el grupo de trabajo del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) que definió los segmentos de enlace Ethernet dúplex completo . El estándar IEEE 802.3x se publicó en 1997.

Pausar fotograma

Un nodo de red abrumado puede enviar una trama de pausa, que detiene la transmisión del remitente durante un período de tiempo específico. Se utiliza una trama de control de acceso a medios (MAC) ( EtherType 0x8808) para llevar el comando de pausa, con el código de operación de control establecido en 0x0001 ( hexadecimal ). Solo las estaciones configuradas para operación full-duplex pueden enviar tramas de PAUSA. Cuando una estación desea pausar el otro extremo de un enlace, envía una trama de pausa a la dirección de destino única de 48 bits de este enlace oa la dirección de multidifusión reservada de 48 bits de 01-80-C2-00-00- 01 . El uso de una dirección conocida hace innecesario que una estación descubra y almacene la dirección de la estación en el otro extremo del enlace.

Otra ventaja de utilizar esta dirección de multidifusión surge del uso del control de flujo entre conmutadores de red. La dirección de multidifusión particular utilizada se selecciona de un rango de direcciones que han sido reservadas por el estándar IEEE 802.1D que especifica el funcionamiento de los conmutadores utilizados para el puenteo . Normalmente, una trama con un destino de multidifusión enviada a un conmutador se reenviará a todos los demás puertos del conmutador. Sin embargo, este rango de direcciones de multidifusión es especial y no será reenviado por un conmutador compatible con 802.1D. En cambio, se entiende que las tramas enviadas a este rango son tramas destinadas a ser actuadas solo dentro del conmutador.

Una trama de pausa incluye el período de tiempo de pausa que se solicita, en forma de un entero sin signo de dos bytes (16 bits) (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 unidad es igual a tiempos de 512 bits .

En 1999, varios proveedores admitían la recepción de tramas de pausa, pero menos implementaron su envío.

Cuestiones

Una motivación original para la trama de pausa era manejar controladores de interfaz de red (NIC) que no tenían suficiente almacenamiento en búfer para manejar la recepción de alta velocidad. Este problema no es tan común con los avances en la velocidad del bus y el tamaño de la memoria. Un escenario más probable es la congestión de la red dentro de un conmutador. Por ejemplo, un flujo puede entrar en un conmutador en un enlace de mayor velocidad que el que sale, o varios flujos pueden entrar en dos o más enlaces que suman más que el 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 a través de ese enlace se retrasen, incluso aquellos que no causan ninguna congestión. Esta situación es un caso de bloqueo de cabecera de línea (HOL) y puede ocurrir con mayor frecuencia en los conmutadores de la red central debido a la gran cantidad de flujos que generalmente se agregan. Muchos conmutadores utilizan una técnica denominada colas de salida virtuales para eliminar el bloqueo HOL internamente, por lo que nunca enviarán tramas de pausa.

Esfuerzos posteriores

Gestión de la congestión

Otro esfuerzo comenzó en marzo de 2004, y en mayo de 2004 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 para limitar la velocidad de transmisión de datos a aproximadamente un 1% de granularidad. La solicitud fue retirada y el grupo de trabajo se disolvió en 2008.

Control de flujo prioritario

El control de flujo de Ethernet perturba la clase de servicio de Ethernet (definida en IEEE 802.1p ), ya que los datos de todas las prioridades se detienen para borrar los búferes existentes que también pueden consistir en 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. Posteriormente, la extensión fue estandarizada por el proyecto Priority-based Flow Control (PFC) autorizado el 27 de marzo de 2008, como IEEE 802.1Qbb. El borrador 2.3 fue propuesto el 7 de junio de 2010. Claudio DeSanti de Cisco fue el editor. El esfuerzo fue parte del grupo de tareas de puenteo del centro de datos , que desarrolló Fibre Channel sobre Ethernet .

Ver también

Referencias

enlaces externos