Integrated Services (IntServ)

Attualmente la rete Internet fornisce unicamente il servizio best effort, cioè tutte le entità che entrano in gioco nell'inoltro dei pacchetti cercano di fare del loro meglio ma di fatto non vengono date garanzie di nessun tipo. Con IntServ, [10], l'intenzione è di estendere (senza stravolgere) l'attuale modello della rete aggiungendo nuove classi di servizio a quella già esistente.

Nella rete Internet attuale tutti i pacchetti vengono trattati allo stesso modo e sono normalmente serviti da nodi a disciplina FIFO. In una rete che supporta IntServ, invece, ogni flusso^3.3 può ricevere una determinata qualità del servizio, che è stata negoziata all'inizio tra l'applicazione e la rete tramite il protocollo RSVP [11] (Resource reSerVation Protocol). Lo stesso RSVP viene anche utilizzato per settare la rete al fine di garantire che tutti i pacchetti di quel flusso beneficino della stessa qualità del servizio. Quindi prima di iniziare la trasmissione, l'applicazione, utilizzando RSVP, deve costruire i percorsi e prenotare le risorse.

Il controllo del traffico (Traffic Control)

Il meccanismo che si occupa di garantire la qualità del servizio necessaria si chiama controllo del traffico, in figura è mostrato il modello di riferimento della sua implementazione nei router.

Figure: Controllo del traffico

Sicuramente gli elementi principali di questo modello sono i seguenti:

1. Packet Scheduler.
   Lo schedulatore si occupa della spedizione dei pacchetti dei diversi stream usando un insieme di code e altri meccanismi basati ad esempio su timer. Deve essere implementato laddove i pacchetti sono accodati, cioè tipicamente nell'output driver del sistema operativo. Gli algoritmi di scheduling possono seguire un approccio a priorità, round robin oppure Weighted Fair Queueing (WFQ).
   Lo schedulatore inoltre decide quali pacchetti scartare in caso di sovraccarico del nodo ed implementa anche funzioni di stima del traffico. Analizza cioè il traffico e ne trae statistiche che ad esempio utilizza per il policing^3.4.
2. Packet Classifier.
   Per implementare il controllo sul traffico (e anche ad esempio la tariffazione) ogni pacchetto arrivato viene mappato in una specifica classe, e ogni pacchetto di una stessa classe riceverà lo stesso trattamento dallo schedulatore.
   Questa mappatura è effettuata dal classificatore. Una classe può corrispondere tanto ad un unico flusso che ad una categoria di flussi dalle caratteristiche comuni. La scelta della classe appropriata è fatta localmente in ogni router e riflette l'importanza che il router dà al singolo flusso.
   La classificazione può essere fatta ad esempio sulla base degli indirizzi sorgente e destinazione, sul tipo di protocollo oppure sul numero di porto.
3. Admission Control.
   É l'algoritmo di decisione che il router utilizza per stabilire se può garantire o meno la qualità del servizio richiesta da un nuovo flusso senza influenzare le precedenti richieste (che sono state già accettate).
   La decisione è presa basandosi sui dati acquisiti dallo schedulatore oppure su stime della situazione peggiore con gli attuali flussi.

Osservando la figura si nota che è divisa in due parti, nella parte superiore troviamo il codice di background, queste routine si occupano di creare le strutture dati che controllano il meccanismo di instradamento. Il routing agent implementa un particolare protocollo di routing e crea il database di routing. Il reservation setup agent implementa il protocollo utilizzato per riservare le risorse (tipicamente RSVP). Se l'admission control da la conferma ad una nuova richiesta, i cambiamenti appropriati sono apportati al database dello schedulatore e del classificatore al fine di garantire la qualità del servizio richiesta. Infine, ogni router supporta un agente per il network management, questo agente deve essere in grado di modificare il database dello schedulatore e del classificatore, ad esempio, per settare le politiche dell'admission control.

Nella parte inferiore troviamo il percorso di inoltro, che viene seguito da ogni pacchetto e deve essere molto ottimizzato affinché il router sia in grado di offrire buone prestazioni.

Nel modello iniziale di IntServ sono state pensate tre diverse classi di servizio corrispondenti a tre diversi tipi di applicazioni.

1. Applicazioni in tempo reale ``hard'' o intolleranti.
   Queste applicazioni hanno vincoli stringenti sui tempi di consegna dei pacchetti e sulla banda disponibile, ad esempio perché sono state progettate inizialmente per funzionare su reti a commutazione di circuito.
2. Applicazioni in tempo reale ``soft'' o tolleranti.
   Sono applicazioni che accettano un comportamento aleatorio della rete, e quindi possono tollerare se un pacchetto non arriva oppure arriva molto in ritardo. Tutte le applicazioni multimediali pensate per la rete attuale sono di questo tipo.
3. Applicazioni elastiche.
   Aspettano indefinitamente un pacchetto e quindi non sono compromesse da un ritardo (anche se questo non vuol dire che l'utente non ne sia infastidito). Rientrano in questa categoria le classiche applicazioni interattive come telnet, ftp, ecc

A questa distinzione corrisponde la distinzione nelle seguenti classi di servizio:

1. Servizio garantito
2. Servizio a carico controllato
3. Servizio best effort

L'ultima classe corrisponde al classico servizio offerto da Internet ed in esse rientrano oltre alle applicazioni elastiche anche tutte le altre applicazioni non interattive (come ad esempio la posta elettronica), le altre due classi di servizio vengono invece illustrate di seguito.

Il servizio garantito (Guaranteed Service)

Questa classe fornisce al flusso di dati generati dall'applicazione cliente un limite stretto sul ritardo di trasmissione end-to-end del generico pacchetto, inoltre viene garantita anche la banda che sarà fornita al flusso. Il servizio garantito quindi rappresenta sicuramente quello con le garanzie massime possibili, ed ha caratteristiche tali da permettere di emulare una comunicazione su circuito dedicato.

Le informazioni relative al traffico generato, le caratteristiche della rete, i parametri di prenotazione ecc. vengono scambiate tra i nodi tramite il protocollo RSVP.

Il servizio a carico controllato (Controlled Load)

Il servizio a carico controllato può essere considerato come una sorta di ``controlled best-effort'', nel senso che ha le stesse caratteristiche di un servizio best-effort (quindi nessuna garanzia) su di una rete poco carica, tuttavia si cerca di fare in modo che il servizio non cambi anche al crescere del carico della rete.

In altre parole l'utente che richiede un servizio a carico controllato ottiene un servizio best-effort che però risulta essere poco sensibile alle variazioni del carico della rete. É chiaro quindi che per riuscire a mantenere queste promesse è fondamentale il ruolo dell'admission control.

Resource reSerVation Protocol (RSVP)

Il protocollo RSVP è usato dagli host per richiedere una specifica qualità del servizio alla rete, ma è anche usato dai router per spedire informazioni sulla qualità del servizio lungo il percorso seguito dal flusso al fine di stabilire e mantenere la classe di servizio richiesta.

Le risorse sono riservate per i flussi simplex, cioè in una sola direzione, quindi sono ben distinti i ruoli di trasmettitore e ricevitore anche se nulla vieta che una stessa entità possa essere allo stesso tempo trasmettitore e ricevitore, in realtà RSVP è indipendente da IntServ, quindi può essere utilizzato anche in altri sistemi che garantiscono la qualità del servizio, la sua integrazione con IntServ è illustrata in [12].

Il protocollo gira al di sopra di IP, tuttavia non trasporta in alcun modo dati, ed è quindi scorretto considerarlo un protocollo di trasporto. Esso fa parte (insieme ad ICMP, IGMP ed ai protocolli di routing) di quei protocolli che possiamo immaginare confinati ancora a livello tre anche se ne sfruttano i servizi.

É interessante notare che RSVP è esplicitamente pensato per funzionare in ambiente multicast, quindi il caso unicast è visto come una semplice specializzazione. Questo permette di fare in modo che ogni ricevitore possa richiedere una qualità del servizio diversa da quanto fatto dagli altri.

Figure: RSVP negli host e nei router.

In figura è mostrato il modo in cui il processo RSVP interagisce negli host e nei router.

Nel processo di prenotazione il ruolo fondamentale è giocato dai messaggi Path e Resv (figura ). I primi vanno dal trasmettitore ad ricevitore, trasportano informazioni sul flusso e sono usati per costruire il percorso che sarà seguito dal flusso. I messaggi Resv seguono il percorso contrario e sono quelli che di fatto compiono la prenotazione. Come si vede la prenotazione è di tipo receiver initiated, questo approccio è molto vantaggioso nel caso multicast, e permette una flessibilità maggiore rispetto al caso in cui la prenotazione viene effettuata dal trasmettitore.

Figure: Il meccanismo di prenotazione.

Un messaggio Path contiene le seguenti informazioni:

• L'indirizzo dell'ultimo nodo RSVP lungo il percorso.
• L'indirizzo e il numero di porto della sorgente, oppure un'etichetta di flusso nel caso in cui il protocollo di livello rete la supporti (come ad esempio IPv6).
• Le caratteristiche del traffico che sarà generato dalla sorgente (Tspec).
• Una struttura opzionale chiamata Adspec che è aggiornata ad ogni nodo attraversato e serve per stabilire le caratteristiche del percorso dalla sorgente alla destinazione.

Quando un nodo riceve un pacchetto Path crea oppure aggiorna lo stato del percorso (path state) che viene poi utilizzato dai messaggi Resv per poter seguire il giusto percorso verso la sorgente. Ad ogni path state è associato un timer che ne indica la validità, una volta scaduto il timer (che può essere resettato se viene ricevuto un messaggio di tipo Path) il path state viene cancellato. Infatti RSVP è un protocollo soft state (detto anche connection less), e quindi i percorsi creati non vengono mantenuti in eterno, ma tendono a ``scadere'', però periodicamente vengono mandati i messaggi Path al fine di mantenere lo stato del percorso nei nodi. Questo comportamento permette di adattarsi dinamicamente ai cambiamenti che si possono avere sulla rete, come ad esempio un cambiamento di un percorso di routing oppure il guasto di un router e così via.

Un messaggio Resv contiene le seguenti informazioni:

• Lo stile di prenotazione, che permette di effettuare una prenotazione per una sorgente ben precisa (Fixed Filter), di condividerla tra più sorgenti selezionate mediante wildcard (Wildcard Filter) oppure di condivere la prenotazione tra più sorgenti selezionate esplicitamente (Shared Explicit).
• La struttura Filterspec, che permette di selezionare il flusso (attraverso l'indirizzo della sorgente oppure tramite protocolli di livello superiore).
• La struttura Flowspec, che contiene una descrizione del traffico a cui va applicata la prenotazione (Tspec) e la classe di servizio richiesta (Rspec).

Footnotes

... flusso^3.3

Un flusso viene definito come una sequenza distinguibile di pacchetti che risultano dall'attività di un singolo utente e che richiedono la stessa qualità del servizio.

... NAME="1572">^3.4

Si controlla se l'host trasmittente rispetta le caratteristiche contrattate per il traffico, in caso che ciò non avvenisse vengono prese delle contromisure.