8.3 KiB
Piano di controllo in Internet
(vedi slides per timeline)
Note storiche
Routing
Intra-domain
Il routing intra domain era necessario tra gli anni 80 e 90 a causa della forte gerarchizzazione di domini separati, mentre l'inter domain non era ancora necessario.
ARPAnet V1 utilizzava un algoritmo distance vector distribuito (bellman-ford). Questo algoritmo e' asincrono, ma ha vari limiti:
- approccio iterativo: convergenza lenta, tabelle inconsistenti e oscillazioni del traffico
- traffico di update interferisce con il traffico dati
Questo approccio ha dato vita a RIP.
ARPAnet V2 ha quindi adottato l'approccio link state (dijkstra). Questo approccio ha dato vita a OSPF.
Inter-domain
Dagli anni 90 a oggi, il routing inter-domain ha guadagnato sempre maggiore importanza.
BGP: protocollo distance vector (like) che determina una comunicazione TCP tra router che segnalano paths verso le destinazioni.
Problematiche:
- Volume di traffico alto rispetto al previsto (1997).
- Alta percentuale di traffico ridondante / patologica / obsoleta.
- Aumento volume di traffico su link congestionati (TCP, timers mal congestionati)
- Errori di configurazione locali hanno effetti sull'intera rete (globali)
- Deadlock / Effetto black hole: router non esistente porta l'intera rete a scartare traffico.
Tutto cio' rese la gestione di BGP praticamente impossibile, anche dimostrando quanto sia deleterio basare l'instradamento dinamico sulla congestione dei link. Questo si e' rivelato sbagliato perche':
- Oscillazioni sui link: un link congestionato viene evitato, ma scegliendo l'altro questo viene liberato, e quindi si oscilla tra i due.
Inoltre BGP ha dimostrato che gli errori di configurazione si propagano, e che non e' consigliabile mischiare pacchetti di controllo e traffico dati.
La soluzione: fornire linee guida per la configurazione dei link / router, che pero' non calcola l'errore umano.
Mantenere lo stato di una rete
Lo stato e' l'informazione memorizzata dai protocolli di rete nei nodi. Lo stato deve essere:
- aggiornato con il mutare delle condizioni della rete
- conservato in molteplici nodi
- associato a sessioni / chiamate generate dai sistemi terminali (utenti).
Lo stato presuppone un mittente e un ricevitore:
- mittente: nodo interessato a creare messaggi di stato / segnalazione sullo stato ricevitore. Questo al fine di installare, mantenere e rimuovere lo stato su altri nodi.
- ricevitore: nodo che reagisce ai messaggi del mittente creando, mantenendo e rimuovendo lo stato.
Hard state: definizione
Utilizzato in telefonia, ATM, TCP.
Nell'hard state, lo stato e' valido (installato) finche' non e' ricevuto un messaggio specifico. Il ricevitore installa e rimuove lo stato alla ricezione di un setup message / teardown message mandato dal mittente.
Problematica:
- Stati orfani: un problema di malfunzionamento genera stati orfani, che quindi non hanno uno stato valido ma pensano che esso lo sia. Per questo sono necessari meccanismi esterni al protocollo per segnalare la perdita dello stato, che altrimenti rimane attivo a oltranza (sprecando risorse allocate e non utilizzate).
Per questo motivo, molti protocolli di rete si basano su soft state perche' e' piu' robusto, mentre hard state e' intrinsecamente fragile.
(vedi slides per disegno)
Soft state: definizione
Il progetto del multicast su IP si e' sempre basato sull'approccio soft-state (Clark, 1988). L'idea e' che lo stato della rete (router) sia installato / gestito dai nodi. Gli utenti quindi sono responsabili dello stato della rete. Lo scopo era ottenere una segnalazione flessibile e robusta, nonche' distribuita e organica.
Chiappa ha ridefinito il soft-state:
- stato mantenuto probabilisticamente
- non e' necessariamente consistente in ogni elemento della rete
- gli utenti assumono la piena responsabilita' di mantenere lo stato
- la rete assume la responsabilita' di rimuovere lo stato.
L'approccio soft state si basa sull'assunzione che lo stato non e' valido a meno che non venga rinnovato (refresh). Il mittente quindi invia periodicamente dei refresh messages, senza i quali assumo che lo stato non sia valido. Lo stato e' quindi aggiornato ogni refresh. Questo tipo di segnalazione e' detta segnalazione best-effort.
La fase di segnalazione e' simile all'approccio hard state:
- il ricevitore installa lo stato a ricezione di un trigger message, ma senza aspettare ACK.
- il messaggio di teardown non e' necessario, in quanto lo stato e' rimosso allo scadere del timeout (che implica la mancata ricezione del trigger message).
E' utilizzato da RTP (RTCP), RSVP, IGMP.
(vedi slides per disegno)
Vantaggi rispetto all'hard-state:
- robustezza: migliore reazione e adattabilita' ai cambiamenti della rete.
- semplicita': evita complessita' aggiuntiva per la gestione degli errori.
IP multicast: a love story
Il multicast a livello IP (3) ha visto vari tentativi di sviluppo, allo scopo di ridurre il carico della rete e minimizzare il consumo di risorse. Il problema ha una notevole complessita'.
- Uno dei principali problemi e' la gestione della massa di utenti interessati a una stessa trasmissione di pacchetti.
- Altro problema e' trovare il miglior modo per ramificare l'albero di trasmissione (steiner tree, unire un sottoinsieme di nodi di un albero minimizzando il costo delle connessioni. NP-Completo).
- L'allocazione di banda (prenotazione di risorse per il flusso dati) puo' dar luogo a un carico molto pesante sulla rete, specialmente sui nodi di smistamento del traffico.
Soluzioni:
- astrazione del gruppo Multicast: riservare gli IP di un determinato gruppo come multicast, e lasciare che gli host dichiarino i loro interessi a partecipare al gruppo multicase (IGMP a livello locale). Sono stati riservati gli IP di classe D (2^28 IP) che pero' sono circa 256 milioni, troppo pochi ad oggi. Quindi:
- Livello locale: IGMP, l'host informa il multicast router locale che e' interessato a far parte del multicast. Il router inoltre invia Query periodiche, aspettandosi risposta positiva dai membri del gruppo. Questo protocollo e' quindi soft-state.
- WAN level: il router locale interagisce con altri multicast router per ricevere il flusso di dati. Questa fase e' gestita da vari protocolli, ma non piu' IGMP.
- Essendo lo steiner tree un problema np-completo, e' stato oggetto di numerosi dibattiti. Varie soluzioni:
- Approccio source-based: un albero diverso da ogni mittente ai ricevitori (piu' complesso, ottimale)
- Approccio shared-tree: l'albero e' unico per ogni membro del gruppo (piu' semplice, piu' dispendioso)
Multicast a singola sorgente
Il modello originale di multicast IP e' difficile da implementare, ma molte applicazioni richiedono una singola sorgente. Si utilizza quindi PIM-SSM, che utilizza la coppia di indirizzi (sorgente, gruppo) non richiedendo quindi indirizzi multicast allocati. Costruisce alberi source-based.
RSVP (Resource Reservation Protocol)
L'obbiettivo e' permettere agli utenti di comunicare i propri requisiti alla rete in modo efficiente e robusto. Ormai e' in disuso, ma era pensato per il multicast di IP. RSVP e' basato su soft-state, ha sostituito l'Internet Signaling Protocol.
Requisiti:
- permettere ricevitori eterogenei (flussi a rate diversi)
- sorgenti possono avere diverse applicazioni con diversi requisiti di risorse.
- appoggiarsi ai protocolli di routing esistenti (non occuparsi quindi della costruzione dell'albero).
- modularita'
- overhead del controllo a crescita al piu' lineare
Non si occupa di:
- dividere le risorse (non garantisce banda su percorso / link), ma offre un sistema per comunicare i requisiti di risorsa
- instradare (non fa routing)
- inoltrare i pacchetti (non si occupa della gestione dei dati)
Funzionamento: alto livello
- mittenti e ricevitori entrano a far parte del gruppo multicast (IGMP), ma i mittenti non devono iscriversi al gruppo. Questo e' gestito da IGMP, esterno a RSVP.
- path messages: messaggi mittente-rete che segnalano ai router della presenza dei trasmettitori
- reservation messages: messaggi per riservare le risorse del mittente, mandati dagli utenti.
(vedi slides per struttura di path message, reservation message) (vedi slides per disegno / funzionamento grafico)