Sartomiki.net

Qualità del servizio su reti IP (QOS)
Le reti a commutazione di pacchetto sono nate seguendo la filosofia best-effort, senza quindi garantire tempi di consegna o senza differenziare il traffico. Per ottenere questi risultati si devono usare altri protocolli:
-RSVP permette di prenotare alcune risorse
-servizi differenziati permettono di classificare il traffico (non si garantisce nulla, ma si garantisce che alcune classi abbiano priorità su altre classi).
-servizi integrati permettono di garantire risorse (molto difficile da implementare).

Meccanismi per garantire QOS
Alcuni meccanismi usati sono:
-politiche di scheduling nelle code dei router:
--coda standard a FIFO non consente la QOS.
--coda a priorità (senza diritto di prelazione) invia i pacchetti a seconda della classe di traffico. Esistono quindi code FIFO differenti a seconda della priorità (le code a priorità maggiore vengono svuotate prima di trasmettere i pacchetti delle code a priorità minore).
--round robin cicla a turno tutte le code.
--weighted fair queuing permette di gestire pesi differenti per le diverse code, che comunque vengono ciclate.
-politiche di scarto delle code dei router:
--tail drop elimina il pacchetto che arriva.
--priority elmina il pacchetto a priorità più bassa.
--random elimina un pacchetto a caso.
--RED elimina dei pacchetti con probabilità maggiore al crescere della lunghezza della coda.
-meccanismi di policing (permettono di verificare se ognuno rispetta il proprio limite di traffico) si basano sul traffico medio sul lungo periodo e sulla massima dimensione dei burst (scarica di pacchetti massimo), che viene chiamata dimensione del picco. Il meccanismo più usato è il modello a token (token bucket), che prevede di garantire le risorse in base a dei "gettoni". Se non sono ancora stati usati tutti i gettoni, la risorsa richiesta viene esaudita immediatamente, altrimenti è messa in attesa di un gettone oppure marcata come non garantita. Il numero massimo di pacchetti immessi nella rete è rt+b con r uguale alla velocità di immissione dei token e b uguale al numero massimo di token; b indica anche la dimensione massima del burst.
Con la combinazione delle tecniche precedenti è possibile garantire la QOS. Ad esempio se si utilizza il modello a token unito con un sistema a code di priorità i pacchetti a priorità più alta avremo un tempo di attraversamento garantito di t=b*L/r, mentre la banda garantita è data dalla banda minima della rete.

IntServ
Su IP non ci sono problemi di segnalazione in quanto c'è instradamento connection less e in più IP è best-effort.
I problemi di segnalazione su IP nascono quando si vuole una certa QOS. Per questo motivo sono stati introdotti due approcci al problema:
-Intserv prevede di trattare il traffico in base al flusso di appartenenza dei pacchetti.
-DiffServ prevede di trattare il traffico in base al tipo.

IntServ
IntServ è uno standard, che specifica i descrittori dei flussi. Essi sono basati su:
-filterspec, dato dalla destinazione/sorgente.
-flowspec, dato dalle caratteristiche del traffico e dai servizi che si vogliono garantire.
Per controllare i flussi, i router sono muniti di un classificatore dei pacchetti, uno scedulatore dei pacchetti e un gestore dei buffer. In più è necessario un controllo di immissione per i pacchetti in ingresso, in modo da garantire la prenotazione delle risorse.

Protocollo RSVP
RSVP prevede una serie di messaggi tra i router in modo da dare la possibilità di prenotare risorse per flussi. Il problema principale è che utilizzare i flussi a priorità differenziata è molto complesso da gestire per i router molto trafficati. Un altro problema è la bassa scalabilità del protocollo, in quanto al crescere del numero di flussi, le difficoltà aumentano.
Lo standard è stato completato nel 1994.
La maggior parte dei router è in grado di gestire i messaggi RSVP ma, in realtà, solo pochi filtrano realmente il traffico grazie a questo protocollo. RSVP garantisce:
-perdite.
-ritardo.
-banda.
RSVP controlla l'accesso e le tecniche di accodamento di ogni flusso all'interno dei router che lo usano. RSVP è pensato per ricevitori e flussi eterogenei.
Il ricevitore chiede alla rete che gli venga attribuito un flusso, in modo che gli venga garantita una certa QoS. Le risorse vengono prenotate in base alle possibilità dei router e non in base all'RSVP.

DiffServ
DiffServ permette di classificare il traffico in diversi tipi indipendenti dai flussi di dati. In questo modo viene semplificato il lavoro dei router. Tutti i pacchetti di una classe  vengono trattati allo stesso modo. Nel momento in cui un pacchetto entra in una rete viene classificato e non sono necessarie ulteriori classificazioni (a meno che non si esca da una rete). Questo meccanismo è molto più semplice e scalabile rispetto a IntServ.
La classificazione può essere gestita direttamente dall'utente, nel caso in cui si facciano pagare di più i servizi a priorità più alta.
SLA indica il tipo di contratto sulla vendita dei servizi (tra clienti e ISP oppure tra ISP), mentre SLS indica le caratteristiche garantite a seconda del tipo di traffico (burst size).
Un DiffServ necessita di un classificatore, uno scheduler delle code e un riclassificatore.
Il campo ToS dell'IP indica la classe di appartenenza del pacchetto.
All'interno del DiffServ è stato definito anche il comportamento della classe all'interno di ogni hop (PHB), in quanto essa può variare in ogni router. I parametri di variazione sono impostati dal gestore del router. Gli standard sono:
-expedite forwarding garantisce un rate di servizio maggiore o uguale al valore specificato.
-assured forwarding assegna diverse priorità di scarto a seconda della classe.
E' possibile definire il per domain behavior (PDB), che informa su quale comportamento e quali garanzie si avranno all'interno di un intero dominio. Vengono definiti:
-i classificatori.
-i condizionatori.
-la concatenazione dei PHB previsti.