Che materia stai cercando?

Riassunto esame Telematica, prof. Ciuffoletti, libro adottato "Computer Networking: A Top-Down Approach" di James F. Kurose, Keith W. Ross

Riassunto esame Telematica del prof. Augusto Ciuffoletti, basato su appunti personali, videolezioni del professore e studio autonomo del testo consigliato dal docente "Computer Networking: A Top-Down Approach" di James F. Kurose, Keith W. Ross. Argomenti trattati: vista generale di Internet, il livello Link, il livello IP, il livello Trasporto, il livello Applicativo, la sicurezza,... Vedi di più

Esame di Telematica docente Prof. A. Ciuffoletti

Anteprima

ESTRATTO DOCUMENTO

4. Le reti wireless e le reti virtuali

La rete WiFi

802.11, chiamato anche WiFi, è un altro protocollo di link della famiglia IEEE802.x; i problemi

che ci si pongono sono diversi rispetto a quelli di una reta cablata, trattandosi di una rete wireless.

In ogni caso, WiFi riesce a riprodurre una situazione simile a quella della rete locale. Esistono due

diverse modalità di funzionamento per una sottorete: la prima è una modalità detta ad hoc, e tutti i

nodi partecipanti sono allo stesso livello (quindi non avendo un componente di controllo deve auto-

organizzarsi nel momento in cui si configura), la seconda è detta infrastructure, e prevede un

componente di controllo detto Access Point.

L’Access Point costituisce l’infrastruttura, e tralasciando le differenze dal punto di vista

tecnologico, è possibile affiancarlo allo switch della rete Ethernet; la sua funzione è quella di

offrire connettività e coordinazione a tutti gli altri nodi appartenenti alla stessa sottorete: un

nodo wireless deve collegarsi con l’Access Point per accedere alla rete (cioè all’infrastruttura), e

quindi comunicherà a livello link solo con l’AP. Ogni Access Point è caratterizzato da un

identificatore SSID, che può essere trasmesso

periodicamente in un frame particolare detto beacon. Il

collegamento con un AP si chiama associazione, e

normalmente richiede l’autenticazione del nodo che si vuole

associare in modo da fornire un servizio solo a chi è abilitato;

terminata l’associazione, l’AP assegna al nodo un indirizzo IP.

Ci sono differenze importanti rispetto a Ethernet, che impediscono la realizzazione di un sistema

di Collision Detection. In una stazione WiFi convivono un trasmettitore e un ricevitore: quando

il trasmettitore è in funzione, il ricevitore è “assordato” dal segnale del primo, quindi non può

rilevare le collisioni. Inoltre la transizione fra trasmissione e ricezione non è istantanea: al

termine di una trasmissione tutti attendono un certo intervallo di tempo detto SIFS per consentire al

trasmettitore di tornare a ricevere. Invece di parlare di Collision Detection, si parla di Collision

Avoidance, ovvero si cerca di evitare che la collisione si verifichi, grazie al lavoro di un algoritmo:

prima controlla la presenza di un’altra trasmissione durante un intervallo DIFS (più ampio di

SIFS), se la linea resta libera avvia la trasmissione, altrimenti entra in un exponential back-off

(ritardo parzialmente randomizzato stabilito per la spedizione di un pacchetto che non era stato

possibile spedire prima) per evitare che tutti quelli che sono in attesa entrino in collisione; al

termine il ricevente attende SIFS (in modo che il mittente possa rientrare in ricezione) e spedisce

un ACK (messaggio di verifica), e se questo non torna al mittente, il frame viene rispedito. I due

intervalli di tempo DIFS e SIFS determinano una priorità: il messaggio di ACK ha priorità superiore

alla spedizione di un frame generico. E’ molto importante che i clock (dispositivi che misurano gli

intervalli) siano ben sincronizzati.

Il problema del terminale nascosto si presenta nel caso frequente in cui due nodi agganciati allo

stesso AP non ricevono l’uno il segnale dell’altro: il fatto che tutti i nodi raggiungano l’AP non

implica che il segnale di un nodo raggiunga tutti gli altri nodi, poiché questo dipende dalla

copertura fornita dall’AP stesso. Uno dei due nodi che non si ricevono può iniziare la propria

trasmissione durante la trasmissione dell’altro, causando problemi di collisione. La finestra di

collisione si allarga ad ambedue i frame, e il problema perdura per tutto il tempo della

trasmissione, degradando significativamente le prestazioni della rete. Per risolvere questo

problema si introduce un protocollo RTS/CTS il quale fa in modo che l’AP coordini gli accessi; si

basa su un brevissimo frame RTS inviato dal nodo che ha intenzione di trasmettere (la sua brevità

limita l’impatto di una eventuale collisione). L’AP riceve l’RTS e, dopo SIFS, spedisce un altro

frame CTS a tutti i nodi: in questo modo, poiché tutti i nodi sono raggiunti dall’AP e ricevono il CTS,

tutti quanti considerano la linea occupata fino alla ricezione dell’ACK. In ogni caso, questo

protocollo viene applicato opzionalmente, e ha un impatto negativo sull’utilizzo della rete, poiché

porta allo scambio di due frame in più; normalmente viene applicato solamente se si presentano

problemi.

La rete virtuale

Il protocollo 802.1Q o rete virtuale, può fornire un’organizzazione della rete differente dal

cablaggio originale: la topologia cablata della rete può essere diversa da quella organizzativa. I

rami potrebbero avere una gestione distinta, per esempio: ad ogni piano ci può essere un nodo

destinato all’amministrazione (riservatezza), un nodo destinato ad essere accessibile dall’esterno

(accessibilità) e un nodo per teleconferenze (connettività); venire incontro a queste esigenze con

tre diverse sottoreti cablate sarebbe estremamente complicato e costoso. Lo strumento che

consente di effettuare questa suddivisione è l’overlay, ovvero una rete sovrapposta su più sottoreti

(cablate) in modo da rispettare le esigenze organizzative. Ad ogni interfaccia viene associata una

LAN virtuale (VLAN) di appartenenza, che ha un proprio identificatore di 12 bit (VLAN Id); ad ogni

porta dello switch viene associato uno di questi id. Per indicare la VLAN di destinazione del

pacchetto, il VLAN Id viene inserito nel pacchetto stesso con un meccanismo di tagging;

successivamente gli switch inoltrano i frame con un certo id solo sulle porte corrispondenti.

5. Il protocollo UDP

Il protocollo UDP è un protocollo di trasporto (a livello trasporto, non più link) che utilizza

pacchetti IP per trasferire dati. Le funzionalità addizionali al livello link che UDP introduce a livello

trasporto sono limitate, per cui si sente ancora fortemente l’influenza del livello inferiore. Il

trasferimento avviene in modo unidirezionale, da un mittente a un destinatario, con l’invio di

pacchetti chiamati datagrammi. Così come in IP, non c’è controllo di flusso, quindi i datagrammi

possono essere perduti, ricevuti in modo disordinato, o ripetuti; questo lo rende adatto a sistemi

real-time, basati su uno scambio di datagrammi con tempistiche molto repentine, in cui ritardare la

trasmissione per un pacchetto perduto non è consentito. UDP è particolarmente utile nel caso di

comunicazioni che vengono ripetute (perdita non rilevante), comunicazioni ridondanti (perdita

limitata) e comunicazioni che fanno parte di una transazione controllata a livello superiore.

L’organizzazione della comunicazione in datagrammi facilita protocolli basati su transazioni (un

sistema di domanda-risposta implementato al livello superiore).

Un datagramma è un pacchetto di informazione autocontenuto e indipendente (simile a un

pacchetto IP ma molto più capiente), che viene inserito nel payload di un singolo pacchetto IP; può

trasportare fino a 65KByte di dati, e può dar luogo a una frammentazione del pacchetto IP che lo

contiene. Il datagramma viene trattato dal routing IP, quindi la comunicazione passa da nodo a

nodo fino alla destinazione. Il protocollo UDP permette il multiplexing, ovvero la possibilità di

raggiungere applicazioni diverse che risiedono sullo stesso nodo (possono esserci destinatari

distinti per pacchetti distinti sullo stesso nodo). Tutto questo avviene grazie alle porte UDP, un

ulteriore livello di indirizzamento che si trova in relazione gerarchica con l’indirizzo IP (il numero di

porta è rappresentato con un intero di 16 bit e deve essere indicato insieme all’indirizzo IP). Come

in altri protocolli, la struttura del pacchetto è suddivisa in varie parti: uno header che include le due

porte (mittente e destinatario), la lunghezza del pacchetto complessivo e la checksum dell’intero

pacchetto per verificare la presenza di errori.

UDP consente anche il multicast, ovvero la comunicazione da uno a molti: una possibilità è

l’indicare come destinatario un indirizzo IP appartenente alla classe D (tutti gli indirizzi che iniziano

con la sequenza 1110); il nodo interessato a ricevere il multicast si iscrive al gruppo corrispondente

all’indirizzo in classe D, tramite una join realizzata dal protocollo IGMP. Altrimenti è possibile usare

un indirizzo, derivato da quello della sottorete IP, associato a tutti i suoi nodi: l’indirizzo broadcast

consiste nell’indirizzo della sottorete riempiendo l’ultimo ottetto di 1 (192.168.5.0/24 ha come

indirizzo broadcast 192.168.5.255); in questo caso tutti i nodi della sottorete ricevono il

datagramma, operazione invasiva e pericolosa il cui uso è riservato alle funzioni di sistema.

Il protocollo UDP deve essere messo a disposizione dell’utente tramite linguaggi di

programmazione, tramite una libreria che ne metta a disposizione le funzionalità: tale libreria

realizza un’interfaccia API (Application Programming Interface) e offre tutte le funzioni

necessarie. Il socket è una specie di porta Input/Output da cui l’utente può leggere o scrivere; lo

scambio di un datagramma avviene tra due socket, ciascuno rappresentato da una coppia IP:porta

(per un socket in ingresso è necessario specificare la porta su cui ricevere i datagrammi, per un

socket in uscita è necessario specificare la porta e l’IP del destinatario).

6. Il protocollo DHCP

Esistono casi in cui l’insieme dei nodi che appartengono a una sottorete a livello link cambia

frequentemente (ufficio con PC spostabili, reti wireless senza amministratore); in molti casi è utile

una configurazione plug and play dei nodi. Il protocollo DHCP serve a configurare

automaticamente l’interfaccia di rete di un dispositivo, associandogli un nuovo indirizzo IP,

grazie alla funzione broadcast di IP e agli indirizzi MAC. Si tratta di identificare un indirizzo IP

inutilizzato, associarlo all’indirizzo MAC dell’interfaccia, determinare un routing per il nodo appena

collegato e fornire informazioni per la configurazione del nodo (server DNS). A questo punto viene

configurato un server DHCP che conosce le informazioni relative alla sottorete e ha a disposizione

un insieme di indirizzi IP da assegnare (ogni IP deve essere assegnato a un solo nodo). Nelle

piccole LAN spesso il server DHCP si trova sul router.

Il nodo appena connesso invia in broadcast sulla sottorete un messaggio di richiesta detto

DISCOVERY, incapsulato in un datagramma UPD (per realizzare il broadcast l’indirizzo IP è

impostato a 255.255.255.255). La porta su cui è inviato il datagramma è la porta 67, riservata a

DHCP. L’indirizzo del mittente (ignoto) è 0.0.0.0. Una volta ricevuto il datagramma, il server

risponde con un pacchetto OFFER, contenente l’indirizzo MAC del cliente, l’indirizzo IP a lui

assegnato dal server e altre informazioni richieste, e considera impegnato l’indirizzo assegnato. I

server possono essere più di uno, per cui il client può ricevere più di una risposta, e deve accettare

l’offerta proposta dal server: Una volta selezionata l’offerta, il cliente spedisce in broadcast un

pacchetto REQUEST, a cui il server risponde con un pacchetto ACK, confermando al cliente che

può iniziare a usare l’indirizzo che gli è stato consegnato, mentre il server la cui offerta non è stata

accettata libera l’indirizzo assegnato. Questo collegamento ha una scadenza detta lease time,

dopo la quale il protocollo DHCP deve essere rieseguito, e il server cerca di riassegnare l’indirizzo

precedente o uno più simile possibile. Dato che i messaggi vengono scambiati con datagrammi

UDP, questo non garantisce il recapito, è necessario analizzare lo scenario in caso di perdita di

messaggi: se DISCOVERY viene perduto, il cliente ne spedirà uno nuovo dopo il timeout, dal

momento che non riceve una OFFER, mentre se DISCOVERY è troppo lento e il cliente invia più

di una richiesta, il server risponde a richieste multiple dallo stesso cliente con gli stessi criteri di

selezione; se OFFER viene perduto, ancora una volta il cliente spedirà un altro DISCOVERY dopo

il timeout.

7. Exterior e Interior Routing dei pacchetti IP

Il cammino di un pacchetto IP consiste in una serie di passi di ricezione e spedizione detti hop (il

nodo che riceve e spedisce il pacchetto viene detto gateway), e il percorso completo viene detto

route (da cui routing), i cui passi vengono calcolati dal router utilizzando una struttura dati

chiamata tabella di routing (della destinazione è nota la sottorete). Il calcolo della tabella per ogni

gateway è una funzione molto complessa, il caso più semplice è quello in cui lo stesso nodo

svolge sia la funzione di router che quella di gateway; in questo caso, la tabella può essere

semplificata con due colonne: la sottorete di destinazione e un router adiacente raggiungibile con

un singolo hop. Per rendere possibile un routing globale, viene introdotta la struttura gerarchica

suddivisa in sistemi autonomi, che da questo punto di vista sono definiti come un insieme di

router che scambiano informazioni attraverso un protocollo comune, gestiti da una stessa

organizzazione (es. Telecom), che vanno a formare un grafo sempre connesso (a meno che non si

verifichino guasti). Esistono due tipi diversi di routing: l’Interior routing attraverso router interni al

sistema autonomo utilizzando l’Interior Gateway Protocol, oppure l’Exterior routing fra sistemi

autonomi distinti messi in contatto da router di confine, che utilizzano l’Exterior Gateway Protocol.

Exterior Routing

Il protocollo BGP (Border Gateway Protocol) tratta lo scambio di informazione senza specificare

algoritmi di determinazione dei cammini, poiché questi vengono selezionati sulla base di politiche

complesse (servizi offerti dall’amministrazione del Sistema Autonomo, ragioni economiche,

politiche, ecc.) La connessione avviene fra gateway che appartengono a Sistemi Autonomi distinti,

che si scambiano informazioni per fornire un immagine coerente della raggiungibilità dei nodi e

delle sottoreti (fra cui il tipo di servizio che un certo sistema

offre). Il protocollo BGP distingue due tipi di nodi: il border

gateway mette in comunicazione i due AS, il BGP speaker

esegue il protocollo BGP e aggiorna le tabelle di routing,

mettendo le informazioni a disposizione del gateway; le due

funzioni sono indipendenti, quindi possono essere cumulate

sullo stesso nodo.

L’adiacenza fra AS sussiste quando c’è un collegamento al livello 2 (Data Link), e ciascun

sistema deve avere un border gateway agganciato a quel link, inoltre i BGP speaker devono

condividere lo stesso collegamento Data Link con il border gateway (quindi possono comunicare

direttamente senza far intervenire il routing interno). Per quanto riguarda la comunicazione in

Internet, un AS può essere la destinazione o l’origine di traffico locale, oppure un tramite di

traffico di transito; in quest’ultimo caso si distinguono tre circostanze: si tratta di uno stub se è

adiacente a un solo AS (non può essere un sistema di transito), si tratta di un multihomed se è

adiacente a più sistemi ma non accetta traffico di transito, si tratta di un sistema di transito se è

adiacente a più sistemi e accetta il traffico di transito.

Il protocollo BGP è in grado di evitare la formazione di cicli nella comunicazione. Le route

(cammini completi) che rendono raggiungibili i nodi e le sottoreti di un AS vengono rese pubbliche

dal protocollo, e sono utilizzabili da altri sistemi. Questo permette ai Sistemi Autonomi di

differenziare l’offerta di traffico ad altri sistemi (offerta di traffico più o meno veloce, ecc.); per

questo tutti i BGP speaker di un sistema, alla pubblicazione delle route, devono applicare politiche

consistenti.

Il protocollo BGP ha tre funzioni fondamentali: l’acquisizione di un nuovo BGP speaker adiacente

(messaggi di tipo open), il mantenimento del collegamento fra gli speaker (messaggi di tipo

keepalive e notification), l’aggiornamento delle route per le reti che possono essere raggiunte

(messaggi di tipo update). I messaggi BGP inviati dal protocollo sono composti da un header e da

una parte variabile; questi vengono scambiati grazie al protocollo di trasporto TCP sulla porta 179,

che genera una comunicazione persistente. Lo header è strutturato in tre parti: un marker (16

ottetti) che il destinatario può prevedere e usare per autenticare il messaggio, la lunghezza (2

ottetti) del messaggio necessaria per compensare l’assenza di un trailer, e il tipo (1 ottetto) che

specifica il tipo di messaggio fra open, update, notification e keepalive; la lunghezza è

particolarmente importante in quanto i messaggi viaggiano su uno stream, per cui può essere

utilizzata per identificare il messaggio nella sua completezza, mentre nel flusso continuano ad

arrivare bytes.

Il messaggio open viene inviato non appena stabilita la connessione TCP, per acquisire il nuovo

vicino: in caso positivo, la risposta inviata è un keepalive. Il messaggio open ha i seguenti campi:

Il messaggio update serve per comunicare una modifica del RIB (Routing Information Basis),

ovvero registrazioni che descrivono le route per raggiungere i vari sistemi, che vengono inserite in

vari database: Adj-RIBs-In contiene RIB acquisiti dall’esterno tramite messaggi update, Loc-RIB

contiene le registrazioni ottenute dal primo database ma applicando le politiche locali, Adj-RIBs-

Out è un insieme delle precedenti che vengono comunicate all’esterno con messaggi update. Un

messaggio update può invalidare diverse route o abilitare una sola nuova route. Questo

messaggio contiene tre campi di lunghezza variabile: i primi due sono composti da un sotto campo

che ne indica la lunghezza e l’informazione, il terzo viene ricavato per differenza. Il primo campo

indica le route che vengono invalidate e le sottoreti di cui si vuol cancellare le informazioni di

raggiungibilità, il secondo campo indica una serie di attributi della nuova route che si vuol rendere

pubblica, il terzo campo indica la destinazione della nuova route espressa come un elenco di

prefissi che diventano raggiungibili attraverso questa route (coppie IP-lunghezza del prefisso). Gli

attributi necessari del messaggio di update sono:

L’attributo route viene rappresentato come un insieme di cammini alternativi (può accadere che

una route sia preferibile in un momento rispetto ad un altro). Per costruire la struttura dati, il BGP

speaker aggiunge il proprio indice alla struttura ottenuta dai cammini che gli sono stati

comunicati dai vicini; successivamente la nuova route viene comunicata ai vicini con un’operazione

detta advertisement, che permette di costruire la route con un cammino a ritroso. In questo modo

gli speaker sono in grado di evitare cicli nella route.

Gli ultimi due tipi di messaggio sono utilizzati per la gestione del collegamento. Il messaggio

keepalive contiene solo lo header, e viene spedito periodicamente da ciascun partner per indicare

che viene mantenuta la connessione; nel messaggio open viene definito l’intervallo massimo fra

due messaggi keepalive (nel campo Hold time). Il messaggio notification indica la rilevanza di un

errore, con la sua descrizione sintetica e una parte di dati di lunghezza variabile.

Interior Routing

Nel caso più semplice, la tabella di routing è statica, impostata manualmente o automaticamente.

Altrimenti esistono algoritmi dinamici che agiscono sulla base dello scambio di tabelle fra router,

scambio che avviene con pacchetti IP o UDP, per cui gli algoritmi devono prevedere perdita,

duplicazione e inversione dei pacchetti. Questi protocolli possono modificare le tabelle in caso di

cambiamento di condizioni della rete (sostituzione di collegamenti inefficienti, ecc.) Questi algoritmi

vengono divisi in due grandi famiglie: distance vector e link state. In una rete è fondamentale

stabilire i costi di comunicazione, in modo da ottimizzare il percorso dei dati comunicati: a

ciascuno dei link uscenti di un certo router viene associato un costo detto metrica; la sottorete a

cui appartiene il router si considera a distanza 0.

La tabella di routing si riferisce al router X che da

accesso alla rete n0. Nella prima colonna troviamo

la rete a cui si vuol arrivare, il router successivo

(next hop) per arrivare a tale rete e il costo

necessario ad arrivarci (per arrivare a n1 il router

successivo è A e il costo è 1). Una volta ricevuto un

pacchetto IP da inoltrare, individuo l’indirizzo del

nodo destinatario, controllo a quale delle sottoreti

appartiene il nodo e inoltro il pacchetto al router

indicato su quella riga.

Il protocollo RIP (Routing Information Protocol)

Il protocollo RIP è un protocollo del tipo distance vector (ciò che i router si scambiano è la tabella

delle distanze dalle possibili destinazioni) che utilizza l’algoritmo di Bellmann-Ford. Viene

impostato un timer di intervalli randomizzati di circa 30 secondi, dopo i quali viene inviato un

messaggio advertisement (porta UDP 520) contenente il distance vector; ogni router invia la

propria tabella di routing solamente ai router vicini. Il router che riceve il messaggio incrementa di

un’unità la distanza relativa a ciascuna riga creando il proprio distance vector, e per ogni riga cerca

nella propria tabella una riga con destinazione uguale: se non la trova la aggiunge, se la trova e

proviene dal router indicato come prossimo router aggiorna la route con il nuovo valore, in caso

non provenga dal router indicato come prossimo router sostituisce alla distanza in tabella la

minore fra le due (quella ricevuta o quella già nota). Il router X riceve dal router vicino C il

seguente distance vector: (n2,1)(n3,0).

Dopodiché il router X incrementa le

metriche e ottiene il proprio distance vector

(n2,2)(n3,1).

La tabella di routing precedente, che non

era ottimizzata, viene modificata una volta

che il router X ottiene il proprio distance

vector, in modo da rendere la

comunicazione più efficace.

Non c’è un modo per indicare l’interruzione di un link, la rilevazione viene associata al timeout:

se non ricevo il messaggio di aggiornamento previsto, il link viene considerato interrotto (il valore

del timeout è di 30 secondi, un tempo molto lungo per la comunicazione). Per rimediare a questo

problema si ricorre al route poisoning: si assegna al collegamento con il router assente il valore

massimo 16, che corrisponde a infinito, riuscendo a rendere più veloce la risposta. RIP è usato in

reti di piccole dimensioni, poiché la sua convergenza è molto lenta .

Consideriamo una rete con 4 router, in cui noi siamo posizionati sul

punto nero e abbiamo la seguente tabella di routing. Che cosa

accade nel momento in cui il link (B,D) si interrompe? La situazione

ottimale diventerebbe (D,1)(B,C,12)(C,D,11)(A,C,12). In realtà, la

situazione converge lentamente alla situazione desiderata, poiché B

riceve da C una distanza 3 dalla destinazione sulla base delle

vecchie distanze, che era vera quando il link (B,D) era ancora

funzionante, per cui si passa alla situazione (D,1)(B,C,4)(C,D,4)(A,C,

4), e così via, passo per passo, fino alla situazione ottimale.

Il protocollo OSPF (Open Short Path First)

OSPF è un protocollo del tipo link state, che supera le limitazioni del protocollo RIP, usato per

configurare il routing all’interno di un sistema autonomo. La comunicazione avviene solamente al

cambiamento dello stato di un link: ogni router monitora il costo e lo stato dei propri link, e in

caso di variazione (cambio del costo, guasto, ecc.), comunica nella rete il cambiamento. Il

messaggio viene chiamato Link State Advertisement (LSA): inizialmente ogni router determina il

costo dei rami uscenti e invia questi dati in un LSA a tutti i router della rete; la tecnica di

comunicazione viene detta di flooding, poiché la comunicazione passa da vicino a vicino fino ad

arrivare a tutti i nodi (l’LSA viene inviato da un router su tutte le sue interfacce tranne quella da cui

è stato ricevuto). OSPF si basa su alcuni vincoli nella configurazione della rete: questa viene

suddivisa in un certo numero di aree connesse da un backbone, ognuna delle quali contiene

almeno un router di confine adiacente a un router del backbone; il percorso di un pacchetto con

la destinazione in un’altra area transita necessariamente nel backbone prima di entrare nell’area di

destinazione. Questa topologia permette di limitare la diffusione della comunicazione alle aree

interessate. Alla fine del processo, ogni nodo conosce lo stato dell’intera rete e può usare

localmente l’algoritmo Dijkstra per determinare le route per i pacchetti.

Il flooding viene quindi usato per mantenere aggiornati i database dei router del sistema

autonomo, con un processo che conduce ad un broadcast (comunicazione da uno a tutti). La

procedura inizia con la ricezione di un Link State Update (LSU), che contiene uno o più LSA:

viene considerata la correttezza del LSA (checksum o test di ragionevolezza), poi, se il dato

ricevuto non è presente o è più recente di quello nel database del router, viene memorizzato,

viene schedulato il ricalcolo dei cammini minimi, viene inviato un Link State Acknowledgement e

l’LSU viene rilanciato su tutte le interfacce del router tranne quella di ricezione; se il dato ricevuto

è presente ed è più vecchio di quello contenuto, viene rilanciato un LSU con il valore contenuto

nel database esclusivamente sull’interfaccia di arrivo del messaggio.

L’algoritmo Dijkstra, è utilizzato per calcolare il cammino minimo da un nodo ad un altro: le route

calcolate da un router X hanno l’aspetto di un albero di cammini minimi con X come radice. Ad ogni

nodo viene assegnata una distanza preliminare dagli altri nodi (0 per la radice e ∞ per gli altri

nodi). Successivamente si aggiorna la distanza dei

nodi adiacenti al nodo in cui ci si trova, sommando

distanza del nodo in cui ci si trova con il costo del

collegamento (metrica); se la distanza esiste già,

ma è maggiore della nuova, viene sostituita. Ci si

sposta poi sul nodo il cui potenziale è minore e si va

avanti con un’iterazione. Alla fine del ciclo, per ogni

nodo sarà registrato il nodo successivo del cammino

minimo e la sua lunghezza.

Il protocollo Hello ha il compito di stabilire e mantenere la relazione di adiacenza, caratterizzata

dalla proprietà della simmetria (N1 è adiacente a N2 e N2 è adiacente a N1). Il protocollo si occupa

anche dell’elezione del router designato di una rete broadcast.

Un router prova ad inviare un pacchetto Hello al vicino, passando nello stato Attempt; nelle reti

broadcast vengono spediti pacchetti con la cadenza richiesta. Nel momento in cui il pacchetto

viene ricevuto, si passa allo stato Init per un periodo corrispondente alla cadenza dei messaggi

richiesta dalla rete. Se il vicino risponde a sua volta con un pacchetto Hello, significa che

l’adiacenza sussiste, e quindi si passa allo stato 2-way. Il passaggio allo stato ExStart indica che

è stata stabilita l’adiacenza.

La creazione dell’adiacenza inizia con la specificazione del router master e del router slave: il

router con l’indirizzo IP superiore è il master; in questo modo può avvenire la sincronizzazione dei

dati attraverso lo scambio di una serie di pacchetti. Si passa quindi alla fase di Exchange, in cui il

master spedisce pacchetti allo slave finchè questi non vengono riscontrati; questa fase termina

quando entrambi rispettano il flag more nel loro pacchetto. Si passa alla fase di Load, in cui

ciascun router richiede all’altro lo stato dei link che risultano meno aggiornati. Dopo questo passo,

l’adiacenza è completa.

Il protocollo OSPF può interagire con protocolli di exterior routing, e può trattare le

informazioni che provengono da altri sistemi autonomi, raccolte tramite BGP e diffuse come lo

stato di un tipo particolare di link. Il sistema autonomo gestito da OSPF è rappresentato da nodi

che possono essere router, reti o host: un arco fra due router è un collegamento data link, un arco

fra una rete e un router indica che questo ha un interfaccia su quella rete (due reti possono

comunicare solo tramite un router). Una rete può essere abilitata ad eseguire operazioni di

broadcast o multicast (es. Ethernet), e in tal caso viene eletto un router designato per

rappresentare l’intera rete nel protocollo OSPF. In una rete non abilitata al broadcast (es. PPP),

questo può essere emulato, eleggendo un router designato che provveda a diramare

l’informazione nella rete: si parla di gestione NBMA del protocollo. Un altro metodo è gestire la

rete con modalità Point-to-Multipoint, considerando tutti i collegamenti fra i router interni alla rete

come link punto a punto.

Ad ogni uscita da un

router viene associato

un costo

corrispondente al costo

del link in uscita verso

un altro router o

un’altra rete. Vengono

anche rappresentate

reti esterne (N12-N15)

i cui costi sono calcolati

tramite un protocollo di

routing esterno.

Tenendo conto della strutturazione del sistema autonomo, i router possono essere classificati in:

router interni che eseguono l’algoritmo di routing per le route intra-area, router di confine che

eseguono l’algoritmo di routing su ciascuna delle aree collegate, router del backbone che hanno

un’interfaccia verso l’area di backbone (tutti i router di confine sono anche di backbone, ma non

viceversa), router di confine del sistema autonomo che diramano nel sistema le route esterne. Il

cammino di un pacchetto fra due nodi appartenenti a due aree diverse viene diviso in tre parti: il

cammino intra-area dal nodo di partenza al router di confine, il cammino nel backbone, il

cammino intra-area nell’area di destinazione. I router di confine scambiano fra loro informazioni

sulla raggiungibilità delle reti interne, grazie alle quali ciascun router è in grado di calcolare

l’albero dei cammini minimi per ciascuna delle reti interne alle diverse aree.

Questa tabella rappresenta l’informazione diramata nel backbone dai router

di confine dell’area 1, R3 e R4; i costi sono relativi ai router e sono calcolati

da OSPF internamente all’area. Il backbone ottiene quindi informazioni sulla

raggiungibilità delle reti all’interno dell’area 1.

La tabella in basso a sinistra rappresenta le informazioni che ogni router (ogni colonna) conosce,

ovvero la raggiungibilità delle reti entro la propria area, lo stato dei link con i router adiacenti e

la raggiungibilità delle reti esterne all’AS. Per esempio, se volessi andare da R3 a N7, dovrei

passare per R6 con costo 8, poi da R10 con costo 7 e infine arrivare a N7 con costo 5. Sulla base

di questa tabella ogni router elabora il proprio albero per ottenere la tabella di routing nel

backbone (tabella al centro), e quindi calcola i cammini verso le varie reti del sistema (tabella a

destra). Queste informazioni vengono distribuite entro la propria area, e costituiscono il database

dell’area stessa (in questo caso l’area 1).

Possiamo quindi individuare vari tipi di link state advertisement: router LSA (tipo 1) generato da

tutti i router e diffuso entro la propria area, network LSA (tipo 2) generato dal router designato di

una rete broadcast e diffuso entro l’area, summary LSA (tipo 3 o 4) generato da router di confine

di un’area e diffuso entro l’area, AS-external LSA (tipo 5) generato da router di confine del

sistema autonomo e diffuso entro il sistema stesso.

Tutti i tipi di LSA hanno in comune uno header iniziale: LS Age

indica da quanti secondi è stato generato lo specifico messaggio,

Type indica il tipo di LSA, Opt indica varie opzioni, LS Sequence

Number serve a determinare il più recente fra due LSA relativi allo

stesso link, la Checksum indica la verifica dell’intero LSA, la

Lunghezza indica la lunghezza in ottetti.

L’esecuzione del protocollo avviene in varie fasi:

l’inizializzazione consiste in un test funzionale dello strato Data Link

• acquisizione dei vicini tramite un protocollo chiamato Hello

• acquisizione delle adiacenze con sincronizzazione delle strutture dati

• flooding dello stato dei link del router entro l’area

• acquisizione delle informazioni da parte dei router del backbone

8. Il servizio DNS

La visualizzazione di un FQDN (Fully Qualified Domain Name) consiste nell’associare a un

indirizzo IP un identificatore detto dominio (es. www.google.com) che rappresenta una gerarchia

amministrativa e un servizio. Il servizio DNS (Domain Name System) serve a collegare un

indirizzo numerico IP con un dominio; la quantità di indirizzi e la necessità di risolvere rapidamente

la corrispondenza pone grossi problemi. La gestione della tabella di corrispondenze viene

distribuita su un gran numero di server DNS, che saranno responsabili (authoritative) per un certo

numero di indirizzi IP, in base alla configurazione dell’amministratore del server; altri server

intermedi registrano in una cache temporanea le corrispondenze ottenute da altri server DNS.

Ogni nodo Internet viene configurato con l’indirizzo IP di un server DNS a cui richiedere la

risoluzione delle corrispondenze, e contiene un programma client, detto resolver, per il protocollo

DNS. L’applicazione utilizzata (browser, ping, ecc.) deve risolvere un dominio, per cui richiede al

resolver l’indirizzo IP corrispondente a un certo dominio; il resolver invia una richiesta di

risoluzione al server DNS che conosce, il quale tratta la richiesta (se non lo conosce lo richiede

ad altri server DNS) e restituisce l’indirizzo IP al client sul nostro host; quest’ultimo consegna

l’indirizzo IP all’applicazione.

Gli indirizzi FQDN sono organizzati secondo una gerarchia di domini, introdotta anche per evitare

duplicazioni. Tale gerarchia è espressa con la notazione puntata: il dominio più ampio è l’ultimo (it,

com, ecc.) ed è chiamato Top Level Domain (TLD), il secondo

è il dominio aziendale (es. google), e all’inizio viene posto

l’indicatore dell’host o di un servizio specifico (www); gli

elementi possono anche essere più di tre, ordinati dalla foglia

verso la radice (da sinistra a destra). La gerarchia dei server

ricalca quella degli indirizzi: ci sono server root (sono 13 nel

mondo, con contenuto sincronizzato), server Top Level

Domain (TLD) e server aziendali. Il server mantiene un

database di Resource Records (RR) che rappresentano la

corrispondenza fra un dominio e un indirizzo IP, e per i server

aziendali vengono inseriti dall’amministratore.

Volendo usare una soluzione non ricorsiva, una richiesta dovrebbe seguire il seguente schema:

richiedo a uno dei server root l’indicazione del server autorevole per il TLD, successivamente

richiedo a quest’ultimo l’indicazione di un server autorevole per il dominio aziendale, e così via

scendendo nella gerarchia dei server (es. richiedo al server di radice quale sia il server autorevole

per .com, poi richiedo al server .com quale sia il server autorevole per google, ecc.) Questo

meccanismo crea sui server di root un traffico enorme e non ottimale, per cui si ricorre a una

modalità ricorsiva: il server ricorso mantiene una cache degli indirizzi dei server autorevoli,

diventando a sua volta server non autorevole ed eseguendo i passi di ricerca visti sopra al posto

del cliente. Solitamente i server DNS primari vengono configurati come ricorsivi e vengono

attrezzati in modo da gestire cache di grandi dimensioni. L’utente non conosce i server di root

ma solo un server primario a cui chiede la risoluzione degli indirizzi: se questo non è in grado di

risolvere la corrispondenza,

consulta il server root che gli

comunica il server autorevole

per il TLD; quest’ultimo viene

registrato nella cache, quindi il

server primario contatta il server

autorevole per il TLD e così via.

Alla fine del processo, il server

primario avrà nella cache gli IP

dei server autorevoli e non

dovrà più richiederli ai server di

root.

La creazione di un FQDN avviene attraverso un’operazione amministrativa complessa. Il servizio

Internet che opera la registrazione del dominio è detto registrar, e si occupa di verificare che il

dominio non sia duplicato e di inserire un Resource Record (associazione dominio—>IP) nel

proprio server DNS. La configurazione iniziale di un server si ottiene inserendo un certo numero di

records in un file che viene letto dal server all’accensione, determinando i domini per cui questo

è autorevole. Il Resource Record è organizzato in vari campi: il campo NAME indica il FQDN, il

campo TYPE specifica il tipo di associazione (A per l’associazione FQDN—>IP, AAAA per

l’associazione FQDN—>IPv6, NS per l’associazione NameServer—>Zona, ecc.), il campo TTL

indica il periodo di validità del dato se presente in una cache, il campo RDATA indica il dato

associato al campo NAME, e può essere l’indirizzo IP. Esiste una funzionalità di Reverse-DNS per

cui il server è in grado di fornire il FQDN conoscendo l’IP: in questo caso il campo NAME

corrisponde all’IP numerico seguito dal dominio in-addr.arpa, e il campo RDATA contiene domini

che corrispondono ai quattro numeri contenuti nell’IP.

Il DNS si basa sullo scambio di messaggi incapsulati in datagrammi UDP: la perdita di pacchetti

non è problematica, poiché un RR perduto può essere richiesto nuovamente dopo un timeout e

non è necessario un controllo di flusso, poiché la comunicazione si esaurisce alla consegna del

RR. Ciò che è più importante è l’integrità del RR, verificabile tramite la checksum del datagramma.

Un messaggio DNS ha una struttura precisa: contiene uno header che identifica la sorgente del

pacchetto, specifica se si tratta di interrogazione o di risposta, specifica l’uso eventuale della

ricorsione e quantifica il numero di sezioni dei vari tipi inserite nel pacchetto; infatti, il resto del

pacchetto è organizzato in un numero variabile di sezioni, appartenenti a quattro categorie:

query (nome del dominio di cui si vuol conoscere l’IP), risposte (RR completi in risposta alla

domanda), risposte authoritative (come le precedenti ma nel caso in cui il mittente è autorevole),

altre RR (aggiunte per arricchire la cache del ricevente).

9. Il multicast IP

Per il momento abbiamo considerato soprattutto la comunicazione unicast (da un indirizzo a un

altro), ma esistono vari modi per fare multi/broadcast: è possibile spedire a tutti gli host della

stessa sottorete utilizzando l’indirizzo IP di broadcast (255.255.255.255 come DHCP), oppure

spedire a tutti i nodi che vogliono ricevere. Il multicast viene realizzato a livello IP utilizzando il

protocollo IGMP (Internet Group Membership Protocol). IPv4 predispone per il multicast un

range di indirizzi Classe D (da 244.0.0.0 a 239.255.255.255), anche denominati gruppi multicast.

Le comunicazioni tra i nodi adiacenti avvengono tramite una connessione a livello 2, infatti IGMP

occupa nella gerarchia Internet un posto vicino a ICMP (rientra come parte integrante di IP e

aggiunge a questo le funzionalità necessarie). Con questa procedura, il mittente spedisce su uno

degli indirizzi di multicast, e per ricevere il messaggio, un nodo aderisce al gruppo con una join,

usando il protocollo IGMP. Il compito del protocollo è di registrare adesioni e abbandoni a gruppi

multicast.

Il messaggio IGMP ha una struttura precisa: il campo Type distingue diverse funzionalità del

messaggio (0x11 indica una membership query che può essere estesa a tutti i gruppi o limitata a

un gruppo, 0x16 indica un membership report di risposta a una query, 0x17 indica un leave group

e informa dell’abbandono), il campo Max Response Time indica il timer utilizzato nel messaggio di

query, la Checksum serve a controllare l’integrità e il campo Group Address indica l’indirizzo del

gruppo a cui ci si riferisce.

Un router IGMP è dotato di funzionalità speciali che lo rendono adatto a gestire il multicast. Questo

spedisce a intervalli regolari messaggi di query, che servono a rilevare la presenza di destinatari

o altri router multicast; gli host o i router interessati inviano in risposta un messaggio di report. Se

riceve la risposta, il router diventa membro del gruppo. Quando la catena di report raggiunge un

router multicast che riceve lo stream dal mittente, inizia il flusso di dati downstream. Un caso

speciale di query è detta general query, e ha lo scopo di verificare la presenza di membri del

gruppo a cui un router non è ancora registrato.

Il messaggio di query viene usato per tenere aggiornata la struttura dati che contiene i gruppi per

cui esistono membri. Per ciascuno degli elementi nella tabella viene mantenuto un timer che

determina l’intervallo per la spedizione dei messaggi di query. Il router che invia le query viene

chiamato querier, che fra tutti i router collegati a un certo link a livello 2 è quello con l’indirizzo IP

inferiore. Per determinarne l’identità, all’accezione ogni router multicast entra nello stato di

querier e invia messaggi di query, uscendo da questo stato nel caso in cui riceva una query da un

altro router con IP inferiore al suo.

Grazie al protocollo IGMP, il messaggio di report di un gruppo viene limitato ad uno, altrimenti

sarebbe spedito da tutti i membri del gruppo. Nell’invio del messaggio il router imposta per i nodi

del gruppo un ritardo di spedizione casuale entro un intervallo massimo stabilito nella query: se il

timeout scade, il router spedisce il messaggio in multicast all’intero gruppo, se riceve un report da

uno dei nodi del gruppo, il router azzera il timer senza spedire il report. Il router che riceve un

report per un certo gruppo lo aggiunge ai gruppi per cui esistono membri e imposta il timeout per

la ricezione del prossimo report; se il router non riceve il report entro il timeout, smette di inoltrare

i pacchetti su quella interfaccia.

Il messaggio di leave notifica l’abbandono di uno dei nodi del gruppo. L’assenza di membri viene

rilevata allo scadere di un timer con il valore di qualche minuto, e quindi le tempistiche sono molto

lunghe. Per ridurle si usa un messaggio esplicito di leave, inviato al gruppo di tutti i routers

(244.0.0.2), solo se a lasciare il gruppo è il nodo che ha spedito l’ultimo report. Il router, ricevendo

un leave, verifica l’esaurimento del gruppo inviando query: una general query ha un timer di

default che si avvicina a 260 secondi, mentre la ricezione di una leave esplicita porta alla

spedizione di una serie di messaggi di query per il gruppo, con un timer che ha default a 2 secondi,

riducendo di molto le tempistiche. Non-member indica che l’host non appartiene al

gruppo, Member (dalay) indica che l’host

appartiene al gruppo e ha ricevuto una query per

cui il timer non è ancora scaduto, Member (idle)

indica che l’host appartiene al gruppo e il timer non

è settato. Gli eventi che causano una transizione di

stato sono: join (adesione al gruppo), leave

(abbandono del gruppo), query recieved

(messaggio di query ricevuto), report recieved

(messaggio di report ricevuto). Gli eventi portano

poi a una serie di azioni: send report, send leave,

set flag, clear flag, start timer, rese timer, clear

timer.

In questo esempio vediamo un querier che invia una query ai nodi a, b,

c. Tutti e tre i nodi, alla ricezione della query, settano un timeout casuale

(a-7, b-6. c-5). Il primo nodo del gruppo ad inviare il report è quello col

timeout più basso (c-5), mentre gli altri non invieranno il report per non

sovraccaricare il traffico. Successivamente vediamo che b esce dal

gruppo (pallino rosso). Poi il querier invia un’altra query e il

meccanismo si ripete, ma stavolta è il nodo a ad inviare il report, poiché

ha il timeout più basso (a-3, c-4). Successivamente anche a lascia il

gruppo. Infine si ripete il meccanismo, e dato che rimane un solo nodo

sarà lui a spedire il report. Infine anche c lascia il gruppo, e il querier

esce dal gruppo non ricevendo più messaggi di report.

No Members indica che nessuno degli host

della rete collegata ha spedito report,

Members indica che uno degli host ha

spedito un report per quel gruppo, Checking

indica che uno degli host ha inviato un leave

per quel gruppo, e il router attende il report.

Gli eventi che causano una transizione

sono: report received (ricezione del report),

leave recieved (ricezione del leave), timer

expired (relativo al timer per l’adesione),

rxmt timer expired (relativo al timer per la

ritrasmissione della query senza risposta).

Le azioni possono essere: timer start, timer

start*, notify routing + (ci sono membri del

gruppo), notify routing - (non ci sono membri

del gruppo), ecc.

Il modulo di routing (software che esegue il routing) riceverà due tipi di notifiche: positiva, e in

questo caso registrerà nella propria tabella di routing che i pacchetti per quel gruppo dovranno

essere istradati su quella interfaccia; negativa, e in questo caso cancellerà la precedente

registrazione, e i pacchetti verranno scartati. In questo modo il router non utilizzerà i gateway

unicast per quei pacchetti.

10. Il protocollo TCP (Transmission Control Protocol)

Questo tipo di protocollo a livello trasporto consente di trasferire fra due applicazioni una

quantità di dati superiori ai 65KByte di UDP (ma sostanzialmente illimitata), con una

comunicazione bilaterale affidabile che le mette in connessione fra loro; l’operazione di apertura

della connessione è asimmetrica: una delle sue applicazioni attende una richiesta (server), l’altra

richiede la connessione (client). Una volta stabilita, la connessione diventa simmetrica, ed

entrambe le applicazioni possono spedire e ricevere. Come in UDP, per ottenere il multiplexing IP

sono introdotte le porte, assegnate a ciascuna applicazione. Gli elementi noti di una connessione

sono l’IP e la porta su cui il server riceve. Altri elementi incogniti sono la porta e l’IP del cliente e

l’SN iniziale di client e server (scelti a caso). Per stabilire questi elementi si usa una transazione

detta three-way handshake: la connessione è iniziata dal client, mentre il server è in attesa,

quindi il cliente invia il primo pacchetto, indicando il proprio IP, la porta e il numero di sequenza

iniziale (SYN); successivamente il server invia il proprio pacchetto, contenente il proprio numero di

sequenza i iniziale e la conferma della ricezione dei dati (SYN-ACK); infine il cliente restituisce un

pacchetto di conferma (ACK). La chiusura della connessione viene invece stabilita con lo scambio

di pacchetti FIN e ACK.

Il flusso di dati viene frammentato in segmenti, che vengono incapsulati in distinti pacchetti IP. Per

trasferire una sequenza di ottetti in modo affidabile e gestire i problemi di perdita, ordine e

duplicazione, TCP introduce alcuni pacchetti che servono per l’apertura e la chiusura della

connessione, mentre altre informazioni di coordinazione vengono introdotte nello header. Un’altra

differenza con UDP consiste nel fatto che TCP introduce un controllo di flusso per garantire

l’affidabilità della comunicazione bidirezionale: è per questo motivo che il protocollo assegna un

identificatore detto sequence number (SN) per ogni ottetto (payload del segmento), in modo da

ordinarli, scartare i duplicati o richiedere i mancanti; per ogni pacchetto IP viene indicato il SN del

primo ottetto contenuto nel segmento che il pacchetto IP contiene. Il destinatario invia in risposta

un acknowledgement (ACK), con cui specifica l’indice del primo ottetto atteso (non ancora

ricevuto): se ACK è successivo all’ultimo byte spedito, è tutto a posto, se invece è precedente,

alcuni byte potrebbero essere ancora in transito o perduti. Un’altra funzione importante è la

finestra di ricezione (WIN), un dato inizializzato in apertura di connessione, che permette di

continuare a spedire un certo numero di dati anche in caso di perdita: il mittente non spedisce byte

che abbiano un SN superiore all’ultimo ACK più la finestra WIN; in questo modo, viene dato un

limite ai dati che possono essere spediti a partire dalla ricezione dell’ultimo ACK da parte del

mittente. Si parla di sliding window, poiché man mano che vengono ricevuti ACK, la finestra si

sposta più avanti. I dati necessari per questo processo sono contenuti nello header del segmento

TCP: SN(32 bit) è il sequence number del primo ottetto inviato del segmento, ACK(32 bit) è l’SN

del primo ottetto atteso, WIN(16 bit) è la finestra di ricezione.


ACQUISTATO

9 volte

PAGINE

36

PESO

4.48 MB

PUBBLICATO

+1 anno fa


DESCRIZIONE APPUNTO

Riassunto esame Telematica del prof. Augusto Ciuffoletti, basato su appunti personali, videolezioni del professore e studio autonomo del testo consigliato dal docente "Computer Networking: A Top-Down Approach" di James F. Kurose, Keith W. Ross. Argomenti trattati: vista generale di Internet, il livello Link, il livello IP, il livello Trasporto, il livello Applicativo, la sicurezza, il cloud computing, ecc.


DETTAGLI
Esame: Telematica
Corso di laurea: Corso di laurea in informatica umanistica (Facoltà di Lettere e Filosofia e di Scienze Matematiche, Fisiche e Naturali)
SSD:
Università: Pisa - Unipi
A.A.: 2016-2017

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher francesac di informazioni apprese con la frequenza delle lezioni di Telematica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Pisa - Unipi o del prof Ciuffoletti Augusto.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Telematica

Esercizi svolti, Telematica
Esercitazione
Appunti Algoritmica
Appunto
Fondamenti Teorici e Programmazione - Modulo B
Appunto
Programmazione Web - Appunti
Appunto