![[successivo]](../icons/right.gif){kind=icon}
![[precedente]](../icons/left.gif){kind=icon}
![[indice]](../icons/contents.gif){kind=icon}
Le applicazioni Real Time per definizione non tollerano bene interruzioni anche temporanee della comunicazione e quindi sono difficilmente supportabili in un ambiente a commutazione di pacchetto con casualita' intrinseca del tempo di transito e del percorso usato dai singoli pacchetti.
Tipiche applicazioni Real Time possono essere:
Problemi ausiliari di applicazioni Real Time possono essere:
Molta esperienza e'stata acquisita in Internet in questo campo con la rete Mbone.
IPv6 risponde ai requisiti Real Time con l'introduzione di due nuovi campi nella testata principale: la Priorita'e l'Etichetta di Flusso.
La definizione di flusso di IPv6 e':
Un flusso e' una sequenza di pacchetti inviati da una certa sorgente ad una certa destinazione (unicast o multicast), per cui e' desiderato un trattamento particolare da parte dei router intermedi.
La definizione di flusso e' infatti quasi autoreferenziali: costituisce un flusso un insieme di pacchetti dalla stessa sorgente per la stessa destinazione e con la stessa etichetta di flusso.
L'etichetta di flusso e' un campo a 24 bit posto proprio all'inizio della testata IP per velocizzarne il trattamento. Non tutti i pacchetti devono usare l'etichetta di flusso, anzi in un periodo iniziale si prevede che la maggior parte dei pacchetti non la useranno.
Le etichette di flusso vengono usate quando la trasmissione e' sottoposta a trattamento speciale, per esempio a limiti real-time severi.
Non vi e' un'associazione precisa tra flusso e routing, in particolare Source Routing. Nello stesso percorso possono trovarsi pacchetti appartenenti a piu' flussi o a nessun flusso. D'altronde, se il Source Routing di una comunicazione cambia, deve cambiare anche l'etichetta di flusso.
E' da notare che il concetto di flusso NON corrisponde al concetto di circuito virtuale.
I router pongono normalmente i pacchetti ricevuti e da smistare in una coda FIFO unica. Anziche' limitarsi a questa situazione, viene ora definita la possibilita' di avere piu' code di smistamento dati. Tipicamente viene generata una coda per ogni flusso ed una coda aggiuntiva per i pacchetti senza flusso.
Viene quindi usata una procedura di riservazione per dichiarare i flussi real-time e per informare il router dei loro requisiti. Ogni coda di flusso real-time viene servita ad un ritmo compatibile con i suoi requisiti. La rimanente coda dati viene invece servita in background, a capacita' ridotta.
Il protocollo di riservazione flussi si chiama RSVP (ReSerVation Protocol). RSVP e' un protocollo receiver driven: toccano ai riceventi le decisioni di quali flussi sorgente ricevere, quanta banda sono disposti ad allocare a ciascuno, e l'eventuale costo di ciascun flusso. Queste decisioni sono comunicate inviando messaggi RSVP alla rete.
Le sorgenti abilitano la riservazione inviando messaggi PATH insieme ai pacchetti normali di dati. I messaggi RSVP vengono propagati a ritroso lungo l'esatto percorso seguito dai messaggi PATH.
Un tipico messaggio RSVP includera' l'indirizzo o indirizzi delle sorgenti a cui viene concesso l'invio di flussi, l'indirizzo del gruppo multicast a cui inviare i dati, e parametri concernenti la qualita' del servizio. Conterra' inoltre un filtro specificante il profilo dei dati che il ricevente selezionera' .
Un profilo e' una specifica delle etichette di flusso accettate e della priorita' che verra' associata a ciascuna. Per esempio un file sonoro puo' essere diviso in componenti parallele a diversa frequenza di campionamento: le frequenze piu' alte apparterranno a flussi con priorita' minore di quelle piu' basse. Oppure un file sonoro avra' priorita di flusso piu' elevata di un normale file transfer.
Il codice dei filtri e' definito a livelli superiori allo strato IP, ma per funzionare dovra' compiere una violazione di livello e accedere allo strato IP. Trovera' comuunque l'etichetta di flusso immediatamente all'inizio della testata IP.
Non si puo' negare l'importanza presente e futura delle applicazioni multimediali, di rete e interattive, che hanno tutte requisiti real-time. Alternative e/o estensioni al concetto di riservazione risorse per questo tipo di applicazioni sono espresse dai concetti di applicativi adattativi, fair queuing, class-based queuing e hierarchical encoding.
A partire dal 1988 il protocollo TCP implementa un algoritmo di slow start, con il quale inizia la connessione ad una velocita' minima ed aumenta in seguito la velocita' di comunicazione pacchetti (finestra di trasmissione scorrevole). TCP include inoltre un meccanismo di feedback per ridurre automaticamente la velocita' di invio pacchetti in seguito a detezione di condizioni di congestione di rete. L'implementazione di meccanismi di feedback, detti di closed loop, aumentano fortemente l'efficienza del TCP.
Per contro, la maggior parte degli applicativi multimediali di rete moderni sono open loop, senza meccanismi di feedback. La loro introduzione generera degli applicativi adattativi, o network conscious, che non saranno cosi' soggetti a congestioni.
Un altro concetto per ridurre la banda richiesta e' quello di navigazione inerziale: l'applicativo predice il comportamento futuro di oggetti in movimento, colori, font, componenti, prima di avere ricevuto conferma positiva dai messaggi di rete. La penalita' possibile da pagare e' quella di sussulti di continuita' in caso di errori di predizione. E' possibile introdurre uno sfasamento temporale (buffer) che faccia si' che l'applicativo esegua i comandi real time con un leggero ritardo, spesso impercettibile; questo allieva il problema di errori di predizione.
Difatti l'unico campo relativamente intrattabile e' quello della trasmissione sonora. Anche qui si fanno progressi, ad esempio trasmettendo pacchetti contenenti non una fetta di tempo di un brano sonoro, ma una fetta di frequenze. La perdita' di pacchetti causa una diminuzione temporanea della qualita', non un intervallo vuoto.
L'idea di base e che i pacchetti vengono suddivisi, nei router o nelle stazioni riceventi, in piu' code, come per la trasmissione di flussi. Ciascuna coda riceve la stessa quota di risorse, ma senza riservazione esplicita.
Le code possono essere definite sulla base dell'indirizzo sorgente, o dell'indirizzo destinazione, o del servizio. Il software di gestione rete forza l'equita' di trattamento di ciascuna coda e rifiuta richieste di priorita', forse provenienti da hacker o da sorgenti arroganti.
Questo concetto e' un'estensione del fair queuing in cui le connessioni sono divise in classi di priorita'. Le classi vengono assegnate ad organizzazioni o a clienti specifici, per contratto, dal fornitore di servizi. Ogni classe ha la garanzia di una banda passante minima in caso di congestione di rete. La somma delle bande di ciascuna classe non supera la banda totale disponibile.
In tempi normali, a basso carico, trasmissioni di una determinata classe possono inviare pacchetti anche ad una velocita' superiore della loro banda minima. Si ha comunque la garanzia che al deterioramento del servizio non si scendera' mai al di sotto di una soglia minima e che il servizio non verra' interrotto.
Applicazioni adattative, conscie del valore della banda minima, possono forse adottare algoritmi particolari, predittivi o adattativi o euristici, all'approssimarsi della soglia minima, o cambiare drasticamente il trattamento dati.
Sia data una trasmissione richiedente una banda passante ottimale X. Si suddivida la banda in sezioni, per esempio del 20%, 40%, 60%, 80% e 100% di X. Si assegni una priorita' diversa a ciascuna sezione, piu' alta per la sezione a bassa percentuale di banda.
In questo caso delle congestioni di rete produrranno la perdita dei pacchetti a priorita' piu bassa, cioe' quelli che portano il servizio migliore. I vantaggi sono:
La Codifica Gerarchica e' supportata dal campo Priorita' della testata IPv6. Il campo a 4 bit supporta 16 valori di priorita'. La specifica IPv6 definisce i primi 8 per il traffico controllato da congestioni:
I codici da 8 a 15 sono riservati per traffico real time, o meglio non controllato dalla congestione. I due intervalli da 0 a 7 e da 8 a 15 sono indipendenti l'uno dall'altro: non e' che i pacchetti a priorita' 8 vengano fatti passare prima dei pacchetti a priorita' 7.
Il campo priorita' era stato concepito per l'uso con un protocollo di riservazione e la definizione di flussi. Pacchetti appartenenti a flussi real-time ricevono priorita' nel secondo intervallo.
E' pensabile lo sfruttamento di questo campo anche senza la gestione di flussi e riservazioni, occorre comunque sempre associarlo ad un algoritmo di accodamento efficace, come il fair queuing o il class-based queuing
L'uso delle etichette di flusso puo' essere problematico poiche' in un router vi possono essere molti piu' flussi che sorgenti o destinazioni. Presumibilmente un router manterrebbe una tabella cache dei flussi attivi. L'assegnazione di numeri casuali come etichette di flusso faciliterebbe infatti lo hashing in una tale tabella. Il numero elevato di flussi simultanei richiederebbe una grande cache dei flussi o genererebbe un numero discreto di cache misses..
Le procedure di riservazione vengono percepite da alcuni come metodi di gestione della scarsita' di risorse. Viene considerata una strategia migliore usare piu' banda passante sul collegamento di rete fin dall'inizio, forse rivolgendosi a fornitori d'accesso migliori. Viene a volte ritenuto migliore l'uso di applicazioni adattative piuttosto che riservazioni di risorse.