Redes sensibles al tiempo

La norma IEEE 802.1AS-2011 define el perfil del Protocolo de Tiempo de Precisión Generalizado (gPTP) que, al igual que todos los perfiles de IEEE 1588 , selecciona entre las opciones de 1588, pero también generaliza la arquitectura para permitir que PTP se aplique más allá de las redes Ethernet cableadas.

Para tener en cuenta los retrasos en la ruta de datos, el protocolo gPTP mide el tiempo de residencia de la trama dentro de cada puente (el tiempo necesario para recibir, procesar, poner en cola y transmitir la información de temporización desde los puertos de entrada a los de salida), y la latencia del enlace de cada salto (un retardo de propagación entre dos puentes adyacentes). Estos retardos calculados se referencian al reloj GrandMaster (GM) en un puente elegido por el algoritmo Best Master Clock, un protocolo Spanning Tree con el que todos los dispositivos Clock Master (CM) y de punto final intentan sincronizarse. Cualquier dispositivo que no se sincronice con los mensajes de temporización queda fuera de los límites del dominio de temporización (Figura 2).

La precisión de la sincronización depende de mediciones precisas del retardo del enlace y del tiempo de residencia de la trama. El estándar 802.1AS utiliza la sincronización lógica , donde se emplea una relación entre las frecuencias del reloj local y del reloj GM para calcular la hora sincronizada, y otra relación entre las frecuencias del reloj local y del reloj GM para calcular el retardo de propagación.

La norma IEEE 802.1AS-2020 introduce una mayor precisión en la medición del tiempo y compatibilidad con múltiples dominios temporales para garantizar la redundancia.

La especificación IEEE 802.1Qav, que mejora el reenvío y la gestión de colas para flujos sensibles al tiempo, define la conformación del tráfico mediante clases de prioridad, basadas en una forma sencilla de cola justa basada en créditos con fugas . 802.1Qav está diseñado para reducir el almacenamiento en búfer en los puentes y puntos finales receptores.

El modelador basado en créditos define créditos en bits para dos colas separadas, dedicadas al tráfico de Clase A y Clase B. La transmisión de tramas solo se permite cuando el crédito no es negativo; durante la transmisión, el crédito disminuye a una tasa denominada sendSlope:

${\displaystyle {\text{sendSlope}}={\text{idleSlope}}-{\text{portTransmitRate}}.}$

El crédito aumenta a una tasa idleSlope si hay tramas esperando a que se transmitan otras colas:

${\displaystyle {\text{idleSlope}}={\frac {\text{reservedBytes}}{\text{divFrameIntervalTime}}}.}$

Así, idleSlope es el ancho de banda reservado para la cola por el puente, y sendSlope es la tasa de transmisión del servicio MAC del puerto.

Si el crédito es negativo y no se transmiten tramas, el crédito aumenta a la tasa de idleSlope hasta llegar a cero. Si no se puede transmitir una trama AVB porque se está transmitiendo una trama que no es AVB, el crédito se acumula a la tasa de idleSlope , pero se permite un crédito positivo.

Los límites adicionales hiCredit y loCredit se derivan del tamaño máximo de trama y del tamaño máximo de interferencia, la pendiente idleSlope/sendSlope y la tasa máxima de transmisión del puerto.

Los fotogramas de tráfico de transmisión AV reservados se reenvían con alta prioridad sobre el tráfico de mejor esfuerzo no reservado , sujeto a reglas de modelado de tráfico basadas en créditos que pueden requerir que esperen una cierta cantidad de créditos. Esto protege el tráfico de mejor esfuerzo al limitar la ráfaga máxima de transmisión AV. Los fotogramas se programan de manera muy uniforme, aunque solo de forma agregada, para suavizar los tiempos de entrega y reducir las ráfagas y agrupaciones, que pueden provocar desbordamientos de búfer y pérdida de paquetes que desencadenan retransmisiones. El mayor retardo de almacenamiento en búfer hace que los paquetes retransmitidos sean obsoletos para cuando llegan, lo que resulta en pérdida de fotogramas, lo que reduce la calidad de las aplicaciones AV.

Aunque el modelador basado en créditos proporciona una programación justa para los paquetes de baja prioridad y suaviza el tráfico para eliminar la congestión, lamentablemente, el retardo promedio aumenta hasta 250 μs por salto, lo cual es demasiado alto para las aplicaciones de control, mientras que un modelador sensible al tiempo (IEEE 802.1Qbv) tiene un retardo de ciclo fijo de 30  μs a varios milisegundos, y un retardo típico de 125  μs. Derivar límites superiores garantizados para los retardos en TSN no es trivial y actualmente se está investigando, por ejemplo, utilizando el marco matemático Network Calculus. ^{[ 7 ]}

El protocolo de reserva de flujo (SRP) IEEE 802.1Qat es un protocolo distribuido punto a punto que especifica controles de admisión basados ​​en los requisitos de recursos del flujo y los recursos de red disponibles.

SRP reserva recursos y anuncia flujos desde el emisor/origen (hablante) a los receptores/destinos (oyentes); funciona para satisfacer los requisitos de QoS para cada flujo y garantizar la disponibilidad de recursos de red suficientes a lo largo de toda la ruta de transmisión del flujo.

Los flujos de tráfico se identifican y registran con un StreamID de 64 bits , compuesto por la dirección MAC de 48 bits (EUI) y un UniqueID de 16 bits para identificar diferentes flujos de la misma fuente.

SRP emplea variantes del Protocolo de Registro Múltiple (MRP) para registrar y anular el registro de valores de atributos en conmutadores/puentes/dispositivos: el Protocolo de Registro de MAC Múltiple (MMRP), el Protocolo de Registro de VLAN Múltiple (MVRP) y el Protocolo de Registro de Flujo Múltiple (MSRP).

El protocolo SRP funciona esencialmente en la siguiente secuencia:

1. Anunciar una transmisión de un locutor
2. Registrar las rutas a lo largo del flujo de datos
3. Calcular la latencia en el peor de los casos.
4. Crear un dominio AVB
5. Reservar el ancho de banda

Los recursos se asignan y configuran tanto en los nodos finales del flujo de datos como en los nodos de tránsito a lo largo de la ruta del flujo de datos, con un mecanismo de señalización de extremo a extremo para detectar el éxito o el fracaso. La latencia en el peor de los casos se calcula consultando cada puente.

Las solicitudes de reserva utilizan la aplicación MRP general con el mecanismo de propagación de atributos MRP. Todos los nodos a lo largo de la ruta de flujo pasan la especificación de Declaración de Atributos MRP (MAD), que describe las características del flujo para que los puentes puedan asignar los recursos necesarios.

Si un puente puede reservar los recursos necesarios, propaga el anuncio al siguiente puente; de ​​lo contrario, se genera un mensaje de error del emisor . Cuando el mensaje de anuncio llega al receptor, este responde con un mensaje de confirmación de que el receptor está listo , el cual se propaga de vuelta al emisor.

Los mensajes de anuncio del emisor y de listo del oyente pueden darse de baja, lo que finaliza la transmisión.

La reserva exitosa solo está garantizada cuando todos los nodos intermedios admiten SRP y responden a los mensajes de anuncio y listos; en la Figura 2 anterior, el dominio AVB 1 no puede conectarse con el dominio AVB 2.

SRP también es utilizado por los estándares TSN/AVB para prioridades de tramas, programación de tramas y modelado de tráfico.

SRP utiliza un procedimiento de registro y reserva descentralizado; las múltiples solicitudes pueden introducir retrasos para el tráfico crítico. La enmienda IEEE 802.1Qcc-2018 "Mejoras y optimización del rendimiento del protocolo de reserva de flujo (SRP)" reduce el tamaño de los mensajes de reserva y redefine los temporizadores para que activen las actualizaciones solo cuando cambie el estado del enlace o la reserva. Para mejorar la administración de TSN en redes a gran escala, cada Interfaz de red de usuario (UNI) proporciona métodos para solicitar servicios de capa 2, complementados por la Configuración de red centralizada (CNC) para proporcionar reserva y programación centralizadas, y administración remota mediante los protocolos NETCONF/RESTCONF y el modelado de datos IETF YANG/NETCONF .

CNC implementa un modelo de solicitud-respuesta por flujo, donde la clase SR no se utiliza explícitamente: las estaciones finales envían solicitudes para un flujo específico (a través del puerto de borde) sin conocimiento de la configuración de la red, y CNC realiza la reserva de flujo de forma centralizada. MSRP solo se ejecuta en el enlace a las estaciones finales como portador de información entre CNC y las estaciones finales, no para la reserva de flujo. La Configuración Centralizada de Usuario (CUC) es un nodo opcional que descubre las estaciones finales, sus capacidades y requisitos de usuario, y configura las características TSN optimizadas para retardo (para aplicaciones IACS de bucle cerrado ). Se proporciona una interoperabilidad perfecta con el transporte del Protocolo de Reserva de Recursos (RSVP). 802.1Qcc permite que la gestión de configuración centralizada coexista con la configuración descentralizada y totalmente distribuida del protocolo SRP, y también admite configuraciones híbridas para dispositivos AVB heredados.

El estándar 802.1Qcc se puede combinar con el control y reserva de ruta (PCR) y los modeladores de tráfico TSN del estándar IEEE 802.1Qca.

Si bien el estándar 802.1Qav FQTSS/CBS funciona muy bien con tráfico en tiempo real flexible, los retrasos en el peor de los casos dependen tanto del número de saltos como de la topología de la red. Las topologías problemáticas introducen retrasos, por lo que los requisitos de tamaño del búfer deben tener en cuenta la topología de la red.

El protocolo IEEE 802.1Qch de cola y reenvío cíclico (CQF), también conocido como modelador peristáltico (PS), introduce un doble búfer que permite a los puentes sincronizar la transmisión (operaciones de encolamiento/desencolamiento de tramas) de forma cíclica, con una latencia limitada que depende únicamente del número de saltos y del tiempo de ciclo, de forma completamente independiente de la topología de la red.

CQF se puede utilizar con el planificador sensible al tiempo IEEE 802.1Qbv, la preempción de tramas IEEE 802.1Qbu y el control de tráfico de entrada IEEE 802.1Qci.

El filtrado y control de tráfico por flujo (PSFP) de IEEE 802.1Qci mejora la robustez de la red al filtrar flujos de tráfico individuales. Previene la sobrecarga de tráfico que puede afectar a los puentes y a los puntos finales receptores debido a fallos de funcionamiento o ataques de denegación de servicio (DoS). El filtro de flujo utiliza reglas de coincidencia para permitir tramas con identificadores de flujo y niveles de prioridad específicos, y aplica políticas en caso contrario. Todos los flujos se coordinan en sus puertas de enlace, de forma similar a la señalización 802.1Qch. La medición de flujo aplica perfiles de ancho de banda predefinidos para cada flujo.

El planificador de tiempo IEEE 802.1Qbv está diseñado para dividir la comunicación en la red Ethernet en ciclos de tiempo repetitivos de duración fija. Dentro de estos ciclos, se pueden configurar diferentes segmentos de tiempo que se pueden asignar a una o varias de las ocho prioridades de Ethernet. De esta manera, es posible otorgar uso exclusivo —durante un tiempo limitado— al medio de transmisión Ethernet para aquellas clases de tráfico que requieren garantías de transmisión y no pueden interrumpirse. El concepto básico es un esquema de acceso múltiple por división de tiempo (TDMA). Al establecer canales de comunicación virtuales para períodos de tiempo específicos, la comunicación crítica en tiempo real se puede separar del tráfico de fondo no crítico.

El planificador con control de tiempo introduce la clase de reserva de flujo CDT para datos de control críticos en el tiempo, con una latencia en el peor de los casos de 100 μs en 5 saltos y un período de transmisión máximo de 0,5  ms, además de las clases A y B definidas para el modelador de tráfico basado en créditos IEEE 802.1Qav. Al otorgar acceso exclusivo al medio de transmisión y a los dispositivos a las clases de tráfico críticas en el tiempo, se pueden evitar los efectos de almacenamiento en búfer en los búferes de transmisión del conmutador Ethernet y el tráfico crítico en el tiempo se puede transmitir sin interrupciones no deterministas. Un ejemplo de configuración de planificador IEEE 802.1Qbv se muestra en la figura 1:

En este ejemplo, cada ciclo consta de dos segmentos de tiempo. El segmento 1 solo permite la transmisión de tráfico etiquetado con prioridad VLAN 3, y el segmento 2 permite el envío del resto de las prioridades. Dado que el planificador IEEE 802.1Qbv requiere que todos los relojes de todos los dispositivos de red (conmutadores Ethernet y dispositivos finales) estén sincronizados y que se configure la misma planificación, todos los dispositivos comprenden qué prioridad se puede enviar a la red en cualquier momento. Como al segmento 2 se le asigna más de una prioridad, dentro de este segmento, las prioridades se gestionan según la planificación de prioridad estricta estándar IEEE 802.1Q.

Esta separación de las transmisiones Ethernet en ciclos y segmentos de tiempo puede mejorarse aún más mediante la inclusión de otros algoritmos de planificación o modelado de tráfico, como el modelador de tráfico basado en créditos IEEE 802.1Qav. IEEE 802.1Qav admite tiempo real flexible. En este ejemplo concreto, IEEE 802.1Qav podría asignarse a una o dos de las prioridades utilizadas en el segundo segmento de tiempo para diferenciar aún más entre el tráfico de audio/vídeo y las transferencias de archivos en segundo plano. El Grupo de Trabajo de Redes Sensibles al Tiempo especifica varios planificadores y modeladores de tráfico que pueden combinarse para lograr la coexistencia no reactiva de tiempo real estricto, tiempo real flexible y tráfico en segundo plano en la misma infraestructura Ethernet.

Cuando una interfaz Ethernet inicia la transmisión de una trama al medio de transmisión, esta debe finalizar por completo antes de que pueda iniciarse otra transmisión. Esto incluye la transmisión de la suma de verificación CRC-32 al final de la trama para garantizar una transmisión fiable y sin fallos. Esta propiedad inherente de las redes Ethernet supone, una vez más, un desafío para el enfoque TDMA del planificador IEEE 802.1Qbv. Esto se observa en la figura 2:

Justo antes de que finalice el intervalo de tiempo 2 del ciclo n, se inicia la transmisión de una nueva trama. Desafortunadamente, esta trama es demasiado grande para caber en su intervalo de tiempo. Dado que la transmisión de esta trama no puede interrumpirse, infringe el siguiente intervalo de tiempo 1 del siguiente ciclo n+1. Al bloquear parcial o totalmente un intervalo de tiempo crítico, las tramas en tiempo real pueden retrasarse hasta el punto de no cumplir con los requisitos de la aplicación. Esto es muy similar a los efectos de almacenamiento en búfer que ocurren en los conmutadores Ethernet que no son TSN, por lo que TSN debe especificar un mecanismo para evitar que esto suceda.

El planificador con control de tiempo IEEE 802.1Qbv debe garantizar que la interfaz Ethernet no esté ocupada con la transmisión de una trama cuando el planificador cambia de un segmento de tiempo al siguiente. El planificador con control de tiempo logra esto colocando una banda de guarda delante de cada segmento de tiempo que transporta tráfico crítico en el tiempo. Durante este tiempo de banda de guarda, no se puede iniciar la transmisión de ninguna nueva trama Ethernet; solo se pueden finalizar las transmisiones que ya están en curso. La duración de esta banda de guarda debe ser igual al tamaño máximo de trama que se puede transmitir de forma segura. Para una trama Ethernet según IEEE 802.3 con una sola etiqueta VLAN IEEE 802.1Q e incluyendo el espaciado entre tramas , la longitud total es: 1500 bytes (carga útil de la trama) + 18 bytes (direcciones Ethernet, EtherType y CRC) + 4 bytes (etiqueta VLAN) + 12 bytes (espaciado entre tramas) + 8 bytes (preámbulo y SFD) = 1542 bytes.

El tiempo total necesario para enviar esta trama depende de la velocidad de enlace de la red Ethernet. Con Fast Ethernet y una velocidad de transmisión de 100 Mbit/s , la duración de la transmisión es la siguiente:

${\displaystyle t_{\text{maxframe}}={\frac {1542{\text{ byte}}}{12.5\cdot 10^{6}{\text{ byte}}\cdot {\frac {1}{s}}}}=123.36\cdot 10^{-6}s}$

En este caso, la banda de guarda debe tener una  longitud mínima de 123,36 μs. Con la banda de guarda, el ancho de banda total o el tiempo utilizable dentro de una sección temporal se reduce en la longitud de la banda de guarda. Esto se puede observar en la figura 3.

Nota: para facilitar la presentación del tema, el tamaño real de la banda de guarda en la figura 3 no está a escala, sino que es significativamente menor que el indicado por el marco en la figura 2.

En este ejemplo, el segmento de tiempo 1 siempre contiene datos de alta prioridad (por ejemplo, para el control de movimiento), mientras que el segmento de tiempo 2 siempre contiene datos de mejor esfuerzo. Por lo tanto, es necesario colocar una banda de guarda en cada punto de transición al segmento de tiempo 1 para proteger el segmento de tiempo del flujo de datos crítico.

Si bien las bandas de guarda logran proteger los intervalos de tiempo con tráfico crítico y de alta prioridad, también presentan algunos inconvenientes importantes:

• El tiempo que consume la banda de guarda se pierde, ya que no se puede utilizar para transmitir datos, puesto que el puerto Ethernet debe permanecer inactivo. Por lo tanto, este tiempo perdido se traduce directamente en una pérdida de ancho de banda para el tráfico de fondo en ese enlace Ethernet en particular.
• Nunca se puede configurar un intervalo de tiempo menor que el tamaño de la banda de guarda. Especialmente con conexiones Ethernet de baja velocidad y un tamaño de banda de guarda cada vez mayor, esto tiene un impacto negativo en la duración mínima alcanzable del intervalo de tiempo y en el tiempo de ciclo.

Para mitigar parcialmente la pérdida de ancho de banda a través de la banda de guarda, el estándar IEEE 802.1Qbv incluye un mecanismo de planificación que tiene en cuenta la longitud. Este mecanismo se utiliza cuando se emplea la conmutación de almacenamiento y reenvío : tras la recepción completa de una trama Ethernet que debe transmitirse en un puerto con la banda de guarda activa, el planificador comprueba la longitud total de la trama. Si la trama cabe completamente dentro de la banda de guarda, sin infringir la siguiente porción de alta prioridad, el planificador puede enviarla, a pesar de la banda de guarda activa, y reducir el desperdicio de ancho de banda. Sin embargo, este mecanismo no se puede utilizar cuando la conmutación de corte directo está habilitada, ya que la longitud total de la trama Ethernet debe conocerse de antemano. Por lo tanto, cuando se utiliza la conmutación de corte directo para minimizar la latencia de extremo a extremo, el desperdicio de ancho de banda persistirá. Además, esto no ayuda a lograr el tiempo de ciclo mínimo. En consecuencia, la planificación que tiene en cuenta la longitud supone una mejora, pero no puede mitigar todos los inconvenientes que introduce la banda de guarda.

Para mitigar aún más los efectos negativos de las bandas de guarda, los grupos de trabajo IEEE 802.1 y 802.3 especificaron la tecnología de preemption de tramas. Ambos grupos colaboraron en este esfuerzo, ya que la tecnología requería cambios tanto en el esquema de control de acceso al medio (MAC) de Ethernet , que está bajo el control de IEEE 802.3, como en los mecanismos de gestión, que están bajo el control de IEEE 802.1. Por este motivo, la preemption de tramas se describe en dos documentos de estándares diferentes: IEEE 802.1Qbu ^{[ 8 ]} para el componente de gestión de puentes e IEEE 802.3br ^{[ 9 ]} para el componente MAC de Ethernet.

La prioridad de trama define dos servicios MAC para un puerto de salida: MAC con prioridad (pMAC) y MAC exprés (eMAC). Las tramas exprés pueden interrumpir la transmisión de tramas con prioridad. Al reanudarse la transmisión, la subcapa de fusión MAC recombina los fragmentos de trama en el siguiente puente.

La interrupción genera una sobrecarga computacional en la interfaz de enlace, ya que el contexto operativo debe pasar a la trama exprés.

La figura 4 muestra un ejemplo básico de cómo funciona la preempción de tramas. Durante el envío de una trama Ethernet de mejor esfuerzo, la MAC interrumpe la transmisión justo antes del inicio de la banda de guarda. La trama parcial se completa con un CRC y se almacena en el siguiente conmutador a la espera de la llegada de la segunda parte. Una vez que el tráfico de alta prioridad del segmento de tiempo 1 ha pasado y el ciclo vuelve al segmento de tiempo 2, se reanuda la transmisión de la trama interrumpida. La preempción de tramas siempre opera de forma puramente enlace por enlace y solo fragmenta la trama de un conmutador Ethernet al siguiente, donde se vuelve a ensamblar. A diferencia de la fragmentación del Protocolo de Internet (IP) , no se admite la fragmentación de extremo a extremo.

Cada trama parcial se completa con un CRC-32 para la detección de errores. A diferencia del CRC-32 Ethernet estándar, los últimos 16 bits se invierten para distinguir una trama parcial de una trama Ethernet normal. Además, se modifica el delimitador de inicio de trama (SFD).

La compatibilidad con la preemption de tramas debe activarse individualmente en cada enlace entre dispositivos. Para indicar la capacidad de preemption de tramas en un enlace, un conmutador Ethernet anuncia esta capacidad mediante el protocolo LLDP (Link Layer Discovery Protocol) . Cuando un dispositivo recibe dicho anuncio LLDP en un puerto de red y admite la preemption de tramas, puede activar la capacidad. No existe negociación ni activación directa de la capacidad en dispositivos adyacentes. Cualquier dispositivo que reciba el anuncio de preemption LLDP asume que en el otro extremo del enlace hay un dispositivo que puede interpretar los cambios en el formato de la trama (CRC-32 y SFD modificados).

La preempción de tramas permite una reducción significativa de la banda de guarda. La longitud de la banda de guarda depende ahora de la precisión del mecanismo de preempción de tramas: el tamaño mínimo de la trama que el mecanismo aún puede preempcionar. IEEE 802.3br especifica la precisión óptima para este mecanismo en 64 bytes , debido a que este es el tamaño mínimo de una trama Ethernet válida. En este caso, la banda de guarda se puede reducir a un total de 127 bytes: 64 bytes (trama mínima) + 63 bytes (longitud restante que no se puede preempcionar). Todas las tramas de mayor tamaño se pueden preempcionar de nuevo y, por lo tanto, no es necesario protegerlas con una banda de guarda. 

Esto minimiza la pérdida de ancho de banda de mejor esfuerzo y permite tiempos de ciclo mucho más cortos a velocidades Ethernet más bajas, como 100 Mbit/s o inferiores. Dado que la preempción se realiza mediante hardware en la MAC, a medida que la trama pasa, también se puede admitir la conmutación de corte, ya que no se necesita conocer el tamaño total de la trama a priori. La interfaz MAC simplemente comprueba a intervalos regulares de 64 bytes si la trama necesita ser preemptivada o no.

La combinación de sincronización horaria, el planificador IEEE 802.1Qbv y la preemption de tramas ya constituye un conjunto eficaz de estándares que pueden utilizarse para garantizar la coexistencia de diferentes categorías de tráfico en una red, a la vez que proporcionan garantías de latencia de extremo a extremo. Esto se mejorará aún más a medida que se finalicen las nuevas especificaciones IEEE 802.1, como la 802.1Qch.

En general, el planificador con control de tiempo presenta una alta complejidad de implementación y su uso del ancho de banda es ineficiente. La planificación de tareas y eventos en los puntos finales debe combinarse con la planificación de puertas del modelador de tráfico para reducir las latencias. Una deficiencia crítica es que se produce cierto retraso cuando un punto final transmite datos no sincronizados, debido al tiempo de espera para la siguiente ventana de activación por tiempo.

El planificador con control de tiempo requiere una sincronización precisa de sus ventanas de activación por tiempo, por lo que todos los puentes en la ruta de transmisión deben estar sincronizados. Sin embargo, sincronizar la selección de tramas del puente TSN y el tiempo de transmisión no es una tarea sencilla, incluso en redes de tamaño moderado, y requiere una solución totalmente gestionada.

La priorización de marcos es difícil de implementar y no ha contado con un amplio apoyo de la industria.

Los modeladores de tráfico basados ​​en créditos, sensibles al tiempo y cíclicos (peristálticos) requieren una sincronización horaria en toda la red y utilizan el ancho de banda de forma ineficiente, ya que imponen la transmisión de paquetes en ciclos periódicos. El modelador de tráfico asíncrono (ATS) IEEE 802.1Qcr funciona de forma asíncrona basándose en relojes locales en cada puente, lo que mejora la utilización del enlace para tipos de tráfico mixtos, como el periódico con periodos arbitrarios, el esporádico (basado en eventos) y el de velocidad restringida.

ATS emplea el planificador basado en urgencias (UBS), que prioriza el tráfico urgente mediante colas por clase y remodelación por flujo. La asincronía se logra mediante la modelación intercalada con caracterización de tráfico basada en la emulación de cubo de tokens (TBE), un modelo de emulación de cubo de tokens , para eliminar los efectos de cascada de ráfagas de la modelación por clase. El modelador TBE controla el tráfico mediante la tasa de transmisión promedio, pero permite cierto nivel de tráfico en ráfagas. Cuando hay una cantidad suficiente de tokens en el cubo, la transmisión comienza inmediatamente; de ​​lo contrario, la puerta de la cola se cierra durante el tiempo necesario para acumular suficientes tokens.

El UBS es una mejora de las Disciplinas de Servicio con Control de Tasa (RCSD) para controlar la selección y transmisión de cada trama individual en cada salto, desacoplando el ancho de banda del flujo del retardo limitado por la separación del control de tasa y la programación de paquetes, y utilizando prioridades estáticas y colas de Primero en Llegar, Primero en Servir y Fecha de Vencimiento Más Temprana, Primero.

El sistema de colas UBS tiene dos niveles de jerarquía: colas con modelado por flujo, con prioridad fija asignada por las fuentes ascendentes según los tiempos de transmisión de paquetes definidos por la aplicación, lo que permite un período de transmisión arbitrario para cada flujo; y colas compartidas que combinan flujos con la misma prioridad interna provenientes de varios modeladores. Esta separación de colas tiene una baja complejidad de implementación, al tiempo que garantiza que los fotogramas de mayor prioridad omitan los de menor prioridad.

Las colas compartidas están altamente aisladas, con políticas para colas separadas para tramas de diferentes transmisores, el mismo transmisor pero con diferente prioridad, y el mismo transmisor y prioridad pero con una prioridad diferente en el receptor. El aislamiento de colas evita la propagación de datos maliciosos, asegurando que las transmisiones normales no sufran interferencias, y permite el bloqueo flexible de transmisiones o transmisores mediante acciones administrativas. El número mínimo de colas compartidas es el número de puertos menos uno, y puede ser mayor con políticas de aislamiento adicionales. Las colas compartidas tienen una prioridad fija interna del planificador, y las tramas se transmiten según el principio de Primero en Llegar, Primero en Ser Atendido (FISA).

En el peor de los casos, la imprecisión en la sincronización del reloj no disminuye la utilización del enlace, a diferencia de los enfoques basados ​​en el tiempo, como TAS (Qbv) y CQF (Qch).

El estándar IEEE 802.1Qca Path Control and Reservation (PCR) especifica extensiones al protocolo Intermediate Station to Intermediate Station (IS-IS) para configurar múltiples rutas en redes conmutadas.

El estándar IEEE 802.1Qca utiliza el protocolo Shortest Path Bridging (SPB) con un modo híbrido de redes definidas por software (SDN): el protocolo IS-IS gestiona las funciones básicas, mientras que el controlador SDN gestiona las rutas explícitas mediante elementos de cálculo de rutas (PCE) en nodos de servidor dedicados. IEEE 802.1Qca integra protocolos de control para gestionar múltiples topologías, configurar una ruta de reenvío explícita (una ruta predefinida para cada flujo), reservar ancho de banda, proporcionar protección y redundancia de datos, y distribuir mensajes de sincronización y control de flujo. Estos protocolos se derivan de los protocolos Equal Cost Tree (ECT), Multiple Spanning Tree Instance (MSTI), Internal Spanning Tree (IST) y Explicit Tree (ET).

El sistema IEEE 802.1CB de replicación y eliminación de tramas para la fiabilidad (FRER) envía copias duplicadas de cada trama a través de múltiples rutas disjuntas para proporcionar una redundancia proactiva y sin interrupciones para las aplicaciones de control que no pueden tolerar la pérdida de paquetes.

La replicación de paquetes puede utilizar información sobre la clase de tráfico y la ruta para minimizar la congestión de la red. Cada trama replicada tiene un número de identificación de secuencia, que se utiliza para reordenar y fusionar tramas y para descartar duplicados.

FRER requiere una gestión de configuración centralizada y debe utilizarse con 802.1Qcc y 802.1Qca. Se admiten las funciones HSR y PRP de tolerancia a fallos industriales especificadas en la norma IEC 62439-3.

Los datos de estado MRP para un flujo ocupan 1500 bytes. Con flujos de tráfico adicionales y redes más grandes, el tamaño de la base de datos aumenta proporcionalmente y las actualizaciones MRP entre vecinos de puente se ralentizan significativamente. El Protocolo de Registro Local de Enlace (LRP) está optimizado para una base de datos de mayor tamaño, de aproximadamente 1  MB, con una replicación eficiente que permite actualizaciones incrementales. Los nodos que no responden y cuyos datos están desactualizados se descartan automáticamente. Mientras que MRP es específico de la aplicación, y cada aplicación registrada define su propio conjunto de operaciones, LRP es independiente de la aplicación.

SRP y MSRP están diseñados principalmente para aplicaciones AV; su modelo de configuración distribuida se limita a las clases A y B de reserva de flujo (SR) definidas por el modelador basado en créditos (CBS), mientras que IEEE 802.1Qcc incluye un modelo de configuración CNC más centralizado que admite todas las nuevas características TSN, como modeladores adicionales, preempción de tramas y redundancia de ruta.

El proyecto IEEE P802.1Qdd actualiza el modelo de configuración distribuida mediante la definición de un nuevo protocolo de asignación de recursos (RAP) entre pares, basado en el protocolo de registro local de enlace P802.1CS. El RAP mejorará la escalabilidad y proporcionará una reserva dinámica para un mayor número de flujos, con soporte para la transmisión redundante a través de múltiples rutas en 802.1CB FRER y la autoconfiguración de la recuperación de secuencia.

RAP admite la capacidad de cálculo de latencia por salto independiente de la topología de los modeladores de TSN, como 802.1Qch Cyclic Queuing and Forwarding (CQF) y P802.1Qcr Asynchronous Traffic Shaping (ATS). Además, mejorará el rendimiento bajo cargas elevadas y admitirá el uso de proxy y diagnósticos mejorados, manteniendo la compatibilidad con versiones anteriores y la interoperabilidad con MSRP.

IEEE P802.1ABdh Station and Media Access Control Connectivity Discovery - Support for Multiframe Protocol Data Units (LLDPv2) ^{[ 10 ] [ 11 ]} actualiza LLDP para admitir el protocolo de enrutamiento de vector de estado de enlace IETF ^{[ 12 ]} y mejorar la eficiencia de los mensajes del protocolo.

El estándar IEEE 802.1Qcp implementa el modelo de datos YANG para proporcionar un marco Universal Plug-and-Play (uPnP) para la notificación de estado y la configuración de equipos como puentes de control de acceso a medios (MAC), relés MAC de dos puertos (TPMR), puentes de red de área local virtual (VLAN) de clientes y puentes de proveedores, y para admitir los estándares de seguridad 802.1X y de interconexión de centros de datos 802.1AX.

YANG es un lenguaje de modelado unificado (UML) para datos de configuración y estado, notificaciones y llamadas a procedimientos remotos, para configurar dispositivos con protocolos de administración de red como NETCONF/RESTCONF.

El Grupo de Trabajo de Redes Deterministas (DetNet) de la IETF se centra en definir rutas de datos deterministas con alta fiabilidad y límites en la latencia, la pérdida y la variación del retardo de los paquetes (fluctuación), como la transmisión de audio y vídeo, la automatización industrial y el control de vehículos.

Los objetivos de DetNet son migrar aplicaciones industriales y de audio y vídeo críticas en tiempo real y de alta fiabilidad desde redes Fieldbus especializadas a redes de paquetes IP . Para lograrlo, DetNet utiliza la asignación de recursos para gestionar el tamaño de los búferes y las tasas de transmisión, con el fin de cumplir con los requisitos de latencia de extremo a extremo. La protección del servicio contra fallos se logra mediante redundancia en múltiples rutas y rutas explícitas para reducir la pérdida y el reordenamiento de paquetes. La misma red física gestionará tanto el tráfico reservado crítico en tiempo real como el tráfico regular de mejor esfuerzo, y el ancho de banda reservado no utilizado se liberará para el tráfico de mejor esfuerzo.

DetNet opera en los segmentos enrutados de la capa 3 de IP utilizando una capa de red definida por software para proporcionar integración IntServ y DiffServ , y ofrece servicios sobre segmentos puenteados de la capa 2 inferior utilizando tecnologías como MPLS e IEEE 802.1 AVB/TSN. ^{[ 13 ]}

Los protocolos de enrutamiento de ingeniería de tráfico (TE) traducen la especificación de flujo DetNet a controles AVB/TSN para algoritmos de cola, modelado y programación, como el modelador basado en crédito IEEE 802.1Qav, el modelador activado por tiempo IEEE 802.1Qbv con un programador de tiempo rotativo, el doble búfer sincronizado IEEE 802.1Qch, la preempción de paquetes Ethernet 802.1Qbu/802.3br y la replicación y eliminación de tramas 802.1CB para mayor confiabilidad. Además, la interoperabilidad de protocolos definida por IEEE 802.1CB se utiliza para anunciar las capacidades de la subred TSN a los flujos DetNet a través de las funciones de identificación de flujo VLAN y MAC de destino activo. Los flujos DetNet se asocian mediante la dirección MAC de destino, el ID de VLAN y los parámetros de prioridad con el ID de flujo y los requisitos de QoS para emisores y receptores en la subred AVB/TSN. ^{[ 14 ]}