De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

Time-Sensitive Networking ( TSN ) es un conjunto de estándares en desarrollo por el grupo de tareas Time-Sensitive Networking del grupo de trabajo IEEE 802.1 . [1] El grupo de tareas de TSN se formó en noviembre de 2012 al cambiar el nombre del Grupo de tareas de puente de audio y vídeo existente [2] y continuar su trabajo. El nombre cambió como resultado de la extensión del área de trabajo del grupo de estandarización. Los estándares definen mecanismos para la transmisión de datos sensibles al tiempo a través de redes Ethernet deterministas .

La mayoría de los proyectos definen extensiones para IEEE 802.1Q  - Bridges and Bridged Networks, que describe LAN virtuales y conmutadores de red . [3] Estas extensiones, en particular, abordan la transmisión de latencia de transmisión muy baja y alta disponibilidad. Las aplicaciones incluyen redes convergentes con transmisión de audio / video en tiempo real y flujos de control en tiempo real que se utilizan en instalaciones de control industrial o automotriz.

Antecedentes [ editar ]

Los equipos de red de TI estándar no tienen el concepto de "tiempo" y no pueden proporcionar sincronización y sincronización de precisión. La entrega de datos de manera confiable es más importante que la entrega dentro de un tiempo específico, por lo que no hay restricciones en cuanto a demoras o precisión de sincronización. Incluso si la demora de salto promedio es muy baja, las demoras individuales pueden ser inaceptablemente altas. La congestión de la red se maneja estrangulando y retransmitiendo los paquetes descartados en la capa de transporte, pero no existen medios para evitar la congestión en la capa de enlace. Los datos se pueden perder cuando los búferes son demasiado pequeños o el ancho de banda es insuficiente, pero el almacenamiento en búfer excesivo aumenta el retraso, lo cual es inaceptable cuando se requieren retrasos deterministas bajos.

Los diferentes documentos de estándares AVB / TSN especificados por IEEE 802.1 se pueden agrupar en tres categorías básicas de componentes clave que se requieren para una solución completa de comunicación en tiempo real basada en redes Ethernet conmutadas con calidad de servicio (QoS) determinista para punto a punto. conexiones. Todas y cada una de las especificaciones estándar se pueden utilizar por sí solas y, en su mayoría, son autosuficientes. Sin embargo, solo cuando se usan juntos de manera concertada, TSN como sistema de comunicación puede alcanzar su máximo potencial. Los tres componentes básicos son:

  1. Sincronización de tiempo: todos los dispositivos que participan en la comunicación en tiempo real deben tener una comprensión común del tiempo.
  2. Programación y modelado del tráfico: todos los dispositivos que participan en la comunicación en tiempo real se adhieren a las mismas reglas en el procesamiento y reenvío de paquetes de comunicación.
  3. Selección de rutas de comunicación, reservas de ruta y tolerancia a fallas: todos los dispositivos que participan en la comunicación en tiempo real se adhieren a las mismas reglas en la selección de rutas de comunicación y en la reserva de ancho de banda y ranuras de tiempo, posiblemente utilizando más de una ruta simultánea para lograr fallas. tolerancia

Las aplicaciones que necesitan una red determinista que se comporte de manera predecible incluyen audio y video, inicialmente definidos en Audio Video Bridging (AVB); redes de control que aceptan entradas de sensores, realizan procesamiento de bucle de control e inician acciones; redes críticas para la seguridad que implementan redundancia de paquetes y enlaces; y redes de medios mixtos que manejan datos con diferentes niveles de sensibilidad y prioridad de sincronización, como redes de vehículos que admiten control de clima, infoentretenimiento, electrónica corporal y asistencia al conductor. La suite IEEE AVB / TSN sirve como base para redes deterministas para satisfacer los requisitos comunes de estas aplicaciones.

AVB / TSN puede manejar tráfico con restricción de velocidad, donde cada flujo tiene un límite de ancho de banda definido por intervalos mínimos entre cuadros y tamaño máximo de cuadro, y tráfico de activación por tiempo con una hora exacta exacta para ser enviada. El tráfico de baja prioridad se transmite sobre la base del mejor esfuerzo, sin garantías de tiempo y entrega.

Sincronización de tiempo [ editar ]

A diferencia de Ethernet estándar según IEEE 802.3 y puente Ethernet según IEEE 802.1Q , el tiempo es muy importante en las redes TSN. Para la comunicación en tiempo real con límites de tiempo estrictos y no negociables para latencias de transmisión de extremo a extremo, todos los dispositivos de esta red deben tener una referencia de tiempo común y, por lo tanto, deben sincronizar sus relojes entre sí. Esto no solo es cierto para los dispositivos finales de un flujo de comunicación, como un controlador industrial y un robot de fabricación, sino también para los componentes de red, como los conmutadores Ethernet.. Solo a través de relojes sincronizados, es posible que todos los dispositivos de red funcionen al unísono y ejecuten la operación requerida exactamente en el momento requerido. Aunque la sincronización de la hora en las redes TSN se puede lograr con el reloj GPS , esto es costoso y no hay garantía de que el dispositivo de punto final tenga acceso a la señal de radio o satélite en todo momento. Debido a estas limitaciones, el tiempo en las redes TSN generalmente se distribuye desde una fuente de tiempo central directamente a través de la propia red utilizando el Protocolo de tiempo de precisión IEEE 1588 , que utiliza tramas Ethernet para distribuir información de sincronización de tiempo. IEEE 802.1ASes un subconjunto estrictamente restringido de IEEE 1588 con una precisión de menos de microsegundos y extensiones para admitir la sincronización a través de radio WiFi ( IEEE 802.11 ). La idea detrás de este perfil es reducir la enorme lista de diferentes opciones de IEEE 1588 a unas pocas opciones críticas manejables que son aplicables a redes domésticas o redes en entornos de automatización industrial o automotriz.

Sincronización y temporización IEEE 802.1AS para aplicaciones sensibles al tiempo [ editar ]

Figura 3 - Jerarquía de reloj 802.1AS

IEEE 802.1AS-2011 define el perfil del Protocolo de tiempo de precisión genérico (gPTP) que emplea mensajes UDP para establecer una jerarquía de relojes y sincronizar el tiempo en un dominio gPTP formado por dispositivos que intercambian eventos de tiempo.

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 (un tiempo necesario para el procesamiento, la puesta en cola y la transmisión desde los puertos de entrada a los de salida) y la latencia del enlace de cada salto (un retraso de propagación entre dos puentes adyacentes). ). Luego, los retrasos calculados se referencian al reloj GrandMaster (GM) en un puente elegido por el mejor algoritmo de reloj maestro, un protocolo de árbol de expansión de reloj con el que todos los dispositivos de punto final y reloj maestro (CM) tienen que sincronizarse. Cualquier dispositivo que no se sincronice con los mensajes de temporización está fuera de los límites del dominio de temporización (Figura 2).

Figura 2 - Conexiones AVB

La precisión de la sincronización depende de mediciones precisas del retardo del enlace y el tiempo de residencia de la trama. 802.1AS usa 'sinonización lógica', donde se usa una relación entre el reloj local y las frecuencias del oscilador del reloj GM para calcular el tiempo sincronizado, y una relación entre las frecuencias del reloj local y CM para calcular el retardo de propagación.

IEEE802.1AS-2020 presenta una precisión de medición de tiempo mejorada y soporte para múltiples dominios de tiempo para redundancia.

Programación y modelado del tráfico [ editar ]

La programación y el modelado del tráfico permiten la coexistencia de diferentes clases de tráfico con diferentes prioridades en la misma red, cada una con diferentes requisitos de ancho de banda disponible y latencia de un extremo a otro.

El modelado del tráfico se refiere al proceso de distribución de tramas / paquetes de manera uniforme en el tiempo para suavizar el tráfico. Sin la configuración del tráfico en las fuentes y los puentes, los paquetes se "agruparán", es decir, se aglomerarán en ráfagas de tráfico, abrumando las memorias intermedias en los siguientes puentes / conmutadores a lo largo del camino.

El puenteo estándar de acuerdo con IEEE 802.1Q utiliza un esquema de prioridad estricto con ocho prioridades distintas. A nivel de protocolo, estas prioridades son visibles en el campo Priority Code Point (PCP) en la etiqueta VLAN 802.1Q de una trama Ethernet estándar.. Estas prioridades ya distinguen entre el tráfico de red más importante y el menos importante, pero incluso con la más alta de las ocho prioridades, no se puede ofrecer una garantía absoluta de un tiempo de entrega de un extremo a otro. La razón de esto son los efectos de almacenamiento en búfer dentro de los conmutadores Ethernet. Si un conmutador ha iniciado la transmisión de una trama Ethernet en uno de sus puertos, incluso la trama de mayor prioridad tiene que esperar dentro del búfer del conmutador para que finalice esta transmisión. Con la conmutación Ethernet estándar, este no determinismo no se puede evitar. Esto no es un problema en entornos donde las aplicaciones no dependen de la entrega oportuna de tramas Ethernet individuales, como las infraestructuras de TI de la oficina. En estos entornos, las transferencias de archivos,Los correos electrónicos u otras aplicaciones comerciales tienen una sensibilidad de tiempo limitada y generalmente están protegidos por otros mecanismos más arriba en la pila de protocolos, como elTransmission Control Protocol. In industrial automation (Programmable Logic Controller (PLC) with an industrial robot) and automotive car environments, where closed loop control or safety applications are using the Ethernet network, reliable and timely delivery is of utmost importance. AVB/TSN enhances standard Ethernet communication by adding mechanisms to provide different time slices for different traffic classes and ensure timely delivery with soft and hard real-time requirements of control system applications. The mechanism of utilizing the eight distinct VLAN priorities is retained, to ensure complete backward compatibility to non-TSN Ethernet. To achieve transmission times with guaranteed end-to-end latency, one or several of the eight Ethernet priorities can be individually assigned to already existing methods (such as the IEEE 802.1Q strict priority scheduler) or new processing methods, such as the IEEE 802.1Qav credit-based traffic shaper, IEEE 802.1Qbv time-aware shaper, [4] or IEEE 802.1Qcr asynchronous shaper.

Time-sensitive traffic has several priority classes. For credit-based shaper 802.1Qav, Stream Reservation Class A is the highest priority, with a worst-case latency requirement of 2 ms, and maximum transmission period of 125 μs; Class B has the second-highest priority with worst-case latency of 50 ms, and a maximum transmission period of 250 μs. Traffic classes shall not exceed their preconfigured maximum bandwidth (75% for audio and video applications). The maximum number of hops is 7. The per-port peer delay provided by gPTP and the network bridge residence delay are added to calculate the accumulated delays and ensure the latency requirement is met. Control traffic has the third-highest priority and includes gPTP and SRP traffic. Time-aware scheduler 802.1Qbv introduces Class CDT for realtime control data from sensors and command streams to actuators, with worst-case latency of 100 μs over 5 hops, and a maximum transmission period of 0.5 ms. Class CDT takes the highest priority over classes A, B, and control traffic.

AVB credit-based scheduler[edit]

IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams[edit]

IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams defines traffic shaping using priority classes, which is based on a simple form of "leaky bucket" credit-based fair queuing. 802.1Qav is designed to reduce buffering in receiving bridges and endpoints.

The credit-based shaper defines credits in bits for two separate queues, dedicated to Class A and Class B traffic. Frame transmission is only allowed when credit is non-negative; during transmission the credit decreases at a rate called sendSlope: . The credit increases at a rate idleSlope if frames are waiting for other queues to be transmitted: . Thus the idleSlope is the bandwidth reserved for the queue by the bridge, and the sendSlope is the transmission rate of the port MAC service.

If the credit is negative and no frames are transmitted, credit increases at idleSlope rate until zero is reached. If an AVB frame cannot be transmitted because a non-AVB frame is in transmission, credit accumulates at idleSlope rate but positive credit is allowed.

Additional limits hiCredit and loCredit are derived from the maximum frame size and maximum interference size, the idleSlope/sendSlope, and the maximum port transmission rate.

Figure 4 – Example Qav traffic shaping

Reserved AV stream traffic frames are forwarded with high priority over non-reserved Best Effort traffic, subject to credit-based traffic shaping rules which may require them to wait for certain amount of credits. This protects best-effort traffic by limiting maximum AV stream burst. The frames are scheduled very evenly, though only on an aggregate basis, to smooth out the delivery times and reduce bursting and bunching, which can lead to buffer overflows and packet drops that trigger retransmissions. The increased buffering delay makes re-transmitted packets obsolete by the time they arrive, resulting in frame drops which reduces the quality of AV applications.

Though credit-based shaper provides fair scheduling for low-priority packets and smooths out traffic to eliminate congestion, unfortunately, average delay increases up to 250 μs per hop, which is too high for control applications, whereas a time-aware shaper (IEEE 802.1Qbv) has a fixed cycle delay from 30 μs to several milliseconds, and typical delay of 125 μs. Deriving save guarantees for worst-case delays in TSN in non-trivial and is currently being researched, e.g., by using the mathematical framework Network Calculus.[5]

IEEE 802.1Qat Stream Reservation Protocol[edit]

IEEE 802.1Qat Stream Reservation Protocol (SRP) is a distributed peer-to-peer protocol that specifies admission controls based on resource requirements of the flow and available network resources.

SRP reserves resources and advertises streams from the sender/source (talker) to the receivers/destinations (listeners); it works to satisfy QoS requirements for each stream and guarantee the availability of sufficient network resources along the entire flow transmission path.

The traffic streams are identified and registered with a 64-bit StreamID, made up of the 48-bit MAC address (EUI) and 16-bit UniqueID to identify different streams from the one source.

SRP employs variants of Multiple Registration Protocol (MRP) to register and de-register attribute values on switches/bridges/devices - the Multiple MAC Registration Protocol (MMRP), the Multiple VLAN Registration Protocol (MVRP), and the Multiple Stream Registration Protocol (MSRP).

The SRP protocol essentially works in the following sequence:

  1. Advertise a stream from a talker
  2. Register the paths along data flow
  3. Calculate worst-case latency
  4. Create an AVB domain
  5. Reserve the bandwidth

Resources are allocated and configured in both the end nodes of the data stream and the transit nodes along the data flow path, with an end-to-end signaling mechanism to detect the success/failure. Worst-case latency is calculated by querying every bridge.

Reservation requests use the general MRP application with MRP attribute propagation mechanism. All nodes along the flow path pass the MRP Attribute Declaration (MAD) specification which describes the stream characteristics so that bridges could allocate the necessary resources.

Figure 5 – Successful reservation (talker advertise)
Figure 6 – Reservation acknowledge (listener ready)

If a bridge is able to reserve the required resources, it propagates the advertisement to the next bridge; otherwise, a 'talker failed' message is raised. When the advertise message reaches the listener, it replies with 'listener ready' message that propagates back to the talker.

Talker advertise and listener ready messages can be-de-registered, which terminates the stream.

Successful reservation is only guaranteed when all intermediate nodes support SRP and respond to advertise and ready messages; in Figure 2 above, AVB domain 1 is unable to connect with AVB domain 2.

SRP is also used by TSN/AVB standards for frame priorities, frame scheduling, and traffic shaping

Enhancements to AVB scheduling[edit]

IEEE 802.1Qcc Enhancements to SRP[edit]

SRP uses decentralized registration and reservation procedure, multiple requests can introduce delays for critical traffic. IEEE 802.1Qcc-2018 "Stream Reservation Protocol (SRP) Enhancements and Performance Improvements" amendment reduces the size of reservation messages and redefines timers so they trigger updates only when link state or reservation is changed. To improve TSN administration on large scale networks, each User Network Interface (UNI) provides methods for requesting Layer 2 services, supplemented by Centralized Network Configuration (CNC) to provide centralized reservation and scheduling, and remote management using NETCONF/RESTCONF protocols and IETF YANG/NETCONF data modeling.

CNC implements a per-stream request-response model, where SR class is not explicitly used: end-stations send requests for a specific stream (via edge port) without knowledge of the network configuration, and CNC performs steam reservation centrally. MSRP only runs on the link to end-stations as an information carrier between CNC and end-stations, not for stream reservation. Centralized User Configuration (CUC) is an optional node that discovers end stations, their capabilities and user requirements, and configures delay-optimized TSN features (for closed-loop IACS applications). Seamless interop with Resource Reservation Protocol (RSVP) transport is provided. 802.1Qcc allows centralized configuration management to coexist with decentralized, fully distributed configuration of the SRP protocol, and also supports hybrid configurations for legacy AVB devices.

802.1Qcc can be combined with IEEE 802.1Qca Path Control and Reservation (PCR) and TSN traffic shapers.

IEEE 802.1Qch Cyclic Queuing and Forwarding (CQF)[edit]

While the 802.1Qav FQTSS/CBS works very well with soft real-time traffic, worst-case delays are both hop count and network topology dependent. Pathological topologies introduce delays, so buffer size requirements have to consider network topology.

IEEE 802.1Qch Cyclic Queuing and Forwarding (CQF), also known as the Peristaltic Shaper (PS), introduces double buffering which allows bridges to synchronize transmission (frame enqueue/dequeue operations) in a cyclic manner, with bounded latency depending only on the number of hops and the cycle time, completely independent of the network topology.

CQF can be used with the IEEE 802.1Qbv time-aware scheduler, IEEE 802.1Qbu frame preemption, and IEEE 802.1Qci ingress traffic policing.

IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP)[edit]

IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP) improves network robustness by filtering individual traffic streams. It prevents traffic overload conditions that may affect bridges and the receiving endpoints due to malfunction or Denial of Service (DoS) attacks. The stream filter uses rule matching to allow frames with specified stream IDs and priority levels and apply policy actions otherwise. All streams are coordinated at their gates, similarly to the 802.1Qch signaling. The flow metering applies predefined bandwidth profiles for each stream.

TSN scheduling and traffic shaping[edit]

IEEE 802.1Qbv Enhancements to Traffic Scheduling: Time-Aware Shaper (TAS)[edit]

The IEEE 802.1Qbv time-aware scheduler is designed to separate the communication on the Ethernet network into fixed length, repeating time cycles. Within these cycles, different time slices can be configured that can be assigned to one or several of the eight Ethernet priorities. By doing this, it is possible to grant exclusive use - for a limited time - to the Ethernet transmission medium for those traffic classes that need transmission guarantees and can't be interrupted. The basic concept is a time-division multiple access (TDMA) scheme. By establishing virtual communication channels for specific time periods, time-critical communication can be separated from non-critical background traffic.

Time-aware scheduler introduces Stream Reservation Class CDT for time-critical control data, with worst-case latency of 100 μs over 5 hops, and maximum transmission period of 0.5 ms, in addition to classes A and B defined for IEEE 802.1Qav credit-based traffic shaper. By granting exclusive access to the transmission medium and devices to time-critical traffic classes, the buffering effects in the Ethernet switch transmission buffers can be avoided and time-critical traffic can be transmitted without non-deterministic interruptions. One example for an IEEE 802.1Qbv scheduler configuration is visible in figure 1:

figure 1: Example IEEE 802.1Qbv schedule

In this example, each cycle consists of two time slices. Time slice 1 only allows the transmission of traffic tagged with VLAN priority 3, and time slice 2 in each cycle allows for the rest of the priorities to be sent. Since the IEEE 802.1Qbv scheduler requires all clocks on all network devices (Ethernet switches and end devices) to be synchronized and the identical schedule to be configured, all devices understand which priority can be sent to the network at any given point in time. Since time slice 2 has more than one priority assigned to it, within this time slice, the priorities are handled according to standard IEEE 802.1Q strict priority scheduling.

This separation of Ethernet transmissions into cycles and time slices can be enhanced further by the inclusion of other scheduling or traffic shaping algorithms, such as the IEEE 802.1Qav credit-based traffic shaper. IEEE 802.1Qav supports soft real-time. In this particular example, IEEE 802.1Qav could be assigned to one or two of the priorities that are used in time slice two to distinguish further between audio/video traffic and background file transfers. The Time-Sensitive Networking Task Group specifies a number of different schedulers and traffic shapers that can be combined to achieve the nonreactive coexistence of hard real-time, soft real-time and background traffic on the same Ethernet infrastructure.

IEEE 802.1Qbv in more detail: Time slices and guard bands[edit]

When an Ethernet interface has started the transmission of a frame to the transmission medium, this transmission has to be completely finished before another transmission can take place. This includes the transmission of the CRC32 checksum at the end of the frame to ensure a reliable, fault-free transmission. This inherent property of Ethernet networks - again- poses a challenge to the TDMA approach of the IEEE 802.1Qbv scheduler. This is visible in figure 2:

figure 2: Frame that is sent too late in the best effort time slice infringes the high-priority time slice

Just before the end of time slice 2 in cycle n, a new frame transmission is started. Unfortunately, this frame is too large to fit into its time slice. Since the transmission of this frame cannot be interrupted, the frame infringes the following time slice 1 of the next cycle n+1. By partially or completely blocking a time-critical time slice, real-time frames can be delayed up to the point where they cannot meet the application requirements any longer. This is very similar to the actual buffering effects that happen in non-TSN Ethernet switches, so TSN has to specify a mechanism to prevent this from happening.

The IEEE 802.1Qbv time-aware scheduler has to ensure that the Ethernet interface is not busy with the transmission of a frame when the scheduler changes from one-time slice into the next. The time-aware scheduler achieves this by putting a guard band in front of every time slice that carries time-critical traffic. During this guard band time, no new Ethernet frame transmission may be started, only already ongoing transmissions may be finished. The duration of this guard band has to be as long as it takes the maximum frame size to be safely transmitted. For an Ethernet frame according to IEEE 802.3 with a single IEEE 802.1Q VLAN tag and including interframe spacing, the total length is: 1500 byte (frame payload) + 18 byte (ethernet addresses, EtherType and CRC) + 4 byte (VLAN Tag) + 12 byte (Interframe spacing) + 8 byte (preamble and SFD) = 1542 byte.

The total time needed for sending this frame is dependent on the link speed of the Ethernet network. With Fast Ethernet and 100 Mbit/s transmission rate, the transmission duration is as follows:

In this case, the guard band has to be at least 123.36 µs long. With the guard band, the total bandwidth or time that is usable within a time slice is reduced by the length of the guard band. This is visible in figure 3

figure 3: Guard bands prevent the infringement of time slices with critical traffic

Note: to facilitate the presentation of the topic, the actual size of the guard band in figure 3 is not to scale, but is significantly smaller than indicated by the frame in figure 2.

In this example, the time slice 1 always contains high priority data (e.g. for motion control), while time slice 2 always contains best-effort data. Therefore, a guard band needs to be placed at every transition point into time slice 1 to protect the time slice of the critical data stream(s).

While the guard bands manage to protect the time slices with high priority, critical traffic, they also have some significant drawbacks:

  • The time that is consumed by a guard band is lost - it cannot be used to transmit any data, as the Ethernet port needs to be silent. Therefore, the lost time directly translates in lost bandwidth for background traffic on that particular Ethernet link.
  • A single time slice can never be configured smaller than the size of the guard band. Especially with lower speed Ethernet connections and growing guard band size, this has a negative impact on the lowest achievable time slice length and cycle time.

To partially mitigate the loss of bandwidth through the guard band, the standard IEEE 802.1Qbv includes a length-aware scheduling mechanism. This mechanism is used when store-and-forward switching is utilized: after the full reception of an Ethernet frame that needs to be transmitted on a port where the guard band is in effect, the scheduler checks the overall length of the frame. If the frame can fit completely inside the guard band, without any infringement of the following high priority slice, the scheduler can send this frame, despite an active guard band, and reduce the waste of bandwidth. This mechanism, however, cannot be used when cut-through switching is enabled, since the total length of the Ethernet frame needs to be known a priori. Therefore, when cut-through switching is used to minimize end-to-end latency, the waste of bandwidth will still occur. Also, this does not help with the minimum achievable cycle time. Therefore, length-aware scheduling is an improvement, but cannot mitigate all drawbacks that are introduced by the guard band.

IEEE 802.3br and 802.1Qbu Interspersing Express Traffic (IET) and Frame Preemption[edit]

To further mitigate the negative effects from the guard bands, the IEEE working groups 802.1 and 802.3 have specified the frame pre-emption technology. The two working groups collaborated in this endeavour since the technology required both changes in the Ethernet Media Access Control (MAC) scheme that is under the control of IEEE 802.3, as well as changes in the management mechanisms that are under the control of IEEE 802.1. Due to this fact, frame pre-emption is described in two different standards documents: IEEE 802.1Qbu[6] for the bridge management component and IEEE 802.3br[7] for the Ethernet MAC component.

Figure 4: Example of frame pre-emption

Frame preemption defines two MAC services for an egress port, preemptable MAC (pMAC) and express MAC (eMAC). Express frames can interrupt transmission of preemptable frames. On resume, MAC merge sublayer re-assembles frame fragments in the next bridge.

Preemption causes computational overhead in the link interface, as the operational context shall be transitioned to the express frame.

Figure 4 gives a basic example how frame pre-emption works. During the process of sending a best effort Ethernet frame, the MAC interrupts the frame transmission just before the start of the guard band. The partial frame is completed with a CRC and will be stored in the next switch to wait for the second part of the frame to arrive. After the high priority traffic in time slice 1 has passed and the cycle switches back to time slice 2, the interrupted frame transmission is resumed. Frame pre-emption always operates on a pure link-by-link basis and only fragments from one Ethernet switch to the next Ethernet switch, where the frame is reassembled. In contrast to fragmentation with the Internet Protocol (IP), no end-to-end fragmentation is supported.

Each partial frame is completed by a CRC32 for error detection. In contrast to the regular Ethernet CRC32, the last 16 bits are inverted to make a partial frame distinguishable from a regular Ethernet frame. In addition, also the start of frame delimiter (SFD) is changed.

The support for frame pre-emption has to be activated on each link between devices individually. To signal the capability for frame pre-emption on a link, an Ethernet switch announces this capability through the LLDP (Link Layer Discovery Protocol). When a device receives such an LLDP announcement on a network port and supports frame pre-emption itself, it may activate the capability. There is no direct negotiation and activation of the capability on adjacent devices. Any device that receives the LLDP pre-emption announcement assumes that on the other end of the link, a device is present that can understand the changes in the frame format (changed CRC32 and SFD).

Frame pre-emption allows for a significant reduction of the guard band. The length of the guard band is now dependent on the precision of the frame pre-emption mechanism: how small is the minimum size of the frame that the mechanism can still pre-empt. IEEE 802.3br specifies the best accuracy for this mechanism at 64 byte - due to the fact that this is the minimum size of a still valid Ethernet frame. In this case, the guard band can be reduced to a total of 127 byte: 64 byte (minimum frame) + 63 byte (remaining length that cannot be pre-empted). All larger frames can be pre-empted again and therefore, there is no need to protect against this size with a guard band.

This minimizes the best effort bandwidth that is lost and also allows for much shorter cycle times at slower Ethernet speeds, such as 100 Mbit/s and below. Since the pre-emption takes place in hardware in the MAC, as the frame passes through, cut-through switching can be supported as well, since the overall frame size is not needed a priori. The MAC interface just checks in regular 64 byte intervals whether the frame needs to be pre-empted or not.

The combination of time synchronization, the IEEE 802.1Qbv scheduler and frame pre-emption already constitutes an effective set of standards that can be utilized to guarantee the coexistence of different traffic categories on a network while also providing end-to-end latency guarantees. This will be enhanced further as new IEEE 802.1 specifications, such as 802.1Qch are finalized.

Shortcomings of IEEE 802.1Qbv/bu[edit]

Overall, the time-aware scheduler has high implementation complexity and its use of bandwidth is not efficient. Task and event scheduling in endpoints has to be coupled with the gate scheduling of the traffic shaper in order to lower the latencies. A critical shortcoming is some delay incurred when an end-point streams unsynchronized data, due to the waiting time for the next time-triggered window.

The time-aware scheduler requires tight synchronization of its time-triggered windows, so all bridges on the stream path must be synchronized. However synchronizing TSN bridge frame selection and transmission time is nontrivial even in moderately sized networks and requires a fully managed solution.

Frame preemption is hard to implement and has not seen wide industry support.

IEEE 802.1Qcr Asynchronous Traffic Shaping[edit]

Credit-based, time-aware and cyclic (peristaltic) shapers require network-wide coordinated time and utilize network bandwidth inefficiently, as they enforce packet transmission at periodic cycles. The IEEE 802.1Qcr Asynchronous Traffic Shaper (ATS) operates asynchronously based on local clocks in each bridge, improving link utilization for mixed traffic types, such as periodic with arbitrary periods, sporadic (event driven), and rate-constrained.

ATS employs the urgency-based scheduler (UBS) which prioritizes urgent traffic using per-class queuing and per-stream reshaping. Asynchronicity is achieved by interleaved shaping with traffic characterization based on Token Bucket Emulation, a token bucket emulation model, to eliminate the burstiness cascade effects of per-class shaping. The TBE shaper controls the traffic by average transmission rate, but allows a certain level of burst traffic. When there is a sufficient number of tokens in the bucket, transmission starts immediately; otherwise the queue's gate closes for the time needed to accumulate enough tokens.

The UBS is an improvement on Rate-Controlled Service Disciplines (RCSDs) to control selection and transmission of each individual frame at each hop, decoupling stream bandwidth from the delay bound by separation of rate control and packet scheduling, and using static priorities and First Come - First Serve and Earliest Due - Date First queuing.

UBS queuing has two levels of hierarchy: per-flow shaped queues, with fixed priority assigned by the upstream sources according to application-defined packet transmission times, allowing arbitrary transmission period for each stream, and shared queues that merge streams with the same internal priority from several shapers. This separation of queuing has low implementation complexity while ensuring that frames with higher priority will bypass the lower priority frames.

The shared queues are highly isolated, with policies for separate queues for frames from different transmitters, the same transmitter but different priority, and the same transmitter and priority but a different priority at the receiver. Queue isolation prevents propagation of malicious data, assuring that ordinary streams will get no interference, and enables flexible stream or transmitter blocking by administrative action. The minimum number of shared queues is the number of ports minus one, and more with additional isolation policies. Shared queues have scheduler internal fixed priority, and frames are transmitted on the First Come First Serve principle.

Worst case clock sync inaccuracy does not decrease link utilization, contrary to time-triggered approaches such as TAS (Qbv) and CQF (Qch).

Selection of communication paths and fault-tolerance[edit]

IEEE 802.1Qca Path Control and Reservation (PCR)[edit]

IEEE 802.1Qca Path Control and Reservation (PCR) specifies extensions to the Intermediate Station to Intermediate Station (IS-IS) protocol to configure multiple paths in bridged networks.

The IEEE 802.1Qca standard uses Shortest Path Bridging (SPB) with a software-defined networking (SDN) hybrid mode - the IS-IS protocol handles basic functions, while the SDN controller manages explicit paths using Path Computation Elements (PCEs) at dedicated server nodes. IEEE 802.1Qca integrates control protocols to manage multiple topologies, configure an explicit forwarding path (a predefined path for each stream), reserve bandwidth, provides data protection and redundancy, and distribute flow synchronization and flow control messages. These are derived from Equal Cost Tree (ECT), Multiple Spanning Tree Instance (MSTI) and Internal Spanning Tree (IST), and Explicit Tree (ET) protocols.

IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER)[edit]

IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER) sends duplicate copies of each frame over multiple disjoint paths, to provide proactive seamless redundancy for control applications that cannot tolerate packet losses.

The packet replication can use traffic class and path information to minimize network congestion. Each replicated frame has a sequence identification number, used to re-order and merge frames and to discard duplicates.

FRER requires centralized configuration management and needs to be used with 802.1Qcc and 802.1Qca. Industrial fault-tolerance HSR and PRP specified in IEC 62439-3 are supported.

Current projects[edit]

IEEE 802.1CS Link-Local Registration Protocol[edit]

MRP state data for a stream takes 1500 bytes. With additional traffic streams and larger networks, the size of the database proportionally increases and MRP updates between bridge neighbors significantly slow down. The Link-Local Registration Protocol (LRP) is optimized for a larger database size of about 1 Mbyte with efficient replication that allows incremental updates. Unresponsive nodes with stale data are automatically discarded. While MRP is application specific, with each registered application defining its own set of operations, LRP is application neutral.

IEEE 802.1Qdd Resource Allocation Protocol[edit]

SRP and MSRP are primarily designed for AV applications - their distributed configuration model is limited to Stream Reservation (SR) Classes A and B defined by the Credit-Based Shaper (CBS), whereas IEEE 802.1Qcc includes a more centralized CNC configuration model supporting all new TSN features such as additional shapers, frame preemption, and path redundancy.

IEEE P802.1Qdd project updates the distributed configuration model by defining new peer-to-peer Resource Allocation Protocol signaling built upon P802.1CS Link-local Registration Protocol. RAP will improve scalability and provide dynamic reservation for a larger number of streams with support for redundant transmission over multiple paths in 802.1CB FRER, and autoconfiguration of sequence recovery.

RAP supports the 'topology-independent per-hop latency calculation' capability of TSN shapers such as 802.1Qch Cyclic Queuing and Forwarding (CQF) and P802.1Qcr Asynchronous Traffic Shaping (ATS). It will also improve performance under high load and support proxying and enhanced diagnostics, all while maintaining backward compatibility and interoperability with MSRP.

RAP could be employed as a generic reservation protocol in a DetNet network.

IEEE 802.1ABdh Link Layer Discovery Protocol v2[edit]

IEEE P802.1ABdh Station and Media Access Control Connectivity Discovery - Support for Multiframe Protocol Data Units (LLDPv2) [8] updates LLDP to support IETF Link State Vector Routing protocol[9] and improve efficiency of protocol messages.

YANG Data Models[edit]

The IEEE 802.1Qcp standard implements the YANG data model to provide a Universal Plug-and-Play (uPnP) framework for status reporting and configuration of equipment such as Media Access Control (MAC) Bridges, Two-Port MAC Relays (TPMRs), Customer Virtual Local Area Network (VLAN) Bridges, and Provider Bridges, and to support the 802.1X Security and 802.1AX Datacenter Bridging standards.

YANG is a Unified Modeling Language (UML) for configuration and state data, notifications, and remote procedure calls, to set up device configuration with network management protocols such as NETCONF/RESTCONF.

DetNet[edit]

The IETF Deterministic Networking (DetNet) Working Group is focusing to define deterministic data paths with high reliability and bounds on latency, loss, and packet delay variation (jitter), such as audio and video streaming, industrial automation, and vehicle control.

The goals of Deterministic Networking are to migrate time-critical, high-reliability industrial and audio-video applications from special-purpose Fieldbus networks to IP packet networks. To achieve these goals, DetNet uses resource allocation to manage buffer sizes and transmission rates in order to satisfy end-to-end latency requirements. Service protection against failures with redundancy over multiple paths and explicit routes to reduce packet loss and reordering. The same physical network shall handle both time-critical reserved traffic and regular best-effort traffic, and unused reserved bandwidth shall be released for best-effort traffic.

DetNet operates at the IP Layer 3 routed segments using a Software-Defined Networking layer to provide IntServ and DiffServ integration, and delivers services over lower Layer 2 bridged segments using technologies such as MPLS and IEEE 802.1 AVB/TSN. [10]

Traffic Engineering (TE) routing protocols translate DetNet flow specification to AVB/TSN controls for queuing, shaping, and scheduling algorithms, such as IEEE 802.1Qav credit-based shaper, IEEE802.1Qbv time-triggered shaper with a rotating time scheduler, IEEE802.1Qch synchronized double buffering, 802.1Qbu/802.3br Ethernet packet pre-emption, and 802.1CB frame replication and elimination for reliability. Also protocol interworking defined by IEEE 802.1CB is used to advertise TSN sub-network capabilities to DetNet flows via the Active Destination MAC and VLAN Stream identification functions. DetNet flows are matched by destination MAC address, VLAN ID and priority parameters to Stream ID and QoS requirements for talkers and listeners in the AVB/TSN sub-network. [11]

Standards[edit]

Related projects:

References[edit]

  1. ^ "IEEE 802.1 Time-Sensitive Networking Task Group". www.ieee802.org.
  2. ^ "IEEE 802.1 AV Bridging Task Group". www.ieee802.org.
  3. ^ "802.1Q-2018 Bridges and Bridged Networks – Revision |". 1.ieee802.org.
  4. ^ "IEEE 802.1: 802.1Qbv - Enhancements for Scheduled Traffic". www.ieee802.org.
  5. ^ Maile, Lisa; Hielscher, Kai-Steffen; German, Reinhard (May 2020). "Network Calculus Results for TSN: An Introduction". Information Communication Technologies Conference (ICTC): 131-140. doi:10.1109/ICTC49638.2020.9123308. ISBN 978-1-7281-6776-3. S2CID 220072988. Retrieved 25 March 2021.
  6. ^ "IEEE 802.1: 802.1Qbu - Frame Preemption". www.ieee802.org.
  7. ^ "IEEE P802.3br Interspersing Express Traffic Task Force". www.ieee802.org.
  8. ^ "IEEE 802 PARs under consideration". www.ieee802.org.
  9. ^ "Link State Vector Routing (lsvr) -". datatracker.ietf.org.
  10. ^ "Deterministic Networking (detnet) - Documents". datatracker.ietf.org.
  11. ^ "draft-ietf-detnet-ip-over-tsn-01 - DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)". datatracker.ietf.org.
  12. ^ https://standards.ieee.org/standard/802_1BA-2011.html
  13. ^ https://standards.ieee.org/standard/802_1AS-2020.html
  14. ^ "P802.1AS-2020 – Timing and Synchronization for Time-Sensitive Applications". 1.ieee802.org.
  15. ^ https://1.ieee802.org/tsn/802-1asdm/
  16. ^ https://standards.ieee.org/standard/802_1Q-2018.html
  17. ^ https://1.ieee802.org/maintenance/p802-1q-rev/
  18. ^ "802.1Qcc-2018 - IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements". standards.ieee.org.
  19. ^ "802.1Qcy-2019 - IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks Amendment 32: Virtual Station Interface (VSI) Discovery and Configuration Protocol (VDP) Extension to Support Network Virtualization Overlays Over Layer 3 (NVO3)". standards.ieee.org.
  20. ^ "P802.1Qcj – Automatic Attachment to Provider Backbone Bridging (PBB) services". 1.ieee802.org.
  21. ^ https://standards.ieee.org/standard/802_1Qcr-2020.html
  22. ^ "P802.1Qcr – Bridges and Bridged Networks Amendment: Asynchronous Traffic Shaping". 1.ieee802.org.
  23. ^ "P802.1Qcz – Congestion Isolation". 1.ieee802.org.
  24. ^ "P802.1Qdd – Resource Allocation Protocol". 1.ieee802.org.
  25. ^ "P802.1Qdj – Configuration enhancements for TSN". 1.ieee802.org.
  26. ^ https://standards.ieee.org/standard/802_1AB-2016.html
  27. ^ https://1.ieee802.org/tsn/802-1abdh/
  28. ^ https://standards.ieee.org/standard/802_1AX-2020.html
  29. ^ "802.1AX-2020 – Link Aggregation". 1.ieee802.org.
  30. ^ https://standards.ieee.org/standard/802_1CB-2017.html
  31. ^ "P802.1CBdb – FRER Extended Stream Identification Functions". 1.ieee802.org.
  32. ^ https://standards.ieee.org/standard/802_1CM-2018.html
  33. ^ https://1.ieee802.org/tsn/802-1cm-2018/
  34. ^ "P802.1CMde – Enhancements to Fronthaul Profiles to Support New Fronthaul Interface, Synchronization, and Syntonization Standards". 1.ieee802.org.
  35. ^ https://standards.ieee.org/standard/802_1CS-2020.html
  36. ^ "P802.1CS – Link-local Registration Protocol". 1.ieee802.org.
  37. ^ "P802.1CQ: Multicast and Local Address Assignment". 1.ieee802.org.
  38. ^ "P802.1DC – Quality of Service Provision by Network Systems". 1.ieee802.org.
  39. ^ "P802.1DF – TSN Profile for Service Provider Networks". 1.ieee802.org.
  40. ^ "P802.1DG – TSN Profile for Automotive In-Vehicle Ethernet Communications". 1.ieee802.org.
  41. ^ "P802.1DP – TSN for Aerospace Onboard Ethernet Communications". 1.ieee802.org.
  42. ^ "IEC/IEEE 60802 TSN Profile for Industrial Automation". 1.ieee802.org.
  43. ^ Interspersing "Express Traffic Task Force".

External links[edit]

  • IEEE 802.1 Time-Sensitive Networking Task Group
  • IEEE 802.1 public document archive
  • Real-time Ethernet – redefined (in German)
  • Time Sensitive Networking (TSN) Vision: Unifying Business & Industrial Automation
  • Is TSN Activity Igniting Another Fieldbus WAR?[dead link]
  • research project related to TSN applications in aircraft
  • Quick Start Guide for visualizing TSN