Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción de PFC mediante DSCP en la capa 3 para tráfico no etiquetado

Protocolos como el acceso directo de memoria remota (RDMA) sobre Ethernet convergente versión 2 (RoCEv2) requieren un comportamiento sin pérdidas para el tráfico a través de conexiones de capa 3 a subredes de Ethernet de capa 2. Tradicionalmente, el control de flujo basado en prioridades (PFC) se puede utilizar para evitar la pérdida de tráfico cuando se produce congestión en interfaces de capa 2 o capa 3 para el tráfico etiquetado por VLAN mediante la pausa selectiva del tráfico en cualquiera de las ocho prioridades correspondientes a puntos de código IEEE 802.1p en los encabezados VLAN del tráfico entrante en una interfaz. Sin embargo, el tráfico sin etiqueta (tráfico sin etiquetado de VLAN) no se puede examinar en busca de puntos de código IEEE 802.1p en los que pausar el tráfico.

Para admitir un flujo de tráfico sin pérdida en la capa 3 para el tráfico sin etiqueta, se admite la habilitación de PFC para interfaces de capa 3 y de acceso de capa 2 mediante valores de punto de código de servicios distribuidos (DSCP) en el encabezado IP de capa 3 del tráfico entrante, en lugar de valores de punto de código IEEE 802.1p en un encabezado de VLAN de capa 2.

Descripción general de PFC basado en DSCP

PFC es una tecnología de puente de centro de datos que opera en la capa 2, y la información DSCP se intercambia en encabezados IP en la capa 3. Sin embargo, puede configurar PFC basado en DSCP, que conserva el comportamiento sin pérdida en las conexiones de red de capa 3 para el tráfico sin etiquetar.

PFC funciona mediante la generación de tramas de pausa para el tráfico identificado en puntos de código configurados en el tráfico entrante para notificar al par que pause la transmisión cuando el vínculo está congestionado. Con PFC basado en DSCP habilitado, las tramas de pausa se activan en función de un valor DSCP de 6 bits configurado (correspondiente a valores decimales del 0 al 63) en el encabezado IP de capa 3 del tráfico entrante.

Sin embargo, PFC solo puede enviar tramas de pausa con una prioridad PFC de 3 bits (uno de los 8 puntos de código correspondientes a los valores decimales del 0 al 7) que, para el tráfico etiquetado por VLAN, generalmente corresponde a los puntos de código IEEE 802.1p en los encabezados VLAN del tráfico entrante. El tráfico sin etiqueta no proporciona ninguna referencia para los valores de punto de código IEEE 802.1p, por lo que para activar PFC en un valor DSCP, el valor DSCP debe asignarse explícitamente en la configuración a una prioridad PFC que se utilizará en las tramas de pausa PFC enviadas al par cuando se produzca una congestión para ese punto de código. Puede asignar tráfico en un valor DSCP a una prioridad PFC cuando defina la clase de reenvío sin pérdida con la que desea clasificar el tráfico PFC basado en DSCP. La clase de reenvío también debe asignarse a una cola de salida con un comportamiento sin pérdidas.

Nota:

No puede asignar la misma prioridad PFC a más de una clase de reenvío porque el valor de prioridad de PFC asignado se utiliza como ID de clase de reenvío cuando se configura PFC basado en DSCP.

También se requiere un clasificador DSCP (en lugar de un clasificador IEEE 802.1p) para especificar que el tráfico entrante con el valor DSCP configurado anteriormente pertenece a la clase de reenvío sin pérdidas. Cualquier valor DSCP para el que esté habilitado PFC basado en DSCP en una interfaz debe especificarse en el clasificador DSCP predeterminado o en un clasificador DSCP definido por el usuario asociado con la interfaz.

Para habilitar PFC basado en DSCP en una interfaz, defina un perfil de notificación de congestión de entrada con el mismo valor DSCP (y los parámetros de almacenamiento en búfer deseados) y asócielo a la interfaz.

El dispositivo par debe tener una configuración de PFC coincidente para los puntos de código de prioridad de PFC asignados.

Limitaciones de la PFC basada en DSCP

A continuación se muestran las limitaciones de la PFC basada en DSCP:

  • No puede configurar PFC basado en DSCP y PFC IEEE 802.1p en el mismo perfil de notificación de congestión, ni asociar un perfil de notificación de congestión basado en DSCP y un perfil de notificación de congestión IEEE 802.1p con la misma interfaz.

  • La PFC basada en DSCP solo se admite en interfaces de capa 3 y de acceso de capa 2 para tráfico no etiquetado. El comportamiento de PFC es impredecible si se reciben paquetes etiquetados con VLAN en una interfaz con PFC basado en DSCP habilitado.

  • Cada clase de reenvío sin pérdidas solo se puede asociar a un valor de prioridad PFC de 3 bits único del 0 al 7.

Umbrales de contabilidad PFC configurables

En las plataformas compatibles, existen búferes de pausa de PFC virtuales denominados cuentas PFC que se definen dentro de un perfil de notificación de congestión (CNP). Cada puerto de entrada puede tener dos cuentas de PFC de este tipo. Puede establecer de forma independiente la prioridad de PFC para transmitir tramas de pausa y los umbrales de XOFF y XON para cada cuenta de PFC.

Considere la Figura 1, que muestra un búfer de pausa típico. En este diagrama, el búfer comienza a llenarse desde abajo hacia arriba debido a la congestión en el puerto de salida. Cuando el relleno de búfer alcanza XOFF, se envía una trama de pausa de PFC ascendente para pausar el tráfico asociado con la clase PFC. El espacio de margen permite paquetes en tránsito y retrasos de procesamiento, de modo que el dispositivo ascendente pueda pausar el tráfico antes de que el búfer se llene por completo y comience a soltar paquetes. El sistema utiliza la longitud del cable y la unidad máxima de recepción (MRU) para calcular la cantidad de espacio libre de búfer reservado para admitir PFC. Cuanto más corta sea la longitud del cable y menor sea la MRU, menos espacio de margen se necesitará para PFC.

Figura 1: Búfer Typical Pause Buffer de pausa típico

Cuando la congestión se reduce y el relleno de búfer cae por debajo del nivel de XON umbral, se envía una trama de reanudación ascendente para reiniciar el tráfico de datos.

Para que PFC funcione eficazmente, debe establecer XOFFcorrectamente , XONy el búfer de margen para cada cuenta PFC. Junos calcula el espacio libre en función de la longitud de cable definida y otros factores calculados internamente.

Defina una cuenta PFC para el tráfico de entrada en un CNP:

  1. Defina una o dos cuentas PFC. Establezca una prioridad PFC para cada cuenta y, si es necesario, establezca XOFF y XON para cada cuenta.

  2. Establezca los puntos de código que está utilizando para PFC y asigne una cuenta PFC a cada punto de código.

  3. Establezca el correcto cable-length para el CNP. La longitud del cable es la distancia entre la interfaz y sus interfaces pares en metros.

Comportamiento de PFC específico de la plataforma

Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.

Utilice la siguiente tabla para revisar los comportamientos específicos de la plataforma para su plataforma.

Plataforma Diferencia

Serie PTX10000

  • Puede configurar hasta dos colas como no-loss al definir clases de reenvío.

  • Los enrutadores de la serie PTX10000 admiten hasta 100 KM de longitud de cable.

  • Los enrutadores de la serie PTX10000 tienen búferes de pausa PFC virtuales denominados cuentas PFC.

  • Toda la contabilidad del búfer de pausa de PFC se produce con respecto a los puertos de entrada y no de salida.

  • Si tanto PFC como ECN están habilitados, cuando la ocupación de una cuenta PFC es superior a XON, de forma predeterminada los paquetes con capacidad ECN se marcan como congestión experimentada (CE).

Documentación relacionada