Sicurezza e Gestione delle Reti (di telecomunicazioni)

Transcript

1 Sicurezza e Gestione delle Reti (di telecomunicazioni) Tommaso Pecorella tommaso.pecorella@unifi.it Corso di Studi in Ingegneria Elettronica e delle Telecomunicazioni Corso di Studi in Ingegneria Informatica Facoltà di Ingegneria Università degli Studi di Firenze Lezione 05, Quality of Service aa. 2010/11 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 1 / 34

2 QoS, QoE, QQ? Aww Quality of Service (QoS) In the field of computer networking and other packet-switched telecommunication networks, the traffic engineering term quality of service (QoS) refers to resource reservation control mechanisms rather than the achieved service quality. Quality of service is the ability to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow. Quality of Experience (QoE) sometimes also known as Quality of User Experience, is a subjective measure of a customer s experiences with a vendor QQ an emoticon for a crying face [like in stop QQing, change ISP ] T. Pecorella (DET) SGRtlc 05 - aa 2010/11 2 / 34

3 QoS, QoE, QQ? Aww La base di tutto è la QoE, ovvero la soddisfazione dell utente. Questa è dipendente dal servizio e dalle aspettative dell utente. Rete monoservizio La QoE è un semplice problema relativo alla gestione della rete. Reti multiservizio La QoE dipende da come sono gestiti nella rete i vari tipi di flussi dati. Bits are NOT bits, non tutti i pacchetti in rete sono uguali. Alcuni pacchetti devono avere una gestione diversa, altrimenti non ci può essere un servizio adeguato. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 3 / 34

4 QoS, come? Application Layer Sviluppo di Application Programming Interface (API) capaci di riservare trattamento diverso ai servizi Real-time a livello di sistema operativo. Transport Layer Protocolli di trasporto differenziati per servizio (o adattativi). QoS end to end. Network Layer Differenziazione dei flussi a livello IP. QoS Router to Router. Data Link Layer Differenziazione dei flussi a livello di frame o celle. QoS sul link. Physical Layer Mezzi trasmissivi più efficienti (rame, fibra ottica), tecniche di codifica, BER adattiva. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 4 / 34

5 QoS, ma serve? Sprint Labs (Sett. 2001): La QoS non serve!!! Sprint: 25 PoP in USA, 10 in Europa, 5 in Asia, TIER-1 ISP: Big Internet! Dopo 11 Settembre WTC: solo 3% di incremento di traffico sulla rete! E colpa dei server! Ogni settimana le velocità dei link vengono cambiate! Usano in media il 30% della capacità di ogni link! Nel core (Sprint Labs!) non ci sono perdite (Ploss 0%) Fra N.Y. e S.Francisco 28 ms di delay, con 5 GigaPoP in mezzo!!! Ciò che SERVE è la Quality of Access (QoA). Le reti di dorsale europee sono molto più congestionate e con capacità inferiori. L overprovisioning non è così semplice in Europa T. Pecorella (DET) SGRtlc 05 - aa 2010/11 5 / 34

6 QoE, ricominciamo Facciamo un po di chiarezza... Le tecniche di QoS servono a raggiungere il grado desiderato di QoE. La QoE non è dipendente dalle tecniche che vengono usate (l utente non ne è al corrente), quindi qualsiasi mezzo per ottenere la QoE è lecito. Esistono differenti metodi per ottenere la QoE. Un paragone Supponiamo che i pacchetti dati in una rete siano come delle automobili in una strada. Strada sempre sgombra: non c è bisogno di differenziare le macchine. Strada abbastanza trafficata: c è bisogno di avere delle precedenze. Strada bloccata: c è bisogno di avere delle corsie riservate. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 6 / 34

7 Tipi di traffico Un esempio di tipo di traffico diverso. Traffico non Real-Time - TCP E di tipo Burst Richiede un tasso di errore praticamente nullo Tutti i pacchetti sono trattati allo stesso modo Può essere recapitato con un certo ritardo Traffico Real-Time - UDP E un flusso di tipo continuo Accetta un certo numero di errori I pacchetti hanno priorità diversa Deve essere recapitato con il minor ritardo possibile Questo è solo un esempio, si possono fare mille altre differenziazioni. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 7 / 34

8 Esempio: VoIP Se andiamo a misurare la qualità di una comunicazione VoIP, si possono usare i seguenti parametri: Tasso di perdita dei pacchetti IP Delay Delay Jitter (variazione del Delay) La QoS risultante è: Scarsa Media Buona Perfetta Packet Loss (%) Delay (ms) > <150 Jitter (ms) Il Jitter è il parametro più difficile da rispettare. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 8 / 34

9 Esempio: Jitter e buffer di playout Tutti i flussi RT (Real-Time) hanno caratteristiche di isocronicità (grossomodo), o quantomeno devono essere usati dal player allo stesso rate di emissione della sorgente. La trasmissione in rete introduce perdite, ritardi ma soprattutto altera i riferimenti temporali intra-pacchetto (Jitter) Per recuperare la desincronizzazione si deve usare un buffer di playout che è dipendente dal Jitter, ma che introduce un ulteriore ritardo. Se è troppo piccolo si cominciano a perdere pacchetti e/o a non averne di disponibili. Se è troppo grande si introduce troppo ritardo. Buffer di playout T. Pecorella (DET) SGRtlc 05 - aa 2010/11 9 / 34

10 QoS End to End La Qualità del Servizio end-to-end deve garantire livelli di servizio accettabili in tutti gli elementi della catena di comunicazione. Sorgono problemi quando il link end-to-end attraversa reti di ISP diversi; servono accordi di peering e di Service Level Agreement fra gli ISP Reti di tipo diverso Il problema è che non tutte le reti sono uguali, ciascuna ha le proprie criticità: Accesso: pochi utenti, banda limitata Core: molti utenti, banda molto elevata Tecnologie differenti Non basta creare un backbone ad altissima velocità in modo da ridurre la dipendenza dalla QoS. Esistono reti in cui non è possibile fare affidamento sulla larga banda. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 10 / 34

11 Approcci per la QoS Per la QoS servono differenti strategie nelle diverse parti di rete. Si può parlare di: QoS nei nodi di rete Sostanzialmente a livello IP Shaping del traffico Scheduling dei pacchetti Classificazione Riservazione delle risorse... QoS end-to-end Può coinvolgere anche livelli protocollari superiori Meccanismi di segnalazione end-to-end Architetture di rete per la Qos... T. Pecorella (DET) SGRtlc 05 - aa 2010/11 11 / 34

12 Possibili Funzioni di QoS sui nodi In un nodo si possono implementare diverse funzioni relative alla QoS. Non tutte sono applicabili in tutti i punti della rete a causa del carico computazionale che richiedono. Classifier, osserva i pacchetti IP entranti nel nodo e li classifica in base al loro ind IP, Port Number e al tipo di protocollo superiore Marker, provvede a marchiare i pacchetti a seconda di come sono stati classificati Traffic Policer, fa condizionamento del traffico, osserva il rate possibile e agisce di conseguenza Traffic Shaper, modella il flusso sulla porta di uscita in modo da ottimizzare il throughput Scheduler, genera più code all interno del nodo di rete, e usa algoritmi di scheduling delle code, evitando o gestendo le congestioni di rete. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 12 / 34

13 Esempio di Traffic Policer: Token Bucket Un esempio di algoritmo di Traffic Policy nei nodi di rete è il Token Bucket. Quando un pacchetto arriva al router, viene tolto dal Bucket un certo numero di Tokens (dipendentemente dalla dimensione del pacchetto), un pacchetto non potrà essere inviato se non ci sono Tokens a sufficienza nel Bucket. Il router trasmetterà un burst di pacchetti minore o uguale a B, ad un rate minore o uguale ad R. R tokens / sec B tokens (bucket capacity) T. Pecorella (DET) SGRtlc 05 - aa 2010/11 13 / 34

14 Scheduling Gli algoritmi di scheduling nei nodi di rete sono molto simili a quelli che si trovano nei Sistemi Operativi, hanno gli stessi obbiettivi e gli stessi difetti. Scheduler ottimo Uno scheduler ottimo sarebbe quello che si avvicina al limite del Fluid Scheduling. Sfortunatamente le unità di scheduling sono i pacchetti. Scheduler non Work Conserving Non-work-conserving scheduling may be idle at any time Ma può garantire alcune proprietà, come le deadlines. Scheduler Work Conserving Work-conserving scheduling is idle only when there is no traffic to send Ma non si può interrompere un work in progress, ossia non è strettamente a priorità. Gli algoritmi di scheduling nei router sono uno dei punti più delicati che possano esistere. Non toccateli se non sapete cosa state facendo. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 14 / 34

15 Queue management A volte le code di ricezione si riempiono. Buttare via i pacchetti quando la cosa è piena (tail-drop) è la cosa sbagliata. Il queue management è strettamente legato al congestion control, perché il TCP (e molti altri protocolli) rilevano le congestioni misurando il numero di pacchetti persi. Weighted Random Early Detection (WRED) I pacchetti vengono scartati dal nodo di rete con probabilità tanto maggiore quanto più la coda è piena (RED) Si fissano dei limiti per la lunghezza della coda e a seconda del loro superamento si scartano i nuovi pacchetti in arrivo La probabilità di scarto può dipendere in modo pesato dal tipo di classe cui appartengono (WRED) Sfrutta rate adattivo del TCP, che vede lo scarto del pacchetto come dovuto a congestione, e dunque rallenta il rate in trasmissione; non funziona con UDP. E una tecnica per evitare la congestione sul nodo di rete, anziché per gestirla una volta che è avvenuta T. Pecorella (DET) SGRtlc 05 - aa 2010/11 15 / 34

16 QoS in Internet In Internet ci sono sostanzialmente due modelli di gestione della QoS. Integrated Services (IntServ) Giugno 1994 RFC 1633 Differentiated Services (DiffServ) Dicembre 1998 RFC 2475 Non sono esattamente due novità dell ultima ora... ci si aspetterebbe che fossero usate. Invece no. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 16 / 34

17 IntServ Il modello IntServ prevede di prenotare le risorse necessarie al mantenimento della QoS richiesta in ogni apparato di rete attraversato da un flusso dati. Flusso: sequenza di pacchetti con stesso indirizzo IP sorgente e destinazione, e stessi Port numbers Ogni router della rete deve allocare risorse (banda, memoria, etc.) a sufficienza per ciascun flusso Ciascun router della rete deve avere un per-flow state relativo a ciascun flusso a cui viene data QoS Poiché le risorse su ogni router sono limitate, ciascun router dovrà controllare e decidere quali flussi allocare e quali rifiutare, esiste un Admission Control. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 17 / 34

18 IntServ Il modello IntServ ha tre componenti di base: Traffic Classes Classi di servizio ottenibili da un flusso. I parametri di ciascuna classe possono essere modificati a piacimento. Traffic Control Esegue controllo sul traffico che transita su ogni nodo di rete. E composto da vari sotto-componenti. Setup Protocol Costituisce il sistema di segnalazione fra i nodi di rete per l allocazione delle risorse. E anche la base per l Admission Control. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 18 / 34

19 IntServ Le Classi di Traffico (Traffic Classes) ammissibili sono 2+1: Default E il servizio Best Effort della Internet attuale. Non è una vera TC. Guaranteed Service Supporta traffico Real-Time che richiede un ritardo di propagazione limitato. Offre una garanzia sulla QoS offerta. Controlled Load Service Approssima un servizio di tipo Best Effort su una rete non congestionata. Guaranteed Service = bad La definizione del Guaranteed Service nasconde un grosso problema: la garanzia. Per ottenere davvero un Guaranteed Service si dovrebbe usare un non work conserving scheduler. Quindi di solito si usa il Controlled Load Service. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 19 / 34

20 IntServ Il Traffic Control viene effettuato tramite tre sotto-sistemi: Admission Control Controlla che le risorse sul router e nella rete possano supportare un particolare servizio richiesto. Packet Classifier Esamina ind. IP e Port number di ogni pacchetto per vedere a che classe appartiene Packet Scheduler Effettua lo scheduling i pacchetti per trasmetterli alla porta di uscita del router (usando ad esempio WFQ). Ovviamente nel caso di un router c è anche una sezione relativa al forwarding dei pacchetti. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 20 / 34

21 IntServ Schema di un nodo IntServ IntServ router QoS DataBase Admission Control Packet Classifier Forwarder Routing Table Packet Scheduler Packet Scheduler Attenzione alla tabella di routing: è diversa da quella normalmente usata. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 21 / 34

22 IntServ - protocollo RSVP Nel modello IntServ il protocollo di setup dei nodi di rete è il Resource Reservation Protocol RSVP Abilita gli host o i router a richiedere l allocazione delle necessarie risorse di rete Installa nei nodi di rete il Per-Flow state soft (refreshing periodico) Il Per-Flow state è soft, nel senso che se non ne viene fatto il refresh viene cancellato dopo un certo timeout. Questo evita che un elemento di rete possa finire le proprie risorse a causa di un errore di comunicazione (es. un host che scompare senza effettuare il teardown della comunicazione). T. Pecorella (DET) SGRtlc 05 - aa 2010/11 22 / 34

23 IntServ - protocollo RSVP In IntServ si identificano due ruoli: Sender: colui che invierà i dati soggetti a QoS. Receiver: colui (coloro) che riceveranno tali dati. Il protocollo RSVP si basa su due mesaggi: PATH Message Trasmesso dal Sender verso il (i) Receiver(s) (unicast o multicast). RESV Message Trasmesso dal (dai) Receiver(s) verso il Sender in risposta al suo PATH. 1) PATH 2) RESV Sender 3) DATA Receiver T. Pecorella (DET) SGRtlc 05 - aa 2010/11 23 / 34

24 IntServ - protocollo RSVP Messaggio PATH 1 Il Sender avvia una sessione RSVP 2 Inserisce nel PATH message il Sender Template (i.e., IP address e Port Number) ed il Sender Tspec (descrive le caratteristiche del traffico dati che sarà generato) 3 Ciascun router memorizza il Sender Template, installa lo stato della richiesta, e può aggiornare l Adspec (riassume le caratteristiche di QoS del percorso fatto fino a quel router). Messaggio RESV 1 il Reciever riceve il PATH e ha (anche) una traccia del percorso fatto dal PATH. 2 Genera un RESV message, contenente il FilterSpec (i.e., IP address e Port number del Receiver) ed il Flowspec (descrive la QoS che il Receiver richiede) 3 L Admission Control di ogni router fa l ultimo controllo per determinare se le risorse sono disponibili (in caso non lo siano viene generato un messaggio d errore per il Receiver). 4 Ciascun router si aggiorna tramite il Filterspec e il Flowspec T. Pecorella (DET) SGRtlc 05 - aa 2010/11 24 / 34

25 IntServ - allocazione risorse Per avere maggior controllo sulla QoS delle applicazioni, RSVP prevede diversi reservation styles, fra cui: Fixed-Filter (FF) Una prenotazione di banda per ogni utente chiamante (es.: videoconferenza con requisiti di ritardo stringenti) Shared-explicit (SE) Più utenti chiamanti nella stessa sessione possono dividere una prenotazione di risorse (es.: voiceconference dove solo uno per volta può parlare) RSVP supporta anche il multicast: riassume le prenotazioni provenienti da ciascun flusso, allocando sul nodo la maggior banda richiesta, e poi trasmette il Flowspec totale al router vicino (farà admission control sul flusso totale). E molto flessibile. Attenzione: Se non fosse chiaro RSVP e IntServ sono unidirezionali. Per una telefonata VoIP servono DUE sessioni IntServ. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 25 / 34

26 IntServ - Pros and Cons Pros Cons Allocazione dinamica della banda. Supporto per l AAA (i.e., billing). Supportato in Winsock2, nuova (nuova?!?!) API per W98. Sempre più router supportano RSVP (diciamo anche praticamente tutti). E un protocollo relativamente maturo, e dunque più stabile e diffuso. Il Per-Flow State è soft, cioè richiede di essere aggiornato periodicamente (ogni 30 sec) sui router, il che comporta un notevole aumento del traffico di segnalazione. Richiede la memorizzazione degli oggetti relativi ad ogni flusso su ogni router. Necessita di una rete con buon Best Effort e routing stabile (le tabelle non devono variare troppo). Non è scalabile in reti di elevate dimensioni. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 26 / 34

27 DiffServ Il modello DiffServ si basa sul multiplexing statistico, ossia si dividono (dinamicamente) le risorse di rete tra un numero limitato di diversi tipi di traffico, in modo che ciascuno sia sostanzialmente isolato dagli altri. La complessità si sposta all edge della rete, dove si classificano i singoli pacchetti, si marchiano (colorazione) e si aggregano per poi inviarli nel core. Flussi provenienti da diverse applicazioni vengono aggregati insieme e trattati allo stesso modo. Si opera su aggregati. Nel core, il flusso aggregato riceve un trattamento relativo alla classe di servizio (al colore) dei pacchetti che contiene (Per-Class, non più Per-Flow) Non c è più segnalazione (RSVP), né admission control, e dunque si deve fare provisioning delle risorse a priori (si allocano più risorse del necessario), e controllare all edge che il traffico immesso non sia eccessivo. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 27 / 34

28 DiffServ La base del DiffServ è nel modo in cui si colorano i pacchetti e come il colore viene trattato. DSCP Il Byte DS nell header IP; 6 bit definiscono il colore del pacchetto. Per-Hop-Behavior (PHB) Definisce il servizio che il pacchetto riceverà a ciascun hop nella rete Behavior Aggregate (BA) Un gruppo di pacchetti (aggregato) con stesso DSCP; nella rete si applica un PHB ad ogni BA DSCP C U Versi on Traffic Class Payload Length Flow Label Next Header Hop Limit Versi on IHL Identification Type of Service Fla gs Total Length Fragment Offset TTL Protocol Header Checksum Source Address Destination Address Source Address Destination Address Options Padding T. Pecorella (DET) SGRtlc 05 - aa 2010/11 28 / 34

29 DiffServ I nodi DiffServ agiscono diversamente tra Edge e Core. DiffServ Edge node Packet Classifier Forwarder Policer Marker Packets with valid DSCP Out-of-policy packets, might be marked with lower DSCP or dropped Edge node Classifier: qualsiasi metodo di classificazione Policer: controllo del rispetto del SLA Marker: marchiatura con il DSCP appropriato Scheduling e MAC marking: ovvio... T. Pecorella (DET) SGRtlc 05 - aa 2010/11 29 / 34

30 DiffServ I nodi DiffServ agiscono diversamente tra Edge e Core. Core node BA Classifier: basato sul DSCP e su altri parametri di livello MAC. Si ricava il PHB. Scheduling: scheduling basato sul PHB. PHB DSCP Il DSCP sono 6 bit, il PHB è di dimensioni maggiori. Un router ricava il PHB dal BA classifier, che può considerare (ad esempio): DSCP del pacchetto IP precedence bits MPLS EXP bits IEEE 802.1p CoS bits swconfig80-cos/download/cos-ba-classifiers.pdf T. Pecorella (DET) SGRtlc 05 - aa 2010/11 30 / 34

31 DiffServ Esistono tre tipi di PHB. Default Best Effort tradizionale Expedited Forwarding (EF) - RFC 2598 Connessioni con basse perdite, basso ritardo e basso jitter. Usa un solo DSCP (101110, 46) per immettere il pacchetto nella coda a più alta priorità nei router di rete (con WFQ ad esempio). Assured Forwarding (AF) - RFC 2597 Definisce 4 classi di servizio relative, ciascuna con tre livelli di precedenza di scarto; usa 12 distinte combinazioni di DSCP. Il SLA dipende da: classe AF (risorse allocate), livello di traffico di quella classe, drop precedence (in caso di congestione) T. Pecorella (DET) SGRtlc 05 - aa 2010/11 31 / 34

32 DiffServ Il PHB AF è quello maggiormente in uso, e definisce una matrice di 4x3 possibili comportamenti: Class 1 Class 2 Class 3 Class 4 Low Drop Medium Drop High Drop La classe è definita nei primi 3 bit. La Drop precedence è definita nei secondi 3 bit. La classe non definisce una priorità relativa. E compito dell ISP definire le associazioni di priorità, ossia i PHB e i BA. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 32 / 34

33 DiffServ - Pros and Cons Pros Cons Maggiore scalabilità, la complessità viene spostata sull edge Non è più necessario il protocollo di segnalazione RSVP, minor oberhead. Clienti diversi possono essere partizionati. Si integra piuttosto bene con le tecnologie di livello rete. La diffusione dei DiffServ su domini di providers diversi impone accordi di peering bilaterali, difficili da gestire. Bisogna non immettere in rete traffico in eccesso, cosa piuttosto complicata. L Admission Control manca, quindi bisogna usare il Traffic Engineering. E QoS statistica, quindi non funziona su reti con poca banda. Va comunque rispettata la regola di Van Jacobson. I link non devono superare il 50-70% della loro capacità. DiffServ funziona ma deve essere accoppiato con altri metodi di supporto alla QoS, come MPLS. Malidetti commerciali. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 33 / 34

34 Traffic Engineering Dal momento che ne abbiamo parlato... http: //en.wikipedia.org/wiki/teletraffic_engineering Telecommunications traffic engineering, Teletraffic engineering or traffic engineering is the application of traffic engineering theory to telecommunications. Teletraffic engineers use their basic knowledge of statistics including queuing theory, the nature of traffic, their practical models, their measurements and simulations to make predictions and to plan telecommunication networks such as a telephone network or the Internet. These tools and basic knowledge help provide reliable service at lower cost. The field was created by the work of A. K. Erlang for circuit-switched networks but is applicable to packet-switched networks. The most notable difference between these sub-fields is that packet-switched data traffic is self-similar. This is a consequence of the calls being between computers, and not people. The crucial observation in traffic engineering is that in large systems the law of large numbers can be used to make the aggregate properties of a system over a long period of time much more predictable than the behaviour of individual parts of the system. Riferito al DiffServ significa: predire il traffico di un determinato BA e tarare il routing, le precedenze, gli scheduler, etc. in modo da ottenere la QoS voluta. T. Pecorella (DET) SGRtlc 05 - aa 2010/11 34 / 34