RETI DI CALCOLATORI II - UniNa STiDuEunina.stidue.net/Computer Networks 2/Materiale/Dispensa RCII...

RETI DI CALCOLATORI IIAnno 2007/2008 prof. G. Ventre

Questa dispensa è il frutto dello studio condotto durante il corso di Reti di Calcolatori II, tenuto dal prof. G. Ventre nell'anno 2007/08, presso l'università Federico II di Napoli.

I disegni, i grafici e le immagini utilizzate in questo testo sono proprietà dei rispettivi autori. Se si dovessero presentare violazioni del diritto di autore, si prega di segnalarlo tempestivamente tramite e-mail: [email protected] .

I contenuti della dispensa prendono spunto dalle slide utilizzate a lezione e sono il frutto dell'elaborazione degli appunti presi durante il corso, dello studio delle fonti segnalate a lezione e delle ricerche di approfondimento compiute.

Questa dispensa non è esaustiva, e molto probabilmente, in alcune sue parti non è del tutto corretta. Tuttavia, potrebbe essere un aiuto nello studio di una materia vasta e complessa come quella trattata.

Per maggiori informazioni sul docente del corso si rimanda al sito web: www.docenti.unina.it/giorgio.ventre .

Informazioni sull'autore della dispensa:Roberto Bifulco, [email protected] , www.robertobifulco.it.

mailto:[email protected]

http://www.robertobifulco.it/

mailto:[email protected]

http://www.docenti.unina.it/giorgio.ventre

Table of contents

Introduzione..........................................................................................................................................................................5

Capitolo INetworks evolution...............................................................................................................................................................6

I.1Communication models..............................................................................................................................................6I.1.1Circuit switching................................................................................................................................................6I.1.2Packet switching................................................................................................................................................7I.1.3Flow switching...................................................................................................................................................8

I.2A rapidly changing scenario.......................................................................................................................................8I.3Data and media taxonomy..........................................................................................................................................8

Capitolo IITechniques and architectures for QoS................................................................................................................................10

II.1QoS problems..........................................................................................................................................................10II.2Service Specification...............................................................................................................................................11II.3Traffic and Service Characterization.......................................................................................................................12

II.3.1Token Bucket..................................................................................................................................................13II.3.2Leaky Bucket..................................................................................................................................................13II.3.3Queue management........................................................................................................................................14II.3.4Scheduling......................................................................................................................................................14

II.3.4.1Scheduling policies................................................................................................................................15II.3.4.1.1GPS................................................................................................................................................16

II.4Parekh-Gallager Theorem.......................................................................................................................................17II.5QoS Architectures...................................................................................................................................................17

II.5.1Integrated Services (IntServ)..........................................................................................................................18II.5.1.1RSVP......................................................................................................................................................19II.5.1.2IntServ today..........................................................................................................................................19

II.5.2Differentiated Services (DiffServ)..................................................................................................................20II.5.2.1PHB: Expedited Forwarding..................................................................................................................20II.5.2.2PHB: Assured Forwarding.....................................................................................................................21

II.6QoS in Fast Interconnect.........................................................................................................................................21II.6.1Flow Control...................................................................................................................................................22

II.6.1.1Flow Control in IBA..............................................................................................................................22II.6.1.2Flow Control in ASI...............................................................................................................................22II.6.1.3Flow Control in Ethernet.......................................................................................................................22

II.6.2Congestion control..........................................................................................................................................22II.6.2.1Congestion Control in IBA....................................................................................................................22II.6.2.2Congestion Control in ASI.....................................................................................................................23

Capitolo IIIInter-domain routing with BGP..........................................................................................................................................24

III.1Intra-Domain Routing............................................................................................................................................25III.1.1Distance Vector.............................................................................................................................................26III.1.2Link State......................................................................................................................................................26

III.2Inter-domain routing..............................................................................................................................................26III.2.1Border Gateway Protocol (BGP)...................................................................................................................28

III.2.1.1BGP Messages......................................................................................................................................30III.2.1.1.1Messages' structure......................................................................................................................31

III.2.1.2BGP Example 1....................................................................................................................................33III.2.1.3Route preference...................................................................................................................................33III.2.1.4The internet organization......................................................................................................................35III.2.1.5BGP in large networks..........................................................................................................................35III.2.1.6Confederations......................................................................................................................................38

Reti di calcolatori II

III.2.1.7Route Reflectors...................................................................................................................................39III.2.1.8The dynamics of BGP...........................................................................................................................41III.2.1.9BGP routing tables................................................................................................................................41III.2.1.10The route selection process.................................................................................................................42

Capitolo IVAsynchronous transfer mode..............................................................................................................................................43

IV.1ATM architecture...................................................................................................................................................43IV.1.1ATM Switching.............................................................................................................................................46IV.1.2Payload type indicator and Cell Loss Priority..............................................................................................47IV.1.3Head Error Control........................................................................................................................................47

IV.2ATM Protocol Stack..............................................................................................................................................48IV.3ATM Addressing...................................................................................................................................................49IV.4ATM Quality of Service........................................................................................................................................49

IV.4.1Connection Admission Control.....................................................................................................................50IV.4.2Flow control..................................................................................................................................................50IV.4.3Service classes...............................................................................................................................................50

IV.5ATM Adaptation Layer.........................................................................................................................................51IV.5.1AAL 1...........................................................................................................................................................52IV.5.2AAL 2...........................................................................................................................................................52IV.5.3AAL 3/4........................................................................................................................................................53IV.5.4AAL 5...........................................................................................................................................................53

IV.6Call and Connection Control.................................................................................................................................54IV.7ATM in LAN.........................................................................................................................................................55

IV.7.1LANE Architecture.......................................................................................................................................55IV.8IP over ATM..........................................................................................................................................................56

Capitolo VMulti Protocol Label Switching ........................................................................................................................................57

V.1MPLS......................................................................................................................................................................58

Capitolo VITraffic Engineering.............................................................................................................................................................60

VI.1IP-based Traffic Engineering.................................................................................................................................60VI.2MPLS-based traffic engineering............................................................................................................................61

Capitolo VIISDH/SONET......................................................................................................................................................................64

VII.1SDH Frame...........................................................................................................................................................65VII.2Differeces between SONET and SDH.................................................................................................................65

Capitolo VIIIIP su reti ottiche..................................................................................................................................................................67

VIII.1DWDM................................................................................................................................................................67VIII.1.1Transparent optical network.......................................................................................................................68VIII.1.2Opaque Optical Network............................................................................................................................69VIII.1.3Translucent Optical Network.....................................................................................................................69

VIII.2Generalized Framing Procedure (GFP)...............................................................................................................69VIII.3Gigabit Ethernet (GbE).......................................................................................................................................70VIII.4IP-centric control of optical networks.................................................................................................................70

3


Capitolo IXNetwork Management........................................................................................................................................................73

IX.1Simple Network Management Protocol (SNMP)..................................................................................................75IX.1.1The impact of UDP.......................................................................................................................................78IX.1.2Sicurezza in SNMP.......................................................................................................................................78

IX.2Network management applications........................................................................................................................79IX.3Professional and Business Challanges...................................................................................................................79IX.4Service life-cycle...................................................................................................................................................80

IX.4.1Service Level Agreement..............................................................................................................................81IX.4.1.1SLA Parameter definition.....................................................................................................................82

IX.5 Provisioning level Agreement..............................................................................................................................83

Capitolo XNetwork Resiliency............................................................................................................................................................84

X.1Network recovery....................................................................................................................................................85X.2Recovery Mechanisms Control...............................................................................................................................86

Capitolo XINetwork security.................................................................................................................................................................88

XI.1Types of Attack......................................................................................................................................................88XI.1.1IP address spoofing.......................................................................................................................................88XI.1.2Host scanning................................................................................................................................................88XI.1.3System penetration........................................................................................................................................89XI.1.4Denial of Service...........................................................................................................................................89XI.1.5Malware........................................................................................................................................................89

XI.2Firewall..................................................................................................................................................................90XI.3NAT.......................................................................................................................................................................92XI.4Intrusion Prevention Systems................................................................................................................................92

4


IntroduzioneNegli ultimi anni l'economia mondiale ha visto l'affermazione decisa di un prodotto rispetto agli altri, questo prodotto è la creazione e la distribuzione dell'informazione e, verosimilmente, tale andamento sarà sempre più accentuato in futuro.

I fattori di questo fenomeno sono da ricercarsi nello sviluppo della tecnologia, in particolare informatica, e quindi nella variazione della rappresentazione dell'informazione. Gli ultimi decenni hanno visto infatti una rapida “digitalizzazione” delle più disparate informazioni, con i conseguenti benefici legati alla possibilità di elaborare l'informazione tramite computer, di replicarla virtualmente all'infinito, di spostarla agevolmente e rapidamente. In questi benefici è concentrato il cuore della “Digital Revolution”, infatti, l'informazione non deve essere più scambiata sotto forma di “atomi” (CD, libri, ecc.) ma è possibile rappresentare l'informazione tramite bit e poi spostare questi agevolmente tramite una rete.

Questi nuovi scenari introducono quindi nuove necessità, fra cui rientrano tecniche per rappresentare tutti i tipi di informazione come bit, e meccanismi per spostare questi bit ovunque, a basso costo, garantendo una certa qualità del servizio (Quality of service).

Introduzione 5

Reti di calcolatori II Capitolo I

Capitolo INetworks evolution

Le odierne reti di comunicazione sono basate su differenti meccanismi di switching, dove per switching si intende la capacità degli elementi della rete di instradare dati. Lo scopo principale di una rete è quindi realizzare un meccanismo di switching che permetta di instradare informazioni da una o più sorgenti verso una o più destinazioni.

L'evoluzione tecnologica ha chiaramente toccato anche il mondo delle reti, che nel corso degli anni hanno visto il succedersi di diversi modelli di switching, legati alla necessità di fornire diversi servizi di comunicazione per diverse tipologie di traffico.

I.1 Communication modelsIl più semplice modello di comunicazione è l'interconnessione diretta, in cui le informazioni fluiscono dalla sorgente alla destinazione senza intermediari. Un modello del genere impone che esista un media fra le due entità coinvolte nella comunicazione, attraverso cui vengono trasferite le informazioni. Quando non è possibile agire in questo modo, è necessario inserire una entità intermedia che sia in grado di instradare i dati seguendo un modello di switching.

I.1.1 Circuit switchingLa commutazione di circuito è il modello di switching tradizionalmente adoperato nella telefonia, dove le entità terminali sono i telefoni e gli exchange sono le entità intermedie. La voce è l'informazione trasmessa fra i terminali, rappresentata da un segnale elettrico modulato analogicamente. La comunicazione è dunque lo scambio continuo di segnali vocali fra due entità paritetiche.

Il modello di switching consiste dunque nella creazione temporanea di un media (cavi in rame, canali a microonde, fibre ottiche), per la trasmissione del segnale vocale, dedicato soltanto a quella comunicazione. La creazione del media è l'operazione che spetta all'exchange che connette fisicamente le due parti di media che portano alle entità coinvolte nella comunicazione (Figura1).

I terminali in questo caso sono decisamente semplici, il loro unico compito è la conversione della voce nel segnale da trasferire attraverso il media.

Networks evolution 6

Figura1: Circuit switching


Anche le entità intermedie hanno il solo compito di configurare un percorso fisico fra la sorgente e la destinazione in un modo che sia del tutto trasparente ad entrambe le parti ed anche all'informazione trasferita, che non deve subire alcuna elaborazione.

Il principale problema di questa soluzione è la necessità di avere un canale dedicato per ogni singola comunicazione. Questa caratteristica non è un problema nel caso di una comunicazione telefonica, ma per altre tipologie di comunicazione, come quella fra computer, si avrebbe un eccessivo “spreco” delle risorse. Molto spesso nelle comunicazioni di questo tipo per molto tempo non c'è necessità di inviare informazioni e, dunque, il flusso dati è di tipo “burst”, in altre parole è discontinuo. Se consideriamo inoltre che su di un computer “vivono” in contemporanea più applicazioni, perché queste comunichino con altre applicazioni su altri computer, dovrebbe esistere un canale dedicato per ciascuna di queste.

I.1.2 Packet switchingCome detto in precedenza, a differenza della comunicazione telefonica in cui si ha un modello “domanda/risposta”, in una comunicazione fra computer il modello segue un approccio del tipo: “domanda/elaborazione/risposta/elaborazione”. In questo caso il flusso di comunicazione non è più continuo ma discreto. Poiché un intero canale fisico verrebbe dunque sfruttato solo in parte, è conveniente pensare ad un modello di switching in cui il media su cui passa la comunicazione sia condiviso piuttosto che dedicato. Un modello del genere potrebbe dunque assomigliare al modello di scambio informazioni postale, in cui le informazioni sono suddivise in atomi (le lettere) che sono poi veicolate attraverso punti di dispaccio che ne gestiscono la corretta consegna (Figura 2).

Questo approccio può essere adoperato a patto di rispettare alcune condizioni per gestire la corretta consegna degli atomi. Tali condizioni impongono che le informazioni siano atomiche e discrete, che ogni “pezzo” d'informazione sia identificabile e che l'instradamento venga eseguito separatamente per ogni singolo pezzo. Per rispondere a questi requisiti, il modello è necessariamente più complesso e come tale, richiede una maggiore complessità anche nelle entità intermedie della rete (nodi). Ogni nodo deve essere infatti in grado di conservare i pezzi di informazione che transitano (esattamente come un dispaccio postale) e di prendere decisioni autonome, ma con un approccio coordinato, per configurare il suo comportamento d'instradamento. Questo modello è tipicamente chiamato store&forward.

Il modello di packet switching fa uso dello statistical multiplexing, in altre parole, pacchetti che provengono da differenti flussi arrivano all'entità intermedia che li seleziona a turno uno per volta per inviarli sul canale di uscita. I pacchetti in attesa vengono conservati in un buffer (store) il cui overflow viene anche detto congestion della rete.


Figura 2: Packet switching


I.1.3 Flow switchingPer alcune applicazioni i computer devono comunque scambiare flussi continui di informazione, ad esempio nelle applicazioni multimediali. In questi casi è conveniente introdurre un concetto di “stream” (flusso) nella rete, in modo che i “pezzi” che compongono l'informazione vengano trattati tutti allo stesso modo dalla rete.

Questo approccio è realizzabile poiché l'informazione continua ad essere divisa in atomi, è però necessario introdurre meccanismi per trattare aggregati di atomi d'informazione e decidere l'instradamento in base al flusso. Questo aggiunge una certa complessità negli elementi intermedi della rete, che devono gestire dati che identifichino i flussi e ne conservino le informazioni necessarie all'instradamento, inoltre, anche la coordinazione fra questi elementi deve essere più stretta rispetto al packet switching, poiché è necessario impostare e successivamente mantenere un percorso per il flusso dati.

I.2 A rapidly changing scenarioNegli anni le tecnologie informatiche e di rete sono cresciute notevolmente, fornendo nuovi mezzi per lo sviluppo delle reti e conseguentemente delle applicazioni che le sfruttano. Allo stesso tempo sono sempre più diffusi dispositivi in grado di integrare più servizi complessi, come la fonia, il video, ecc. In concomitanza, i monopoli nelle telecomunicazioni sono andati svanendo, incrementando la competizione sul mercato.

In questo contesto è nata la necessità per le aziende di telecomunicazioni di creare un'unica grande infrastruttura globale che supportasse tutte i tipi di applicazione. La scelta in questo caso poteva essere fatta fra un numero notevole di tecnologie, alcune delle quali teoricamente perfette dal punto di vista delle prestazioni e dei servizi, ma all'atto pratico troppo complesse e costose. La scelta finale si è dunque orientata verso Internet, che anche se con limitazioni più o meno forti, è risultata la scelta più semplice ed economica. Al giorno d'oggi non è difficile individuare aziende che agiscono come Triple Player, ossia che utilizzano un'unica infrastruttura per gestire il traffico video, audio e dati.

I.3 Data and media taxonomyUn aspetto fondamentale che caratterizza un'informazione è la semantica che la accompagna, che generalmente caratterizza maggiormente il modo in cui tale informazione va trattata. E' infatti possibile immaginare diversi modi di trattare l'informazione a seconda del suo significato, basti pensare alla differenza fra un bit appartenente ad un messaggio e-mail ed uno appartenente ad un flusso video. Chiaramente questi due bit hanno bisogno di trattamenti differenti, e, quindi, hanno richieste di requisiti differenti per la rete. Possiamo identificare una serie di proprietà che definiscono la Quality of the information:

➔ Correctness: è una misura del grado accettabile di corruzione dell'informazione, ossia di quanto l'informazione può essere non fedele all'originale rimanendo utilizzabile. Solitamente si identificano livelli di correttezza come ad esempio:

○ Hard Correctness: tipica di applicazioni quali le transazioni commerciali, applicazioni di controllo e la segnalazione, applicazioni computazionali distribuite.

○ Soft Correctness: per applicazioni grafiche, video, e-mail ecc.



➔ Order: è una proprietà legata alla possibilità di accettare sequenze di dati nell'elaborazione di un gruppo di informazioni. Anche in questo caso si possono individuare diversi gradi di ordinamento:

○ Absolute order: per giochi distribuiti, CIM, network stock exchange;

○ Relative order: per applicazioni basate sul modello domanda-risposta.

➔ Timeliness: è una misura legata alla soddisfazione di un requisito di quando deve avvenire un evento, o più eventi:

○ Asynchronous: nessun requisito;

○ Relative time: requisiti solo nel tempo relativo di occorrenza di una sequenza di eventi;

○ Real time: specifica dettagliata del tempo assoluto di occorrenza di un evento entro limiti più o meno stretti.

➔ Consistency: è una misura del livello di coerenza fra diverse copie della stessa informazione, è solitamente una funzione del tempo;

➔ Privacy: una proprietà legata al livello di apertura della condivisione dell'informazione, è solitamente una funzione dello spazio;

➔ Robustness: è la capacità che ha l'informazione di sopravvivere a guasti durante la sua elaborazione o scambio, è una funzione sia del tempo che dello spazio.


Reti di calcolatori II Capitolo II

Capitolo IITechniques and architectures for QoS

Per supportare un raggio più ampio di applicazioni, quali le applicazioni multimediali, real time, ecc. è necessario avere una rete globale che offra un servizio migliore rispetto al tradizionale best effort. Inoltre, c'è una richiesta da parte degli ISP di sviluppare nuovi modelli economicamente sostenibili con corrispondenti servizi personalizzati di networking. Questo perché attualmente per garantire un certo servizio l'unica soluzione è fornire una quantità di risorse sempre sovradimensionata, in modo da evitare congestione e rallentamenti.

Per supportare queste innovazioni è necessario introdurre la cosiddetta Quality of Service, in altre parole con QoS si intende che la rete garantisce ad una applicazione un livello di prestazioni sufficiente al suo corretto funzionamento.

Per definire la QoS si adoperano parametri generici, quali ad esempio la larghezza di banda, il delay, la percentuale di pacchetti persi, inoltre si adoperano anche parametri specifici per la particolare applicazione. Chiaramente ciascuno di questi parametri può essere misurato secondo una diversa granularità: micro flow, aggregate flow, population. La QoS è considerata migliore se può essere specificata a granularità fine, con un gran numero di parametri.

Sostanzialmente la QoS si muove su di una scala che da un lato ha il best effort, ossia assenza di QoS e dall'altro la linea dedicata.

Figure 1: QoS spectrum

II.1 QoS problemsSe consideriamo la rete best effort, lo schedulatore nei router seleziona i pacchetti secondo una logica FIFO, in cui le prestazioni assegnate ad un flusso sono convolute con l'arrivo di pacchetti dagli altri flussi (Questo perché si allunga la coda nello schedulatore e i pacchetti permangono più a lungo in tale coda). Da questo risulta chiaro che non si può ottenere QoS se si ha un accesso libero per tutti e che si rende necessario definire una politica di scheduling che tenga conto delle diverse priorità di trattamento dei pacchetti, ossia che isoli il trattamento di alcuni flussi dal traffico dal restante traffico.

Sostanzialmente il problema con cui ci si scontra è che non si può violare la legge della conservazione di Kleinrock, ossia che il lavoro fornito da una macchina è sempre costante, dunque,

Techniques and architectures for QoS 10

Best Effort Leased Line


per trattare “meglio” qualcuno, è necessario trattare “peggio” qualcun altro. Un approccio possibile è quello, ad esempio, di riservare un certo numero di risorse per i servizi premium. Per queste ragioni si comprende come un meccanismo di routing standard non può essere utilizzato, ma si rende necessario quanto meno l'utilizzo di protocolli che garantiscano una gestione distribuita delle risorse.

Ci sono due differenti piani su cui agire per garantire la QoS:

➢ Control Plane: Si opera su meccanismi di signaling, controlli di ammissione alla rete e contratti di accesso, traffic engineering;

➢ Data Plane: Sono i dati in questo caso ad essere trattati per garantire la QoS, si adoperano dunque meccanismi di condizionamento e classificazione del traffico, scheduling, gestione delle code.

Per fornire la QoS si devono considerare una serie di aspetti:

Specifica del servizio premium, dato che su di una connessione dati non è possibile fare previsioni sulla quantità e sul tipo di traffico (service level agreement);

Definizione delle risorse necessarie(adminssion control, provisioning);

Garantire che le risorse riservate permettano comunque un utilizzo della rete nel migliore dei modi, permettendo dunque load balancing, gestione flessibile del traffico dal punto di vista degli aggregati e dei percorsi (QoS routing, traffic engineering);

Gestire le risorse in ambito distribuito (Signaling, provisioning, policy);

Gestione del traffico all'interno della rete (Traffic shaping, classification, scheduling);

Valutazione della qualità, dell'appartenenza e della tariffazione dei servizi (Network management, accounting, billing, pricing).

A questi aspetti prettamente legati alla QoS “pura” si aggiungono problemi di aggiornamento delle attuali reti perché supportino la QoS. Per questa problematica si adopera l'approccio di disaccoppiare l'evoluzione degli end-system da quella della rete.

Si sviluppano dunque protocolli end-to-end (RTP, H.323, ecc.) per seguire la crescita delle applicazioni multimediali, assumendo che sfruttino un servizio sia best-effort che better-than-best-effort. Allo stesso tempo si lavora per realizzare protocolli di rete (IntServ, DiffServ, RSVP, MPLS, ecc.) per supportare better-than-best-effort a livello di rete.

II.2 Service SpecificationVisto che non è possibile prevedere a priori il traffico dati, poiché è composto da componenti eterogenee e variabili, è necessario fornire una specifica del servizio che si richiede alla rete sulla base di alcuni parametri:

Loss: probabilità che un pacchetto del flusso vada perso;

Delay: il tempo impiegato da un pacchetto per andare dalla sorgente alla destinazione;

Delay jitter: la massima differenza fra i ritardi subiti fra due pacchetti del flusso;

Bandwidth: la massima velocità a cui la sorgente può inviare dati.



Sulla base di questi parametri l'end system e la rete stabiliscono un contratto, il Service Level Agreement, in cui entrambe le parti si impegnano a dare delle garanzie. Chiaramente sono previsti anche meccanismi per verificare che il contratto, e dunque le garanzie, siano rispettati. Nel seguito sono riportati alcuni esempi di contratto:

➔ Hard Real Time: servizio garantito

○ Contratto:

■ Dalla rete al client: è garantito un limite superiore deterministico al delay per ogni pacchetto della sessione;

■ Dal client alla rete: si garantisce che nella sessione non viene inviato più traffico di quanto specificato;

○ Supporto algoritmico:

■ Controllo di ammissione basato sull'analisi del caso peggiore;

■ Classificazione e scheduling del traffico per flusso a livello dei router;

➔ Soft Real Time: servizio a carico controllato

○ Contratto:

■ Dalla rete al client: è garantito un livello di performance simile a quello di una rete best-effort con poco traffico;

■ Dal client alla rete: si garantisce che nella sessione non viene inviato più traffico di quanto specificato;

○ Supporto algoritmico:

■ Controllo di ammissione basato sulla misurazione di aggregati;

■ Scheduling per aggregati.

II.3 Traffic and Service CharacterizationSi possono adoperare due informazioni per quantificare in termini di risorse un servizio:

Il tipo di traffico da trattare;

Il servizio fornito dal router, ad esempio in termini di risorse riservate in ciascun router.

Per controllare il traffico inviato alla rete, e per renderlo conforme ad un modello noto, è possibile caratterizzarne l'andamento nei terminali di accesso alla rete. In altre parole, qualsiasi client acceda alla rete, lo fa attraverso una sorta di filtro, che adatta il traffico generato ad un modello specifico.

Questo approccio è necessario poiché il traffico dati non ha un andamento prevedibile come quello telefonico.

In Figure 2 sono rappresentati i modelli di traffico telefonico e dati, dove si vede chiaramente che l'andamento è ben diverso. Questo è dovuto anche al fatto che il traffico dati è self-similar, in altre parole, quando si sommano più flussi dati, la curva di traffico mantiene la stessa forma.



Figure 2: Traffic model

II.3.1 Token BucketUno dei meccanismi di traffic characterization è il Token Bucket. Si suppone che ogni flusso abbia associato una riserva di token, che rappresentano la possibilità di poter trasmettere un bit. Ad ogni bit trasmesso si consuma un token, quando questi sono finiti, non si può più trasmettere. I token sono rigenerati ad una frequenza fissa, quindi, quando tutti i token sono stati consumati, si potrà trasmettere ad una velocità massima data dalla velocità di rigenerazione dei token.

E' importante notare che, se la riserva di token non si svuota del tutto, il Token Bucket non modifica il segnale in ingresso, poiché anche se la velocità di trasmissione è più grande della velocità di rigenerazione dei token, fin quando la riserva di token non è esaurita, si può trasmettere a tale velocità. Con questo sistema si sta definendo sostanzialmente un inviluppo del segnale iniziale. In questo modo, si descrive il segnale in ingresso alla rete, senza incidere eccessivamente sulla sua forma iniziale. Quello che sostanzialmente viene caratterizzato nel suo worst case è il traffico medio, dato dalla velocità di rigenerazione dei token, e il massimo burst di dati, dato dalla profondità della riserva di token.

Se ben dimensionato, il Token Bucket garantisce che non si accumulino ritardi.

II.3.2 Leaky BucketIl Leaky Bucket si può associare all'idea di un imbuto. Il traffico viene raccolto nel Leaky Bucket che lo rilascia ad una velocità (bitrate) costante. A differenza del Token Bucket, con questo meccanismo il traffico accumula ritardi se la sua velocità di arrivo è maggiore di quella di uscita dal Bucket. Inoltre, per lo stesso motivo, il segnale in ingresso viene modificato, assumendo un'unica forma che è quella data dalla velocità di uscita dei dati dal Bucket.


Figure 3: Token Bucket

Traffico telefonico Traffico dati

tempo


II.3.3 Queue managementDal lato dei router, è possibile gestire la QoS introducendo una gerarchia fra i pacchetti. A seconda della particolare gerarchia, i pacchetti vengono assegnati ad una coda del router. Chiaramente, la classe gerarchica più importante (quella il cui servizio costa di più!) andrà verosimilmente nella coda più breve.

Figure 4: Queue management con code separate

Quello che si fa stabilendo delle code separate è definire delle classi di traffico. E' necessario stabilire un meccanismo per capire a quale classe appartiene un pacchetto, ad esempio è possibile dedicare un campo dell'header del pacchetto. La gestione delle code può poi essere fatta secondo vari schemi, ad esempio, per priorità, round robin, ecc.

E' possibile immaginare anche uno schema per la protezione dalla perdita dei pacchetti. Supponiamo di voler proteggere del traffico, in modo che non vengano scartati i pacchetti appartenenti a quel flusso in caso di congestione della rete. Quello che andiamo a fare è sostanzialmente definire un meccanismo di cancellazione selettiva dei pacchetti, quando la coda del router è piena.

Si potrebbero marcare i pacchetti con un flag, che ne indica l'appartenenza o meno ad un flusso protetto, inoltre, si stabilisce una soglia nella coda del router oltre la quale i pacchetti che non hanno il flag impostato vengono cancellati. Dopo una seconda soglia di emergenza, i pacchetti vengono tutti cancellati, per evitare il collasso della rete.

Nell'esempio di Figure 5 i pacchetti con il flag settato sono rappresentati in rosso:

Figure 5: Queue management with flagged packets

II.3.4 SchedulingPer trattare il problema dello scheduling in una rete che supporta la QoS è necessario innanzitutto osservare la comune architettura di un router. In Figure 6 è mostrato uno schema esemplificativo:


$$$$$$

Traffic Classes

Drop only blue packet

Drop blue and red packet


Figure 6: Router schematic architecture

I moduli di ingresso (indicati in giallo) trasformano il formato in ingresso in modo che sia trattabile dalla Fabric. Questa viene impostata dall'algoritmo di instradamento ed ha il compito di trasportare ogni byte verso l'appropriato modulo d'uscita. Il modulo di uscita contiene i meccanismi di controllo del servizio, inserendo questi meccanismi in questo punto, si ha una stima più precisa del delay relativo dei pacchetti.

II.3.4.1 Scheduling policiesE' necessario stabile una policy sul trattamento delle code in ingresso allo scheduler. In particolare, si deve decidere come e quando prendere i pacchetti da una determinata coda. Uno schema di principio potrebbe basarsi sul prendere il prossimo pacchetto dalla coda di più alta priorità che è non vuota (L'attribuzione ad una coda potrebbe essere basata sia su di un marking specifico del pacchetto, sia ad esempio sul numero di porta destinazione).

Questo principio di base può essere applicato in diversi modi, ad esempio è possibile stabilire se si deve interrompere il lavoro di invio di un pacchetto se in quel momento ne arriva un altro di priorità maggiore. Con quest'ultimo meccanismo, che viene indicato come preemptive, si ha un notevole incremento di complessità nella gestione dell'algoritmo. In Figure 7 è presentato un esempio di scheduling per priorità non-preemptive.

Una soluzione alternativa prevede l'utilizzo di uno scheduling round robin, ossia, lo schedulatore esamina una per volta le code di priorità e seleziona un pacchetto per ogni coda che non è vuota. Pero' questo meccanismo non garantisce alcuna QoS se non si adotta una queue discipline, in altre parole se le code sono tutte piene allo stesso modo non si ha QoS, se invece si adopera un


Figure 7: Scheduling per priorità non-preemptive

FABRIC

Flow 1Flow 2Flow 3

Buffer management

SchedulerClassifier


meccanismo come quello presentato nei paragrafi precedenti in cui le code a maggior priorità sono più corte, allora la QoS è rispettata. In Figure 8 è riportato l'esempio precedente ma adottando uno scheduling round robin.

Lo scheduling round robin presenta una ulteriore problematica. Fino ad ora si è dato per scontato che i pacchetti fossero tutti della stessa dimensione, ma se così non fosse, i pacchetti di dimensione più grande sarebbero avvantaggiati, poiché occuperebbero maggior tempo del router a svantaggio dei pacchetti più piccoli.

Una ulteriore decisione è se adottare un algoritmo work conserving. Questi algoritmi fanno sempre lavorare lo schedulatore finché c'è qualcosa in una delle code. Una scelta per un algoritmo non work conserving potrebbe essere dettata dalla necessità di contenere il jitter per pacchetti di priorità più alta. In realtà attualmente questa è un'ipotesi non verosimile e quindi le reti adoperano sempre algoritmi work conserving.

II.3.4.1.1 GPSDa quanto detto fin è possibile delineare uno schema ideale di schedulatore che garantisca indipendentemente dall'algoritmo utilizzato massima precisione ed equità. Tale schedulatore dovrebbe lavorare sull'atomo minimo di informazione, ossia sul bit. Chiaramente questo non è possibile poiché il singolo bit non porta informazioni sul “chi è” e “dove va”. Questo schedulatore prende il nome di GPS.

Un esempio di gestione dei pacchetti (bit) con GPS in modo equo è basato sull'utilizzo della seguente formula per il calcolo del numero di bit che devono passare per ogni coda (in caso di congestione del link): ∑ minr i , f x wi=C dove con r si indica il numero di bit in coda nella coda i, con w il peso della coda (in base alla priorità assegnatale), C è il traffico massimo che può attraversare il link, f è il parametro che viene calcolato in base alla formula per rispettare gli altri vincoli.

Il GPS ha un comportamento simile a quello di un sistema di fluidi, per renderlo applicabile dobbiamo però approssimarlo per farlo funzionare con i pacchetti.

Assumendo dunque che si adoperi un sistema non-preemptive, in altre parole in un dato istante si seleziona un pacchetto assumendo che non ci siano arrivi futuri, si adopera un algoritmo che seleziona sempre il pacchetto più breve. In questo modo sono sempre favoriti i pacchetti piccoli rispetto a quelli più grandi, tuttavia, osservando i dati reali, si può facilmente vedere come i pacchetti più piccoli sono solitamente quelli che appartengono alle applicazioni che necessitano di essere “trattate meglio”.

L'approccio utilizzato per garantire l'accodamento equo (fair queuing) è quello di servire i pacchetti nell'ordine in cui verrebbe completata la loro trasmissione in un sistema di flussi fluidi. L'astrazione adoperata è di considerare il link una risorsa da condividere in contemporanea fra i pacchetti presenti in coda. Supponendo che i pacchetti presenti siano 3, il link verrebbe diviso in 3 parti uguali, ciascuna dedicata a contenere i bit di un pacchetto. Quando tutti i bit di un pacchetto sono esauriti, viene fissato il tempo di fine per quel pacchetto. A questo punto il link viene diviso fra i rimanenti 2 pacchetti in coda. Si stabiliscono cosi' anche gli altri due tempi di fine. Terminato questo procedimento di astrazione della coda, i pacchetti sono poi trasmessi nell'ordine dei tempi di


Figure 8: Scheduling round robin


fine (Figure 9).

Una variante dell'algoritmo è il Weighted Fair Queuing (WFQ) che assegna un peso al pacchetto (in base alla sua priorità). Questa variante non fa altro che allargare lo spazio di link destinato ad un pacchetto quando si crea l'astrazione del sistema di fluidi. Sostanzialmente questo permette al pacchetto di avere un tempo di fine più basso.

L'utilizzo del FQ garantisce a tutti la stessa banda, ottiene dunque un effetto simile a quello che si ottiene quando tutte le connessione di una linea fanno uso di trasporto su TCP (che usa meccanismi di autoregolamentazione). Il problema è che non può garantire le particolari esigenze di un singolo.

In sostanza FQ non elimina la congestione della rete ma aiuta a gestirla. Non va tuttavia dimenticato che in caso di congestione si deve comunque stabilire come prendere una decisione su quali pacchetti eliminare.

II.4 Parekh-Gallager TheoremUn interessante teorema, il Parekh-Gallager theorem, ha dimostrato che è possibile definire un limite superiore al delay fra due entità della rete sotto le seguenti limitazioni:

I router adoperano un meccanismo WFQ;

Il traffico in ingresso alla rete è regolato da dei Leaky Bucket;

Si conosce il più largo pacchetto nella rete.

In realtà il risultato può essere generalizzato per una qualsiasi variante del WFQ e si può immaginare anche l'utilizzo di un diverso sistema di caratterizzazione del traffico in ingresso, per quanto questo comporti un aumento nella complessità del calcolo. Il risultato è chiaramente molto interessante perché formalizza un risultato fondamentale dal punto di vista della fattibilità di applicazioni che richiedono un certo livello di qualità del servizio come quelle real time in una rete del genere.

II.5 QoS ArchitecturesSono due gli approcci possibili per garantire la QoS nella rete:

➢ Soluzione Stateless: i router non mantengono informazioni a grana fine sul traffico che li attraversa. Questo rende il sistema più scalabile e robusto, ma fornisce servizi deboli.

➢ Soluzione Statefull: i router mantengono lo stato per ogni flusso. In questo caso i servizi sono garantiti, cosi' come la protezione e un differenziazione a grana fine. Chiaramente una soluzione simile è meno scalabile poiché aumenta sensibilmente la complessità, meno


Figure 9: Astrazione del canale come sistema di fluidi - Ordinamento reale dei pacchetti


robusta perché se un router va in crash perde le informazioni sui flussi che lo attraversano e quindi tali flussi vanno persi.

Nel seguito si esaminano le soluzioni proposte, che adoperano uno di questi due approcci.

II.5.1 Integrated Services (IntServ)IntServ è una architettura stateful per introdurre la QoS in reti IP. IntServ definisce una serie di aspetti per ottenere la QoS:

➔ Classi di servizio

➔ Admission Control

➔ Resource reservation

In breve, quello che IntServ fa è classificare in 3 classi di servizio un flusso dati: Guaranteed Service, per applicazioni che necessitano di prestazioni real time, Controlled Service, per applicazioni che richiedono le prestazioni simili a quelle di una rete best effort non carica, e best effort per tutto il resto. La classe di appartenenza con le specifiche richieste alla rete è dichiarata all'inizio dall'applicazione che intende aprire quel flusso dati.

Dopo aver ottenuto la richiesta di apertura del flusso e le sue richieste in termini di risorse, la rete stabilisce se può fornire il servizio richiesto, garantendo sia che il servizio sia conforme alla specifica richiesta, sia che l'aggiunta del servizio non comporti un peggioramento dei servizi già forniti.

Infine, se il servizio può essere fornito dalla rete, si avvia una procedura che riserva le risorse necessarie a fornire tale servizio.

Nei paragrafi precedenti abbiamo visto come può essere specificata la richiesta di una applicazione per un servizio dalla rete tramite i Service Level Agreement, in IntServ il SLA viene definito tramite due specifiche:

T-Spec: definisce le caratteristiche del traffico legato a quel flusso;

R-Spec: definisce la QoS richiesta per quel flusso.

Mentre la R-Spec è di facile creazione, poiché non fa altro che richiedere il livello di qualità del servizio specificando una classe di appartenenza ed eventualmente dei parametri che limitano il delay (per Guaranteed Service), si ha qualche difficoltà in più a descrivere la T-Spec. Solitamente per farlo si adoperano meccanismi come quelli che abbiamo visto nei precedenti paragrafi, per la caratterizzazione del traffico, quali il Token Bucket.L'admission control è un problema non di poco conto. Il suo compito principale è stabilire se la rete ha adeguate risorse per fornire il servizio richiesto, e se ciò non fosse vero, rifiutare l'accesso a quel servizio. Il problema nasce nella valutazione delle risorse della rete. Meccanismi quali i fair queuing, se adoperati su tutti i router, rendono questo problema molto più semplice.

La procedura di resource reservation prevede l'adozione di un protocollo di signaling che si occupi di “perlustrare” la rete per riservare le risorse necessarie a fornire il servizio. Il protocollo che risolve questo problema in IntServ è RSVP.



II.5.1.1 RSVPRSVP è un protocollo per la resource reservation che cerca di mantenere la robustezza tipica delle reti non orientate alla connessione, mantenendo tuttavia le caratteristiche di creazione e mantenimento di una connessione fra due punti. Tale risultato è ottenuto adoperando un concetto di soft state presso i router: ogni router mantiene le informazioni su di un dato flusso per un certo periodo di tempo e le cancella solo quando queste non sono rinnovate. Quindi con RSVP devono essere mandati periodicamente messaggi che confermano la presenza della connessione.

La prenotazione delle risorse avviene da parte del destinatario della comunicazione, seguendo dunque un modello receiver-oriented. Questo approccio permette di definire specifiche di qualità del servizio diverse per ogni destinatario (ricordiamo che la specifica viene fatta tramite le R-Spec), anche se il flusso dati è lo stesso (ad esempio in caso di multicast). Chiaramente, per effettuare la prenotazione delle risorse, il destinatario deve anche conoscere la T-Spec che è una conoscenza posseduta dal mittente del flusso dati. RSVP opera dunque nel seguente modo:

1. Il mittente del flusso dati invia un messaggio PATH che contiene:

○ La T-Spec;

○ Un'informazione sui router/end che ha attraversato questo messaggio (in modo da poter ricostruire il percorso seguito dal messaggio);

2. Ciascun router che riceve il messaggio aggiorna l'informazione legata al percorso seguito dal messaggio;

3. Quando il destinatario riceve il messaggio PATH, esamina il percorso seguito da tale messaggio e invia in risposta un messaggio RESV che contiene la R-Spec e che richiede di riservare le risorse presso i router;

4. Ciascun router che riceve il messaggio RESV valuta se è possibile soddisfare la richiesta di servizio (T-Spec, R-Spec), se la risposta è affermativa, invia al successivo router il messaggio RESV, altrimenti invia un messaggio di errore al destinatario che ha fatto la richiesta.

Da notare che tutto il traffico di signaling fatto da RSVP viaggia sul tradizionale IP, è dunque sottoposto a variazioni del percorso “casuali”. Il soft state permette di evitare una situazione in cui si crea una connessione per un percorso ma poi se ne utilizza un altro.

In particolare, poiché i router si scambiano con una certa frequenza i messaggi PATH e RESV (in risposta al PATH), quando questi messaggi non sono più ricevuti la connessione è considerata automaticamente chiusa dal router. Allo stesso tempo, quando un router riceve un messaggio PATH inatteso, provvede ad avviare un nuovo tentativo di connessione. Se questo tentativo non andasse a buon fine, la connessione verrebbe irrimediabilmente chiusa.

E' importante notare come questo approccio richieda la gestione di uno stato per ogni flusso in ogni router del percorso.

II.5.1.2 IntServ todayAttualmente, per quanto i meccanismi di IntServ siano affermati nell'implementazione dei router, questa architettura non è adoperata nelle reti pubbliche. Il problema principale è che la soluzione stateful appesantisce sensibilmente il centro della rete, dove i flussi dati sono innumerevoli, inoltre, non si è riusciti a sviluppare un modello per vendere un servizio di QoS del genere.



II.5.2 Differentiated Services (DiffServ)Per risolvere i problemi principali legati a IntServ, ossia la necessità di mantenere uno stato per ogni flusso nei router e le problematiche legate al protocollo di signaling, è stato introdotto questo ulteriore modello: DiffServ.

L'approccio adoperato è quello di introdurre la QoS gradualmente nelle reti IP. In particolare, con DiffServ non è necessario alcun protocollo di signaling e per individuare la classe di traffico cui appartiene un determinato pacchetto si è abbandonata l'idea di gestire flussi a favore della gestione di aggregati di flussi. Per semplificare l'identificazione dell'aggregato cui appartiene un pacchetto, si è deciso che ad indicare a quale aggregato appartiene sia il pacchetto stesso. Sempre per non incidere sull'attuale architettura di rete, per questa informazione è stato ridefinito il valore del campo TOS dell'attuale header IP, che non è stato mai usato nella sua accezione originaria. Tale campo prende adesso il nome di DSCP (Differentiated Service Code Point) ed indica a quale aggregato (classe di servizio) appartiene il pacchetto.

Quando un router che supporta DiffServ ottiene un pacchetto provvede dunque a controllare il campo DSCP dell'header per verificare come trattare tale pacchetto.

Chiaramente va chiarito chi provvede a impostare il campo DSCP del pacchetto. A tale scopo nell'architettura DiffServ si prevedono due tipi di router:

Edge Router: sono i router di ingresso ad una rete che gestisce la QoS tramite DiffServ. Questi router hanno il compito di negoziare con i loro client il servizio che verrà fornito ai pacchetti da loro generati all'interno della rete con DiffServ. Questa negoziazione può avvenire manualmente ed una tantum, ad esempio se un ISP fornisce ad un cliente un servizio di alta qualità per tutto il traffico da lui generato, oppure può essere gestita per via automatica tramite un opportuno protocollo di signaling. Una volta stabilito il servizio che devono ottenere i pacchetti, il router provvede ad impostare il loro campo DSCP;

Interior Router: sono i router interni alla rete che adopera DiffServ. Questi router devono semplicemente controllare il campo DSCP dei pacchetti in transito e trattarli di conseguenza.

DiffServ presenta dunque un modello estremamente semplice nella gestione dell'interno della rete, poiché gli interior router sono praticamente stateless e devono semplicemente gestire opportunamente i pacchetti per fornire la QoS opportuna.

Quale gestione applicare al pacchetto, come detto, è definito dal campo DSCP, il meccanismo di gestione vero e proprio viene detto per-hop behavior (PHB). Ad ogni valore DSCP corrisponde un particolare PHB che deve essere applicato al pacchetto. La definizione PHB è fatta in base a due specifiche expedited forwarding (EF) e assured forwarding (AF). Ad ogni pacchetto vengono impostati i comportamenti PHB, combinando le specifiche EF ed AF, tramite l'opportuno settaggio del DSCP.

II.5.2.1 PHB: Expedited ForwardingEF è un servizio molto semplice: il pacchetto va servito il prima possibile, in modo da garantire il minimo dealy e loss.

Chiaramente, perché sia garantito tale servizio, è necessario che ci sia un controllo sul traffico EF ammesso nella rete, in caso contrario si avrebbe la rete saturata di traffico prioritario, causando, di



fatto, l'assenza di un trattamento particolareggiato. Una scelta conservativa in questo ambito è accettare in ingresso una quantità di traffico prioritario pari a quella sostenibile dal link meno capace della rete. Gli interior router potrebbero usare un meccanismo di WFQ assegnando ai pacchetti prioritari una coda opportunamente pesata, in modo da garantire che tali pacchetti non consumino tutta la banda rendendo impossibile il passaggio dei pacchetti non prioritari e che allo stesso tempo ottengano una garanzia sulla consegna veloce. E' possibile definire più classi di EF, utilizzando il campo DSCP.

II.5.2.2 PHB: Assured ForwardingAF è un servizio che cerca di garantire che un pacchetto non venga scartato dalla coda di un router quando il traffico dati comincia ad essere elevato. Il meccanismo adottato è simile a quello presentato nel paragrafo sulla gestione delle code, quando si è trattato dei pacchetti “marcati” e delle due soglie oltre le quali scartare pacchetti. AF adopera esattamente lo stesso approccio, definendo un certo numero di politiche di dropping sulle code. Da notare che i pacchetti marcati come assured non vengono consegnati prima di quelli best effort, semplicemente, in caso di congestione, la probabilità che i pacchetti assured vengano persi è più bassa rispetto a che vengano persi quelli best effort.

II.6 QoS in Fast InterconnectPer fast interconnect si intendono le connessioni LAN ad alta velocità adoperate, ad esempio, nelle server farm. La QoS in IP è una QoS distribuita in un ambito WAN, per le LAN inizialmente non c'erano preoccupazioni per la QoS, poiché una LAN era nativamente una rete over provisioned per le applicazioni che doveva supportare. Questo non è più vero allo stato attuale delle cose, in cui grosse server farm gestiscono enormi quantità di dati da trasferire fra i computer, per le applicazioni più disparate: data warehousing, web, CDN, ecc.

Nasce così la necessità di introdurre la QoS anche a livello LAN. In questo caso va tenuto in conto che le informazioni sulla gestione della QoS stessa possono viaggiare molto più velocemente, data la vicinanza spaziale e la relativa complessità ridotta della rete, fornendo quindi possibilità di maggior coordinazione.

Poiché le LAN sono costituite sostanzialmente da protocolli di livello data link (anche se sono presenti architetture differenti) c'è la necessità di meccanismi di QoS a livello della comunicazione point-to-point. A questo livello si può agire su controllo di flusso, gestione della congestione, differenziazione del servizio.

Alcune architetture di interesse sono:

➢ Infiniband Architecture (IBA): standardizzata nell'ottobre del 2000 adopera un modello di interconnessione seriale point-to-point full duplex. Il suo scopo era rimpiazzare le interfacce PCI all'interno dei server e i canali in fibra ottica nelle storage area network. Attualmente è adoperata come interconnessione fra sistemi differenti;

➢ Advanced Switching Interconnect (ASI): deriva da PCI Express I/O, un sistema che utilizza degli switch per l'interconnessione interna di un sistema. Riutilizza lo stesso livello fisico e link aggiungendo nuove funzioni per la comunicazione peer-to-peer a livello transazione.

➢ Ethernet: è la tecnologia dominante per le LAN, a cui sono già stati introdotti alcuni meccanismi per il supporto alla QoS è che è ancora in fase di studio per ulteriori modifiche.



II.6.1 Flow ControlEsaminiamo come viene effettuato il controllo di flusso nelle tre architetture precedentemente nominate.

II.6.1.1 Flow Control in IBAIl controllo di flusso in IBA è basato su di un meccanismo a cascata point-to-point di crediti. In particolare un mittente può inviare dati solo se ha sufficienti crediti per farlo. I crediti sono forniti dal destinatario di quei dati, che, quando è pronto a riceverli, fornisce al mittente i crediti.

IBA divide il canale di comunicazione in una serie di “corsie virtuali” (virtual lane) ed esegue il controllo di flusso separatamente per ciascuna di esse, separando anche la gestione delle code, della congestione, dei buffer. Questo permette ad esempio di costruire virtual network al di sopra delle virtual lane. Il problema principale è che facendo comunque capo allo stesso nodo di elaborazione, per quanto le virual lane siano del tutto separate logicamente, si rischia che qualcuna di queste vada in starvation, poiché potrebbe non ottenere mai crediti nella circostanza in cui i crediti messi a disposizione vengano consumati più velocemente da un'altra virtual lane.

II.6.1.2 Flow Control in ASIIl controllo di flusso ASI segue un approccio analogo, ma tenta di risolvere il problema della starvation. Viene definito un particolare tipo di coda, bypassable, e due tipi di pacchetti: bypass e ordered. Quando non ci sono più crediti per pacchetti bypass, gli altri pacchetti possono continuare a passare, inoltre, quando sono nuovamente disponibili crediti, si da' la precedenza alle code che erano bloccate.

II.6.1.3 Flow Control in EthernetIl meccanismo di Ethernet si basa su messaggi espliciti di ON-OFF che però agiscono sull'intero link fisico, quindi tutte le comunicazioni che adoperano quel link sono influenzate dai messaggi ON-OFF, anche se solo una delle comunicazioni doveva sospendere l'invio dati, non differenziando quindi i pacchetti. Il meccanismo è dunque molto semplice, il messaggio di ON abilita all'invio di informazioni, quello di OFF ferma tale invio, indicando anche un tempo per la ripresa. Perché questo meccanismo sia efficace è necessaria una stretta tempificazione dei segnali ON-OFF, quindi, è necessario che non ci siano troppi switch lungo il percorso.

II.6.2 Congestion controlMentre il controllo di flusso agisce come un semaforo, indicando quando trasmettere, il controllo di congestione fa un'operazione più complessa, operando un controllo di rete, per risolvere il problema alle sorgenti del traffico.

II.6.2.1 Congestion Control in IBAE' basato su tre meccanismi:

1. FECN (Forward Explicit Congestion Notification): quando uno switch lungo la rete rileva congestione, imposta un opportuno campo dell'header del pacchetto in modo da segnalare tale situazione alla destinazione del pacchetto. Quando la destinazione riceve



questo pacchetto, verifica il bit e segnala la congestione al mittente. Sono previsti 16 livelli di congestione. Si può anche implementare un meccanismo di beckward, in cui lo switch che rileva la congestione invia direttamente la segnalazione alla sorgente dei dati.

2. Static Rate Control: è adoperato agli end-node quando si ricevono flag FECN. Più pacchetti col flag impostato arrivano, più il rate è ridotto. Torna ad aumentare allo scadere di appositi timout;

3. Head of queue drain: è utilizzato come meccanismo estremo per evitare situazioni di stallo dovute alla mancanza di crediti o a lane che non consumano i pacchetti. Non fa altro che svuotare la testa della coda.

II.6.2.2 Congestion Control in ASIIn ASI il controllo di congestione è Status-based Flow Control dove uno switch in ricezione può segnalare il bisogno di ridurre la priorità di alcuni flussi. Questa operazione è fatta selettivamente solo su quei flussi che stanno inducendo la congestione.


Reti di calcolatori II Capitolo III

Capitolo IIIInter-domain routing with BGP

Attualmente Internet è organizzata come un insieme di oltre 10.000 domini autonomi di routing, fra loro interconnessi. Ogni dominio non è altro che l'insieme di link, host, router e LAN sotto uno stesso controllo amministrativo. Le dimensioni dei domini variano da milioni di indirizzi IP a singoli indirizzi IP. L'interconnessione fra tutti i domini garantisce che un pacchetto possa essere teoricamente mandato ovunque, tuttavia non si deve credere che i domini attraversati siano molti, in realtà studi sperimentali hanno dimostrato che si attraversano 4, 5 autonomous system in media prima che un pacchetto raggiunga la sua destinazione.

E' utile a questo punto introdurre con maggior precisione i concetti di dominio e autonomous system, per quanto questi tipicamente indichino la stessa cosa:

➢ Autonomous system: è un insieme di router sotto una singola amministrazione tecnica, che presentano una chiara indicazione di quali siano le destinazioni raggiungibili attraverso essi.

Ciascun AS è identificato da un AS number univoco, assegnato da un'autorità preposta a questo scopo.

➢ Domain: Un dominio è un'entità amministrativa che può corrispondere ad un AS, a più AS o ad un sottoinsieme di un AS.

Gli AS possono essere suddivisi in:

➢ Stub AS: sono AS in cui il traffico circolante al loro interno ha destinazione o sorgente nell'AS stesso;

➢ Transit AS: sono AS che possono essere attraversati da traffico destinato ad altri AS.

Generalmente gli AS Stub sono quelli che generano contenuti o gli ISP che forniscono connettività ad aziende ed utenti domestici. I Transit AS sono di proprietà delle società che gestiscono le reti di backbone.

Figure 10: Internet come insieme di AS

Inter-domain routing with BGP 24

AS2

AS3

AS5

AS4

AS6

AS1


Chiaramente perché i pacchetti si muovano lungo la rete è necessario adoperare opportuni protocolli di routing. I classici protocolli non sono tuttavia sufficienti, infatti, date le dimensioni impressionanti di Internet, un normale protocollo di routing non sarebbe sufficientemente scalabile, inoltre, i protocolli di routing standard, adoperati ad esempio in un AS, ottengono una descrizione approfondita della rete e, per ragioni amministrative, qualche dominio potrebbe non desiderare la diffusione di queste informazioni. Per queste motivazioni si adoperano due famiglie diverse di protocolli in Internet:

➢ Interior Gateway Protocol (IGP): sono protocolli che lavorano solo internamente ad un AS, conoscendo dunque la topologia solo del loro AS;

➢ Exterior Gateway Protocol (EGP): sono protocolli che gestiscono l'instradamento fra AS diversi.

Il protocollo di routing agisce poi sulla tabella d'instradamento del router come mostrato nella seguente figura:

Figure 11: Router architecture

III.1 Intra-Domain RoutingL'intra-domain routing consente di trasmettere pacchetti IP attraverso il miglior percorso verso la loro destinazione. Per migliore si può intendere il percorso più breve in termini di distanza percorsa, tempo di percorrenza o anche percorso meno carico. Gli algoritmi di questo tipo permettono di trovare un percorso alternativo, se esistente, nel caso il precedente per qualche guasto non sia più adoperabile. Questi algoritmi permettono lo scambio di informazioni sulla rete da parte dei router, che in questo modo vengono a conoscenza di informazioni di routing riguardanti l'intero dominio cui appartengono.

Sono sostanzialmente 3 i tipi di IGP:

Static routing: la configurazione manuale statica è utilizzabile soltanto in domini molto piccoli;

Distance vector routing: la sua principale implementazione, RIP, è ancora molto usata in molti domini nonostante le sue limitazioni;


IP packets

Routing tableRoutingprotocol

FABRIC = Forwarding table

Control

Forwarding


Link State routing: il protocollo OSPF che implementa il LS è molto usato a livello di reti enterprise, mentre negli ISP si adopera principalmente Intermediate System-Intermediate System(IS-IS).

III.1.1 Distance VectorIl DV è implementato dal protocollo RIP. Il meccanismo di routing è basato sull'algoritmo di Bellman-Ford per il calcolo del percorso minimo su rete. Sostanzialmente i router si scambiano fra loro un vettore che contiene, per ogni router, le destinazioni che quel router può raggiungere con associato il costo necessario per raggiungerle. Le destinazioni sono espresse in termini di prefissi di rete.

Chiaramente ogni router riceve solo i vettori di tutti i suoi vicini (e manda i vettori soltanto a tutti i suoi vicini). Su tali vettori sono basate le tabelle di routing del router.

Questo algoritmo soffre di alcuni seri problemi quando ci sono variazioni consistenti della topologia di rete, come ad esempio la caduta di un link. In questo caso, infatti, prima che la conoscenza dell'avvenuta caduta del link sia consolidata, i router chiusi in un ciclo si scambiano informazioni incrementando di una unità per volta il costo del link caduto, che è considerato tale soltanto quando l'incremento ennesimo porta il costo di quel link al valore che indica infinito, ossia l'assenza del link. Per tali problemi la rete non può avere molti hop poiché altrimenti l'algoritmo non convergerebbe mai. Solitamente il limite consigliato è 16.

Le varianti che tentano di risolvere questo problema (Split Horizon, Split Horizon Poison Reverse) in realtà risolvono soltanto i problemi derivanti da cicli formati fra due hop. Per queste ragioni gli algoritmi DV sono usati solo in piccoli domini.

III.1.2 Link StateAnche nel LS i router hanno necessità di scambiarsi informazioni per comprendere la topologia della rete. Mentre nel DV i router scambiavano informazioni riguardanti tutta la rete ma solo con i vicini, nel LS i router inviano informazioni che riguardano solo i loro link diretti, ma a tutti gli altri router. Questo è ottenuto attraverso un reliable flooding di messaggi che contengono tali informazioni. Quando un router ha ricevuto tutte le informazioni inviate dagli altri router calcola il minimo percorso attraverso l'algoritmo di Dijkstra per il minimo percorso. A differenza del DV i protocolli di routing LS hanno tempi di convergenza molto più brevi in caso di cambiamenti della topologia.

Generalmente questi protocolli indicano per una stessa destinazione più percorsi, se tali percorsi hanno stesso costo. In questo modo si possono adoperare semplici strategie di load balancing sui link, facendo un banale roud-robin fra questi. Lo svantaggio è che pacchetti di una stessa connessione TCP potrebbero in questo modo arrivare in ordini diversi, il che comporta una certa penalizzazione nelle prestazioni del TCP.

III.2 Inter-domain routingI protocolli EGP hanno il compito di gestire i pacchetti nell'attraversamento di AS differenti. Lo scopo in questo caso è differente rispetto ai protocolli IGP. Gli AS sono infatti considerati delle black-box e il calcolo del percorso migliore non necessariamente significa il percorso più breve, anzi, molto spesso il significato di percorso migliore in questo caso è percorso più economico.



Le compagnie che gestiscono gli AS di transito offrono il servizio di connettività previo pagamento, dunque, uno degli scopi di un protocollo di EGP è anche permettere la definizione di policy da parte degli AS. Un protocollo EGP calcola dunque il miglior percorso per un pacchetto tenendo conto delle policy amministrative di ciascun AS, ignorando il trattamento del pacchetto internamente all'AS stesso.

Il protocollo EGP utilizzato in Internet è il Border Gateway Protocol (BGP). Quello che BGP sostanzialmente fa è annunciare delle rotte (route), in altre parole, ciascun AS tramite BGP comunica agli altri AS quali destinazioni sono raggiungibili attraverso esso, allo stesso tempo l'AS riceve le destinazioni raggiungibili attraverso gli altri AS ad esso connessi.

Gli AS sono connessi fra loro in due modi (Figure 12), o attraverso un link diretto, o attraverso un punto pubblico di interconnessione, solitamente realizzato con uno switch in tecnologia almeno Gigabit Ethernet.

Figure 12: AS interconnection

Come detto, BGP deve garantire anche dei vincoli amministrativi, che sanciscono il rapporto fra due AS, in particolare sono due le policy principalmente adottate:

➢ Customer-provider: un AS provider fornisce previo pagamento il passaggio attraverso di se dei pacchetti provenienti da un AS customer.

➢ Shared-cost: due AS si accordano per scambiare pacchetti fra loro usando un link diretto o un punto di interconnessione.

Le relazioni che legano un AS con gli AS a lui vicini condizionano chiaramente la scelta dei percorsi dichiarati raggiungibili. Ad esempio, facendo riferimento alla Figure 13, AS1 dichiarerà raggiungibile attraverso se tutte le destinazioni in AS1, AS2, AS3 e lo stesso farà AS2. Viceversa, AS3 dichiarerà ad AS1 e ad AS2 soltanto le destinazioni interne ad AS3 stesso, poiché paga i suoi collegamenti, e non vuole di certo essere adoperato come transito del traffico fra AS1 e AS2.

Figure 13: AS policy example


Direct Link

Public Interconnectionpoint

AS1 AS2

AS3$ $


Allo stesso modo, è chiaro che se una destinazione è raggiungibile da due link diversi, uno a pagamento e l'altro no, un AS potrebbe preferire selezionare in via prioritaria il link non a pagamento.

Tutte queste considerazioni vanno a formare le policy di routing dell'AS. Perché queste policy vengano specificate, si adoperano due insiemi di filtri per i router BGP:

➢ Import filter: specifica quali route possono essere accettate dal router fra tutte le route ricevute dagli altri router BGP ad esso collegati, suoi pari (anche detti semplicemente peer);

➢ Export filter: specifica quali route possono essere dichiarate ad un determinato peer.

Per definire i filtri si può adoperare il linguaggio Routing Policy Specification Language (RPSL)[RFC2622].

Figure 14: Import, Export filter example

I filtri per gli AS4 e AS7 dell'esempio riportato in Figure 14 potrebbero essere così impostati:● AS4 import:

○ Import: from AS3 accept AS3

○ Import: from AS7 accept AS7

○ Import: from AS1 accept ANY


● AS4 export:

○ Export: to AS3 announce AS4 AS7

○ Export: to AS7 announce ANY



● AS7 import:


● AS7 export:

○ Export: to AS4 announce AS7

III.2.1 Border Gateway Protocol (BGP)Avendo specificato le problematiche principali che deve affrontare da un punto di vista concettuale BGP, vediamo ora come è realizzato il protocollo per rendere possibile quanto descritto.

Talvolta BGP viene definito un protocollo di routing “path vector”, poiché il suo principale compito è annunciare rotte. In particolare BGP non fa altro che annunciare agli AS vicini, quali AS sono raggiungibili tramite quell'AS e attraverso quale percorso, indicato sempre in termini di AS attraversati.


AS1 AS2

AS4$ $

AS3

$

AS7$


Un tipico messaggio di dichiarazione rotte BGP conterrà quindi le destinazioni raggiungibili e gli AS da attraversare per raggiungere quelle destinazioni.

Figure 15: Esempio di scambio messaggi BGP

In Figure 15 è mostrato un esempio di scambio messaggi BGP. Premettiamo che non sono rappresentati tutti i messaggi scambiati, ma, per chiarezza, solo un sottoinsieme. In particolare, supponiamo che AS3 stia annunciando la rotta per raggiungere le destinazioni 1.0.0.0/8 che sono corrispondenti ad una sottorete presente al suo interno. AS3 manda dunque un messaggio per comunicare la presenza di questa rotta per la destinazione 1.0.0.0/8. La rotta in questo caso è semplicemente AS3, poiché AS3 sta annunciando una sua sottorete. Gli AS confinanti ottengono questa informazione e, se per loro è una nuova rotta, provvedono ad informare anche i loro vicini della presenza di questa nuova rotta. Ogni AS aggiunge il suo identificativo nel campo PATH del messaggio, poiché dichiara una rotta che deve attraversare se stesso per raggiungere la destinazione finale.

E' interessante vedere come BGP abbia due meccanismi per supportare le policy: quando un AS ha più rotte per la stessa destinazione, seleziona quale annunciare all'esterno in base alla sua policy amministrativa. Ad esempio, AS4 avrebbe potuto annunciare ad AS7 la rotta AS4,AS3 ma per qualche sua policy ha invece annunciato la rotta AS4,AS1,AS3. Il secondo meccanismo permette ad un AS anche di non annunciare affatto la nuova rotta ricevuta, in base a considerazioni analoghe a quelle fatte nel precedente paragrafo.

La presenza del PATH garantisca la possibilità di evitare loop nell'instradamento dei pacchetti, poiché ogni AS può controllare la rotta seguita. Inoltre, questo da' la possibilità di garantire possibilità di decisione, in base alle policy di natura amministrativa, di quale percorso seguire.

Viene a questo punto spontaneo chiedersi da dove BGP impari nuove rotte da annunciare. L'esempio precedente dimostra chiaramente che una parte delle rotte sono imparate dagli altri AS. Ma, ad esempio, cosa ha permesso ad AS3 di conoscere la rotta per 1.0.0.0/8?

In realtà BGP impara le rotte in altri due modi:

➔ Static configuration: le rotte da dichiarare sono impostate manualmente. Questo garantisce


AS1 AS2

AS4AS3AS7

1.0.0.0/8

Prefix: 1.0.0.0/8PATH: AS3

Prefix: 1.0.0.0/8PATH: AS3

Prefix: 1.0.0.0/8PATH: AS1,AS3

Prefix: 1.0.0.0/8PATH: AS1,AS3 Prefix: 1.0.0.0/8

PATH: AS2,AS1,AS3

Prefix: 1.0.0.0/8PATH: AS4,AS1,AS3


una solida stabilità ma, per contro, ogni aggiornamento va fatto manualmente richiedendo dunque un ingente tempo;

➔ Learned from IGP: è anche possibile che le rotte da annunciare siano conosciute apprendendole tramite il protocollo di routing IGP, chiaramente BGP dichiara poi aggregati delle destinazioni così apprese. Questa soluzione permette a BGP di seguire lo stato della rete e aggiornare le rotte in base alla comparsa di nuovi percorsi o alla scomparsa di altri, ad esempio a seguito della caduta di un link. Lo svantaggio è che se il protocollo IGP presenta una certa instabilità per via di condizioni mutevoli frequenti della rete, anche BGP diviene instabile, con conseguente crescita del traffico di overhead del protocollo, poiché ogni messaggio di aggiornamento BGP genera messaggi a cascata negli AS.

Avendo definito per sommi capi il funzionamento di segnalazione delle rotte di BGP, possiamo definire un'architettura di massima di un router BGP, tale architettura è riportata in Figure 16:

Figure 16: BGP router architecture

Gli import filter definiscono i messaggi BGP accettabili dal peer per cui sono definiti, tutte le possibili rotte vengono poi esaminate dal processo decisionale BGP, assieme alle rotte apprese tramite il protocollo di routing IGP, per selezionare fra questi quali sono quelle migliori per una data destinazione. Infine, queste rotte sono comunicate ai filtri di uscita che selezionano gli annunci di rotta che possono essere fatti al particolare peer per cui sono definiti quegli export filter.

III.2.1.1 BGP MessagesFino ad ora non si è specificato in che modo due router BGP comunichino. Per quanto BGP sia un protocollo di livello rete, per la comunicazione dei suoi messaggi fa affidamento a TCP che è un protocollo di livello trasporto. Per scambiare messaggi fra due peer si stabilisce quindi una sessione BGP su TCP fra i due router. Allo stabilimento della sessione, i router inviano tutte le rotte da loro conosciute. Nell'arco della sessione l'aggiornamento delle rotte avviene invece per via incrementale, in altre parole, ad ogni nuova rotta disponibile, il router invia un messaggio di aggiornamento.

In uno schema semplificato possiamo identificare due tipi di messaggi di aggiornamento dei path vector:

➢ UPDATE: è utilizzato per annunciare una rotta per un particolare prefisso, contiene:

○ L'indirizzo/prefisso destinazione;

○ L'inter-domain path per raggiungere la destinazione;

○ Next-hop: l'indirizzo del router che ha annunciato la rotta;


Peer[N]

Peer[1]

IMPORT FILTER

Acceptable routes

BGP Decision Process

One route per destination

Peer[N]

Peer[1]

EXPORTFILTER


➢ WITHDRAW: è adoperato per indicare che una rotta precedentemente annunciata non è più disponibile, il contenuto del messaggio è semplicemente la destinazione non più raggiungibile.

Con i messaggi di UPDATE e WITHDRAW, e tramite il protocollo IGP adoperato internamente all'AS, BGP viene dunque a conoscenza delle nuove rotte, o di quelle non più esistenti. In realtà BGP elimina anche tutte le rotte che passano attraverso un AS con il quale è aperta una sessione BGP, quando tale sessione viene chiusa. Questo avviene poiché si suppone che la sessione sia stata chiusa per malfunzionamenti nell'AS non più connesso.

Per verificare la persistenza della connessione, BGP prevede l'invio ad una certa frequenza di messaggi di KEEPALIVE (anche detti “heart beat”).

III.2.1.1.1 Messages' structureI messaggi BGP sono a lunghezza variabile, ma hanno header di lunghezza fissa:

Figure 17: BGP message header

I messaggi possono essere di diversi tipi:

➢ OPEN: per aprire una connessione BGP;

➢ UPDATE: per inviare nuove rotte o per ritirare quelle non più funzionanti;

➢ NOTIFICATION: per informare un peer remoto di un errore, una sessione BGP è chiusa dopo l'invio o la ricezione di questo messaggio;

➢ KEEPALIVE: viene inviato ogni 30 secondi per confermare la presenza della connessione BGP;

➢ ROUTE_REFRESH: adoperato per supportare ripartenze graduali.

Nel seguito sono riportati alcuni formati dei messaggi:

● OPEN:


Figure 18: Open message

Marker: Tutti 1

32 bit

Lenght (16 bit) Type


● UPDATE:

● KEEPALIVE: è un messaggio formato solo dall'header BGP;

● NOTIFICATION:

Rimane da specificare il meccanismo di stabilimento della sessione fra due peer BGP. Solitamente, una sessione BGP può essere stabilita soltanto fra due peer configurati manualmente. Ogni peer deve essere configurato con l'indirizzo IP e il numero di AS del peer remoto. La sequenza di messaggi è la seguente:


Figure 19: Update message

Figure 20: Notification message


III.2.1.2 BGP Example 1Nel seguito è riportato un esempio di funzionamento di BGP:

Figure 21: BGP example 1/2

R1 impara una nuova rotta, tramite il protocollo di IGP, all'interno del suo AS, la comunica dunque agli AS confinanti che a loro volta propagano la rotta.

Supponiamo che cada il link fra AS10 ed AS20, quando AS20 non riceve più il messaggio di KEEPALIVE, provvede a cancellare tutte le rotte che passano per AS10, di conseguenza aggiorna anche la rotta precedentemente inviata ad AS30, inviando un nuovo messaggio di UPDATE:

Figure 22: BGP example 2/2

III.2.1.3 Route preferenceAbbiamo visto che BGP lavora sostanzialmente con decisioni di tipo amministrativo, quindi, è utile disporre di un meccanismo che dia la possibilità di preferire una rotta piuttosto che un'altra. I sistemi di filtri offrono la possibilità di accettare o negare una rotta, ma se abbiamo due rotte per una stessa destinazione, ad esempio una principale ed una di backup, come indicare quale delle due preferire? Un possibile approccio è impostare un valore di preferenza locale per ciascun canale di comunicazione verso gli altri AS.

Per inserire tale valore è possibile operare una piccola modifica al modello di router BGP presentato in Figure 16. E' sufficiente far si che i filtri in ingresso aggiungano l'informazione del


AS10

AS40

AS20 AS30R1

R4

R2R3

BGP sessionUPDATEpref ix:194.100.0.0/24NextHop:R1ASPath:AS10

194.100.0.0/24

UPDATEpref ix:194.100.0.0/24NextHop:R1ASPath:AS10

UPDATEpref ix:194.100.0.0/24NextHop:R4ASPath:AS40,AS10

UPDATEpref ix:194.100.0.0/24NextHop:R2ASPath:AS20,AS10

AS10

AS40

AS20 AS30R1

R4

R2R3

BGP session194.100.0.0/24

UPDATEpref ix:194.100.0.0/24NextHop:R2ASPath:AS20,AS40,AS10


valore di preferenza locale a ciascuna rotta e impostare opportunamente l'algoritmo di decisione in modo che tenga conto di questi valori nella selezione della rotta per una destinazione. Una semplice impostazione è selezionare la rotta con la preferenza locale più alta.

In realtà, per quanto questa possa sembrare una soluzione ottimale, ci sono alcuni problemi all'atto dell'applicazione pratica che rischiano di generare loop nella consegna di alcuni pacchetti:

In questa situazione AS1 dichiara la rotta per 194.100.0.0/24 ad AS2 ed AS3, ed entrambi la dichiarano reciprocamente fra loro. Poiché AS2 preferisce il link con AS3 che non è a pagamento, deciderà di inviare i pacchetti tramite AS3, ma AS3 per raggiungere 194.100.0.0/24 preferirà a sua volta AS2.

In realtà in questa situazione si possono avere tre casi:

1. Il messaggio di UPDATE di AS1 è inviato ad AS2 ed AS3, ma AS2 invia il messaggio che dichiara la nuova rotta con PATH AS2,AS1 prima che AS3 invii il suo messaggio. In questo modo AS3 impara la rotta per 194.100.0.0/2 tramite AS2 e non invia ad AS2 la rotta attraverso di se per raggiungere la destinazione. Il routing in questo caso è stabile;

2. Il secondo caso è la situazione duale alla precedente, con AS2 che impara la rotta con path AS3,AS1;

3. Il terzo caso si ha quando i messaggi con path AS3,AS1 e AS2,AS1 viaggiano in contemporanea, in questo caso, i due AS inviano un messaggio di WITHDRAW della rotta precedentemente dichiarata. Subito dopo poiché verificano la loro connessione diretta con AS1, reinviano i messaggi con i PATH che prima avevano ritirato, e ancora una volta può verificarsi uno di questi tre casi. Il procedimento va avanti fino a quando non ci si trova nel caso 1 o 2.

Purtroppo possono anche esserci casi in cui non si può raggiungere la convergenza:


AS2

AS1

AS3R1

R4

R2

$ $

194.100.0.0/24

Preferred path: AS3 Preferred path: AS2

Figure 23: Esempio di caso in cui BGP non converge


Come è facile vedere, poiché ciascuno degli AS non accede direttamente ad AS0, un pacchetto continuerebbe a percorre in loop un percorso che non raggiunge mai la sua destinazione.

III.2.1.4 The internet organizationAttualmente Internet è come già detto organizzata come un insieme di AS. Alla luce di quanto detto in questi paragrafi, possiamo caratterizzare con più accuratezza la sua struttura.

In Figure 24 è mostrata un'immagine schematica di Internet come appare oggi. Possiamo distinguere chiaramente 3 livelli:

1. Tier 1 ISP: è formato dai fornitori di servizio (ISP) di backbone, in altre parole sono quelle aziende che offrono la connettività del cuore della rete, trasportando informazioni su grandi distanze. Questi ISP scambiano fra loro link shared-cost;

2. Tier 2 ISP: è formato da ISP che sono customer degli ISP di backbone, fra loro gli ISP di livello due adoperano link shared-cost, mentre sono provider per ISP di terzo livello. A questa categoria solitamente appartengono ISP nazionali o regionali;

3. Tier 3 ISP: sono ISP di piccole dimensioni, grandi reti aziendali o fornitori di contenuti, che sono customer di altri ISP di livello 2 o 3. Fra loro utilizzano link shared-cost.

Tipicamente un percorso di un pacchetto in Internet attraversa 0 o più relazioni customer-provider, 0 o una relazione peer e 0 o più relazioni provider-customer. Inoltre, nella maggior parte dei casi, i percorsi fra due punti della rete sono asimmetrici.

III.2.1.5 BGP in large networksConsideriamo la seguente figura:


Figure 24: Una visione schematica di Internet

AS10 AS20 AS30

R1 R3R2

R4


In un largo AS è verosimile che ci siano più router BGP per connettersi agli altri AS. In queste condizioni è necessario disporre di un metodo per far comunicare fra loro questi router. Nell'esempio in figura, R3 impara le rotte di AS10, R4 dovrà annunciare ad AS30 anche queste rotte, ma come fa a conoscerle?

Una possibile soluzione è adoperare il protocollo IGP sottostante per comunicare anche le rotte apprese tramite BGP. Il problema è che tipicamente il numero di rotte è considerevole, quindi, il protocollo IGP verrebbe velocemente sovraccaricato, rendendo di fatto la soluzione non scalabile. In aggiunta, i protocolli IGP non prevedono meccanismi per trasportare le informazioni aggiuntive legate alle rotte BGP, come ad esempio gli ASPath.

Un tentativo di usare un protocollo IGP per far comunicare due router BGP di un AS sfociò in un noto malfunzionamento, noto come l'incidente dell'AS7007, che causò il blocco di Internet (in larga parte) per ore. Il problema fu che adoperando il protocollo di IGP per trasportare le rotte, l'AS7007 risultò agli altri router come destinazione della gran parte degli indirizzi IP imparati dalle rotte BGP, inoltre, non avendo l'informazione ASPath, il percorso attraverso l'AS7007 risultava il più breve poiché riportava solo quell'AS, questo causò un sovraccarico di traffico che bloccò la rete.

La soluzione alternativa è instaurare una connessione BGP anche fra i router interni allo stesso AS, si configurano così due diversi tipi di connessione BGP:

➢ iBGP: connessione BGP fra router appartenenti allo stesso AS;

➢ eBGP: connessione BGP fra router appartenenti ad AS diversi;

Le connessione iBGP devono essere mantenute da ogni router BGP di un AS, verso tutti gli altri router BGP di quell'AS (full iBGP mesh). Da notare che le connessioni iBGP non necessariamente seguono la topologia fisica della rete, poiché BGP viaggia su TCP.

Chiaramente ci sono delle differenze nella gestione delle due differenti connessioni BGP:

Innanzitutto, poiché il valore di local pref appartiene ad una impostazione locale, tale valore sarà incluso come informazione soltanto all'interno delle connessioni iBGP. Allo stesso modo, non ci sono solitamente filtri applicati alle sessioni iBGP, perché come detto i filtri si adoperano per applicare policy amministrative fra AS differenti.

La scelta della rotta migliore verso una destinazione è fatta dal router BGP che riceve l'annuncio di quella rotta. Effettuata la scelta, il router provvede ad informare solo della rotta selezionata gli altri router BGP del suo AS, tramite la connessione iBGP. Le rotte apprese da un router tramite la connessione iBGP non sono poi annunciate agli altri router dello stesso AS, poiché i router BGP di un AS sono fra loro connessi in full mesh, quindi già avranno ricevuto lo stesso annuncio.

In sintesi, mentre con eBGP si annunciano ai router di altri AS tutte le migliori rotte verso qualsiasi destinazione conosciuta, con iBGP si annunciano ai router del proprio AS solo le migliori rotte apprese tramite eBGP.

Quando si trasmette una rotta tramite iBGP i campi NextHop e ASPath non variano rispetto a quelli del messaggio eBGP ricevuto in origine, questo perché chiaramente non viene attraversato nessun ulteriore AS, inoltre, il campo NextHop contiene per definizione l'indirizzo IP del router BGP del prossimo AS da contattare per raggiungere la destinazione.

In Figure 25 è mostrato un esempio per chiarire quanto detto:



Figure 25: Esempio di messaggi eBGP e iBGP

Facendo sempre riferimento al precedente esempio, scriviamo le tabelle di routing BGP ed IGP di R4:

● BGP routing table

○ 194.100.0.0/23 via R1

● IGP routing table

○ 194.100.0.0/30 via R3

Mettendo insieme queste informazioni, R4 costruisce la sua forwarding table:● Farwarding table

○ 194.100.0.0/23 via R3

○ 194.100.0.0/30 via R3

Consideriamo adesso cosa succede nel momento in cui due router BGP interni ad un AS non sono fra loro fisicamente direttamente collegati, Abbiamo detto che la sessione iBGP viene stabilita senza problemi poiché viaggia su protocollo TCP, tuttavia, i router compresi fra i BGP router non è detto che sappiano instradare correttamente tutti i pacchetti IP che ricevono, poiché questi router non hanno le informazioni di BGP, ma solo quelle apprese tramite IGP (Figure 26).

Figure 26: Il problema dei backbone router

E' dunque necessaria una strategia per consentire a questi router di instradare correttamente il traffico IP. Tre possibili soluzioni sono le seguenti:


AS10

AS20 AS30R1 R3

R2eBGP

R4

iBGP eBGP

UPDATE(eBGP)Pref ix: 194.100.0.0/23NextHop: R1ASPath: AS10

194.100.0.0/23UPDATE(iBGP)Pref ix: 194.100.0.0/23NextHop: R1ASPath: AS10Local-pref : 1000

UPDATE(eBGP)Pref ix: 194.100.0.0/23NextHop: R4ASPath: AS20,AS10

AS10

AS20

AS30R1

R3

R2

eBGP

R4

iBGP

eBGP194.100.0.0/23

R5


1. Utilizzare un “tunnel” fra i router BGP per incapsulare i pacchetti destinati ad AS esterni. Generalmente questo approccio adopera due tecnologie per il tunneling:

○ GRE tunnel: ha bisogno di una configurazione statica e necessita di grande attenzione nell'impostazione degli MTU;

○ MPLS tunnel: i tunnel sono creati dinamicamente adoperando il sistema di labeling MPLS (che verrà trattato successivamente in questo testo);

Figure 27: Soluzione con tunneling

2. Adoperare il protocollo di IGP per trasportare le informazioni EGP delle rotte verso i router interni dell'AS. Questa soluzione è applicabile se si evita che i router EGP annuncino come nuove rotte quelle esterne che il protocollo IGP sta redistribuendo all'interno dell'AS. Tuttavia, anche con questo accorgimento, il numero di rotte EGP velocemente sovraccarica il protocollo IGP.

3. E' possibile anche decidere di rendere tutti i router di backbone dell'AS dei router BGP. Tali router riceverebbero le rotte tramite iBGP, ma, poiché i router BGP non dichiarano mai rotte apprese tramite iBGP, non annuncerebbero mai rotte. Il problema principale di questo approccio è che comporta che tali router partecipino alla full mesh iBGP dell'AS, con conseguente aumento esponenziale del numero di connessioni iBGP

III.2.1.6 ConfederationsPer risolvere i problemi di scalabilità derivanti dal numero crescente di connessioni iBGP per stabilire la full mesh, si è pensato di introdurre le confederations. Il concetto è semplice, si divide un AS in sottoinsiemi, all'interno del sottoinsieme si adopera la full mesh iBGP, fra sottoinsiemi diversi si adopera eBGP.

I sottoinsiemi sono identificati da un numero di AS detto Member-AS, mentre ciascun AS rimane identificato dal suo numero globale, che in questo caso assume il nome di Confederation AS.

Ogni router BGP conosce dunque questi due numeri, in modo da impostare opportunamente il campo ASPath nei messaggi BGP. Per il routing IGP la distinzione in sottoinsiemi non viene fatta, quindi, generalmente, un solo algoritmo IGP copre l'intero dominio.

Nelle connessioni verso altri AS, i router risultano sempre appartenenti all'AS principale cui appartengono (sono quindi appartenenti all'AS identificato dal confederation AS). Quando invece la comunicazione con eBGP è fra due router appartenenti a due sottoinsiemi diversi dello stesso AS, allora i numeri AS utilizzati in questo caso sono i Member-AS.


AS10

AS20

AS30R1

R3

R2

eBGP

R4

iBGP

eBGP194.100.0.0/23

R5

Tunnel


Per chiarire quanto affermato facciamo riferimento alla seguente figura:

Figure 28: BGP Confederations

Nella comunicazione fra RX ed R2, R2 appartiene all'AS20, così come nella comunicazione fra R5 e RY, R5 appartiene all'AS20. Nella comunicazione fra R1 e R6, R1 appartiene all'AS65020 mentre R6 all'AS65021.

Quando si propaga un messaggio di UPDATE in una confederation, i router che hanno una connessione eBGP con router della stessa confederation, provvedono ad inserire nell'ASPath il numero di sottoinsieme Member-AS. Quando il messaggio deve essere inviato all'esterno della confederation, il router elimina tutti i riferimenti Member_AS dall'ASPath e inserisce il confederation AS.

Figure 29: Esempio di propagazione UPDATE in una confederation

L'utilizzo delle confederation rende molto semplice l'attuazione di procedure amministrative, quali il passaggio sotto un unico dominio di due AS precedentemente appartenenti a domini differenti.

III.2.1.7 Route ReflectorsUna ulteriore soluzione per introdurre la scalabilità delle connessioni iBGP è l'utilizzo di particolari router, detti Route Reflectors. Come il nome lascia facilmente intendere, questi router hanno il compito di replicare agli altri router le rotte che apprendono, la particolarità è che fanno questo


AS10

AS20

AS30RX

R2

RYeBGP

R3

iBGP

eBGP

R1

iBGP

iBGP

R6

R5

iBGPeBGP

AS65020 AS65021

AS10

AS20

AS30RX

R2

RYeBGP

R3

iBGP

eBGP

R1

iBGP

iBGP

R6

R5

iBGPeBGP

AS65020 AS65021

UPDATE(eBGP)Prefix: 1.0.0.0/8ASPath: AS10

UPDATE(iBGP)Prefix: 1.0.0.0/8ASPath: AS10

UPDATE(eBGP)Prefix: 1.0.0.0/8ASPath: [AS65020],AS10

UPDATE(iBGP)Prefix: 1.0.0.0/8ASPath: [AS65020],AS10

UPDATE(eBGP)Prefix: 1.0.0.0/8ASPath: AS20,AS10


anche se apprendono tali rotte da connessioni iBGP, ricordiamo infatti che il comportamento comune è quello di non annunciare le rotte apprese tramite iBGP.

Sostanzialmente i route reflectors hanno il compito di fare da “server centralizzato” per la diffusione delle rotte fra i router appartenenti ad uno stesso dominio. Altri router possono registrarsi come client di un route reflector e dipendere da questo per ottenere le rotte che sono state apprese da altri router BGP dello stesso AS.

Figure 30: Route Reflector

In Figure 30 i router R1, R2, RN sono client del route reflector RR che invece con RX, RY, RZ partecipa ad una iBGP full mesh. Da questo esempio risulta chiaro come un route reflector possa comportarsi anche come un comune router BGP in alcuni casi.

Il comportamento del route reflector può essere semplicemente schematizzato:

➔ Se si apprende una rotta tramite una connessione eBGP, si seleziona la migliore rotta per quella destinazione e la si comunica a tutti gli altri peer. Questo comportamento è lo stesso adottato da un qualsiasi router BGP che ha una connessione eBGP verso altri AS.

➔ Se si riceve una rotta da uno dei peer non client (RX. RY, RZ della Figure 30) allora si seleziona la migliore rotta per quella destinazione e la si comunica tramite le connessioni iBGP a tutti i peer client (R1, R2, RN).

Poiché il route reflector non è altro che un approccio centralizzato alla diffusione delle informaizoni sulle rotte, bisogna immaginare qualche meccanismo per evitare di avere un single point of failure. Il meccanismo utilizzato è generalmente quello della replicazione dei route reflector, permettendo ad ogni peer di essere client di almeno due route reflector. Poiché errori di configurazione potrebbero causare dei loop nella redistribuzione delle rotte, si aggiungono due informazioni ai messaggi di aggiornamento delle rotte:

ORIGINATOR ID: l'identificatore di chi ha dato origine alla rotta;

CLUSTER LIST: contiene la lista dei route reflector che hanno mandato il messaggio di UPDATE per questa rotta in questo AS.

Chiaramente queste informazioni vengono eliminate dal router BGP che annuncia la rotta all'esterno del proprio AS.

E' interessante notare che i route reflector, per aumentare la scalabilità, possono essere organizzati in gerarchie.


R1 R2 RN

RR

RX

RY

RZ

IBGP connection


III.2.1.8 The dynamics of BGPIdealmente il comportamento di BGP dovrebbe essere stabile, con i router che si scambiano pochi messaggi raramente. Purtroppo in Internet le cose non sono così semplici e il comportamento del protocollo non è stabile.

Studi sperimentali dimostrano che una gran parte delle rotte apprese cambia in tempi brevissimi, nell'ordine dei minuti. Inoltre solo un numero limitato di rotte è coinvolto nell'invio della maggior parte del traffico e queste rotte sono anche quelle più stabili.

Le ragioni di questi risultati sono da ricercarsi nella complessità di Internet e nel fatto che un piccolo evento, come la caduta di un link fra AS, genera una serie di messaggi a cascata di aggiornamento nei router.

Possibili soluzioni per questi problemi prevedono il cambiamento dei filtri di ingresso dei router BGP, tuttavia tale approccio non è semplicissimo. Una volta che una rotta è stata selezionata questa viene registrata nella memoria del router, se il filtro in ingresso cambia, le rotte che già sono registrate non verranno più filtrate e quindi non saranno selezionate dal nuovo filtro. Una soluzione in questo caso è riavviare la sessione BGP, con il conseguente reinvio di tutti i messaggi per la comunicazione delle rotte, come avverrebbe in caso di crash!

III.2.1.9 BGP routing tablesNegli ultimi anni si è assistito ad una crescita accelerata della dimensione delle tabelle di routing BGP. I fattori scatenanti, oltre alla naturale crescita di Internet, sono da ricercarsi nell'incredibile crescita di AS, che hanno comportato anche l'annuncio di prefissi IP più lunghi, e quindi indicativi di un numero ristretto di destinazioni. Inoltre, molti AS sono diventati multi-homed, ossia ottengono connettività da più AS provider, con conseguente crescita delle rotte, poiché ogni provider dichiarerà il suo modo di raggiungere quel particolare AS.

Proviamo ora ad esaminare il tipico ciclo di vita di un AS di nuova creazione. Inizialmente questo AS otterrà un numero “privato” di AS dal provider che gli fornisce connettività (che indicheremo come AS123). L'AS sarà quindi trasparente per il resto della rete, poiché AS123 dichiarerà le rotte come se fossero sue destinazioni interne.

Nello sviluppo successivo, si decide di fornire all'AS un numero di AS “pubblico” per prepararsi ad un futuro multi-homing. Supponiamo che ottenga così il numero AS4567. Per AS123 questo non comporta un problema eccessivo di configurazione, tuttavia tutti i router BGP vedono ingrandirsi con la presenza delle rotte per AS4567 le loro tabelle.

BGP è in grado di aggregare le rotte ricevute anche se perdendo alcune informazioni sull'ASPath. Si introduce così l'AS SET, che rappresenta un insieme di AS nel campo ASPath di BGP. Si perde informazione perché un AS SET conta come un singolo AS nella valutazione della lunghezza di un percorso.

Ad esempio, se AS4567 diventa multi-homed, poiché acquista l'accesso anche da AS789, se solo AS123 compie l'aggregazione, potrebbe verificarsi che nessun pacchetto adopera AS123 per raggiungere AS4567, poiché si preferisce seguire la rotta più specifica (che contiene più informazioni) per raggiungerlo, che è quella attraverso AS789.

Per questa motivazione solo il 7% degli AS opera l'aggregazione sulle proprie rotte, rendendo, di fatto, le tabelle di routing del 50% più grandi!



Le soluzioni che si studiano in questo caso sono di due tipi, una per il futuro, sul lungo periodo, e l'altra per risolvere il problema attualmente:

➢ Soluzione per il lungo periodo: Definire una architettura per il multi-homing in Ipv6;

➢ Soluzione immediata: Alcuni ISP possono filtrare le rotte con prefissi troppo lunghi. Sono due i metodi usati attualmente. Il primo è ignorare le rotte con prefissi più lunghi di p bit (solitamente fra 22 e 24 bit). Il secondo è ignorare le rotte che sono più lunghe delle regole di allocazione adottate dai registri Internet. Il problema di questo approccio è che alcune rotte non sono distribuite nell'Internet globale.

III.2.1.10 The route selection processFino ad ora si è solo accennato al processo di scelta della rotta verso una destinazione, formalizziamo ora l'algoritmo adoperato. La scelta è compiuta esaminando di volta in volta le caratteristiche delle varie rotte nel seguente ordine, fino a quando non si ottiene una sola rotta:

➢ Ignora le rotte con NextHop non raggiungibile;

➢ rotte con valore local-pref più alto;

➢ rotte con ASPath più corto: questa scelta tenta di selezionare il percorso migliore, tuttavia BGP non riporta una informazione reale a riguardo, quindi questa assunzione potrebbe anche essere sbagliata. La conseguenza è che le rotte risultano generalmente limitate a 3-5 AS con convergenza in almeno un ISP di livello 1, con conseguente aumento del traffico su queste dorsali;

➢ rotte con MED (parametro eBGP usato per indicare il costo interno all'AS per raggiungere la destinazione) più piccolo: indica qual è il border router dell'AS più vicino alla destinazione;

➢ rotte apprese tramite eBGP vanno preferite a quelle ottenute tramite iBGP: si introduce questa regola per seguire il principio di base che è maggiormente conveniente inviare il traffico non destinato all'AS agli AS esterni il prima possibile;

➢ rotte con il più vicino NextHop: analogamente al precedente caso, questo cerca di assicurare che il traffico esca al più presto dall'AS;

➢ Tie breaking rule: seleziona la rotta appresa dal router con id più piccolo, questo garantisce che la rotta selezionata sia unica.


Reti di calcolatori II Capitolo IV

Capitolo IVAsynchronous transfer mode

Sebbene le reti ATM non siano lo stato dell'arte delle telecomunicazioni, hanno una forte valenza didattica. L'idea iniziale con cui ATM nacque era quella di porsi come rete unica per video, voce e dati. Venne dunque introdotto un supporto per la QoS e, a differenza delle soluzioni sincrone time division multiplexing proposte fino ad allora come Sonet/SDH, introduceva un meccanismo asincrono di comunicazione, basato su pacchetti.

Considerare il contesto storico in cui ATM è stato realizzato aiuta a comprendere molte delle scelte realizzative. ATM, infatti, è un prodotto sostenuto fortemente dalle compagnie telefoniche, le quali miravano ad ottenere un meccanismo veloce ed affidabile per il trasferimento dati, puntando alla realizzazione di nuovi servizi.

IV.1 ATM architectureATM è una metodo di trasferimento dati, basato su celle, orientato alla connessione, che gestisce dinamicamente l'allocazione delle risorse e la QoS. I mezzi fisici su cui lavora hanno un bassissimo tasso di errore in trasmissione ed i terminali per la connessione alla rete possono essere o estremamente semplici, poiché potevano essere anche soltanto dei semplici telefoni, o complessi, come dei computer. Infine, ATM è organizzato gerarchicamente, come si usa fare in una rete telefonica.

Abbiamo detto che il trasferimento dati è basato su celle (cell switching), la differenza sostanziale fra un pacchetto e una cella è che il primo è di lunghezza variabile, la seconda ha lunghezza fissa. Può sembrare strana la scelta per le celle, poiché la lunghezza variabile avrebbe permesso di adattare la dimensione del pacchetto ai dati da trasferire, garantendo un efficiente utilizzo del canale di comunicazione, tuttavia in quel periodo la tecnologia hardware per gli apparati di rete non garantiva un livello di prestazioni così elevato da poter gestire velocemente la lunghezza variabile. Viceversa, la lunghezza fissa delle celle permetteva di realizzare hardware allo stesso tempo semplice ed estremamente veloce. In aggiunta, la dimensione costante garantisce una conoscenza precisa del tempo necessario per uno switch a trattare una cella, il che aiuta a controllare con grande precisione la QoS.

La scelta della dimensione delle celle è fatta sulla base delle seguenti considerazioni:

1. Celle piccole sono più veloci da trasmettere: con celle di piccole dimensioni l'hardware di rete può inviare una cella in pochissimo tempo, questo aiuta nella gestione delle code. Ad esempio, se bisogna limitare il delay delle celle appartenenti ad una certa classe di servizio, la dimensione ridotta delle celle garantisce un piccolo tempo di trasmissione e quindi un più veloce controllo della presenza di pacchetti privilegiati in attesa nella coda.

Asynchronous transfer mode 43


2. Le celle grandi garantiscono un minor peso dell'header sulla quantità di dati scambiati sul link, per le celle piccole l'header potrebbe invece essere un overhead consistente.

3. Celle troppo grandi potrebbero comportare uno spreco dello spazio del link quando sono da trasmettere poche informazioni. Infatti, essendo la dimensione della cella fissa, tutto lo spazio non utilizzato dalle informazioni utili deve essere riempito da padding.

Partendo da queste considerazioni si è deciso di realizzare celle di piccole dimensioni, in particolare di 53 byte: 48 byte di payload e 5 byte di header. La dimensione non è casuale, infatti è stata scelta in modo da trasportare un campione di voce di 6 msec campionato a 64 Kbps. La dimensioni ridotta della cella impone che le informazioni di indirizzamento contenute nell'header siano piccole ed efficienti.

L'indirizzamento non può dunque essere globale, come ad esempio come avviene per IP, poiché un header di queste dimensioni non consentirebbe uno spazio d'indirizzamento sufficiente. La soluzione si può avere ricorrendo ad uno spazio di indirizzamento locale. Ricordiamo che un indirizzamento globale è caratterizzato dalle seguenti proprietà:

1. Id univoco a livello mondiale;

2. Informazioni di identificazione grandi;

3. Gestione globale degli identificativi;

4. Conoscenza globale degli identificativi.

Per un indirizzamento locale si ha invece:

1. Id locali;

2. Informazioni di identificazione piccole;

3. Gestione locale degli identificativi;

4. Necessità di elaborazione nel passaggio locale-locale per la conversione degli identificativi.

Poiché ATM è orientato alla connessione, lo switching è fatto basandosi sulle informazioni di connessione, in particolare, ogni pacchetto contiene un identificativo locale di connessione, tale identificativo è formato da due campi:

➢ Virtual Channel Identifier (VCI): è un'astrazione adoperata per descrivere un canale unidirezionale per il trasporto delle celle;

➢ Virtual Path Identifier (VPI): una ulteriore astrazione per descrivere un insieme di virtual channel, introducendo quindi un concetto di aggregazione.

In Figure 31 è mostrato graficamente il concetto di VCI e VPI:

Figure 31: VCI e VPI


Virtual PathVirtual Channel


Come si può vedere il VPI consente di aggregare una serie di flussi che percorrono uno stesso percorso, in modo da ridurre lo spazio necessario di indirizzamento, quando poi i flussi devono tornare a distinguersi, è possibile adoperare i VCI per ricondurli alle opportune destinazioni.

ATM per la prima volta si configurava come un'unica tecnologia a supporto di reti sia WAN che LAN, per questo prevede due interfacce differenti per il rapporto con utenti o con altri elementi della rete:

➢ UNI: User to Network interface, consente di collegare gli utenti alla rete. Da notare che per utente si intende anche una LAN privata che si connette ad una rete pubblica;

➢ NNI: Network to Network interface, connette fra loro reti (privata-privata o pubblica-pubblica).

Chiariti a grandi linee gli aspetti principali di ATM, passiamo a studiare il formato delle celle, che varia leggermente fra le celle scambiate nelle interfacce UNI e quelle NNI:

I campi VCI e VPI sono chiaramente gli identificatori specificati precedentemente, l'unica nota è la presenza del campo GFC nella cella UNI, che poi rappresenta anche l'unica differenza con la cella NNI che invece presenta un campo VPI che comprende anche lo spazio GFC.


Figure 32: Esempi di interfacce ATM

Figure 33: Celle ATM


GFC sta per generic flow control, ed è un campo, raramente usato, il cui scopo è quello di fornire meccanismi per il controllo prettamente locale (e quindi non utile nella rete) dell'accesso ad un link condiviso.

IV.1.1 ATM SwitchingLo spazio GFC viene lasciato al VPI nelle celle NNI perché presumibilmente nel cuore della rete c'è una maggiore necessità di spazio d'indirizzamento per i virtual path.

Dal pacchetto possiamo facilmente rilevare quanto detto, infatti, nella UNI, ci sono soltanto 256 VPI, mentre in NNI ce ne sono 4096. Per i VCI lo spazio di indirizzamento totale è di 65.536 id.

Per quanto possa sembrare un indirizzamento molto limitato, l'indirizzamento locale garantisce che tale dimensionamento sia sufficiente. Il fatto che l'indirizzamento sia locale comporta che ogni switch mantenga una tabella che associa ad una coppia VPI/VCI in ingresso una nuova coppia VPI/VCI in uscita, quindi, una connessione che viaggia su diversi hop avrà associati valori VPI/VCI differenti su ogni hop.

In realtà inizialmente si consentì uno switching solo sui VPI, quindi hop per hop veniva cambiato solo il valore VPI, mantenendo per ogni VPI gli stessi numeri VCI:

In Figure 34 gli ATM Switch hanno il compito di aggregare i VCI in appositi VPI in ingresso alla rete e in uscita disaggregarli. Come si può vedere nel primo switch i virtual channel VC4, VC1, VC3 vengono inviati in uscita tramite i virual channel VC1, VC2, VC3 aggregati nel VP1. L'ordine di questi virtual channel non varia all'interno del VP, che viene commutato in blocco, se necessario, dal VP Switch. I VC vengono disaggregati all'arrivo nell'ATM Switch di uscita.

Successivamente si è permessa un'architettura in cui si poteva avere una commutazione totale, con VC riassegnati a VP differenti (Figure 35).


Figure 34: ATM switching

Figure 35: ATM switching 2


Le tabelle di switching sono create quando si stabilisce la connessione. In caso di problemi, come ad esempio la caduta di un nodo, la connessione viene persa e deve essere ristabilita.

Le connessioni possono essere stabilita in due modi:

➢ Permanent Virtual Circuit (PVC): il circuito virtuale è stabilito in modo amministrativo e rimane attivo per lunghi periodi;

➢ Switched Virtual Cirtcuit (SVC): il circuito virtuale è stabilito al momento (on the spot) attraverso ATM signalling. In questo caso la durata è arbitraria.

IV.1.2 Payload type indicator and Cell Loss PriorityIl campo PTI è utilizzato per indicare il tipo di pacchetto trasportato, 4 tipi sono per dati utente ed altri 4 per pacchetti di gestione della rete:

0xx = dati utente;

00x = assenza di congestione;

01x = congestione;

0x0 = il pacchetto non è di user signalling; 0x1 = il pacchetto è di user signalling; 1xx = pacchetto di gestione della rete;

100 = pacchetto di controllo da switch a switch (Lo switch che lo riceve va a leggere il payload);

101 = pacchetto di controlo ent-to-end;

110 = RM cell;

111 = riservato.

Il campo CLP è invece una indicazione utile per la gestione della QoS.

IV.1.3 Head Error ControlI mezzi su cui viaggia ATM sono molto precisi, evitando dunque molti errori di comunicazione.


Figure 36: Esempio di tabelle di switching ATM


Tuttavia, è fondamentale garantire la correttezza dell'header poiché c'è il rischio che una cella, in un meccanismo orientato alla connessione, con errori nell'header giunga nel posto sbagliato. Il codice HEC garantisce un certa sicurezza di rilevazione dell'errore e la possibilità di correggere gli errori su di un bit. Le informazioni sugli errori sono poi usate per la creazione di statistiche sulla QoS.

IV.2 ATM Protocol StackLo stack protocollare ATM può essere sintetizzato in 4 livelli: fisico, ATM, ATM adaptation layer ed infine il livello delle applicazioni video, audio e dati.

Il livello di adattamento serve a rendere possibile il passaggio dei protocolli applicativi sulle celle ATM. Viene dunque definito un particolare meccanismo per ogni tipologia di applicazione, in modo da rendere possibile la traduzione del formato dati del livello applicazione, generalmente formato da pacchetti anche di dimensione considerevole, nel formato delle celle, che devono contenere al massimo 48 byte di payload. Questa traduzione non è altro dunque che l'introduzione di un meccanismo di segmentation&reassembly al di sopra delle celle ATM.

In realtà lo stack protocollare ATM è ben più complesso. Possiamo immaginarlo come formato da più piani che interagiscono fra loro per fornire il servizio di comunicazione. In questo ATM differisce sostanzialmente dal paradigma IP, dove per la risoluzioni di particolari problemi si introducono nuovi protocolli. ATM, infatti, ha un approccio monolitico, facendosi carico della gestione di tutte le operazioni per realizzare la comunicazione.

In realtà anche la parte fisica deve essere opportunamente modificata per “parlare” con ATM. Inoltre, per quanto sarebbe possibile immaginare che gli switch supportino solo fino al livello ATM, in realtà anch'essi hanno l'ATM adaptation layer (AAL) e il livello applicazioni per gestire le applicazioni di network management.Come è facile vedere ATM non corrisponde esattamente allo stack OSI, poiché è come se mancasse il livello di rete. In realtà ATM ingloba in se sia il livello link che quello rete, poiché gestisce anche funzioni di coordinamento globale come la scelta dei link e la traduzione degli identificatori locali. Inoltre l'AAL introduce anche alcune caratteristiche dei livelli OSI 4,5,7 rendendo difficoltosa la separazione di alcune funzioni per operare efficientemente l'internetworking.


Figure 37: ATM Stack

Physical Layer

ATM Layer

ATM Adaptation Layer

Voice Video Data

Figure 38: The ATM Stack in details


Come abbiamo detto, ATM deve adattarsi anche al livello fisico sottostante, per farlo si adopera un apposito sublayer del protocollo, detto Physical Medium Dependent (PMD) che ha appunto il compito di definire la velocità con cui è possibile trasferire celle ATM sul link fisico sottostante. Inoltre è presente anche un sublayer Transmission Convergence che prepara le celle ATM per la trasmissione sul link fisico.

Il livello ATM (come presentato in Figure 39) è il vero cuore del sistema, poiché si occupa della comunicazione end-to-end e del cell switching. Va sottolineato che dato l'approccio orientato alla connessione, le celle vengono consegnate a destinazione nello stesso ordine di invio. Inoltre, come si è potuto appurare, non ci sono meccanismi per il flow control o l'error control fra gli hop, ma solo a livello degli end-point, questo poiché le probabilità di errore o di perdita dei pacchetti sono remote. Tuttavia, in caso di problemi, si fa affidamento sui protocolli di livello superiore, come potrebbe essere TCP, per il recupero dei dati persi. Da notare che questo corrisponde al reinvio di un gran numero di celle ATM, poiché si deve ritrasferire un'intera PDU (protocol data unit) TCP.

IV.3 ATM AddressingPer quanto abbiamo detto che ATM adopera indirizzamento locale, in realtà sono presenti anche degli indirizzi ATM univoci che identificano switch ed end-point. La presenza di questi indirizzi è tuttavia necessaria soltanto per le operazioni iniziali di stabilimento della connessione fra i terminali.

Gli indirizzi sono differenti per reti pubbliche e private. Le prime adoperano gli indirizzi E.164, le seconde adoperano il formato NSAP.

IV.4 ATM Quality of ServiceUna delle caratteristiche più interessanti di ATM è il suo supporto alla QoS. ATM prevede l'inserimento di ciascuna connessione in una delle possibili 5 classi di servizio: Constant bit rate real time, Variable bit rate real time, Variable bit rate non real time, Available bit rate, Unspecified bit rate. Queste classi di servizio sono associate ad un insieme di parametri utili a stabilire la QoS:

Cell Loss Ratio: informazione ottenuta anche grazie alle statistiche ottenute dal controllo HEC. Questo parametro è abbastanza semplice da quantificare ed è stato usato estensivamente per dimensionare opportunamente gli switch ATM e negli algoritmi di


Figure 39: ATM layers in details 2


admsission control; Cell Misinsertion Rate: celle che sono arrivate con indirizzi incongruenti in un prefissato

intervallo di tempo;

Cell Error Ratio: percentuale di celle consegnate con errori all'interno del payload;

Severely Errored Cell Block Ratio: errori che si verificano in blocchi di celle, questo parametro è tenuto in conto poiché i guasti hardware sono raramente transienti, quindi gli errori sono immessi in più celle;

Cell transfer delay: il tempo preso per trasferire una cella end-to-end ;

Mean cell transfer delay; Cell delay variation: distanza di un singolo delay dalla media dei delay.

Per caratterizzare il traffico in ingresso alla rete anche ATM adopera il Token Bucket. Il servizio richiesto viene quindi specificato attraverso i parametri precedentemente elencati, mentre il traffico inviato si caratterizza con la definizione dei parametri del Token Bucket.

Chiaramente la rete ATM può garantire la QoS solo se mette in atto strategie di controllo del traffico. Nel seguito sono presentati i principali meccanismi.

IV.4.1 Connection Admission ControlE' il principale meccanismo attuato da ATM, una connessione viene accettata solo quando ci sono sufficienti risorse per supportarla. Il meccanismo decide se una connessione può essere accettata durante la fase di set-up della stessa. L'utente specifica le caratteristiche del traffico generato e la QoS richiesta (SLA). La rete, attraverso un algoritmo distribuito, calcola la sua capacità di garantire quella QoS.

IV.4.2 Flow controlIl flow control verifica che siano rispettati i requisiti dichiarati all'inizio della connessione. Il controllo è fatto valutando il tempo che intercorre fra due celle successive del flusso. Si controllano due valori, il valor medio e quello minimo. Se non si rispettano le condizioni dettate dal SLA, la rete applica delle “punizioni” al traffico non in regola. Tali punizioni possono essere:

➢ rilascio della connessione;

➢ eliminazione delle celle

➢ etichettatura delle celle: in questo caso la rete imposta il flag CLP per segnalare che questi pacchetti saranno i primi da eliminare in caso si verifichi congestione.

Chiaramente questo meccanismo raggiunge la massima efficienza se combinato con la caratterizzazione del traffico.

IV.4.3 Service classesIn precedenza abbiamo già nominato le differenti classi di servizio, tuttavia, adesso è conveniente specificarle con maggior precisione per indicare anche la loro effettiva utilità:



1. Constant bit rate real time, CBR: applicazioni che richiedono un delay garantito ma che hanno un traffico dati costante;

2. Variable bit rate real time, VBR-rt: applicazioni che richiedono un delay garantito e che generano un traffico variabile;

3. Variable bit rate non real time, VBR-nrt: applicazioni che non richiedono un delay garantito e che generano un traffico dati variabile;

4. Available bit rate, ABR: è una classe particolare utilizzata per lo scambio di messaggi per la gestione della congestione della rete. In particolare si adoperano i messaggi RM.

5. Unspecified bit rate, UBR: corrispondente al classico best-effort.Uno dei problemi fondamentali della QoS è il riservare le risorse necessarie a garantire le prestazioni. Una possibile soluzione è dividere la capacità totale del link in opportune aree, ciascuna dedicata ad una classe. Ad esempio, si avrebbe una parte del link dedicata a CBR, una parte a VBR e il rimanente a UBR/ABR (le due classi vengono spesso accomunate).

Chiaramente in questo caso la banda per UBR potrebbe anche essere del tutto nulla se le altre classi consumano tutte le risorse.

IV.5 ATM Adaptation LayerUna componente molto importante di ATM è l'AAL. Questo componente ha il compito di disaccoppiare i dettagli di ATM dalle applicazioni.

Il livello di convergenza introduce al messaggio proveniente dall'applicazione un header ed un trailer, per poi passarlo al livello SAR (segmentation and reassembly) che a sua volta aggiunge header e trailer SAR. Ogni output del SAR è di esattamente 48 byte, quindi può essere passato al livello ATM.


Figure 40: Allocazione spazio del link

Figure 41: AAL


Il livello AAL è in realtà formato da 4 categorie, che servono a fornire il supporto a diversi tipi di applicazione. Ogni applicazione adopera dunque un particolare AAL.

IV.5.1 AAL 1L'AAL 1 è adoperato per applicazioni che adoperano un'emulazione di circuito, quindi che simulano un canale punto-punto tipo TDM (time division multiplexing), oppure anche per applicazioni audio che presentano un constant bit-rate, quali applicazioni di audio e video digitali. Poiché queste applicazioni sono CBR, conoscendo la quantità dati prodotta, la tempificazione di chi produce il traffico ed il delay introdotto dalla rete, possiamo risalire ad una precisa tempificazione fondamentale per questa tipologia di applicazioni real time.

L'incapsulazione SAR per AAL 1 ha la seguente struttura:

Il sequence count indica il numero di cella, e, poiché in queste applicazioni la tempificazione è fondamentale, il CRC successivo è un controllo soltanto sul sequence count.AAL 1 garantisce inoltre un buffer, nel convergence sublayer, per eliminare il jitter fra le celle. Le celle sono sempre consegnate con CBR, anche se il loro delay varia, seppur di poco, fra cella e cella. Il numero di sequenza garantisce inoltre la possibilità di verificare la presenza di celle perse o inserite male.

IV.5.2 AAL 2AAL 2 è realizzato per applicazioni real time VBR. Generalmente queste sono applicazione di video ed audio compressi. Per comprendere il funzionamento di AAL 2, dobbiamo considerare che su di una singola connessione ATM possono viaggiare flussi provenienti da distinte sorgenti. Si rende necessario n meccanismo di separatori di tali flussi a livello applicazione. AAL 2 effettua dunque un multiplexing di diversi flussi nella stessa connessione ATM. Dal lato del ricevente, effettua invece il de-multiplexing per ricondurre le informazioni provenienti dalla connessione ai singoli flussi. Questi servizi sono realizzati nel convergence sublayer, che si divide a sua volta in service specific convergence sublayer(SSCS) e common part sublayer (CPS).Ogni flusso è servito da un separato SSCS che è poi associato al CPS.


Figure 42: SAR per AAL 1

Figure 43: AAL 2: SSCS e CPS


Il formato delle celle AAL 2 è il seguente:

OSF: è un offset che indica dove comincia il nuovo CPS-packet nel payload. Questa particolare funzione è stata introdotta per permettere l'invio di parti di dato in pacchetti differenti. Lo start field è sempre l'header iniziale della cella e consultandolo si può verificare se i dati dopo lo start field sono da considerare come completamente del precedente dato e quindi, dove comincia il nuovo packet header;

SN: sequence number;

P: controllo di parità;

CID: channel identifier, identifica un canale, la decisione sul numero di ogni canale è presa a priori tramite il servizio ANP dell'AAL;

LI: indica la lunghezza del payload;

UUI: trasferisce informazioni di tipo protocollare (signalling, dati) direttamente fra gli gli end-point.

IV.5.3 AAL 3/4Questo AAL non deve gestire più applicazioni real time anche se tratta comunque applicazioni VBR, di tipo burst, cambia dunque la priorità e, anziché garantire il delay, si preferisce garantire la correttezza. Non c'è più la necessità di portare informazioni di tempificazione, che vengono invece sostituite da controlli di correttezza sul payload e da serial number per identificare le perdite di pacchetti.

I messaggi dell'applicazione sono prima incapsulati in un formato di pacchetto che prevede un header ed un trailer per individuare l'inizio e la fine di ciascun messaggio, per poi essere segmentati e incapsulati nelle celle ATM.

Il formato di tali celle è fatto da un header che contiene informazioni sul tipo di segmento, numero di sequenza, ed un campo riservato per l'eventuale multiplexing del canale, e da un trailer che contiene un indicatore di lunghezza ed il controllo CRC sul payload.

Come per AAL 2, bisogna considerare che quando si fa il multiplexing su di un singolo canale ATM di più flussi, tali flussi riceveranno tutti la stessa QoS dalla rete ATM. Questo meccanismo va dunque adoperato con attenzione.

IV.5.4 AAL 5L'introduzione di questo ulteriore AAL avvenne per tentare di ridurre la complessità e l'efficienza dell'utilizzo di ATM su reti locali. AAL 5 non fa altro che aggiungere una coda di 8 byte ad ogni pacchetto che contiene un campo riservato, una indicazione sulla lunghezza del payload ed un CRC


Figure 44: Formato delle celle AAL 2


di 32 bit. Questo pacchetto viene direttamente incapsulato nelle celle standard ATM, di cui pero', per gestire la segmentazione, si adopera il campo d 2 bit PIT, che viene impostato opportunamente per segnalare quando una cella è l'ultima di un pacchetto. In questo modo si comunica solo qual è l'ultima cella, dopo la quale si assume che la cella successiva sia la prima di un nuovo pacchetto.

Questo approccio è stato quello preferito da IETF per il mappaggio del trasferimento di pacchetti IP su ATM.

IV.6 Call and Connection ControlAbbiamo visto che ATM è orientato alla connessione e che gestisce la QoS. Per stabilire la connessione e per negoziare la QoS è necessario un opportuno sistema di controllo. Inoltre, ATM permette anche connessioni point-to-multipoint che devono essere anch'esse gestite.

Vediamo dunque quali sono i comandi della user to network interface (UNI):● Stabilimento della chiamata

○ SETUP;

○ CALL PROCEEDING;

○ CONNECT;

○ CONNECT ACK;

● Annullamento della chiamata

○ RELEASE;

○ RELEASE COMPLETE;

● Point-to-Multipoint

○ ADD PARTY;

○ ADD PARTY ACK;

○ ADD PARTY REJ;

○ DROP PARTY;

○ DROP PARTY ACK;

● Misc

○ RESTART(VC);

○ STATUS ENQUIRY;

○ STATUS.

Nel seguito si presenta la dinamica per stabilire una connessione. Da notare che nel SETUP si inviano anche le informazioni riguardanti la QoS:


Figure 45: ATM call signalling


IV.7 ATM in LANATM era una tecnologia che poteva risolvere parte dei problemi legati alla banda disponibile nelle LAN. Per rendere possibile questa soluzione, era necessario garantire una compatibilità con i frame delle tecnologie IEEE 802.X.

Le differenze fra queste tecnologie però sono considerevoli:

➢ Le classiche LAN sono connectionless mentre ATM è orientata alla connessione;

➢ Le LAN possono inviare in broadcast su mezzo condiviso le informazioni;

➢ Le LAN adoperano indirizzi MAC mentre ATM indirizzi in stile telefonia.

Per risolvere questi problemi si è definito LANE (LAN Emulation), un insieme di regole per emulare le caratteristiche di una classica LAN su ATM. Sostanzialmente LANE fornisce un sistema per far lavorare qualsiasi LAN su ATM, oltre a fornire la possibilità di connettere fra loro sistemi ATM e sistemi su LAN, e permettere anche la convivenza di più LAN simulate sulla stessa rete fisica ATM. Sostanzialmente quello che fa LANE è tradurre gli indirizzi MAC di 48 bit in quelli ATM di 20 byte, convertire i pacchetti in celle con AAL 5.

Chiaramente oltre al vantaggio di avere ATM come sistema di comunicazione a larga banda inserito in modo praticamente trasparente, ci sono una serie di svantaggi, quali la perdita del supporto alla QoS ed alcuni problemi di efficienza e scalabilità.

IV.7.1 LANE ArchitectureIl primo problema da risolvere è l'adattamento di ATM alla caratteristica della LAN di essere a mezzo condiviso. Una soluzione iniziale potrebbe prevedere l'utilizzo di una maglia di connessioni punto-multipunto che però porterebbe ad una struttura di connessioni molto pesante da sostenere. Si predilige quindi un approccio software basato su server di connessione (Figure 46).

I server adoperati sono 3:

➢ LES (Lan Emulation Server): converte i MAC address in indirizzi ATM. La sua funzione è simile a quella delle “pagine bianche”. Data l'alta mobilità dell'ambiente, le entità dell'architettura devono interagire spesso con il LES per aggiornare la sua banca dati;

➢ BUS (Broadcast and Unknown Server): per il broadcast diretto dei pacchetti. Per gestire il broadcast il server apre connessioni con tutti i partecipanti alla rete. Questo gli consente


Figure 46:


anche di fornire funzionalità simili a quelle del protocollo ARP;

➢ LECS (Lan Emulation Configuration Server): per gestire la configurazione della rete;

Solitamente i 3 server sono posizionati all'interno degli switch ATM.

IV.8 IP over ATMData la difficoltà di interfacciamento con le LAN, si è pensato di mettere direttamente IP su ATM. La tecnica proposta è quella di mettere IP sopra ATM in una singola sottorete logica IP (LIS).

Una LIS è un gruppo di host IP che condividono stesso numero di rete e subnet mask e che comunicano fra loro direttamente tramite connessioni ATM.

Chiaramente è lecito aspettarsi un certo rallentamento prodotto dall'alta componente software ed anche un aumento di inefficienza causato dall'aggiunta di strati protocollari rispetto alle tradizionali LAN composte dal singolo livello data link.

Ogni membro della LIS ha sia un indirizzo ATM che uno IP. Gli indirizzi IP sono convertiti in indirizzi ATM tramite il protocollo ATMARP internamente alla LIS (protocollo basato su ARP). Il protocollo InATMARP compie invece la conversione duale.

Un ATMARP server mantiene una tabella o una cache di mappaggio fra indirizzi IP ed ATM. Tali indirizzi sono appresi attraverso lo scambio di messaggi fra ATMARP e gli host della LIS. Tipicamente questo server è contenuto direttamente negli switch ATM.


Reti di calcolatori II Capitolo V

Capitolo VMulti Protocol Label Switching

Con l'aumentare del traffico dati e delle applicazioni a questo connesse, si è sentita sempre più la necessità di aumentare le prestazioni di Internet non ricorrendo soltanto all'aggiunta di risorse. La considerazione principale che si è fatta per ottenere questo risultato è che il routing è molto complesso nel cuore della rete, dove le tabelle sono di grandi dimensioni, mentre alle estremità è molto più semplice. In aggiunta, l'aumento della capacità dei link non ha fatto altro che rendere ancora più pesante il lavoro dei router che si trovano a dover lavorare con molti più dati.

Una rete come quella ATM nasceva proprio per risolvere problemi del genere, tuttavia la sua struttura è troppo costosa e complessa perché venga adoperata in Internet. Un possibile approccio per limitare la complessità potrebbe essere l'utilizzo di ATM come rete fisica e di IP come rete di overlay su ATM. La rete IP dovrebbe avere dunque un numero ridotto di contatti con la rete ATM. Si avrebbe qualcosa di simile alla rete IP che rappresenta tunnel, “autostrade” su cui viaggiano dati, mentre ATM si occupa della diffusione capillare.

Questo risolverebbe il problema delle prestazioni perché lo switching è un'operazione decisamente più veloce del routing. Infatti nel primo caso si ricerca semplicemente un “indice” in una tabella per individuare il percorso da seguire, nel secondo si opera una ricerca a maggiore somiglianza di prefisso. A ciò si aggiunge che nel routing si ha un “riassemblaggio” del pacchetto IP, mentre in ATM no. In sostituzione ATM aggiunge un tempo per la creazione della connessione che va però sostenuto una sola volta.

Per questa ultima considerazione è chiaro che va preferita una comunicazione orientata alla connessione quando c'è un flusso continuo di dati da scambiare, mentre applicazioni con traffico altamente discontinuo è conveniente farle lavorare su di una rete che fa routing.

Un primo sviluppo di una idea del genere fu fatto dalla Ipsilon. L'idea di base era abbastanza semplice, utilizzare ATM come rete fisica di base ponendo al di sopra di questa i router IP. Ogni switch ATM aveva così anche la parte di routing IP, però la gestione dei VC era differenziata: alcuni VC erano per le trasmissioni “corte” quindi i dati da loro trasportati venivano sempre passati al livello IP, altri erano per le trasmissioni “lunghe” (i tunnel!) e passavano in modo trasparente per il livello IP in diversi switch ATM.

L'Ipsilon ha inoltre dimostrato che il 90% del traffico dati scambiato sulla rete adopera un concetto di flusso, rendendo valida l'applicazione dei concetti esposti, inoltre il software necessario a realizzare i protocolli a supporto di tale soluzione è estremamente semplice, comportando un bassissimo overhead.

In realtà il problema della soluzione esposta è che ciascuno switch doveva dotarsi di questo flusso e gestire per ogni flusso l'apposito VC. Nel cuore della rete questa soluzione diviene non scalabile.

Multi Protocol Label Switching 57


L'alternativa fu proposta da CISCO, che presentò una soluzione basata sull'aggiunta di etichette ai pacchetti scambiati sulla rete per realizzare uno switching di flusso. Dei router di ingresso hanno il compito di introdurre le etichette sui pacchetti che poi vengono indirizzati nel cuore della rete tramite tali etichette. In uscita ulteriori router eliminano le etichette permettendo la ripresa del normale routing del pacchetto per raggiungere capillarmente una destinazione.

V.1 MPLSLa proposta di CISCO è stata considerata valida ed ha dato vita allo standard MPLS. L'architettura MPLS è analoga a quella proposta da CISCO:

➢ Label distribution protocol, LDP: ha il compito di distribuire le etichette fra i router;

➢ Label Switched Path, LSP: individua un tunnel MPLS;

➢ Forwarding Equivalence Class, FEC: rappresenta una regola di trattamento del traffico in ingresso che viene attuata in base all'etichetta;

➢ Label Switching Router, LSR: router interno alla rete con supporto ad MPLS;

➢ Label Edge Router, LER: router di ingresso alla rete MPLS, ha il compito di inserire/eliminare le etichette.

Da notare che MPLS è detto multi-protocol perché la sua definizione è del tutto indipendente sia dai protocolli superiori che da quelli inferiori nello stack.

Il funzionamento è abbastanza semplice: un pacchetto IP giunge ad un LER tramite il routing tradizionale. Viene valutata la sua destinazione, e, se per tale destinazione è presente un LSP nella tabella del router, il pacchetto viene incapsulato in un header MPLS e mandato lungo tale LSP. All'uscita dall'LSP un ulteriore LER provvederà ad eliminare l'header MPLS.

Durante il LSP il pacchetto attraverserà vari LSR. Nel pacchetto IP si tiene conto di questa distanza aggiornando della dimensione del LSP il campo TTL, in modo da non compromettere il significato di tale valore.

L'header MPLS è di 32 bit, così costituiti:

20 per il label;

3 per EXP: experimental bits;

1 bit per Stacking: si adopera per fornire l'opportunità di creare uno stack di etichette e quindi una gerarchia di flussi;

8 bit per TTL: la copia del campo TTL del pacchetto IP.

Il numero ridotto di etichette non è un problema poiché i flussi che si considerano sono in realtà aggregati, quindi ciascun flusso è utilizzato da dati provenienti da molteplici fonti. Inoltre la scelta della label avviene su base locale, quindi ogni router può adoperare l'intero spazio disponibile per l'assegnazione delle label, comunicandole poi ai router vicini tramite LDP.

Per i protocolli di livello inferiore si sono definite opportune regole per il mappaggio delle label MPLS negli header di tali protocolli.

Nella successiva figura è mostrato un esempio di funzionamento di MPLS:



Figure 47: MPLS example

Ciascun router tramite LDP comunica ai suoi vicini il label che ha assegnato a quel particolare percorso. Quando in A arriva il pacchetto con destinazione nella sottorete 134.112/16, A verifica che esiste un LSP verificando la sua tabella ed inserisce l'etichetta 22. Il successivo router sul LSP si limita a fare il label switching, ossia sostituisce il valore dell'etichetta con quella del canale con il successivo router. Viene dunque cambiato il valore da 22 a 41. Quando infine il pacchetto giunge in Z, il router che è un LER, si accorge che è finito il LSP e provvede ad eliminare l'etichetta, procedendo all'instradamento IP tradizionale.

Fino ad ora abbiamo sorvolato sul come creare gli LSP, i meccanismi sono due:

1. Quando i router percepiscono una certa configurazione del traffico, istruiscono la rete per la creazione delle opportune connessioni, gestendo le opportune label. Questo approccio non garantisce però una decisione strategica sul lungo periodo per la gestione del traffico;

2. L'alternativa è adoperare un source-routing. In altre parole si decide a priori il percorso in base a considerazioni per massimizzare il vantaggio per la rete. Questo è un modo anche per pianificare la gestione del traffico della rete attraverso un routing esplicito. Inoltre, si garantisce la possibilità di impostare il routing in base a delle policy personalizzate e non più su base del classico routing ip.

Per questa soluzione sono però ancora da risolvere del tutto i problemi legati al signaling, per cui le proposte di risoluzione si basano sue due protcolli: CR-LDP, RSVP ext.


A

Z

134.112/16

IP packetdest:134.112.1.5

Dest. 134.112/16

MPLS lbl

22

MPLS lbl ing 22

MPLS lbl ex

41

MPLS lbl ing 41

MPLS lbl ex

2

MPLS ingr 2

Dest

134.112/16

Reti di calcolatori II Capitolo VI

Capitolo VITraffic Engineering

Le attuali reti IP sono in grado di gestirsi da sole? I protocolli di routing e il TCP effettivamente forniscono questa capacità alle reti IP, purtroppo, però, questa gestione non è efficiente poiché i percorsi selezionati potrebbero anche essere quelli più congestionati.

La disciplina del traffic engineering tenta di risolvere proprio questa tipologia di problemi:

“Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks. Traffic Engineering encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic”Distinguiamo due approcci in tale disciplina: Ip-based, MPLS based.

VI.1 IP-based Traffic EngineeringNelle tradizionali reti Ip l'instradamento è calcolato sulla base della destinazione del pacchetto. Gli algoritmi di routing non fanno altro che lavorare sulla topologia della rete, definita oltre che dalla struttura dei link, anche dal peso a questi associato. Quest'ultimo parametro è fondamentale nel calcolo dei percorsi.

Poiché l'assegnazione dei costi ai link viene fatta dagli amministratori di rete, è possibile incidere su tale parametro per condizionare le decisioni sulle tabelle di instradamento. Solitamente la scelta viene fatta basandosi su delle euristiche, come la proporzionalità all'effettiva distanza fisica oppure impostando il costo in modo inversamente proporzionale alla capacità del link. Il traffic engineering adopera un modo più ingegneristico per la risoluzione del problema, adoperando un approccio basato sulla misurazione del traffico e della topologia della rete per ottenere un modello dell'intera rete e ricavare quindi le opportune configurazioni da apportare. Questo approccio è in realtà ciclico, poiché dopo aver apportato una modifica alla rete si procede a rimisurarne le caratteristiche e quindi si riprende con i precedenti passi.

Le informazioni raccolte sono sostanzialmente due:

1. Topologia della rete, comprendendo anche la capacità dei link;2. Matrice del traffico, ossia il traffico scambiato fra ciascuna coppia di nodi.

Il modello della rete che si sviluppa, partendo da queste informazioni deve ottenere i pesi da assegnare a ciascun link per bilanciare il carico di rete.

Per ricavare gli input il problema sorge quando non si è amministratori di un dominio, poiché bisogna affrontare tutti i problemi legati alla scoperta della topologia. Questo non è però il nostro

Traffic Engineering 60


caso, poiché ci stiamo ponendo nell'ottica di chi vuole amministrare al meglio il traffico del proprio dominio. Dando per scontato dunque che conosciamo la topologia, per calcolare il traffico fra due router è sufficiente adoperare le funzionalità di logging di questi ultimi.

Il modello matematico che si sviluppo per ricavare i costi è conosciuto come modello di flusso multi-commodity, in cui si opera su di una rete G(R,L), con R router e L link unidirezionali fra questi, con un costo c l assegnato ad ogni link l. Sulla rete è definita una matrice di traffico

M ij che rappresenta il traffico dal router i a quello j.

La risoluzione di questo modello darà i pesi w l da assegnare ad ogni link e la frazione di traffico che va dal router i al router j attraverso ogni link l indicata dalle variabili P i , j ,l . Chiaramente si deve tener conto che un router selezionerà sempre il percorso a costo minimo, quindi, perché ci sia un bilanciamento del traffico, è necessario fornire più percorsi allo stesso costo minimo ad un router, in modo che possa operare operazioni di load balancing. La funzione obiettivo del modello di ottimizzazione presentato potrebbe avere un andamento del tipo:

Con ρ che indica l'utilizzazione del link. Purtroppo un problema del genere è NP-completo, quindi il calcolo di una soluzione ha tempi con crescita esponenziale all'aumentare della dimensione del problema.

Per ottenere un risultato in tempi ragionevoli si opera un calcolo basato sulla ricerca di ottimi locali. L'algoritmo parte da una soluzione iniziale di tentativo. Da questa, vengono calcolato tutti i minimi percorsi fra le coppie di router e il traffico passante fra questi in base alla soluzione tentativo. Si ottengono così i primi valori della funzione obiettivo. Perturbando tale soluzione si ricerca l'ottimo locale. Varie tecniche possono semplificare il calcolo, ad esempio, conservando le precedenti configurazioni di costo esaminate, in modo da evitare loop nel calcolo.

Questo algoritmo viene fermato relativamente presto nella sua esecuzione, poiché non si esaminano tutte le soluzioni possibili. Lo scopo non è infatti giungere all'ottimo, ma ottenere una buona soluzione.

AT&T ha adoperato questa soluzione, effettuando queste impostazioni di riconfigurazione nei periodi notturni di scarso traffico, sperimentando risultati migliori del tradizionale modo di impostare i costi basato sulle euristiche.

VI.2 MPLS-based traffic engineeringNei precedenti capitoli abbiamo visto il funzionamento di MPLS, ricordiamo che la caratteristica principale di questo sistema è la possibilità di gestire il routing tramite etichette. I pacchetti, con MPLS, sono identificati all'ingresso della rete ed associati ad un LSP. Questa associazione può


ρ

c


essere fatta sulla base del prefisso destinazione, come nel tradizionale routing, ma anche sulla quintupla degli indirizzi mittente/destinazione, porte mittente/destinazione e protocollo, oppure ancora in base alla particolare interfaccia di provenienza del traffico.

Per creare le LSP la definizione dei protocolli è ancora in fase di consolidamento, tuttavia possiamo dire che LDP ed RSVP si adoperano per la definizione dei LSP sulla base delle tabelle di routing, mentre CR-LDP e RSVP-TE si adoperano per stabilire LSP esplicitamente. Proprio quest'ultima possibilità, la definizione esplicita delle rotte, fornisce una grande flessibilità rispetto al tradizionale routing IP basato sulla destinazione. In teoria, in una rete MPLS si potrebbe giungere alla soluzione ottima per il problema generale del routing.

L'unione della definizione esplicita delle rotte e di una definizione a grana fine delle forward equivalence class (FEC), ossia delle classi di traffico che indicano in quale LSP deve essere immesso un pacchetto, consente di gestire la selezione del LSP in base ai requisiti di QoS dei flussi. Per ottenere questo risultato è, chiaramente, necessario che il flusso specifichi i suoi requisiti al router di ingresso alla rete MPLS, che provvede a realizzare l'opportuno LSP esplicito per quel flusso.

In questo caso, la scelta del LSP nel quale convogliare il traffico è fatta in base ad una valutazione delle risorse disponibili. Assumendo che il flusso richieda una larghezza di banda B fra la sorgente s e la destinazione d, indicando con R(l) la banda residua di ciascun link, è chiaro che il LSP selezionato sarà quello nei quali tutti i link che lo compongono hanno R(l)>B.

Se l'approccio adoperato è di potare dalla lista delle nostre scelte tutti i percorsi con R(l)<B, tutti i percorsi rimanenti della “rete potata” sono percorsi che possono supportare quel flusso. La scelta fra questi può dunque essere eseguita per migliorare l'utilizzo delle risorse. In particolare, la scelta viene compiuta tramite il widest shortest path (WSP), si seleziona il percorso con meno hop fra tutti i percorsi della “rete potata”. Se ci sono più percorsi con lo stesso numero di hop, si seleziona quello con il maggiore R(l).

Formalizzando meglio il comportamento di molti algoritmi di traffic engineering, possiamo individuare il seguente approccio:

➢ si potano i link che non hanno sufficiente banda;

➢ si assegnano a ciascun link un costo nella rete potata;

➢ si seleziona il percorso a costo minimo.

Quello che è molto importante, ancora una volta, sono le tecniche per assegnare i costi.

Esaminiamo ora due tecniche per la selezione dei LSP:

➢ Minimum Interference Routing (MIRA): considerando conosciuta la coppia ingresso-uscita, MIRA seleziona il percorso che minimizza l'interference. Per interference su di una coppia ingresso-uscita (s,d) si intende quel fenomeno che a causa del routing fra un'altra coppia (s,d), fa ridurre il massimo flusso di rete fra s,d. Quindi il percorso che minimizza l'interference è quello che sfrutta al meglio le risorse. Poiché il peso dei link deve essere impostato proporzionalmente alla riduzione del massimo flusso, il problema è NP-completo.

➢ Simple Minimum Interference Routing (SMIRA): il calcolo dell'interference è eseguito come se si debbano calcolare k percorsi minimi, anziché il massimo flusso. I passi sono i seguenti:

○ Sono selezionati k percorsi eseguendo il widest shortest path fra s e d.

○ Tutti i link di questi percorsi con una banda pari alla banda più piccola fra i percorsi



sono potati.

○ Il secondo percorso è il widest shortest path nella rete potata;

○ Questa procedura è reiterata fin quando non sono stati trovati o K percorsi o nessun altro percorso è disponibile.

Il costo dei link che appartiene all'insieme dei K percorsi è aumentato proporzionalmente al peso del percorso ed al rapporto fra la banda più piccola (il bottleneck) e la banda residua.


Reti di calcolatori II Capitolo VII

Capitolo VIISDH/SONET

Per le sue caratteristiche di bassa attenuazione e poco disturbo, la fibra ottica è un ottimo mezzo per il trasporto di grandi quantità di dati. SDH e SONET sono due standard, quasi del tutto uguali, per la comunicazione su fibra ottica. SDH è lo standard definito dall'ITU, SONET è la versione utilizzata in america, definita dall'ANSI. Con questi standard la capacità di trasmissione dati su fibra e nell'ordine dei Gbs.

Gli obiettivi iniziali della standardizzazione furono l'acquisizione di indipendenza ed interoperabilità dai fornitori dei sistemi, l'eliminazione di tutte le operazioni manuali, la riduzione del costo delle operazioni, la protezione da fallimenti nei nodi o rotture dei cavi. In poche parole si voleva fornire un servizio più affidabile, meno costoso e allo stesso tempo più veloce.

Poiché questo processo nasce inizialmente per il supporto alla rete telefonica, l'unità di trasmissione base è fissata a 155,520 Kbps, un valore diretta conseguenza del teorema di Nyquist-Shannon. SDH supporta però comunicazioni a rate ben più alti, definiti come multipli interi dell'unità di trasmissione base, ad esempio STM-4 ha una capacità di 622.08 Mbps, STM-16 di 2488.32 Mbps.

Il limite superiore alla velocità di trasmissione non è imposto dallo standard, ma dai limiti tecnologici. Va sottolineato che la durata di un qualsiasi frame STM-N è sempre 125μs. Questa imposizione è necessaria per garantire la corretta tempificazione dei segnali, SDH infatti lavora in TDM(Time division Multiplexing).La rete SDH è divisa in diversi layer strettamente collegati alla topologia di rete. Il livello più basso è quello che rappresenta il media di trasmissione. Per quanto si è detto che SDH viaggia su fibra, è possibile adoperare anche canali radio o satellitari. Il livello successivo è quello regenerator che copre le necessità dei percorsi fra i rigeneratori di segnale. Sopra questo livello trova posto il livello di gestione del multiplexing. Infine c'è il livello virtual container (VC) che ha il compito di fare il mappaggio fra i segnali dei livelli superiori e il modulo di trasporto SDH (Figure 48).

Attualmente le reti SDH sono composte da 4 tipi di elementi:

SDH/SONET 64

Figure 48: Come sono dislocati i livelli della gerarchia SDH


➢ Regenerator: hanno il compito di rigenerare il clock ed i livelli dei segnali in ingresso. Riescono a derivare il loro clock dai segnali dati in ingresso;

➢ Terminal Multiplexers: hanno il compito di multiplexare un insieme di segnali tributari (provenienti dai livelli superiori, ATM, PDH, ecc.) in un unico segnale;

➢ Add/Drop Multipexers: hanno il compito di aggiungere/estrarre uno dei segnali precedentemente “multiplexati” nella trasmissione;

➢ Digital Cross-Connect: questo elemento ha un vasto insieme di funzioni, consente infatti di mappare i segnali tributari in virtual containers così come di fare lo switching di vari container anche di diverse velocità. Vista la complessità di questo elemento che richiede elaborazioni sui segnali, deve essere necessariamente essere realizzato per via elettronica e non otticamente, questo comporta una consistente riduzione di velocità.

La connessione di questi elementi solitamente segue un approccio ad anello, per ragioni di affidabilità. Bisogna considerare che l'applicazione per cui nascono queste reti è la fonia, quindi, è necessario recuperare la caduta di un link in tempi di ms. La struttura ad anello permette questa rapidità di risposta grazie alla presenza di switch automatici che passano sul link integro appena si accorgono che l'altro link in ingresso è caduto (Figure 49).

VII.1 SDH FrameIl frame base SDH ha il formato synchronous transport module (STM), STM-1 è il livello base. Il frame SDH è formato da 9 righe di 270 byte e come già detto dura 125μs. I primi 9 byte di ogni riga contengono le informazioni necessarie a gestire la tempificazione, i restanti formano il payload che può essere assegnato in vari modi per trasportare diversi segnali con bit rate inferiore. Ciascuno di questi segnali ha il suo campo di overhead.

VII.2 Differeces between SONET and SDHLa prima differenza fra i due standard è nei segnali tributari con cui lavorano, per via del differente

SDH/SONET 65

Figure 49: Unidirectional Path Switched Ring


contesto tecnologico in cui operano. Questo è principalmente dovuto al fatto che questi standard sono andati a rimpiazzare un certo numero di tecnologie, dovendo quindi adattarsi per procedere in modo graduale a tale sostituzione.

Poiché i due standard furono sviluppati in contemporanea, si tenne conto in fase di progetto della loro futura integrazione. Per questo motivo la conversione fra i due standard è molto semplice e richiede soltanto pochi byte di overhead.

SDH/SONET 66

Reti di calcolatori II Capitolo VIII

Capitolo VIIIIP su reti ottiche

Le attuali reti di trasporto realizzano l'intero stack IP, Atm, SONET, DWDM. Chiaramente ciascun layer ha la sua funzione ma così tanti livelli non fanno altro che incrementare la complessità sia di gestione che di realizzazione. In aggiunta, si ha una inevitabile perdita di efficienza, che porta ad un utilizzo della banda totale disponibile soltanto al 50% per l'effettivo trasporto di informazione. L'obiettivo, attualmente, è semplificare questa struttura grazie all'utilizzo di generalized MPLS (GMPLS) per il trasporto IP e di un sottile strato protocollare di adattamento fra SONET e GMPLS.

VIII.1 DWDMWDM è una sigla che indica wavelenght division multiplexing, sostanzialmente corrisponde alla stessa operazione che si fa in TDM, ma anziché considerare il tempo si fa il multiplexing delle lunghezze d'onda. Questo comporta che diversi segnali occupino contemporaneamente la stessa fibra. Appositi ADM (add/drop multiplexer) e XC (cross-connect) provvedono poi a fare le operazioni di switching come avviene per il tempo nelle reti SONET.

Il WDM si applica in due varianti:

➢ Coarse WDM: adopera solo 2 o 4 lunghezze d'onda distanti fra loro, per il trasporto dei dati;

➢ Dense WDM: adopera una distanza minima fra le lunghezze d'onda, permettendone un gran numero sulla stessa fibra. In laboratorio si è riusciti ad introdurre fino a 1000 diverse lunghezze su di una singola fibra.

Esaminiamo i componenti di questa rete, che corrispondono sostanzialmente a quelli SONET:

➢ Optical amplifier: sono amplificatori che amplificano interamente il segnale passante sulla fibra. In questo modo le varie lunghezze d'onda sono tutte amplificate. Per quanto questo amplificatore analogico tenti un'amplificazione lineare, in realtà questo comportamento ideale è difficilmente ottenibile, vengono infatti introdotti disturbi, inoltre, il rumore che accompagna il segnale viene anch'esso amplificato;

➢ Regenerators: i rigeneratori risolvono i problemi degli OA estraendo le lunghezze d'onda, riconvertendole in digitale e rimodulando il segnale per trasmetterlo nuovamente in uscita del tutto rigenerato. Oltre a queste operazioni, anche il clock del segnale viene recuperato.L'uso di OA e R assieme garantisce che mediamente i R siano a distanze 3 volte maggiori fra loro rispetto a quanto accade in SONET;

➢ Optical Add/Drop Multiplexer: gli OADM sono funzionalmente equivalenti alle loro controparti SONET. Possono effettuare l'individuazione dei payload elettronicamente, add/drop elettronico, rimodulazione o semplice attraversamento e aggiunta dei segnali nelle

IP su reti ottiche 67


nuove lunghezze d'onda d'uscita.

Per quanto ci siano tutte queste funzionalità è preferibile garantire che il semplice attraversamento avvenga interamente in dominio ottico, poiché le conversioni ottico-elettronico ed elettronico-ottico comportano un consistente incremento dei tempi. Tipicamente gli OADM vengono fatti con un numero di lunghezze d'onda destinate all'add/drop ed altre che passano in modo trasparente. E' possibile realizzare anche OADM in cui le lunghezze d'onda che vengono elaborate siano configurabili.

➢ Optical Cross-Connect(OXC): come nelle reti SONET, questi sono switch non bloccanti del traffico, che hanno il compito di commutare ogni fibra di ingresso verso ogni fibra di uscita, eseguendo la commutazione anche a livello di lunghezza d'onda singola che viaggia su di una fibra. Il problema critico è ancora una volta l'elaborazione dinamica di un segnale ottico. Allo stato attuale le conversioni di lunghezza d'onda non sono fattibili nel campo dell'ottico, quindi, è necessario riconvertire il segnale in elettrico, elaborarlo e successivamente ritornare all'ottico.

A seconda dei tipi di OXC adoperati, le reti ottiche vengono classificate in:

➢ Transparent;➢ Opaque;➢ Translucent.

VIII.1.1 Transparent optical networkNelle reti ottiche trasparenti gli OXC operano interamente in tecnologia ottica. Questo significa che i segnali subiscono un ritardo dato soltanto dal tempo di propagazione, fornendo di fatto un valore deterministico del delay e dei parametri di trasmissione in genere. Il problema è che al giorno d'oggi non è possibile fare l'elaborazione del segnale nel dominio ottico, è quindi impossibile cambiare la lunghezza d'onda dei flussi, che possono al massimo essere sottoposti ad uno switch da fibra a fibra. Attualmente, dunque, gli OXC nelle reti transparent non fanno altro che passare in blocco da una fibra di ingresso ad una fibra di uscita i segnali che viaggiano tutti su quella stessa fibra d'ingresso. Questa poca flessibilità nella gestione delle lunghezze d'onda comporta una accresciuta complessità


Figure 50: Optical Add/Drop multiplexer


nella risoluzione del problema dell'assegnazione delle lunghezze d'onda (RWA). E' necessario infatti stabilire a priori, fra tutti gli OXC interessati dalla comunicazione, quali lunghezze d'onda assegnare ai flussi. Questo problema, oltre ad essere NP-completo, comporta la necessità di uno spazio di indirizzamento di molto maggiore rispetto ad una analoga versione del problema che permette la riassegnazione delle lunghezze d'onda. Quest'ultima necessità non sorprende perché sostanzialmente i due casi corrispondono ad un indirizzamento globale l'uno e locale l'altro. In aggiunta, gli OXC totalmente in tecnologia ottica comportano che il segnale non venga rigenerato nel loro attraversamento, è dunque necessario prevedere un numero opportuno di regenerator lungo il percorso.

Il problema RWA, come precedentemente detto è molto complesso, si adottano due approcci per la sua risoluzione:

➢ Off-line: si assume che tutti i percorsi da realizzare sulla rete siano conosciuti a priori. Utilizzando opportune ipotesi sul funzionamento della rete si calcola la soluzione al problema. Da notare che in questo modo, poiché la computazione è eseguita off-line ed una sola volta, è possibile utilizzare anche un algoritmo molto complesso con tempi di calcolo lunghi;

➢ On-line: gli algoritmi on-line assegnano una lunghezza d'onda quando viene richiesta. Questo potrebbe anche portare ad una attesa perché tutte le lunghezza d'onda sono già assegnate. L'assegnazione di una nuova lunghezza d'onda avviene soltanto se non c'è nessun link lungo il percorso in cui quella lunghezza d'onda è già occupata. Chiaramente, questi algoritmi devono essere sufficientemente veloci, poiché sono eseguiti dinamicamente.

VIII.1.2 Opaque Optical NetworkLe reti opache permettono il cambio di lunghezza d'onda in un percorso ricorrendo ad una conversione ottico-elettronico per l'elaborazione del segnale e la successiva conversione elettronico-ottico per la trasmissione. Il percorso composto dalle diverse lunghezze d'onda, fra due end point è detto virtual wavelength path (VWP). Questo approccio garantisce che non si verifichino più i problemi derivanti dal blocco delle lunghezze d'onda, inoltre, l'elaborazione elettronica permette di ottenere informazioni sui dati trasferiti e di allungare le distanza senza necessità di rigeneratori.

Chiaramente il passaggio all'elettronico per l'elaborazione del segnale comporta anche svantaggi, primo fra tutti il rallentamento del segnale, poiché al tempo di propagazione si aggiunge quello di elaborazione, inoltre, i dispositivi per la conversione ottico-elettronico sono molto costosi.

VIII.1.3 Translucent Optical NetworkLe reti translucent sono reti che provano a trovare una via di mezzo fra i due precedenti approcci. L'idea di base è avere un numero relativamente piccolo i OXC opachi, per permettere la conversione delle lunghezze d'onda in punti strategici, con gli altri nodi tutti trasparenti. In particolare, è necessario almeno un nodo opaco su tre trasparenti per garantire che sia praticamente risolto il problema del blocco delle lunghezze d'onda.

VIII.2 Generalized Framing Procedure (GFP)GFP fornisce un modo per trasmettere su di un sistema di comunicazione tipo SONET segnali dati di tipo frame o comunque byte-oriented come sono quelli IP. Questo si ottiene aggiungendo alcune ulteriori informazioni ai dati trasferiti. In particolare è necessario fornire informazioni per la



rigenerazione della tempificazione, un certo numero di transizioni nei bit per garantire che si recuperino piccole variazioni di jitter nel clock, informazioni per identificare correttamente i pacchetti all'interno del flusso dati seriale.

VIII.3 Gigabit Ethernet (GbE)GbE consente di raggiungere la capacità di trasmissione di 1 Gbit in una connessione punto-punto, tramite 4 paia di cavi Cat.5 UTP. Rispetto alla tradizionale Ethernet viene abbandonato il concetto di condivisione del media, tramite CSMA/CD per passare ad un approccio totalmente switched. GbE è chiaramente poco costosa rispetto alle altre tecnologie, ma non garantisce l'affidabilità e precisione delle tecnologie su fibra ottica.

Tecnologia ancora più veloce è 10GbE che, anch'essa totalmente switched, può essere utilizzata, a differenza di GbE, anche per reti WAN. Per quanto ne condivida il nome, questa tecnologia non è compatibile con Ethernet, di cui condivide soltante il framing. 10GbE adopera infatti gli stessi protocolli di accesso dei livelli più alti di SONET, della quale, fra l'altro può riadoperare gran parte dello stesso hardware.

VIII.4 IP-centric control of optical networksIP è il tipo dominante di traffico su rete e le nuove tecniche di trasporto sono sviluppate per trasportare questo tipo di traffico su fibra, è chiaro dunque che IP ha influenzato il piano dei dati di queste tecniche. Oltre a questo, queste tecniche sono state sviluppate anche nell'ottica di garantire modi per effettuare la topology discovery, routing e per lo stabilimento di circuiti virtuali da parte del piano di controllo di Internet. Solitamente questo modo tipo di approccio, poiché considera le esigenze di IP sia sul piano dati che su quello controllo, è detto Ip-centric control.Tradizionalmente le reti di trasporto erano fatte per subire pochi cambiamenti nella loro configurazione, fatti, quando necessario, in un modo semi-manuale. Le nuove prospettive prevedono però la possibilità di realizzare path di onde luce dinamicamente. Questo approccio deve chiaramente essere supportato da una cooperazione distribuita fra i nodi, ottenuta tramite la topology discovery ed i protocolli di routing di Internet.

Procedendo in quest'ottica, dobbiamo tener presente che non è possibile modificare interamente l'intera struttura che regola le attuali reti per introdurre i nuovi approcci. E' dunque necessario tenere in conto quanto è già presente attualmente.

In particolare, il mondo delle reti è partito con una fortissima presenza di ATM che è stato via via soppiantato da SONET/SDH per il trasporto dei dati. L'introduzione della tecnologia DWDM non può essere che graduale in questo contesto. Un possibile approccio è quello di una coesistenza fra il mondo SONET e quello DWDM come mostrato in Figure 51.


Figure 51: Coesistenza SONET e DWDM


Su ogni porta ottica si può introdurre una evoluzione fatta in 3 passi:

1. Si comincia con l'introdurre l'hardware relativo all'utilizzo delle diverse frequenze solo in un approccio punto-punto;

2. Successivamente, si provvede ad inserire nella rete i WDM ADM;

3. Infine, si introducono anche i WDM OXC, completando così l'infrastruttura per il supporto totale a WDM.

Si otterrebbe dunque una condizione del tipo:

In realtà le scelte architetturali in questo caso possono essere due:

1. IP-over-DWDM: i router IP sono connessi direttamente al sistema di trasporto DWDM.

I router a ciascun PoP sono connessi in una configurazione ridondata per ragioni di affidabilità a bilanciamento del traffico. I due router superiori sono router che gestiscono l'add/drop del traffico verso la rete ed il traffico di passaggio. I due router inferiori gestiscono invece il traffico verso i client device. Come si vede questa configurazione non adopera OXC.

Questo approccio ha la capacità di trattare moli di dati nell'ordine dei centinaia di Gbps. Le funzioni di trasporto come lo switching, la configurazione, ecc. sono fatte direttamente dal layer IP e realizzate tramite protocolli come MPLS, ottenendo così un framework unificato. Questo garantisce che i router IP possano controllare la selezione dei percorsi end-to-end tramite meccanismi di Traffic Engineering ed appositi protocolli di signaling. Infine, questo

modello garantisce la possibilità che i router interagiscano con i loro pari per lo scambio di informazioni di routing.

Il problema principale di questo approccio è che non si è certi che i router IP riescano a gestire un traffico nell'ordine dei terabit senza compromettere prestazioni, affidabilità, velocità di recupero e stabilità del software.


Figure 52: IP/OTN architecture

Figure 53: IP over DWDM


2. IP-over-OTN: l'alternativa è adoperare una backbone OXC riconfigurabile per collegare fra loro i router.

Un backbone ottico riconfigurabile garantisce una struttura di trasporto flessibile, inoltre le reti OXC possono essere condivise con altre reti di servizio come ATM, Frame Relay e le linea di servizio privato SONET/SDH. Infine, questo approccio garantisce la possibilità di interconnettere i router in una arbitraria topologia logica, cosa non possibile nel precedente approccio, poiché ciascun router ha al massimo 4 (generalmente 2) conduttori che lo collegano ai PoP vicini.

Chiaramente ci sono degli svantaggi legati all'utilizzo degli OXC, primo fra tutti, l'aggiunta di un layer protocollare fra IP e DWDM che aumenta la complessità ed introduce un

certo overhead. Fra l'altro questo approccio non consente di operare il traffic engineering in una visione globale, il che potrebbe causare inefficienze nella gestione del routing.

Per la gestione da parte dei router IP delle connessioni su fibra, si sono introdotti vari sistemi:

1. OSPF-TE: è un'estensione di OSPF che tiene conto della conoscenza degli attributi di link e nodi necessari alla realizzazione di meccanismi di traffic engineering;

2. MpλS: è una semplice modifica di MPLS per gestire i canali di luce come fossero LSP, che invece sostituisce le etichette con gli insiemi di lunghezze d'onda su quel link. L'unica differenza è nel tipo di switching fabric utilizzata (questo sistema non è più usato);

3. Generalized MPLS (GMPLS): è una generalizzazione del concetto di etichetta fornito da MPLS. Ogni risorsa di un canale di trasmissione può essere vista come una etichetta generalizzata. GMPLS, dunque, non fa altro che estendere MPLS fornendo il piano di controllo per la gestione di dispositivi che adoperano sistemi di switching basati sui seguenti domini: pacchetti, tempo, lunghezze d'onda, fibre. Il piano di controllo condiviso garantisce una maggior semplicità nella gestione delle operazioni di rete e nella gestione dinamica automatica delle connessioni, delle risorse e per la realizzazione della QoS.

In aggiunta, GMPLS supporta interamente le capacità di stack delle etichette per la gestione dell'aggregazione dei flussi o per la realizzazione di instradamenti in varie regioni o domini dove non si conoscono i dettagli interni di routing ma solo i punti di ingresso/uscita.


Figure 54: IP over OTN

Reti di calcolatori II Capitolo IX

Capitolo IXNetwork Management

L'incredibile crescita ed espansione delle reti ha aumentato enormemente la complessità di gestione quotidiana e le scelte strategiche per i piani di accrescimento, per tali ragioni la gestione di una tale infrastruttura senza opportuni strumenti sarebbe impossibile.

Un sistema di network management è un insieme di tool per il monitoraggio ed il controllo di una rete. In un sistema del genere si possono identificare due ruoli:

➢ Manager: è un'entità implementata da un insieme di tool software che è in esecuzione su di una workstation.

➢ Agent: è un'entità che risiede sui dispositivi di rete e che ha il compito di comunicare al Manager lo stato di tale dispositivo.

Gli agent sono generalmente direttamente implementati all'interno dei dispositivi, quando i dispositivi non hanno sufficiente intelligenza per ospitare un agent, si ricorre ad un proxy agent cui viene affidata la gestione di tali dispositivi. Inizialmente questi erano molto semplici, con l'aumento della capacità di calcolo, hanno assunto sempre maggiori funzionalità ed è molto difficile oggi trovare dispositivi di rete che non implementino un agent.Le aree di interesse del network management sono definite dalla Recommendation iso 7498-4 e sono 5:

➢ Performance management: controllo delle prestazioni della rete. Lo scopo è determinare l'effettiva utilizzazione delle risorse di rete in modo da rilevare e rimuovere colli di bottiglia o possibili guasti. Generalmente questo comporta la raccolta di informazioni dalla rete, l'analisi di queste per la rilevazione dei “normali” livelli di prestazioni, elaborazione dei dati per ottenere indici prestazionali e monitoring di tali indici per avere la stima delle prestazioni;

➢ Fault management: rilevazione, notificazione, isolamento e correzione dei guasti, se possibile, in modo automatico in modo da mantenere sempre funzionante la rete. Questo si traduce in passi di diagnosi del problema, isolamento del guasto, correzione, test delle correzioni e salvataggio delle informazioni sul guasto e sulla sua risoluzione;

➢ Configuration management: gestione della configurazione dei dispositivi hw/sw, in modo da poter gestire e raccogliere le informazioni derivanti dagli effetti che tali configurazioni causano sulla rete. Questo corrisponde a mantenere un database con tutte le informazioni per, ad esempio, applicare opportune elaborazioni per cercare eventuali problemi di incompatibilità;

➢ Accounting management: misurazione dell'utilizzo di risorse su base specifica per gestione

Network Management 73


della rete e tariffazione dei servizi. Lo scopo è ridurre i problemi di rete grazie ad un opportuno partizionamento delle risorse, garantire equità nell'utilizzo delle stesse oltre a ottenere informazioni utili per il billing;

➢ Security management: controllo dell'accesso alle risorse di rete e protezione contro sabotaggi ed usi scorretti secondo le policy locali di gestione. Questo corrisponde fra le altre cose ad identificare le risorse critiche per la rete, mappare queste risorse con gli insiemi di utenti e monitorarne l'accesso. A questo si aggiunte la solita attività di logging di tutte le operazioni.

Le prime tre aree hanno a che fare strettamente con il monitoring della rete, mentre le restanti due sono la parte di control, ossia, le aree in cui si agisce per modificare i parametri di funzionamento della rete.

Chiaramente chi più ha interesse nel network management sono i provider, per i quali la gestione della rete non solo è un problema molto complesso, ma è anche la loro fonte di profitto. In questo contesto è necessario definire un approccio al problema, in modo da garantire servizi vendibili sul mercato, poco costosi da realizzare e mantenere.

Gli approcci al problema sono due:

➢ Top-down: partendo da servizi e funzionalità si determinano le strategie di controllo e di monitoraggio. Questo approccio punta a mantenere alta la soddisfazione del cliente, basandosi su di un contratto cliente-fornitore (SLA) stipulato per la fornitura del servizio. Chiaramente c'è un compromesso fra livello di qualità e costi di gestione.

In ogni caso gestire significa sempre seguire le tre fasi: aspettare, diagnosticare, risolvere.

➢ Bottom-up: si parte dalle caratteristiche del sistema e degli apparati per determinare la loro influenza sul funzionamento del sistema e dei servizi. Gli elementi costitutivi della rete vanno dai cavi fino ai complessi apparati software che sono eseguiti su di un server.

La necessità di gestione di apparati fra loro estremamente eterogenei non solo per tipo di implementazione, ma anche per caratteristiche funzionali, rende necessaria un'architettura unica che semplifichi tale gestione. La gestione integrata di tutti gli apparati porta con se anche un problema di fondo che è l'individuazione precisa delle correlazioni fra le notifiche di errore. E' infatti necessario stabilire la correlazione fra le segnalazioni poiché, tipicamente, un errore generare notifiche in più apparati.

La rete può essere gestita in due modi differenti, generalmente adottati entrambi in dipendenza del contesto:

➢ gestione reattiva: si attende la segnalazione di un problema per intervenire per la sua risoluzione;

➢ gestione proattiva: attraverso un continuo monitoraggio della rete si interviene nel minor tempo possibile per la prevenzione o risoluzione del problema, idealmente, anche prima che venga percepito. Questa gestione si può applicare con differenti strategie:

○ Polling: il gestore della rete esegue un controllo sugli apparati, o periodicamente gli apparati sono interrogati per ottenere informazioni sul loro stato. Questo è anche l'unico modo di agire quando non c'è un agent sull'apparato, per comprendere il suo funzionamento su base deduttiva;

○ Event Reporting: quando c'è un problema è l'agent a riportarlo. Questo approccio asincrono garantisce poco consumo della banda di rete ed una reazione immediata al



problema. L'affidabilità non è però garantita, se infatti il guasto è tale da compromettere anche l'agent o il sistema di segnalazione, il guasto non viene rilevato.

Il controllo di questi apparati può essere eseguito in due modi:

➢ out of band: la gestione del controllo degli apparati segue un canale dedicato, o attraverso interfacce cui si accede fisicamente in prossimità dell'apparato, o attraverso una rete di controllo dedicata per il monitoraggio a distanza;

➢ in band: i segnali di gestione viaggiano con gli stessi meccanismi che utilizzano i segnali dati. Questo riduce i costi ma se c'è un guasto si perde la visibilità dell'apparato per la diagnosi e risoluzione.

IX.1 Simple Network Management Protocol (SNMP)SNMP è stato sviluppato per garantire un sistema semplice e robusto per il controllo delle reti che potesse essere usato su tutti gli apparati di rete e quindi facilmente estendibile anche per gli apparati futuri. Questo comporta che SNMP fornisca una rappresentazione dei dati indipendente dalla piattaforma, che sia indipendente da altri servizi di rete e che sia uno standard internazionale in modo da garantire il disaccoppiamento da qualsiasi vendor. L'ultima definizione, la versione 3, risale al 1998.

Il protocollo di comunicazione viaggia su UDP/IP, ed è un protocollo di livello applicativo che deve essere implementato dagli agent e dai manager. I messaggi del protocollo prendono il nome di protocol data unit (PDU) e sono codificati secondo le basic encoding rules (BER) per garantire l'indipendenza dalla piattaforma.

I messaggi del protocollo, che sono chiamati primitive, per garantire la semplicità implementativa, sono in tutto 4, differenziati a seconda di chi è il mittente:

➢ Manager => Agent

○ GetRequest

○ GetNextRequest

○ SetRequest

➢ Agent => Manger

○ Trap

In Figure 55 è presentata schematicamente l'interazione fra Manager e Agent attraverso i messaggi SNMP. Nella seguente figura è invece presentata la struttura dei messaggi:


Figure 55:


Figure 56:

Version: versione del protocollo;

Community: “password” di autenticazione in chiaro;

PDU type: meta-informazione di tipo ASN.1 (Abstract Syntax Notation) del messaggio;

Request ID: id univoco per ogni richiesta per accoppiare una richiesta alla corrispondente risposta;

Error Status: vale 0 nelle richieste, nelle risposte fornisce una indicazione dell'esito della richiesta;

Error index: è 0 nelle richieste e nelle risposte corrette, in caso di errore indica l'indice della variabile che ha causato l'errore;

Variable bindings (varbinds): è una lista di coppie nome/valore, che permette di richiedere più variabili in contemporanea. Su tutte le variabili viene eseguita la stessa operazione. Durante le richieste getRequest, getNextRequest i campi valore sono vuoti.

I messaggi trap hanno una struttura leggermente differente:

Figure 57:

I campi che differiscono rispetto al precedente messaggio sono i seguenti:

Enterprise: permette di individuare il tipo di apparato/sottosistema che ha generato la trap;

Agent Address: indirizzo IP dell'agent generatore;

Generic Trap: tipo di trap, ce ne sono un insieme predefinito, fra cui un identificatore che indica di consultare il campo specifi trap;

Specific Trap: tipo di trap non standard;

Timestamp: indica il momento in cui è stata inviata la trap;

Per descrivere un apparato SNMP fa affidamento sul management information base (MIB), che è un albero delle informazioni di configurazione della rete. La sua funzione è descrivere il contenuto informativo e la struttura associata ad uno specifico dispositivo, in poche parole, è un descrittore dell'interfaccia. Il MIB viene rappresentato come una lista ordinata di valori che l'agent adopera per modellare il dispositivo che gestisce.


SNMP PDUVersion Community

Variable bindingsPDU Type Request ID Error status Error index

Name 1 Value 1 Name 2 Value 2 Name N Value N

SNMP PDUVersion Community

Variable bindingsPDU Type Enterprise Agent addr. Generic trap

Name 1 Value 1 Name 2 Value 2 Name N Value N

Specific trap Timestamp


Le variabili scambiate tramite i messaggi SNMP sono dunque identificate in base alla loro posizione nell'albero MIB. Va puntualizzato che SNMPv1 permette la gestione soltanto di variabili scalari, eccezion fatta per le tabelle che sono rappresentate come variabili indicizzate.

La cosa interessante del MIB è che da un lato ha una struttura standard, per essere compatibile con tutti i vendor, dall'altra è estendibile rimanendo entro tale struttura, per consentire la specifica di un particolare apparato.

In Figure 58 è presentato un esempio di MIB:

Come si può vedere nel MIB trovano posto sia informazioni statiche come il nome del dispositivo, sia informazioni dinamiche, come le tabelle di routing o l'up-time. Ciascun oggetto dell'albero MIB viene identificato in base alla concatenzazione di tutti gli identificativi dei nodi su tutta la gerarchia, fino alla radice, nel precedente esempio la variabile up-time avrebbe identificativo 1.2.2. Per indicare che si vuole accedere al valore di quella variabile si concatena uno zero finale: 1.2.2.0.

L'ordinamento degli identificativi è fatto considerando le cifre con peso crescente da destra a sinistra, qujindi 1.3 > 1.2.2, 1.5.10>1.5.2, 1.1.0 > 1.1.

Per garantire l'interoperabilità, oltre alle BER per la codifica dei messaggi che adoperano una struttura ricorsiva del tipo type-length-value, è necessario garantire che la struttura della MIB condivisa fra Agent e Manager sia definita senza nessuna ambiguità. Per questo motivo si adopera una notazione astratta per la descrizione della struttura dell'informazione gestita. Questa notazione è la ASN.1 definita dall'OSI. Il compito di ASN.1 è la definizione di tipi astratti e valori, dove per tipo si intende un insieme di valori. SNMP utilizza un sotto-insieme di ASN.1 per descrivere i MIB.

ASN.1 definisce un insieme di strutture:

➢ Simple Type: un semplice insieme di valori;

➢ Complex Type: un tipo strutturato costituito da sotto-componenti;

➢ Macro: notazione per estendere i tipi ASN.1 in maniera arbitraria;

➢ Module: un insieme di definizioni per il riuso in altri moduli.

L'insieme dei tipi ASN.1 adoperati da SNMP è costituito da alcuni tipi standard ASN.1 come


Figure 58: esempio di MIB


INTEGER, OCTET STRING, NULL e da altri tipi definiti nelle RFC appositamente per SNMP, come ad esempio IpAddress, Counter, Gauge, Opaque.

Quando si definisce un nodo dell'albero MIB, vengono specificati:

➢ Syntax: il tipo ASN.1;

➢ Access: il tipo di accesso consentito;

➢ Status: il supporto richiesto alle implementazioni di questo MIB;

➢ Description: una descrizione in formato leggibile dall'uomo per ragioni di documentazione.

Quest'ultimo campo consente di fornire un meccanismo per la lettura simbolica degli identificativi di un dato MIB, per quanto, questi non sono i dati che viaggiano su rete. Questo approccio è utilizzato per favorire la lettura delle informazioni da parte dell'uomo.

Alla luce di quanto detto i campi dei messaggi SNMP dovrebbero ora essere chiari, vediamo dunque nello specifico il significato dei vari tipi di primitiva:

➢ GetRequest: permette di richiedere il valore di una o più variabili del MIB;

➢ SetRequest: consente di assegnare un valore a istanze di variabili già esistenti o è adoperato per comandare azioni;

➢ GetNextRequest: Restituisce il nome ed il valore della successiva istanza di variabile del MIB. Questa primitiva consente l'esplorazione della struttura del MIB e delle tabelle;

➢ Trap: è la segnalazione di un evento da parte di un agent. L'agent non riceve conferma della ricezione della trap da parte del Manager. E' possibile anche configurare gli Agent in modo che emettano trap solo verso specifici Manager o in modo che non emettano affatto trap.

IX.1.1 The impact of UDPSNMP è un protocollo tipicamente datagram, che non ha il concetto di connessione, inoltre, nasce per la gestione di reti locali, dove la perdita di pacchetti è praticamente nulla. Per queste ragioni, fu scelto UDP come protocollo di trasporto. Con l'estensione dell'uso di SNMP a reti geografiche, l'inaffidabilità di UDP diviene un grosso problema, tuttavia è conveniente implementare meccanismi di affidabilità, quali timeout e retry, direttamente dal lato applicativo, in modo da non dover far uso dell'intero strato TCP, molto pesante in termini di elaborazione. L'utilizzo di UDP, con la sua struttura connectionless, garantisce maggior robustezza in situazioni critiche per la rete.

Chiaramente ci si confronta con le classiche decisioni sull'impostazione del tempo di timeout, da dimensionare in base alla dimensione della rete, e con il numero di tentativi ritrasmissione, che devono essere in numero sufficiente da garantire l'affidabilità ma non eccessivo in modo da non sovraccaricare la rete.

IX.1.2 Sicurezza in SNMPLa gestione della sicurezza in SNMP è decisamente basilare, se non addirittura inadeguata. L'unico concetto di sicurezza è l'utilizzo della COMMUNITY che altro non è che una password che passa in chiaro sulla rete. Generalmente è bene configurare i firwall in modo da garantire che non possa fluire traffico SNMP verso percorsi diversi da quelli agent-manager. In aiuto alla sicurezza vengono alcune funzionalità degli agent, come la gestione di access control list che contengono gli indirizzi dei manager di fiducia.



IX.2 Network management applicationsLe applicazioni di network management adoperano SNMP per ottenere informazioni sulla rete e per operare opportune azioni di configurazione. Ad esempio, una informazione tipica elaborata dai NMS (Network management system) è il calcolo dell'utilizzo della rete in un determinato intervallo di tempo. Tale calcolo è compiuto dividendo il numero di bit trasmessi in pacchetti che non hanno subito errori per il numero totale di bit trasmettibili sul canale, ottenuto moltiplicando l'intervallo di tempo di misurazione per la banda del canale. Assieme a questo parametro sono calcolati ulteriori interessanti parametri, come il numero di pacchetti broadcast o unicast.

Uno dei problemi più spinosi per questi sistemi sono le operazioni di scoperta della topologia di rete. Generalmente questa operazione è fatta eseguendo richieste ad ogni possibile indirizzo IP della rete esaminata. Il problema principale si ha quando la composizione della rete è dinamica, perché bisogna decidere quando e con che frequenza eseguire la costruzione della topologia.

IX.3 Professional and Business ChallangesAbbiamo fino ad ora esaminato il problema del network management in un contesto prettamente tecnico, senza identificare con precisione il contesto in cui si colloca questa attività. Un telecom operator (TO) odierno si trova a gestire una rete di grosse dimensioni, in cui mediamente si ricevono fra i 100,000 e 1,000,000 di allarmi al giorno, e la risoluzione di questi warning costituisce un parte significativa del lavoro quotidiano svolto dal TO. Questi allarmi non vengono correlati, quindi, ci sono un numero di segnalazioni irrilevanti ai fini pratici, poiché si riferiscono alla stessa problematica. La ragione di questa inefficienza è che attualmente la maggior parte di questi warning non è altro che un allarme inviato direttamente da uno dei differenti sistemi di gestione, che non seguono uno standard.

Per rispondere a questi allarmi i TO organizzano una gerarchia a livelli. Il primo livello ha il compito di verificare la presenza di allarmi, raggrupparli in base alla loro correlazione e distribuire le informazioni sul problema fra le parti coinvolte. Generalmente molti allarmi vengono risolti direttamente nel primo livello, specialmente quelli che riguardano il singolo utente. Se questo non fosse possibile, gli allarmi passano ad un secondo livello, che potrebbe includere anche staff sul posto, oppure al terzo livello che include anche i vendor degli apparati.

Lo scopo finale è giungere ad un sistema automatico di gestione degli allarmi che possa ricostruire tutto il workflow necessario dall'identificazione del problema alla sua risoluzione. Questa prospettiva non solo si scontra con le difficoltà tecniche derivanti dalla gestione degli allarmi, ma impone una serie ulteriore di problematiche. Innanzitutto un TO deve limitare i costi, il che significa che è necessario disporre di team piccoli ed efficienti per la risoluzione dei problemi. Questo, per quanto può sembrare banale, è un obiettivo molto complesso, infatti l'infrastruttura di un TO oltre ad essere molto estesa, include un insieme di apparati diversi con diverse interfacce, che richiedono diverse competenze. Quando poi si deve identificare un problema, è necessario comprendere quel problema dove va ad impattare, quali servizi, se l'impatto su quei servizi è tale da far decadere il servizio stesso, quali conseguenze ha sul cliente. Queste ultime problematiche introducono ancora un ulteriore necessità: la specifica puntuale del servizio e del modo in cui è venduto.

Dal punto di vista tecnico i problemi sono quelli già esaminati in precedenza: difficoltà nella conoscenza della topologia di rete e nella sua gestione, bassa qualità degli allarmi.

I TO stanno dunque tentando di ottenere un sistema che non gestisca solo la rete, ma gestisca i



servizi nell'interezza degli aspetti esposti. Un tool di base in questo senso è l'albero del servizio, che realizza una visione schematica delle strutture necessarie per fornire il servizio, mappando su queste gli impatti che hanno i warning. Anche in questo caso però si sente la necessità di un software che gestisca la correlazione, di formalismi e, in generale, di gestione della conoscenza.

IX.4 Service life-cycleE' bene formalizzare il ciclo di vita di un servizio per identificare le varie parti in cui agire per la realizzazione di un sistema per la gestione dei servizi:

1. Design: definizione del servizio, operazioni di marketing;

2. Negotiation: è una interazione di business;

3. Provisioning: implementazione e test del servizio;

4. Usage: inteso sia come operazione che come cambiamento

5. Disinstallation: il servizio smette di essere fornito.

Esaminando il modello di gestione dell'infrastruttura di un TO, ci stiamo chiaramente ponendo al livello della gestione del servizio (Figure 59).

In una analisi leggermente più approfondita, possiamo dire che ciascuna delle aree della precedente figura è interessata da 5 attività, come mostrato in Figure 60.

Il TeleManagementFORUM ha formalizzato l'intera attività di un TO in un modello schematico. Questo modello, il Telecom Operations Map (TOM), non fa altro che rappresentare tutte le operazioni di un TO, dall'interazione con il cliente, alla gestione della rete fisica.


Figure 59:

Figure 60:


Scendendo nello specifico delle operazioni necessarie a fornire un servizio, possiamo identificare le seguenti fasi (Figure 62):

1. Service creation;2. service provisioning;3. service activation;4. service assurance;5. service monitoring;6. service accounting.

Come è facile vedere, ciascuna fase si integra con tutti i principali processi di business.

IX.4.1 Service Level AgreementAbbiamo nominato più volte i SLA nel corso di questo testo, fornendo una vista più o meno formale del loro significato ad un livello tecnico. La definizione formale, che si adatta a più ambiti è la seguente:

Un SLA è un contratto fra il fornitore del servizio e il cliente che specifica il livello di QoS che può essere previsto per quel servizio.

E' chiaro che un SLA include sia aspetti tecnici, per la caratterizzazione del comportamento del servizio, sia legali, come il costo, gli obblighi, ecc. Talvolta si è soliti identificare la specifica tecnica del servizio col nome di service level specification (SLS).Ci sono una serie di campi di ricerca aperti riguardo gli SLA:


Figure 61: TOM

Figure 62:


➢ Definizione dei parametri del SLA, per identificare in modo formale il servizio che si offre/richiede;

➢ Valutazione della possibilità di gestire automaticamente la stipula o la negoziazione di un SLA;

➢ Misurazione della QoS fornita dal servizio;

➢ Meccanismi per fornire al cliente un feedback sull'effettiva QoS ricevuta;

➢ Gestione della QoS in modo da garantire che il cliente riceva il servizio effettivamente richiesto;

➢ Definizione di un linguaggio che permetta la definizione e validazione formale di un SLA.

Nella definizione dei parametri, un grande sforzo è stato fatto dal TeleManagementFORUM che ha identificato una serie di termini e definizioni, creando un glossario per la misurazione e comunicazione delle prestazioni di un servizio. La IETF allo stesso tempo ha formalizzato una serie di metriche per la valutazione dei servizi Internet.

Vediamo ora quali sono le componenti di un SLA:

➢ Descrizione della natura del servizio: questa parte contiene il tipo di servizio che viene fornito e qualsiasi qualificazione riguardante quel tipo. Si includono anche informazioni su dove il servizio deve essere fornito. In Internet la definizione del servizio potrebbe anche essere molto complicata ed includere molti componenti: applicazioni (sicurezza, accesso, tempi di risposta, ecc.), sistema, rete (QoS, encryption,ecc.);

➢ I livelli attesi di prestazioni del servizio: indicano i requisiti minimi per netowrk accessibility, availability, performance, operation and manteinance;

➢ La procedura per riportare i problemi;➢ Il tempo per la risposta e la risoluzione del problema;

➢ Il processo per monitorare e comunicare il servizio;

➢ Le conseguenze se non si rispetta il SLA;

➢ Clausole e vincoli.

IX.4.1.1 SLA Parameter definitionPer quanto potrebbe sembrare uno dei problemi più semplici da risolvere, la definizione dei parametri per la specifica di un SLA è comunque difficoltosa. Ad esempio, ci sono parametri definiti da ITU e IETF, i primi orientati ad un mondo di tipo SONET, i secondi basati sui pacchetti, quali adottare?

ITU definisce i suoi parametri basandosi principalmente sulle percentuali di bit error e numeri da questi derivati. Vengono quindi definiti dei livelli per la specifica dei parametri nel SLA, ad esempio: errored second, severely errored second, unavailable second, degraded minute, error free second.

Sono poi date anche ulteriori definizioni, per la comunicazione basata su celle: cell loss ratio, cell error ratio, cell misinsertion rate, cell transfer delay, mean cell transfer delay, cell delay variation.

Per il mondo IP i parametri dovrebbero invece essere basati sui pacchetti e sul mondo del routing in genere, specificando ad esempio il delay medio fra due router, o il delay massimo che un pacchetto



può subire attraversando una determinata parte della rete. Vista la complessità dei servizi IP, talvolta viene anche specificato il metodo utilizzato per la misurazione. Parametri tipici per il mondo IP sono: throughput, utilization, packet loss ratio, packet delay, availability, packet jitter.

Tipiche clausole nella definizione di un SLA e dei suoi parametri sui livelli di servizio possono essere:

➢ The hosted server will not be unavailable for a contiguous period exceeding 5 min in any 24-h period. Unavailability is defined as the ability to ping the server from a machine with network connectivity to the hosting provider’s access router.

➢ The hosted server will be able to handle inbound traffic of 30 000 Web requests per day.Nella gestione di un un certo numero di clienti, si deve anche garantire che i servizi dati ad un cliente non interferiscano con quelli dati ad un altro, tipici approcci in questo caso sono il controllo delle risorse e la virtualizzazione delle risorse.

La misurazione dei parametri del servizio fornito segue diversi approcci:

➢ Passive probe: non aggiunge traffico, raccoglie molte informazioni, ma deve essere situato in posti strategici della rete;

➢ Active probe: è utile nella misurazione dei ritardi, anche questo deve essere oculatamente situato;

➢ Polling MIB: scalabile e semplice, non permette la misurazione dei ritardi e non sempre permette di ottenere tutte le informazioni necessarie;

➢ Classical Tools: ad esempio, il ping, son semplici ma hanno solo informazioni statiche.

IX.5 Provisioning level AgreementI SLA sono una definizione del servizio di fatto non scalabile, poiché, all'aumentare del numero di richiedenti dello stesso servizio, non c'è modo di cambiare il SLA per adattarlo alle mutate condizioni della rete. Una alternativa che viene considerata nell'ultimo periodo è quella di adoperare i PLA. I PLA non sono altro che contratti sul servizio generati nel momento della richiesta dello stesso. I PLA possono dunque essere dinamicamente cambiati a seconda delle caratteristiche e dei requisiti differenti del servizio. Una volta stipulato un PLA il servizio viene fornito secondo le provisioning level specification.


Reti di calcolatori II Capitolo X

Capitolo XNetwork Resiliency

Col passare del tempo le reti di telecomunicazione sono diventate infrastruttura critiche. Su Internet, ad esempio, trovano posto tantissimi servizi e business per enormi quantità di denaro, ma le reti di telecomunicazioni sono divenute anche un mezzo vitale per il funzionamento di altre reti critiche, come quella elettrica, dei trasporti, ecc. Per queste motivazioni è necessario un impegno consistente per garantire la resiliency delle reti. Per resiliency si intende “la capacità della rete di mantenere o recuperare un accettabile livello di prestazioni durante malfunzionamenti della rete, applicando varie tecniche di recupero, e la mitigazione o la prevenzione di service outage”.Data la complessità ed il numero di diversi componenti che realizzano una rete, la network resiliency include un insieme di concetti che sono legati alla network reliability,che si occupa dell'affidabilità degli elementi della rete.

Chiaramente la capacità di fornire servizi della rete può essere minata da diversi guasti. Un TO non può gestire tutti questi guasti, poiché il loro numero rende un approccio del genere proibitivo, si decide quindi di occuparsi dei guasti più frequenti. Questi guasti, per cui è prestabilito un piano di recupero, sono detti accounted failures. Ciascun failure ha un diverso peso sul funzionamento della rete, alcuni failure possono anche causare un grande danno, come ad esempio la rottura di un cavo transoceanico che comporta la caduta di migliaia di connessioni dati.

Alcuni parametri per la caratterizzazione dell'affidabilità di una rete sono stati dati dalla ITU G.911 Recommendation, che riprende alcuni dei parametri tipici della teoria dell'affidabilità dei sistemi:

➢ FIT, failure in time: indica il numero di fallimenti del dispositivo in un certo intervallo di tempo;

➢ MT, maintenance: è il tempo durante il quale viene effettuata la manutenzione del dispositivo, sia in modo automatico che manuale;

➢ MTBF, mean time between failure: indica il tempo medio che intercorre fra due fallimenti;

➢ MTTR, mean time to repair: è il tempo medio impiegato perché il sistema venga riparato in seguito ad un fallimento;

➢ A, availability: è la capacità del sistema di fornire il servizio corretto in un certo intervallo

di tempo. Si esprime in funzione di MTBF e MTTR nel seguente modo: A=1− MTTRMTBF ;

Poiché l'affidabilità è un concetto altamente relativo, il livello di affidabilità di un sistema dipende dal servizio offerto e dal tipo di utenti che ne usufruiscono. Per questa ragione si è soliti classificare gli utenti in base ai loro requisiti di affidabilità:

Network Resiliency 84


➢ Safety critical user: utenti per i quali l'interruzione del servizio è inaccettabile;

➢ Business critical user: utenti per i quali l'interruzione del servizio comporta perdite finanziarie;

➢ Low cost user: utenti per i quali l'interruzione del servizio causa soltanto un fastidio;

➢ Basic level user: utenti per i quali l'affidabilità del servizio è solo un valore aggiunto ma non fondamentale.

In un sistema complesso è praticamente impossibile garantire l'affidabilità nel senso stretto della parola, ossia l'assenza di fallimenti. Per queste ragioni solitamente si parla di network survivability per indicare la capacità del sistema di funzionare nonostante la presenza di fallimenti. La classificazione dei fallimenti che possono colpire un sistema è vasta, esempi sono le categorie components, human error, systems, perché sia garantita la survivability, si devono attuare tecniche per il superamento di questi fallimenti, tali tecniche vengono categorizzate in protection switching e restoration.

Per un sistema che tenta di offrire affidabilità, una delle fondamentali operazioni da garantire è la capacità di misurare l'affidabilità del sistema stesso. Questo perché un sistema affidabile deve garantire con certezza qual è la fiducia che si può dare a quel sistema. Questa valutazione è più semplice nelle reti a commutazione di circuito, dove esiste un link fisico, diviene invece molto più complessa in reti come IP poiché si possono avere diversi percorsi. Questa considerazione rende necessaria la presenza di altri parametri per la valutazione dell'affidabilità. Per la misurazione della availability, alcuni parametri sono:

➢ port count method: si calcolano il numero di porte disponibili nella rete. Il rapporto fra numero di porte funzionanti a seguito di un guasto e numero di porte totale da' l'availability;

➢ bandwidth method: calcola l'ammontare di banda disponibile sulla rete. Il rapporto fra bandwidth disponibile dopo un guasto e bandwidth totale da' l'availability;

X.1 Network recoveryPer garantire il recupero di funzionalità della rete, sono vari gli approcci. Questi hanno tuttavia in comune una serie di requisiti: garantire sufficiente capacità di backup, garantire che la capacità di backup soddisfi i requisiti per la QoS, evitare single point of failure, ecc.


Figure 63:


Possiamo distinguere la capacità di backup in:

➢ Dedicata: c'è una relazione uno ad uno fra il percorso funzionante e quello di backup. Per quanto semplice questa soluzione è alquanto inefficiente;

➢ Condivisa: le risorse di backup sono divise fra differenti percorsi, garantendo un uso più efficiente delle risorse.

La scelta del modo di recovery del sistema può essere fatta sia per via predefinita, ossia prevedendo dei piano di recovery prestabiliti per rispondere a specifici fallimenti, oppure può essere realizzata dinamicamente, rendendo possibile in questo modo un tentativo di risoluzione anche per i non accounted failure.

Partendo da questa distinzione possiamo delineare due approcci alla recovery:

➢ Protection: i percorsi di recovery sono predefiniti e completamente predisposti prima che si verifichi il fallimento. Questa soluzione è in assoluto la più veloce. Alcuni schemi di protezione sono i seguenti:

○ 1+1: c'è esattamente un percorso di recovery dedicato ad ogni percorso operativo, il traffico dati è replicato continuamente su entrambi i percorsi:

○ 1:1: anche in questo caso c'è un percorso di recovery per ogni percorso operativo, ma il traffico dati è trasmesso solo su di un percorso per volta. In caso di assenza di fallimenti è anche possibile adoperare il percorso di recovery per il trasporto di traffico addizionale;

○ M:N: si adoperano M percorsi di recovery per N percorsi operativi, con possibilità di adoperare i percorsi di recovery per il trasporto di traffico aggiuntivo.

➢ Restoration: i percorsi di recovery possono essere predefiniti o dinamicamente realizzati, ma non sono stabiliti in via preventiva. Questo comporta che ci sia un traffico addizionale di signaling per stabilire il percorso di recovery. Questo approccio garantisce una buona flessibilità.

A quanto già detto si aggiunge una ulteriore riflessione: dove applicare le procedure di recovery? Sono due le possibilità:

➢ Local recovery: in condizioni di fallimento vengono isolate solo le componenti della rete coinvolte. Questo approccio, bypassando solo le parti colpite da fallimento, permette di diagnosticare il fallimento con maggior velocità e precisione. Lo svantaggio è che la riconfigurazione del sistema ha una visione locale, con la possibilità che si selezioni recovery path non efficienti;

➢ Global recovery: in caso di fallimento l'intero percorso operativo fra sorgente e destinazion colpito dal fallimento viene bypassato. Il tempo di recovery è molto più alto in questo caso, ma si garantisce l'utilizzo del miglior path disponibile.

X.2 Recovery Mechanisms ControlI meccanismi di recovery possono essere controllati in due modi:

➢ Controllo centralizzato: un controller centrale determina le azioni da prendere in caso di fallimenti, determinando allo stesso tempo quando e dove è avvenuto un fallimento. Il controller diviene un single point of failure ma generalmente garantisce un approccio efficiente e sufficientemente semplice, per quanto il controller potrebbe divenire un sistema



molto complesso;

➢ Controllo distribuito: non c'è un'entità centrale di controllo, ma tutti gli elementi della rete sono in grado di reagire autonomamente ad un fallimento. Con questo approccio non c'è una visione globale della condizione di rete e quindi i vari componenti devono scambiare fra loro informazioni per ottenere dati su come applicare il recovery. Con questo approccio si riesce a garantire una certa scalabilità.

In un sistema multilayer il controllo può agire su vari livelli per risolvere il problema. In realtà, non sempre un fallimento può essere risolto in un livello, ma è anche possibile che un fallimento possa essere risolto da più livelli dello stack. Per garantire un approccio che non comporti inefficienza nell'intera rete generalmente si adopera un approccio sequenziale, in cui via via i vari livelli, in tempi successivi applicano il loro meccanismo di recovery, fin quando il problema non è risolto.

Approcci più evoluti prevedono un intervento integrato in cui si ha una visione completa di tutti i livelli e si decide caso per caso quando ed in quali livelli avviare i meccanismi di recovery.


Reti di calcolatori II Capitolo XI

Capitolo XINetwork security

La sicurezza nelle reti è diventata un argomento predominante dato il valore dei servizi offerti e i danni che è possibile causare tramite Internet. Attualmente grande attenzione è riservata alla sicurezza, diversamente da quanto avveniva nel passato, nel seguito esaminiamo alcuni tipici attacchi informatici.

XI.1 Types of Attack

XI.1.1 IP address spoofingL'attacker modifica l'indirizzo IP sorgente del pacchetto da lui inviato per fare richieste ad un host vittima. Il pacchetto è instradato correttamente poiché IP basa il routing sulla destinazione. In questo caso l'attacker non può vedere le risposte della vittima, ma allo stesso tempo non può essere identificato. Per ottenere le risposte mantenendo l'anonimato l'attacker può sfruttare metodi per prendere il controllo di macchine ignare per eseguire l'attacco. In questo modo la vittima vede solo la macchina intermedia, che farà da replicatore delle risposte della vittima.

XI.1.2 Host scanningPer individuare un indirizzo IP si possono adoperare viri approcci. Il più seplice è l'eseguire il comando ping su range di indirizzi IP per ottenere i messaggi di risposta e quindi i corrispondenti indirizzi IP di chi ha generato la risposta. Molto spesso però i messaggi PING sono filtrati dai firewall, si adoperano dunque segmenti TCP Syn/Ack in modo da indurre il ricevente a generare messaggi TCP RST. Tali messaggi non sono filtrati dai firewall poiché vengono interpretati come risposte ad una richiesta di apertura connessione. Dal messaggio TCP RST viene poi ricavato l'indirizzo IP.

La stessa tecnica viene adoperata per fare lo scanning delle porte aperte su di un sistema host.Quando si vuole tentare l'ingresso in una rete, molto spesso oltre alla scoperta degli indirizzi IP degli host, si tenta anche il discovery della topologia tramite sistemi di trace route. Assieme a queste operazioni si generano inoltre opportuni pacchetti per ricavare dalla risposta ricevuta il tipo di sistema che sta rispondendo.

I sistemi operativi, o comunque i sistemi di rete in genere, hanno infatti caratteristiche peculiari nelle risposte che potrebbero renderne semplice l'identificazione al fine di preparare opportune tipologie di attacco basate sulle vulnerabilità di tali sistemi.

Generalmente queste tecniche di scanning sono eseguite con frequenza ridotta in modo da non

Network security 88


destare sospetti nei sistemi difensivi della vittima.

XI.1.3 System penetrationLa penetrazione all'interno di un sistema può avvenire in diversi modi. Il più comune è certamente il furto delle password. Questi attacchi generalmente hanno successo se non ci sono meccanismi che bloccano il numero di tentativi nell'immissione di una password.

Molto comune è anche lo sfruttamento di vulnerabilità software che non sono state corrette.

Un attacco più complesso è invece il session hijacking in cui un attacker si sostituisce alla vittima in una sessione TCP. Il procedimento è abbastanza semplice concettualmente. L'attcker esegue un denial of service sulla vittima e comincia a mandare pacchetti al server con cui la vittima aveva una connessione TCP modificando indirizzo sorgente dei pacchetti di attacco generati. La complessità è nel tener traccia durante l'attacco dei numeri di sequenza TCP, poiché anche quelli vanno replicati opportunamente.

A seguito della penetrazione del sistema, possono essere varie le operazioni compiute che minacciano la sicurezza. Dal semplice inserimento di rootkit alla creazione di backdoor per futuri accessi al sistema.

XI.1.4 Denial of ServiceGli attacchi DoS hanno lo scopo di minare la availability di un servizio, sono generalmente di due tipi:

➢ Single message DoS: sfruttano comportamenti non previsti dai programmatori per mandare in crisi i sistemi software;

➢ Flooding DoS: inviano un grande numero di messaggi verso la vittima, in modo da consumare interamente le sue risorse e mandarla in crash. Generalmente questo viene fatto inviando una serie di TCP SYN, per richiedere l'apertura di un gran numero di connessioni TCP.

Gli attacchi DoS diventano molto pericolosi quando l'attacker organizza una rete distribuita di zombie, ossia di macchine ignare su cui è stato installato un malware che risponde ai comandi dell'attacker, che permettono di effettuare l'attacco DoS partendo da più macchine.

La gestione di questi tipi di attacco è molto complessa, poiché per quanto i firewall potrebbero scartare tutto il traffico DoS in ingresso, comunque il link risulterebbe saturato rendendo impossibile il passaggio di altro traffico. In questi casi è necessario un approccio coordinato degli ISP in modo da tagliare il traffico DoS in principio, ad esempio quando è in uscita dal proprio ISP.

XI.1.5 MalwareMalware è una parola che sta per malicious software, si tratta dunque un termine che individua una categoria di software che ha intenti malevoli. I tipi di malware più noti sono:

➢ virus: sono software il cui scopo è procurare un danno al sistema su cui risiedono. La loro propagazione avviene manualmente, ossia, devono essere distribuiti da un'entità separata poiché non sono in grado di farlo da soli. Il virus generalmente si propaga nel sistema infettando i file, copiando se stesso. La copia avviene nella parte finale del file, il che

Network security 89


permette ai software antivirus di identificare semplicemente i file infetti se si conosce la fingerprint (ossia il codice caratteristico del virus). Alcune tipologie di virus, dette metamorphic, copiano il loro contenuto in parti casuali del file, rendendo la loro individuazione ben più complessa e spesso, eccessivamente time-consuming.

Il mezzo attualmente più diffuso per la distribuzione di virus sono le e-mail e i download dai siti internet.

➢ Worm: i worm sono programmi malevoli in grado di duplicarsi e propagarsi autonomamente. Il worm punta ad infettare il maggior numero di sistemi possibile, reinviandosi, ad esempio, a tutti i contatti della rubrica di un utente.

➢ Trojan: i trojan sono malware il cui scopo è rimanere nascosti nel sistema per fornire la possibilità a chi li ha diffusi di appropriarsi di parte delle funzionalità del sistema vittima, o anche dell'intero sistema.

Dato il forte impatto nella diffusione dei malware attraverso le e-mail. Poiché gli utenti finali hanno statisticamente poca cura nei sotware di controllo, spesso gli antivirus sono introdotti direttamente nei server di smistamento e-mail in modo da impedire la diffusione dei malware.

XI.2 FirewallI firewall non sono altro che dei filtri che selezionano i pacchetti in ingresso/uscita da una rete.

Il firewall che separa una rete interna, fidata, dal resto della rete, viene detto border firewall, ed il suo compito è eliminare tutti i pacchetti scorretti “loggando” tale attività in modo da poter consentire un monitoraggio degli avvenimenti, e, allo stesso tempo, lasciar passare tutti i pacchetti autorizzati. Tuttavia, un border firewall non può garantire che tutto il traffico malevolo sia scartato, il concetto di sicurezza deve essere dunque affrontato in modo distribuito, diffondendo il software di controllo su tutti i computer interni alla rete. Il vero problema è che comunque questi software presentano una capacità di intercettazione dei pericoli limitata alla conoscenza stessa dei pericoli. In altre parole, questi software sono in grado di prevenire il passaggio di traffico scorretto il cui tipo è noto. Quando si presentano nuovi tipi di traffico malevolo, i filtri non sono in grado di intercettarlo.

Sulla base di questa affermazione si può affermare che non sempre la sicurezza distribuita garantisce una maggiore protezione. Se infatti il bagaglio di conoscenze dei vari filtri installati è sempre lo stesso, quel che non viene filtrato dal primo filtro, non lo sarà nemmeno da quelli successivi.

Network security 90

Figure 64:


I firewall si scontrano anche con una serie di difficoltà legate alla configurazione ed all'utilizzo degli stessi senza incidere sulle funzionalità dei sistemi. Ad esempio, nelle VPN, in cui sono stabiliti dei canali virtuali criptati per realizzare una rete privata virtuale, il firewall non è in grado di identificare i pacchetti della VPN poiché tutte le informazioni sull'header di tali pacchetti sono criptate. Il firewall, infatti, lavoro con un semplice concetto di “dentro-fuori” e dunque se non può riconoscere il pacchetto l'operazione compiuta è semplicemente scartalo.

In realtà i firewall convivono con le VPN se gli sono fornite sufficienti informazioni per riconoscere le VPN corrette.

In realtà i problemi legati ai firewall possono anche essere più spinosi. Basti pensare al VOIP, in cui per avviare una chiamata si inviano informazioni di signaling ad un indirizzo IP. Perché si possano ricevere chiamate da tutti, sarebbe necessario rendere possibile l'attraversamento del firewall da parte di tutti i possibili indirizzi IP sorgente. Poiché questo renderebbe del tutto inutile l'utilizzo del firewall stesso, per rendere il VOIP realizzabile in questo modo, si devono sviluppare strategie alternative per la diffusione degli indirizzi IP fidati da cui è possibile accettare pacchetti.

In base all'hardware su cui è operativo il software del firewall, distinguiamo diverse categorie:

➢ Screening router firewall: il firewall è aggiunto al router, tuttavia, poiché la gran parte delle risorse del dispositivo sono dedicate al routing, è necessario limitare la capacità del firewall;

➢ Computer based firewall: è un computer con 2 interfacce di rete, una verso il mondo interno, l'altra verso quello esterno, su cui è in esecuzione il firewall. Questi firewall hanno un problema legato ai tempi di risposta, poiché sono generalmente realizzati sulla base di un sistema operativo gerneral purpose che potrebbe rendere non efficienti le operazioni. Il problema critico in questo caso risiede nel tempo di elaborazione dei filtri del firewall;

➢ Firewall appliances: sono delle macchine dedicate che tipicamente montano un sistema operativo custom, chiuso, che si espone a poche vulnerabilità. Viene tuttavia garantita una certa flessibilità software per il supporto a funzioni complesse.

➢ Host firewall: sono i piccoli software di firewall che sono installati sugli host della rete. Il problema principale in questo caso è la gestione della configurazione degli stessi.

Per quanto appartenenti a differenti categorie, tutti i tipi di firewall sono costretti a confrontarsi con un trade-off di fondo: più il filtraggio è complesso, più il tempo per il filtraggio aumenta.

Gli approcci per la gestione del filtraggio sono due:

➢ Static (Stateless) Packet Inspection: viene definito un insieme di regole basate sugli header TCP e IP dei pacchetti. IN basi a tali regole sono selezionati i pacchetti autorizzati a passare. Il problema principale di questo approccio è che non si adatta al traffico di rete che sta interessando il sistema in quel momento. Ad esempio, non si accorge di richieste di apertura connessione TCP ripetute in grande quantità. Le regole sono solitamente definite sotto forma di ACL (access control list).

➢ Stateful Packet Inspection: in questo approccio si tiene memoria della connessione dati, analizzando il flusso di pacchetti ed associando ad esso un'informazione di stato su cui si prendono le decisioni. Il meccanismo stateful adopera anch'esso ACL, ma a questo aggiunge la gestione della stato per prendere la decisione. Lo stato viene mantenuto soltanto per gli indirizzi IP che hanno il permesso di passare.

Network security 91


XI.3 NATUn approccio comune per la difesa di una rete è adoperare meccanismi di NATTING. In questo modo gli sniffer non possono imparare gli indirizzi IP e i numeri di porta interni alla rete, ma solo quelli tradotti dal NAT. Questo garantisce di per se che un attacker esterno non possa stabilire una connessione con un computer interno.

XI.4 Intrusion Prevention SystemsGli IPS operano un controllo sul traffico molto più accurato rispetto ai firewall. Gli IPS, infatti, esaminano flussi di pacchetti alla ricerca di pattern che non potrebbero essere individuati guardando al singolo pacchetto o connessione. In aggiunta, l'ispezione fatta sul pacchetto è molto più profonda, arrivando ad esaminare gli header di tutti i livelli del pacchetto.

Gli IPS agiscono in maniera proattiva, quindi, quando è individuato un attacco, tutti i pacchetti che appartengono a quell'attacco vengono automaticamente scartati.

La diffusione di questi sistemi è molto spesso limitata dalla difficoltà di configurazione degli stessi, che potrebbero portare, se impostati in modo errato, all'irraggiungibilità della rete.

Network security 92

RETI DI CALCOLATORI II - UniNa STiDuEunina.stidue.net/Computer Networks 2/Materiale/Dispensa RCII...

Documents

Transcript of RETI DI CALCOLATORI II - UniNa STiDuEunina.stidue.net/Computer Networks 2/Materiale/Dispensa RCII...