RETI TELEMATICHE Lucidi delle Lezioni Capitolo VIII

Transcript

1 Prof. Giuseppe F. Rossi Homepage: UNIVERSITA' DEGLI STUDI DI PAVIA Facoltà di Ingegneria A.A. 2011/12 - I Semestre - Sede PV RETI TELEMATICHE Lucidi delle Lezioni Capitolo VIII Quality-of-Service (QoS)) in reti a commutazione di pacchetto Struttura del capitolo Quando serve la QoS? Le tipologie di schemi per la QoS Il modello IntServ Il modello DiffServ Capitolo VIII 1-2/25 Copyright Ing. Giuseppe F. Rossi,

2 Le applicazioni distribuite e i loro requisiti prestazionali verso la rete Si supponga di avere un'applicazione distribuita formata da una coppia di processi che devono scambiarsi messaggi attraverso una rete a pacchetto caratterizzata da un ritardo τ. Tale applicazione può appartenere ad una delle due seguenti categorie Real-time application Lo scambio di un messaggio tra i due processi applicativi deve avvenire entro un certo tempo max (è necessario imporre un limite superiore τ max al ritardo τ end-to-end ), caratteristico dell'applicazione Il valore τ max di norma è dell'ordine delle centinaia di ms Il superamento di τ max va ad inficiare il corretto funzionamento dell'applicazione Elastic application Lo scambio di un messaggio tra i due processi applicativi può avvenire in un tempo qualunque (naturalmente compatibilmente con i time-out dei protocolli confermati) La conversazione telefonica trasferita a pacchetto Caratteristiche & requisiti Si consideri il traffico (di pacchetti) generato da una conversazione telefonica digitalizzata La digitalizzazione (senza alcuna compressione) del segnale telefonico genera traffico avente packet_rate e packet_size costanti (un traffico avente tali caratteristiche si dice isocrono) (Modulazione PCM) Banda massima del segnale analogico = 4 KHz fcamp = 8 KHz Quantizzazione = 8 bit / campione Bit-rate risultante = 64 Kbps Vincolo sul ritardo: il modulo nel processo ricevente che ricostruisce il segnale trasmesso deve ricevere i campioni del segnale contenuti nei pacchetti alla stessa cadenza regolare con la quale sono stati generati (nell'esempio, uno ogni 125 µs) sul lato mittente; in caso contrario la ricostruzione risulta degradata... entro un tempo max, altrimenti gli interlocutori cominciano a non capirsi Capitolo VIII 3-4/25 Copyright Ing. Giuseppe F. Rossi,

3 La conversazione telefonica trasferita a pacchetto La bufferizzazione sul ricevente I pacchetti contenenti i campioni, attraversando una rete a pacchetto in generale sperimentano un ritardo non costante (fenomeno del jitter di pacchetto) Al fine di ripristinare l'isocronia del traffico presso il processo destinatario (condizione necessaria per il buon funzionamento), sul nodo ricevente viene utilizzato un buffer La funzione del buffer è di assorbire le fluttuazioni introdotte dal jitter Processo Mittente Mittente buffer Destinatario Processo Destinatario La conversazione telefonica trasferita a pacchetto Le componenti del ritardo Il ritardo sperimentato tra l'istante in cui un campione viene generato e l'istante in cui lo stesso campione viene ritrasformato in segnale analogico ha le seguenti componenti (tra loro additive): Ritardo di compressione Ritardo di pacchettizzazione Ritardo della rete (τ end-to-end ) Tempi di trasmissione Tempi di propagazione Tempi di processing da parte dei nodi di commutazione Tempi di accodamento Ritardo di bufferizzazione (τ buffer ) Ritardo di decompressione Ritardo di ricostruzione del segnale (trascurabile) Capitolo VIII 5-6/25 Copyright Ing. Giuseppe F. Rossi,

4 La conversazione telefonica trasferita a pacchetto I ritardi tollerati La telefonia classica individua in 150 ms il massimo ritardo ammissibile tra i due interlucutori nel caso di conversazione di ottima qualità Quindi deve sicuramente essere: τ end-to-end + τ buffer < 150 ms τ end-to-end non deve avere fluttuazioni troppo ampie altrimenti costringe ad avere τ buffer molto elevati Quando serve la Quality-of-Service? La rete I controlli di QoS sono necessari quando si verificano contemporaneamente le due seguenti condizioni E' necessario garantire alcune grandezze (Throughput, τ end-to-end ) Vi possono essere degli intervalli di tempo in cui le richieste possono eccedere la capacità delle risorse del sistema (se le risorse di un sistema (rete) sono dimensionate sul caso peggiore (picchi massimi di richieste), allora la QoS non serve: il sistema sarà sempre in grado di garantire le grandezze in qualunque condizione di traffico) Effetti Aumento degli accodamenti Scarto dei pacchetti dalle file d'attesa (nel caso queste siano di dimensione max non sufficiente) Capitolo VIII 7-8/25 Copyright Ing. Giuseppe F. Rossi,

5 Come si fissa la QoS in una rete? I valori di QoS di una rete vengono fissati tramite un contratto tra Utente e Provider, detto Service Level Agreement (SLA) Capacità (in bps) Disponibilità (Availability) (in %) Ritardo (in ms)... SLA su reti IP E' una cosa molto interessante ma difficile da realizzare nelle reti IP IP fornisce una QoS best effort (=nessuna garanzia) in quanto non vi é alcun controllo circa gli usi (e gli abusi) degli utenti della rete Approcci alla QoS Si possono individuare 3 approcci Predictive QoS Dimensionamento della rete sulla base di quello si stima essere il traffico Flow-based QoS Richiesta esplicita e successiva allocazione di risorse per le singole sessioni (o flow) comunicative Class-based QoS Raggruppamento delle sessioni comunicative in classi di traffico I pacchetti appartenenti alla stessa classe di traffico sono trattati, dal punto di vista della QoS, in modo indistinguibile Capitolo VIII 9-10/25 Copyright Ing. Giuseppe F. Rossi,

6 Predictive QoS E' la modalità utilizzata nella maggior parte delle reti datagram attuali (es. Internet) Si dimensiona la rete in base al numero di utenti ed in base al traffico stimati (dimensionamento sul presunto caso "peggiore") Nel caso, in qualche intervallo di tempo, le richieste superino la capacità della rete, la QoS inizialmente prevista non è più garantita Flow-based QoS L'approccio predictive QoS in sostanza non garantisce nessuna QoS All'estremo opposto si trova lo schema flow-based QoS Una sessione comunicativa (flow) tra 2 applicazioni effettua una prenotazione delle risorse di rete necessarie, le quali, se disponibili, vengono riservate esclusivamente a tale comunicazione Un problema: la scalabilità su reti con un numero elevato di flussi I router dei backbone IP devono mantenere uno stato (prenotazione) per ogni sessione che li attraversa (per-flow-state): un router di dorsale di Internet può essere attraversato da centinaia di migliaia di flow Capitolo VIII 11-12/25 Copyright Ing. Giuseppe F. Rossi,

7 Class-based QoS Il concetto di base che distingue questo tipo di QoS dalla flow-based QoS sta nel fatto che la differenziazione dei pacchetti avviene su base aggregata e non su base singolo flusso Una data informazione aggiunta nella testata dei pacchetti identifica non un singolo flusso ma una classe di flussi (o classe di traffico) I router della rete devono riconoscere e trattare in modo differenziato le varie classi e non i vari flussi (per esempio prevederanno sistemi a coda con 1 fila d'attesa per ogni classe di traffico) Essendo il numero delle classi inferiore al numero dei flussi (merito dell'aggregazione), sulle dorsali cadono i problemi di scalabilità emersi nel caso della flow-based QoS IETF & QoS Il problema della QoS nelle reti a pacchetto é da tempo oggetto di studio in ambito IETF (Internet Engineering Task Force) I due principali approcci sono i seguenti Modello Integrated Services (IntServ) IntServ Working Group Propone un modello (sofisticato) di tipo flow-based QoS DiffServ Working Group Approccio più recente, propone un modello di tipo class-based QoS Capitolo VIII 13-14/25 Copyright Ing. Giuseppe F. Rossi,

8 Modello Integrated Services (IntServ) Nel Giugno del 1994 il gruppo di lavoro Integrated Services dell'ietf pubblica un RFC con una proposta di estensione dell'architettura di Internet e dei relativi protocolli per il supporto su rete a pacchetto IP di servizi real-time e non-real-time RFC1633: Integrated Services in the Internet Architecture: an Overview. R. Braden, D. Clark, S. Shenker. June (Status: INFORMATIONAL) Punto chiave dell'architettura IntServ: estensione al modello di servizio best-effort di IP attraverso l'aggiunta di nuovi tipi di servizi più sofisticati Modello Integrated Services (IntServ) L'implementazione E' necessario modificare il modello di IP-forwarding dei router estendendo le operazioni sui flow anche a tutti i nodi intermedi: ogni router deve riconoscere l'insieme di pacchetti che appartengono alla stessa conversazione (flow), fornendo loro la stessa QoS E' necessario aggiungere ai router funzioni di traffic control Packet classifier: riconosce i pacchetti ricevuti che appartengono allo stesso flow e che devono subire lo stesso trattamento, cioé la stessa QoS Packet scheduler: decide la politica di forwarding dei pacchetti (WRR, WFQ,... ) che permette di garantire determinate QoS a specifici flow Admission control: é l'algoritmo che decide se accettare o meno la richiesta di un nuovo flow Reservation protocol: é il protocollo di segnalazione che serve per instaurare e mantenere lo stato associato ad un flow sul percorso mittente-destinatario (prenotazione esplicita delle risorse) Capitolo VIII 15-16/25 Copyright Ing. Giuseppe F. Rossi,

9 Modello Integrated Services (IntServ) Riconoscimento dei flow in IP Analizzando le sole informazioni contenute nella header della PDU IPv4 non è possibile identificare univocamente un flow Il rimedio consiste nell'utilizzare anche informazioni contenute nelle testate dei protocolli di livello superiore all'ipv4 Per esempio i protocolli di livello Transport Un flow può essere identificato dalla quintupla: (Src_IP_Addr,Src_Port_Nr,Dest_IP_Addr,Dest_Port_Nr,Prot) Analizzando le sole informazioni contenute nella header della PDU IPv6 è possibile identificare univocamente un flow Un flow può essere identificato dalla coppia: (Src_IP_Addr,Flow_Label) Modello Integrated Services (IntServ) RSVP: concetti di base Protocollo di segnalazione progettato per poter eseguire due attività fondamentali Permettere ad una applicazione di richiedere una specifica QoS alla rete Permettere ai router di inoltrare attraverso i percorsi le varie richieste di QoS RSVP é in grado di funzionare per comunicazioni unicast e multicast: nel caso multicast RSVP si adatta dinamicamente alla composizione dei gruppi La richiesta RSVP di allocazione delle risorse è relativa flussi simplex Per allocare risorse in due sensi opposti bisogna inoltrare due diverse richieste (caso più frequente) Capitolo VIII 17-18/25 Copyright Ing. Giuseppe F. Rossi,

10 Fondamenti del modello DiffServ Modello di tipo class-based QoS Nessuna gestione su base flusso (flow) nei router IP intermedi => nessun per-flow-state sui router intermedi Aggregazione dei traffici all'ingresso della rete (DS Domain) in classi di traffico attraverso l'utilizzo del campo DS_Field presente nelle testate IP Per-Hop-Behavior (PHB) sui router intermedi All'interno del DS Domain ogni router mappa il contenuto del campo DS_Field in una particolare modalità di forwarding (PHB) Pacchetti con lo stesso valore di DS_Field subiscono lo stesso forwarding Necessità di funzioni di controllo ai bordi del DS Domain Quando un traffico si presenta al router di confine (ingress router) di un DS Domain, tale nodo deve decidere se e come far entrare detto traffico Il traffico (flow) viene riconosciuto dal router di ingresso sulla base delle classiche informazioni contenute nelle testate dei protocolli di livello 3 e 4 In base agli accordi contrattuali Customer-Provider (SLA) tale flusso viene collocato in una classe di traffico, tramite assegnazione di un valore al DS_Field (DSCP_Field) Ogni router del DS Domain analizza DS_Field ed applica il conseguente PHB (forwarding) La QoS end-to-end (cioé ingress-egress node) risulta data non da una esplicita allocazione, ma dall'effetto complessivo di tanti (indipendenti) PHB sui nodi intemedi Datagram IP Datagram IP DS_Field DS Domain Capitolo VIII 19-20/25 Copyright Ing. Giuseppe F. Rossi,

11 La marcatura dei pacchetti Dove viene definito il DS_Field (lungo 1 byte) nelle header IPv4? Sostituisce il campo Type_Of_Service (TOS) Il modello DS utilizza solo i 6 bit più significativi del DS_Field, che costituiscono il campo chiamato DSCP (Differentiated Services Control Point) L'uso di DS_Field è solo parzialmente compatibile con il vecchio uso di TOS DS_Field TOS Header IPv4 DSCP CU 6 bit 2 bit Struttura del DS_Field (1 byte) DS_Field in IPv4 DSCP = Differentiated Services Code Point CU = Currently Unused I Per-Hop-Behavior Default PHB Si tratta del classico best effort forwarding presente in tutti i router esistenti, standardizzato in RFC1812 ("Requirements for IP Version 4 Routers" F. Baker. June 1995) Deve essere supportato da tutti i nodi DS-compliant Assured Forwarding PHB Group Definisce un gruppo di PHB, ciascuno dei quali prevede un diverso grado di 'garanzie' sul recapito del pacchetto (es. diversa drop precedence in caso di congestione) Expedited Forwarding PHB Definisce un PHB che fornisce strette garanzie sul tempo di forwarding del pacchetto Capitolo VIII 21-22/25 Copyright Ing. Giuseppe F. Rossi,

12 Default PHB E' il comportamento di un router classico IP Realizza un servizio best effort delivery Valore per codificare questo PHB: DSCP='000000' Assured Forwarding PHB Group "Assured Forwarding (AF) PHB group is a means for a provider DS domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain" (da RFC2597) AF PHB Group definisce: N "classi di forwarding" (attualmente N=4) tra loro indipendenti M livelli diversi di "drop precedence" (attualmente M=3) all'interno di ciascuna classe Le classi sono di uso generale: il trattamento subito dai loro traffici é configurabile sui nodi Ogni nodo deve allocare ad ogni classe una quantità minima (configurabile) di "risorse di forwarding" (= buffer e banda trasmissiva), al fine di limitare il rischio di deadlock di un traffico Non esiste alcun requisito temporale quantificabile (val. max, varianza,... ) circa il tempo di forwarding subìto da un pacchetto appartenente al gruppo AF PHB Capitolo VIII 23-24/25 Copyright Ing. Giuseppe F. Rossi,

13 Expedited Forwarding PHB "The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains" (da RFC2598) Questo specifico PHB (DSCP='101110') può essere usato per costruire un servizio end-to-end di tipo "virtual leased line" Un nodo DS-compliant non é obbligato a supportare EF PHB; tuttavia se dichiara di supportare tale PHB deve essere conforme a quanto specificato in RFC2598 Come si costruisce un servizio end-to-end così stringente? Su ogni nodo di rete, per la classe di traffico della classe EF, il max rate di arrivo deve essere inferiore al min rate di partenza Questo si traduce (per la classe EF) in: Minimo rate di partenza garantito (cioé indipendente dagli altri traffici) in ogni nodo Conditioning sul rate di immissione del traffico ai confini del DS Domain Capitolo VIII 25-26/25 Copyright Ing. Giuseppe F. Rossi,