Modelli per il supporto della QoS nelle reti IP

Presentazione sul tema: "Modelli per il supporto della QoS nelle reti IP"— Transcript della presentazione:

1 Modelli per il supporto della QoS nelle reti IP
Alfio Lombardo (testo di riferimento: Tofoni)

2 Servizi di Rete Connectionless
trasferimento di piccole quantità di dati in tempi limitati robustezza e flessibilità dei path efficienza nell'uso delle risorse di rete necessità di controllo del traffico offerto dalla sorgente processamento durante il trasferimento dei dati

3 Target reti IP Impossibilità di ingegnerizzare il traffico
IP come unica piattaforma su cui far transitare: Voce Video Dati ……. Ma: Impossibilità di ingegnerizzare il traffico Impossibilità di supportare QoS Impossibilità di differenziare Servizi

4 TE: Ingegneria del Traffico
Costi per le risorse di rete Qualita’ del servizio + Massimizzazione dei ricavi Traffic Engineering is the process where data is routed through the network according to a management view of the availability of resources and the current and expected traffic. The class of service and quality of service required for the data can also be factored into this process. Traffic Engineering may be under the control of manual operators. They monitor the state of the network and route the traffic or provision additional resources to compensate for problems as they arise. Alternatively, Traffic Engineering may be driven by automated processes reacting to information fed back through routing protocols or other means. Traffic Engineering helps the network provider make the best use of available resources, spreading the load over the layer 2 links, and allowing some links to be reserved for certain classes of traffic or for particular customers. One of the main uses for MPLS will be to allow improved Traffic Engineering on the ISP backbone networks. Ingegneria del Traffico Dimensionamento delle Risorse Valutazione delle Prestazioni Gestione del Traffico

5 Senza controllo della Congestione Zona di “grave Congestione”
TE : obiettivi di Qualità del Servizio Con controllo della Congestione  Input Traffic > Output Capacity Throughput Congestione Traffico Offerto Senza controllo della Congestione Ritardo Fisso jitter 1 -   Ritardo max ritardo fT(rit.) Zona di “grave Congestione” Affidabilità Ritardo

6 Differenziazione dei Servizi
Esigenze diverse in termini di QoS Varie tipologie di traffico (trasferimento dati, real-time, …) Varie tipologie di utenti Differenziazione dei Servizi offerti Possibilità di servire un’utenza eterogenea Differenziazione dei costi

7 QoS nelle reti IP:SLA Parametro Limite Penale
Banda garantita d’accesso Valore Contrattuale 1% del valore per ogni scostamento in diminuzione di 1 punto percentuale Banda garantita end-to-end Disponibilità unitaria contrattuale 99,5% 0,2 % del valore per ogni scostamento in diminuzione di 0,1 punto percentuale Disponibilità complessiva 99,9% 0,8 % del valore per ogni scostamento in diminuzione di 0,1 punto percentuale Ritardo di trasferimento tra ogni coppia di accessi appartenenti allo stesso gruppo di accessi IP 50% dei pachetti entro100 ms 95% dei pachetti entro 150 ms 99,9 dei paccheti entro 500 ms 1% del valore complessivo per ogni diminuzione di 5 punti della perc. di pacchetti consegnati entro 100 ms …. Tasso di perdita < 0,1 % …..

8 Misure di affidabilità (perdita)
Cause di Perdita di pacchetti nella rete: Errori di trasmissione Eccessivo ritardo end-to-end Congestione Buffer 1 2 3 Tasso di perdita:

9 Variazione del ritardo
Misure di ritardo Distribuzione della densità di probabilità del ritardo ritardo medio deviazione standard Ritardo Fisso Variazione del ritardo 1-  Massimo ritardo

10 Meccanismi di QoS nelle reti IP
Classificazione Controllo del traffico d’utente (metering, marking, shaping, dropping) Scheduling Queue Management (controllo della congestione) Il classificatore seleziona i flussi di traffico secondo certe regole, dopodiché ciascun pacchetto viene inviato al controllore di traffico. Un controllore (o condizionatore) di traffico può contenere i seguenti elementi: meter, marker, shaper, dropper. Di seguito si parla in dettaglio dei quattro possibili elementi di un condizionatore di traffico. Si tenga presente che quest’ultimo non deve necessariamente contenerli tutti. Meter Il meter viene utilizzato, laddove è necessario, per misurare le proprietà temporali di un flusso di pacchetti selezionato dal classificatore e per confrontarle con quelle indicate nel profilo di traffico [1] del flusso a cui appartiene il pacchetto. Il meter è così in grado di stabilire se i pacchetti del flusso in questione sono “in-profile” o “out-of-profile”, ed è suo ulteriore compito quello di comunicare quest’informazione di stato ai blocchi che implementano le funzionalità di condizionamento del traffico (vale a dire lo shaper/dropper ed il marker), in modo che essi eseguano opportune azioni sui pacchetti. Un esempio di meter è quello che si basa sull’uso di un token bucket (vedi dopo). Si noti che, se non viene adottato alcun profilo di traffico, la presenza del meter non è richiesta. Marker Il marker, dove utilizzato, ha il compito di assegnare, in base alle informazioni di stato provenienti dal meter, il valore del codepoint di un pacchetto A seconda dei casi, un marker può agire in uno dei seguenti modi: può fissare il valore del codepoint di un pacchetto non ancora marcato; può modificare il valore del codepoint originario di un pacchetto già marcato; in questo caso si dice che esso effettua un’operazione di “re-marking”. Shaper Lo shaper ritarda alcuni o tutti i pacchetti di un flusso di traffico, al fine di riportare il flusso stesso entro i limiti imposti dal profilo di traffico; in altri termini esso agisce con lo scopo di trasformare i pacchetti “out-of-profile” in pacchetti “in-profile”. L’operazione eseguita da uno shaper viene indicata col nome di “shaping”. Uno shaper è solitamente realizzato mediante un buffer di lunghezza finita; di conseguenza i pacchetti ad esso inviati possono anche essere scartati se non c’è spazio sufficiente per contenerli. Dropper Il dropper scarta alcuni o tutti i pacchetti di un flusso di traffico, al fine di far rientrare il flusso nei limiti imposti dal profilo. Quest’operazione è nota con il nome di “policing”. Si può facilmente notare che un dropper può essere implementato come un tipo particolare di shaper; per far ciò basta fissare la dimensione del buffer a zero o ad un numero di byte molto piccolo. [1] Un profilo di traffico descrive le proprietà temporali di un flusso di traffico, come ad esempio il rate di arrivo dei pacchetti e la “burst size”, cioè la massima dimensione consentita per un burst di pacchetti

11 Meccanismi di QoS nelle reti IP
Classificazione (es. class. BA) Traffico Classificazione (es. class. MF) Queue Man.+ Scheduling Controllo Traffico

12 Classificazione Il traffico in ingresso ad una rete può essere cjassific: A livello di singola sessione d’utente (micro-flusso) - A livello di aggregato di micro-flussi aventi le stesse Caratteristiche (flusso) Ai fini della classificazione viene utilizzata una porzione dell’intestazione del pacchetto IP e/o del segmento TCP/UDP; ad esempio: - classificazione in base ad una parte del campo TOS - classificazione in base a Indirizzo IP sorgente e destinazione, indirizzo di porta sorgente e destinazione tipo di protocollo trasportato I classificatori selezionano i pacchetti appartenenti ad un flusso di traffico basandosi sul contenuto di alcune porzioni dell’header degli stessi, dopo aver verificato l’autenticità delle informazioni ivi contenute. Si distinguono due tipi di classificatori: Classificatori BA (Behavior Aggregate), che classificano i pacchetti solamente in base al valore del TOS o del DS codepoint (in ambiente DiffServ). Si tratta dei classificatori normalmente presenti nei nodi interni DS per stabilire a quale BA è associato ciascun pacchetto. Classificatori MF (Multi-Field), che selezionano i pacchetti in base al valore della combinazione di uno o più campi dell’header, vale a dire il source address, il destination address, il DS Field, il protocol ID, la source port, la destination port ed eventuali altre informazioni, come ad esempio l’interfaccia da cui proviene il pacchetto. I classificatori MF sono quelli usati di norma nei punti di accesso della rete per scegliere a quale BA associare ciascun pacchetto. L’obiettivo finale di un classificatore è condurre i pacchetti, secondo certe regole, verso un particolare elemento di un condizionatore di traffico, che eventualmente li processerà ulteriormente.

13 Controllo del traffico d’utente (metering+marking): Token Bucket (Leaky Bucket)
Token rate: r Ampiezza del Bucket: b Gettoni r b Bucket Un profilo di traffico descrive le proprietà temporali di un flusso di traffico, come ad esempio il rate di arrivo dei pacchetti e la “burst size”, cioè la massima dimensione consentita per un burst di pacchetti. Fissato un profilo di traffico, effettuando delle opportune misure è possibile stabilire se un pacchetto soddisfa i requisiti imposti da quel profilo oppure no. Nel primo caso il pacchetto si dirà “in-profile”, mentre nel secondo esso sarà considerato “out-of-profile”[1]. Un modo semplice per controllare se un pacchetto ricade nella prima o nella seconda categoria è quello di usare un token bucket. Token bucket Un token bucket si realizza mediante un buffer (eventualmente virtuale, ovvero un contatore) di dimensione pari a b byte, cioè alla burst size, ed un meccanismo che genera dei token (vale a dire, letteralmente, dei “gettoni”) al ritmo di 1 ogni ΔT secondi. Ogni token rappresenta il diritto di spedire k byte. Normalmente, anziché specificare l’intervallo temporale ΔT che intercorre tra la generazione di un token di k byte ed il successivo, ci si riferisce al rate r di arrivo dei token. Affinché un pacchetto possa essere trasmesso, esso deve prima catturare e distruggere un numero di token sufficiente a coprirne interamente la lunghezza in byte. Se il numero di token risulta insufficiente, allora il pacchetto dovrà rimanere in attesa che vengano generati ulteriori token. I token frazionati vengono conservati per usi futuri. Per implementare un token bucket è sufficiente una variabile che conti i gettoni. Il contatore viene incrementato di k byte ogni ΔT secondi e decrementato della lunghezza totale dei pacchetti spediti; istante per istante, il valore del contatore moltiplicato per k indica il numero massimo di byte cui può essere consentita la spedizione. Si osservi che il token bucket può scartare i token quando il contatore raggiunge il valore massimo consentito, legato alla capacità del link d’uscita. Viceversa, esso non scarta mai i pacchetti. I parametri b ed r, che specificano completamente il funzionamento del token bucket, vanno settati in modo opportuno. Si noti che, supponendo che in ingresso al token bucket si abbia una sorgente “greedy”, cioè che abbia continuamente pacchetti da trasmettere, in qualsiasi intervallo di tempo arbitrario T il numero massimo di byte che possono essere spediti è: b+rT. La figura mostra lo schema di principio di un token bucket. Il regolatore ha il compito di decidere se consentire al primo pacchetto della coda di passare. Un profilo di traffico basato su un token bucket può essere realizzato usando, per i pacchetti marcati con un generico codepoint X, un token bucket con parametri r, b. Tale profilo indica che tutti i pacchetti marcati con il codepoint X devono essere inviati con rate di generazione pari ad r byte al secondo e burst size b. In tal caso si considerano “in-profile” quei pacchetti del flusso di traffico che arrivano quando il numero dei token disponibili è sufficiente a far sì che essi acquisiscano il diritto di essere trasmessi; tutti gli altri sono “out-of-profile”. [1] I concetti di “in-” e “out-of-profile” possono essere estesi a più di due livelli di conformità ad un certo profilo; ad esempio nel seguito si analizza il caso in cui vengono usati tre livelli indicati con i colori rosso, giallo e verde. Crediti Sufficienti ? Nuovi Pacchetti Si: Pacchetto Conforme NO: Pacchetto non conforme b+rT= numero massimo di byte che possono essere spediti in un tempo T

14 Controllo del traffico d’utente: Single Rate TCM
Si: Verde Tc  Tc - L L  Te ? L  Tc ? CBS L byte EBS No: Rosso CIR tokens/s Tc Te No Si: Giallo Te  Te - L trabocco C E Un Three Color Marker (TCM) può essere utilizzato come componente di un condizionatore di traffico situato in un nodo DS. Il TCM misura un flusso di traffico e marca i pacchetti, seguendo certe regole, con i colori verde, giallo o rosso. Sono stati finora standardizzati tre tipi di TCM: srTCM (single rate TCM); trTCM (Two Rate TCM); tswTCM (Time Sliding Window TCM). La differenza tra le tre versioni del TCM sta nel modo in cui vengono effettuate le misure e nel modo in cui viene scelto il colore da attribuire ai pacchetti. Nel Single Rate Three Color Marker (srTCM) ([RFC2697]) la scelta del colore con cui eseguire il marking si basa sul valore di tre parametri di traffico, vale a dire: Committed Information Rate (CIR): rate massimo per il quale si garantisce con elevata probabilità la consegna dei pacchetti; si misura in ed include i byte dell’header IP ma non quelli dell’header di livello 2. Committed Burst Size (CBS): massima dimensione che deve occupare un burst di pacchetti per avere la garanzia di consegna con elevata probabilità; si misura in . Excess Burst Size (EBS): massima dimensione in eccesso che può avere un burst di pacchetti perché si possa tentare di offrirgli risorse disponibili (se ce ne sono) e non si proceda direttamente allo scarto; si misura in . Un pacchetto viene marcato con il colore verde se non eccede il CBS, con il giallo se eccede il CBS ma non l’EBS, con il rosso altrimenti. Il srTCM è utile, ad esempio, per eseguire il policing di un servizio all’ingresso di un dominio DS, laddove sia la lunghezza di un burst, e non il peak rate, a determinare l’idoneità dei pacchetti a ricevere un dato servizio. Il Meter del srTCM utilizza due token bucket, che verranno indicati con le lettere C ed E. Entrambi i token bucket sono caratterizzati dallo stesso valore del rate di generazione dei token, che viene posto pari al CIR. La dimensione massima del token bucket C viene fissata pari a CBS, mentre quella di E viene posta pari ad EBS. Per indicare i contatori dei token, si userà la seguente notazione: Tc(t) = numero di token presenti nel token bucket C all’istante t; Te(t) = numero di token presenti nel token bucket E all’istante t. Ciascun token rappresenta il diritto a trasmettere 1 byte. I token bucket C ed E sono inizialmente (all’istante 0) pieni.’, ovvero Tc(t) =CBS; Te(t) = EBS. In pratica Tc viene incrementato di 1 byte CIR volte al secondo fino a quando non raggiunge il suo valore massimo (CBS). A quel punto Tc rimane invariato mentre Te viene incrementato fino al raggiungimento del suo valore massimo (EBS). Se entrambi i contatori hanno raggiunto il loro valore massimo non viene compiuta nessun’altra operazione fino a quando il valore di almeno uno dei due contatori non si abbasserà. L’srTCM può essere usato per marcare un flusso di pacchetti che devono ricevere un certo servizio, assegnando differenti livelli di garanzia (sia assoluta che relativa) ai pacchetti verdi, gialli e rossi. Per esempio, un servizio può: scartare tutti i pacchetti rossi, poiché essi eccedono sia la Committed Burst Size che la Excess Burst Size; istradare i pacchetti gialli fornendo ad essi un servizio best-effort; istradare i pacchetti verdi con una bassa probabilità di scarto.

15 Two Rate TCM Peak Information Rate (PIR): rate di picco massimo consentito; Committed Information Rate (CIR): rate massimo per il quale si garantisce la consegna dei pacchetti con alta probabilità; Peak Burst Size (PBS): massima dimensione che può avere un burst di pacchett perché si tenti di offrirgli risorse disponibili e non si proceda allo scarto; Committed Burst Size (CBS): massima dimensione che può avere un burst di acchetti per avere la garanzia di consegna a destinazione con elevata probabilità; si misurano in ed include l’header IP ma non l’header di livello 2.

16 Two Rate TCM: rule 1

17 Two Rate TCM: rule 2

18 Scheduling . ……. FIFO (FCFS) Priority Queueing WFQ 1 2 N Code Flusso 1
scheduler Flusso 1 Flusso N Flusso 2 C l a s i f c. . Code ……. FIFO (FCFS) Priority Queueing WFQ

19 FIFO No QoS management (best effort) . N 2 2 1 1 1 N 2 2 1 1 1
Flusso 1 Flusso 2 C l a s i f c. . N 2 2 1 1 1 scheduler N 2 2 1 1 1 Flusso N No QoS management (best effort)

20 PQ Queue Starvation . ……. 1 1 1 1 2 2 2 2 2 2 N 1 1 1 1 Code Flusso 1
scheduler 2 2 2 1 1 1 1 ……. N Flusso N Code Queue Starvation

21 WFQ weight: 0,5 0,2 0,3 Equivale a: . ……. 1 1 1 1 2 2 2 N 2 N 2 1 1 1
Flusso 1 0,2 Flusso 2 C l a s i f c. 0,3 1 1 1 1 . 2 2 2 scheduler 2 N 2 1 1 1 ……. N Flusso N Equivale a: C = 300 Kbit/s C = 200 Kbit/s C = 500 Kbit/s

22 Controllo della congestione
Drop tail RED WRED

23 Drop Tail soglia Pacchetti in arrivo Coda FCFS Scarto

24 RED: Drop with Drop all prob P No drop 1 Probabilità di Scarto THmin
THmin THmax Occupazione del buffer (stima)

25 Stima dell’occupazione
RED Stima dell’occupazione del buffer THmax THmin Decisione Pacchetti in arrivo Coda FCFS Scarto Regione di possibile scarto

26 WRED 1 Probabilità di Scarto Profilo di servizio Standard Premium
Lunghezza media della Coda

27 Modelli emergenti di QoS
Integrated Services Differentiated Services Tecniche conformi ai modelli MPLS

28 “Servizio” DEFINIZIONE: Un “servizio” definisce le caratteristiche significative della trasmissione di un pacchetto in una certa direzione attraverso l’insieme di uno o più percorsi interni di una rete. 2 Modi per esprimere tali caratteristiche: In termini assoluti Thoughtput, Ritardo, Jitter, Perdite In termini relativi Classi di traffico, Priorità relativa di accesso alle risorse Un “servizio” definisce alcune caratteristiche significative della trasmissione dei pacchetti in una certa direzione attraverso l’insieme di uno o più percorsi interni di una rete. Tali caratteristiche possono essere espresse in termini di requisiti quantitativi o statistici sulla performance (riguardanti, ad esempio, il throughput, il ritardo, il jitter e/o le perdite), oppure possono essere specificate in termini di priorità relativa di accesso alle risorse di rete, e quindi in termini di performance relativa (ad esempio attraverso la differenziazione del traffico in classi). La differenziazione dei servizi offerti in Internet deve essere in grado di soddisfare i requisiti richiesti da applicazioni eterogenee e da varie tipologie di utenti, assicurando altresì una conseguente differenziazione dei costi. La costruzione dei servizi differenziati può essere realizzata eseguendo insieme le seguenti operazioni: applicando ai pacchetti IP in transito, nei nodi di confine della rete, un opportuno marchio (indicativo del tipo di servizio che ciascuno di essi riceverà); utilizzando tale marchio per determinare il modo in cui i pacchetti dovranno essere trattati dai nodi interni della rete; eventualmente condizionando, ai confini della rete, i pacchetti marcati in accordo con le regole stabilite per ciascun servizio; tali regole vengono fissate attraverso una precisa politica amministrativa.

29 Integrated Services: RSVP
Messaggi PATH (Tspec) Messaggi RESV (Flow spec e Filter spec) Ricevitori I messaggi RSVP sono 7: PATH (downstream) RESV (upstream) PATH ERR (upstream) RESV ERR (downstream) PATH TEAR (downstream) RESV TEAR (upstream) RESV CONF (downstream) The RSVP Tspec object carried on Path messages describes the data that will flow (rather than the QoS that is required from the connection). I messaggi di prenotazione RESV viaggiano dal ricevitore verso la sorgente. Essi indicano le caratteristiche di banda del canale che si intende prenotare ed hanno la funzione di instaurare e mantenere, nei router interessati, uno stato di prenotazione (Reservation State) e di impegnare lungo il percorso le risorse prenotate. Se la prenotazione non è periodicamente aggiornata dai messaggi di RESV, questa è automaticamente abbattuta senza la necessità di un’esplicita comunicazione. I messaggi di RESV seguono la stessa strada, ma nella direzione opposta, che i pacchetti dati dovranno percorrere dalla sorgente alla destinazione. Ogni router del percorso deve perciò conoscere le informazioni sul giusto instradamento: queste informazioni sono comunicate ai routers tramite i messaggi di PATH. I messaggi di PATH che viaggiano lungo il percorso downstream dalla sorgente alla destinazione (il ricevitore) servono anche per definire il percorso seguito dai pacchetti dati e dai messaggi RESV. Essi creano nei routers del percorso uno stato locale denominato Path State. I messaggi PATH TEAR e RESV TEAR servono invece per abbattere esplicitamente la sessione da parte di ambedue i contraenti. Anche i routers intermedi li possono usare quando non ricevono i messaggi di PATH o di RESV allo scadere di un certo intervallo di tempo. Questo tipo di messaggi viaggia lungo il percorso hop–by–hop per cancellare i relativi stati di prenotazione. Anche se le sessioni sono abbattute automaticamente se non aggiornate, i messaggi PATH TEAR e RESV TEAR sono molto utili per eliminare inutili tempi di latenza. RSVP normalmente viene incapsulato direttamente in un pacchetto IP (sia IPv4 che IPv6) con protocol number 46 ma può operare anche su UDP. Trasmettitore

30 Filterspec Pacchetti che passano il Filtro Scheduler
(IP sorg.;Porta sorg.) Trattamento QoS Flowspec Filterspec Trattamento Best-effort Pacchetti di una Sessione (IP dest.;Porta dest.; Prot. ID) La figura nella slide illustra la sorte subita da un flusso di pacchetti in un router RSVP e introduce alcuni concetti chiave di RSVP. Un concetto importante è quello di Sessione. Una Sessione definisce la destinazione di un flusso di dati ed è identificata dalla tripletta: <indirizzo IP dest.; porta TCP o UDP dest.; identificativo di protocollo> Una richiesta di prenotazione RSVP consiste di due parametri detti Flow spec e Filter spec: questa coppia è chiamata Flow descriptor. Il Flow spec specifica la QoS desiderata: viene utilizzato per definire una classe di flussi nello scheduler e allocare i relativi buffer. In generale un Flow spec contiene i seguenti elementi: Classe di Servizio: è un identificatore del tipo di servizio richiesto; RSpec: definisce l’ammontare della banda da prenotare; TSpec: definisce il profilo di traffico della sessione. Il Filter spec specifica un arbitrario sottoinsieme dei pacchetti di una sessione. In altre parole, un Filter spec definisce il sottoinsieme di pacchetti per i quali è stata prenotata la banda. Ad esempio, un Filter spec potrebbe specificare solo determinate sorgenti, o determinati protocolli sorgente, o in generale pacchetti che hanno lo stesso determinato campo contenuto nelle intestazioni protocollari. L’attuale versione di RSVP utilizza un Filter spec che contiene l’indirizzo IP e la porta UDP o TCP del trasmettitore. In un router, i pacchetti di una sessione vengono dapprima “filtrati” attraverso il Filter spec (ovvero vengono suddivisi asseconda che siano conformi a quanto definito nel parametro Filter Spec o meno). I pacchetti che superano il filtro sono quelli per cui è stata riservata una determinata banda attraverso i componenti del Flow spec e quindi sono quelli per cui viene garantito dallo scheduler (o dagli altri meccanismi preposti allo scopo ,vedi prima) un determinato livello di QoS. I pacchetti che non superano il filtro vengono trattati come “best effort”. Il principale limite del modello IntServ e’ l’impossibilità di scalare il modello su reti di grandi dimensioni: IntServ infatti necessita il mantenimento del PathState e Reservation State in ciascun router per ciascuna sessione; questo necessita di molta segnalazione in rete e di molta memoria sui router. Per tale ragione il modello trova utilizzo solo nelle reti di accesso. Altri pacchetti Flow spec specifica la QoS desiderata: viene utilizzato per definire una classe di flussi nello scheduler e allocare i relativi buffer. In generale un Flow spec contiene i seguenti elementi: Classe di Servizio: è un identificatore del tipo di servizio richiesto; RSpec: definisce l’ammontare della banda da prenotare; TSpec: definisce il profilo di traffico della sessione. Il Filter spec specifica un arbitrario sottoinsieme dei pacchetti di una sessione.

31 RSVP protocol stack RSVP viene incapsulato direttamente in un pacchetto IP con protocol number 46 ma può operare anche su UDP RSVP UDP IP (v4/v6)

32 DiffServ Working Group [RFC2575]
Gruppo di lavoro dell’IETF Obiettivo: migliorare IP prevedendo la differenziazione in classi di servizio del traffico Risultato: Differentiated Services (o DiffServ) L’architettura del Diffserv, definita in [RFC2575], è basata su un modello semplice in cui il traffico entrante in una rete è classificato (ed eventualmente condizionato) ai confini della rete stessa. Scopo di tale classificazione è assegnare ogni pacchetto entrante nella rete ad un determinato DS behavior aggregate (BA), cioè ad una collezione di pacchetti, anche appartenenti a flussi differenti, identificati dallo stesso valore del DS codepoint. Nei nodi interni della rete, invece, i pacchetti vengono trattati in accordo con il Per-Hop Behavior (PHB) associato al BA cui essi sono stati assegnati. A ciascun BA è associato uno specifico PHB, per cui a tutti i pacchetti di un dato BA è riservato lo stesso PHB. Punti di forza semplicità scalabilità

33 Passi da seguire per realizzare la Differenziazione dei Servizi
Confini della rete: i pacchetti ricevono un marchio (identifica il tipo di servizio che riceveranno) Confini della rete: condizionamento del traffico (in accordo con le regole stabilite per ciascun servizio) Nodi interni: marchio -> “forwarding behavior” Il marchio impresso sui pacchetti viene codificato attraverso il valore dei bit di un’opportuna porzione dell’header IP, della quale si parlerà più approfonditamente tra breve. Un nodo che supporti il DiffServ, sia esso situato all’interno che ai confini della rete, deve essere sicuramente dotato di un classificatore, che distingue i pacchetti in base al marchio che essi possiedono, ed inoltre deve includere meccanismi di scheduling e di gestione del buffer in grado di offrire ai pacchetti lo specifico “forwanding behavior” (= trattamento di spedizione) associato al valore del marchio che viene letto dal classificatore. In altri termini, le decisioni sulle regole di forwarding di un pacchetto vengono prese, ad ogni nodo di rete che esso incontra lungo il suo cammino, semplicemente traducendo il valore del marchio che gli è stato apposto nel corrispondente “forwarding behavior”, vale a dire riservando al pacchetto un trattamento differenziato mediante l’uso dei particolari meccanismi di scheduling e gestione delle code di cui è dotato. L’attribuzione dell’opportuno valore al marchio che deve accompagnare i pacchetti ed il condizionamento del comportamento temporale dei pacchetti marcati non devono essere effettuati in tutti i nodi, ma sono necessari solo ai confini della rete.

34 Funzioni dei Router ai confini della rete
Meter Shaper/ Dropper/ Ricolorazione Classificatore MF Marker Le operazioni di classificazione e condizionamento del traffico sono certamente fondamentali nel modello DiffServ. La politica di classificazione (insieme di regole per la definizione di filtri) permette di identificare l’aggregato di traffico che riceverà un servizio particolare attraverso l’utilizzo di uno specifico PHB nel dominio. La politica di condizionamento, tramite il metering, lo shaping, il policing (shaping/dropping), assicura che il traffico entrante nel dominio DS sia conforme alle regole specificate negli accordi fra ISP e Clienti. La tipologia e la complessità di queste operazioni è legata all'offerta del servizio. Il meter ha il compito di misurare le caratteristiche temporali del traffico presentato, per distinguere il traffico conforme (in-profile) da quello non conforme (out-of-profile). La discriminazione fra traffico conforme e non conforme permette ai moduli seguenti di realizzare le operazioni più opportune. Sono possibili diverse realizzazioni di meter in base al descrittore del traffico scelto. L’orientamento attuale è quello di privilegiare implementazioni dei meter che siano basate su un l’algoritmo di tipo token-bucket. Il marker ha il compito di impostare i bit del DSCP in modo che il pacchetto venga ad essere associato ad un particolare aggregato. Quando il marker cambia il codice di un pacchetto è più corretto parlare di re-marking del pacchetto. Le ragioni che spingono ad utilizzare il marker sono essenzialmente due: si realizza una forma di policing del traffico non conforme che può essere rimarcato per assegnargli un PHB dai requisiti meno stringenti; si fornisce un servizio a valore aggiunto al Cliente, che può non essere in grado, o non è interessato ad effettuare il marking sui pacchetti che invia alla rete; in questo caso è necessario avere un classificatore MF per distinguere i Clienti e i loro microflussi. Lo shaper ritarda l’inoltro dei pacchetti per portarli in una condizione di conformità nei confronti del relativo profilo di traffico. Il dropper scarta alcuni o tutti i pacchetti di un aggregato per portarlo in condizioni di conformità al relativo profilo. Da un punto di vista logico un dropper è uno shaper con un buffer di dimensione nulla; è chiaro che questa è la forma più semplice di policing che possa essere implementata.

35 Funzioni dei Router Interni
PHB 1 Classificatore BA PHB 2 PHB n

36 Scalabilità Le funzioni di classificazione complesse (per l’attribuzione del valore al marchio) ed il condizionamento devono essere effettuati solo ai confini della rete. Non è necessario mantenere ad ogni nodo il “per-flow state” o il “per-customer state”. Non è richiesta un’apposita segnalazione ad ogni “hop”. L’architettura del DiffServ realizza la scalabilità proprio implementando le funzioni di classificazione complesse ed il condizionamento solamente ai nodi di confine della rete, mentre i nodi interni si limitano semplicemente a riservare a ciascun pacchetto, marcato dai nodi di confine, un opportuno forwarding behavior. Inoltre, la scalabilità è garantita dal fatto che non c’è la necessità di mantenere nei nodi interni della rete il “per-flow state” o il “per-customer state” (vale a dire lo stato di ogni flusso in transito attraverso il nodo o di ogni utente della rete), così come non è necessario effettuare un’apposita segnalazione ad ogni “hop”. L’approccio DiffServ punta a sveltire le operazioni richieste per realizzare la differenziazione dei servizi, suddividendo in pratica l’architettura in due principali componenti, tra loro distinte. La prima componente è quella più semplice, perché è quella che si occupa della spedizione dei pacchetti, che deve essere eseguita il più velocemente possibile e solamente in base alle informazioni presenti nel singolo pacchetto ed al valore di certi parametri opportunamente configurati. La seconda componente, più complessa, ha il compito, invece, di configurare i parametri utilizzati nell’istradamento dei pacchetti, cioè quelli usati dalla prima.

37 Nuova Terminologia DS codepoint (DSCP): valore assunto dalla porzione dell’header IP utilizzata per marcare i pacchetti DS behavior aggregate (BA): collezione di pacchetti, marcati con lo stesso DSCP, che attraversano un link in una particolare direzione Per-Hop Behavior (PHB): “forwanding behavior” esternamente osservabile che un nodo DS riserva a tutti i pacchetti di uno stesso BA Al fine di descrivere il funzionamento del DiffServ, il DiffServ WG ha coniato una nuova terminologia; è utile anticipare subito alcune definizioni: DS codepoint (DSCP): è il valore assunto dalla porzione dell’header IP utilizzata per marcare i pacchetti, in modo che essi ricevano un certo “forwarding behavior”. DS sta, ovviamente, per Differentiated Services. Il DSCP, in pratica, non è altro che il marchio di cui si è parlato. DS behavior aggregate (BA): collezione di pacchetti, marcati con lo stesso DS codepoint, che attraversano un link in una particolare direzione. Per-Hop Behavior (PHB): “forwanding behavior” esternamente osservabile che viene applicato da un nodo di rete (che supporta il DiffServ) a tutti i pacchetti di uno stesso BA. Il PHB definisce solamente il comportamento di un singolo nodo. Invece, la specifica del comportamento di una collezione di nodi viene fornita dal Per-Domain Behavior (PDB), di cui si parlerà più avanti (nel paragrafo 2.5). Sono stati definiti vari PHB allo scopo di fornire ai nodi di rete degli strumenti in base ai quali allocare le risorse disponibili (in termini di banda e spazio nel buffer), suddividendole secondo certi criteri tra i vari flussi di traffico che competono tra loro per aggiudicarsele.

38 Definizione del DS CodePoint Field
Type Of Service Il DiffServ ha lo scopo di fornire un’architettura e dei blocchi costitutivi che consentano la differenziazione scalabile dei servizi in Internet. La realizzazione dei servizi differenziati richiede anzitutto la definizione di un campo di 6 bit dell’header del pacchetto IP, che viene indicato col nome di Differentiated Services Field (o DS Field); tale definizione viene fornita in [RFC2474]. Nell’architettura DiffServ, il DS Field trova collocazione nell’ottetto Type Of Service (TOS) dell’header IPv4 o nell’ottetto Traffic Class dell’header IPv6. Header del pacchetto IPv4

39 Definizione del DS Field
Da ignorare DS codepoint = marchio, valore codificato nel DS Field In realtà, come viene chiarito in [RFC3260], il DS Field occupa solo i 6 bit più significativi di tali ottetti, mentre i successivi 2 bit non sono stati assegnati al DiffServ, ma sono riservati per l’Explicit Congestion Notification (ECN), cioè per la “notifica esplicita della congestione” . Il DS codepoint (o DSCP) è un valore di 6 bit che viene codificato nel DS Field e che viene usato da ogni nodo compatibile con il DiffServ per scegliere lo specifico PHB da riservare a ciascun pacchetto. Il campo ECN, invece, non avrà alcun peso sulle decisioni (relative alla spedizione dei pacchetti) prese dal nodo, che, pertanto, ne ignorerà il contenuto. Per indicare il valore del DSCP si utilizzerà la seguente notazione: 'xxxxxx' (dove 'x' può essere uguale a '0' o '1'). I nodi che supportano il DiffServ devono eseguire il mapping dei DS codepoint nei PHB, utilizzando ciascun valore del DSCP come l’indice di una tabella da cui verrà selezionato un certo PHB, e quindi da cui verrà scelto un particolare meccanismo di manipolazione dei pacchetti implementato nel dispositivo. Tranne alcune eccezioni, tale mapping deve essere configurabile. La specifica dei PHB deve includere necessariamente un DS codepoint di default raccomandato, che si trova nello spazio dei DS codepoint standard e che deve essere univoco. Inoltre, le varie implementazioni devono includere i mapping raccomandati dai DS codepoint standard ai relativi PHB nella loro configurazione di default. Gli operatori possono scegliere di utilizzare dei DS codepoint diversi per un certo PHB, in aggiunta o in sostituzione di quelli raccomandati. I pacchetti che giungono ad un nodo interno con un DS codepoint non riconosciuto (nel senso che non può essere mappato in nessuno specifico PHB) devono ricevere un trattamento pari a quello che riceverebbero se fossero marcati per il PHB di default, e il loro codepoint non deve essere modificato. Alla IANA (Internet Assigned Numbers Authority) è richiesto di mantenere un registro dei DSCP raccomandati, cioè di quelli assegnati attraverso azioni di standardizzazione Struttura dell’ottetto IPv4 Type Of Service o IPv6 Traffic Class nel DiffServ

40 ECN ECN=11 feedback

41 Per-Hop-Behaviour (PHB)
E’ la strategia di “forwarding” applicata ad un aggregato di traffico Specifica le modalità di allocazione/gestione delle risorse agli aggregati di traffico Banda da allocare (via scheduling) Priorità di scarto (via “queue management”) “Gruppo di PHB”: insieme di PHBs caratterizzati dallo stesso insieme di vincoli (es. stessa politica di “queue management”, di scheduling, ecc.). Le relazioni tra i PHB di uno stesso gruppo possono essere espresse in termini di priorità relativa o assoluta Un Per-Hop Behavior (PHB) è la descrizione del “forwarding behavior” che un nodo DS riserva ai pacchetti appartenenti ad un particolare “behavior aggregate”. Nel caso in cui un link sia attraversato dai pacchetti di un solo BA, il trattamento d’istradamento sperimentato dagli stessi dipenderà solo dal carico che viene immesso sul link. Sicuramente più interessante è, invece, il caso in cui più BA competono per aggiudicarsi le risorse (banda e spazio nel buffer) messe a disposizione dal nodo. In questo caso i PHB diventano il mezzo mediante il quale ogni nodo alloca le risorse ai vari BA, ed è proprio sulla base di questo meccanismo di allocazione delle risorse “hop-by-hop” che è possibile costruire in modo efficiente un’architettura che fornisca servizi differenziati. Il PHB relativo ad un certo BA può essere espresso in due modi: in termini di priorità di accesso alle risorse (es: buffer, banda) rispetto agli altri BA; in termini di caratteristiche di traffico osservabili e misurabili (es: ritardo, perdita). Un PHB può essere specificato individualmente oppure come parte di un gruppo. Un gruppo di PHB, o PHB group, solitamente è costituito da uno o più PHB differenti, che, però, possono essere implementati simultaneamente, in virtù del fatto che ad ogni PHB del gruppo viene applicato un vincolo in comune, come ad esempio la stessa politica di scheduling o la stessa politica di gestione della coda. Un PHB group fornisce un blocco costruttivo di servizio, che consente, ad un insieme di “forwarding behavior” tra loro correlati, di poter essere specificati insieme. Le relazioni tra i PHB di uno stesso gruppo possono essere espresse in termini di priorità relativa o assoluta (ad esempio, di scarto), ma questo non è rigorosamente richiesto, nel senso che ai PHB di un PHB group possono essere garantite le stesse porzioni di link. Un PHB singolo, definito in modo isolato, è un caso particolare di un PHB group. Un nodo DS riesce ad implementare un particolare PHB adottando opportuni meccanismi di gestione del buffer e di scheduling dei pacchetti. La definizione di un PHB contiene, però, solo la descrizione degli aspetti più importanti della politica di approvvigionamento del servizio, senza entrare nel merito sulla loro implementazione. In generale un PHB può essere implementato in molti modi, utilizzando algoritmi e meccanismi di tipo diverso. Ciascun nodo, in genere, è in grado di implementare più di un PHB group. Ogni PHB group deve essere implementato in modo tale che possa essere effettuata opportunamente l’allocazione e la suddivisione delle risorse tra i pacchetti dei vari gruppi. Inoltre, è auspicabile che si realizzino dei meccanismi integrati adatti a supportare simultaneamente due o più gruppi di PHB. L’implementazione dei PHB group nei nodi di un dominio DS deve condurre ad una opportuna suddivisione, tra i vari BA, delle risorse disponibili su quei nodi e sui link che li collegano, in accordo con la politica di approvvigionamento del servizio utilizzata in quel dominio. I condizionatori di traffico possono altresì controllare l’uso di queste risorse per forzare il TCA, ricevendo eventualmente un feedback dai nodi e dagli altri condizionatori di traffico del dominio. L'interazione tra i condizionatori di traffico e i nodi interni del dominio può richiedere l’uso di specifiche entità di controllo e di specifici protocolli, che devono essere scelti in modo da garantire la scalabilità.

42 Tabella di mapping di un nodo DS (DSCP: indice tabella)
Mapping DSCP -> PHB DSCP PHB Tipo PHB DSCP di default PHB di default Standard DSCP 1 PHB A DSCP 2 PHB B DSCP 3 PHB C DSCP 4 PHB D Locale DSCP 5 PHB E DSCP 6 PHB F … Tabella di mapping di un nodo DS (DSCP: indice tabella)

43 Al nodo giunge un pacchetto con DSCP 3
Mapping DSCP -> PHB DSCP PHB Tipo PHB DSCP di default PHB di default Standard DSCP 1 PHB A DSCP 2 PHB B DSCP 3 PHB C DSCP 4 PHB D Locale DSCP 5 PHB E DSCP 6 PHB F … DSCP 3 Al nodo giunge un pacchetto con DSCP 3

44 PHB di default – DSCP non modificato
Mapping DSCP -> PHB DSCP PHB Tipo PHB DSCP di default PHB di default Standard DSCP 1 PHB A DSCP 2 PHB B DSCP 3 PHB C DSCP 4 PHB D Locale DSCP 5 PHB E DSCP 6 PHB F DSCP ??? DSCP ??? PHB di default – DSCP non modificato

45 PHB PHB di default PHB Class Selector Gruppo di PHB Assured Forwarding
PHB Expedited Forwarding

46 Best Effort PDB (Default PHB)
preserva, entro limiti ragionevoli, i servizi offerti ai pacchetti che non richiedono alcuna speciale differenziazione garantisce che i pacchetti ricevano dai domini “il più possibile ed il più presto possibile”. I pacchetti non dovranno essere mai completamente bloccati e, quando saranno disponibili delle risorse (nel senso che non saranno richieste da altri aggregati di traffico), gli elementi di rete dovranno essere configurati in modo tale da permettere ai pacchetti di questo PDB di utilizzarle. Su ogni nodo DS deve essere disponibile un PHB di default, detto appunto Default PHB ([RFC2474]). Si tratta del comune trattamento d’istradamento di tipo best-effort, già disponibile nei router preesistenti al DiffServ. Best Effort PDB Il Best Effort PDB (o BE PDB) è stato pensato per il normale traffico Internet in transito attraverso una rete che supporta il DiffServ. In pratica, l’utilità di questo PDB è quella di preservare, entro limiti ragionevoli, i servizi offerti ai pacchetti che non richiedono alcuna speciale differenziazione. Sebbene il suddetto PDB non preveda limiti sulla disponibilità del servizio, sul ritardo e sulla perdita di pacchetti, ciò non preclude agli ISP di progettare la loro rete imponendo limiti commercialmente ragionevoli sui servizi che utilizzano il BE PDB, in modo simile alle “Service Level Guarantees”, cioè alle garanzie sul livello del servizio che vengono fornite nell’attuale rete Internet. I nodi di confine devono essere configurati in modo tale che i pacchetti che utilizzano il PDB in questione siano marcati con il DS codepoint di default, mentre i nodi interni devono applicare a questi pacchetti il Default PHB. Il BE PDB garantisce che i pacchetti ricevano dai domini “il più possibile ed il più presto possibile”. I pacchetti non dovranno essere mai completamente bloccati e, quando saranno disponibili delle risorse (nel senso che non saranno richieste da altri aggregati di traffico), gli elementi di rete dovranno essere configurati in modo tale da permettere ai pacchetti di questo PDB di utilizzarle.

47 Class Selector PHB compatibilità con il preesistente uso del campo IP Precedence, che costituisce i primi tre bit dell’ottetto Type Of Service dell’header del pacchetto IPv4 xxx000 xxx000 Il Class Selector PHB (o CS PHB) è stato standardizzato in [RFC2474] con l’intento di mantenere, in qualche modo, la compatibilità con il preesistente uso del campo IP Precedence, che costituisce i primi tre bit dell’ottetto Type Of Service dell’header del pacchetto IPv4. Già da prima che si parlasse di DiffServ esistevano (ed esistono tutt’oggi) router in grado di utilizzare il valore del campo IP Precedence per selezionare differenti PHB, in modo simile a quanto avviene nei nodi dell’architettura DiffServ, che si basano, invece, sul valore del DS codepoint. Il campo IP Precedence si può considerare come una sorta di precursore del DS Field. Con la definizione del CS PHB non è necessaria una rigida conformità al DiffServ in ogni nodo della rete, visto che i bit 0-2 del CS codepoint sono usati in modo simile a come viene utilizzato il campo IP Precedence, o comunque in un modo più ampio che lo include. In tal modo, inoltre, non si avranno problemi di eventuali “failure”, specialmente durante il periodo di sviluppo del Diffserv. I valori che possono essere assunti dal campo IP Precedence di 3 bit sono stati assegnati a vari tipi di traffico, incluso il traffico di controllo della rete, il traffico di “routine” e vari tipi di traffico con differenti livelli di privilegio. Il livello più basso è stato assegnato al traffico di “routine”. Per preservare una parziale compatibilità con l’uso tradizionale del campo IP Precedence, senza sacrificare la futura flessibilità, si è scelto di standardizzare un insieme di PHB compatibili con la maggior parte dei “forwarding behavior” selezionati dal campo IP Precedence, descrivendo per ciascuno di essi i requisiti minimi richiesti. La definizione dei suddetti PHB è stata accompagnata, ovviamente, da quella dei relativi DS codepoint. I PHB individuati da questi DS codepoint possono anche avere una lista più dettagliata di specifiche in aggiunta a quelle minime richieste.xxx000 I DS codepoint in questione prendono il nome di Class Selector codepoint, ed i PHB su cui essi vengono mappati sono chiamati Class Selector PHB. Ai CS codepoint è riservato l’insieme di valori del DSCP del tipo: xxx000 I requisiti del Class Selector PHB sul codepoint ‘000000’ sono compatibili con quelli elencati per il Default PHB. Un Class Selector codepoint avente un valore più elevato rispetto ad un altro si dice che ha un grado relativo maggiore rispetto al secondo, mentre in caso contrario si dice che esso ha un grado relativo minore. L’insieme complessivo dei PHB su cui si mappano gli otto possibili Class Selector codepoint deve condurre ad almeno due classi di traffico. I pacchetti marcati con Class Selector codepoint differenti devono essere inoltrati indipendentemente; quindi può accadere che pacchetti che viaggiano con CS codepoint differenti vengano riordinati. In presenza di condizioni operative ragionevoli, a tutti i pacchetti marcati con un CS codepoint di grado relativo maggiore si deve garantire una probabilità di spedizione tempestiva maggiore rispetto a quella offerta ai pacchetti marcati con un CS codepoint di grado relativo minore. Il caso estremo di istradamento non tempestivo è lo scarto di un pacchetto. Inoltre, i PHB selezionati dai codepoint ‘11x000’ devono riservare ai pacchetti un trattamento preferenziale rispetto ai PHB selezionati dal codepoint ‘000000’, per preservare l’uso che comunemente si fa dei valori ‘111’ e ‘110’ del campo IP Precedence (normalmente riservati al traffico di controllo). Un nodo di rete può imporre limiti sulla quantità di risorse che possono essere usate da ciascuno dei Class Selector PHB. I PHB selezionati dai codepoint ‘11x000’ devono riservare un trattamento preferenziale rispetto ai PHB selezionati dal codepoint ‘000000’, per preservare l’uso che comunemente si fa dei valori ‘111’ e ‘110’ del campo IP Precedence normalmente riservati al traffico di controllo).

48 Assured Forwarding PHB
AF4x AF3x Servizio migliore AF2x AF1x AF11; AF12; AF13 Una classe AF può essere configurata per ricevere una quantità di risorse di inoltro maggiore di quella minima quando risorse in eccesso sono disponibili dalle altre classi AF o da altri gruppi di PHB. L’implementazione deve specificare quali algoritmi sono attualmente supportati e come essi possono essere parametrizzati; tuttavia, non è specificato come le risorse in eccesso dovrebbero essere allocate. L’allocazione delle risorse deve essere tale che, sotto normali condizioni operative e di carico, piu’ basso e’ il valore di x, minore e’ la probabilita’ di scarto. All’interno di una classe, il router deve accettare tutti e tre i valori di “drop precedence” ed è tenuto a garantire almeno due effettivi livelli di differente probabilità di perdita per i pacchetti di quella classe. Per reti, quali ad esempio quelle aziendali, in cui i fenomeni di congestione sono un evento raro e di durata contenuta, può essere sufficiente garantire solo due livelli di probabilità e non tre, necessari invece quando la congestione è un evento comune. Nel caso di realizzazione di solo due livelli di probabilità di perdita su una classe AFx, allora il codice AFx1 deve essere usato per il traffico che deve ottenere una bassa probabilità di subire perdite, e i codici AFx2 ed AFx3 per il traffico che potrà sperimentare una probabilità maggiore di subire perdite di pacchetti. Ogni implementazione degli AF PHB deve tentare di minimizzare la congestione a lungo termine, mentre può permettere la congestione a breve termine causata da burst di traffico. Questo richiede algoritmi di gestione delle code attivi, quali ad esempio il RED. Una corretta politica di scarto dei pacchetti dovrebbe far si che flussi di traffico con differenti modelli di burst nel breve termine, ma identiche velocità medie nel lungo termine, abbiano pacchetti scartati con uguale probabilità. L’azione di rifiuto dei pacchetti deve essere graduale e non drastica in modo da permettere al sistema di raggiungere un punto di funzionamento stabile. Si può pensare di usare due livelli di soglia per lo stato di congestione: sotto la prima soglia nessun pacchetto è scartato; tra la prima e la seconda soglia i pacchetti sono scartati con probabilità crescente; oltre la seconda soglia tutti i pacchetti devono essere scartati. Cura dell’implementatore è la corretta configurazione delle soglie per ottenere il rispetto dei requisiti del servizio proposto. Attualmente, sono definite quattro classi (N=4) per uso generale, con tre livelli di drop precedence in ogni classe (M=3). Un numero maggiore di classi e di livelli di drop precedence può essere definito per uso locale. Soglie di scarto dei pacchetti Assured Forwarding (AF) PHB group provides forwarding of IP packets in N independent AF classes. Within each AF class, an IP packet is assigned one of M different levels of drop precedence. An IP packet that belongs to an AF class i and has drop precedence j is marked with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) with three levels of drop precedence in each class (M=3) are defined for general use. More AF classes or levels of drop precedence MAY be defined for local use.

49 AF PHB:example weight: 0,5 0,2 0,3 AF4x AF3x AF2x AF1x ……. 1 1 1 1 2 2
Servizio migliore scheduler AF2x ……. Una classe AF può essere configurata per ricevere una quantità di risorse di inoltro maggiore di quella minima quando risorse in eccesso sono disponibili dalle altre classi AF o da altri gruppi di PHB. L’implementazione deve specificare quali algoritmi sono attualmente supportati e come essi possono essere parametrizzati; tuttavia, non è specificato come le risorse in eccesso dovrebbero essere allocate. L’allocazione delle risorse deve essere tale che, sotto normali condizioni operative e di carico, piu’ basso e’ il valore di x, minore e’ la probabilita’ di scarto. All’interno di una classe, il router deve accettare tutti e tre i valori di “drop precedence” ed è tenuto a garantire almeno due effettivi livelli di differente probabilità di perdita per i pacchetti di quella classe. Per reti, quali ad esempio quelle aziendali, in cui i fenomeni di congestione sono un evento raro e di durata contenuta, può essere sufficiente garantire solo due livelli di probabilità e non tre, necessari invece quando la congestione è un evento comune. Nel caso di realizzazione di solo due livelli di probabilità di perdita su una classe AFx, allora il codice AFx1 deve essere usato per il traffico che deve ottenere una bassa probabilità di subire perdite, e i codici AFx2 ed AFx3 per il traffico che potrà sperimentare una probabilità maggiore di subire perdite di pacchetti. Ogni implementazione degli AF PHB deve tentare di minimizzare la congestione a lungo termine, mentre può permettere la congestione a breve termine causata da burst di traffico. Questo richiede algoritmi di gestione delle code attivi, quali ad esempio il RED. Una corretta politica di scarto dei pacchetti dovrebbe far si che flussi di traffico con differenti modelli di burst nel breve termine, ma identiche velocità medie nel lungo termine, abbiano pacchetti scartati con uguale probabilità. L’azione di rifiuto dei pacchetti deve essere graduale e non drastica in modo da permettere al sistema di raggiungere un punto di funzionamento stabile. Si può pensare di usare due livelli di soglia per lo stato di congestione: sotto la prima soglia nessun pacchetto è scartato; tra la prima e la seconda soglia i pacchetti sono scartati con probabilità crescente; oltre la seconda soglia tutti i pacchetti devono essere scartati. Cura dell’implementatore è la corretta configurazione delle soglie per ottenere il rispetto dei requisiti del servizio proposto. Attualmente, sono definite quattro classi (N=4) per uso generale, con tre livelli di drop precedence in ogni classe (M=3). Un numero maggiore di classi e di livelli di drop precedence può essere definito per uso locale. AF1x N 1 Probabilità di Scarto AF13 AF12 Lunghezza media della Coda

50 Expedited Forwarding PHB
servizio end-to-end a bassa perdita, basso ritardo, basso jitter e banda minima assicurata attraverso i domini DS Tale servizio(servizio Premium ) appare agli “endpoint” come una connessione punto-punto o come una VLL, che sta per Virtual Leased Line (= linea virtualmente affittata). L’Expedited Forwarding PHB (o EF PHB) è stato standardizzato in [RFC3246] per costruire un servizio end-to-end a bassa perdita, basso ritardo, basso jitter e banda minima assicurata attraverso i domini DS. Tale servizio appare agli “endpoint” come una connessione punto-punto o come una VLL, che sta per Virtual Leased Line (= linea virtualmente affittata). Questo tipo di servizio, cioè il servizio VLL, viene anche indicato col nome di servizio Premium La perdita, il ritardo ed il jitter sono tutti dovuti alle code che il traffico sperimenta mentre transita attraverso la rete. In effetti, le cause principali di ritardo nelle reti sono legate ai ritardi di accodamento negli switch e nei router, ma anche a quelli propagazione fissi sperimentati su link che si estendono in ampie aree. Siccome i ritardi di propagazione sono proprietà fisse della topologia della rete, il ritardo ed il jitter complessivi risultano minimi quando vengono minimizzati i ritardi di accodamento. Quindi, fornire bassi ritardi e bassi jitter significa assicurare che i pacchetti dell’aggregato non incontrino code, o che sperimentino code molto brevi. In più, se le code si mantengono corte rispetto allo spazio disponibile nei buffer, anche la perdita di pacchetti viene minimizzata. Le code si creano quando in alcuni nodi il rate istantaneo degli arrivi supera quello delle partenze. Per realizzare un servizio che assicuri che un aggregato non sperimenti delle code, occorre limitare gli arrivi in modo tale che, per l’aggregato in questione, ad ogni nodo di transito il rate degli arrivi massimo sia inferiore a quello delle partenze. In particolare, la creazione di un tale servizio deve essere eseguita in due parti: configurando i nodi in modo che l’aggregato abbia un ben definito rate minimo delle partenze. Per “ben definito” s’intende che tale rate minimo sia indipendente dallo stato dinamico del nodo ed, in particolare, dalla intensità degli altri tipi di traffico nel nodo (e cioè del traffico non-EF). condizionando l’aggregato (attraverso operazioni di policing e shaping) in modo tale che il suo rate degli arrivi all’ingresso di ogni nodo sia sempre inferiore al rate minimo configurato delle partenze. L’EF PHB fornisce la prima parte del servizio. I condizionatori di traffico ai confini della rete forniscono la seconda parte. L’EF PHB non è una parte obbligatoria dell’architettura Diffserv, cioè ad un nodo non è richiesto necessariamente di implementare l’EF PHB per essere considerato un nodo DS. Tuttavia, quando un nodo DS dichiara di supportare l’EF PHB, l’implementazione deve conformarsi alle specifiche fissate dal DiffServ WG in [RFC3246]. L’EF PHB si definisce esattamente come il “forwanding behavior” che viene riservato ad un particolare BA per il quale si impone, ad ogni nodo DS, che il rate medio delle partenze dei pacchetti dell’aggregato superi, o al più eguagli, un rate R minimo configurabile, e ciò deve essere valere indipendentemente dall’intensità di ogni altro traffico che tenta di attraversare il nodo. In particolare, la condizione suddetta deve valere calcolando il valore medio del rate delle partenze su ogni intervallo di tempo maggiore o uguale al tempo che il link d’uscita del nodo DS impiega a trasmettere un pacchetto di lunghezza MTU (Maximum Transfer Unit) al rate configurato R. Quest’ultimo deve poter essere fissato dall’amministratore della rete. Occorre evitare che il traffico EF limiti troppo gli altri tipi di traffico, o addirittura provochi la negazione del servizio (“denial of service”) in alcuni nodi DS nei confronti di alcuni flussi di traffico non-EF. Per far ciò, si può fissare un rate EF massimo (e un valore massimo per la burst size, se è opportuno) ed utilizzare, ai confini di un dominio DS, un limitatore di rate realizzato mediante un token bucket, che imponga rigorosamente che i pacchetti marcati come EF abbiano un rate di arrivo inferiore al rate EF massimo configurato. Il traffico EF che eccede questi limiti deve essere scartato. Il rate EF massimo ed il massimo valore della burst size devono poter essere configurati dall’amministratore della rete. I rate massimo e minimo, inoltre, possono anche avere lo stesso valore. In genere un dominio DS a valle concorda con il dominio a monte il valore da utilizzare per il rate EF massimo. Se due domini adiacenti non hanno negoziato un rate EF massimo, il dominio a valle deve usare come rate di riferimento un rate pari a 0, cioè deve scartare tutti i pacchetti EF. Siccome il servizio Premium, costruito sulla base dell’EF PHB, richiede che il dominio a monte esegua il policing e lo shaping sul traffico da inviare al dominio a valle, in teoria il condizionatore di traffico del dominio a valle non dovrebbe mai scartare pacchetti, per cui, se ciò dovesse verificarsi, questi scarti si dovranno interpretare come violazioni di sicurezza. In modo simile, siccome il rate del traffico EF viene forzato ad ogni nodo interno, la coda EF di ciascun nodo non dovrebbe mai andare in “overflow”, per cui, se ciò dovesse accadere e se dovessero esserci degli scarti, questi ultimi dovranno essere interpretati come seri problemi di errata configurazione. Per una definizione formale dell’EF PHB si rimanda a [RFC3246].

51 Expedited Forwarding PHB
la creazione di un tale servizio deve essere eseguita in due parti: configurando i nodi in modo che l’aggregato abbia un ben definito rate minimo delle partenze condizionando l’aggregato (attraverso operazioni di policing e shaping) in modo tale che il suo rate degli arrivi all’ingresso di ogni nodo sia sempre inferiore al rate minimo configurato delle partenze.

52 EF PHB: example Classificazione Controllo Traffico EF
1 1 1 1 PQ-scheduler 2 2 2 1 1 1 1 2 2 2 EF Un rigido controllo del traffico puo’ evitare la starvation nel PQ Per evitare la starvation viene definito un rate di servizio massimo (oltre che quello minimo)

53 Architettura del DiffServ: Elementi Costitutivi
Regione DS Domini DS stesse definizioni per i PHB L’elemento base dell’architettura è il “nodo DS-compliant”, o brevemente nodo DS, cioè un nodo in grado di supportare le funzionalità ed i PHB definiti nel DiffServ. Un “dominio DS-capable”, o dominio DS, è costituito da una collezione di nodi DS contigui che utilizzano un insieme comune di politiche di “service provisioning” (= approvvigionamento del servizio) e le stesse definizioni per i PHB. In genere, un dominio DS è costituito da una o più reti gestite dalla stessa amministrazione; esempi di domini DS potrebbero essere l’intranet di un’organizzazione oppure l’insieme delle reti gestite da un Internet Service Provider (ISP). Una regione DS è costituita da un insieme di domini DS contigui in grado di offrire i “differentiated services” su tutti i percorsi che li attraversano. Regione DS = insieme di domini DS contigui in grado di offrire “differentiated services” su tutti i percorsi che li attraversano

54 Problema Domini DS distinti che appartengono ad una stessa regione DS possono: supportare PHB differenti eseguire il mapping dei DSCP nei PHB in modo differente Domini DS diversi che appartengono alla stessa regione DS possono supportare PHB differenti tra loro e possono anche eseguire il mapping dei DS codepoint nei PHB in modo differente. Tuttavia, per fornire i “differentiated services” anche attraverso domini DS differenti che appartengono ad una stessa regione, i domini contigui devono stabilire tra loro un Service Level Agreement (SLA).

55 Service Level Agreement (SLA)
Due domini DS contigui devono concordare un SLA Cliente di un’organizzazione o dominio a monte Dominio DS (sorgente o a valle) In generale un SLA è un contratto di servizio, stipulato tra un utente (o customer) ed un service provider, che specifica il tipo di servizio che l’utente riceverà dallo stesso service provider Il service provider è rappresentato, in ogni caso, da un dominio DS “downstream”, cioè a valle. L’utente può essere il cliente di un’organizzazione (nel caso in cui ci si trovi nel dominio sorgente) oppure un altro dominio DS, ed in particolare il dominio “upstream”, cioè quello a monte. Un SLA può includere la specifica delle regole di condizionamento del traffico che dovranno essere adottate per garantire che i termini del contratto vengano rispettati. Queste regole costituiranno per intero, o almeno in parte, quello che prende il nome di Traffic Conditioning Agreement (TCA). SLA può includere: regole di condizionamento del traffico (Traffic Conditioning Agreement: TCA).

56 Traffic Conditioning Agreement (TCA)
TCA = accordo che specifica: regole per il classificatore; possibili profili di traffico; operazioni di condizionamento eseguite (se necessario) sui flussi selezionati dal classificatore Un TCA contiene tutte le regole per il condizionamento del traffico esplicitamente specificate in un SLA, insieme ad altre regole implicite (es: principali requisiti del servizio) Un TCA non è altro che un accordo che specifica le regole che verranno seguite dal classificatore, insieme ai possibili profili di traffico ed alle operazioni di condizionamento (metering, marking, dropping e/o shaping) che devono essere eseguite sui vari flussi di traffico selezionati dal classificatore. Un TCA contiene tutte le regole per il condizionamento del traffico esplicitamente specificate in un SLA, insieme alle regole implicite che riguardano i principali requisiti del servizio e la politica seguita dal dominio DS per fornire il servizio di trasferimento dei pacchetti. Una volta definito il TCA, sarà noto il modo in cui il traffico in transito da un dominio DS ad un altro verrà condizionato al confine tra i due domini. Chiaramente non sarà necessario eseguire il condizionamento del traffico tra due domini DS contigui qualora essi utilizzino la stessa politica di approvvigionamento del servizio, lo stesso insieme di PHB e le stesse modalità di mapping dai DS codepoint ai PHB.

57 “Accordo” In generale, il concetto di “accordo” contiene:
considerazioni tecniche direttamente correlate al DiffServ (SLS, TCS) altre considerazioni tecniche ragioni di natura contrattuale, economica, commerciale SLA e TCA contengono e 3. Come si è visto, la lettera A presente negli acronimi SLA e TCA sta per “agreement”, cioè per “accordo”. In realtà, in generale, la nozione di “accordo” implica, oltre a considerazioni rigorosamente tecniche, anche ragioni di natura contrattuale, economica e commerciale, nonché considerazioni tecniche non direttamente correlate al DiffServ, come ad esempio quelle riguardanti la disponibilità del servizio. Come si suggerisce in [RFC 3260], le nozioni di SLA e TCA devono essere utilizzate in quest’accezione più ampia, mentre per descrivere quegli elementi del servizio e del condizionamento di traffico che riguardano direttamente il DiffServ devono essere usati i concetti di SLS e TCS.

58 SLS e TCS RFC 3220: per descrivere quegli elementi del servizio e del condizionamento di traffico riguardanti direttamente il DiffServ (1.) devono essere usate le nozioni di SLS e TCS Una Service Level Specification (SLS) è costituita da un set di parametri e dai rispettivi valori, che, insieme, definiscono nel complesso il servizio offerto da un dominio DS ad un particolare flusso di traffico. Per flusso di traffico si può sempre intendere l’insieme dei pacchetti che compongono un certo BA, qualunque sia il dominio DS considerato. Invece, nel caso in cui ci si trovi nel dominio DS sorgente o in quello di destinazione, un flusso di traffico può essere costituito da un singolo microflusso o da un gruppo di microflussi, dove per microflusso s’intende una singola istanza di un flusso di pacchetti diretti da un’applicazione ad un’altra. Di conseguenza, nei domini DS di sorgente o destinazione una SLS si può applicare ad un singolo microflusso o ad un gruppo di microflussi, mentre in ogni dominio DS può applicarsi ad un particolare BA. Una Traffic Conditioning Specification (TCS), invece, è costituita da un set di parametri e dai rispettivi valori che, insieme, specificano un profilo di traffico ed un set di regole per il classificatore. Una TCS è una parte integrante di una SLS.

59 Service Level Specification (SLS)
SLS = è costituita da un set di parametri e dai rispettivi valori, che, insieme, definiscono nel complesso il servizio offerto da un dominio DS ad un particolare flusso di traffico

60 Traffic Conditioning Specification (TCS)
TCS = è costituita da un set di parametri e dai rispettivi valori che, insieme, specificano: un profilo di traffico un set di regole per il classificatore. Una TCS è una parte integrante di una SLS

61 Classificazione Classificazione PHB Controllo Traffico Classificazione Controllo Traffico DS Domain SLA DS Domain