Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción del control de flujo basado en prioridades

El control de flujo basado en prioridades (PFC), estándar IEEE 802.1Qbb, es un mecanismo de control de flujo a nivel de enlace. El mecanismo de control de flujo es similar al utilizado por la pausa Ethernet IEEE 802.3x, pero funciona según prioridades individuales. En lugar de pausar todo el tráfico en un vínculo, PFC le permite pausar selectivamente el tráfico según su clase.

En este tema se describe:

Confiabilidad de la entrega de paquetes en redes Ethernet estándar y en redes de capa 2

Ethernet estándar no garantiza que un paquete inyectado en la red llegue a su destino previsto. La confiabilidad es proporcionada por los protocolos de capa superior. Generalmente, una ruta de red consta de varios saltos entre el origen y el destino. Un problema surge cuando los transmisores envían paquetes más rápido de lo que los receptores pueden aceptarlos. Cuando los receptores se quedan sin espacio de búfer disponible para contener los flujos entrantes, silenciosamente dejan caer paquetes entrantes adicionales. Este problema generalmente se resuelve mediante protocolos de capa superior que detectan las caídas y solicitan la retransmisión.

Las aplicaciones que requieren confiabilidad en la capa 2 deben tener un control de flujo que incluya información de un receptor a un remitente con respecto a la disponibilidad del búfer. Mediante las tramas de control de pausa Ethernet IEEE 802.3x, un receptor puede generar una trama de control MAC y enviar una solicitud de pausa a un remitente cuando se ha llenado un umbral especificado de búfer del receptor para evitar el desbordamiento del búfer. Al recibir una solicitud de pausa, el remitente detiene la transmisión de cualquier paquete nuevo hasta que el receptor notifique al remitente que tiene suficiente espacio en búfer para aceptarlos nuevamente. La desventaja de usar Ethernet PAUSE es que funciona en todo el vínculo, que puede estar transportando múltiples flujos de tráfico. Algunos flujos de tráfico no necesitan control de flujo en la capa 2, ya que llevan aplicaciones que dependen de protocolos de capa superior para mayor confiabilidad. PFC le permite configurar el control de flujo de capa 2 de forma selectiva para el tráfico que lo requiere, como el tráfico de canal de fibra sobre Ethernet (FCoE), sin afectar al resto del tráfico del vínculo. También puede habilitar PFC para otros tipos de tráfico, como iSCSI.

Cálculos de los requisitos de búfer cuando se utiliza la pausa de PFC

El búfer de recepción debe ser lo suficientemente grande como para dar cabida a todos los datos que se reciben mientras el sistema responde a una trama de pausa PFC.

Cuando calcule los requisitos de búfer, tenga en cuenta los siguientes factores:

  • Retraso de procesamiento y cola de la pausa de PFC: en general, el tiempo para detectar la falta de suficiente espacio intermedio y transmitir la pausa de PFC es insignificante. Sin embargo, pueden producirse retrasos si el conmutador detecta una reducción en el espacio de búfer justo cuando el transmisor comienza a transmitir una trama de longitud máxima.

  • Retraso de propagación a través de los medios: la cantidad de retraso depende de la longitud y la velocidad del vínculo físico.

  • Tiempo de respuesta al marco de pausa de PFC

  • Retraso de propagación a través de los medios en la ruta de retorno

Nota:

Se recomienda configurar al menos el 20 por ciento del tamaño del búfer para la cola que utiliza PFC y que no especifique la opción exacta .

Dado que es obligatorio configurar explícitamente un determinado porcentaje de tamaño de búfer para PFC, también debe configurar explícitamente cierto tamaño de búfer para cualquier otra clase de reenvío que tenga previsto utilizar (incluidas las clases de reenvío predeterminadas y las clases de reenvío definidas por el usuario). El porcentaje que asigne depende del uso de las clases respectivas.

Cómo funcionan los perfiles de notificación de congestión y PFC con o sin DCBX

PFC se puede aplicar a una interfaz independientemente de si el protocolo de intercambio de capacidad de puente del centro de datos (DCBX) está habilitado.

Sin embargo, el control automático y la publicidad de PFC requieren DCBX:

  • Cuando DCBX está habilitado: DCBX detecta la configuración de PFC del vecino de puente del centro de datos (DCB), utiliza la negociación automática para anunciar la configuración de PFC local y del mismo nivel y, a continuación, habilita o deshabilita PFC dependiendo de si las configuraciones son compatibles o no. Cuando PFC está habilitado, utiliza el perfil de notificación de congestión, que ha configurado y aplicado a la interfaz.

  • Cuando DCBX no está habilitado: la clase de servicio (CoS) activa PFC cuando la trama entrante tiene un campo de prioridad de usuario (UP) que coincide con el patrón de tres bits especificado para el perfil de notificación de congestión.

Para controlar manualmente el uso de PFC en la interfaz, independientemente de la configuración de los dispositivos del centro de datos del mismo nivel, puede cambiar explícitamente la configuración de DCBX en la interfaz para deshabilitar la negociación automática de PFC. Consulte Deshabilitar DCBX para deshabilitar la negociación automática de PFC en conmutadores de la serie EX (procedimiento de CLI). Cuando la negociación automática de PFC está deshabilitada, PFC se activa mediante el perfil de notificación de congestión para PFC, independientemente de la configuración del par DCB.

Nota:

PFC funciona eficazmente solo cuando los dispositivos del mismo nivel conectados a la interfaz local también usan PFC y están configurados de manera compatible con la interfaz local. PFC debe ser simétrico: si PFC no está configurado para usar la misma clase de tráfico (punto de código) tanto en la interfaz local como en la del mismo nivel, no tiene ningún impacto en el tráfico.

La tabla 1 muestra la asignación uno a uno entre el campo UP de una trama etiquetada IEEE 802.1Q, la clase de tráfico y la cola de salida. Además de establecer un perfil de notificación de congestión de PFC en un puerto de entrada, debe establecer una clase de reenvío que coincida con la prioridad especificada en el perfil de notificación de congestión de PFC y reenviar la trama a la cola adecuada.

Los conmutadores Ethernet de la serie EX de Juniper Networks admiten hasta seis clases de tráfico y le permiten asociar esas clases con seis perfiles de notificación de congestión diferentes. (Los conmutadores admiten hasta 16 clases de reenvío).

Tabla 1: Entrada para el perfil de notificación de congestión de PFC y asignación a clase de tráfico y cola de salida

Campo UP del marco etiquetado IEEE-802.1Q

Clase de tráfico

Cola de salida

000

TC 0

cola 0

001

TC 1

Cola 1

010

TC 2

Cola 2

011

TC 3

Cola 3

100

TC4

Cola 4

101

TC 5

cola 5