Panoramica generale e navigazione...
- Comprendere i principi su cui è basato il livello di collegamento (data link):
- Rilevazione e correzione degli errori
- Condivisione di un canale broadcast: accesso multiplo
- Indirizzamento a livello di collegamento (riguarda ARP già trattato, vedi qui)
- Local Area Network:
- Canali virtuali (MPLS) e reti dei data center
La navigazione è data dagli argomenti elencati sopra. Consiglio la lettura del paragrafo: introduzione e Servizi offerti dal livello di collegamneto, per poi passare alla navigazione (argomenti elencati sopra) e consultarli nell'ordine in cui sono scritti e linkate le pagine degli argomenti. Dopo aver letto tutti gli argomenti del capitolo tornate su questa pagina per leggere il paragrafo Retrospettiva: cronaca di una richiesta di una pagina web per mettere insieme tutto ciò che è stato affrontato dai capitoli 1 a 6.
Introduzione...
Ciò su cui porremo la nostra attenzione in questo capitolo sono i link o collegamenti. Il nucleo della rete è una maglia di commutatori di pacchetti (router) e collegamenti (link) che interconnettono i sistemi periferici di internet. Le applicazioni si scambiano messaggi di vario genere e dimensione, la sorgente suddivide tali messaggi in pacchetti, dopo di che essi viaggiano da un router all'altro attraverso dei link.
Con link ci riferiamo ai collegamenti tracciati in azzurro nell'immagine sopra.
Ci sono due tipi di collegamento:
- Canali broadcast dove:
- in un gruppo di nodi collegati, tutti ricevono tutto
- il canale è condiviso: accesso multiplo
- è necessario un protocollo per il controllo di accesso al mezzo condiviso (Medium Access Control: MAC, che non ha niente a che vedere con il MAC Address)
- l'indirizzamento avviene a livello di collegamento
- Canali punto a punto dove:
- si devono coordinare solo due nodi
- il problema dell'indirizzamento è assai ridotto
Terminologia
A questo livello di internet non viene fatta nessuna differenza tra host o router, essi prendono il nome di nodi.
Canali di comunicazione connettono nodi adiacenti lungo un cammino di comunicazione: collegamenti (link), che possono essere:
- Cablati (wired), ovvero vengono utilizzati dei cavi per il collegamento
- Wireless
- LAN
Ci si riferisce ad un pacchetto di questo livello con il nome di: frame.
Il compito del livello di collegamento è quello di trasferire datagrammi (pacchetti del livello superiore: 3) da un nodo ad un altro fisicamente adiacente usando un singolo collegamento/mezzo fisico.
Quindi un datagramma viene trasferito da un router all'altra utilizzando un solo mezzo, tuttavia, possono essere utilizzati mezzi diversi, per collegamenti diversi.
Nel corso del percorso che ha inizio in A e termina in D, tra i vari nodi vengono utilizzati più protocolli del livello di collegamento. Il punto è che da nodo a nodo viene utilizzato solamente un protocollo.
Servizi offerti dal livello di collegamento...
- Framing: quasi tutti i protocolli incapsulano i datagrammi del livello di rete all'interno di un frame a livello di collegamento, prima di trasmetterlo. I frame sono costituiti da un campo dati, nel quale è inserito il datagramma, e da vari campi di intestazione. La struttura del frame è specificata dal protocollo utilizzato.
- Accesso al collegamento: un protocollo che controlla l'accesso al mezzo trasmissivo (MAC: medium access protocol) specifica le regole con cui trasmettere i frame. In un collegamento punto-punto con un solo mittente e un solo destinatario, in cui il MAC è semplice (o inesistente), il mittente può inviare il frame quando il canale risulta libero. Un caso più interessante è quello in cui vari nodi condividono un singolo canale broadcast.
- Consegna affidabile: abbiamo già visto che anche alcuni protocolli di trasporto (come TCP) forniscono un servizio affidabile, allo stesso modo può essere realizzato un servizio al livello di collegamento. Tale servizio è spesso utilizzato per collegamenti soggetti a elevati tassi di errore (per esempio wireless) allo scopo di correggere l'errore localmente, sul collegamento dove tale errore si è verificato, invece di costringere nuovamente i protocolli di trasporto o di applicazione a procedere con la ritrasmissione dei dati dalla sorgente alla destinazione. Tuttavia, la consegna affidabile del livello di collegamento può ritenersi non necessaria nei collegamenti che prestano un basso numero di errori sui bit: fibra ottica, cavo coassiale e doppino.
- Rilevazione e correzione degli errori: il nodo ricevente può decidere, erroneamente, che un bit in un frame sia 0 quando questo era stato trasmesso come 1, e viceversa. Gli errori di bit sono causati dall'attenuazione di segnale e dai disturbi elettromagnetici. Siccome non è utile inoltrare datagrammi contenenti errori, molti protocolli del livello di collegamento forniscono un servizio per rilevarne la presenza. Abbiamo visto anche nei livelli 3 e 4 dei sistemi per la rilevazione degli errori attraverso checksum. I metodi usati in questo livello sono molto più sofisticati. La correzione dell'errore è molto simile, in aggiunta alla rilevazione dell'errore il nodo ricevente lo localizza nel punto del frame in cui si è verificato e lo corregge.
Come abbiamo appreso nel capitolo 4, il livello di collegamento di un host è implementato nelle line card dei router. Per un dato collegamento, il protocollo del livello di collegamento è realizzato da un adattatore di rete noto anche come scheda di rete (NIC: network interface card). Il cuore della scheda di rete è il controller a livello di collegamento, che è di solito un chip dedicato che implementa molti dei servizi sopra descritti. Quindi il livello di collegamento è implementato in hardware.
Retrospettiva: cronaca di una richiesta di una pagina web...
Di seguito verrà fatto un riepilogo di come avviene la richiesta di una pagina web a partire dal momento in cui un host si connette alla rete, passando per DHCP, ARP, datagrammi, frame, DNS, ecc. Quello che segue è un riepilogo di tutto ciò che abbiamo visto (compreso il livello di collegamento appena trattato). Suggerisco di tornare a questa sezione solo dopo aver letto e studiato tutto ciò che riguarda il livello di collegamento.
Si comincia: DHCP, UDP, IP, Ethernet...
Quando Bob accende il suo laptop e lo collega tramite un cavo ethernet allo switch ethernet della scuola, che a sua volta è connesso al router della scuola, Bob non ha ancora un indirizzo IP e dunque non può effettuare, allo stato delle cose, alcuna richiesta.
Il provider della scuola è un ISP Comcast, tale ISP fornisce il servizio di DNS alla scuola, quindi il server DNS risiede nella rete Comcast, piuttosto che nella rete della scuola.
La prima cosa che il laptop di Bob deve fare è ottenere un indirizzo IP, dunque effettuare una richiesta DHCP per ottenere l'indirizzo e altre informazioni. La richiesta va effettuata al server DHCP che normalmente è installato nel router.
- Il sistema operativo del laptop di Bob crea un messaggio DHCP request e inserisce questo messaggio in un segmento UDP con porta di destinazione 67 (server DHCP) e porta 68 (client DHCP). Il segmento UDP viene inserito in un datagramma IP con indirizzo IP di destinazione (255.255.255.255) broadcast e indirizzo IP sorgente 0.0.0.0, poiché il dispositivo di Bob non ha ancora un IP.
- Il datagramma IP contenente la richiesta DHCP è posto in un frame ethernet. Il frame ha indirizzo MAC di destinazione (FF:FF:FF:FF:FF:FF) broadcast. Il frame verrà ricevuto da tutti i dispositivi nella speranza di beccare il server DHCP. Il MAC sorgente del dispositivo di Bob è 00:16:D3:23:68:8A.
- Lo switch inoltra il frame a tutte le sue porte, compresa quella in cui è connesso il router (in cui gira il server DHCP).
- Il router riceve il frame sulla sua interfaccia. Il datagramma IP viene estratto dal frame. L'indirizzo IP di destinazione del datagramma (broadcast) indica che il datagramma deve essere elaborato ad un livello superiore, allora il payload del datagramma (pacchetto UDP) viene estratto e passato al livello superiore (viene effettuato demultiplexing) verso UDP e il messaggio di richiesta DHCP viene estratto dal segmento UDP. Ora il server DHCP ha il messaggio di richiesta DHCP.
- Supponiamo che il server possa allocare indirizzi IP nel blocco CIDR 68.85.2.0/24. Supponiamo che il server DHCP allochi l'indirizzo 68.85.2.101 al laptop di Bob. Il server DHCP crea un messaggio DHCP ACK contenente l'IP scelto per il device di Bob, insieme all'IP del server DNS (68.87.71.226), l'IP del gateway di default (68.85.2.1) e il blocco della sottorete (68.85.2.0/24). Il messaggio DHCP è posto all'interno di un segmento UDP, inserito in un datagramma IP, a sua volta inserito in un frame ethernet. Il frame ethernet ha come MAC di destinazione quello del dispositivo di Bob e come MAC sorgente quello dell'interfaccia del router che si affaccia sulla rete scolastica (00:22:6B:45:1F:1B).
- Il frame ethernet contenente DHCP ACK è inviato in unicast (direttamente al device di Bob) dal router allo switch, lo switch poiché è in grado di apprendere in autonomia e ha precedentemente ricevuto dal laptop di Bob un frame ethernet contente la richiesta DHCP, sa di dover inoltrare un frame indirizzato al MAC 00:16:D3:23:68:8A solo alla porta di uscita verso il laptop di Bob.
- Il laptop di Bob riceve il frame ethernet contenente il messaggio DHCP ACK, estrae dal frame ethernet il datagramma IP, estrae dal datagramma IP il segmento UDP ed estrae dal segmento UDP il messaggio DHCP ACK. Il client DHCP di Bob memorizza il suo indirizzo IP e quello del server DNS. Inoltre installa nella sua tabella di inoltro l'indirizzo del gateway di default a cui, eventualmente, dirigere pacchetti che non fanno parte di 68.85.2.0/24. A questo punto, il laptop di Bob ha inizializzato le sue componenti di rete e può iniziare ad elaborare la lettura della pagina web.
Siamo ancora all'inizio: DNS e ARP...
Quando Bob scrive l'URL www.google.com nel suo browser inizia la lunga catena di eventi che alla fine porterà a visualizzare la pagina di Google. Il browser crea una socket TCP che verrà usata per inviare una richiesta HTTP a www.google.com. Il laptop di Bob, per creare la socket, deve conoscere l'indirizzo IP di www.google.com, entra quindi in gioco qui il protocollo DNS che usato per tradurre un nome in IP.
8. Il sistema operativo del laptop di Bob crea un messaggio di DNS query. Il messaggio è posto in un segmento UDP con porta di destinazione 53 (server DNS). Il segmento UDP è posto in un datagramma con IP di destinazione 68.87.71.226 (indirizzo del server DNS che è stato restituito da DHCP ACK al passo 5) e indirizzo IP sorgente 68.85.2.101.
9. Il laptop di Bob quindi inserisce il datagramma contenente il messaggio di richiesta DNS in un frame ethernet che verrà inviato, con indirizzo a livello di collegamento, al gateway della scuola (68.85.2.1), non conosce il MAC di esso, per ottenerlo effettua una richiesta ARP.
10. Il laptop di Bob crea un messaggio di ARP query con IP di destinazione quello del gateway di default, pone il messaggio ARP all'interno di un frame ethernet con indirizzo di destinazione MAC broadcast e lo invia allo switch che lo inoltra a tutti i dispostivi connessi.
11. Il gateway nota che l'IP presente nella richiesta ARP è il suo, allora fornisce il suo MAC al mittente della richiesta ARP. Il gateway prepara una ARP reply che indica che il suo indirizzo MAC 00:22:6B:45:1F:1B corrisponde con l'IP 68.85.2.1. Pone il messaggio di risposta ARP in un frame ethernet con indirizzo di destinazione MAC quello del dispositivo di Bob e invia il frame allo switch che lo consegna al computer di Bob.
12. Il laptop di Bob riceve il frame contenente la risposta ARP ed estrae l'indirizzo MAC del gateway dal messaggio di risposta ARP.
13. Il laptop di Bob può ora indirizzare il frame ethernet contenente l'interrogazione DNS all'indirizzo MAC del gateway. Si noti che il datagramma IP in questo frame ha indirizzo IP di destinazione 68.87.71.226 (server DNS), mentre il frame ha indirizzo di destinazione del router gateway (Consegna indiretta). Il laptop di Bob invia questo frame allo switch che lo consegna al gateway.
Siamo ancora all'inizio: instradamento intra-dominio al server DNS...
- Il gateway riceve il frame ed estrae il datagramma IP con l'interrogazione DNS. Il router ricerca l'indirizzo di destinazione di tale datagramma (68.87.71.226) e determina sulla base della sua tabella di inoltro che il datagramma dovrebbe essere inviato al router più a sinistra nella rete Comcast (vedi figura sopra). Il datagramma IP è posto all'interno di un frame appropriato per il collegamento che connette il router della scuola al router Comcast più a sinistra; il frame viene trasmesso.
- Il router Comcast più a sinistra riceve il frame, estrae il datagramma IP, esamina l'IP di destinazione e determina l'interfaccia di uscita basandosi sulla sua tabella di inoltro che è stat riempita utilizzando algoritmi come OSPF e dal protocollo inter-dominio di internet BGP.
- Infine, il datagramma IP contente l'interrogazione DNS arriva al server DNS, che estrae il messaggio, ricerca www.google.com nel suo database DNS e trova il record di risorsa DNS che contiene l'IP di www.google.com (assumendo che si trovi nella cache del server DNS). Il DNS prepara il messaggio di DNS reply contenente la corrispondenza tra il nome dell'host e l'indirizzo IP, lo pone in un segmento UDP, pone il segmento in un datagramma indirizzato al laptop di Bob. Questo datagramma verrà restituito al router della scuola attraverso la rete Comcast e poi al laptop di Bob tramite lo switch ethernet.
- Il laptop di Bob conosce ora l'IP di www.google.com dal messaggio DNS. Finalmente, dopo un tanto lavoro, Bob può accedere a Google.
Interazione client-server: TCP e HTTP...
- Il laptop di Bob, ora che ha l'IP di www.google.com, può creare la socket TCP che verrà usata per inviare un messaggio di HTTP GET a www.google.com. Quando Bob crea la socket TCP, per prima cosa il laptop effettua l'handshake a tre vie con TCP su www.google.com. Quindi il laptop di Bob crea un segmento TCP SYN con porta di destinazione 80 (per HTTP), pone il segmento TCP all'interno di un datagramma IP con IP di destinazione 64.223.169.105 (www.google.com), pone il datagramma all'interno di un frame con indirizzo MAC di destinazione del gateway.
- I router nelle reti della scuola, di Comcast e di Google inoltrano il datagramma contenente TCP SYN a www.google.com, usando ognuno la propria tabella di inoltro, come spiegato nei passi 14-16. Si ricordi che le righe delle tabelle di inoltro dei router che governano la procedura di inoltro dei pacchetti sul collegamento inter-dominio tra Comcast e Google sono determinate dal protocollo BGP.
- Infine, il datagramma contente TCP SYN arriva a www.google.com. Il messaggio TCP SYN viene estratto dal datagramma e viene effettuato un demultiplexing verso la socker di benvenuto associata alla porta 80. Viene creata una socket di connessione per la connessione TCP tra server HTTP di Google e il laptop di Bob. Un segmento TCP SYNACK viene generato, posto all'interno di un datagramma indirizzato al laptop di Bob e infine inserito in un frame appropriato al collegamento tra www.google.com e il primo router.
- Il datagramma contenente il segmento TCP SYNACK viene inoltrato attraverso le reti di Google, Comcast e della scuola per arrivare infine alla schede ethernet del laptop di Bob. Viene effettuato demultiplexing del datagramma all'interno del sistema operativo alla socket TCP creata al passo 18, che entra nello stato di connessione.
- Con la socket sul laptop di Bob finalmente pronta per trasmettere byte a www.google.com, il browser di Bob crea il messaggio HTTP GET contenente l'URL da leggere. Quindi il messaggio HTTP GET viene scritto nella socket e diventa il payload di un segmento TCP. Il segmento TCP viene posto in un datagramma, inviato e consegnato a www.google.com come descritto nei passi 18-20.
- Il server HTTP di www.google.com legge dalla socket il messaggio HTTP GET, crea un messaggio di risposta HTTP, pone il contenuto della pagina web richiesta nel corpo del messaggio di risposta HTTP che invia alla scoket TCP.
- Il datagramma contenente il messaggio di risposta HTTP viene inoltrato attraverso le reti di Google, Comcast e della scuola al laptop di Bob. Il borwser di Bob legge dalla socket la risposta HTTP, estrae il codice HTML della pagina web dal corpo della risposta HTTP e finalmente visualizza la pagina web.