Control de flujo de Ethernet
Técnica para suspender la transmisión para evitar congestiones
Captura de pantalla de Wireshark de un marco de pausa de Ethernet

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

El primer mecanismo de control de flujo, la trama de pausa , fue definido por el estándar IEEE 802.3x . El siguiente control de flujo basado en prioridad , tal 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), tal como se define en IEEE P802.1p y es aplicable a redes de puentes de centros de datos (DCB), y para permitir la priorización del tráfico de voz sobre IP (VoIP), video sobre IP y sincronización de bases de datos sobre el tráfico de datos predeterminado y las transferencias de archivos en masa.

Descripción

Una estación emisora ​​(computadora o conmutador de red ) puede estar transmitiendo datos a una velocidad mayor que la que el otro extremo del enlace puede aceptar. Mediante el control de flujo , la estación receptora puede enviar una señal al emisor 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, la trama 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 full duplex . El estándar IEEE 802.3x se publicó en 1997. [1]

Marco de pausa

Un nodo de red sobrecargado puede enviar una trama de pausa, que detiene la transmisión del remitente durante un período de tiempo especificado. Se utiliza una trama de control de acceso al medio (MAC) ( EtherType 0x8808) para llevar el comando de pausa, con el código de operación de control establecido en 0x0001 ( hexadecimal ). [1] 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 o a la dirección de multidifusión reservada de 48 bits de 01-80-C2-00-00-01 . [2] : Anexo 31B.3.3  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 la conexión en puente . 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, las tramas enviadas a este rango se entienden como tramas destinadas a ser procesadas únicamente 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) (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 tiempos de bit .

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

Asuntos

Una de las motivaciones originales 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 a máxima velocidad. Este problema no es tan común con los avances en las velocidades de bus y 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 entrar en un conmutador en un enlace de mayor velocidad que el que sale, o pueden entrar varios flujos 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 hará 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 conmutadores de red central 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]

Esfuerzos posteriores

Gestión de la congestión

En marzo de 2004 se inició otro esfuerzo que, en mayo de ese 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 velocidad de transmisión de datos a una granularidad de aproximadamente el 1 %. La solicitud fue retirada y el grupo de trabajo se disolvió en 2008. [5]

Control de flujo prioritario

El control de flujo de 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 buffers existentes que también podrían 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. [6] La extensión fue estandarizada posteriormente por el proyecto de Control de flujo basado en prioridad (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 fue parte del grupo de trabajo de puenteo de centros de datos , que desarrolló Fibre Channel over Ethernet . [9]

Véase también

Referencias

  1. ^ ab IEEE Standards for Local and Metropolitan Area Networks: Supplements to Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification - Specification for 802.3 Full Duplex Operation and Physical Layer Specification for 100 Mb/s Operation on Two Pairs of Category 3 or Better Balanced Twisted Pair Cable (100BASE-T2) [Estándares IEEE para redes de área local y metropolitana: complementos del método de acceso de acceso múltiple con detección de colisiones y detección de portadora (CSMA/CD) y especificaciones de capa física: especificación para operación full duplex 802.3 y especificación de capa física para operación a 100 Mb/s en dos pares de cable de par trenzado equilibrado de categoría 3 o superior (100BASE-T2)]. Institute of Electrical and Electronics Engineers . 1997. doi :10.1109/IEEESTD.1997.95611. ISBN 978-1-55937-905-2. Archivado desde el original el 13 de julio de 2012.
  2. ^ Estándar IEEE para Ethernet (PDF) . Asociación de estándares IEEE. 31 de agosto de 2018. doi :10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4. Consultado el 29 de noviembre de 2022 . {{cite book}}: |website=ignorado ( ayuda ) [ enlace roto ]
  3. ^ Ann Sullivan; Greg Kilmartin; Scott Hamilton (13 de septiembre de 1999). "Los proveedores de conmutadores superan las pruebas de interoperabilidad". Network World . págs. 81–82 . Consultado el 10 de mayo de 2011 .
  4. ^ ab "Proveedores de control de flujo". Network World Fusion . 13 de septiembre de 1999. Archivado desde el original el 7 de febrero de 2012.Comentarios del proveedor sobre el control de flujo en la prueba de 1999.
  5. ^ "IEEE P802.3ar Congestion Management Task Force". 18 de diciembre de 2008. Consultado el 10 de mayo de 2011 .
  6. ^ "Control de flujo prioritario: crear una infraestructura de capa 2 confiable" (PDF) . Documento técnico . Cisco Systems. Junio ​​de 2009 . Consultado el 10 de mayo de 2011 .
  7. ^ IEEE 802.1Qbb
  8. ^ "Control de flujo basado en prioridades IEEE 802.1Q". Instituto de Ingenieros Eléctricos y Electrónicos. 7 de junio de 2010. Consultado el 10 de mayo de 2011 .
  9. ^ "Grupo de trabajo sobre puentes de centros de datos". Instituto de Ingenieros Eléctricos y Electrónicos. 7 de junio de 2010. Consultado el 10 de mayo de 2011 .
  • "Control de acceso a medios Ethernet: tramas PAUSE". Resumen técnico de Ethernet de TechFest . 1999. Archivado desde el original el 4 de febrero de 2012. Consultado el 10 de mayo de 2011 .
  • Tim Higgins (7 de noviembre de 2007). "Cuando el control de flujo no es algo bueno". Small Net Builder . Consultado el 6 de enero de 2020 .
  • Herramienta de Linux para generar marcos PAUSE de control de flujo Archivado el 24 de mayo de 2012 en Wayback Machine
  • Herramienta de Python para generar cuadros PFC
  • "Control de flujo Ethernet". Temas de mensajería de alto rendimiento . Archivado desde el original el 8 de diciembre de 2007.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Control_de_flujo_de_Ethernet&oldid=1245015384"