Rete sensibile al tempo - Time-Sensitive Networking
Time-Sensitive Networking ( TSN ) è un insieme di standard in fase di sviluppo da parte del gruppo di lavoro Time-Sensitive Networking del gruppo di lavoro IEEE 802.1 . Il gruppo di lavoro TSN è stato formato nel novembre 2012 rinominando il gruppo di lavoro di bridging audio video esistente e continuando il suo lavoro. Il nome è cambiato a seguito dell'ampliamento dell'area di lavoro del gruppo di normalizzazione. Gli standard definiscono meccanismi per la trasmissione di dati sensibile al tempo su reti Ethernet deterministiche .
La maggior parte dei progetti definisce estensioni a IEEE 802.1Q – Bridges and Bridged Networks, che descrive LAN virtuali e switch di rete . Queste estensioni in particolare affrontano la trasmissione di latenza di trasmissione molto bassa e alta disponibilità. Le applicazioni includono reti convergenti con streaming audio/video in tempo reale e flussi di controllo in tempo reale utilizzati nelle strutture di controllo automobilistiche o industriali.
Sfondo
Le apparecchiature di rete IT standard non hanno il concetto di "tempo" e non possono fornire sincronizzazione e tempi di precisione. La consegna affidabile dei dati è più importante della consegna entro un tempo specifico, quindi non ci sono vincoli al ritardo o alla precisione della sincronizzazione. Anche se il ritardo medio del salto è molto basso, i ritardi individuali possono essere inaccettabilmente alti. La congestione della rete viene gestita limitando e ritrasmettendo i pacchetti persi a livello di trasporto, ma non ci sono mezzi per prevenire la congestione a livello di collegamento. I dati possono andare persi quando i buffer sono troppo piccoli o la larghezza di banda è insufficiente, ma un buffering eccessivo si aggiunge al ritardo, il che è inaccettabile quando sono richiesti ritardi deterministici bassi.
I diversi documenti degli standard AVB/TSN specificati da IEEE 802.1 possono essere raggruppati in tre categorie di componenti chiave di base necessarie per una soluzione di comunicazione in tempo reale completa basata su reti Ethernet commutate con qualità di servizio (QoS) deterministica per punto-punto connessioni. Ogni specifica standard può essere utilizzata da sola ed è per lo più autosufficiente. Tuttavia, solo se usati insieme in modo concertato, TSN come sistema di comunicazione può raggiungere il suo pieno potenziale. I tre componenti fondamentali sono:
- Sincronizzazione dell'ora: tutti i dispositivi che partecipano alla comunicazione in tempo reale devono avere una comprensione comune del tempo
- Pianificazione e modellazione del traffico: tutti i dispositivi che partecipano alla comunicazione in tempo reale aderiscono alle stesse regole nell'elaborazione e nell'inoltro dei pacchetti di comunicazione
- Selezione dei percorsi di comunicazione, prenotazione dei percorsi e tolleranza ai guasti: tutti i dispositivi che partecipano alla comunicazione in tempo reale aderiscono alle stesse regole nella selezione dei percorsi di comunicazione e nella prenotazione di larghezza di banda e fasce orarie, possibilmente utilizzando più di un percorso simultaneo per ottenere il guasto tolleranza
Le applicazioni che necessitano di una rete deterministica che si comporti in modo prevedibile includono audio e video, inizialmente definiti in Audio Video Bridging (AVB); reti di controllo che accettano input dai sensori, eseguono l'elaborazione del loop di controllo e avviano azioni; reti critiche per la sicurezza che implementano la ridondanza di pacchetti e collegamenti; e reti multimediali miste che gestiscono dati con diversi livelli di sensibilità e priorità di temporizzazione, come le reti di veicoli che supportano il controllo del clima, l'infotainment, l'elettronica della carrozzeria e l'assistenza alla guida. La suite IEEE AVB/TSN serve come base per il networking deterministico per soddisfare i requisiti comuni di queste applicazioni.
AVB/TSN è in grado di gestire il traffico con vincoli di velocità, in cui ogni flusso ha un limite di larghezza di banda definito da intervalli minimi tra i fotogrammi e dimensioni massime del fotogramma e il traffico di attivazione temporale con un'ora esatta per l'invio. Il traffico a bassa priorità viene trasferito sulla base del miglior sforzo, senza garanzie di tempistica e consegna.
Sincronizzazione dell'ora
A differenza dell'Ethernet standard secondo IEEE 802.3 e del bridging Ethernet secondo IEEE 802.1Q , il tempo è molto importante nelle reti TSN. Per la comunicazione in tempo reale con limiti temporali rigidi e non negoziabili per le latenze di trasmissione end-to-end, tutti i dispositivi in questa rete devono avere un riferimento temporale comune e, pertanto, devono sincronizzare i propri orologi tra loro. Questo non vale solo per i dispositivi finali di un flusso di comunicazione, come un controller industriale e un robot di produzione, ma anche per i componenti di rete, come gli switch Ethernet . Solo tramite orologi sincronizzati, è possibile che tutti i dispositivi di rete operino all'unisono ed eseguano l'operazione richiesta esattamente nel momento richiesto. Sebbene la sincronizzazione dell'ora nelle reti TSN possa essere ottenuta con l' orologio GPS , questa operazione è costosa e non vi è alcuna garanzia che il dispositivo endpoint abbia accesso al segnale radio o satellitare in ogni momento. A causa di questi vincoli, l'ora nelle reti TSN viene solitamente distribuita da una sorgente dell'ora centrale direttamente attraverso la rete stessa utilizzando il protocollo IEEE 1588 Precision Time Protocol , che utilizza frame Ethernet per distribuire le informazioni sulla sincronizzazione dell'ora. IEEE 802.1AS è un sottoinsieme strettamente vincolato di IEEE 1588 con una precisione inferiore al microsecondo ed estensioni per supportare la sincronizzazione tramite radio WiFi ( IEEE 802.11 ). L'idea alla base di questo profilo è restringere l'enorme elenco di diverse opzioni IEEE 1588 a poche opzioni critiche gestibili applicabili alle reti domestiche o alle reti in ambienti automobilistici o di automazione industriale.
Temporizzazione e sincronizzazione IEEE 802.1AS per applicazioni sensibili al tempo
IEEE 802.1AS-2011 definisce il profilo Generic Precision Time Protocol (gPTP) che utilizza messaggi UDP per stabilire una gerarchia di orologi e sincronizzare l'ora in un dominio gPTP formato da dispositivi che scambiano eventi temporali.
Per tenere conto dei ritardi del percorso dei dati, il protocollo gPTP misura il tempo di residenza del frame all'interno di ciascun bridge (un tempo necessario per l'elaborazione, l'accodamento e la trasmissione dalle porte di ingresso a quelle di uscita) e la latenza del collegamento di ciascun hop (un ritardo di propagazione tra due bridge adiacenti ). I ritardi calcolati vengono quindi riferiti al clock GrandMaster (GM) in un bridge eletto dal Best Master Clock Algorithm, un protocollo di clock spanning tree a cui tutti i dispositivi Clock Master (CM) e endpoint devono sincronizzarsi. Qualsiasi dispositivo che non si sincronizza con i messaggi di temporizzazione è al di fuori dei limiti del dominio di temporizzazione (Figura 2).
La precisione della sincronizzazione dipende da misurazioni precise del ritardo del collegamento e del tempo di permanenza del frame. 802.1AS utilizza la "sintonia logica", in cui viene utilizzato un rapporto tra le frequenze dell'orologio locale e dell'oscillatore dell'orologio GM per calcolare il tempo sincronizzato e un rapporto tra le frequenze dell'orologio locale e CM per calcolare il ritardo di propagazione.
IEEE802.1AS-2020 introduce una migliore precisione di misurazione del tempo e il supporto per più domini temporali per la ridondanza.
Pianificazione e modellazione del traffico
La pianificazione e la modellazione del traffico consentono la coesistenza di diverse classi di traffico con priorità diverse sulla stessa rete, ciascuna con requisiti diversi per la larghezza di banda disponibile e la latenza end-to-end.
La modellazione del traffico si riferisce al processo di distribuzione di frame/pacchetti in modo uniforme nel tempo per appianare il traffico. Senza la modellazione del traffico alle sorgenti e ai bridge, i pacchetti si "raggruppano", cioè si agglomerano in raffiche di traffico, sovraccaricando i buffer nei successivi bridge/switch lungo il percorso.
Il bridging standard secondo IEEE 802.1Q utilizza uno schema di priorità rigoroso con otto priorità distinte. A livello di protocollo, queste priorità sono visibili nel campo Priority Code Point (PCP) nel tag VLAN 802.1Q di un frame Ethernet standard . Queste priorità distinguono già tra traffico di rete più importante e meno importante, ma anche con la più alta delle otto priorità non può essere data alcuna garanzia assoluta per un tempo di consegna end-to-end. La ragione di ciò sono gli effetti di buffering all'interno degli switch Ethernet. Se uno switch ha avviato la trasmissione di un frame Ethernet su una delle sue porte, anche il frame con la priorità più alta deve attendere all'interno del buffer dello switch il completamento di questa trasmissione. Con la commutazione Ethernet standard, questo non determinismo non può essere evitato. Questo non è un problema negli ambienti in cui le applicazioni non dipendono dalla consegna tempestiva di singoli frame Ethernet, come le infrastrutture IT degli uffici. In questi ambienti, i trasferimenti di file, e-mail o altre applicazioni aziendali hanno una sensibilità temporale limitata e sono solitamente protetti da altri meccanismi più in alto nello stack di protocollo, come il Transmission Control Protocol . Nell'automazione industriale (Programmable Logic Controller ( PLC ) con un robot industriale ) e negli ambienti automobilistici, in cui le applicazioni di controllo ad anello chiuso o di sicurezza utilizzano la rete Ethernet, una consegna affidabile e tempestiva è della massima importanza. AVB/TSN migliora la comunicazione Ethernet standard aggiungendo meccanismi per fornire diversi intervalli di tempo per diverse classi di traffico e garantire una consegna tempestiva con requisiti soft e hard in tempo reale delle applicazioni del sistema di controllo. Viene mantenuto il meccanismo di utilizzo delle otto priorità VLAN distinte, per garantire la completa retrocompatibilità con Ethernet non TSN. Per ottenere tempi di trasmissione con latenza end-to-end garantita, una o più delle otto priorità Ethernet possono essere assegnate individualmente a metodi già esistenti (come lo scheduler a priorità rigorosa IEEE 802.1Q) o a nuovi metodi di elaborazione, come IEEE 802.1 Shaper di traffico basato sul credito Qav, shaper time-aware IEEE 802.1Qbv o shaper asincrono IEEE 802.1Qcr.
Il traffico sensibile al tempo ha diverse classi di priorità. Per lo shaper basato sul credito 802.1Qav, la classe di prenotazione di flusso A è la priorità più alta, con un requisito di latenza nel caso peggiore di 2 ms e un periodo di trasmissione massimo di 125 μs; La classe B ha la seconda priorità più alta con una latenza nel caso peggiore di 50 ms e un periodo di trasmissione massimo di 250 μs. Le classi di traffico non devono superare la loro larghezza di banda massima preconfigurata (75% per applicazioni audio e video). Il numero massimo di hop è 7. Il ritardo peer per porta fornito da gPTP e il ritardo di residenza del bridge di rete vengono aggiunti per calcolare i ritardi accumulati e garantire il rispetto dei requisiti di latenza. Il traffico di controllo ha la terza priorità più alta e include il traffico gPTP e SRP. Lo scheduler time-aware 802.1Qbv introduce la classe CDT per i dati di controllo in tempo reale dai sensori e dai flussi di comando agli attuatori, con una latenza nel caso peggiore di 100 μs su 5 hop e un periodo di trasmissione massimo di 0,5 ms. La classe CDT ha la priorità più alta sulle classi A, B e sul traffico di controllo.
Scheduler basato sul credito AVB
Miglioramenti all'inoltro e all'accodamento IEEE 802.1Qav per flussi sensibili al tempo
IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams definisce la modellazione del traffico utilizzando classi di priorità, che si basano su una semplice forma di "leaky bucket" basata sul credito equo accodamento . 802.1Qav è progettato per ridurre il buffering nei bridge e negli endpoint riceventi.
Lo shaper basato sul credito definisce i crediti in bit per due code separate, dedicate al traffico di Classe A e di Classe B. La trasmissione del frame è consentita solo quando il credito non è negativo; durante la trasmissione il credito decresce ad una velocità denominata sendSlope: . Il credito aumenta ad una velocità idleSlope se i frame sono in attesa di altre code da trasmettere: . Quindi idleSlope è la larghezza di banda riservata alla coda dal bridge e sendSlope è la velocità di trasmissione del servizio MAC della porta.
Se il credito è negativo e non vengono trasmessi frame, il credito aumenta alla velocità di idleSlope fino a raggiungere lo zero. Se non è possibile trasmettere un frame AVB perché è in trasmissione un frame non AVB, il credito si accumula alla velocità di idleSlope ma è consentito un credito positivo.
I limiti aggiuntivi hiCredit e loCredit derivano dalla dimensione massima del frame e dalla dimensione massima dell'interferenza, idleSlope/sendSlope e la velocità di trasmissione massima della porta.
I frame di traffico del flusso AV riservati vengono inoltrati con alta priorità rispetto al traffico Best Effort non riservato , soggetti a regole di modellazione del traffico basate sul credito che potrebbero richiedere loro di attendere una certa quantità di crediti. Ciò protegge il traffico best-effort limitando il burst del flusso AV massimo. I frame sono pianificati in modo molto uniforme, anche se solo su base aggregata, per appianare i tempi di consegna e ridurre burst e raggruppamenti, che possono portare a buffer overflow e cadute di pacchetti che attivano le ritrasmissioni. L'aumento del ritardo nel buffering rende i pacchetti ritrasmessi obsoleti nel momento in cui arrivano, con conseguente perdita di frame che riduce la qualità delle applicazioni AV.
Sebbene lo shaper basato sul credito fornisca una pianificazione equa per i pacchetti a bassa priorità e smussa il traffico per eliminare la congestione, sfortunatamente il ritardo medio aumenta fino a 250 μs per hop, che è troppo alto per le applicazioni di controllo, mentre uno shaper time-aware (IEEE 802.1 Qbv) ha un ritardo di ciclo fisso da 30 μs a diversi millisecondi e un ritardo tipico di 125 μs. Derivare limiti superiori garantiti sui ritardi in TSN in modo non banale ed è attualmente oggetto di ricerca, ad esempio, utilizzando il framework matematico Network Calculus.
Protocollo di prenotazione del flusso IEEE 802.1Qat
IEEE 802.1Qat Stream Reservation Protocol (SRP) è un protocollo peer-to-peer distribuito che specifica i controlli di ammissione in base ai requisiti di risorse del flusso e alle risorse di rete disponibili.
SRP riserva risorse e pubblicizza i flussi dal mittente/fonte (interlocutore) ai destinatari/destinazioni (ascoltatori); funziona per soddisfare i requisiti di QoS per ogni flusso e garantire la disponibilità di risorse di rete sufficienti lungo l'intero percorso di trasmissione del flusso.
I flussi di traffico vengono identificati e registrati con uno StreamID a 64 bit, composto dall'indirizzo MAC (EUI) a 48 bit e dall'UniqueID a 16 bit per identificare flussi diversi da un'unica fonte.
SRP utilizza varianti del Multiple Registration Protocol (MRP) per registrare e deregistrare i valori degli attributi su switch/bridge/dispositivi: Multiple MAC Registration Protocol (MMRP), Multiple VLAN Registration Protocol (MVRP) e Multiple Stream Registration Protocol ( MSRP).
Il protocollo SRP funziona essenzialmente nella seguente sequenza:
- Pubblicizza un flusso da un oratore
- Registra i percorsi lungo il flusso di dati
- Calcola la latenza del caso peggiore
- Crea un dominio AVB
- Riserva la larghezza di banda
Le risorse sono allocate e configurate sia nei nodi finali del flusso di dati che nei nodi di transito lungo il percorso del flusso di dati, con un meccanismo di segnalazione end-to-end per rilevare il successo/fallimento. La latenza nel caso peggiore viene calcolata interrogando ogni bridge.
Le richieste di prenotazione utilizzano l'applicazione MRP generale con il meccanismo di propagazione degli attributi MRP. Tutti i nodi lungo il percorso del flusso superano la specifica MRP Attribute Declaration (MAD) che descrive le caratteristiche del flusso in modo che i bridge possano allocare le risorse necessarie.
Se un bridge è in grado di riservare le risorse richieste, propaga l'annuncio al bridge successivo; in caso contrario, viene generato un messaggio di errore dell'oratore. Quando il messaggio di pubblicità raggiunge l'ascoltatore, risponde con un messaggio "pronto per l'ascoltatore" che si propaga all'interlocutore.
La pubblicità dell'oratore e i messaggi pronti per l'ascoltatore possono essere cancellati dalla registrazione, il che termina il flusso.
La corretta prenotazione è garantita solo quando tutti i nodi intermedi supportano SRP e rispondono a messaggi pubblicitari e pronti; nella Figura 2 sopra, il dominio AVB 1 non è in grado di connettersi con il dominio AVB 2.
SRP è utilizzato anche dagli standard TSN/AVB per le priorità dei frame, la pianificazione dei frame e la modellazione del traffico
Miglioramenti alla programmazione AVB
Miglioramenti IEEE 802.1Qcc a SRP
SRP utilizza la procedura di registrazione e prenotazione decentralizzata, richieste multiple possono introdurre ritardi per il traffico critico. L'emendamento IEEE 802.1Qcc-2018 "Stream Reservation Protocol (SRP) Enhancements and Performance Improvements" riduce la dimensione dei messaggi di prenotazione e ridefinisce i timer in modo che attivino gli aggiornamenti solo quando lo stato del collegamento o la prenotazione vengono modificati. Per migliorare l'amministrazione TSN su reti su larga scala, ciascuna interfaccia di rete utente (UNI) fornisce metodi per richiedere servizi di livello 2, integrati da Centralized Network Configuration (CNC) per fornire prenotazione e pianificazione centralizzate e gestione remota utilizzando i protocolli NETCONF/RESTCONF e IETF YANG /NETCONF modellazione dei dati.
Il CNC implementa un modello di richiesta-risposta per flusso, in cui la classe SR non viene utilizzata esplicitamente: le stazioni finali inviano richieste per un flusso specifico (tramite la porta edge) senza conoscere la configurazione di rete e il CNC esegue la prenotazione del vapore a livello centrale. MSRP funziona solo sul collegamento alle stazioni finali come vettore di informazioni tra il CNC e le stazioni finali, non per la prenotazione del flusso. Centralized User Configuration (CUC) è un nodo opzionale che rileva le stazioni terminali, le loro capacità e i requisiti utente e configura le funzionalità TSN ottimizzate per il ritardo (per applicazioni IACS a ciclo chiuso ). Viene fornita un'interoperabilità perfetta con il trasporto RSVP ( Resource Reservation Protocol ). 802.1Qcc consente alla gestione centralizzata della configurazione di coesistere con la configurazione decentralizzata e completamente distribuita del protocollo SRP e supporta anche le configurazioni ibride per i dispositivi AVB legacy.
802.1Qcc può essere combinato con IEEE 802.1Qca Path Control and Reservation (PCR) e traffic shaper TSN.
Accodamento e inoltro ciclico IEEE 802.1Qch (CQF)
Mentre l'FQTSS/CBS 802.1Qav funziona molto bene con traffico soft in tempo reale, i ritardi nel caso peggiore dipendono sia dal numero di hop che dalla topologia della rete. Le topologie patologiche introducono ritardi, quindi i requisiti di dimensione del buffer devono considerare la topologia di rete.
IEEE 802.1Qch Cyclic Queuing and Forwarding (CQF), noto anche come Peristaltic Shaper (PS), introduce il doppio buffering che consente ai bridge di sincronizzare la trasmissione (operazioni frame enqueue/dequeue) in modo ciclico, con latenza limitata dipendente solo dal numero di hop e il tempo di ciclo, completamente indipendente dalla topologia di rete.
CQF può essere utilizzato con lo scheduler time-aware IEEE 802.1Qbv, il frame preemption IEEE 802.1Qbu e il controllo del traffico in ingresso IEEE 802.1Qci.
IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP)
IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP) migliora la robustezza della rete filtrando i singoli flussi di traffico. Previene le condizioni di sovraccarico del traffico che possono influenzare i bridge e gli endpoint di ricezione a causa di malfunzionamenti o attacchi Denial of Service (DoS). Il filtro del flusso utilizza la corrispondenza delle regole per consentire i frame con ID di flusso e livelli di priorità specificati, altrimenti applica le azioni dei criteri. Tutti i flussi sono coordinati alle loro porte, in modo simile alla segnalazione 802.1Qch. La misurazione del flusso applica profili di larghezza di banda predefiniti per ogni flusso.
Programmazione TSN e modellazione del traffico
Miglioramenti IEEE 802.1Qbv alla pianificazione del traffico: Time-Aware Shaper (TAS)
Lo scheduler time-aware IEEE 802.1Qbv è progettato per separare la comunicazione sulla rete Ethernet in cicli temporali ripetuti a lunghezza fissa. All'interno di questi cicli è possibile configurare diversi intervalli di tempo che possono essere assegnati a una o più delle otto priorità Ethernet. In questo modo è possibile concedere in uso esclusivo - per un tempo limitato - al mezzo trasmissivo Ethernet per quelle classi di traffico che necessitano di garanzie di trasmissione e non possono essere interrotte. Il concetto di base è uno schema di accesso multiplo a divisione di tempo (TDMA). Stabilendo canali di comunicazione virtuali per periodi di tempo specifici, la comunicazione time-critical può essere separata dal traffico in background non critico.
Lo scheduler time-aware introduce la classe CDT di prenotazione del flusso per i dati di controllo time-critical, con latenza nel caso peggiore di 100 μs su 5 hop e periodo di trasmissione massimo di 0,5 ms, oltre alle classi A e B definite per il credito IEEE 802.1Qav- modellatore di traffico basato. Concedendo l'accesso esclusivo al mezzo di trasmissione e ai dispositivi a classi di traffico time-critical, è possibile evitare gli effetti di buffering nei buffer di trasmissione dello switch Ethernet e trasmettere traffico time-critical senza interruzioni non deterministiche. Un esempio di configurazione dello scheduler IEEE 802.1Qbv è visibile nella figura 1:
In questo esempio, ogni ciclo è costituito da due intervalli di tempo. L'intervallo di tempo 1 consente solo la trasmissione del traffico contrassegnato con la priorità 3 della VLAN e l'intervallo di tempo 2 in ogni ciclo consente l'invio del resto delle priorità. Poiché lo scheduler IEEE 802.1Qbv richiede la sincronizzazione di tutti gli orologi su tutti i dispositivi di rete (switch Ethernet e dispositivi finali) e la configurazione della stessa pianificazione, tutti i dispositivi comprendono quale priorità può essere inviata alla rete in un dato momento. Poiché l'intervallo di tempo 2 ha più di una priorità assegnata, all'interno di questo intervallo di tempo le priorità vengono gestite secondo la schedulazione delle priorità standard IEEE 802.1Q.
Questa separazione delle trasmissioni Ethernet in cicli e intervalli di tempo può essere ulteriormente migliorata con l'inclusione di altri algoritmi di pianificazione o modellazione del traffico, come lo shaper del traffico basato sul credito IEEE 802.1Qav. IEEE 802.1Qav supporta soft real-time. In questo particolare esempio, IEEE 802.1Qav potrebbe essere assegnato a una o due delle priorità utilizzate nella seconda fascia di tempo per distinguere ulteriormente tra traffico audio/video e trasferimenti di file in background. Il gruppo di attività Time-Sensitive Networking specifica un numero di schedulatori e traffic shaper diversi che possono essere combinati per ottenere la coesistenza non reattiva di traffico hard real-time, soft real-time e in background sulla stessa infrastruttura Ethernet.
IEEE 802.1Qbv in modo più dettagliato: intervalli di tempo e bande di guardia
Quando un'interfaccia Ethernet ha avviato la trasmissione di un frame al mezzo di trasmissione, questa trasmissione deve essere terminata completamente prima che possa aver luogo un'altra trasmissione. Ciò include la trasmissione del checksum CRC32 alla fine del frame per garantire una trasmissione affidabile e senza errori. Questa proprietà intrinseca delle reti Ethernet, ancora una volta, pone una sfida all'approccio TDMA dello scheduler IEEE 802.1Qbv. Questo è visibile in figura 2:
Poco prima della fine dell'intervallo di tempo 2 nel ciclo n, viene avviata una nuova trasmissione di frame. Sfortunatamente, questo frame è troppo grande per rientrare nel suo intervallo di tempo. Poiché la trasmissione di questo frame non può essere interrotta, il frame infrange il successivo intervallo di tempo 1 del ciclo successivo n+1. Bloccando parzialmente o completamente un intervallo temporale critico, i frame in tempo reale possono essere ritardati fino al punto in cui non possono più soddisfare i requisiti dell'applicazione. Questo è molto simile agli effetti di buffering effettivi che si verificano negli switch Ethernet non TSN, quindi TSN deve specificare un meccanismo per evitare che ciò accada.
Lo scheduler time-aware IEEE 802.1Qbv deve garantire che l'interfaccia Ethernet non sia occupata con la trasmissione di un frame quando lo scheduler passa da una sezione a quella successiva. Lo scheduler time-aware ottiene ciò mettendo una banda di guardia davanti a ogni intervallo di tempo che trasporta traffico time-critical. Durante questo tempo di banda di guardia, non può essere avviata alcuna nuova trasmissione di frame Ethernet, solo le trasmissioni già in corso possono essere terminate. La durata di questa banda di guardia deve essere pari a quella necessaria alla dimensione massima del frame per essere trasmessa in sicurezza. Per un frame Ethernet secondo IEEE 802.3 con un singolo tag VLAN IEEE 802.1Q e spaziatura tra frame inclusa , la lunghezza totale è: 1500 byte (payload frame) + 18 byte (indirizzi ethernet, EtherType e CRC) + 4 byte (tag VLAN) + 12 byte (spaziatura tra frame) + 8 byte (preambolo e SFD) = 1542 byte.
Il tempo totale necessario per l'invio di questo frame dipende dalla velocità di collegamento della rete Ethernet. Con Fast Ethernet e velocità di trasmissione 100 Mbit/s, la durata della trasmissione è la seguente:
In questo caso, la banda di guardia deve essere lunga almeno 123,36 µs. Con la banda di guardia, la larghezza di banda totale o il tempo utilizzabile in un intervallo di tempo viene ridotto della lunghezza della banda di guardia. Questo è visibile in figura 3
Nota: per facilitare la presentazione dell'argomento, la dimensione effettiva della fascia di guardia in figura 3 non è in scala, ma è notevolmente inferiore a quella indicata dal riquadro in figura 2.
In questo esempio, l'intervallo di tempo 1 contiene sempre dati ad alta priorità (ad es. per il controllo del movimento), mentre l'intervallo di tempo 2 contiene sempre dati best-effort. Pertanto, è necessario posizionare una banda di guardia in ogni punto di transizione nell'intervallo di tempo 1 per proteggere l'intervallo di tempo dei flussi di dati critici.
Sebbene le bande di guardia riescano a proteggere le fasce orarie con traffico critico ad alta priorità, presentano anche alcuni inconvenienti significativi:
- Il tempo impiegato da una banda di guardia è perso: non può essere utilizzato per trasmettere dati, poiché la porta Ethernet deve essere silenziosa. Pertanto, il tempo perso si traduce direttamente in larghezza di banda persa per il traffico in background su quel particolare collegamento Ethernet.
- Non è mai possibile configurare un singolo intervallo di tempo inferiore alla dimensione della banda di guardia. Soprattutto con le connessioni Ethernet a velocità inferiore e la crescente dimensione della banda di guardia, ciò ha un impatto negativo sulla lunghezza della fascia di tempo e sul tempo di ciclo più bassi realizzabili.
Per mitigare parzialmente la perdita di larghezza di banda attraverso la banda di guardia, lo standard IEEE 802.1Qbv include un meccanismo di schedulazione sensibile alla lunghezza. Questo meccanismo viene utilizzato quando si utilizza la commutazione store-and-forward : dopo la ricezione completa di un frame Ethernet che deve essere trasmesso su una porta in cui è attiva la banda di guardia, lo scheduler verifica la lunghezza complessiva del frame. Se il frame può rientrare completamente all'interno della banda di guardia, senza alcuna violazione della successiva slice ad alta priorità, lo scheduler può inviare questo frame, nonostante una banda di guardia attiva, e ridurre lo spreco di larghezza di banda. Questo meccanismo, tuttavia, non può essere utilizzato quando è abilitata la commutazione cut-through , poiché la lunghezza totale del frame Ethernet deve essere nota a priori. Pertanto, quando viene utilizzata la commutazione cut-through per ridurre al minimo la latenza end-to-end, si verificherà comunque lo spreco di larghezza di banda. Inoltre, questo non aiuta con il tempo di ciclo minimo ottenibile. Pertanto, la programmazione in base alla lunghezza è un miglioramento, ma non può mitigare tutti gli inconvenienti introdotti dalla banda di guardia.
IEEE 802.3br e 802.1Qbu Interspersing Express Traffic (IET) e Frame Preemption
Per mitigare ulteriormente gli effetti negativi delle bande di guardia, i gruppi di lavoro IEEE 802.1 e 802.3 hanno specificato la tecnologia di prelazione del frame. I due gruppi di lavoro hanno collaborato a questo sforzo poiché la tecnologia richiedeva sia modifiche allo schema Ethernet Media Access Control (MAC) che è sotto il controllo di IEEE 802.3, sia modifiche ai meccanismi di gestione che sono sotto il controllo di IEEE 802.1. Per questo motivo, la prelazione del frame è descritta in due diversi documenti standard: IEEE 802.1Qbu per il componente di gestione del bridge e IEEE 802.3br per il componente MAC Ethernet.
La prelazione dei frame definisce due servizi MAC per una porta di uscita, MAC prerilasciabile (pMAC) e MAC espresso (eMAC). I frame rapidi possono interrompere la trasmissione di frame prerilasciabili. Al ripristino, il sottolivello di unione MAC riassembla i frammenti di frame nel bridge successivo.
La prelazione causa un sovraccarico computazionale nell'interfaccia di collegamento, poiché il contesto operativo deve essere trasferito al frame espresso.
La Figura 4 fornisce un esempio di base di come funziona la prelazione dei frame. Durante il processo di invio di un frame Ethernet Best Effort, il MAC interrompe la trasmissione del frame appena prima dell'inizio della banda di guardia. Il frame parziale viene completato con un CRC e verrà memorizzato nello switch successivo per attendere l'arrivo della seconda parte del frame. Dopo che il traffico ad alta priorità nell'intervallo di tempo 1 è passato e il ciclo torna all'intervallo di tempo 2, viene ripresa la trasmissione di trama interrotta. La prelazione del frame opera sempre su una base puramente link-by-link e frammenta solo da uno switch Ethernet allo switch Ethernet successivo, dove il frame viene riassemblato. A differenza della frammentazione con il protocollo Internet (IP) , non è supportata alcuna frammentazione end-to-end.
Ogni frame parziale è completato da un CRC32 per il rilevamento degli errori. A differenza del normale CRC32 Ethernet, gli ultimi 16 bit vengono invertiti per rendere distinguibile un frame parziale da un normale frame Ethernet. Inoltre, viene modificato anche l' inizio del delimitatore di frame (SFD).
Il supporto per la prelazione frame deve essere attivato su ogni collegamento tra dispositivi singolarmente. Per segnalare la capacità di prelazione dei frame su un collegamento, uno switch Ethernet annuncia questa capacità tramite LLDP (Link Layer Discovery Protocol) . Quando un dispositivo riceve un tale annuncio LLDP su una porta di rete e supporta la prelazione del frame stessa, può attivare la funzionalità. Non c'è negoziazione diretta e attivazione della capacità sui dispositivi adiacenti. Qualsiasi dispositivo che riceve l'annuncio di prelazione LLDP presuppone che all'altra estremità del collegamento sia presente un dispositivo in grado di comprendere le modifiche nel formato del frame (cRC32 e SFD modificati).
La prelazione del telaio consente una significativa riduzione della fascia di guardia. La lunghezza della fascia di protezione ora dipende dalla precisione del meccanismo di prelazione del telaio: quanto è piccola la dimensione minima del telaio che il meccanismo può ancora anticipare. IEEE 802.3br specifica la migliore precisione per questo meccanismo a 64 byte, poiché questa è la dimensione minima di un frame Ethernet ancora valido. In questo caso, la banda di guardia può essere ridotta a un totale di 127 byte: 64 byte (frame minimo) + 63 byte (lunghezza residua non anticipabile). Tutti i telai più grandi possono essere pre-svuotati nuovamente e quindi non è necessario proteggersi da queste dimensioni con una fascia di protezione.
Ciò riduce al minimo la migliore larghezza di banda che viene persa e consente anche tempi di ciclo molto più brevi a velocità Ethernet più basse, come 100 Mbit/s e inferiori. Poiché la prelazione avviene nell'hardware del MAC, al passaggio del frame, può essere supportata anche la commutazione cut-through, poiché la dimensione complessiva del frame non è necessaria a priori. L'interfaccia MAC controlla solo a intervalli regolari di 64 byte se il frame deve essere anticipato o meno.
La combinazione di sincronizzazione temporale, schedulatore IEEE 802.1Qbv e frame preemption costituisce già un efficace insieme di standard che possono essere utilizzati per garantire la coesistenza di diverse categorie di traffico su una rete fornendo anche garanzie di latenza end-to-end. Questo sarà ulteriormente migliorato con la finalizzazione delle nuove specifiche IEEE 802.1, come 802.1Qch.
Carenze di IEEE 802.1Qbv/bu
Nel complesso, lo scheduler time-aware presenta un'elevata complessità di implementazione e il suo utilizzo della larghezza di banda non è efficiente. La pianificazione di attività ed eventi negli endpoint deve essere abbinata alla pianificazione del gate del traffic shaper per ridurre le latenze. Un difetto critico è un ritardo che si verifica quando un endpoint trasmette dati non sincronizzati, a causa del tempo di attesa per la successiva finestra temporale.
Lo scheduler time-aware richiede una stretta sincronizzazione delle sue finestre con attivazione temporale, quindi tutti i bridge sul percorso del flusso devono essere sincronizzati. Tuttavia, la sincronizzazione della selezione del frame del bridge TSN e del tempo di trasmissione non è banale anche in reti di dimensioni moderate e richiede una soluzione completamente gestita.
La prelazione dei frame è difficile da implementare e non ha visto un ampio supporto del settore.
Modellazione del traffico asincrono IEEE 802.1Qcr
Gli shaper basati sul credito, time-aware e ciclici (peristaltici) richiedono tempo coordinato a livello di rete e utilizzano la larghezza di banda della rete in modo inefficiente, poiché impongono la trasmissione dei pacchetti a cicli periodici. L'Asynchronous Traffic Shaper (ATS) IEEE 802.1Qcr opera in modo asincrono in base ai clock locali in ciascun bridge, migliorando l'utilizzo del collegamento per tipi di traffico misti, ad esempio periodici con periodi arbitrari, sporadici (guidati da eventi) e con vincoli di velocità.
ATS utilizza lo scheduler basato sull'urgenza (UBS) che dà la priorità al traffico urgente utilizzando l'accodamento per classe e il rimodellamento per flusso. L'asincronicità è ottenuta mediante interleaved shaping con caratterizzazione del traffico basata su Token Bucket Emulation, un modello di emulazione token bucket , per eliminare gli effetti a cascata burstiness della per-class shaping. Lo shaper TBE controlla il traffico in base alla velocità di trasmissione media, ma consente un certo livello di traffico burst. Quando c'è un numero sufficiente di token nel bucket, la trasmissione inizia immediatamente; altrimenti il gate della coda si chiude per il tempo necessario ad accumulare abbastanza token.
L'UBS è un miglioramento delle discipline di servizio a controllo di velocità (RCSD) per controllare la selezione e la trasmissione di ogni singolo frame a ciascun hop, disaccoppiando la larghezza di banda del flusso dal ritardo vincolato dalla separazione del controllo della velocità e dalla pianificazione dei pacchetti e utilizzando priorità statiche e First Come - Primo servizio e prima scadenza - Data Prima coda.
Le code UBS hanno due livelli di gerarchia: code a forma di flusso, con priorità fissa assegnata dalle sorgenti upstream in base ai tempi di trasmissione dei pacchetti definiti dall'applicazione, consentendo periodi di trasmissione arbitrari per ciascun flusso e code condivise che uniscono i flussi con la stessa priorità interna da diversi shaper. Questa separazione delle code ha una bassa complessità di implementazione, garantendo al tempo stesso che i frame con priorità più alta ignorino i frame con priorità inferiore.
Le code condivise sono altamente isolate, con criteri per code separate per frame provenienti da trasmettitori diversi, stesso trasmettitore ma priorità diversa e stesso trasmettitore e priorità ma priorità diversa sul ricevitore. L'isolamento della coda impedisce la propagazione di dati dannosi, assicurando che i flussi ordinari non subiscano interferenze e consente il flusso flessibile o il blocco del trasmettitore mediante un'azione amministrativa. Il numero minimo di code condivise è il numero di porte meno uno e più con criteri di isolamento aggiuntivi. Le code condivise hanno una priorità fissa interna dello scheduler e i frame vengono trasmessi secondo il principio First Come First Serve.
L'imprecisione di sincronizzazione dell'orologio nel peggiore dei casi non riduce l'utilizzo del collegamento, contrariamente agli approcci a tempo come TAS (Qbv) e CQF (Qch).
Selezione dei percorsi di comunicazione e tolleranza ai guasti
Controllo e prenotazione del percorso IEEE 802.1Qca (PCR)
IEEE 802.1Qca Path Control and Reservation (PCR) specifica le estensioni del protocollo Intermediate Station to Intermediate Station (IS-IS) per configurare più percorsi nelle reti a ponte.
Lo standard IEEE 802.1Qca utilizza il Shortest Path Bridging (SPB) con una modalità ibrida di rete definita dal software (SDN): il protocollo IS-IS gestisce le funzioni di base, mentre il controller SDN gestisce i percorsi espliciti utilizzando Path Computation Elements (PCE) sul server dedicato nodi. IEEE 802.1Qca integra protocolli di controllo per gestire più topologie, configurare un percorso di inoltro esplicito (un percorso predefinito per ogni flusso), riservare larghezza di banda, fornire protezione e ridondanza dei dati e distribuire messaggi di sincronizzazione e controllo del flusso. Questi sono derivati dai protocolli Equal Cost Tree (ECT), Multiple Spanning Tree Instance (MSTI) e Internal Spanning Tree (IST) ed Explicit Tree (ET).
Replica ed eliminazione dei frame IEEE 802.1CB per l'affidabilità (FRER)
IEEE 802.1CB Frame Replication and Elimination for Reliability (FRER) invia copie duplicate di ciascun frame su più percorsi disgiunti, per fornire una ridondanza proattiva senza soluzione di continuità per le applicazioni di controllo che non possono tollerare la perdita di pacchetti.
La replica del pacchetto può utilizzare le informazioni sulla classe di traffico e sul percorso per ridurre al minimo la congestione della rete. Ogni frame replicato ha un numero di identificazione della sequenza, utilizzato per riordinare e unire i frame e per scartare i duplicati.
FRER richiede una gestione centralizzata della configurazione e deve essere utilizzato con 802.1Qcc e 802.1Qca. Sono supportati HSR e PRP con tolleranza ai guasti industriali specificati in IEC 62439-3.
Progetti attuali
Protocollo di registrazione locale del collegamento IEEE 802.1CS
I dati di stato MRP per un flusso richiedono 1500 byte. Con flussi di traffico aggiuntivi e reti più grandi, la dimensione del database aumenta proporzionalmente e gli aggiornamenti MRP tra i bridge adiacenti rallentano in modo significativo. Il Link-Local Registration Protocol (LRP) è ottimizzato per un database di dimensioni maggiori di circa 1 Mbyte con una replica efficiente che consente aggiornamenti incrementali. I nodi che non rispondono con dati obsoleti vengono eliminati automaticamente. Mentre MRP è specifico per l'applicazione, con ogni applicazione registrata che definisce il proprio insieme di operazioni, LRP è neutrale rispetto all'applicazione.
Protocollo di assegnazione delle risorse IEEE 802.1Qdd
SRP e MSRP sono progettati principalmente per applicazioni AV: il loro modello di configurazione distribuita è limitato alle classi A e B di Stream Reservation (SR) definite dal Credit-Based Shaper (CBS), mentre IEEE 802.1Qcc include un modello di configurazione CNC più centralizzato che supporta tutti nuove funzionalità TSN come shaper aggiuntivi, prelazione dei frame e ridondanza del percorso.
Il progetto IEEE P802.1Qdd aggiorna il modello di configurazione distribuita definendo il nuovo protocollo di allocazione delle risorse peer-to-peer basato sul protocollo di registrazione locale del collegamento P802.1CS. RAP migliorerà la scalabilità e fornirà la prenotazione dinamica per un numero maggiore di flussi con il supporto per la trasmissione ridondante su più percorsi in 802.1CB FRER e l'autoconfigurazione del ripristino della sequenza.
RAP supporta la capacità di "calcolo della latenza per hop indipendente dalla topologia" degli shaper TSN come 802.1Qch Cyclic Queuing and Forwarding (CQF) e P802.1Qcr Asynchronous Traffic Shaping (ATS). Migliorerà anche le prestazioni in condizioni di carico elevato e supporterà il proxy e la diagnostica avanzata, il tutto mantenendo la compatibilità con le versioni precedenti e l'interoperabilità con MSRP.
Protocollo di rilevamento del livello di collegamento IEEE 802.1ABdh v2
IEEE P802.1ABdh Station and Media Access Control Connectivity Discovery - Il supporto per Multiframe Protocol Data Units (LLDPv2) aggiorna LLDP per supportare il protocollo IETF Link State Vector Routing e migliorare l'efficienza dei messaggi di protocollo.
Modelli di dati YANG
Lo standard IEEE 802.1Qcp implementa il modello dati YANG per fornire un framework Universal Plug-and-Play (uPnP) per la segnalazione dello stato e la configurazione di apparecchiature come Media Access Control (MAC) Bridge, Two-Port MAC Relays (TPMR), Customer Bridge Virtual Local Area Network (VLAN) e Provider Bridge e per supportare gli standard 802.1X Security e 802.1AX Datacenter Bridging.
YANG è un Unified Modeling Language (UML) per dati di configurazione e stato, notifiche e chiamate di procedure remote, per impostare la configurazione del dispositivo con protocolli di gestione della rete come NETCONF/RESTCONF.
DetNet
Il gruppo di lavoro IETF Deterministic Networking (DetNet) si sta concentrando sulla definizione di percorsi di dati deterministici con elevata affidabilità e limiti su latenza, perdita e variazione del ritardo dei pacchetti (jitter), come streaming audio e video, automazione industriale e controllo del veicolo.
Gli obiettivi della rete deterministica sono la migrazione di applicazioni industriali e audio-video time-critical e ad alta affidabilità da reti Fieldbus speciali a reti a pacchetto IP . Per raggiungere questi obiettivi, DetNet utilizza l'allocazione delle risorse per gestire le dimensioni del buffer e le velocità di trasmissione al fine di soddisfare i requisiti di latenza end-to-end. Protezione del servizio contro i guasti con ridondanza su più percorsi e route esplicite per ridurre la perdita e il riordino dei pacchetti. La stessa rete fisica deve gestire sia il traffico riservato time-critical che il traffico best-effort regolare e la larghezza di banda riservata inutilizzata deve essere rilasciata per il traffico best-effort.
DetNet opera nei segmenti instradati IP Layer 3 utilizzando un livello Software-Defined Networking per fornire l' integrazione di IntServ e DiffServ e fornisce servizi su segmenti con bridge Layer 2 inferiori utilizzando tecnologie come MPLS e IEEE 802.1 AVB/TSN.
I protocolli di routing di Traffic Engineering (TE) traducono le specifiche del flusso DetNet in controlli AVB/TSN per l'accodamento, la modellazione e gli algoritmi di pianificazione, come lo shaper basato sul credito IEEE 802.1Qav, lo shaper attivato dal tempo IEEE802.1Qbv con un programmatore orario rotante, IEEE802. Doppio buffering sincronizzato 1Qch, prelazione del pacchetto Ethernet 802.1Qbu/802.3br e replica ed eliminazione del frame 802.1CB per l'affidabilità. Inoltre, l'interazione del protocollo definita da IEEE 802.1CB viene utilizzata per pubblicizzare le capacità della sottorete TSN ai flussi DetNet tramite le funzioni di identificazione del MAC di destinazione attivo e del flusso VLAN. I flussi DetNet sono abbinati per indirizzo MAC di destinazione, ID VLAN e parametri di priorità ai requisiti Stream ID e QoS per oratori e ascoltatori nella sottorete AVB/TSN.
Standard
| Standard | Titolo | Stato | Data di pubblicazione |
|---|---|---|---|
| IEEE 802.1BA-2011 | Sistemi Audio Video Bridging (AVB) | Attuale, modificata da Cor1-2016 | 30 settembre 2011 |
| IEEE 802.1AS-2020 | Temporizzazione e sincronizzazione per applicazioni sensibili al tempo ( gPTP ) | Attuale | 30 gennaio 2020 |
| IEEE 802.1ASdm | Temporizzazione e sincronizzazione per applicazioni sensibili al tempo - Hot Standby | Bozza 0.2 | 15 marzo 2021 |
| IEEE 802.1Qav-2009 | Miglioramenti all'inoltro e all'accodamento per flussi sensibili al tempo | Incorporato in IEEE 802.1Q | 5 gennaio 2010 |
| IEEE 802.1Qat -2010 | Protocollo di prenotazione del flusso (SRP) | 30 settembre 2010 | |
| IEEE 802.1aq -2012 | Ponte sul percorso più breve (SPB) | 29 marzo 2012 | |
| IEEE 802.1Qbp-2014 | Percorsi multipli a costo uguale (per il bridging del percorso più breve) | 27 marzo 2014 | |
| IEEE 802.1Qbv-2015 | Miglioramenti per il traffico programmato | 18 marzo 2016 | |
| IEEE 802.1Qbu-2016 | Prelazione telaio | 30 agosto 2016 | |
| IEEE 802.1Qca-2015 | Controllo e prenotazione del percorso | 11 marzo 2016 | |
| IEEE 802.1Qch-2017 | Accodamento e inoltro ciclici | 28 giugno 2017 | |
| IEEE 802.1Qci-2017 | Filtraggio e controllo per stream | 28 settembre 2017 | |
| IEEE 802.1Q -2018 | Bridge e reti con ponte ( incorpora 802.1Qav/Qat/aq/Qbp/Qbv/Qbu/Qca/Qci/Qch e altri emendamenti ) | Attuale | 6 luglio 2018 |
| IEEE 802.1Q-Rev | Bridge e reti con bridge | Bozza 1.0 | 1 agosto 2021 |
| IEEE 802.1Qcc-2018 | Miglioramenti del protocollo di prenotazione del flusso (SRP) e miglioramenti delle prestazioni | Attuale | 31 ottobre 2018 |
| IEEE 802.1Qcy-2019 | Protocollo di rilevamento e configurazione (VDP) dell'interfaccia della stazione virtuale (VSI) | Attuale | 4 giugno 2018 |
| IEEE 802.1Qcj | Collegamento automatico ai servizi Provider Backbone Bridging (PBB) | Bozza 1.3 | 12 febbraio 2021 |
| IEEE 802.1Qcr-2020 | Modellazione asincrona del traffico | Attuale | 6 novembre 2020 |
| IEEE 802.1Qcz | Isolamento della congestione | Bozza 2.0 | 15 gennaio 2021 |
| IEEE 802.1Qdd | Protocollo di allocazione delle risorse | Bozza 0,5 | 1 settembre 2021 |
| IEEE 802.1Qdj | Miglioramenti alla configurazione per TSN | Bozza 0.1 | 20 novembre 2020 |
| IEEE 802.1AB-2016 | Rilevamento della connettività di controllo dell'accesso a stazioni e supporti ( Link Layer Discovery Protocol (LLDP)) | Attuale | 11 marzo 2016 |
| IEEE 802.1ABdh | Rilevamento della connettività per il controllo dell'accesso a stazioni e supporti - Supporto per unità dati protocollo multiframe (LLDPv2) | Bozza 2.0 | 15 luglio 2021 |
| IEEE 802.1AX -2020 | Aggregazione link | Attuale | 30 gennaio 2020 |
| IEEE 802.1CB-2017 | Replica ed eliminazione dei frame per l'affidabilità | Attuale | 27 ottobre 2017 |
| IEEE 802.1CBdb | FRER Funzioni estese di identificazione del flusso | Bozza 2.0 | 22 luglio 2021 |
| IEEE 802.1CM-2018 | Rete sensibile al tempo per Fronthaul | Attuale | 8 giugno 2018 |
| IEEE 802.1CMde-2020 | Miglioramenti ai profili Fronthaul per supportare la nuova interfaccia Fronthaul, la sincronizzazione e gli standard di sincronizzazione | Attuale | 16 ottobre 2020 |
| IEEE 802.1CS-2020 | Protocollo di registrazione locale del collegamento | Attuale | 3 dicembre 2020 |
| IEEE 802.1CQ | Assegnazione di indirizzi multicast e locali | Bozza 0.7 | 19 luglio 2021 |
| IEEE 802.1DC | Qualità della fornitura del servizio da parte dei sistemi di rete | Bozza 1.1 | 18 ottobre 2019 |
| IEEE 802.1DF | Profilo TSN per reti di fornitori di servizi | Bozza 0.1 | 21 dicembre 2020 |
| IEEE 802.1DG | Profilo TSN per comunicazioni Ethernet nel veicolo automobilistico | Bozza 1.3 | 18 dicembre 2020 |
| IEEE 802.1DP | TSN per comunicazioni Ethernet a bordo aerospaziale | preparazione | 3 dicembre 2020 |
| IEC/IEEE 60802 | Profilo TSN per l'automazione industriale | Bozza 1.3 | 25 agosto 2020 |
Progetti correlati:
| Standard | Titolo | Stato | Data aggiornata |
|---|---|---|---|
| IEEE 802.3br | Intervallo del traffico espresso | Pubblicato | 30 giugno 2016 |
Riferimenti
link esterno
- Gruppo di attività di rete sensibile al tempo IEEE 802.1
- Archivio di documenti pubblici IEEE 802.1
- Ethernet in tempo reale – ridefinito (in tedesco)
- Visione Time Sensitive Networking (TSN): Unificare il business e l'automazione industriale
- L'attività di TSN sta innescando un'altra guerra del bus di campo?
- progetto di ricerca relativo alle applicazioni TSN negli aeromobili
- Guida rapida per la visualizzazione di TSN
- Formazione TSN , Marc Boyer (ONERA), Pierre Julien Chaine (Airbus Defence and Space)