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

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