Capitolo 2
Differentiated
Service
Architecture
Introduzione:
La più grande rete esistente, Internet, tutt’oggi fornisce un servizio Best Effort. Il traffico viene smaltito il più velocemente possibile, senza alcuna garanzia sulla certezza della consegna; inoltre, quando il traffico sulla rete è elevato e non ci sono risorse disponibili a sufficienza, ecco che si genera una situazione di congestione, in cui inevitabilmente i pacchetti in eccesso vengono scartati, rendendo necessaria la loro ritrasmissione con conseguente aumento dei tempi di attesa.
L’aumento della richiesta di applicazioni sulla rete Internet, ed il diversificarsi di queste richieste, hanno portato alla necessità di avere una maggiore affidabilità dei servizi (basti pensare alla videoconferenza, voice over ip etc…) dando origine all’idea di diverse classi di sevizio.
Questo particolare approccio è definito Quality Of Service ( QoS), e cioè la capacità della rete di offrire differenti trattamenti per diverse categorie di traffico. L’utilizzo di diverse classi di servizio consente infatti di poter assegnare le risorse in maniera differenziata in termini di
- Banda (Troughput) - Ritardi ( delay) - Jitter e perdite
L’ Internet Engineering Task Force(IETF), ha proposto due architetture principali per soddisfare questa esigenza di QoS: Integrated Service e Differentiated Service.
In questo capitolo, verrà data un’introduzione del protocollo DiffServ, spiegandone il suo funzionamento, ed infine sarà descritta l’ architettura di rete su cui andremo ad analizzare il protocollo implementato.
2.1 Introduzione alla Qualità del Servizio
La Quality of Services, come detto, è nata dall’ idea di trattare in modo differenziato alcuni pacchetti rispetto ad altri. La parola servizio associata ad un flusso vuol dire che tutti i pacchetti appartenenti ad esso subiscono un trattamento particolare, all’interno della rete, che può essere diverso da quello di tutti gli altri. Un servizio può essere di tipo qualitativo o quantitativo.
In particolare (in un servizio di tipo qualitativo) si possono utilizzare alcuni parametri: • Delay
• Probabilità di eliminazione dei pacchetti • MTU (Maximum Transfer Unit) • Priorità
Esistono ad oggi due tipi di modalità molto diffusi per garantire la Qualità di servizio: • Intserv ed in particolare RSVP (Reservation Protocol)
• Differentiated Services
Il primo alloca statisticamente alcune risorse di rete dedicandole esclusivamente per alcuni flussi, causando pertanto un elevato overhead dovuto alla segnalazione, richiedendo infatti, che tutti i dispositivi di instradamento della rete siano compatibili con questa modalità. RSVP garantisce da un lato un rispetto dei parametri concordati per il tipo di servizio molto accurati e stabili, e dall’altro richiede che tutti i router delle reti interessate dal traffico in questione siano compatibili RSVP e generino una segnalazione periodica a tutti gli altri.
Invece, l’architettura di una rete DiffServ è indipendente dai protocolli di livello 2, e non introduce nuovi meccanismi di segnalazione. Il traffico appartenente ad una stessa “classe di servizio” che ha cioè PHB analoghi e proviene da sorgenti (interfacce di ingresso) distinte, determina nelle interfacce di uscita l’aggregazione: cioè, tali flussi vengono raccolti in un'unica coda e trattati in tutta la rete DiffServ allo stesso modo, come se si trattasse di un flusso unico.
2.2 Introduzione all’architettura Differentiated
Services
L’architettura differentiated services detta anche diffserv o DS, viene definita nell’RFC 2475[]. Nell’RFC in questione sono descritte tutte le regole che dobbiamo rispettare per garantire l’interoperabilità tra i sistemi DS.
La caratteristica di questa architettura è rappresentata dal traffico che non è più considerato come un insieme generico di pacchetti che costituiscono un unico flusso che viene trattato in modo best-effort, ma la banda complessiva disponibile nei vari collegamenti viene suddivisa in un insieme di flussi caratterizzati da alcuni comportamenti comuni.
Al loro interno, sono costituiti da microflussi che rappresentano aggregati di differenti connessioni aventi caratteristiche comportamentali analoghe (stesso BA o Behaviour Aggregate). La gestione di un flusso prescinde quindi dalla sua composizione, ossia da come sono organizzati dentro di sé i vari microflussi, in questo modo, da un lato si opera trattando analogamente tutti i microflussi appartenenti ad un unico Behaviour Aggregate (BA), ma da un altro è necessario che questo flusso aggregato rispetti i livelli di servizio concordati con l’utente (che si vogliono offrire all’utente Service Level Agreement). Una caratteristica importantissima che ha reso vincente la soluzione DS, è la scalabilità, ossia la possibilità di interfacciare tra loro differenti rete DS in sequenza o l’una dentro l’altra, anche senza conoscere nel dettaglio i meccanismi gestionali di ciascuna rete, questo meccanismo è importante nel caso in cui due A.S (Autonomus System) che supportano entrambi DS si interfaccino tra di loro.
Come detto quindi, la rete DiffServ non prevede controlli sul singolo microflusso, ma solo sugli aggregati, pertanto è necessario che verso i nodi più esterni della rete venga previsto un controllo del rispetto dei requisiti che si vogliono mantenere mediante delle policy opportune, per evitare in seguito comportamenti imprevedibili.
Poiché la rete DS è assimetrica, ogni connessione è vista come un flusso monodirezionale. I pacchetti vengono quindi classificati e marcati in modo tale da poter essere trattati in modo diverso, chiaramente la differenza di trattamento è imposta dal particolare comportamento di inoltro (Per Hop Behaviours, PHB) sui nodi lungo il percorso.
C’è quindi una sequenza di operazioni che devono essere svolte per garantire un corretto funzionamento di una rete DS.
La rete DS è divisa in domini (Fig 2.1), a loro volta i domini si possono suddividere in due insimi significativi: i domini centrali (CORE) ed i domini di confine (EDGE).
I domini di confine (Edge Router) sono i più delicati per lo svolgimento delle politiche di qualità e di differenziazione dei servizi, in quanto è lì che è necessario classificare i pacchetti, e svolgere altre importanti operazioni come shaping, policing, dropping e remarking. host A host B edge router core
router routercore
edge router DiffServ Domain forwarding forwarding classification conditioning classification conditioning
2.3 Componenti della rete DiffServ
2.3.1 Condizianamento del traffico
Un condizionatore di traffico può contener i seguenti elementi: classifier, meter, marker, shaker e dropper. Quando i pacchetti escono dal dispositivo di condizionamento del traffico di un edge router, deve essere impostata, ad un valore appropriato, un’etichetta DS (DiffServ Code Point) per ogni pacchetto. I condizionatori di traffico, che rappresentano la parte più complessa della rete DS sono normalmente situati sulla frontiera della rete, ma non è escluso che possano anche essere nei nodi interni di un dominio DS, o talvolta dentro un dominio non compatibile con DS.
La figura 2.2 mostra un diagramma a blocchi di un classificatore e condizionatore di traffico. Questo dispositivo può non essere necessariamente costituito da tutti e quattro gli elementi. Per esempio nel caso in cui nessun profilo di traffico sua configurato, i pacchetti passano soltanto attraverso un classificatore e un marker.
classificatore
classificatore MarkerMarker
Shaper o Dropper Shaper o Dropper meter meter Pacchetti IP
Figura 2.2 : condizionamento e classificazione del traffico
2.3.2 Classificazione dei pacchetti
Prima che il traffico di rete riceva un trattamento differenziato è necessario classificarlo, ossia suddividerlo in classi differenziate in base ai comportamenti di inoltro (PHBs) che si vogliono garantire, quindi associarlo ad opportune code specifiche per i vari tipi di traffico, per poi effettuare l’operazione di marking inserendo un’etichetta (DSCP) presente nell’intestazione del pacchetto IP che viene riconosciuta in tutta la rete DiffServ, in modo da garantire un trattamento diverso dagli altri pacchetti. Pertanto queste funzioni avvengono ai nodi di ingresso (ingress node) della rete DS.
I classificatori selezionano i pacchetti in un flusso di traffico basandosi sul contenuto di una parte dell’intestazione del pacchetto. Esistono due tipi di classificatori:
• Il classificatore Behaviour Aggregate classifica i pacchetti basandosi solo sull’etichetta DSCP.
• Il classificatore Multifield seleziona i pacchetti sulla base di uno o più campi dell’intestazione, come per esempio l’indirizzo IP sorgente e/o destinatario, il
campo DS, il protocollo (protocoll ID), i numeri delle porte sorgente o destinazione, ed altre informazioni.
Figura 2.3 : Esempio di un elemento classifier
Sarà chiaro, che un Classifier considera un flusso di traffico come input e lo dirige al corretto output , così come può essere visto in figura 2.3 .
2.3.3 Profilo del Traffico: Meter
Se le proprietà di un flusso di pacchetti, non superano certi parametri predefiniti, i pacchetti, sono chiamati in-profile (o in caso, contrario out-profile).
I profili di traffico specificano le proprietà temporali (es rate, burst) di un certo livello di servizio, e così forniscono le regole per la determinazione se un pacchetto è in-profile oppure no.
Un esempio di profilo di traffico, può essere : - max bit rate = 1Mbit/s
- burts di 2Mbit/s con massima durata di 20 secondi, se non sono entro 1 minuto l’uno dall’altro Classifier Unclassified traffic Match filter_x Match filter_y No Match Output a Output b Output c
Figura 2.4: Esemio di un elemento meter
La figura 2.4 mostra un elemento meter molto generico. Esso considera un flusso di dati come input e decide se quel flusso è conforme o non conforme ad un certo profilo di traffico.
E facile capire che l’operazione di marking è fortemente influenzata dal metering, infatti subito dopo la misurazione del traffico verranno prese decisioni di dropper o shaping.
2.3.4 Marker
Sulla frontiera (EDGE) di ingresso della rete DiffServ, i pacchetti subiscono il marking, in particolare vengono prima selezionati da un classificatore e successivamente marcati opportunamente scrivendo una sequenza di codice sempre all’interno dell’header, chiamata DS-byte ( si utilizza la porzione di campo riservata al ToS/CoS del pacchetto Ipv4/Ipv6) . Si tratta di 8 bit, di cui 6 costituiscono il cosiddetto DiffServ Code Point (DSCP), i restanti 2 bit ( i meno significativi) sono riservati. Il marking di un pacchetto quindi fa in modo di aggiungerlo ad un particolare flusso aggregato. Il marker può essere configurato per fare il
Meter
Unmetered traffic
Conformità a
marking di tutti i pacchetti che gli arrivano ad una stessa etichetta, o può essere configurato per fare marking di un pacchetto ad una o un insieme di etichette utilizzate per selezionare un aggregato in un gruppo, in accordo con lo stato del misuratore.
Quando il marker cambia un precedente DSCP presente in un pacchetto in uno nuovo si dice che esso ha subito un remarking.
2.3.5 Sheduler
Lo scheduler attua al suo interno vari algoritmi di scheduling, che descrivono il modo con cui i pacchetti, dopo essere stati classificati, ed opportunamente accodati, possono venire trattati, determinando in quale ordine ed in che momento i pacchetti che arrivano al suo ingresso sono inviati alla rete.
Tali algoritmi sono chiamati discipline di servizio. Sono inoltre inclusi, parametri che influiscono sull’operazione di uno scheduler: parametri statici come la priorità relativa associata ai vari canali di input, e parametri dinamici come il valore DSCP dei pacchetti presenti all’ingresso di uno scheduler. Sono possibili quindi diverse discipline di servizio, come: “first come, first served” (FCFS), “rated based” (RB) e “weighted fair bandwidth sharing” (WFBS).
2.3.6 Policing
Il Policing è il processo di eliminazione dei pacchetti (per mezzo di un dropper) appartenenti ad un determinato flusso di traffico, in funzione dello stato di un misuratore (meter). Esso è quindi costituito da un insieme di regole che devono essere rispettate per mantenere la proporzione voluta fra i volumi di traffico che devono occupare l’intera banda
il condizionamento del traffico. Per mantenere all’interno la semplicità della rete DS, è fortemente consigliabile effettuare l’operazione di policing solo negli ingress nodes.
2.3.7 Policy
Può succedere che i pacchetti che sono in eccesso ad un certo profilo di traffico possano subire diversi “trattamenti”. Con l’impostazione delle policy è possibile stabilire i limiti per i vari profili di traffico e le azioni da intraprendere, tra le seguenti:
• Scarto (dropping) • Remarking
• Trasmissione come Best Effort
Quando vengono intraprese azioni diverse dall’eliminazione dei pacchetti, come il reamarking dei pacchetti in eccesso, è consigliabile utilizzare un nuovo DSCP che ha un comportamento associato differente, magari meno privilegiato rispetto al precedente, solitamente inoltre si utilizza come nuovo comportamento quello standard che identifica il traffico di default, chiamato Best Effort. In questi casi, nasce un pericolo, cioè è possibile che venga “sovvertito” l’ordine con cui arrivano i pacchetti, questo infatti può mettere in crisi, il meccanismo di gestione della congestione. Infatti, alcuni pacchetti che andrebbero eliminati, nel caso in cui vengano rimarcati come Best Effort, possono subire dei ritardi troppo elevati dovuti ai diversi comportamenti di inoltro (PHBs) che subiscono, e rischiano quindi di arrivare anche con ritardi consistenti rispetto agli altri, introducendo meccanismi di ritrasmissione che non creano alcun beneficio. Per risolvere questo problema quindi è necessaria un’accurata gestione delle policy e un continuo monitoraggio della rete.
Le operazioni di policy solitamente sono svolte nei nodi di confine ed in particolare negli ingress nodes, per garantire un’equa ripartizione delle risorse disponibili tra i diversi domini che generano del traffico.
2.3.8 Shaper
Lo shaper ha il compito di ritardare qualcuno o tutti i pacchetti in un flusso di traffico, cercando di mantenere l’ordine all’interno dello stesso microflusso, in modo tale da mantenerlo con un profilo di traffico compatibile con il tipo di servizio che si vuole offrire. Uno shaper normalmente ha un buffer a lunghezza finita, ed i pacchetti possono essere limitati se in esso non c’è lo spazio sufficiente per mantenere tutti i pacchetti che devono essere ritardati. In ogni caso viene suggerito di evitare, per quanto sia possibile, l’eliminazione dei pacchetti, in quanto lo shaper serve per evitare che le policy successive eliminino i pacchetti poco distribuiti, che si presentano sotto forma di burst.
Essenzialmente ci sono tre tecniche per implementare il traffic shaping: • Leaky bucket
• Token bucket • Flow specification
2.3.9 Dropper
Il dropper elimina qualcuno o tutti i pacchetti in un flusso di traffico, senza però cambiare l’ordine di arrivo, per mantenere il flusso con un profilo di traffico compatibile. Da notare che un dropper può essere implementato come un caso particolare di uno shaker attraverso la regolazione della lunghezza del buffer dello shaper a zero o a pochi pacchetti.
Quando un pacchetto viene classificato all’interno di un router , viene differenziato rispetto agli altri in base all’etichetta, ovvero dal valore del campo DS. Questa, può essere vista come divisa in due parti, la prima parte viene utilizzata per scegliere la coda di appartenenza del pacchetto, la seconda per eseguire una differenziazione tra i pacchetti appartenenti alla stessa coda, nel caso si verifichi una congestione. Ognuna delle code presenti in un router è collegata ad una particolare classe di servizio e quindi ad un Per Hop Behaviours (PHB), e le proprietà di queste code, come ampiezza di banda o ritardo medio, dipendono dal meccanismo di scheduling adottato. Il PHB non è altro che una descrizione della regole di smistamento del traffico, assegnate a tutti i pacchetti aventi stesso valore DSCP. In particolare andremo a descrivere nel dettaglio tre differenti tipologie di PHB:
• Expedited Forwarding (EF) • Assured Forwarding (AF) • Best Effort (BE)
2.4.1 Expedited Forwarding (EF)
L’Expedited Forwarding PHB (EF) [RFC 2598], è un servizio che fornisce all’utente una percentuale minima garantita per l’utilizzo del collegamento. L’EF si presenta quindi come la forma di traffico “privilegiato”, a cui forniamo quindi minimo ritardo, bitter e minima perdita di pacchetti. Per poter garantire al traffico EF i requisiti minimi di basso delay e bassa delay varation, bisogna fare in modo che la permanenza all’interno della coda sia minima, pertanto il compito del manager della rete, deve essere quello di determinare un limite alla lunghezza delle code, fino al limite in cui si abbia perdita di pacchetti molto bassa. Infatti è preferibile perdere un pacchetto fra tanti, piuttosto che rallentarlo in una coda lunga.
E’ importante notare che la dimensione della coda dipende dal tipo di traffico EF che si intende trasportare, cioè dalla composizione dei microflussi che compongono l’aggregato EF, per cui è necessario monitorare i pacchetti trasmessi da questa classe di servizio, in maniera da mantenere mediamente la velocità dei pacchetti del flusso EF in arrivo, sempre minore di quella con cui vengono smaltiti.
2.4.2 Assured Forwarding (AF)
L’Assured Forwarding PHB (AF) è un servizio piuttosto complesso la cui specifica può essere osservata nell’RFC 2597[], in cui possiamo osservare che la classe delle azioni standard è stata ripartita nel seguente modo:
• 4 classi indipendenti
• ciascuna classe in tre livelli di precedenza
Questa specifica indica quattro classi di traffico, per ognuna delle quali è garantita una minima quantità di banda e di buffer; si tratta quindi di requisiti non stringenti come invece avevamo osservato nell’EF, ma comunque migliori rispetto al Best Effort.
Possiamo mostrare adesso una tabella che mette in relazione il DSCP della classe con il corrispettivo valore di precedenza di scarto.
DSCP Afij ( i="classe" ; j="prec(drop)" )
Precedenza di scarto classe 1 classe 2 classe 3 classe 4
bassa 001010 010010 011010 100010 media 001100 010100 011100 100100 alta 001110 010110 011110 100110
La suddivisione viene fatta chiamando ciascun comportamento con il simbolo Afij con 0<i<5 0<j<4; quindi il pedice i indica la classe e il pedice j il livello di precedenza.
Come detto, le quattro classi definibili sono indipendenti tra loro, quindi un flusso che viene assegnato ad una classe non può essere rimarcato su una classe diversa. Per rispettare le specifiche sul DSCP, una classe AFi è caratterizzata da comportamenti associati a caratteristiche di inoltro superiori rispetto ad una classe AFj quando i>j.
La precedenza di eliminazione, invece, è una caratteristica specifica di ogni classe, e può essere più alta o più bassa. Essa serve soprattutto per permettere all’interno di una stessa classe ed in caso di congestione, diversi comportamenti con caratteristiche di inoltro differenziate.
Normalmente, all’interno della classe AF, è consigliabile l’uso di due precedenze in caso di rare situazioni di congestione, e tre nel caso di forti e prolungate situazioni di blocco del corretto funzionamento della rete. All’interno di una stessa classe, la precedenza di eliminazione serve per stabilire parametri di accodamento e di scarto dei pacchetti differenziati.
2.4.3 Best Effort (BE)
Best Effort (BE) rappresenta il comportamento associato al traffico non “privilegiato”, cioè che non viene trattato per soddisfare requisiti particolari, ma a cui possiamo comunque associare una banda minima garantita con opportune policy, per garantirne l’inoltro. Quando all’ingresso di un edge router si presenta del traffico che non rispetta le condizioni imposte dai filtri (ossia nessun campo dell’ intestazione del pacchetto è configurato per la rete DS), viene automaticamente assegnato ad un profilo di traffico di tipo Best Effort.
