Teoria Unico Word PDF

LIVELLO RETE Internet è una rete di reti capaci di funzionare come un’unica rete, tale interconnessione è resa possibile grazie allo stack TCP/IP e a dispositivi di rilegamento, chiamati router. Principali funzioni di internet: - Connette sistemi terminali: host (client) e server - Usa...

LIVELLO RETE Internet è una rete di reti capaci di funzionare come un’unica rete, tale interconnessione è resa possibile grazie allo stack TCP/IP e a dispositivi di rilegamento, chiamati router. Principali funzioni di internet: - Connette sistemi terminali: host (client) e server - Usa la commutazione di pacchetto: ogni flusso di dati end-to-end è diviso in pacchetti (datagrammi) - Principio di consegna best effort (non è garantito l’arrivo dei pacchetti) - Identifica ogni end-system con un indirizzo numerico univoco: l’indirizzo IP 32 bit in IPv4 128 bit in IPv6 Non è associato a un host/router ma ad un’interfaccia, cioè il punto di connessione tra un dispositivo e la rete (es: scheda di rete) Gli end-system (es: pc, tablet, sensori, elettrodomestici) possono essere sorgente e/o destinazione di informazioni e dispongono di una interfaccia fisica verso una rete e quindi di un indirizzo IP assegnato a quell’interfaccia. I router hanno la funzione di inoltrare le unità informative IP, ovvero i datagrammi. Possono avere più interfacce e di conseguenza possiedono un indirizzo IP per ogni interfaccia. Si ha quindi rete “piena” di indirizzi IP e l’idea è quella di assegnare gli indirizzi IP con lo stesso prefisso alle interfacce sulla stessa rete IP. ARCHITETTURA TCP/IP Lo stack TCP/IP è logicamente situato al di sopra di qualsiasi altro protocollo di rete e garantisce l’indipendenza dalla tecnologia delle sottoreti - Non specifica i livelli 1 e 2, ma utilizza quelli conformi agli standard esistenti (ethernet, token ring, Wi-fi) che sono visti come una piattaforma per il trasferimento fisico - Se alcune funzioni non sono svolte da una particolare rete, TCP/IP le realizza (es: non sempre il livello LLC è implementato, dunque è necessario effettuare nuovi controlli sull’arrivo dei pacchetti e su eventuali errori); se sono già svolte, le duplica Per permettere l’interconnessione tra reti vi sono due approcci: - Traduzione di protocolli (es: interconnessione di LAN) - Incapsulamento Internet non prevede una “traduzione” dei protocolli nel passare da una rete all’altra, ma “incapsula” le unità informative dello strato IP, nelle unità dati dei protocolli delle reti che attraversa. Ogni livello riceve dati dal livello superiore e aggiunge un’intestazione (header) per creare una nuova entità dati e la passa al livello inferiore. Il frame ha anche un trailer finale LIVELLI ARCHITETTURA TCP/IP LIVELLO APPLICAZIONE Il livello applicazione comprende parte dello strato di sessione, presentazione e applicazione del modello ISO/OSI, qui si trovano protocolli come FTP, SMTP e HTTP, che gestiscono l'interazione tra programmi. I protagonisti sono: Processi: Sono programmi in esecuzione che si scambiano messaggi per comunicare tra loro. Paradigma Client-Server: o Server: Un processo sempre attivo che offre servizi. Il server accetta richieste, le elabora e invia i risultati al client. o Client: Un processo che si attiva quando richiede un servizio al server. Per scambiarsi messaggi, i processi usano i socket: canali di comunicazione che permettono a processi su macchine diverse di comunicare. Per individuare il processo destinatario, servono: L'indirizzo IP, che identifica il dispositivo. Il numero di porta, che specifica il processo all'interno di quel dispositivo (a livello TCP). LIVELLO TRASPORTO Il livello di trasporto corrisponde a parte dello strato di trasporto e dello strato di sessione del modello OSI. Si occupa di gestire il trasferimento dei dati tra mittente e destinatario in modo efficiente e organizzato. Tipi di Protocolli 1. TCP (Transmission Control Protocol): o Servizio orientato alla connessione: ▪ Prima del trasferimento dei dati, il mittente e il destinatario instaurano una connessione tramite un meccanismo chiamato handshaking. ▪ Garantisce un trasferimento di dati affidabile. o Flusso controllato: ▪ Il mittente evita di sovraccaricare il destinatario regolando il ritmo della trasmissione. 2. UDP (User Datagram Protocol): o Servizio senza connessione: ▪ Trasferisce dati senza instaurare una connessione tra mittente e destinatario. ▪ Utilizza datagrammi, quindi i segmenti di dati possono essere: ▪ Persi ▪ Conseguiti fuori ordine. o Vantaggi di UDP: ▪ Non richiede connessione, riducendo i ritardi. ▪ È semplice, poiché non mantiene uno stato di connessione. ▪ Non ha controllo di congestione, quindi può inviare dati rapidamente ("a raffica"). Identificazione delle Connessioni Ogni connessione è identificata da una coppia di socket: o Indirizzo IP: Identifica il dispositivo. o Numero di porta: Indica il processo specifico sul dispositivo. La porta è uno strumento che permette la multiplexazione delle connessioni, consentendo a un dispositivo di gestire più connessioni contemporaneamente. Numerazione delle Porte Il numero di porta è un valore di 16 bit (0-65535) e si divide in tre categorie: 1. Known Ports (0-1023): ▪ Assegnate da IANA per applicazioni standard. ▪ Esempi: SMTP (porta 25), HTTP (porta 80). 2. User Ports (1024-49151): ▪ Assegnate da IANA per processi utente. 3. Dynamic/Private Ports (49152-65535): ▪ Non assegnate. ▪ Usate per connessioni temporanee negoziate dinamicamente tra mittente e destinatario. LIVELLO RETE Consente l’interoperabilità delle varie reti grazie a funzionalità che nel modello OSI sono collocate in un sottostrato di rete. Il protocollo di strato è IP (Internet Protocol). Utilizza una modalità di trasferimento senza connessione con un servizio best-effort (cerca di “fare il suo meglio”) - ogni datagramma è un messaggio autonomo - nessuna instaurazione di connessione tra mittente e destinatario - la consegna ordinata e la banda non sono garantite Le funzioni principali sono (le vedremo dopo descritte meglio) - frammentazione e aggregazione delle PDU. - indirizzamento. - instradamento (Routing) e inoltro (forwarding). PROTOCOLLO IPv4 IP è un protocollo di livello tre che fornisce le seguenti funzionalità: - Definisce l’unità dati (datagramma) e ne specifica il formato - Definisce le modalità per la frammentazione e l’aggregazione dei datagrammi - Definisce lo schema di indirizzamento - Definisce il percorso di un datagramma verso la destinazione (instradamento/Routing) FORMATO DEL DATAGRAMMA Il datagramma IP è composto da un'intestazione (header) e dai dati (payload). L'intestazione include vari campi che specificano informazioni cruciali per la gestione del datagramma. 1. Versione (Vers - 4 bit) Indica la versione del protocollo IP in uso: 0100 corrisponde a IPv4. 2. Lunghezza dell’Intestazione (Hlen - 4 bit) Specifica la lunghezza dell’intestazione in parole da 4 byte: Minimo: 20 byte (valore 5). Massimo: 60 byte (valore 15). 3. Tipo di Servizio (Service Type - 8 bit) Indica la qualità del servizio richiesto per il datagramma, influenzando il trattamento che riceve in rete. Include: Precedence (3 bit): Importanza del datagramma. D (Delay): Minimizzare il ritardo. T (Throughput): Massimizzare la velocità. R (Reliability): Massimizzare l’affidabilità. C (Cost): Minimizzare il costo. Se un bit è impostato a 1, il parametro corrispondente viene considerato. 4. Lunghezza del Datagramma (Datagram Length - 16 bit) Specifica la lunghezza totale del datagramma in byte (incluso header e dati). Dimensione minima: 576 byte (tutti i dispositivi devono supportare questa lunghezza). 5. Identificazione (Identification - 16 bit) Un numero unico assegnato dal mittente al datagramma ed è copiato in tutti i frammenti del datagramma per consentire il riassemblaggio a destinazione. 6. Flag (Flags - 3 bit) Controllano la frammentazione del datagramma: X: Non utilizzato, sempre impostato a 0. DF (Don’t Fragment): Se impostato a 1, impedisce la frammentazione. MF (More Fragment): o 1: Indica che ci sono altri frammenti. o 0: Indica che è l’ultimo frammento. 7. Offset del Frammento (Fragment Offset - 13 bit) Indica la posizione del frammento rispetto al datagramma originale: Permette di numerare fino a 8192 frammenti (2¹³). 8. Time to Live (TTL - 8 bit) Indica il tempo massimo che il datagramma può rimanere in rete (misurato in salti o secondi): Decrementato di 1 ogni volta che attraversa un router. Se il valore raggiunge 0, il datagramma viene eliminato e il mittente riceve un messaggio ICMP. 9. Protocollo (Protocol - 8 bit) Identifica il protocollo di livello superiore che deve gestire i dati contenuti nel datagramma: 1: ICMP. 6: TCP. 10. Checksum dell’Intestazione (Header Checksum - 16 bit) Utilizzato per verificare l'integrità dell'intestazione: Calcolato sommando a 16 bit i valori dell'intestazione e memorizzando il complemento a 1. 11. Indirizzi di Sorgente e Destinazione (Source/Destination Address - 32 bit ciascuno) Source Address: Indirizzo IP del mittente. Destination Address: Indirizzo IP del destinatario. 12. Opzioni (Options - fino a 40 byte) Opzionali, utilizzate per funzioni avanzate: Source Route Option (SRO): Specifica gli indirizzi IP dei router da attraversare. Record Route Option (RRO): Crea una lista vuota in cui ogni router aggiunge il proprio indirizzo IP. Timestamp Option: Come RRO, ma ogni router aggiunge anche l’ora del passaggio. 13. Padding Riempie l’intestazione con zeri per assicurare che la sua lunghezza sia un multiplo di 32 bit. 14. Dati (Data/Payload) Contiene le informazioni da trasmettere. È la parte effettiva del messaggio inviata dal mittente al destinatario. Frammentazione e Aggregazione Quando un datagramma IP viene trasmesso, viene incapsulato in una trama di livello 2. Tuttavia, la trama di livello 2 ha una dimensione massima per il payload, nota come MTU (Maximum Transfer Unit), che esclude header e trailer. Se la dimensione del datagramma IP supera quella dell’MTU, il datagramma viene frammentato. La frammentazione è gestita dal livello IP del dispositivo che invia o inoltra il datagramma (host o router). Se il bit DF (Don’t Fragment) è impostato a 1, il datagramma non può essere frammentato e viene scartato. Ogni frammento generato può essere ulteriormente frammentato, se necessario, nel caso in cui incontri una rete con un’MTU ancora più piccola. I frammenti viaggiano in rete come entità indipendenti e possono seguire percorsi diversi per arrivare a destinazione. Saranno poi riassemblati dal destinatario per ricostruire il datagramma originale. L’aggregazione è effettuata invece dall’host di destinazione.  INSTRADAMENTO IP Il routing ha come obiettivo la determinazione del percorso ottimale, ossia una sequenza di router, che un pacchetto deve seguire per arrivare dalla sorgente alla destinazione. Una volta stabilito questo percorso, entra in gioco la commutazione o forwarding, che consiste nell'inoltrare i pacchetti lungo il percorso scelto. L'inoltro dei pacchetti da parte di un router si basa sulle informazioni contenute nelle tabelle di routing. Queste tabelle vengono costruite e aggiornate scambiando informazioni tra i router, utilizzando protocolli di routing specifici. È importante notare che un router non ha una visione completa del percorso che il pacchetto seguirà fino alla destinazione finale. Conosce solo il passo immediato successivo, noto come next hop, che indica il prossimo router a cui inoltrare il pacchetto. Nella tabella di routing sono presenti: - Net: indirizzo IP della rete di destinazione - Mask: maschera associata all’indirizzo di rete - Next_hop: indirizzo IP del router successivo verso la destinazione - Interface: identificatore della porta fisica del router verso il next hop - Metric: costo assegnato al cammino (es: numero di hop da attraversare, tempo di attraversamento, etc.) L’instradamento può essere - Statico/non adattativo Le tabelle sono definite manualmente dall’operatore Criteri fissi di instradamento Semplice ma poco flessibile e scalabile - Dinamico/adattativo Le tabelle sono calcolate automaticamente, in base alla tipologia della rete, allo stato del 30.0.0.7 traffico ed altre variabili. Permette un istradamento più efficiente grazie a criteri adattivi di instradamento Migliori prestazioni e maggiore controllo della congestione Tuttavia, per funzionare, i router devono scambiarsi continuamente informazioni sullo stato della rete. Questo genera un traffico addizionale, ma permette di ottimizzare le scelte di routing. Tutti i protocolli di Routing IP sono dinamici ed essi devono: - Determinare il percorso per raggiungere le reti non direttamente connesse - Acquisire automaticamente nuove informazioni di routing - Comunicare informazioni aggiornate agli altri router SISTEMI AUTONOMI Internet è organizzata come un insieme di Sistemi Autonomi (AS), ovvero porzioni di rete amministrate da un unico gestore, capaci di decidere quali informazioni di Routing accettare/inoltrare. - I router che instradano messaggi all’interno dell’AS sono detti interior router - I router che instradano messaggi tra AS diversi sono detti exterior router Gli AS sono identificati da un AS NUMBER assegnato da InterNIC, univoco a livello mondiale. Le informazioni di instradamento riguardanti i cammini all’interno di un AS sono gestite per mezzo di Interior Gateway Protocol (IGP). Le informazioni di instradamento riguardanti cammini che coinvolgono più AS sono gestite mediante Exterior Gateway Protocol (EGP). Tutti i nodi presenti all’interno dell’AS devono essere raggiungibili con percorsi interni. Per raggiungere un nodo esterno si dovrà passare attraverso i router “di confine” (border router). Ogni AS affida ad uno o più dei suoi router interni il compito di border router, con l’obiettivo di informare il mondo esterno della sua tipologia. PROTOCOLLI E ALGORITMI DI ROUTING L’obiettivo di un algoritmo di Routing è trovare il percorso a costo minimo su un grafo, che rappresenta la tipologia della rete - I nodi del grafo sono i router - I rami del grafo sono i collegamenti fisici Gli algoritmi per il calcolo del minimum spanning tree sono Dijkstra e Bellman-Ford: entrambi individuano il cammino a lunghezza minima tra un nodo sorgente e tutti gli altri nodi di un grafo procedendo in modo da aumentare progressivamente il numero di nodi (Dijkstra) o il numero di rami (Bellman-Ford). I due algoritmi convergono alla stessa soluzione  PROTOCOLLI IGP DISTANCE VECTOR Ogni router costruisce e aggiorna la propria tabella di routing sulla base dei Distance Vector (DV) ricevuti dai nodi adiacenti. Un DV è un insieme di coppie [destinazione-costo]. Processo di aggiornamento tabella di routing: 1. Ricezione di un DV da un router vicino: Il router confronta le informazioni ricevute con quelle già presenti nella propria tabella di routing (TR). 2. Confronto e Aggiornamento: o Se la destinazione non è presente nella tabella di routing (TR): ▪ Il router crea una nuova entry nella tabella, utilizzando le informazioni ricevute. o Se la destinazione è già presente nella tabella di routing (TR): ▪ Se il router che ha inviato il DV è già il next hop per quella destinazione: ▪ Aggiorna il costo nella tabella con il valore ricevuto. ▪ Se il router che ha inviato il DV non è il next hop corrente, ma il costo annunciato è inferiore a quello attuale: ▪ Aggiorna la entry nella tabella, modificando sia il costo che il next hop. 3. Trasmissione del Distance Vector Aggiornato: o Periodicamente, il router invia ai router vicini il proprio Distance Vector aggiornato. o Questo include tutte le coppie [Destinazione, Costo] attualmente presenti nella tabella di routing. LINK STATE Ogni router annuncia lo stato dei suoi collegamenti (link) adiacenti e i relativi costi inviando pacchetti chiamati Link State Advertisement (LSA) a tutti gli altri router della rete. Questi pacchetti contengono informazioni dettagliate sulla topologia locale del router, permettendo a tutti i dispositivi di avere una visione condivisa della rete. Le informazioni contenute nei LSA vengono raccolte e memorizzate da ogni router all'interno di un database, noto come Link-State Database. Questo database rappresenta una mappa completa della rete. LSA FLOODING I Link State Advertisement (LSA) vengono trasmessi in modalità flooding (inviati a tutti i nodi) attraverso tutti i link del router che li ha originati. Questo metodo garantisce una rapida diffusione delle informazioni e un aggiornamento tempestivo della rete, specialmente in caso di variazioni nella topologia. Quando un router riceve un LSA, lo inoltra agli altri router solo se il contenuto del messaggio ha portato a una modifica del suo Link-State Database (LS- database). Questo meccanismo evita il flooding inutile e riduce il traffico di controllo sulla rete. Un elemento critico del sistema è la necessità di mantenere i LS-database sincronizzati tra tutti i router. Se i router non condividono una visione coerente della rete, possono verificarsi problemi Alla ricezione di un LSA, un router compie le seguenti azioni - Se il LSA è inviato da un router non ancora noto o se il LSA è più recente dell’ultimo memorizzato, allora memorizza il nuovo LSA nel database e lo inoltra in flooding - Se il LSA è una replica di quello memorizzato, allora non viene fatto nulla - Se il LSA è più vecchio di quello memorizzato, allora il router ricevente trasmette il LSA aggiornato al router mittente Ogni router calcola localmente la sua TR applicando alla mappa della rete l’algoritmo di Dijkstra. ROUTING INFORMATION PROTOCOL (RIP) È un protocollo di routing IGP di tipo Distance Vector basato sull’algoritmo di Bellman-Ford distribuito. I router si scambiano ogni 30 secondi pacchetti RIP update che contengono i distance vector, le tabelle di routing sono aggiornate dinamicamente sulla base dei DV ricevuti e viene memorizzato un solo percorso (il migliore) (Link state invece può memorizzare, oltre al percorso migliore, anche un percorso alternativo nel caso il primo non fosse disponibile). La metrica è rappresentata dal numero di hop, ovvero il numero di router/reti intermedi da attraversare per raggiungere la destinazione. Si considerano al massimo 15 hop, superati i quali il percorso viene ritenuto irrealizzabile (problema del counting infinity); per questo RIP è usato per reti piccole. RIP aggiorna le TR in modo incrementale dopo aver ricevuto i DV dai vicini: - Se il DV contiene una nuova rete allora viene aggiunta quest’informazione nella TR - Se il DV contiene un cammino verso una rete già presente in TR ma con una metrica più piccola rispetto a quella memorizzata allora il nuovo cammino sostituisce quello memorizzato - Se il DV annuncia un cammino più lungo, la entry è aggiornata solo se il router che invia il DV è il next-hop nella TR Ogni entry nella TR contiene - Indirizzo IP della rete - Metrica - Next-hop router - Vari timer (si parla di entry soft state, cioè informazioni che non durano per sempre) In caso di guasto su un link o modifiche della tipologia il messaggio di RIP update viene trasmesso con un ritardo tra 1 e 5 s (per evitare collisioni) e si trasmettono solo le entry modificate. Se un router non riceve RIP update da un vicino per 180s, quest’ultimo viene dichiarato fuori servizio - I cammini attraverso il router vicino sono invalidati (si mette la distanza pari a 16, ovvero infinito) - se nel frattempo il router riceve da un altro vicino un update che offre un percorso valido verso una delle destinazioni precedentemente invalidate allora memorizza il nuovo percorso e azzera il timer per quella rotta, poiché ora c'è un percorso alternativo valido. - La cancellazione della entry avviene dopo ulteriori 120s tramite il garbage collector timer (si dà la possibilità ad altri router di essere informati della modifica) Gli update possono essere inviati in broadcast: si mandano le informazioni anche agli host non interessati e di conseguenza queste info vengono scartate. Questa tecnica si usa per evitare di trovare un percorso specifico verso un router destinatario. COUNTING TO INFINITY E SPLIT HORIZON Il counting to infinity si verifica quando i router aggiornano le loro TR in modo ciclico, causando un incremento continuo della metrica verso una destinazione non più raggiungibile, fino a raggiungere il valore di "infinito" (16). Soluzione  split horizon: il router non annuncia mai le route “a ritroso”, cioè al router vicino da cui le ha apprese.  Open Shortest Path First (OSPF) OSPF è un protocollo di routing interno (IGP, Interior Gateway Protocol) basato sul modello Link State e sull'algoritmo di Dijkstra. È stato progettato per superare le limitazioni del protocollo RIP e offre una serie di vantaggi significativi. Caratteristiche Principali di OSPF Convergenza più rapida: OSPF aggiorna le tabelle di routing in modo molto veloce rispetto a RIP, riducendo i tempi di adattamento ai cambiamenti di rete. Nessun limite di hop count: A differenza di RIP, OSPF può operare su grandi reti senza essere limitato dal numero massimo di salti (hop). Update incrementali: Invia solo gli aggiornamenti relativi ai cambiamenti nella rete, riducendo il traffico di controllo. Uso del multicast: Utilizza indirizzi multicast per comunicare con i router vicini, migliorando l'efficienza nella trasmissione dei messaggi. Maggiore complessità: Rispetto a RIP, OSPF richiede più risorse di CPU e memoria, poiché utilizza l'algoritmo di Dijkstra per calcolare i percorsi. Supporto per netmask: Permette l'uso di subnet e netmask variabili (VLSM), rendendolo più flessibile nella configurazione delle reti. Autenticazione dei messaggi: Include un sistema per verificare l'autenticità dei messaggi di routing, migliorando la sicurezza. Instradamento per Service Type (ToS): Può calcolare diverse tabelle di routing in base al tipo di servizio richiesto (es. priorità per il traffico voce). Bilanciamento del carico: Supporta il equal-cost multipath routing, ovvero la distribuzione del traffico su percorsi multipli di uguale costo. Questo consente di utilizzare meglio le risorse di rete e di evitare congestioni. Equal-Cost Multipath Routing Quando OSPF identifica più percorsi di costo uguale verso una destinazione, il traffico può essere suddiviso equamente tra questi percorsi. Questo approccio ottimizza l'utilizzo della rete e migliora la resilienza in caso di guasti di uno dei percorsi. Gli annunci sulla topologia della rete sono contenuti nei Link State Advertisement (LSA) che vengono diffusi usando la tecnica del selective flooding per raggiungere tutti gli altri router e dai LSA ricevuti, ogni nodo costruisce il suo database e usa localmente l’algoritmo di Dijkstra per calcolare i cammini minimi e costruire la sua tabella di routing. Alla ricezione di un LSA, un router Memorizza il LSA se non è già contenuto nel suo db e lo inoltra su tutte le interfacce tranne quella da cui ha ricevuto il LSA Se la rete annunciata dal LSA è già contenuta nella TR, allora Se l’informazione è meno recente, viene sostituita con la nuova e il LSA viene inviato su tutte le interfacce tranne quella di provenienza Se l’informazione memorizzata è più recente, il LSA con l’informazione più recente viene trasmesso in flooding Con il flooding si ha il vantaggio di inviare le informazioni a tutti i nodi ma si hanno problemi di scalabilità al crescere delle dimensioni di routing. La soluzione è introdurre una gerarchia di aree nel dominio di routing Il dominio di routing (che può coincidere con il sistema autonomo) è suddiviso in aree indipendenti, connesse da un’area di backbone Ogni area contiene un gruppo di reti contigue e di router I LSA si propagano in flooding all’interno di una singola area ma non tra aree. Le aree sono configurate manualmente e sono identificate da un area-id di 32 bit; la backbone area ha id = 0 (ci può essere una sola area 0) e deve essere connessa a tutte le altre aree. Aree e router nella gerarchia - Internal Router (IR): ha tutte le interfacce appartenenti ad una stessa area in quanto generano nella loro area i LSA che descrivono soltanto le reti della loro area e che si propagano a tutti i router della stessa area - Area Border Router (ABR): ha interfacce appartenenti ad area diverse; tutti gli ABR sono inclusi nell’area di backbone; essi propagano le informazioni di routing originate all’interno di un’area sull’area backbone e verso gli altri ABR che a loro volta le propagano all’interno delle loro aree. Ogni ABR diffonde in un’area il “riassunto” delle informazioni raccolte dalle altre aree su cui si affaccia - Backbone Router (BR): ha interfacce appartenenti alla backbone area, cioè ABR più i router connessi alle reti non appartenenti a nessuna area - Autonomous System Boundary Router (ASBR): scambia informazioni di routing con altri AS I PACCHETTI Il protocollo OSPF utilizza diversi tipi di pacchetti per gestire la comunicazione tra router, garantire la sincronizzazione delle informazioni e aggiornare la topologia della rete in modo affidabile. Pacchetti HELLO I pacchetti HELLO vengono inviati periodicamente su ogni interfaccia del router. E hanno 2 funzioni principali: o Scoprire i router vicini e identificare il costo dei collegamenti (link) con essi. o Gestire i meccanismi di elezione per selezionare un Designated Router (DR) e un Backup Designated Router (BDR) in reti multiaccesso. Pacchetti LSU (Link State Update) e LS-Ack (Link State Acknowledgment) LSU (Link State Update): Contengono le informazioni topologiche sotto forma di Link State Advertisement (LSA) e sono inviati nei seguenti casi: ▪ Quando cambia lo stato di un link. ▪ Periodicamente, allo scadere di un timer, anche in assenza di variazioni. LS-Ack (Link State Acknowledgment): o Confermano la ricezione degli LSU. o Contengono gli header dei LSA ricevuti per evitare duplicazioni e garantire un aggiornamento affidabile. Pacchetti LSR (Link State Request) e DD (Database Description) Questi pacchetti vengono utilizzati per sincronizzare i database di link-state (LS-database) tra router adiacenti. 1. Database Description (DD): o Dopo che due router si sono identificati come vicini tramite i pacchetti HELLO, sincronizzano i propri database tramite un processo di Master-Slave: ▪ Il router master avvia il processo. ▪ Il router slave risponde seguendo le istruzioni del master. o I pacchetti DD contengono un elenco di LSA presenti nel database del router (solo l’header, non i dettagli completi). 2. Database Download con LSR e LSU: o Se un router si accorge, tramite i pacchetti DD, che mancano alcuni LSA nel proprio database, richiede i dati mancanti inviando un Link State Request (LSR). Questo pacchetto contiene gli header degli LSA richiesti. o In risposta, il router adiacente invia un LSU con i dati richiesti. o Per ogni LSU ricevuto, il router adiacente invia un LS-Ack per confermare la ricezione. PROPAGAZIONE DI LSA SU LAN Ogni LSA inviato su una LAN deve essere ricevuto da tutti i router collegati a quella LAN. Vi è però il problema di gestire ACK multipli ed eventuali ritrasmissioni. La soluzione consiste nel delegare un solo router, cioè il Designated Router (DR) che deve distribuire i LSA e ricevere gli ACK. Nel caso di malfunzionamento del DR si avrebbe la perdita di informazioni; si elegge dunque un Backup Designated Router (B-DR) che ascolta i messaggi diretti al DR e memorizza le stesse informazioni. DR e B-DR sono annunciati nei pacchetti di HELLO. Gli LSU vengono inviati in Multicast dai router all'indirizzo specifico riservato al (DR) e al (B-DR). Questo consente di ridurre il numero di pacchetti trasmessi sulla rete. Il DR riceve gli LSA dagli altri router e li re-inoltra a un altro indirizzo multicast, riservato a tutti i router OSPF presenti sulla LAN. In questo modo, tutti i router aggiornano la loro visione della rete. Ogni router, dopo aver ricevuto un LSU, invia un messaggio di acknowledgment (ACK) all'indirizzo multicast riservato al DR e al B-DR. Questo conferma la corretta ricezione del messaggio. Se il DR non riceve una conferma (ACK) da un router, esegue una ritrasmissione selettiva degli LSA mancanti solo verso quel router. Questo evita di ritrasmettere inutilmente i dati a tutta la rete. Questo processo ottimizza la propagazione degli LSA nelle reti LAN, riducendo il traffico superfluo e garantendo che tutti i router ricevano le informazioni necessarie in modo affidabile. TIPI DI LSA (CHILL) LSA di tipo 1: Router Link Advertisement Generato da ogni router nell’area a cui appartiene Contiene informazioni sullo stato dei link/reti di ogni router nell’area Propagato in flooding solo nell’area in cui è generato LSA di tipo 2: Network Link Advertisement Generato dal DR su una rete multi-accesso (es: LAN) Contiene il set di router su quella rete Propagato in flooding solo nell’area in cui è generato LSA di tipo 3: Network Summary Link Advertisement Generato da un ABR e propagato sull’area backbone Descrizione riassuntiva di un’area a cui appartiene l’ABR LSA di tipo 4: ASBR Summary Link Advertisement Generato da un ABR e propagato sull’area backbone Descrizione della route verso l’ASBR LSA di tipo 5: AS external Link Advertisement Descrive il percorso verso una destinazione esterna al AS Generato da un ASBR Propagato in tutto il dominio di routing OSPF TRADUZIONE DEGLI INDIRIZZI IN INTERNET ADDRES RESOLUTION PROTOCOL (ARP) Lo strato collegamento non riconosce gli indirizzi IP  servono indirizzi di livello 2 (indirizzi MAC = indirizzi fisici). Gli indirizzi MAC si compongono di 2 parti di 3 byte ciascuna - 3 byte identificano il lotto di indirizzi acquistato dal costruttore della scheda - 3 byte sono un numero progressivo deciso dal costruttore Il mapping tra indirizzo IP e indirizzo fisico può essere - Statico: una tabella di associazione indirizzo IP-indirizzo fisico viene predisposta staticamente su ogni host connesso alla rete (necessario quindi un aggiornamento manuale) - Dinamico: la tabella di associazione viene costruita dinamicamente attraverso il protocollo ARP che associa un indirizzo locale ad un indirizzo IP; invece, RARP associa un indirizzo IP a un host locale Vi sono due tipi di servizi ARP: RP-Server usato per le reti punto-punto Broadcast ARP (invio richiesta in broadcast/ risposta in unicast) ARP fa uso di una cache che contiene le corrispondenze già risolte tra indirizzo IP e indirizzo fisico: se la corrispondenza non è presenta nella cache, invia un messaggio ARP request in broadcast. L’host aggiorna la cache quando riceve una trama di ARP reply. Il contenuto della cache ha un tempo di vita limitato (20 minuti) altrimenti si avrebbe una situazione statica, i dati diventano inconsistenti senza notifica. Il GRATUITOUS ARP è una richiesta ARP speciale che un dispositivo invia per verificare o annunciare informazioni relative al proprio indirizzo IP e MAC. Serve a: Verificare conflitti di indirizzi IP: Il dispositivo controlla se un altro host nella rete locale utilizza lo stesso indirizzo IP. Aggiornare gli altri host sulla rete: Informa gli altri dispositivi di un cambiamento del proprio indirizzo MAC, ad esempio dopo la sostituzione di una scheda di rete. In pratica, è usato per mantenere la coerenza degli indirizzi IP e MAC nella rete locale. Il Proxy ARP viene utilizzato quando l'host di destinazione (ad esempio, G) si trova su una rete diversa rispetto all'host o al router che invoca il modulo ARP (ad esempio, A). In questo scenario, i router non possono inoltrare trame broadcast di livello 2, e il Proxy ARP consente di gestire la comunicazione. (VEDERE FOTO GIU) 1. Invio della Richiesta ARP: o L'host A invia una richiesta ARP per trovare l'indirizzo fisico corrispondente all'indirizzo IP dell'host G, che si trova su un'altra rete. 2. Intercettazione da Parte del Router: o Il router R, che collega le due reti, intercetta la richiesta ARP. o Per "simulare" la presenza dell'host G, il router invia una risposta ARP ad A, fornendo il proprio indirizzo fisico (MAC address). 3. Inoltro del Datagramma: o L'host A, credendo che il router R sia il destinatario, invia il datagramma al router. o Il router, una volta ricevuto il datagramma, lo inoltra all'host G utilizzando una richiesta ARP, se necessario, per determinare il binding IP-MAC di G. “to ff:ff:ff:ff:ff:ff” rappresenta il broadcast (tutti 1) RARP (REVERSE ARP) E DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) Vi sono 3 modi per ottenere un indirizzo IP - Assegnazione manuale - Protocolli automatici (RARP e DHCP) - Messaggi ICMP RARP viene usato - All’accensione dei sistemi che non ricordano il proprio indirizzo IP, ma conoscono l’indirizzo fisico della loro interfaccia di rete - Dai sistemi privi di disco rigido che non ricordano il loro indirizzo IP - Dai sistemi a cui non è stato assegnato un indirizzo IP Il RARP (Reverse ARP) consente a un host di ottenere il proprio indirizzo IP partendo dall’indirizzo MAC. L’host invia una richiesta RARP Request in broadcast a livello 2, che non viene inoltrata dai router. Per questo, deve essere presente un RARP server su ogni sottorete. Il server utilizza un file di configurazione per mappare gli indirizzi MAC agli indirizzi IP e risponde all’host con un messaggio unicast contenente l’indirizzo IP. DHCP è utile quando - Gli host si connettono e disconnettono frequentemente - Il numero di host supera il numero di indirizzi disponibili nella rete - Si vuole rendere automatica l’assegnazione degli indirizzi IP DHCP utilizza un processo in 4 fasi per configurare un client 1) Quando un client viene inizializzato, richiede il lease (affitto) di un indirizzo IP trasmettendo una richiesta broadcast a tutti in server DHCP in un messaggio DHCP DISCOVER (contiene l’indirizzo MAC del client). Non avendo ancora un indirizzo IP e non conoscendo l’indirizzo IP di un server DHCP, il client utilizza 0.0.0.0 come indirizzo IP di origine e 255.255.255.255 come indirizzo IP di destinazione (Se il client non riceve offerte, ritrasmetterà la richiesta per 3 volte, poi ogni 5 minuti) 2) Tutti i server DHCP che ricevono la richiesta e dispongono di un indirizzo IP da assegnare al client inviano in broadcast un’offerta tramite messaggio DHCP OFFER che include le seguenti informazioni a. Indirizzo MAC del client che ha fatto la richiesta b. Indirizzo IP offerto c. Subnet mask corrispondente all’indirizzo IP d. Durata del lease e. Indirizzi IP del server che ha inviato l’offerta 3) Dopo aver ricevuto un’offerta da almeno un server DHCP, il client seleziona l’indirizzo IP dalle offerte ricevute e comunica il broadcast l’accettazione dell’offerta con un messaggio DHCP REQUEST che contiene l’indirizzo IP del server di cui è stata accettata l’offerta 4) Il server DHCP di cui è stata accettata l’offerta invia al client in broadcast un riconoscimento di operazione riuscita con un messaggio DHCP ACK. Se l’indirizzo IP richiesto non è più disponibile, viene inviato in broadcast un riconoscimento di operazione non riuscita mediante il messaggio DHCP NACK. (Se non riceve né ACK né NACK prova a ritrasmettere una nuova REQUEST con un algoritmo di backoff esponenziale) Altri possibili messaggi - DHCP RELEASE: inviato dal client per rilasciare il lease dell’indirizzo IP - DHCP DECLINE: Inviato dal client al server per indicare che l’indirizzo IP assegnato è già in uso (scoperto tramite ARP per es.) e riparte con il processo di configurazione - DHCP INFORM - Inviato dal client al server per chiedere solo parametri di configurazione locale; il client ha già un indirizzo IP configurato dall’esterno Tutti i client DHCP provano a rinnovare il proprio lease una volta trascorso il 50% del periodo di lease tramite un messaggio DHCP REQUEST inviato direttamente al server DHCP da cui ha ottenuto il lease. - Se il server DHCP rinnova il lease invierà al client un messaggio DHCP ACK con il nuovo periodo di lease ed eventuali aggiornamenti dei parametri di configurazione - Se il client non riesce a rinnovare il lease allo scadere del 50% della sua durata, cerca di contattare qualsiasi server DHCP disponibile una volta trascorso l’87,5% del periodo di lease inviando un messaggio DHCP REQUEST in broadcast Domain Name System (DNS) Il DNS è un sistema distribuito che funge da database e protocollo, permettendo la traduzione di nomi di dominio (hostname) come dimes.unical.it in indirizzi IP e viceversa. Questa traduzione è essenziale per consentire la comunicazione tra host, router e server DNS. 1. Formato dei Nomi: o I nomi di dominio sono stringhe ASCII composte da etichette separate da punti (.), con una lunghezza massima di 63 caratteri per etichetta e 255 caratteri totali. o Tipicamente, la corrispondenza tra nome e indirizzo IP è biunivoca, ma ci sono eccezioni: ▪ Un indirizzo IP può essere associato a più nomi (alias). Ad esempio, cnn.com e www.cnn.com. ▪ Un nome può essere associato a più indirizzi IP (ad esempio, per bilanciare il carico su server replicati). 2. Struttura Gerarchica: o Lo spazio dei nomi è organizzato in una struttura ad albero. Ogni nodo rappresenta un’etichetta e il nome completo si ottiene risalendo dall’etichetta del nodo fino alla radice dell’albero. 3. Risoluzione dei Nomi: o Il DNS segue un modello client-server basato su UDP (porta 53). o Il client, chiamato resolver, è implementato nel sistema operativo dell’host. o Il server, chiamato name server, gestisce le richieste DNS. Il DNS utilizza una gerarchia di server che cooperano per rispondere alle richieste: 1. Server DNS Radice: o Sono i server che rappresentano il livello più alto della gerarchia DNS. o Quando un server DNS locale non può tradurre un nome, contatta un server radice, che a sua volta può indirizzare verso il server responsabile. o Esistono solo 13 server radice nel mondo. 2. Server TLD (Top-Level Domain): o Gestiscono domini di alto livello come.com,.org,.net, e quelli geografici come.it,.uk,.fr.  3. Server di Competenza: o Contengono i record definitivi per un dominio specifico e sono responsabili della risoluzione dei nomi all’interno di quel dominio. 4. Server DNS Locale: o Opera come intermediario (proxy) tra gli host e la gerarchia DNS. o Quando un host effettua una richiesta DNS, questa viene inviata al server DNS locale, che si occupa di ottenere una risposta. Lo spazio dei nomi DNS è suddiviso in zone di autorità, ciascuna gestita da un name server responsabile della risoluzione dei nomi nella propria zona. Per garantire affidabilità e sicurezza, le informazioni relative a una zona possono essere replicate su più name server, che devono trovarsi su macchine diverse e con alimentazione indipendente. L’albero dei name server ha tipicamente meno livelli rispetto all’albero dei nomi. Questo perché un singolo name server può gestire più sub-domini, riducendo la complessità dell’organizzazione dei server. ESEMPIO: l’host cis.poly.edu vuole l’indirizzo IP di gaia.cs.umass.edu. Si possono seguire 2 approcci: - query iterativa o il server contattato risponde con il nome del server da contattare o Questo approccio può essere più efficiente in termini di risorse di rete, poiché il server DNS non è responsabile di gestire tutte le fasi di risoluzione della query - Query ricorsiva o affida il compito di tradurre il nome al server DNS contattato o questo approccio offre un’esperienza più semplice per il client che delega la risoluzione della query al server DNS o trae vantaggio del caching Una volta che un server DNS impara la mappatura, la mette nella cache: - le informazioni nella cache vengono invalidate dopo un certo periodo di tempo - tipicamente un server DNS locale memorizza nella cache gli indirizzi IP dei server TLD  STATO TRASPORTO Lo strato di trasporto fornisce la comunicazione logica tra processi e ciò può avvenire attraverso 2 protocolli (TCP e UDP). Una funzione comune a TCP e UDP è il multiplexing/demultiplexing - Multiplexing nell’host mittente: raccoglie dati da diversi processi e li incapsula con gli header - Demultiplexing nell’host ricevente: consegna i segmenti ricevuti ai rispettivi processi User Datagram Protocol (UDP) UDP è il protocollo di trasporto più semplice in quanto è senza connessione: - Non c’è handshaking tra mittente e destinatario - Ogni segmento UDP è gestito indipendentemente dagli altri. Ciò vuol dire che possono essere perduti o consegnati fuori sequenza. - Non vi è controllo di flusso e di congestione, quindi possibile saturazione del ricevitore - Non vi è controllo di errore (si può implementare un opzionale controllo tramite checksum) Perché allora si utilizza UDP? - semplice: nessuna connessione tra mittente e destinatario - non vi è controllo di congestione, quindi UDP può “sparare” dati a raffica - è usato per il supporto di transazioni semplici in cui le applicazioni mettono tutti i dati in un solo pacchetto - è adatto per le applicazioni Real-Time - supporta le trasmissioni multicast Ogni volta che un processo invia dati allo strato UDP, produce esattamente un solo datagramma UDP che viene incapsulato in un solo datagramma IP. Il datagramma UDP viene indicato con il campo “Protocol = 17” nell’header IP. - Source port e destination port: identificano i processi sorgente e destinazione dei dati - UDP lenght: lunghezza totale del datagramma (in byte), compreso l’header UDP - Checksum (opzionale) Trasport Control Protocol (TCP) TCP è un protocollo “con connessione”, cioè mittente e destinatario stabiliscono una connessione prima di scambiare dati. Ciò vuol dire che TCP gestisce connessioni punto-punto full-duplex (i flussi nelle due direzioni sono indipendenti). Il socket TCP è identificato dalla quadrupla:. TCP effettua operazioni di - Segmentation & reassembly - Controllo e recupero di errore - Riordinamento delle unità informative - Controllo di flusso - Controllo di congestione Segmentation & Reassembly Il TCP converte un flusso continuo di byte in una serie di unità distinte, dette segmenti. Ogni segmento TCP è incapsulato in un pacchetto IP e la segmentazione è a totale carico del TCP. La lunghezza massima di un del campo dati di un segmento (MSS – Maximum Segment Size) viene negoziata all’apertura della connessione. Essa dipende da - La dimensione del buffer delle entità TCP - Dalla MTU delle sottoreti a cui sono connessi gli end-system Per quanto riguarda la reassembly, TCP è un protocollo “byte oriented” - Si numerano i byte e non i segmenti - Ogni byte è identificato da un numero di sequenza di 32 bit - L’identificativo di un segmento è il numero di sequenza del primo byte contenuto nel campo dati - Nei messaggi di ACK è indicato il numero di sequenza del byte successivo atteso dal ricevitore ----------------------------------------------------------------------------------------------------------------------------- ------------------------------ - Il TCP sender utilizza un buffer per immagazzinare i byte finché costruisce un segmento - Il TCP receiver raccoglie i byte in un buffer prima di mandarli all’applicazione come un flusso continuo di byte Segmento TCP - Source port e destination port: identificano i processi sorgente e destinazione dei dati - Sequence Number: contiene il numero di sequenza del primo byte di Data - Acknowledgement Number: nei segmenti in cui il flag ACK=1, contiene il numero di sequenza del byte successivo che il ricevitore si aspetta di ricevere - Header lenght - Reserved: riservato per usi futuri (tutti 0) - Window: comunicata dal TCP ricevente al TCP mittente, contiene il numero di byte che il TCP ricevente è disposto a ricevere - Urgent Pointer: contiene il numero di sequenza dell’ultimo byte di dati che devono essere consegnati con urgenza al processo ricevente - Control bit: o SYN: Segnala l'inizio della connessione (utilizzato nel 3-way handshake, vale 1 solo nel primo segmento inviato). o FIN: Indica la fine della trasmissione. o RST: Resetta la connessione in caso di malfunzionamento. o ACK: Conferma che il campo "Acknowledgement Number" contiene un valore valido. o PSH: Forza l'invio immediato dei dati al ricevente, bypassando i buffer (es. sessioni Telnet). o URG: Segnala dati urgenti da elaborare immediatamente (es. interruzione in una sessione Telnet). - Checksum - Options (es: negoziazione dell’MSS) - Padding: contiene degli zeri per far sì che l’header abbia una lunghezza multipla di 32 bit Gestione della connessione TCP Abbiamo detto che TCP è un protocollo orientato alla connessione, cioè mittente e destinatario si sincronizzano attraverso il meccanismo 3-way handshake: tale sincronizzazione serve a scambiarsi i numeri di sequenza iniziali dei segmenti scambiati su quella connessione. Al set-up, gli host scelgono un numero di sequenza iniziale (ISN) di 32 bit, ponendolo uguale al valore del clock locale (ISN è scelto in modo pseudo-casuale tra 1 e 232). È necessario che, quando i numeri di sequenza si ripetono, i vecchi segmenti con lo stesso numero di sequenza siano scomparsi dalla rete: si pone un limite al tempo di permanenza in rete di un segmento, Maximum Segment Lifetime (MSL) che deve essere minore del tempo di ciclo del clock. INSTAURAZIONE DI UNA CONNESSIONE 1-2: Lato server, il TCP viene attivato mediante una primitiva PASSIVE_OPEN che serve a predisporre il server alla ricezione di richieste di connessione invece lato client quando si vuole aprire una connessione deve essere passata al TCP locale una primitiva di ACTIVE_OPEN che contiene il socket di destinazione. 3: La prima trama inviata dal TCP client è una trama di SYN (synchronize) caratterizzata dal bit SYN=1. Il numero di sequenza contenuto nel campo SN è il numero iniziale ISN scelto dal TCP del client per la nuova connessione. 4: In risposta, il TCP del server invia una trama di SYN-ACK con i bit di SYN e ACK posti a 1. ISN contiene il numero di sequenza iniziale scelto dal TCP del server per la nuova connessione. Il campo ACK Number contiene il riscontro della corretta ricezione della trama precedente (valore di ISN ricevuto più 1). 5: L’apertura della connessione viene completata con l’invio di un segmento di ACK vuoto contenente il riscontro del TCP client della corretta ricezione della trama di SYN-ACK, con il numero di sequenza riscontrato pari al numero di sequenza in trasmissione dell’host destinatario + 1 6,8: Il TCP sender comincia a trasmettere dati, dopo aver inviato la primitiva di Connection Opened al livello applicativo. Si noti che il SN dei messaggi 5 e 8 è lo stesso perché l’invio degli ACK non contribuisce ad incrementare il valore di SN! 7,9: L’host destinatario comincia a trasmettere solo dopo aver ricevuto l’ultimo terzo segmento (ACK) e aver inviato al proprio livello applicativo la primitiva di Connection Opened RILASCIO DI UNA CONNESSIONE Il processo di rilascio di una connessione è analogo a quello di instaurazione. Una connessione TCP è bi-direzionale e può essere vista come due flussi di dati indipendenti per ciascuna direzione, nel rilascio le 2 vie possono essere chiuse indipendentemente: quando un programma applicativo non ha più dati da trasmettere ordina al TCP corrispondente di chiudere la connessione “in una direzione”. Il TCP finisce di trasmettere gli eventuali dati rimasti nel buffer e ne aspetta il riscontro; quindi, invia un messaggio di FIN (bit di FIN settato a 1) al TCP ricevente. Il TCP ricevente invia un messaggio ACK al TCP trasmittente e avvisa il suo livello applicativo che non ha più dati da trasferirgli. Intanto i dati possono continuare a fluire nella direzione ancora aperta della connessione; i riscontri devono continuare a essere inviati dal TCP che aveva chiesto la chiusura della connessione. Questo finché anche l’altra direzione della connessione verrà chiusa. Normalmente per il rilascio di una connessione servono 4 segmenti: 2 FIN e 2 ACK, però può succedere che il primo ACK e il secondo FIN siano contenuti nello stesso segmento. Il rilascio di una connessione è più complesso della sua instaurazione (da un punto di vista del tempo impiegato); il meccanismo usato non garantisce la corretta chiusura e per questo il TCP rimedia con dei timeout (2 MSL) - Se il pacchetto di FIN non è seguito da un ACK, dopo un timeout la connessione full duplex viene chiusa - L’altra parte può non accorgersi della chiusura immediatamente ma prima o poi si renderà conto che nessuno risponde e a sua volta chiuderà Reset di una connessione Se una connessione non può essere chiusa secondo la procedura normale a causa di situazioni anomale, o se un programma applicativo è forzato a chiudere immediatamente una connessione, TCP prevede una procedura di reset che consiste nell’inviare un segmento con il bit RST=1. Alla ricezione di tale segmento la connessione è immediatamente terminata senza scambio di ulteriori messaggi e il TCP ne informa i programmi applicativi. Controllo errore di TCP Il controllo di errore è necessario per risolvere potenziali situazioni di errore: ciò è dovuto al fatto che IP non è affidabile, i datagrammi possono essere persi, ritardati, duplicati o consegnati fuori sequenza. Ogni segmento contiene una checksum che il ricevitore usa per verificare l’integrità dei dati: se il segmento è corretto viene inviato un ACK altrimenti viene scartato. Il meccanismo di recupero da errore del TCP è basato sul RTO (retransmission timeout): la ritrasmissione è innescata dalla mancata ricezione degli ACK entro il tempo limite RTO. Può essere successo che - Il segmento non è arrivato a destinazione - Il segmento è arrivato a destinazione ma con checksum errata - Il segmento è arrivato con checksum corretta ma l’ACK trasmesso non viene ricevuto La dimensione del RTO è un aspetto critico per le prestazioni del TCP - valore è troppo piccolo  i segmenti in ritardo potrebbero essere considerati persi - valore è troppo grande  la risposta ad un evento di perdita sarebbe troppo lenta con conseguente perdita di efficienza e minore velocità di trasferimento RTO è fissato dal TCP sender in base ai valori misurati del RTT (round-trip time), ovvero il tempo dopo l’invio di un segmento fino alla ricezione dell’ACK (RTT = tempo di trasferimento in un verso + tempo di trasferimento nell’altro verso + tempo di risposta del destinatario (trascurabile)). Quindi RTO > RTT. TCP utilizza una media pesata dei campioni di RTT (Round Trip Time) per stimare il SRTT (Smoothed Round Trip Estimate), calcolato con la formula: Dove α\alpha è il fattore di smussamento, solitamente compreso tra 0,1 e 0,2. Questo metodo permette di bilanciare stabilità e reattività della stima. Tuttavia, il calcolo dell'RTO (Retransmission Timeout) presenta due problemi: 1. Ambiguità nella misura del RTT durante le ritrasmissioni (risolto dall'algoritmo di Karn). 2. Assunzione errata che la varianza dei valori di RTT sia costante e piccola (risolto da Jacobson). ALGORITMO DI KARN I campioni di RTT (Round Trip Time) relativi ai segmenti ritrasmessi non vengono utilizzati per calcolare il nuovo RTT, per evitare ambiguità. Ad ogni ritrasmissione il valore di RTO (Retrasmission Timeout) relativo a segmenti ritrasmessi si calcola con una procedura di backoff esponenziale: ogni volta che si ritrasmette un segmento, il TCP sender moltiplica l’ultimo valore di RTO per un fattore q (solitamente 2) Appena arriva un ACK relativo a un segmento che non è stato ritrasmesso si riattiva l’algoritmo classico di Jacobson per il calcolo di RTO. Dopo sei ritrasmissioni consecutive senza ricevere un ACK, la connessione viene considerata fallita e resettata. ALGORITMO DI JACOBSON Il calcolo di RTO non tiene conto della varianza del ritardo TCP: CONTROLLO DI FLUSSO Effettuare un controllo di flusso significa fare in modo che il trasmettitore non sovraccarichi il buffer del ricevitore trasmettendo troppi dati o troppo velocemente. Il controllo di flusso nel TCP è basato sul meccanismo della sliding window, tramite il quale il ricevitore informa il trasmettitore dello spazio libero nel buffer. - La finestra in trasmissione specifica i byte che possono essere inviati, mentre il trasmettitore è in attesa dei riscontri dei byte già trasmessi - La finestra in ricezione indica lo spazio disponibile per ricevere e memorizzare nuovi dati che possono essere anche ricevuti fuori sequenza Solitamente la dimensione della finestra - è pari a n*MSS (Maximum Segment Size), dove n è un numero intero che serve per evitare che il TCP trasmittente esegua una segmentazione poco efficiente - varia dinamicamente durante la connessione - quella del trasmettitore si adatta a quella del ricevitore (in assenza di controllo di congestione coincidono) Se il mittente rimane bloccato si verifica deadlock. Si usa quindi un persist timer - Quando window = 0, il sender fa partire un timer (default 500 ms) - Allo scadere del timer, se non è stato ricevuto nessun segmento, il sender invia un segmento di 1 byte, detto “probe”, per sollecitare il ricevitore a riannunciare nell’ACK la dimensione della finestra - Il timer raddoppia ogni volta che non riceve risposta fino ad un massimo di 60s SINDROME DELLA SILLY WINDOW Nelle prime implementazioni del TCP si verificava che l’applicazione sorgente passava i dati al TCP a blocchi di grandi dimensioni, mentre l’applicazione ricevente riceveva i byte lentamente. Il ricevitore vedeva ogni volta svuotarsi di pochi byte il buffer e sollecitava col campo Window la trasmissione di segmenti di pochi byte. Molti segmenti con pochi byte portano ad uno spreco di risorse a causa dell’elevato overhead! Per risolvere il problema si sono introdotti i seguenti meccanismi: - Lato ricevitore: prima di annunciare un aggiornamento del valore di “window”, il ricevitore deve aspettare di avere a disposizione almeno 1 MSS o uno spazio pari alla metà della finestra di ricezione - Lato trasmettitore: deve creare segmenti non più piccoli di ½MSS (tranne se è sollecitato tramite flag PUSH o URGENT) CALCOLO SEMPLIFICATO DEL THROUGHPUT TCP Il throughput TCP può essere calcolato facendo alcune assunzioni semplificative: - Il percorso tra trasmettitore e ricevitore è semplificato come un canale punto-punto - La dimensione della finestra del ricevitore è costante - Il ricevitore invia un ACK ad ogni segmento - No errori, no ritrasmissioni Il throughput S si calcola confrontando il Tciclo con il Tw - Tciclo è il tempo necessario a ricevere l’ACK di un segmento trasmesso ed è dato da: dove (Ts = Tempo Trasmissione Segmento) - Tw è il tempo per inviare tutti i segmenti nella finestra del trasmettitore ed è dato da: dove (W=dimensione finestra) e (R=Capacità canale) Quindi - Se Tw > Tciclo  il riscontro (ACK) arriva prima che la finestra si chiuda e il throughput è massimo (S=R) - Se Tw < Tciclo  il sender si ferma in attesa del riscontro e in questo caso, il throughput si riduce ed è calcolato come: S = W / Tciclo CONTROLLO DI CONGESTIONE La congestione si verifica quando troppe sorgenti inviano dati troppo velocemente perché la rete riesca a gestirli. Ciò porta a: - Pacchetti persi per overflow dei buffer dei router - Ritardi lunghi per accodamento nei buffer dei router Il livello IP non possiede meccanismi per rilevare e controllare la congestione. L’idea è quindi quella di dedurre la congestione dal TCP negli end-system in base a perdite e ritardi che vengono costantemente monitorati dalle entità TCP. Il TCP ha funzione auto-sincronizzante (self-clocking): il sender usa gli ACK come clock per l’invio di nuovi segmenti - L’invio di nuovi segmenti in rete è determinato dalla ricezione degli ACK dei segmenti già trasmessi - L’invio degli ACK è regolato dalla velocità del link più lento sul percorso sorgente-destinazione (se il bottleneck è nella rete) o dalla velocità del ricevitore (se il bottleneck è nel ricevitore) Idea: lo scadere del time-out di ritrasmissione è considerato un sintomo di congestione. Sono stati ideati quattro meccanismi per migliorare le prestazioni del TCP in caso di congestione operando sulla dimensione della finestra del TCP. SLOW START Previene la congestione durante la fase di avvio di una connessione TCP in quanto espande gradualmente la finestra del TCP trasmettitore regolando l’emissione dei segmenti fino a raggiungere il ritmo di emissione di regime. Si introduce una nuova variabile per il trasmettitore, la Congestion Window (CWND), misurata in segmenti che aumenta progressivamente con la ricezione degli ACK. L’ampiezza della finestra del trasmettitore in segmenti = SW = min [RW, CWND]. RW = Recived Windows Per ogni ACK, CQND aumenta in modo esponenziale fino al valore massimo, ovvero la finestra di ricezione RW. CONGESTION AVOIDANCE Regola l’ampiezza della finestra in caso di congestione già rilevata, cioè allo scadere di un time-out. La finestra è regolata in base a un meccanismo di AIMD (additive increase multiple decrease) - Additive increase: la finestra aumenta di 1 MSS dopo ogni RTT - Multiple decrease: la finestra si dimezza ad ogni time-out Il TCP usa i meccanismi di SLOW START e CONGESTION AVOIDANCE insieme - Allo scadere di un time-out, il TCP sender inizializza un valore di soglia SS_Thresh alla metà del valore corrente di CWND - All’arrivo dei riscontri, cwnd cresce esponenzialmente (SLOW START) fino al valore di SS_Tresh - Poi cresce linearmente (CONGESTION AVOIDANCE) FAST RETRANSMIT Nel caso di ricezione di un segmento fuori sequenza, il TCP receiver invia un ACK duplicato, in cui riscontra l’ultimo segmento ricevuto correttamente in sequenza. Il TCP sender può interpretare l’ACK duplicato come segnale che il segmento che segue l’ultimo segmento riscontrato è stato ritardato e arriverà fuori sequenza o si è perso. Il Fast Retransmit fornisce al sender uno strumento per decidere se quel segmento è perso o soltanto ritardato. Jacobson suggerì che: - La ricezione di 3 ACK duplicati per lo stesso segmento è sintomo che il segmento successivo è perso - Quindi conviene ritrasmetterlo senza aspettare la scadenza del time-out Algoritmo - Alla ricezione di un segmento fuori sequenza, il TCP ricevente emette immediatamente un ACK per l’ultimo segmento ricevuto in ordine - Continua a ripetere l’ultimo ACK per ogni segmento successivo correttamente ricevuto finché non riceve il segmento (ritrasmesso) fuori sequenza - Quindi genera un ACK cumulativo per tutti i segmenti ricevuti in ordine nel frattempo FAST RECOVERY Jacobson propose il Fast Recovery da associare al Fast Retransmit per accelerare il recupero dopo una mancata ricezione. Idea: l’arrivo di ACK duplicati assicura che i segmenti successivi sono ricevuti regolarmente; quindi, la procedura di recupero basata su SS+CA potrebbe essere troppo conservativa. - Con Fast Retransmit, i tre ACK duplicati vengono trattati come sintomo di congestione, quindi con il classico meccanismo di SS+CA - Fast Recovery evita la fase di Slow Start!