Internet: Architettura, Principali Protocolli e Linee...

Nicola BLEFARI-MELAZZIDipartimento di Ingegneria Elettronica e dell’Informazione

Università di Perugia

Eventuali commenti e/o correzioni sono graditi e possono essere comunicati viaposta elettronica:

[email protected]

Internet:Architettura, Principali Protocolli e Linee

Evolutive

Versione 3.0 (Luglio 2000)

A.A. 2000-2001

2

INDICE

I INTRODUZIONE ........................................................................................4

I.1 IL PROCESSO DI STANDARDIZZAZIONE IN INTERNET.................................................. 10

II LE APPLICAZIONI INTERNET ............................................................12

III ARCHITETTURA E PROTOCOLLI .....................................................20

III.1 ARCHITETTURE DI INTERCONNESSIONE.................................................................. 21

III.2 STRUTTURA ............................................................................................................. 30

III.3 ARCHITETTURA PROTOCOLLARE ............................................................................ 33

III.4 IL PROTOCOLLO IP................................................................................................... 37

III.4.1 Formato dell’unità di dati ................................................................................... 38III.4.2 Modalità di segmentazione e di aggregazione .................................................... 42III.4.3 Schema di indirizzamento .................................................................................... 44III.4.4 Traduzione di indirizzi IP in indirizzi locali........................................................ 50III.4.5 Instradamento ...................................................................................................... 54

III.4.5.1 Instradamento diretto............................................................................................................................56III.4.5.2 Instradamento indiretto ........................................................................................................................59III.4.5.3 Tabelle di instradamento ......................................................................................................................60III.4.5.4 Determinazione delle tabelle di instradamento.....................................................................................68

III.4.6 Messaggi di errore e di controllo (ICMP)........................................................... 75III.4.7 Domain Name System .......................................................................................... 78

III.4.7.1 Attribuzione dei nomi...........................................................................................................................81III.4.7.2 Traduzione dei nomi in indirizzi e viceversa........................................................................................85

III.4.8 Esempi.................................................................................................................. 89

III.5 I PROTOCOLLI DI STRATO 4 ..................................................................................... 92

III.6 IL PROTOCOLLO UDP .............................................................................................. 94

III.7 IL PROTOCOLLO TCP............................................................................................... 96

III.7.1 Formato dell’unità dati...................................................................................... 100III.7.1.1 Calcolo della checksum......................................................................................................................102

III.7.2 Instaurazione e rilascio di una connessione...................................................... 102III.7.2.1 Dimensione massima di un segmento.................................................................................................108III.7.2.2 Trasmissione di dati urgenti (out of band)..........................................................................................109

III.7.3 Controllo e recupero di errore .......................................................................... 109III.7.3.1 Stima del valore di TO (time-out di ri-trasmissione)..........................................................................114

III.7.4 Controllo di flusso ............................................................................................. 115III.7.5 Controllo di congestione.................................................................................... 117III.7.6 Estensioni di TCP per le applicazioni in reti ad alta velocità........................... 118

III.8 UN PROTOCOLLO DI GESTIONE: SNMP................................................................. 119

3

III.9 ACCESSO AD INTERNET TRAMITE UN INTERNET SERVICE PROVIDER.................. 120

IV EVOLUZIONE DI INTERNET .............................................................121

IV.1 TCP/IP E ATM: VERSO L’INTEGRAZIONE............................................................. 123

IV.2 SOLUZIONI PER MIGLIORARE LE PRESTAZIONI DI PORTATA................................. 127

IV.2.1 Routers veloci .................................................................................................... 129IV.2.2 Commutatori multi-strato .................................................................................. 133IV.2.3 Multi-Protocol Label Switching (MPLS)........................................................... 139

IV.3 SOLUZIONI PER MIGLIORARE LA QUALITÀ DI SERVIZIO ...................................... 143

IV.3.1 Introduzione alla Qualità di Servizio (QdS) ...................................................... 144IV.3.2 Approccio Integrated Services (IntServ)............................................................ 150

IV.3.2.1 Il protocollo RSVP.............................................................................................................................153IV.3.2.2 Il protocollo RTP ...............................................................................................................................163

IV.3.3 Approccio Differentiated Services (DiffServ) .................................................... 167IV.3.4 Ingegneria del traffico e QoS-routing ............................................................... 175IV.3.5 Conclusioni ........................................................................................................ 177

IV.4 IPV6 ....................................................................................................................... 181

IV.4.1 Caratteristiche generali..................................................................................... 183IV.4.1.1 Nuovo piano di indirizzamento ..........................................................................................................183IV.4.1.2 Miglioramenti prestazionali ...............................................................................................................184IV.4.1.3 Supporto della qualità di servizio .......................................................................................................184IV.4.1.4 Flessibilità nell'indirizzamento...........................................................................................................185IV.4.1.5 Facilitazione della conversione tra indirizzi IP e indirizzi locali (ARP).............................................185IV.4.1.6 Facilitazione della configurazione dei nodi (plug and play) ...............................................................185IV.4.1.7 Funzioni di sicurezza..........................................................................................................................186IV.4.1.8 Supporto della mobilità ......................................................................................................................186IV.4.1.9 Transizione da IPv4 a IPv6 ................................................................................................................187

IV.4.2 Terminologia...................................................................................................... 188IV.4.3 Formato dell'unità di dati .................................................................................. 189IV.4.4 Schema di indirizzamento .................................................................................. 195

IV.5 MOBILE IP.............................................................................................................. 198

IV.5.1 Il concetto di mobilità ........................................................................................ 199IV.5.1.1 Mobilità di terminale..........................................................................................................................199IV.5.1.2 Portabilità...........................................................................................................................................206IV.5.1.3 Mobilità personale..............................................................................................................................207IV.5.1.4 Conclusioni sul concetto di mobilità ..................................................................................................208

IV.5.2 Caratteristiche generali..................................................................................... 209IV.5.3 Terminologia...................................................................................................... 210IV.5.4 Descrizione del protocollo................................................................................. 213IV.5.5 Sviluppi futuri .................................................................................................... 217

IV.5.5.1 Route Optimization (ottimizzazione della strada): .............................................................................217IV.5.5.2 Mobile IPv6 .......................................................................................................................................218IV.5.5.3 Seamless Handover ............................................................................................................................219

V BIBLIOGRAFIA......................................................................................220

V.1 LISTA DELLE FIGURE E DELLE TABELLE ................................................................... 222

4

I� Introduzione

Lo scopo di questa trattazione è quello di descrivere, in modo sommario esenza pretesa di esaustività, la struttura ed il funzionamento della rete Internet.Si assume che siano noti i principi generali di una rete di telecomunicazioni edil modello OSI (cfr., ad es. [ROV95]).

Internet è una infrastruttura per comunicazioni di dati (rete di calcolatori),che si è sviluppata seguendo le linee-guida del modello omonimo. Attualmentesta conoscendo un successo a livello mondiale che non ha precedenti per la suaestensione geografica, per la numerosità dei suoi utenti e per la vastità diinteressi coinvolti. A titolo puramente orientativo, alla fine del 1997, il numerodi calcolatori connessi era di oltre 20 milioni e si stimavano in circa 70 milionigli utenti serviti (tenendo conto che uno stesso calcolatore può essere usato dapiù utenti). Alla fine del 2000, in ambito mondiale, il numero di utenti dovrebbeessere di circa 300 milioni e sestuplicarsi entro la fine del 2005.

Il modello architetturale di Internet sarà discusso con più dettaglio nelseguito (Cap. III). Qui è importante sottolineare che Internet non è una nuovarete, progettata e costruita ex novo o necessariamente alternativa alle soluzionidiscusse in precedenza, ma l’unione di diverse reti, spesso pre-esistenti edeterogenee tra loro. Le reti componenti Internet sono però omogenee al lorointerno e possono operare in accordo ad un qualsiasi paradigma dicomunicazione.

La struttura fisica di Internet è costituita quindi da un certo numero di reticomponenti e da alcuni dispositivi che le interconnettono; tali dispositivi diinterconnessione, mediante l’uso di opportuni protocolli di comunicazione,consentono a calcolatori connessi a reti diverse di scambiarsi informazioni.

Elemento caratterizzante di Internet è il modo in cui questa rete è nata e siè sviluppata. I primi studi sulla interconnessione di calcolatori furono effettuatialla fine degli anni sessanta. Si voleva allora sperimentare una tecnica chepermettesse la condivisione di linee di comunicazione da parte di utenti attestatisu sistemi diversi, sfruttando la tecnica della commutazione di pacchetto. Inquegli anni il Ministero della Difesa degli Stati Uniti (Department of Defense,DoD) incaricò l'organizzazione ARPA (Advanced Research Project Agency) disviluppare e sperimentare una rete di calcolatori.

Dovendo avere applicazioni militari, uno dei requisiti fondamentali chetale rete doveva soddisfare era la resistenza ad attacchi che ne modificassero laconfigurazione (ad .es. per interruzione di linee di giunzione o di centri di

5

commutazione). Sue caratteristiche dovevano quindi essere una strutturareticolare, magliata, non gerarchica e con un’elevata capacità diinterconnessione e di interlavoro fra una grande varietà di nodi di rete. Per lostesso motivo si scelse di adottare una modalità di trasferimento senzaconnessione e senza garanzie di qualità del servizio, rimandando queste ultimeai livelli superiori dell’architettura protocollare. La rete nata da questo progetto,e denominata ARPANET, è stata il primo esempio di rete geografica acommutazione di pacchetto. Nel 1983 tale rete fu separata in due parti: unacivile (ARPANET) ed una militare (MILNET). Nel 1985, sempre negli StatiUniti, la National Science Foundation finanziò lo sviluppo di una rete ditrasporto a lunga distanza (NSFnet) e di reti regionali, che consentirono diinterconnettere LAN di diverse università e di enti di ricerca alla reteARPANET.

La rete Internet si è sviluppata a partire da questo nucleo iniziale fino adestendersi in tutto il mondo e comprendendo non più solo organizzazionipubbliche o di ricerca e al servizio della comunità scientifica ma ancheorganizzazioni commerciali ed utenti privati.

Le entità di calcolo all’interno di questa struttura sono chiamati host.Questi possono essere super-computer paralleli, mini-computer, workstation,semplici personal computer o calcolatori portatili. I ritmi binari di trasferimentodelle informazioni possono essere molto variabili, sia nel tempo che in funzionedelle coppie origine-destinazione considerate (da pochi bit/s fino a centinaia diMbit/s).

A causa delle particolari esigenze sopra menzionate, e postedall'organizzazione ARPA, si determinò una divergenza tecnica iniziale tra lescelte effettuate per ARPANET e quelle adottate dagli organismi distandardizzazione ISO e ITU-T (ex CCITT). La divergenza iniziale sulle sceltetecniche è perdurata nel tempo attraversando gli anni settanta ed ottanta,durante i quali ARPANET cresceva notevolmente negli Stati Uniti,espandendosi dall'ambito iniziale della difesa a quello dell'istruzione e dellaricerca e conquistando sul campo un numero di utenti sempre maggiore. Nelfrattempo ISO e ITU-T lavoravano alla definizione di un modello teorico diinterconnessione tra sistemi aperti (l'Open Systems Interconnection, OSI) edalla specifica di una serie di protocolli di comunicazione conformi a talemodello.

Fino alla fine degli anni ottanta era opinione diffusa che OSI ed i suoiprotocolli sarebbero stati universalmente adottati.

Tale previsione si è però dimostrata non corretta: la realtà Internet si èinfatti talmente diffusa, sia negli Stati Uniti che nel resto del mondo, che ha di

6

fatto impedito ad OSI di svilupparsi significativamente. La rete Internet haraggiunto gli obiettivi che OSI si prefiggeva, costituendo una base diinterconnessione aperta ed indipendente dai costruttori di sistemi ditelecomunicazione.

Internet è oggi una infrastruttura di comunicazione le cui risorse sonodislocate spazialmente in tutto il mondo, ma che sono viste dal singolo utente inmodo trasparente, senza cioè che sia necessario sapere dove sono fisicamente,ed a cui è molto facile accedere con strumenti progettati e realizzati per i suoiutenti.

Fra le principali caratteristiche ed i fattori di successo che hanno portatoallo sviluppo esplosivo di Internet, si possono citare i seguenti:

- la modalità di trasferimento, nello strato di rete, è senza connessione eInternet non fornisce alcuna garanzia sulla qualità di servizio; Internet siimpegna a fare del suo meglio, ma non è possibile, in generale, essere sicuri ocontrattare che il trasferimento avvenga con determinate specifiche (integritàinformativa, ritardo di trasferimento, grado di trasparenza temporale, etc.). Ilcompito di rendere la qualità di servizio adeguata alle esigenze degli utenti èdemandato ai livelli applicativi residenti nei sistemi terminali. Il paradigmaInternet offre quindi meno funzionalità del modello OSI (almeno negli stratibassi dell’architettura protocollare), ma la sua realizzazione è più semplice;

- la modalità di funzionamento di Internet è diversa rispetto a quella tipica dialtre reti; infatti essa non richiede che tutti i sistemi che la compongono sianobasati su di una identica e comune architettura protocollare;

- in molte reti geografiche le apparecchiature di rete deputate al trasporto, allacommutazione ed all’elaborazione delle informazioni sono di proprietà disocietà pubbliche o private che installano e gestiscono i sistemi di TLCmettendoli a disposizione dell’utenza; nel caso della rete Internet ciò è verosolo in parte, in quanto alcune apparecchiature di utente e molte sotto-retiprivate contribuiscono in modo significativo al trasporto delle informazioni;

- Internet offre i suoi servizi a costi accessibili; la tariffazione èprevalentemente di tipo “flat rate”, cioè non dipende dalla quantitàdell’informazione scambiata o dalla distanza che separa gli utenti;

- il software che realizza i protocolli di comunicazione di Internet è statofornito gratuitamente e risulta di semplice implementazione; inoltre,inizialmente ed ancora oggi, tali protocolli sono stati distribuiti insieme alsistema operativo Unix. La grande diffusione di Unix, soprattutto nellacomunità scientifica, ha trainato con se anche i protocolli Internet;

- altrettanto gratuito è spesso il software applicativo necessario per sfruttareappieno le capacità di comunicazione dell'infrastruttura; gli applicativi più

7

utili e più facili da usare si diffondono in tal modo con grande rapidità, comeè avvenuto in passato per applicazioni quali Gopher (applicativo per laricerca di informazione) e, più recentemente, per il WWW (World Wide Web),cioè per una applicazione multimediale di banca di dati distribuita.

- il processo di standardizzazione è snello, rapido e prevede delle verificheimplementative: si richiede che esistano almeno due diverse implementazioniinteroperanti di un protocollo ed una solida esperienza in campo prima didichiararlo standard;

- le idee di lavoro e le specifiche dei protocolli sono state sempre ampiamentee liberamente diffuse (anche e soprattutto per mezzo della stessa Internet); ladisponibilità di informazioni generali e dettagliate sui protocolli, e dellerelative implementazioni, anche nei primissimi stadi di sviluppo, ha svolto unruolo essenziale nella loro diffusione. Un simile impegno verso ladocumentazione pubblica e gratuita a questo livello di dettaglio è inusuale. Ibenefici di questo modo di procedere hanno avuto significative conseguenzenon solo sulla realizzazione di Internet ma anche, più in generale, sullosviluppo delle telecomunicazioni. In particolare, il sito www.ietf.org forniscesia informazioni relative all'organizzazione generale di Internet e sui suoiorganismi che i relativi standard, denominati Request For Comments (RFC).

La principale caratteristica della struttura attuale di Internet (una unione didiverse reti) è motivata da due considerazioni:

- nel passato è stato difficile far si che un’unica tipologia di rete potesserispondere in modo esauriente alla esigenze di comunicazione di ognipossibile utente. Ad esempio, le reti in area locale consentivano elevatevelocità di trasferimento ma erano limitate geograficamente; il viceversaaccadeva per le reti in area geografica. Inoltre la fisiologica esistenza didiversi produttori ha portato spesso a sviluppare sistemi di telecomunicazionenon compatibili tra loro. Da ciò è derivato lo sviluppo di diversi paradigmi dicomunicazione e la attuale co-esistenza di diverse reti di telecomunicazioni.Oggi è tecnicamente possibile realizzare un’unica infrastruttura dicomunicazione che soddisfi i requisiti di tutti gli utenti in modo efficiente (èl’obiettivo della rete B-ISDN, basata sul modo di trasferimento ATM), manon risulta economicamente vantaggioso sostituire tutti i sistemi giàoperativi;

- gli utenti desiderano una connettività universale. L’importanza e l’utilità diuna rete di telecomunicazioni sono legate anche al numero dei suoi utenti. Adesempio, la rete telefonica risulta molto utile proprio perché i suoi utenti sononumerosi (e quindi tramite essa è possibile comunicare con un grande

8

numero di persone) e perché la rete appare ad essi come un solo sistema dicomunicazione. La rete telefonica non avrebbe avuto lo sviluppo checonosciamo se fosse stata costituita da diverse sotto-reti con diversi standarde protocolli e non comunicanti tra loro. In tal caso infatti da un datoapparecchio telefonico non sarebbe stato possibile raggiungere tutti gli altriutenti ma solo un loro sotto-insieme.

In altre parole si desidererebbe una singola rete a cui tutti possanoconnettersi e tramite la quale raggiungere chiunque, ma è apparso sinoradifficile realizzare una soluzione unitaria e quindi si è preferito renderepossibile la comunicazione tra diverse tipologie di reti.

Tali considerazioni hanno portato al concetto di inter-rete, e cioè di unainfrastruttura fisicamente costituita da:

- un certo numero di reti componenti (nel seguito indicate come sotto-reti), cuisono collegati dei calcolatori (denominati nel seguito host);

- un certo numero di dispositivi necessari per interconnettere le sotto-reticomponenti (denominati sistemi di interconnessione).

Da un punto di vista logico, l’elemento distintivo di una inter-rete èrappresentato dall’insieme di procedure di inter-lavoro (o protocolli dicomunicazione) necessarie per interconnettere le sotto-reti e per permettere aqualunque host A connesso alla inter-rete di colloquiare con qualunque altrohost B, anch’esso connesso alla inter-rete. La comunicazione tra A e B deveessere possibile indipendentemente dalle sotto-reti a cui A e B sonodirettamente connessi e dal numero e dalla tipologia delle altre sotto-retieventualmente coinvolte in tale comunicazione.

Internet è l’esempio più significativo di inter-rete oggi operativa su basemondiale. Sono da sottolineare le sue specificità. In primo luogo si vuolenascondere la struttura di rete ai suoi utenti. Questi ultimi e i programmiapplicativi di loro interesse non devono preoccuparsi dei dettagliimplementativi della rete fisica. Non si vuole imporre una pre-determinatatopologia di rete. L’aggiunta di una nuova sotto-rete a Internet, e quindi allesotto-reti pre-esistenti in Internet, non si effettua connettendo la nuovasotto-rete ad un nodo centrale o con l’aggiunta di connessioni fisiche dirette trala nuova sotto-rete e tutte le altre pre-esistenti. E’ sufficiente connettere lanuova sotto-rete ad una qualsiasi altra sotto-rete già connessa ad Internet. Leinformazioni sono quindi trasferite da una sotto-rete ad un’altra utilizzando, ingenerale, altre sotto-reti intermedie e attraversando diversi sistemi diinterconnessione. Non vengono invece coinvolte sotto-reti intermedie qualorauna sotto-rete che origina delle informazioni sia direttamente connessa allasotto-rete cui queste informazioni sono dirette, ovvero quando è possibile

9

trasferire informazione dall’una all’altra attraversando un solo sistema diinterconnessione (cfr. par. III.1 e par. III.2).

Una seconda specificità di Internet è che essa assicura l’indipendenzadell’interfaccia utente-rete dalle specificità della sotto-rete di accesso.L’insieme di operazioni necessarie per trasferire dati è indipendente dallatecnologia della sotto-rete di accesso e dal sistema di destinazione. Unprogramma applicativo di comunicazione non deve tenere in conto la topologiae la struttura di sotto-rete.

I protocolli Internet si vanno ad aggiungere a quelli già esistenti all’internodelle sotto-reti componenti; questi ultimi non devono essere modificati. In talmodo alcune funzioni possono risultare duplicate e quindi si possono verificaredelle inefficienze, ma questo modo di procedere determina notevolisemplificazioni operative.

Prima dell’avvento di Internet le reti per dati erano in gran parte diverse enon inter-comunicanti. Le sotto-reti di Internet sono rimaste diverse, nel sensoche sono basate su diverse architetture e protocolli (e di per se autonome), ma iprotocolli e i sistemi di interconnessione di Internet hanno fatto si che potesserocolloquiare tra loro.

Essendo Internet costituita da diverse tipologie di rete, ognuna, in generale,di proprietà di enti diversi, la sua modalità di gestione è necessariamente di tipodistribuito.

L’architettura di Internet comprende quattro strati.Un primo strato, detto di accesso alla rete (Network Access Layer),

consente la utilizzazione di risorse infrastrutturali (sotto-reti), tra loro anche nonomogenee per tecnica realizzativa. Lo strato di accesso alla rete include lefunzioni che nel modello OSI sono comprese negli strati fisico, di collegamentoe di rete, quest'ultimo almeno per ciò che riguarda gli aspetti connessi alfunzionamento di ogni singola rete componente (sottostrato di rete basso).

Un secondo strato, che è denominato IP (Internet Protocol) dal nome delprotocollo che gli è proprio, consente l'interfunzionamento delle varie reticomponenti con funzionalità che nel modello OSI sono collocabili in unsottostrato di rete alto. Il servizio di strato corrispondente è senza connessione.

Un terzo strato corrisponde allo strato di trasporto del modello OSI e vienedenominato in base al protocollo che gli è proprio. Un primo tipo di protocollodi questo strato è il TCP (Transmission Control Protocol), nell'ambito del qualeil servizio di strato è con connessione. Un protocollo alternativo è l'UDP (UserDatagram Protocol), che a differenza del precedente è senza connessione;

Il quarto e ultimo strato del modello Internet è quello applicativo e

10

corrisponde ai tre ultimi strati del modello OSI. Viene denominato strato deiServizi Applicativi (Application Services).

Prima di iniziare a descrivere il funzionamento di Internet è utile fare unaprecisazione. La trattazione che segue fa riferimento a sistemi (host)direttamente connessi ad Internet e dotati di un proprio, stabile ed univocoindirizzo. Questo non è il caso di sistemi che si connettono ad Internet per iltramite di un Internet Service Provider (ISP), usando tipicamente la retetelefonica commutata, ovvero la probabile maggioranza dei lettori di questamonografia. Tuttavia le modalità di funzionamento di Internet sono statedefinite con riferimento ad host direttamente connessi e quindi è necessario fareriferimento a questa situazione. In particolare, quando un utente si connette atInternet tramite un ISP, prima di poter iniziare effettivamente uno scambioinformativo con altri host, riceve dall'ISP delle opportune informazioni diconfigurazione, tra cui un indirizzo che lo identificherà nell'ambito di quellasessione, ma che potrà essere diverso in sessioni successive. Ciò significa ancheche un utente di questo tipo è raggiungibile dall'esterno solo tramite il suo ISP,dal momento che l'utente in questione, non disponendo tipicamente di unindirizzo stabile ed univoco in Internet non è "conosciuto" dagli altri sistemiconnessi ad Internet (cfr. III.4.4). Questa precisazione risulterà probabilmentepiù chiara dopo aver letto la trattazione che segue, dal momento che è difficileillustrare tali peculiarità prima di avere descritto i principi generali di Internet(cfr. III.9).

Infine, riteniamo opportuno dare nel seguente paragrafo qualcheinformazione sommaria circa gli Enti che presiedono al processo distandardizzazione in Internet ed alla relativa organizzazione.

I.1� Il processo di standardizzazione in Internet.

L'Ente responsabile della definizione dei protocolli e delle regole difunzionamento di Internet è denominata Internet Engineering Task Force(IETF). Informazioni dettagliate relative all'organizzazione generale di Interneted ai suoi organismi nonché i relativi standard possono essere reperiti nel sitowww.ietf.org. Qui citiamo solo la presentazione dell'IETF(www.ietf.org/overview.htm):

"La Internet Engineering Task Force (IETF) è una comunitàinternazionale, aperta, di progettisti di rete, operatori, costruttori, venditori ericercatori interessati all'evoluzione ed al regolare funzionamento di Internet. E'aperta a tutti gli interessati.

11

L'attività di ricerca&sviluppo è organizzata in Gruppi di Lavoro (WorkingGroups), ognuno responsabile di una certa tematica (routing, transport, security,etc.). I Gruppi di Lavoro sono organizzati in Aree. Gran parte del lavoro èsvolta mediante "mailing lists", ovvero via posta elettronica. L'IETF organizzatre riunioni ogni anno. Ogni Area è gestita dagli Area Directors (AD). Gli ADsono membri dell'Internet Engineering Steering Group (IESG). La InternetArchitecture Board (IAB) si occupa di questioni architetturali di portata piùgenerale e risolve eventuali conflitti che l'IESG non sia riuscita a risolvere.L'IESG e l'IETF sono presiedute dal General Area Director, che è anchemembro di diritto dell'IAB.

L'Internet Assigned Numbers Authority (IANA) è l'autorità centrale checoordina l'assegnazione dei parametri numerici dei protocolli (inclusi gliindirizzi IP ed i numeri di porta TCP, cfr. i seguenti capitoli). L'Internet Society(ISOC) infine sopraintende all'IANA, all'IESG e all'IAB."

Internet è definita dall'IETF come una collaborazione di reti autonome edinterconnesse, non rigidamente organizzata (loosely organized), che supportacomunicazioni tra host attraverso il volontario rispetto di protocolli e procedureaperti, definiti dagli Internet Standards. Il suo "credo" è "We reject kings,presidents and voting. We believe in rough consensus and running code". (IETFCredo, Dave Clark, 1992).

Come si vede, la comunità Internet tiene a preservare lo spirito potremmodire pioneristico originale, ma la stessa importanza di Internet sta spingendosempre più verso una organizzazione più gerarchica e formale, seppure nelrispetto del suo credo e soprattutto nell'apertura verso chiunque vogliacollaborare e nella diffusione dei protocolli.

In Internet, gli standard sono denominati Request For Comments (RFC).Ciò in accordo alle procedure seguite inizialmente (ed in parte ancora oggi)dalla comunità Internet, in cui di fronte ad un problema si chiedeva a chiunquefosse interessato di proporre delle soluzioni (da cui il nome).

Originariamente, quindi, le RFC non erano degli standard, masemplicemente delle comunicazioni tra gli addetti ai lavori. Attualmenteesistono due tipi di RFC:

- For Your Information RFC (FYI RFC): sono di natura descrittiva, riportanoargomenti di natura generale o perfino l'organizzazione delle riunioni dellacomunità Internet ed il modo di vestirsi alle stesse (cfr. ad esempio, RFC1718, "The Tao of the IETF").

- Standard RFC (STD RFC): sono i veri e propri standard adottati in Internet.La strada che conduce ad una RFC standard parte tipicamente da un

cosiddetto Internet-Draft. Un Internet-Draft è un documento di lavoro che può

12

essere proposto da un qualunque individuo o Ente interessato e che viene postoa disposizione di tutti tramite i siti dell’IETF e tramite le mailing lists. UnInternet-Draft ha una validità di sei mesi trascorsi i quali decade, a meno chenon sia ritenuto interessante e quindi promosso a RFC (eventualmente conopportune modifiche/integrazioni). Un Internet-Draft può essere sostituito,migliorato o cancellato in ogni momento durante il suo periodo di validità.

II� Le applicazioni Internet

Nell’ambiente Internet, i protocolli di strato superiore al 4 sono denominatiServizi Applicativi e le loro funzioni non sono divise in termini di strato disessione, presentazione ed applicazione.

I Servizi Applicativi in Internet operano prevalentemente in accordo alparadigma client/server; hanno cioè una componente client ed una server. Taleparadigma è importante anche perché è alla base di molti sistemi dicomunicazione ed è fondamentale per comprendere le modalità difunzionamento di algoritmi distribuiti.

Il termine server si applica a qualunque processo che offre un servizio eche può essere raggiunto attraverso la inter-rete. I server accettano le richieste,le elaborano, effettuano il servizio richiesto e restituiscono il risultato alrichiedente. Un processo applicativo è invece un client quando invia unarichiesta ad un server ed aspetta la relativa risposta. Ad esempio, un sempliceserver “ora esatta” fornisce l’ora attuale ogni volta che un client gli invia unarichiesta. I server gestiscono le risorse e i client richiedono servizi alle risorse.

La durata in attività delle componenti client e server è diversa; un serverinizia ad essere attivo prima che l’interazione con il client inizi e continua adaccettare richieste e ad inviare risposte senza cessare di essere attivo; lacomponente client si attiva al momento di inviare una richiesta e si disattiva unavolta ricevuta la risposta. Normalmente la componente server inizia ad operareal momento dell’accensione di un host e quando invocata, fornisce allacomponente client i mezzi e le procedure o i dati di cui questa ha bisogno.

Molti dei servizi applicativi richiedono un’autorizzazione all’uso: unutente può usare un servizio applicativo se dispone di una utenza (“account”),concessa dall’amministratore del sistema remoto (server), a cui accede medianteuna parola d’ordine (“password”). In tal caso, la componente client devecomunicare a quella server il nome dell’utenza e la relativa parola d’ordine,prima di poter richiedere uno specifico servizio.

In questo paragrafo si descriveranno i più importanti e diffusi serviziapplicativi che la comunità Internet mette a disposizione dell’utenza. Ognuno di

13

tali servizi opera in accordo ad uno specifico protocollo che governa lo scambiodi informazioni tra la componente client e quella server. Inoltre, un datoservizio applicativo può essere implementato nell’ambito di diverseapplicazioni, basate su specifiche piattaforme operative e personalizzate oarricchite da interfacce di utente e più o meno sofisticate.

TELNETLa componente client di TELNET è un protocollo di emulazione di

terminale che permette agli utenti di un sistema di accedere ad applicazioni inaltri sistemi remoti, come se fossero direttamente connessi a tali sistemi.Consente quindi di utilizzare le funzioni di un calcolatore remoto come se ilterminale che si usa fosse uno dei terminali locali del sistema remoto. L'host didestinazione deve contenere la componente server di TELNET. Il procedimentopuò essere iterativo; ovvero ci si può collegare ad un host remoto e, da lìcollegarsi ad un altro host e così via.

L’applicativo Telnet consente di aprire sessioni interattive (login remoto)su host ovunque ubicati all’interno della inter-rete purché si disponga diun’autorizzazione all’uso (utenza + parola d’ordine). Il terminale emulato è ditipo testuale.

SMTP (SIMPLE MAIL TRANSFER PROTOCOL)La posta elettronica (E-mail) è uno dei servizi applicativi più usato in

Internet. La sua popolarità deriva dalla facilità di uso che consente di trasferirevelocemente sia piccole note che voluminosi documenti. I vantaggi sono ovvi:il messaggio ricevuto può essere registrato e catalogato, inoltre può esseremodificato o usato come base per successivi lavori, al contrario di unmessaggio ricevuto su carta o a voce che necessita di dover essere trascritto.Inoltre non richiede che mittente e destinatario siano contemporaneamentepresenti. Un utente può inviare un messaggio ed il destinatario può leggerlo inun tempo successivo. Gli applicativi di posta elettronica permettono discambiare messaggi tra utenti utilizzando il protocollo di comunicazioneSMTP.

L'obiettivo che il protocollo SMTP si propone è quello di offrire imeccanismi per trasferire messaggi in forma elettronica in modo affidabile edefficiente attraverso Internet. A tal fine, SMTP usa il protocollo TCP comeprotocollo di strato 4 e quindi adotta una modalità di trasferimento conconnessione ed affidabile.

A fronte di una richiesta di invio di e-mail da parte dell'utente, il "sender-SMTP" stabilisce una connessione bi-direzionale con il "receiver-SMTP". La

14

connessione è bi-direzionale, in quanto il servizio è di tipo confermato, cioè ildestinatario invia al mittente dei messaggi di riscontro per confermare lacorretta ricezione del messaggio inviato dall’utente.

Preliminarmente all’invio del messaggio vero e proprio il "sender-SMTP"verifica la disponibilità del "receiver-SMTP" ad accettare il messaggio stesso e,se non vengono riscontrati problemi (indisponibilità del receiver, utentesconosciuto, etc.), si avvia il processo di trasmissione del messaggio generatodall'utente.

Il formato dei messaggi è regolato da uno standard (RFC822). SMTPprevede anche funzionalità di traduzione tra diversi formati e l’uso di gatewayverso sistemi di E-mail non basati su TCP/IP. Ha diverse potenzialità: uso dialias, liste di destinatari, risposte automatiche, etc.

FTP: FILE TRANSFER PROTOCOL

E’ un altro dei servizi applicativi più usati ed è responsabile di unarilevante quantità del traffico totale. La principale funzione del protocollo FTPè il trasferimento efficiente ed affidabile di archivi (files) tra host remoti.Consente anche di visualizzare il contenuto di sistemi di archiviazione remoti edi modificare o cancellare files e directories ivi residenti.

Supporta il trasferimento di quattro tipi di files: Binari, ASCII, EBCDIC e“paged”. Fornisce funzionalità di protezione dei file trasmessi e compressionedi dati; non fornisce funzionalità di traduzione o di conversione di files.

Nell’effettuare il trasferimento di un file, la componente client delprotocollo FTP realizza innanzitutto una connessione di controllo con lacomponente server. Attraverso questa connessione vengono inviati al serverFTP i comandi, opportunamente codificati, che originano da richiestedell’utente. Il server FTP, interpreta tali comandi ed effettua la trasmissione deidati richiesti. Per garantire l’affidabilità dei dati trasmessi usa, come protocollodi strato 4, TCP.

TFTP: TRIVIAL FTPE’ un protocollo simile a FTP, trasferisce archivi (files) tra host remoti, ma

fornisce meno funzionalità di FTP: non consente di proteggere i files trasmessie di gestire directories. Usa UDP invece di TCP come protocollo di strato ditrasporto.

TALKConsente il dialogo in tempo reale tra due utenti. Genera, sullo schermo

degli utenti, una finestra divisa in due parti; in una compare ciò che si scrive

15

mentre nell’altra compare ciò che scrive l’utente remoto.

X-WINDOW

E’ simile a Telnet, ma fornisce anche sofisticate funzionalità grafiche.Consente ad un utente di accedere contemporaneamente a diverse applicazioniin altri sistemi come se fosse direttamente connesso a tali sistemi.

La principale differenza rispetto a Telnet è che il terminale emulato è ditipo grafico e quindi consente di usare anche applicazioni remote che fanno usodi visualizzazioni non solo testuali.

NFS: NETWORK FILE SYSTEM

Consente di utilizzare un sistema di archiviazione (file system) remoto allostesso modo di uno locale. Grazie a NFS è possibile vedere, copiare, modificaree cancellare files residenti in un sistema remoto in modo del tutto trasparenteper l’utente. A differenza di FTP, con NFS l’utente può anche ordinarel’esecuzione di un qualunque processo ed usare qualsivoglia file (locale oremoto) per l’input e l’output di tale processo. Un’altra caratteristica di NFS èche consente all’utente finale di eseguire tutte le azioni appena descrittemediante gli stessi comandi del sistema operativo che l’utente usa nel propriosistema, per le stesse azioni riferite al sistema locale. Non è necessario quindiche l’utente debba usare in modo esplicito il tramite di un’applicazione di reteper interagire con un sistema remoto; NFS gestisce tutte le operazioninecessarie per tali interazioni senza che l’utente finale ne abbia coscienza edopera, per usare un termine gergale, “nello sfondo” o “in ombra” (in“background”). Nella Fig. 1 le directories ed i files dei sistemi remoti “berkeleyed “osaka” sono accessibili come se fossero residenti sul sistema locale, a menosolo di eventuali limitazioni nella velocità di accesso. Sempre in gergo, si diceche i file systems remoti sono “montati” sul sistema locale.

16

�

�

��

��

��

��

��

��

Fig. 1 – Esempio di funzionamento di NFS

WORLD WIDE WEBWorld Wide Web, chiamato anche WWW o W3, è un sistema informativo

multimediale basato su ipertesti la cui origine risale al 1989. E’ attualmente ilservizio applicativo più usato in Internet. Consente ad un utente di acquisire undocumento situato in un sistema remoto, usando la componente client di WWW(denominata “browser”). In ogni host in cui siano contenuti dei documenti deveinvece operare la componente server. La particolarità di WWW è la tipologiadei documenti acquisibili.

I documenti WWW sono:- multimediali e cioè contengono informazioni testuali, grafiche e sonore,

eventualmente compresse mediante opportuni algoritmi per ridurre il volumedi traffico scambiato durante il trasferimento;

- ipertestuali: alcune parole o immagini o zone del documento acquisitocontengono dei collegamenti ad altri documenti; l’utente, selezionando unodi questi collegamenti (link), acquisisce il relativo documento.

Quest’ultima caratteristica è quella che ha determinato lo sviluppo attualedel WWW. Un particolare documento può contenere diversi collegamenti,ognuno dei quali è un puntatore ad un altro documento; ogni documento puòessere situato in un qualunque host connesso ad Internet. L’utente, sfogliando ildocumento in questione, può scegliere di seguire uno qualsiasi di questicollegamenti. L’aspetto più comodo, che rende il WWW particolarmentesemplice da usare, è che ogni collegamento contiene anche l’indirizzo dell’hostin cui il documento cercato si trova. In tal modo, l’utente può acquisire diversidocumenti, localizzati ovunque nel mondo, senza bisogno di sapere dove essi

17

siano fisicamente memorizzati. Il processo può divenire iterativo per cui da undocumento l’utente può passare ad esaminare un altro documento che contienecollegamenti ad altri documenti ancora e così via.

Di fatto l’intero insieme del WWW (e cioè tutti i documenti accessibili ditipo WWW) appare all’utente, nella sua interezza, come se fosse disponibile nelsuo host, a meno di eventuali limitazioni nella velocità di accesso; l’utente nonè tenuto a sapere dove sia localizzato uno specifico documento, e non c'ènecessità che digiti comandi o interroghi basi di dati alla ricerca di talelocazione.

Ad esempio, quando una nuova parola o un nuovo concetto sono introdottiin un testo, WWW offre i mezzi per collegarsi ad un altro documento in cuivengono forniti maggiori dettagli a riguardo, in modo tale che il lettore puòaprire il secondo documento selezionando la parola o il concetto sconosciuto;questo documento può a sua volta contenere ulteriori riferimenti ad altradocumentazione residente in altri sistemi. E’ ciò che si intende per “navigare”nella rete, seguendo un “albero” di documenti che si può biforcare in ognimomento.

L'accesso ai server WWW avviene tramite applicativi di tipo client. Questiapplicativi sono disponibili per diverse piattaforme software. Gli esempi piùnoti e diffusi di tali applicativi sono Netscape e Internet Explorer. Spesso leapplicazioni che implementano la componente client di WWW contengonoanche componenti client di altri servizi applicativi, come ad esempio FTP oNews. Tali applicazioni contengono inoltre ulteriori moduli software (nonservizi di rete, ma applicazioni locali) necessari per:

- convertire il formato di alcuni documenti;- decomprimere documenti codificati con opportuni algoritmi per ridurre il

volume di traffico scambiato;- presentare in modo adeguato l’informazione (ad es. video o audio) all’utente

finale.Il servizio applicativo WWW si basa su due protocolli:

- Hyper Text Markup Language (html): definisce il formato dei documenti;- Hyper Text Transfer Protocol (http): è il protocollo che consente di trasferire

i documenti.Il protocollo HTTP usa come protocolli di strato di trasporto sia TCP che

UDP, instaurando contemporaneamente anche più di una connessione TCP peril trasporto di diverse parti del documento.

GOPHERInternet Gopher, o più semplicemente Gopher, è un servizio distribuito per

18

l’acquisizione di documenti, che consente di esplorare, cercare e acquisireinformazioni residenti in differenti locazioni. E’ simile a WWW ma a questiprecedente e sta diventando obsoleto, poiché offre meno funzionalità.L'interfaccia tipica di questo servizio suddivide le informazioni in una serie dimenu nidificati, che rispecchiano l'organizzazione delle informazioni indirectory, sub-directory e file.

Dal punto di vista dell'utente, tutte le informazioni sembrano esseredislocate nello stesso posto, sebbene alcune sub-directory e il loro contenutopossano trovarsi fisicamente su dei sistemi remoti gestiti da altri serversGopher. Tale struttura gerarchica delle informazioni porta alla definizione diuno “spazio Gopher”, cioè di una struttura logica unitaria composta dainformazioni contenute in server gopher ubicati spazialmente in luoghi diversi.

La tipologia delle informazioni gestite da questo servizio comprende file ditesto, file binari, immagini e suoni.

ARCHIEArchie è un sistema informativo nato per offrire un servizio di directory

elettronico centralizzato, mediante il quale è possibile localizzare leinformazioni nell'ambito della rete Internet; allo stato attuale si contano uncentinaio di siti distinti che offrono il servizio.

L'uso principale che viene fatto di tale sistema informativo è quello diinterrogare una base di dati di carattere generale, che contiene informazioni suhost ad accesso libero presenti nella rete; il risultato dell’interrogazione è unalista di indirizzi, presso i quali è possibile reperire le informazioni oggetto dellaricerca.

WAIS (WIDE AREA INFORMATION SERVER)WAIS è un sistema per il recupero di informazioni distribuite nella rete;

esso aiuta l'utente nella ricerca sulle basi di dati presenti in Internet. Leinformazioni contenute in tali basi di dati sono generalmente di tipo testo, mapossono contenere anche suoni, immagini e filmati, con un vasto campo diapplicazioni.

L'organizzazione di tali basi di dati varia a seconda dell'ente che gestisceun particolare WAIS, mantenendo comunque una semplice interfaccia d'utente,al quale vengono mascherate le differenze. Tali interfacce fanno usogeneralmente del linguaggio naturale, mediante il quale è possibile impostaretutti i parametri necessari alla ricerca.

L'architettura del servizio è strutturata in modo tale che, a seguito di unaricerca avviata dall'utente, il centro servizi a cui tale utente è collegato si

19

incarica di attivare le opportune operazioni di ricerca sulle basi di datiselezionate, eventualmente remote. Il risultato di tale ricerca si concretizza in uninsieme di documenti, che contengono le stringhe oggetto della ricerca con irelativi riferimenti necessari per il recupero degli stessi attraverso la rete.

WHOISIl servizio Whois fornisce un sistema di directory elettronico per gli utenti

registrati nella rete Internet. Fornisce cioè i mezzi per l'identificazione diindirizzi di posta elettronica, indirizzi postali e numeri telefonici.

La base di dati principale con le informazioni generali sulla rete(organizzazioni, siti, reti, persone, etc. ) è gestito da un ente denominato"INTERnet Network Information Center” (INTER-NIC). Allo stato attuale, inomi dei gestori dei domini registrati sono automaticamente introdotti nellabase di dati quando le autorità di coordinamento della rete Internet concedonouna numerazione specifica di rete (indirizzo IP).

L'accesso ai vari server Whois attualmente presenti in rete è reso possibileo attraverso sessioni interattive Telnet con siti opportuni, o facendo uso diappositi programmi applicativi.

In aggiunta a tali modalità di accesso INTER-NIC offre per le proprie basidi dati un'interfaccia di tipo E-mail, per consentire l'accesso anche a quellafascia di utenza che è dotata soltanto di posta elettronica, o che non appartienealla rete Internet.

LISTSERVListserv è un’applicazione per la gestione di liste distribuite che permette a

gruppi di utenti con interessi comuni di comunicare tra loro tramite postaelettronica, realizzando al tempo stesso un uso efficiente delle risorse di rete.

La funzione principale di Listserv è quella di operare su liste di indirizzi(mailing list), ossia di realizzare la distribuzione di posta elettronica ad ungruppo di utenti stabilendo un vero e proprio forum di utenti su argomenti diinteresse comune. Tale tipo di servizio è utile per lo scambio di idee e diinformazioni poiché è la stessa applicazione Listserv che si incarica direcapitare a tutti i partecipanti alla mailing list l’informazione inviata da un suoutente, evitando così a quest’ultimo la replica e l’invio dello stesso messaggio atutti i componenti della lista.

Listserv fornisce inoltre gli strumenti per effettuare monitoraggio edarchiviazione del traffico di posta elettronica, funzioni di file server e ricerca diarchivi in basi di dati.

20

NEWSNetnews o Usenet o News è un’applicazione per la condivisione di

messaggi che permette di scambiarli elettronicamente usando un formatostandard.

I messaggi scambiati su Netnews sono organizzati per argomentiall’interno di categorie chiamate newsgroup. I messaggi possono contenere siaesclusivamente testo che informazioni binarie codificate; possono contenereanche intestazioni informative sul mittente, su quando e dove il messaggio èstato messo in rete, dove è transitato ed altre informazioni amministrative.

Esistono oggi migliaia di categorie newsgroup riguardanti i più svariatiargomenti. Il contenuto dei messaggi scambiati nei newsgroup non è in genereregolamentato, anche se qualche newsgroup ha un moderatore che esamina imessaggi prima che siano distribuiti e decide quali siano appropriati per ladiffusione.

La componente client di News è chiamata “news reader” ed utilizza ilprotocollo NNTP (Network News Transfer Protocol) per ricevere informazionida opportune basi di dati.

III� Architettura e protocolli

L’organizzazione di questo capitolo è la seguente. Dapprima vengonopresentate alcune problematiche riguardanti una generica inter-rete ed il ruolosvolto in tale struttura dai sistemi deputati ad interconnettere reti diverse (par.III.1). Di seguito sono trattate la struttura (par. III.2) e l’architettura protocollaredi Internet (par. III.3). Il successivo paragrafo è dedicato al protocollo IP (par.III.4). Il paragrafo III.5 discute in generale i protocolli di strato 4, mentre glispecifici protocolli di questo strato, ovvero UDP e TCP sono espostirispettivamente nei par. III.6 e III.7. Una breve presentazione dei protocolli digestione usati in Internet conclude il capitolo (par. III.8), mentre si ricorda che irelativi protocolli applicativi sono stati discussi nel (par. II). Nel corso di questocapitolo cercheremo di presentare le modalità di funzionamento di Internetsecondo delle opportune strutture logiche, al fine di dare una certa sistematicitàall’esposizione. Avvertiamo però che alcuni aspetti di Internet, a causa delmodo in cui questa infrastruttura si è evoluta, sfuggono ad un inquadramento inparadigmi ben definiti e, pur nel rispetto dei protocolli, sono possibili numeroseeccezioni e soluzioni alternative ad una data modalità di funzionamento.

21

III.1� Architetture di interconnessione

In questo paragrafo vengono presentate le possibilità connesse allarealizzazione di infrastrutture costituite dalla interconnessione di diverse reti traloro non omogenee e quindi caratterizzate da diverse architetture protocollari(cfr. § I). All’insieme degli elementi utilizzati in questa interconnessione siattribuirà nel seguito il termine inter-rete. Le reti individuali ed omogenee alloro interno che compongono una inter-rete saranno denominate sotto-reti; aqueste sono collegati dei calcolatori, denominati host.

La trattazione presentata nei capitoli precedenti ha riguardatoprevalentemente le modalità relative allo scambio di informazioni tra sistemiappartenenti alla stessa rete. Realizzare una inter-rete significa invececonsentire uno scambio di informazioni tra sistemi appartenenti a sotto-retidiverse.

Affinché ciò sia possibile occorre soddisfare diversi requisiti. Il primorequisito è che le sotto-reti siano fisicamente connesse tra loro, mediante unopportuno collegamento. Tuttavia la connessione fisica è necessaria ma nonsufficiente. Per trasferire una generica unità informativa da una sotto-rete adun’altra occorre interporre tra le sotto-reti in questione un opportunodispositivo, denominato sistema di interconnessione. Tale dispositivo, oltre asvolgere, eventualmente, funzioni legate al trattamento del segnale fisico chetrasporta l’informazione, quali ad esempio amplificazione o ri-generazione delsegnale stesso, deve anche svolgere delle funzioni di natura logica. Tra questeultime funzioni vi è, in generale, quella di determinare quali unità informative,tra tutte quelle che possono transitare per un dato sistema di interconnessione,abbiano necessità di essere inoltrate verso una data sotto-rete. In altre parole unsistema di interconnessione deve svolgere anche funzioni di instradamento.

Un sistema di interconnessione consiste di un calcolatore dotato di unopportuno software e di due o più interfacce fisiche, a seconda del numero disotto-reti che esso pone in corrispondenza; ogni interfaccia fisica deve esserecompatibile con la sotto-rete verso cui si affaccia. La Fig. 2 mostra un esempioin cui il sistema di interconnessione G mette in corrispondenza le sotto-reti 1 e2. Se la sotto-rete 1 fosse la rete telefonica e la sotto-rete 2 una LAN Ethernet,l’interfaccia fisica verso la sotto-rete 1 sarebbe un modem, collegato medianteun doppino ad una centrale telefonica, mentre l’interfaccia fisica verso la sotto-rete 2 sarebbe una scheda Ethernet, collegata mediante un cavo (coassiale RG58o doppino RJ45) al bus della LAN. Il sistema G dovrà acquisire le unitàinformative provenienti dalla LAN e dirette a sistemi connessi alla retetelefonica e trasferirle a quest’ultima; dovrà compiere anche l’operazione

22

inversa.

GSotto-rete 1 Sotto-rete 2

Interfaccia fisicaverso la sotto-rete 1

Interfaccia fisicaverso la sotto-rete 2

Interfaccia fisicaverso un’altra sotto-rete

Fig. 2 - Esempio di interconnessione di due sotto-reti

La differenza tra due sotto-reti può essere più o meno accentuata. Adesempio, con riferimento all’architettura OSI, due sotto-reti possono avere glistessi protocolli di strato di applicazione, presentazione, sessione e trasporto madifferire nei protocolli di rete, collegamento e fisico, ovvero esserecompletamente diverse a partire dallo strato fisico. I sistemi di interconnessionedevono realizzare una “traduzione” dei protocolli di una sotto-rete neicorrispondenti protocolli di un’altra sotto-rete ogni qualvolta dei protocollicorrispondenti differiscano tra loro.

Se si vogliono interconnettere due sistemi che presentano architettureprotocollari diverse fino ad un certo strato N, essendo poi i protocolli deglistrati di livello superiore ad N uguali tra loro, il sistema di interconnessionedeve tradurre tutti i protocolli di livello minore o uguale a N. Una possibileclassificazione dei sistemi di interconnessione è basata sul livello protocollarepiù alto a cui essi operano la traduzione dei protocolli, ovvero N.

La relativa nomenclatura è la seguente:repeater: agisce a livello di strato 1; estende il carattere fisico della

sotto-rete, può operare una conversione di mezzi ditrasferimento (rame-fibra), ma non migliora le limitazioni didistanza dovute alle caratteristiche dei protocolli usati;

bridge: opera a livello di strato 2 (più spesso allo strato MAC). Il pianodi indirizzamento (cfr. par. III.4.3) deve essere comune a tutte lesotto-reti interconnesse con questi sistemi;

LLC-Switch: opera a livello di strato LLC; diversi protocolli di strato MACpossono essere attivi all'interno di ognuna delle LANinterconnesse con questi sistemi;

router: agisce a livello di strato 3, utilizzando opportuni indirizzi distrato di rete definiti con una significatività che si estende

23

all’insieme delle sotto-reti interconnesse;gateway: può convertire i protocolli di tutti gli strati fino a quello di

applicazione.

È ovvio che, al salire nella gerarchia OSI, le funzioni da svolgerediventano più complesse e quindi il sistema di interconnessione diviene piùcostoso e meno veloce nell’eseguire le sue funzioni.

Se si vuole realizzare una inter-rete, i sistemi di interconnessione chebisognerà usare dovranno realizzare una traduzione dei protocolli almeno finoallo strato di rete incluso. Infatti, una inter-rete si propone di interconnetteresotto-reti diverse e, in generale, le sotto-reti da interconnettere sono diversealmeno fino allo strato 3. La necessità di terminare i protocolli fino allo strato 3deriva dal fatto che le funzioni di indirizzamento e di instradamento sonoproprie di questo strato. D’altra parte quando si vuole realizzare una inter-rete,bisogna evidentemente essere in grado di indirizzare tutti i sistemi che fannoparte della inter-rete e di instradare l’informazione. Con riferimento allanomenclatura appena introdotta, i sistemi di interconnessione di una inter-retesaranno quindi dei router o dei gateway.

Per entrare nel merito delle funzioni di natura logica svolte da un sistemadi interconnessione, occorre prenderne in esame l’architettura protocollare.Consideriamo due host, A e B connessi rispettivamente alle sotto-reti 1 e 2;assumiamo che queste due sotto-reti abbiano diversi protocolli di strato fisico,di collegamento e di rete e che esse siano interconnesse da un sistema diinterconnessione G. Ipotizziamo anche, per semplicità, che gli host in questioneadottino, in tutti gli strati, una modalità di trasferimento senza connessione. LaFig. 3 mostra tale esempio; in questa figura si denota ogni strato con il numeroche lo contraddistingue nel modello di riferimento OSI e si aggiunge, adognuno dei sotto-sistemi dei primi tre strati, un numero che contraddistingue lasotto-rete a cui il sotto-sistema stesso appartiene. Infine si assume che iprotocolli di strato 4 e degli strati applicativi siano uguali nei due host e chequindi per questi ultimi non vi sia bisogno di funzioni di “traduzione”. Secondola nomenclatura di cui sopra, G è quindi un router.

24

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Percorsoseguito da X

Fig. 3 – Esempio di architettura di sistema di interconnessione

Come si vede dalla Fig. 3, il sistema di interconnessione G è caratterizzatodalla presenza di due pile protocollari, una compatibile verso la sotto-rete 1 el’altra compatibile verso la sotto-rete 2. Ciò è ovviamente necessario perconsentire lo scambio informativo tra A e G da una parte e tra G e B dall’altra.Si ricorda infatti che due sistemi possono scambiarsi informazione solo seutilizzano lo stesso protocollo per ognuno degli strati coinvolti. Con questepremesse si può discutere la modalità di funzionamento di G.

Consideriamo una unità di dati (PDU), X, generata da una entità dellostrato applicativo di A. L’ unità di dati X attraversa la pila protocollare di A,partendo dallo strato applicativo ed arrivando allo strato fisico; ognisotto-sistema attraversato esplica le sue funzioni ed aggiunge ad Xl’informazione di protocollo (PCI) tipica dello strato a cui il sotto-sistemaappartiene (nella Fig. 3 il percorso seguito da X è rappresentato con una lineatratteggiata; si vedano anche le relazioni tra unita' di dati in strati adiacenti,esposte ad es. in [ROV95]). L’unita X, accresciuta delle informazioniprotocollari di cui sopra, perviene, attraverso la sotto-rete 1, al sistema G.Questi termina i protocolli dei primi tre strati (lato sotto-rete 1), svolgendone lerelative funzioni fino ad estrarre dal flusso informativo ricevuto l’unità di datidi strato 4 (PDU), come questa era stata emessa da A (a meno di errori). Aquesto punto G si deve far carico di inviare tale unità di dati di strato 4 (che

25

contiene quella di strato applicativo, X) al sistema di destinazione B.A tal fine G non può che usare i protocolli tipici della sotto-rete 2; G

provvede quindi ad incapsulare la unità di dati di strato 4 nella unità di dati distrato 3 (lato sotto-rete 2) ed esegue le normali funzioni protocollari relative allasotto-rete 2, facendo così pervenire la unità di dati originaria, X, al sistema B.Questa volta X sarà incapsulata in unità di dati tipiche della sotto-rete 2 e quindiB potrà terminare tutti i protocolli coinvolti e consegnare all’utente finalel’informazione originale contenuta in X.

L’operazione di “passaggio” da una pila protocollare all’altra, all’internodi G, è indicata graficamente in Fig. 3 da un sotto-sistema con due segmentidiagonali.

Quanto detto non esaurisce però le funzioni che devono essere svolte daisistemi coinvolti. Rimangono infatti da affrontare le questioni relativeall’indirizzamento ed all’instradamento. Nell’esempio sopra riportato sivolevano interconnettere due diverse sotto-reti. In generale due sotto-reti sonocaratterizzate non solo da diversi algoritmi di instradamento ma anche dadiversi piani di indirizzamento (cfr. par. III.4.3 e III.4.5).

Si consideri la seguente esemplificazione, avente scopo esclusivamentedidattico: la rete telefonica usa come indirizzi i ben noti numeri telefonici,mentre una LAN Ethernet usa come indirizzi delle stringhe di 48 bit (spessorappresentati con 12 caratteri esadecimali). E’ allora evidente che, se si vuoleinviare un generico messaggio ad un sistema B connesso ad una Ethernet,inviandoglielo a partire da un sistema A connesso alla rete telefonica, sorgonodei problemi: il sistema B è caratterizzato da un indirizzo di 48 bit, ma la sotto-rete di origine accetta come indirizzi destinatari solo numeri telefonici.

Una possibile soluzione è la seguente. Il sistema di interconnessione G,che pone in corrispondenza le due sotto-reti in esame, disporrà di due interfaccefisiche e quindi di due indirizzi, ognuno relativo alle due sotto-reti cheinterconnette. Sarà perciò indirizzato nell’ambito della sotto-rete telefonica daun numero di telefono e nell’ambito della sotto-rete Ethernet da una stringa di48 bit.

Si assuma che l’utente che origina il messaggio conosca non solol’indirizzo del destinatario finale B (una stringa di 48 bit) ma anche l’indirizzo(telefonico) del sistema di interconnessione G, collegato alla sotto-rete didestinazione.

L’utente in A invierà il messaggio non direttamente a B, ma a G. Ciò èpossibile dal momento che:

- sia A che G sono connessi alla stessa sotto-rete;- A conosce l’indirizzo telefonico di G;

26

Nel contempo A dovrà anche comunicare a G che il messaggio che gli stainviando non è diretto a G stesso, ma ad un altro sistema B, fornendogli quindianche l’indirizzo di destinazione finale (di tipo Ethernet) di B. In tal modo G èin grado, una volta ricevuto il messaggio, di rilanciarlo verso il sistema didestinazione, poiché ne conosce l’indirizzo nell’ambito della sotto-rete diappartenenza.

Questo modo di operare risolve il problema ma presenta diversi svantaggi:- il mittente deve conoscere l’indirizzo (Ethernet) di B e ciò è ragionevole,

anche se in tal modo è costretto ad usare una tipologia di indirizzi diversa daquella propria. In aggiunta deve però anche conoscere l’indirizzo (telefonico)di G; si noti che disporre di quest’ultima informazione equivale a svolgerefunzioni di instradamento: l’utente di origine deve cioè conoscere la strada dafar percorrere all’informazione;

- qualora l’inter-rete non sia costituita da due sole sotto-reti, comenell’esempio di cui sopra, il compito del mittente diventa più arduo.

In quest’ultimo caso il mittente deve anche:- conoscere la sequenza di sistemi di interconnessione che porta dalla sua

sotto-rete di origine a quella di destinazione (qualora ve ne sia più di uno);- conoscere le coppie di indirizzi con cui ogni sistema di interconnessione è

caratterizzato nell’ambito delle sotto-reti che interconnette e che il messaggioin questione deve attraversare;

- inviare al sistema di interconnessione che viene per primo nella sequenza dicui sopra le coppie di indirizzi relativi a tutti i sistemi di interconnessione chesi trovano a valle del primo (e che il messaggio in questione deveattraversare);

Ogni sistema di interconnessione nella sequenza di cui sopra dovrà poirilanciare verso il sistema di interconnessione che si trova a valle rispetto adesso, sia il messaggio che le coppie di indirizzi relativi ai sistemi diinterconnessione che devono ancora essere percorsi dal messaggio stesso.

E’ evidente come, al crescere della dimensione della inter-rete, lasoluzione proposta diviene rapidamente molto complessa e soprattutto imponeun onere eccessivo agli utenti terminali. Si noti infine che questo modo dioperare richiede una modifica dei protocolli coinvolti (in tutti i sistemidell’inter-rete), necessaria, se non altro, per trasportare le informazioni diindirizzamento sopra descritte.

Avendo discusso le operazioni concettualmente necessarie per consentireuno scambio informativo in una inter-rete, si propone ora una soluzionealternativa al problema.

Si consideri la Fig. 4, che rappresenta la stessa situazione descritta nella

27

Fig. 3. Questa volta si è introdotto, al di sopra dello strato di rete, uno stratoaggiuntivo (con un relativo protocollo), comune a tutti i sistemi coinvoltinell’inter-rete e denominato PA. Lo scopo di questo protocollo è quello direalizzare, automatizzandole, tutte le funzioni sopra descritte, sollevando quindigli utenti terminali da tale compito. In particolare dovrà svolgere funzioni diinstradamento e quindi determinare una sequenza di sistemi di interconnessioneche porti da origine a destinazione.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Fig. 4 – Esempio di architettura di sistema di interconnessione, nel caso di adozione di unprotocollo aggiuntivo e comune a tutti i sistemi coinvolti

In aggiunta, nel realizzare una inter-rete, si preferisce definire un nuovopiano di indirizzamento, aggiuntivo a tutti quelli relativi alle varie sotto-retiinterconnesse. In tal modo ogni host connesso alla inter-rete è caratterizzato dadue indirizzi: uno che ha significatività nell’ambito della sotto-rete diappartenenza (indirizzo locale) ed uno che ha significatività globale in tuttal’inter-rete (indirizzo globale). Ogni sistema di interconnessione sarà invececaratterizzato da tante coppie di indirizzi quante sono le sue interfacce fisiche.

Con questo modo di operare, gli host connessi alla inter-rete sonoraggiungibili mediante un’unica tipologia di indirizzi (quella globale). Se, adesempio, a partire da un host connesso alla rete telefonica, si vuole raggiungereun host anch’esso connesso alla rete telefonica si potrà usare sia l’indirizzo

28

globale che quello locale (il numero telefonico). Ma se si vuole raggiungere unhost connesso ad un’altra sotto-rete si userà l’indirizzo globale, a prescinderedalla particolare sotto-rete di destinazione.

Compito del protocollo PA è anche quello di gestire questo piano dinumerazione aggiuntivo. In particolare sarà necessario che PA, o degli altriprotocolli di supporto, riescano a determinare quale indirizzo locale corrispondead un dato indirizzo globale e viceversa, sollevando così gli utenti finali daun’altra delle funzioni che gli erano state attribuite nella prima soluzioneproposta.

Un’ultima considerazione riguarda la scelta della modalità di trasferimentoda adottare per PA: con connessione o senza?

Ambedue le scelte presentano dei pro e dei contro. Si riprenda in esame laFig. 4. Se PA è con connessione, le funzioni che i sistemi di interconnessionedevono svolgere sono più complesse. Infatti quando un host A vuole instaurareuna connessione a strato PA, dovrà farne richiesta prima a G e non direttamentea B; G dovrà elaborare tale richiesta, eventualmente accettarla, per il tratto cheva da A a G, e chiedere a B di accettare una connessione da G a B. Laconnessione da estremo a estremo risulta quindi dalla concatenazione di diverseconnessioni componenti. La connessione da A a G dovrà soddisfare i requisitiprestazionali posti da A in termini, ad esempio, di portata e di ritardo massimo.Dovrà quindi essere cura di G far si che anche la tratta da G a B soddisfi glistessi requisiti, affinché sia poi l’intero collegamento da estremo a estremo agodere delle prestazioni volute da A. Si noti che G potrebbe non riuscire asoddisfare i requisiti posti da A, anche nel tratto da G a B, e quindi potrebbeessere forzato a rifiutare la richiesta di A.

Se, viceversa, PA opera in modalità senza connessione, il compito di G èpiù semplice. G tratterà le unità informative in arrivo da A, una per volta, inmodo indipendente l’una dall’altra, e non dovrà porsi il problema di soddisfaredeterminati requisiti relativi ad una connessione, giacché quest’ultima nonesiste. Se la sotto-rete 2 diviene indisponibile a causa di un guasto, G puòcercare una strada alternativa per raggiungere B, senza preoccuparsi dire-instradare le connessioni già instaurate, cosa che avrebbe dovuto farenell’ipotesi precedente.

La seconda ipotesi è di più semplice realizzazione ma ha due svantaggisignificativi:

- non è possibile garantire che lo scambio informativo tra A e B avvenga inaccordo a determinate caratteristiche prestazionali (portata, ritardo, perdita diinformazione);

- la funzione decisionale relativa all’instradamento deve essere svolta per ogni

29

unità informativa che attraversa G; al contrario, nell’alternativa conconnessione, la decisione su quale strada far percorrere all’informazioneveniva presa solo una volta, durante la fase di instaurazione. Poiché lafunzione di instradamento è abbastanza complessa ed è tipicamente realizzatain software, invece che in hardware, la modalità senza connessione impone aisistemi di interconnessione delle limitazioni in termini di portata.

In altri termini, adottando la modalità senza connessione, un sistema diinter-connessione deve svolgere compiti più semplici ma deve eseguirli unnumero più elevato di volte, rispetto all’alternativa con connessione.

Un protocollo che realizza le funzioni sinora genericamente attribuite a PAè il protocollo IP, adottato in Internet. Si rimanda perciò al par. III.4, permaggiori dettagli inerenti il modo di operare di un simile protocollo. Qui si fanotare solo che IP è un protocollo senza connessione; si può quindi ora capiremeglio quanto affermato nel § I. La modalità senza connessione di IP ne hadeterminato la semplicità implementativa ed ha significativamente contribuitoallo sviluppo di Internet, ma è la causa degli inconvenienti attuali di questa rete:limitazioni in termini di portata ed assenza di garanzie sulle prestazionipercepite dagli utenti.

Per concludere la descrizione delle modalità generali di funzionamento diuna inter-rete, si fa notare che ogni sistema di inter-connessione deve disporredi opportune informazioni riguardanti la topologia dell’inter-rete. Taliinformazioni sono quelle necessarie a svolgere la funzione di instradamento ecioè determinare quale strada far seguire ad una data unità informativa affinchéquesta giunga alla destinazione voluta. A titolo di esempio, si consideri la inter-rete rappresentata in Fig. 5. Con riferimento alle unità informative generatedalla sotto-rete 1, il sistema di inter-connessione G1 deve trasferire allasotto-rete 2 sia le unità informative dirette alla sotto-rete 2 stessa, sia quelledirette alla sotto-rete 3; deve quindi essere “a conoscenza” anche dell’esistenzadella sotto-rete 3, a cui non è direttamente connesso.

G1Sotto-rete1

G2Sotto-rete2

Sotto-rete3

Fig. 5 - Esempio di interconnessione di tre sotto-reti

La complessità dei sistemi di inter-connessione può essere limitataadottando la seguente modalità di instradamento (applicata in Internet):

30

I sistemi di inter-connessione instradano le unità informative soloverso la sotto-rete di destinazione e non verso il singolo host didestinazione; una volta che un’unità informativa arriva allasotto-rete di destinazione saranno i protocolli propri di questasotto-rete ad instradarla verso lo specifico host di destinazione.L’algoritmo di instradamento operante nei sistemi di inter-connessione determina solo la sequenza dei sistemi di inter-connessione da attraversare e non quella di tutti i sistemi di ognisotto-rete.

In tal modo la quantità di informazioni, relative alla funzione diinstradamento, che un sistema di inter-connessione deve elaborare per fararrivare un generico messaggio a destinazione è proporzionale al numero disotto-reti che costituiscono l’inter-rete e non al numero degli host ad essaconnessi. Tale modalità di funzionamento corrisponde dunque ad un algoritmodi instradamento di tipo gerarchico (cfr. [BLE]).

III.2� Struttura

Internet è una particolare inter-rete costituita dall’interconnessione di retieterogenee. Da quanto esposto nel par. III.1, si evince che una inter-rete è unainfrastruttura il cui elemento distintivo è rappresentato dall’insieme diprocedure di inter-lavoro (protocolli) necessarie per interconnettere lereti-componenti e per permettere quindi ai calcolatori a queste connessi dicolloquiare tra loro secondo quanto richiesto dai processi applicativi in essoresidenti.

Nel seguito, quando ci si riferirà in modo indifferenziato ad un host o adun router si userà il termine generico di “sistema”.

I sistemi connessi ad Internet comunicano tra loro impiegando un insiemedi protocolli comuni a cui ci si riferisce con il termine "Internet Protocol Suite";i protocolli più conosciuti ed importanti al suo interno sono TCP (TransmissionControl Protocol, di strato 4) e IP (di strato 3). Tali protocolli rappresentano labase comune per lo scambio delle informazioni tra le varie sotto-reti. La dizione“rete TCP/IP” identifica una rete che operi in accordo a tali protocolli, sia essauna sotto-rete o una inter-rete; Internet è quindi anche definibile come una reteTCP/IP. Inoltre, per brevità, nel seguito si farà riferimento alla Internet ProtocolSuite con la dizione TCP/IP.

La struttura generale di Internet presenta i seguenti elementi distintivi:- ogni sotto-rete utilizza protocolli di strato fisico, di collegamento e di rete

31

che sono in generale diversi da quelli usati da altre sotto-reti, fermo restandoil fatto che ogni sotto-rete sia omogenea al suo interno;

- grazie a tali protocolli gli host che appartengono ad una data sotto-retepossono scambiare informazioni con host appartenenti alla stessa sotto-rete(ma non con host connessi ad altre sotto-reti); ad esempio gli host connessiad una rete ATM, adottano gli omonimi protocolli e possono scambiareinformazioni solo con host connessi alla rete ATM; un apparecchiotelefonico può raggiungere solo un altro analogo apparecchio connesso allastessa rete telefonica;

- le sotto-reti componenti Internet sono interconnesse tramite sistemi di inter-connessione operanti a livello di strato di rete e quindi denominati “router”(si noti che fino a qualche tempo fa la comunità Internet usava la dizione“gateway” per tali dispositivi; tale dizione è ora in disuso e noi seguiremo lanomenclatura introdotta nel par. III.1);

- in alcuni o eventualmente in tutti gli host di una data sotto-rete possonoessere implementati i protocolli della Internet Protocol Suite; ovvero aiprotocolli tipici di una data sotto-rete si aggiungono i protocolli TCP/IP,senza modificare i protocolli pre-esistenti; tali host, denominati host IP nelseguito, possono scambiare informazioni con qualsiasi altro host IPappartenente sia alla stessa sotto-rete che alle altre sotto-reti interconnesse;

- si identificano inoltre con il nome di “host non IP” quegli host che, purdisponendo dei protocolli necessari per scambiare informazioni con host aloro omogenei e quindi connessi alla stessa sotto-rete, non sono dotati deiprotocolli della Internet Protocol Suite;

- ogni host dispone, in generale, di una interfaccia fisica ed è caratterizzato dauna coppia di indirizzi, uno locale ed uno globale; un router dispone di due opiù interfacce fisiche, tante quante sono le sotto-reti che esso pone incorrispondenza ed è caratterizzato da tante coppie di indirizzi (locali eglobali) quante sono le sue interfacce fisiche.

- siccome un host ha, in generale, una sola interfaccia di rete non deve decidereverso quale interfaccia inviare un dato datagramma. Viceversa un routerdispone per definizione di più interfacce di rete (ovvero di diversicollegamenti verso altre sotto-reti) e deve perciò necessariamente scegliereverso quale di queste inviare una certa unità di dati. Esso svolge cioè le stessefunzioni logiche che, in altre reti di telecomunicazioni (ed anche all’internodi alcune sotto-reti che costituiscono Internet), sono svolte da sistemidenominati commutatori. A parte la differenza di nomenclatura, un routerinfatti non è altro che un commutatore, anche se, per principi architetturali etecnica costruttiva è alquanto diverso da, ad esempio, un commutatore

32

telefonico.La Fig. 6 mostra esemplificativamente tale struttura. La "nuvola" più

grande rappresenta Internet; gli host IP (utilizzati dagli utenti di Internet) sonorappresentati al di fuori di tale nuvola per evidenziare il fatto che Internetappare ad essi come un’unica rete; tali utenti non “vedono” la complessitàsottostante e possono ignorare i dettagli e la topologia di rete. In tal modo è piùsemplice derivare un modello astratto delle comunicazioni e sviluppare leapplicazioni di rete. Il software applicativo è indipendente da quello di rete edambedue possono essere migliorati e modificati in modo indipendente.

sotto-rete6

��

host IP

host IP

host IPhost IP

host IP

host non IP

host non IP

host non IP

sotto-rete1 sotto-rete

2

sotto-rete3

sotto-rete4

sotto-rete5

Router

Router

Router

RouterRouter

Router

host IP

Fig. 6 - Struttura esemplificativa di Internet

Gli host non-IP sono invece rappresentati all’interno della nuvola inquanto essi possono comunicare solo con utenti connessi alla loro stessasotto-rete ed a questi omogenei. Si noti anche come non è necessario che unadata sotto-rete sia connessa direttamente, tramite un router, a tutte le altre sotto-reti. Il traffico proveniente da una sotto-rete e destinato ad un’altra sotto-reteattraversa, in generale, diverse sotto-reti intermedie. I router non consentono, ingenerale, connessioni dirette tra due qualsivoglia sotto-reti che costituisconoInternet. Ogni entità che costituisce Internet contribuisce quindi al trasferimento

33

dell’informazione, realizzando anche funzioni che in altre infrastrutture ditelecomunicazioni sono tipiche dei gestori di rete.

Un altro concetto importante è che, dal punto di vista di Internet, ognisistema di comunicazione capace di trasferire informazione appare come unasingola sotto-rete in modo non dipendente dalle sue caratteristiche e prestazioni(protocolli, dimensione delle unità informative, scala geografica, velocità ditrasferimento, ritardo, grado di trasparenza temporale, integrità informativa,portata, etc.). La Fig. 6 rappresenta infatti in modo indifferenziato tutte lesotto-reti che compongono Internet, poiché i protocolli TCP/IP le trattano allostesso modo, nonostante le loro differenze:

i protocolli TCP/IP trattano tutte le sotto-reti in modo uguale; unarete in area locale, una rete in area metropolitana, una retegeografica, una connessione punto-punto dedicata, ognuno di questisistemi di comunicazione è visto da Internet come una singolasotto-rete.

III.3� Architettura Protocollare

L’architettura protocollare di Internet è rappresentata nella Tab. 1. Lanumerazione degli strati nella prima colonna stabilisce una corrispondenza trastrati del modello OSI e protocolli Internet. Lo strato 3 è stato diviso insotto-strati mentre non è stata individuata una corrispondenza tra gli stratisuperiori al 4 del modello OSI ed i relativi protocolli Internet. Infatti,nell’ambiente Internet, i protocolli di strato superiore al 4 sono denominatiServizi Applicativi e le loro funzioni non sono divise in termini di strato disessione, presentazione ed applicazione (cfr. par. II). I servizi di applicazioneutilizzano, a loro scelta, i protocolli di strato di trasporto disponibili.

34

Strati Protocolli

Application Services:

TELNET SMTP FTP

TFTP RIP TALK

DNS X-Window NFS

5-7 WWW GOPHER ARCHIE

WAIS WHOIS News

Listserv SNMP

etc.

CMOT

4 TCP UDP

3c IP ICMP

3b ARP/RAR

P

3a Ad es. X.25 strato 3, SNA, DECnet, etc.

•2 Ad es. X.25 strato 2, 802.2, 802.3, 802.4 etc.

1 Strato fisico

Tab. 1 - Architettura protocollare di Internet

Tutti gli strati inferiori a IP, da 3a compreso in giù, sono considerati comestrato di accesso alla rete e sono trattati indifferentemente dalla InternetProtocol Suite (e rappresentati con sfondo grigio). Tali protocolli sono quellitipici di una data sotto-rete; un host non-IP dispone solo di questi protocolli e diquelli applicativi. Un host non IP diviene host IP quando ai protocolli appenamenzionati si aggiungono quelli della Internet Protocol Suite. TCP/IP èlogicamente situato al di sopra dei protocolli di rete delle sotto-retiinterconnesse.

La Internet Protocol Suite riesce a inter-connettere tutti i tipi di sotto-retegrazie alla sua modalità di funzionamento. Infatti, essa assume solo che ognunadelle sotto-reti interconnesse sia capace di trasferire informazione, senzarichiedere particolari prestazioni; quindi implementa tutte le funzioni tipichedegli strati 2, 3 e 4: controllo di errore, indirizzamento, instradamento,frammentazione e ri-assemblaggio delle unità informative. Se alcune o tuttequeste funzioni non erano state svolte da una particolare sotto-rete, TCP/IP lerealizza; se erano già state svolte le duplica, realizzandole nuovamente; ciòconduce ad eventuali inefficienze ma consente di non imporre alcun vincolosulla tecnologia e sui protocolli delle sotto-reti che interconnette.

35

Come ovvia conseguenza la velocità di trasferimento delle informazioni, igradi di trasparenza temporale e di integrità informativa nonché tutte le altreprestazioni di rete sono fortemente legate alla tecnologia ed alla tipologia dellesotto-reti su cui TCP/IP si appoggia.

Il protocollo IP tratta ciascuna unità informativa come un messaggioindipendente da tutti gli altri; non esistono pertanto, in questo strato, i concettidi connessione e di circuito logico; il protocollo IP è senza connessione. Iltrasferimento delle unità informative può richiedere una segmentazione dellestesse laddove le dimensioni delle unità informative gestite dalle sotto-reti sianoinferiori alle dimensioni massime consentite alle unità informative di TCP/IP. Atale scopo IP fornisce un meccanismo specifico per la segmentazione ed il ri-assemblaggio delle proprie unità informative.

Il livello di trasporto viene realizzato, in alternativa, mediante i protocolliTCP e UDP. TCP offre un servizio affidabile orientato alla connessione. Questaaffidabilità viene raggiunta senza che TCP imponga vincoli ai protocolli su cuisi appoggia. Infatti è stato progettato per funzionare anche sfruttando unservizio di trasferimento di strato di rete a datagramma e potenzialmenteinaffidabile (come IP). TCP può operare su di un ampio spettro di piattaformecomunicative, dalla semplice connessione dedicata alla commutazione dicircuito o di pacchetto. Trasferisce un flusso informativo continuo ebi-direzionale. TCP può sopperire a problemi di danneggiamento, perdita,duplicazione e consegna fuori sequenza dei dati. TCP implementa anche uncontrollo di flusso che consente di adeguare il volume dei dati trasmesso allereali capacità di ricezione e di invio dei processi TCP coinvolti nelle retiattraversate (mediante un meccanismo a finestra variabile).

Si noti infine che una data sotto-rete componente Internet può adottarecome protocolli propri di strato di rete e di trasporto rispettivamente IP e TCP.In tal caso gli host ad essa appartenenti sono già host IP e quindi possonocolloquiare con altri host IP connessi ad Internet, una volta che la sotto-rete inesame sia interconnessa ad altre sotto-reti in accordo ai principi sopra espressi.

Nel seguito del paragrafo si esporranno brevemente le caratteristicheprincipali dei protocolli usati nell’architettura Internet negli strati 1-4, essendo iprotocolli applicativi già stati descritti nel par. II.

ARP e RARP (Address Resolution Protocol, Reverse Address ResolutionProtocol) sono protocolli di supporto. ARP è usato per determinare qualeindirizzo locale (che identifica un sistema nell’ambito della sotto-rete diappartenenza) corrisponde ad un dato indirizzo globale Internet (cfr. par. III.1).RARP esegue la procedura inversa. Le specifiche modalità di funzionamento di

36

ARP e RARP dipendono dalla particolare sotto-rete in cui operano. In altritermini, ogni tipo di sotto-rete usa dei particolari e diversi protocolli ARP eRARP.

Il protocollo RARP è utilizzato da sistemi privi di dispositivi dimemorizzazione di massa, per determinare, durante la fase di inizializzazione, ilproprio indirizzo IP a partire dal loro indirizzo locale (in tal caso l’indirizzolocale sarà fisicamente scritto, in hardware, nella loro interfaccia di rete). RARPassume che nella sotto-rete siano presenti uno o più RARP server a cui inviarela richiesta RARP. Il RARP server una volta ricevuta la richiesta rispondeinviando l’indirizzo IP cercato.

IP (Internet Protocol) è il principale protocollo di Internet e sarà descrittoin dettaglio nel par. III.4. Le sue funzioni possono riassumersinell’indirizzamento, nell’instradamento, nella frammentazione e nel ri-assemblaggio delle unità informative. In ricezione, lo strato IP consegna leproprie unità informative al protocollo di strato superiore a cui esse sonodestinate (ad. Es. TCP, UDP o ICMP).

ICMP (Internet Control Message Protocol) è un protocollo senzaconnessione utilizzato per risolvere eventuali situazioni anomale, comunicandoai sistemi coinvolti i problemi riscontrati; effettua inoltre semplici funzioni dicontrollo di flusso.

I messaggi di ICMP sono trasportati all'interno delle unità informative diIP (da questo punto di vista, ICMP è quindi logicamente situato al di sopra diIP). In caso di malfunzionamento della rete, ICMP provvede ad uno scambio dimessaggi fra i sistemi coinvolti per notificare l’errore o indicare le circostanzeinaspettate che causano il comportamento anomalo. Il destinatario di unmessaggio ICMP non è un programma applicativo od un utente ma è il processoche implementa il protocollo IP. In altre parole ICMP fornisce i mezzi per unoscambio di informazione tra un’entità IP di un sistema e la corrispondente entitàIP di un altro sistema. Da questo punto di vista, ICMP può essere consideratofunzionalmente situato al di sotto di IP e ciò giustifica la posizione di ICMPnella architettura protocollare rappresentata in Tab. 1, posto a fianco e aldisopra di IP. La funzione di ICMP è solo di notifica degli errori al sistema diorigine; ICMP non specifica le azioni che devono essere prese per rimediareagli errori ed ai malfunzionamenti; sarà poi il sistema di origine a porre inrelazione il particolare errore con il relativo programma applicativo ed adecidere cosa fare per correggere il problema.

Esempi di messaggi ICMP:

37

- Source Quench: inviato dal destinatario, interrompe l'emissione di unitàinformative da parte del mittente;

- Redirect: il destinatario segnala al mittente di re-instradare una particolareunità informativa verso un altro sistema;

- Echo: controlla se un possibile destinatario è attivo;- Destination Unreacheable: notifica il mittente della non-raggiungibilità di un

sistema.

TCP (Transmission Control Protocol) è descritto in dettaglio nel par. III.7.È un protocollo di strato 4, con connessione, controllo di errore, controllo diflusso, ri-ordinamento delle unità informative, indirizzamento di uno specificoutente all’interno di un host (utente in senso OSI).

Un host può essere utilizzato da più utenti o processi. Vedremo che ilprotocollo IP indirizza un host in modo globale. È quindi necessario ancheprecisare con quale specifico utente (processo) di un determinato host si vuolecomunicare. Di ciò si occupa TCP.

UDP (User Datagram Protocol) è descritto in dettaglio nel par. III.6; è unprotocollo di strato 4, molto più semplice di TCP; è senza connessione. Offreagli strati superiori un trasferimento non affidabile; la sua funzione principale èl’indirizzamento di uno specifico utente all’interno di un host. Opzionalmentefornisce un meccanismo per il controllo di errore, limitato alla rivelazione dierrori in ogni singola unità informativa (non necessaria se si attraversano retialtamente affidabili). È utilizzato prevalentemente da TFTP e RIP.

III.4� Il protocollo IP

Il protocollo IP è un protocollo di strato 3 e fornisce le seguentifunzionalità:

- definisce lo schema di indirizzamento;- definisce l’unità base per il trasferimento dei dati attraverso Internet e quindi

specifica il formato di tutti i dati che attraversano l’ inter-rete;- definisce la strada che un’unità di dati deve percorrere per arrivare a

destinazione;- specifica un insieme di regole che host e router devono seguire per

processare le unità informative; come e quando i messaggi di errore devonoessere generati e le condizioni che rendono necessario scartare un’unitàinformativa;

- definisce le modalità per la segmentazione e l'aggregazione delle unità di

38

dati; nel seguito il risultato dell'operazione di segmentazione verrà chiamato"frammento", termine che meglio aderisce a quello inglese usato in questocontesto (fragment).

Il principale servizio offerto da IP è il trasferimento di unità informative. Ilservizio è inaffidabile, senza connessione e basato sul paradigma del “best-effort” (la rete cerca di “fare del suo meglio”).

Il servizio è definito inaffidabile perché la consegna di un’unitàinformativa non è garantita. Questa può essere persa, duplicata, ritardata oconsegnata fuori sequenza. Il servizio non notifica queste condizioni né almittente né al destinatario. Il servizio è senza connessione e quindi ogni unitàinformativa è trattata in modo indipendente dalle altre e ognuna di esse puòseguire una strada diversa per arrivare a destinazione. Infine il servizio è detto“best-effort” perché fa del suo meglio per recapitare le unità informative, ma, incaso di malfunzionamenti, errori o congestione, la qualità di servizio offertapuò diminuire considerevolmente. In queste ultime situazioni IP sfrutta lefunzioni di ICMP per cercare di risolvere il problema.

Il seguito del paragrafo è diviso in otto parti. Nella prima si descrive ilformato dell’unità di dati; la seconda è dedicato alle modalità di segmentazionee di aggregazione delle unità di dati; la terza introduce lo schema diindirizzamento; la quarta spiega come gli indirizzi IP (globali, con unasignificatività che si estende a tutta l’inter-rete) sono posti in corrispondenzacon gli indirizzi locali. La quinta parte definisce le procedure perl’instradamento; la sesta si occupa dei messaggi di errore e di controllo (ovverodi ICMP). Nella settima parte si introduce il Domain Name System (DNS),ovvero un meccanismo che consente di associare ad ogni indirizzo IP un nome,più significativo per gli utenti e più semplice da ricordare e da utilizzare. IlDNS fornisce le procedure di traduzione da un indirizzo numerico ad un nome eviceversa; svolge delle funzioni che si possono paragonare a quelle diun’agenda telefonica. Infine nell'ultima parte si presentano degli esempi cheillustrano il funzionamento di alcune operazioni tipiche svolte durante unoscambio informativo in Internet.

III.4.1� Formato dell’unità di dati

Le unità di dati dello strato IP sono dette IP datagrammi o semplicementedatagrammi. Il datagramma è composto da una intestazione e da un campoinformativo che contiene i dati di utente. Il formato del datagramma IP èillustrato nella Tab. 2. Ogni riga contiene 32 bit. La lunghezza massima di undatagramma è di 65536 ottetti.

39

0 4 8 16 19 24 31

VERS HLEN SERVICE TYPE TOTAL LENGTH

IDENTIFICATION Flags FRAGMENT OFFSET

TIME TO LIVE PROTOCOL HEADER CHECKSUM

SOURCE IP ADDRESS (NET AND NODE, NOT USER)

DESTINATION IP ADDRESS (NET AND NODE, NOT USER)

OPTIONS PADDING

DATA

DATA

...

Tab. 2 - Formato del datagramma IP

I campi definiti in Tab. 2 hanno i seguenti significati e funzioni:

- Vers: (versione) versione del protocollo usata; grazie a talecampo è possibile che più versioni di IP operinocontemporaneamente; in tal modo si rendono piùsemplici la modifica ed i miglioramenti del protocollo

- HLEN: lunghezza dell'intestazione (specificata in parole di 32bit)

- Service type: (tipo di servizio) specifica parametri della qualità diservizio richiesti dall’utente: affidabilità, velocità ditrasferimento; nella definizione originale [RFC791], unsub-campo (di tre bit) con valori da 0 a 7 indical'importanza del datagramma; un sub-campo successivo ècomposto da tre bit che possono essere utilizzati perrichiedere particolari caratteristiche: D-bit (basso ritardo,“Delay”), T-bit (alta portata, “Throughput”), R-bit (altaaffidabilità, “Reliability”); i restanti due bit sono riservatiper usi futuri. In seguito il formato di tale campo è statomodificato dalla [RFC1349]: uno dei due bit riservati èstato aggiunto al secondo sub-campo di cui soprarisultando nella seguente semantica dei 4 bit seguenti iprimi tre (i quali continuano ad identificare l’importanzadi un datagramma in scale di priorità):- 1000 minimizzare il ritardo (delay)

40

- 0100 massimizzare la portata (throughput)- 0010 massimizzare l’affidabilità (reliability)- 0001 minimizzare il costo- 0000 servizio normale.Di fatto l’uso di tale campo è attualmente opzionale erisulta raramente tenuto in conto nelle implementazioni,in favore di una maggiore semplicità. Alcune recentiproposte ne rilanciano l’uso, proponendo di usarlo inmodo obbligatorio per lo meno in tutti i routerappartenenti ad una sezione di Internet che intenda offriretali funzionalità

- Total length: (lunghezza totale) (16 bit) specifica la lunghezza deldatagramma, misurata in ottetti, includendo l'intestazioneed i dati (2^16=65536 byte); la lunghezza di undatagramma è sempre uguale ad un multiplo di 4 byte

- Identification: (identificazione) (16 bit) numero del datagramma; è unvalore identificativo assegnato dal processo sorgente aldatagramma o ai suoi frammenti (un datagramma puòessere segmentato in unità più piccole, cfr. § III.4.2).Questo valore è fornito da un contatore dell'host sorgenteche viene incrementato ogniqualvolta l'host genera undatagramma. Ogni router che segmenta un datagrammaricopia questo campo nell'intestazione di ogni frammentodel datagramma di partenza

- Flags: (bandiere) è un campo di 3 bit: X, DF e MFX: non usato e posto al valore logico zeroDF: Don't Fragment; se uguale a 0 indica che ildatagramma può essere segmentato, se 1 noMF: More Fragment; se 0 indica che è l'ultimoframmento di un datagramma, se 1 che seguono altriframmenti

- Fragment Offset: (13 bit); posizione di un frammento all'interno deldatagramma originario; espresso in unità di 8 byte puònumerare 8192 frammenti; ciò implica ancora che lalunghezza massima di un datagramma è di 65536 ottetti,

41

e che la lunghezza di un frammento è sempre uguale adun multiplo di 8 byte. La segmentazione di undatagramma si rende necessaria quando almeno una dellesotto-reti attraversate ha una dimensione massima dellapropria unità di dati inferiore alla dimensione deldatagramma stesso (cfr. § III.4.2). I frammenti nonarrivano necessariamente a destinazione nello stessoordine in cui sono stati emessi; se uno o più frammenti diun dato datagramma non viene ricevuto, verrà scartatol'intero datagramma

- Time to Live: (tempo di vita) (8 bit); indica quanto tempo ildatagramma può rimanere all'interno della inter-rete.Quando un host genera un datagramma, inizializzaquesto campo con il valore del tempo concesso aldatagramma stesso per attraversare l’inter-rete. Questovalore verrà decrementato da ogni router incontrato nelcammino percorso dal datagramma. Quando il valore diquesto campo sarà nullo, il relativo datagramma verràscartato. Questa tecnica impedisce ad un datagramma diviaggiare indefinitamente nella rete, se, a causa di errori,il suo instradamento risultasse in un cammino chiuso o,in ogni caso, di evitare tempi di trasferimentoeccessivamente lunghi; il Time to Live è decrementato apassi minimi di un secondo; dopo 255 secondi (2^8) ildatagramma viene scartato. Nelle implementazioniattuali, e sempre in favore di una maggiore semplicità, ilvalore di questo campo non è definito in secondi ma in“salti” (hops). Per salto si intende l’attraversamento di unrouter e quindi un datagramma può attraversare almassimo 256 routers prima di essere scartato

- Protocol: indica a quale protocollo dello stato superiore deve esseretrasferito il contenuto informativo del datagramma

- Header Cecksum: l'intestazione è protetta da un controllo di errore (in unarete di rilevanti dimensioni bisogna evitare che undatagramma vada verso siti diversi da quelli voluti). Ilcontenuto di questo campo è ottenuto considerando i bit

42

dell’intestazione a gruppi di 16 alla volta; se ne effettua lasomma e si memorizza in questo campo il complementoa 1 del risultato

- Source Address: (32 bit); indirizzo di sorgente IP (dell’host, nondell’utente finale)

- Destin. Address: (32 bit); indirizzo di destinazione IP (dell’host, nondell’utente finale)

- Options: (opzioni) campo di lunghezza variabile (multipli di 8 bit);può essere omesso. La lunghezza è funzione delleopzioni implementate. Ad esempio:Record Route Option (RRO): consente al mittente dicreare una lista vuota di indirizzi IP in modo che ognisistema attraversato inserisce il suo indirizzo in questalista;Source Route Option: consente al mittente di specificare isistemi attraverso i quali vuole che transiti ildatagramma; in tal modo un mittente può far percorrereal datagramma una particolare strada. E’ usata per scopigestionali e di verifica del funzionamento di unadeterminata parte di Internet.Timestamp Option: ha la stessa funzione di RRO, ma inaggiunta ogni sistema attraversato comunica, oltre alproprio indirizzo, anche l'istante temporale in cui ildatagramma attraversa il sistema stesso

- Padding: (riempitivo) rende la lunghezza dell'intestazione unmultiplo intero di 32 bit, mediante introduzione di zeri

III.4.2� Modalità di segmentazione e di aggregazione

Le sotto-reti componenti Internet possono avere diverse limitazioni circa lalunghezza massima delle loro unità di dati; ad esempio la lunghezza massima diun’unità di dati in una LAN Ethernet è di 1500 bytes mentre nella MAN FDDI èdi 4470 bytes. La dimensione massima dell’unità di dati di una sotto-rete èdenominata, in TCP/IP, Maximum Transfer Unit (MTU). Dovendo scegliere ladimensione di un datagramma IP, una possibile soluzione potrebbe esserequella di adottare un valore pari al minimo delle MTU delle sotto-reti da

43

attraversare. Ciò richiederebbe però uno scambio di informazioni di controlloper determinare tale valore minimo e causerebbe delle inefficienze nel trasportoattraverso sotto-reti con dimensioni di MTU maggiori del valore minimo. Comeper altre problematiche, si è scelta invece una soluzione che sia la più semplicepossibile e che non sia legata a particolari tecnologie delle sotto-reticomponenti Internet. Ogni host che emette un datagramma IP può sceglierequalsivoglia dimensione per il datagramma stesso, purché inferiore alladimensione massima di un datagramma pari a 65536 ottetti e superiore a quellarelativa alla sola intestazione. Tipicamente la dimensione di un datagrammaviene scelta pari alla MTU della sotto-rete a cui è connesso il sistema mittente.Quest’ultima è resa nota all’entità IP mittente dal software che interfaccia IPstesso ad una data sotto-rete (tale software è denominato driver). Ovviamente,se la quantità di dati da trasmettere è inferiore alla MTU prescelta, ildatagramma avrà una dimensione minore della MTU stessa.

Quando poi un datagramma deve attraversare diverse sotto-reti pergiungere a destinazione ed almeno una di queste sotto-reti ha una MTU didimensioni inferiori a quelle scelte per un dato datagramma (ovvero unadimensione inferiore a quella della MTU della sotto-rete di origine), ildatagramma stesso viene segmentato in più parti, chiamate frammenti. Iframmenti non devono essere necessariamente tutti della stessa dimensione,anche perché non è detto che un datagramma abbia una lunghezza che sia unmultiplo intero di una data MTU; in tal caso almeno l’ultimo frammento di undato datagramma avrà una dimensione diversa dagli altri frammenti dello stessodatagramma. Può accadere anche che un frammento venga a sua voltaframmentato, qualora debba attraversare sotto-reti con MTU di dimensioniancora inferiori

Il solo vincolo che IP pone ai sistemi connessi ad Internet è che i routersdebbano accettare datagrammi di dimensioni pari a quelli delle MTU dellesotto-reti a cui sono connessi e che tutti i sistemi (host e router) debbonocomunque accettare e gestire datagrammi di dimensioni almeno pari a 576ottetti.

La segmentazione di un datagramma si rende necessaria quando anche solouna delle sotto-reti attraversate ha una dimensione massima della propria unitàdi dati inferiore alla dimensione del datagramma.

Alcuni datagrammi IP potrebbero però essere contrassegnati come nonsegmentabili (bit DF posto ad uno) e, in questo caso, non verranno suddivisi inunità più piccole per attraversare la inter-rete. Ciò comporta la perdita deldatagramma. In tal caso verrà generato un messaggio ICMP.

Le procedure di segmentazione e di aggregazione devono essere in grado

44

di segmentare il datagramma originario in un numero arbitrario di unità che,giunte a destinazione, devono poter essere ricomposte nella forma originaria. Ildestinatario utilizzerà il campo "Identification" di ogni frammento per garantireche datagrammi generati da processi diversi non siano confusi tra loro. Talecampo identificativo, che sarà univoco per tutti i processi operanti in quelmomento tra entità sorgenti e entità remote, sarà assegnato dalla entità sorgenteal datagramma trasmesso.

Ad ogni frammento è inoltre assegnato il campo “Fragment Offset” chepermette al destinatario di risalire alla posizione occupata dal frammento neldatagramma originario. Il frammento con il Flag MF posizionato a zero indicache questo è l'ultimo segmento del datagramma originario.

L'informazione presente nell'intestazione del datagramma viene copiatanell'intestazione dei frammenti, ad eccezione del campo “Total Length” cheviene modificato per fornire la lunghezza del frammento in questione. In talmodo ogni frammento diventa a sua volta un datagramma e può essere quindiulteriormente segmentato.

Il datagramma originale viene ricostruito completamente solo adestinazione. Se uno o più frammenti di un datagramma vengono persi, irestanti che arrivano a destinazione vengono scartati. Ciò avviene dopo un certotempo pre-definito (detto “time-out”), necessario per evitare che si scartinoframmenti di un datagramma anche nel caso in cui alcuni frammenti non sianoarrivati non perché persi ma perché in ritardo (si ricorda che IP è senzaconnessione e quindi non conserva la sequenza originaria di emissione). Se siutilizza TCP come protocollo di trasporto, quest’ultimo chiederà al mittente diun datagramma scartato di ri-inviarlo. Questo modo di procedere porta aeventuali inefficienze, ma l'alternativa sarebbe quella di effettuare un controllodi errore in ogni router, rendendo così più complessi tali sistemi.

Per aggregare i frammenti di un datagramma, la destinazione combineràinsieme i frammenti caratterizzati dagli stessi valori dei campi relativiall'identificazione, alla sorgente, al destinatario e al tipo di protocollo. La partedati di ogni frammento sarà inserita nel datagramma ricostruito nella posizioneindicata dal campo “Fragment Offset”, che si trova nell'intestazione delframmento stesso.

III.4.3� Schema di indirizzamento

Per consentire a tutti i sistemi connessi ad Internet di comunicare tra loro,è necessario stabilire un metodo globalmente accettato per identificare edindirizzare in modo univoco tutti i sistemi. Così come ogni numero della retetelefonica mondiale è unico, così anche gli indirizzi dei sistemi connessi ad

45

Internet devono essere unici. Ciò ha implicato la necessità di definire un nuovoschema di indirizzamento, poiché le sotto-reti pre-esistenti avevano schemi diindirizzi, in generale, diversi tra loro e globalmente non univoci (ad es. indirizziEthernet, indirizzi X.25, numeri telefonici etc.).

Lo schema di indirizzamento di Internet è definito all’interno degli strati IPe TCP (o UDP). Un indirizzo IP identifica solo un sistema e non uno specificoutente (si ricorda che un generico sistema può essere utilizzato da più utenti oprocessi). L’identificazione di un utente (in senso OSI) all’interno di un sistemaè affidata ai protocolli di strato superiore (TCP o UDP). Un indirizzo completoè quindi costituito da due parti, una definita all’interno di IP ed un’altra definitaall’interno di TCP (o UDP). In questo paragrafo tratteremo solo gli indirizzi alivello IP; si rimanda invece il lettore ai par. III.5, III.6 e III.7, per quantoriguarda l’indirizzamento di uno specifico processo all’interno di un datosistema.

Lo schema di indirizzamento di IP si sovrappone a quello delle sotto-retiche interconnette, nel senso spiegato nel par. III.1. Gli indirizzi IP devonoessere unici in tutta la inter-rete (è possibile attribuire indirizzi arbitrari ad unadata rete TCP/IP solo se questa non è connessa con altre reti o con Internet).

Lo schema di indirizzamento di IP ha una struttura gerarchica, perfacilitare l’operazione di instradamento. Un indirizzo IP identifica prima unaporzione di inter-rete a cui un sistema è connesso e poi il sistema all’interno diquella porzione; ciò facilità la scelta di una strada per raggiungere un datosistema.

Si può fare un parallelo con il sistema di numerazione telefonica. Ilprefisso telefonico internazionale identifica una data nazione; all’interno diquesta, il prefisso interurbano identifica un distretto e il numero di utente siriferisce ad uno specifica linea all’interno di quel distretto. In altre parolel’indirizzamento è gerarchico.

Un indirizzo IP è costituito da una stringa di 32 bits; possono quinditeoricamente esistere 2^32 (=4 294 967 296) possibili indirizzi; ogni indirizzoIP consta di due parti: Net_Id e Host_Id. L’indirizzo completo può quindiessere scritto come:

IP_Address=Net_Id.Host_Id

I 32 bits totali sono divisi tra Net_Id e Host_Id.E’ importante sottolineare che la componente Net_Id di un indirizzo IP

non è necessariamente in corrispondenza con una data sotto-rete fisica. Lacomponente Net_Id è in corrispondenza con quella che si è prima definitagenericamente come una porzione dell’inter-rete. Tale porzione può coincidere

46

con una data sotto-rete fisica ma può anche comprendere più sotto-reti fisiche oessere un sotto-insieme di una data sotto-rete fisica. Nel seguito, si faràriferimento ad una porzione di inter-rete, caratterizzata da una comunecomponente Net_Id degli indirizzi IP in essa contenuti, con il termine “retelogica”.

La suddivisione di un indirizzo IP nelle sue due componenti non è fissa. Inparticolare sono state definite cinque classi, in ognuna delle quali si assegna unafrazione diversa dei 32 bits totali alla Net_Id e conseguentemente alla Host_Id.

La possibile suddivisione di un indirizzo IP è riportata in Tab. 3, perognuna delle cinque classi. Il motivo dell’introduzione di queste classi è ancorada ricercarsi nel fatto che Internet si propone di inter-connettere diversi tipi disotto-rete; si possono perciò avere diverse necessità, circa la definizione dellereti logiche. Le cinque classi sono contraddistinte da una lettera, da A a E; leprime tre, ovvero le classi A, B e C sono destinate all’utenza normale; la classeD è destinata a comunicazioni di tipo multi-punto (multicast); la classe E èriservata per usi futuri e per ricerca e sviluppo. Grazie alla distinzione in classi,possono esistere:

- per la classe A: un numero ristretto di reti logiche (=128), ognuna delle qualipuò contenere milioni di possibili diversi indirizzi (fino a 16 777 216); ilnumero totale di indirizzi di classe A è (2^32)/2;

- per la classe B: un discreto numero di reti logiche (=16384), ognuna dellequali può contenere diverse migliaia di possibili diversi indirizzi (fino a65536); il numero totale di indirizzi di classe B è (2^32)/4;

- per la classe C: un elevato numero di reti logiche (=2 097 152), ognuna dellequali può contenere solo un ristretto numero di possibili diversi indirizzi(fino a 256); il numero totale di indirizzi di classe C è (2^32)/8;

Un indirizzo IP di Classe D è invece utilizzato per comunicazioni di tipomultipunto. Ovvero, se si vuole inviare un messaggio non ad un solodestinatario ma ad un pre-definito gruppo di destinatari, si può usare unapposito indirizzo di tipo multipunto, che corrisponde ad una pluralità di host(tale insieme di host è denominato “gruppo multicast”). A tal fine si usa ancheun apposito protocollo aggiuntivo (Internet Group Management Protocol,IGMP). Si noti che una trasmissione di tipo multipunto è diversa da una di tipodiffusiva (broadcast); la prima fa riferimento ad uno specifico gruppo didestinatari mentre la seconda fa riferimento a tutti gli utenti all’interno di unaspecificata sotto-rete (o perfino a tutti gli utenti di Internet). Il numero totale diindirizzi di classe D è (2^32)/16. Infine il numero totale di indirizzi di classe E è(2^32)/32.

Si noti che, a causa della divisione in classi, il numero totale di possibili

47

indirizzi IP, di tutte e cinque le classi, è pari a

N = 232

2+ 232

4+ 232

8+ 232

16+ 232

32= 31

32232

invece che N=2^32; infatti (2^32)/32 indirizzi risultano non assegnati a nessunaclasse e quindi, ad oggi, non utilizzabili.

Classe Bit/s Iniziali Net_Id Host_Id reti logiche

disponibili

indirizzi disponibili

all’interno di ogni

rete logica

A 0 7 bits 24 bits 128 16 777 216

B 10 14 bits 16 bits 16 384 65 536

C 110 21 bits 8 bits 2 097 152 256

D 1110 Indirizzi di tipo multicast, 28 bits

numero di indirizzi multicast possibili: (2^32)/16=268 435 456

E 11110 riservata per usi futuri e ricerca, 27 bits

numero di indirizzi possibili: (2^32)/32=134 217 728

Tab. 3 - Formato degli indirizzi

Al fine di assicurare che ogni indirizzo di Internet sia unico è statacostituita un’autorità centrale con il compito di assegnare gli indirizzi, il"INTERnet Network Information Center” (INTER-NIC). L’INTER-NIC ècontrollato a sua volta da una autorità amministrativa denominata “InternetAssigned Number Authority (IANA). INTER-NIC assegna però solo la parteNet_Id e quindi una rete logica, delegando poi l’organizzazione richiedente perl’assegnazione della restante parte dell’indirizzo, l’Host_Id; ovviamente unarete logica di classe A è concessa in uso solo ad organizzazioni molto grandi (oad intere nazioni); una rete logica di classe B è concessa solo ad organizzazioniche dimostrino di aver bisogno di connettere ad Internet almeno qualchemigliaia di host e così via.

L’organizzazione che si vede assegnare una Net_Id potrà poi suddividerela parte di Host_Id per creare, all’interno della “sua” rete logica, delle sotto-retilogiche, ognuna delle quali avrà la stessa Net_Id. In tal modo, un utente che habisogno di un singolo indirizzo IP non deve rivolgersi direttamente all’INTER-NIC, ma può fare riferimento ad un’autorità locale. Si noti che la scelta di unoschema di indirizzamento gerarchico può risultare in indirizzi non utilizzati e

48

quindi in sprechi. Gli indirizzi corrispondenti alla parte Host_Id di una data retelogica, non usati dall’organizzazione responsabile della corrispondente Net_Id,non possono essere usati da nessun altro; ciò spiega l’attuale relativa penuria diindirizzi IP, a fronte dei 3 758 096 384 indirizzi teoricamente disponibili per leprime tre classi.

In particolare, sono le reti logiche di classe B quelle con maggiore rischio diesaurimento. Nel tentativo di alleviare questo problema, nel 1993, si è deciso di consentireuna certa violazione della suddivisione in classi di cui sopra, nota come “supernetaddressing”. Questa metodica consente di attribuire più reti logiche ad una stessaorganizzazione. In tal modo una data organizzazione, invece di chiedere una rete logica diclasse B e non utilizzare tutti i relativi indirizzi disponibili, può chiedere un certo numero direti logiche di classe C, fino a soddisfare le sue esigenze. Affinché però questo insieme di retilogiche appaia all’esterno come un’unica rete logica è stato necessario introdurre alcunemodifiche ad alcune procedure precedentemente utilizzate (cfr. § III.4.5.3).

Nonostante questa tecnica (ed altre, introdotte allo stesso fine, come “TransparentRouters” e “Proxy ARP”, cfr. § III.4.5.1), lo spazio degli indirizzi appare non essere piùadeguato alle esigenze di una utenza in continua crescita. Per questa ragione, ed anche permigliorare altri punti deboli dell’attuale versione di IP (versione 4, IPv4), è stata recentementeproposta una nuova versione di IP (IPv6). In IPv6 il singolo indirizzo è una stringa binaria di128 bits invece che di 32; lo spazio degli indirizzi ne risulta significativamente esteso. Si notianche che si è passati dalla versione 4 direttamente alla 6: la versione 5 non è mai statacompletamente definita.

Come detto, un indirizzo IP è costituito da una stringa di 32 bits; per lecomunicazioni tra persone, in documenti tecnici ed anche in alcuni programmiapplicativi si preferisce invece usare un’altra notazione. La notazione inquestione si ottiene separando i 32 bits in 4 campi di 8 bits ciascuno; questicampi si esprimono poi in decimale invece che in binario, separandoli con unpunto; questa notazione è nota come “dotted” (“puntata”) o decimale. Adesempio l’indirizzo IP di un particolare sistema, espresso in una stringa di 32bits e nella relativa notazione “dotted” è:

10010111 01100100 00001000 00010010

151. 100. 8. 18

È utile sottolineare che l’indirizzo effettivamente utilizzato da IP è sempreuna stringa di 32 bits e la rappresentazione dotted deve essere preventivamentetradotta da un opportuno software (molto semplice, in questo caso) prima diessere utilizzata da IP per l’effettivo scambio di informazione.

In aggiunta alle classi definite nella Tab. 3, sono stati definiti alcuniindirizzi speciali. Con riferimento alla notazione binaria si è stabilito che uncampo costituito da zeri, “0”, (0 nella notazione dotted) significa “questo” ed un

49

campo costituito da uni, “1”, (255 nella notazione dotted) significa “tutti”.Infine un indirizzo che inizia con 01111111 (127 nella notazione dotted) è unindirizzo di “rinvio a se stesso” (loopback), cioè il messaggio inviato ritorna almittente (usato per prove, verifiche e per comunicazioni tra processi cheoperano nello stesso sistema). I casi possibili e permessi sono rappresentatinella Tab. 4.

Significato Net_Id Host_Id

“questo host” tutti 0 tutti 0

la rete a cui appartiene l’host

con indirizzo “Host”

tutti 0 “Host”

tutti gli host tutti 1 tutti 1

tutti gli host della rete logica

“Net”

“Net” tutti 1

loopback 127 (in decimale) seguito da qualsiasi cosa

Tab. 4 - Indirizzi speciali

Ne segue che gli indirizzi definiti nella Tab. 3 hanno delle limitazioni aivalori che i loro campi possono assumere; in particolare alcuni campi di ungenerico indirizzo non possono assumere i valori 0, 127 e 255.

Gli indirizzi con campi uguale ad “uni” sono utilizzati per comunicazionidiffusive (broadcast) ovvero per comunicare con una pluralità indifferenziata disistemi. Con riferimento alla notazione dotted (si ricorda che una stringa di 8bits uguale a 11111111 equivale a “255” in decimale), inviando un messaggioall’indirizzo 255.255.255.255 si indirizzano tutti i sistemi di Internet (il che ingenerale non è permesso). L’indirizzo 151.100.255.255 si riferisce a tutti isistemi della rete logica 151.100. Il campo composto da “zeri” è inveceimportante quando si vuole comunicare con un host collegato alla stessa retelogica cui si è collegati e non si conosce l’indirizzo della rete logica stessa ( èun problema che sorge per alcune applicazioni). Ad esempio, 0.0.0.0 si riferisceall’host che origina la richiesta; 0.0.0.23 si riferisce alla rete logica a cui èconnesso l’host 23.

Per concludere bisogna precisare che un router, che è collegatodirettamente a due o più sotto-reti e quindi, in generale, a due o più reti logiche,deve avere due o più indirizzi IP (oltre ai corrispondenti indirizzi locali). LaFig. 7 illustra un esempio in cui le reti logiche coincidono con sotto-reti fisiche.La sotto-rete fisica Ethernet corrisponde alla rete logica con Net_Id=128.10 (innotazione binaria: 10000000.00001010, 16 bit complessivi, di classe B); la

50

sotto-rete fisica Token Ring corrisponde alla rete logica con Net_Id=192.5.48(in notazione binaria: 11000000.00000101.00011000, 24 bit complessivi, diclasse C). Si noti anche che si usa indicare una rete logica aggiungendo allaNet_Id degli zeri, fino ad avere la stessa dimensione di un indirizzo IP (sia inbinario che in decimale).

ETHERNET 128.10.0.0

128.10.2.3 128.10.2.8 128.10.2.70 128.10.2.26

Gauss Dirac

Newton Einstein

Token Ring192.5.48.0

Fermi Galilei

192.5.48.3 192.5.48.7

192.5.48.1192.5.48.6 10.2.0.37

Fig. 7 - Esempio di sistemi connessi a più di una sotto-rete

I calcolatori “Newton” e “Fermi” sono dei router, sono connessi sia allaToken Ring che all’Ethernet e hanno quindi due indirizzi IP (vedremo inseguito che è possibile attribuire dei nomi agli host ed ai router, cfr. III.4.7).Anche “Dirac” è un router, che interconnette la Token Ring verso un’altrasotto-rete e quindi anch’esso ha due indirizzi IP. Gli altri calcolatori hanno unsolo indirizzo IP e sono quindi degli host. Si noti anche che, siccome gliindirizzi sono utilizzati per l’instradamento (cfr. § III.4.5), se ci riferiamo a“Newton” con l’indirizzo 192.5.48.3 il messaggio gli perverrà tramite la TokenRing, se invece usiamo 128.10.2.3, il messaggio gli perverrà tramite l’Ethernet.

III.4.4� Traduzione di indirizzi IP in indirizzi locali

Abbiamo visto come ad ogni sistema connesso ad Internet sia assegnato ununico indirizzo IP che lo identifica nell’ambito dell’intera inter-rete (indirizzoglobale). Come si vedrà nel § III.4.5 (cfr. anche par. III.1), quando undatagramma arriva alla sotto-rete di destinazione, l'ultimo router attraversato hail compito di rilanciare il datagramma verso l’host di destinazione (prendendoin considerazione anche la componente Host_Id dell'indirizzo e sfruttando imeccanismi protocollari propri della sotto-rete di destinazione). L’indirizzo IP

51

non è però sufficiente per far arrivare il datagramma all’host in questione.Infatti, la sotto-rete di destinazione ha un suo schema di indirizzamento (locale)e l’interfaccia di rete di un host è indirizzata, nell’ambito della sotto-rete diappartenenza, da un indirizzo locale. L'ultimo router deve quindi compiere delleoperazioni di ricerca per determinare l'indirizzo locale di sotto-rete dell’host didestinazione che corrisponde all’indirizzo globale IP contenuto nel datagrammain arrivo.

La traduzione di un indirizzo globale in uno locale interessa però anche glihost e non solo i router; infatti ogni sistema (host o router) quando invia undatagramma ad un altro sistema connesso alla stessa sotto-rete ha bisogno dellefunzionalità di traduzione; ciò accade:

- sia quando un host invia un datagramma IP direttamente ad un altro host,senza passare attraverso un router (cosa possibile quando sia l’host mittenteche quello di destinazione sono connessi alla stessa sotto-rete);

- sia quando un host invia un datagramma ad un router affinché questi lorilanci poi verso la destinazione finale (in tal caso sicuramente l’host mittenteed il router apparterranno alla stessa sotto-rete, cfr. § III.4.5).

Il problema di tradurre indirizzi globali IP in indirizzi locali è risoltomediante protocolli di tipo ARP (cfr par. III.3). Tale procedura di traduzione ènota con il termine “risoluzione” di un indirizzo. La risoluzione di un indirizzoavviene secondo diverse modalità, ognuna specifica di una data tipologia disotto-reti. Le modalità più usate sono le seguenti:

1) Alcuni protocolli ARP utilizzano delle tabelle, che contengono coppie diindirizzi IP e dei corrispondenti indirizzi locali; tali tabelle, predispostedall’amministratore della sotto-rete in questione, sono contenute in unopportuno server (o in più di un server); quando un host (o un router) habisogno di una corrispondenza tra un dato indirizzo IP ed un indirizzo locale,interroga tali server (denominati ARP server). In tal caso l’host deveconoscere l’indirizzo locale di almeno un ARP server, per potergli inviareuna richiesta di risoluzione. (Si noti che nulla vieta che un ARP server siafisicamente implementato in un calcolatore che svolge anche funzioni dirouter).

2) Altri protocolli ARP utilizzano un opportuno algoritmo. Ciò è possibilequando lo schema di indirizzamento della sotto-rete in questione gode diopportune proprietà e gli indirizzi IP sono assegnati agli host secondoopportune modalità, in funzione dei rispettivi indirizzi locali.

3) Altri protocolli ARP ancora ottengono dinamicamente questa corrispondenzausando degli opportuni messaggi di interrogazione: quando un host (o unrouter) ha bisogno di risolvere un dato indirizzo IP, interroga tutti gli host

52

della sotto-rete a cui è collegato, chiedendo a quale host corrispondequell’indirizzo IP.

Quest’ultima modalità è vantaggiosa quando usata in sotto-reticaratterizzate da capacità di trasmissioni diffusive (broadcast) “intrinseche”come, ad esempio, una LAN Ethernet. Vista la diffusione di tali sotto-reti inInternet, i corrispondenti protocolli ARP sono tra i più usati.

In tal caso (cfr. [BLE]), un messaggio inviato sul mezzo fisico relativo aduna data sotto-rete perviene sempre a tutti gli host collegati a quel mezzo fisico.Nel messaggio di interrogazione si chiederà quindi: “quale host ha l’indirizzoIP X.X.X.X?”; tale messaggio perverrà a tutti gli host della sotto-rete e solol’host con tale indirizzo IP risponderà all’interrogazione con un messaggio incui comunicherà: “l’indirizzo IP X.X.X.X corrisponde al (mio) indirizzo localeY”.

Consideriamo, ad esempio, una sotto-rete Ethernet in cui operi unprotocollo ARP del tipo appena descritto. Una Ethernet è caratterizzata daindirizzi locali costituiti da stringhe di 48 bit, spesso rappresentati con 12caratteri esadecimali divisi, a coppie, dal simbolo “:”. Assumiamo che in taleEthernet esista un host, denominato “Plinius”, con indirizzo IP “128.6.18.45” eindirizzo Ethernet “08:0:20:9:3e:be” (espresso in caratteri esadecimali). Quandoun host (o un router), connesso alla stessa Ethernet, emette un’interrogazioneARP (“ARP REQUEST”), chiedendo a chi corrisponde l’indirizzo IP128.6.18.45 ottiene la risposta:

“Plinius (128.6.18.45) at 08:0:20:9:3e:be”

Ovvero l’host “Plinius”, che è a conoscenza di essere caratterizzatodall’indirizzo IP in questione, risponde comunicando il proprio indirizzo localeEthernet.

Quando il protocollo ARP ha risolto un dato indirizzo IP, memorizza lacorrispondenza indirizzo IP->indirizzo locale in un’apposita tabella. Questatabella svolge una funzione di “cache” (=nascondiglio, magazzino nascosto),cioè permette di ottenere rapidamente quelle corrispondenze che venganorichieste ripetutamente in brevi intervalli di tempo, senza bisogno di invocareogni volta il protocollo ARP. Periodicamente le informazioni contenute nellacache vengono cancellate in modo da garantire la consistenza con le(eventualmente) mutate condizioni della topologia di rete.

In tal modo, un router (o un host) deve emettere un messaggio ARPREQUEST solo quando deve trattare un datagramma il cui indirizzo didestinazione non sia contenuto nella sua tabella di corrispondenze.

Si noti che risulta molto complesso implementare un protocollo ARP di

53

questo tipo in una sotto-rete priva di capacità di trasmissioni diffusiveintrinseche e legate alla sua topologia fisica. In tal caso, il router dovrebbe (sead es. la sotto-rete adottasse una modalità di trasferimento con connessione)instaurare delle connessioni verso tutti gli host della sotto-rete ed inviare adognuno di essi il messaggio ARP REQUEST. Si pensi a cosa ciòsignificherebbe in una sotto-rete di rilevanti dimensioni. Per tali tipi disotto-rete (denominate Non Broadcast Multi-access Network - NBMA), ilproblema della risoluzione degli indirizzi risulta essere una delle tematiche piùcomplesse, quando si vuole interconnettere una di tali sotto-reti ad Internet.

In questi casi si preferisce adottare la prima delle soluzioni proposte inquesto paragrafo e cioè l’uso di ARP servers. Anche questa soluzione presentaperò degli aspetti critici. Infatti, se si usa un solo ARP server, quest’ultimodovrà gestire numerose richieste ed in caso di un suo guasto, l’intera sotto-retenon sarebbe in condizioni di operare. Se si usano più ARP servers sorge ilproblema di coordinarne il funzionamento e di comunicare ad ogni host a quale(o a quali) ARP server rivolgere le proprie richieste.

Infine, citiamo il caso di risoluzione di indirizzi inversa; ovvero quello incui è noto un indirizzo locale, ma non il corrispondente indirizzo IP. Tale casosi presenta quando un sistema, all’accensione, pur conoscendo il proprioindirizzo locale, non conosce il proprio indirizzo IP. Per risolvere questoproblema si usa un protocollo di tipo Reverse Address Resolution Protocol(RARP). Il sistema emette un messaggio in cui chiede "qual’è il mio indirizzoIP?", comunicando il proprio indirizzo locale; un server RARP, residente nellastessa sotto-rete ed opportunamente configurato dall’amministratore di rete,risponde alla richiesta comunicandogli il relativo indirizzo IP. Altri esempi diprotocolli che svolgono funzioni simili a quelle di RARP sono BootP e DHCP.

Questa situazione è tipica per sistemi privi di dispositivi dimemorizzazione di massa, che non possono quindi “ricordare” il proprioindirizzo IP o per sistemi a cui non è stato assegnato un indirizzo IP e che siconnettono ad Internet per il tramite di un fornitore di servizi (Internet ServiceProvider). In quest’ultima eventualità il fornitore di servizi dispone di uninsieme limitato di indirizzi IP che assegna dinamicamente a quegli host che inun dato momento gli richiedono di connettersi ad Internet. Ognuno di questihost è caratterizzato da un dato indirizzo IP solo per il tempo durante il quale èconnesso ad Internet; quando l’host termina di usufruire dei servizi Internet,quell’indirizzo IP sarà assegnato ad un altro host che, in un tempo successivo,chiederà di connettersi ad Internet. In un'altra alternativa, il fornitore di serviziassegna ai suoi utenti indirizzi IP che hanno solo un significato locale e, non

54

essendo visibili all'esterno, possono essere scelti in modo arbitrario. Sarà poicompito del fornitore di servizi porre in corrispondenza tali indirizzi conspecifiche sessioni di comunicazione.

Questo modo di operare è molto usato per host che accedono ad Internettramite la rete telefonica e consente sia un risparmio di indirizzi IP, essendoquesti condivisi tra più utenti, sia una semplificazione d’uso per gli utenti, iquali non devono richiedere un proprio personale indirizzo IP e configurareconseguentemente il proprio calcolatore. Oltre a tale indirizzo, un utente diquesto tipo riceve dal suo fornitore di servizi anche altre informazioni diconfigurazione, tra cui l'indirizzo del router di default (cfr. III.4.5.3) e quello delname server (cfr. III.4.7). Quando un host si connette ad Internet secondo questamodalità è necessario usare anche un ulteriore protocollo che governa loscambio di informazioni e di comandi tra utente e fornitore di servizi. Unesempio di tale protocollo è PPP (Point to Point Protocol).

III.4.5� Instradamento

L'instradamento è una funzione di natura logica avente lo scopo di guidarel’informazione di utente verso la destinazione voluta (cfr. [BLE]), ovvero discegliere un percorso per far arrivare i datagrammi a destinazione. La scelta delpercorso può avvenire in base a diversi criteri più o meno sofisticati; può tenerein conto lo stato di occupazione delle risorse di rete in un certo momento, lalunghezza del datagramma, il tipo di servizio richiesto o semplicementescegliere il cammino più breve; il relativo algoritmo può essere statico (se noncambia nel tempo) o dinamico; può anche essere adattativo e reagire aparticolari situazioni (malfunzionamenti, indisponibilità di un particolareelemento di rete, congestione). Molti degli algoritmi di instradamento inInternet (vedremo che ne esiste più di uno) sono abbastanza semplici ed usanoregole basate sul cammino più breve (cfr. [BLE]).

In Internet, ogni datagramma attraversa un cammino composto da router eda sotto-reti. Quando un router consegna un datagramma ad una sotto-retequesto diventa il "corpo" (SDU) dell’unità di dati propria dello stratoimmediatamente inferiore ad IP di questa sotto-rete (strato 3a, cfr. Tab. 1). Lasotto-rete consegna tale unità dati al prossimo router o a destinazione (se ladestinazione è all'interno della sotto-rete stessa) con le stesse modalità con cuitratta le unità di dati ad essa "appartenenti". Il relativo incapsulamento deldatagramma (unità di dati IP) in unità di dati caratteristiche delle sotto-retiattraversate è esemplificato in Fig. 8. La parte in grigio rappresenta ildatagramma IP, in cui si è evidenziato il campo Net_Id contenutonell’intestazione.

55

Più in dettaglio si può dire che i router instradano i datagrammi solo versola rete logica di destinazione e non verso il singolo host di destinazione.L’algoritmo di instradamento operante nei router determina solo la sequenza deirouter da attraversare e non quella di tutti i sistemi di ogni sotto-rete e si basasolo sulla componente Net_Id dell’indirizzo IP di destinazione. La componenteHost_Id viene presa in considerazione solo quando un datagramma arriva allarete logica di destinazione.

Bridge

host mittente

router X

router Y

sub-rete A (X25)

sub-rete B (?)

host destinatario

LAN 1

LAN 2

��

Net_Id Data

Net_Id Data

Net_Id Data

Net_Id Data

Net_Id Data

Net_Id Data

Net_Id Data

PCIPCItramapacchet.

PCI ?

MACLLC

Fig. 8 - Esempio di incapsulamento del datagramma IP in unità di dati caratteristiche dellesotto-reti attraversate

L'instradamento in Internet può essere diviso in due classi: diretto edindiretto. L’instradamento diretto è possibile solo se l’host mittente e l’hostdestinatario sono connessi alla stessa sotto-rete; l’instradamento indiretto siapplica quando un datagramma deve attraversare almeno un router per giungerea destinazione; ciò avviene sicuramente quando l’host destinatario è connessoad una sotto-rete diversa da quella relativa all’host mittente. L’instradamentoindiretto può però essere applicato anche tra due host appartenenti alla stessa

56

sotto-rete fisica; l’amministratore di rete può cioè scegliere di far instradare inmodo indiretto i datagrammi emessi da un dato host e diretti ad un hostappartenente alla stessa sotto-rete, anche se questo non è strettamentenecessario (cfr il paragrafo successivo). Nel seguito, quando ci si riferirà inmodo indifferenziato ad un host o ad un router si userà il termine generico di“sistema”.

III.4.5.1 Instradamento diretto

Un host connesso ad una data sotto-rete ha i mezzi per inviareinformazioni a qualsiasi altro host connesso alla stessa sotto-rete, grazie allerisorse di rete ed ai protocolli della sotto-rete stessa. Lo scambio di datagrammitra host connessi alla stessa sotto-rete non coinvolge, in generale, i router e,previa un’operazione di risoluzione di indirizzi e di incapsulamento, larisultante unità di dati può essere inviata direttamente a destinazione. Quandoun host IP deve inviare un datagramma in modo diretto, lo incapsula nell’unitàdi dati specifica di quella sotto-rete, traduce l’indirizzo IP di destinazione nelcorrispondente indirizzo locale di quella sotto-rete (grazie ai protocolli ARP) edutilizza i meccanismi propri della sotto-rete in questione per inviare ildatagramma.

Vediamo ora come un host mittente determina se usare un instradamentodiretto oppure uno indiretto.

Per prima cosa l’host mittente deve stabilire se l’host destinatarioappartiene alla stessa sotto-rete fisica o meno. Nel secondo caso devesicuramente usare un instradamento indiretto. Nel primo caso può invece usareentrambi i tipi di instradamento e la decisione tra le due alternative èconseguenza delle scelte dell’amministratore di rete.

Per affrontare in generale tale problematica occorre introdurre dei concettiaggiuntivi. Si è detto che un indirizzo IP è caratterizzato da una gerarchia,ottenuta mediante la suddivisione in Net_Id e Host_Id; si tratta quindi di unagerarchia a due livelli; con il progressivo estendersi delle dimensioni di Internetsi è però deciso di rendere più flessibile tale schema di indirizzamento,introducendo un ulteriore livello gerarchico: la parte Host_Id può essere a suavolta suddivisa in due parti (denominate nel seguito come Sub_Net_Id eSub_Host_Id), creando così delle “sotto-reti logiche” e portando a tre i livelligerarchici; un generico indirizzo IP può quindi essere considerato diviso in treparti:

IP_Address=Net_Id.Host_Id=Net_Id.Sub_Net_Id.Sub_Host_Id

Grazie a tale terzo livello gerarchico (introdotto nei primi anni ‘80) si

57

possono semplificare le operazioni di instradamento e ridurre gli sprechi dovutiad indirizzi non utilizzati. Anche in tal caso si può fare un parallelo con ilsistema di numerazione telefonico che suddivide un numero completo inprefisso inter-nazionale, prefisso inter-urbano e numero di utente. Si noti ancheche, in una data rete logica, la componente Host_Id può anche non esseresuddivisa in due parti; questa situazione può sempre essere vista come un casoparticolare della gerarchia a tre livelli appena introdotta in cui il campoSub_Net_Id ha dimensione nulla e rete logica e sotto-rete logica coincidono.

La divisione della parte Host_Id è di competenza dell’amministratore diuna data rete logica, che può scegliere qualsiasi tipo di suddivisione: ledimensioni e le configurazioni delle parti Sub_Net_Id e Sub_Host_Id possonoessere qualunque, purché, ovviamente, la loro somma sia uguale alladimensione originaria dell’Host_Id.

La componente Sub_Net_Id è presa in esame solo quando un datagrammaarriva alla rete logica di destinazione; sono solo i router locali ad una rete logicaa conoscere e gestire tale suddivisione (tipicamente un solo router). I routeresterni ad una data rete logica continuano a basarsi solo sulla parte Net_Iddell’indirizzo per instradare i datagrammi. Tali router non prendono mai inesame la componente Host_Id e quindi, dal loro punto di vista, la suddivisionedella parte Host_Id non ha nessun significato.

Ricordiamo anche che una rete logica può coincidere con una datasotto-rete fisica, può comprendere più sotto-reti fisiche o essere unsotto-insieme di una data sotto-rete fisica. Per ciò che riguarda invece lerelazioni tra sotto-reti logiche e sotto-reti fisiche, una data sotto-rete logica puòcoincidere con una data sotto-rete fisica, può essere un sotto-insieme di unadata sotto-rete fisica ma non può comprendere più sotto-reti fisiche.

Da un punto di vista operativo, occorre rendere noto ad ogni host in chemodo il suo indirizzo IP è suddiviso, ovvero quali sono le dimensioni delle particomponenti il suo indirizzo. Questa informazione è codificata mediante lacosiddetta “maschera di sotto-rete”. Una maschera di sotto-rete è una stringabinaria avente la stessa dimensione di un indirizzo IP in cui i campicorrispondenti alle parti Net_Id e Sub_Net_Id sono costituiti da “1” binari e larestante parte, corrispondente alla parte Sub_Host_Id è costituita da “0” binari.

Ad esempio, in un indirizzo di classe B le parti Net_Id e Host_Id hannoentrambe dimensione pari a 16 bit. Se la parte Host_Id non è suddivisa lacorrispondente maschera di sotto-rete è:

11111111.11111111.00000000.00000000in notazione decimale:255.255.000.000

58

Se invece la parte Host_Id fosse suddivisa a metà in Sub_Net_Id eSub_Host_Id la relativa maschera di sotto-rete sarebbe:

11111111.11111111.11111111.00000000in notazione decimale:255.255.255.000Come si vede, esaminando tale maschera, un host può dedurre la modalità

di suddivisione del suo indirizzo.Con queste premesse possiamo tornare al problema di come un generico

host mittente, appartenente ad una data sotto-rete fisica, decide se inviare undatagramma usando l’instradamento diretto ovvero quello indiretto. Sonopossibili diverse alternative:

- se la sotto-rete fisica coincide con la sotto-rete logica, l’host mittente devesolo confrontare la parte del proprio indirizzo corrispondente ai campi Net_Ide Sub_Net_Id con la parte dell’indirizzo del destinatario di dimensionicorrispondenti; se tali parti sono uguali allora i due host risiedono nella stessasotto-rete e il mittente usa l’instradamento diretto. Il confronto vieneeffettuato usando la maschera di sotto-rete: le parti da confrontare sonoquelle caratterizzate da “1” binari nella maschera (il nome “maschera” derivada questa operazione);

- se la sotto-rete fisica a cui è collegato l’host mittente contiene diversesotto-reti logiche, allora sono possibili diverse sub-alternative, conseguenzedelle scelte dell’amministratore di rete.

• una prima sub-alternativa è che l’host mittente usil’instradamento diretto solo per destinazioni contenute nellastessa sotto-rete logica a cui egli appartiene; in tal caso per talicomunicazioni si procede come al caso precedente. Percomunicazioni dirette ad host appartenenti alla stessa sotto-retefisica, ma a diverse sotto-reti logiche, l’host mittente adotta uninstradamento indiretto, coinvolgendo quindi un router.

• una seconda sub-alternativa è che l’amministratore di reteconfiguri opportunamente ogni host, comunicandogli in modoesplicito (cfr. § III.4.5.3) quali sotto-reti logiche, oltre a quella acui egli appartiene, sono raggiungibili direttamente e quindiappartengono alla stessa sotto-rete fisica. Tale comunicazionepuò riguardare un numero qualunque di sotto-reti logichecontenute nella stessa sotto-rete fisica; se le riguarda tutte, alloral’host mittente può usare l’instradamento diretto per tutte lecomunicazioni dirette alla sotto-rete fisica a cui appartiene.

Si noti che se la parte Host_Id non è suddivisa, le decisioni di cui sopra si

59

possono prendere basandosi solo sulla Net_Id: per determinare se un hostdestinatario appartiene alla stessa rete logica di quello mittente è sufficienteconfrontare la parte Net_Id. In tal caso, a meno che non si usino delle altresoluzioni, alternative a quella della suddivisione in sotto-reti logiche, non èpossibile che una rete logica comprenda più di una sotto-rete fisica; altrimenti,un host mittente tenterebbe di usare un instradamento diretto anche verso hostdestinatari non appartenenti alla sua sotto-rete fisica.

Concludiamo il paragrafo citando brevemente delle soluzioni, alternative allasuddivisione in sotto-reti logiche, per consentire che una rete logica comprenda più sotto-retifisiche: “Transparent Routers” e “Proxy ARP”. In entrambe queste soluzioni, e come accadeanche per la suddivisione in sotto-reti logiche, si partiziona l’insieme degli host appartenentiad una data rete logica, in più sotto-insiemi. Tale partizione deve sicuramente essere nota alrouter o ai router locali che pongono in corrispondenza la rete logica con il resto di Internet;viceversa ciò non è sempre necessario per tutti i sistemi in questione. La suddivisione nondeve però essere visibile dal resto di Internet. Ne segue che l’amministratore di rete puòscegliere qualsiasi metodologia per definire e rendere nota ai sistemi interessati la partizionein sotto-insiemi della rete logica.

La soluzione Transparent Routers si basa su dei routers che svolgono dei compiti diversida quelli tradizionali; in particolari essi multiplano (e demultiplano) tutto il traffico direttoverso e proveniente da una data rete logica in una sola connessione fisica. Essi realizzano, inmodo concentrato, la partizione di cui sopra, distinguendo così i datagrammi di pertinenza diognuno dei sotto-insiemi in cui la rete logica è divisa (cfr [COM91, COM94]).

La soluzione Proxy ARP attua la suddivisione a livello degli indirizzi locali, invece cheal livello degli indirizzi IP. La suddivisione è nota solo ad un opportuno router che, grazie aduna apposita tabella, pone in corrispondenza sotto-insiemi di indirizzi locali con una datasotto-rete fisica; esso può quindi sapere se un host con un dato indirizzo locale appartiene omeno ad una data sotto-rete fisica. Questa soluzione è applicata quando le sotto-reti fisichesono delle LAN e sono in uso opportuni protocolli ARP. Gli host non sono a conoscenza diquesta suddivisione e quando emettono una richiesta ARP, al fine di raggiungere un host cheappartiene alla stessa rete logica, e che essi credono appartenga anche alla stessa sotto-retefisica, il router intercetta tale richiesta e la gestisce in proprio. Il router “fa credere” all’hostmittente di essere lui il destinatario e quindi rilancia il datagramma in questione verso il verodestinatario (cfr [COM91, COM94]).

III.4.5.2 Instradamento indiretto

L’instradamento indiretto è più complesso. Il mittente deve identificare unrouter a cui inviare un dato datagramma e tale router deve inviare ildatagramma verso la rete logica di destinazione (ricordiamo ancora una voltache i router instradano i datagrammi solo verso la rete logica di destinazione enon verso il singolo host di destinazione). I router non si occupanodell'instradamento all’interno delle sotto-reti. Nell’instradamento indirettoviene utilizzata solo la componente Net_Id dell'indirizzo Internet. Si immaginiuna situazione come quella rappresentata in Fig. 8: due host agli estremi di unainter-rete costituita da diverse sotto-reti.

60

Supponiamo che esista almeno un router connesso alla sotto-rete fisica diorigine e che esista almeno un cammino attraverso un certo numero di routerche porti alla sotto-rete di destinazione. Il mittente invia il datagramma al routerpiù vicino, utilizzando la sotto-rete a cui è direttamente connesso; a tal fine puòquindi usare un instradamento diretto in cui il router è visto come undestinatario intermedio a cui il mittente invia il datagramma, chiedendogli dirilanciarlo verso la destinazione finale. Il router esamina il datagramma ricevutoe decide verso quale altro router indirizzarlo; una volta presa tale decisione usaun instradamento diretto per far pervenire il datagramma al router successivo,attraverso la sotto-rete a cui sono entrambi collegati. Il processo si ripete dirouter in router finché si arriva alla sotto-rete di destinazione; qui tramite uninstradamento diretto il datagramma viene inviato allo specifico host didestinazione.

I router formano una struttura inter-connessa e cooperativa. I datagrammipassano di router in router finché ne raggiungono uno che può consegnare ildatagramma tramite un indirizzamento diretto. Si può quindi dire chel’instradamento indiretto consiste di una successione di instradamenti diretti,opportunamente coordinata dai router.

Rimane ora da vedere:- come un host mittente individua il primo router a cui inviare un datagramma

e come tale router decide verso quale altro router rilanciare il datagrammastesso, ovvero come si determina la sequenza di router che un datagrammadeve attraversare;

- quali sono le procedure operative seguite dagli host per inviare i datagrammie dai router per rilanciare i datagrammi stessi.

I prossimi due paragrafi si occupano rispettivamente di queste dueproblematiche. In particolare si illustreranno prima le procedure operative,assumendo che ogni sistema (host o router) conosca già quale percorso farseguire ad ogni datagramma, ovvero verso quale router inviare (nel caso di unhost) o rilanciare (nel caso di un router) i datagrammi, in funzione dell’indirizzodi destinazione. In seguito si spiegherà come fanno host e router a venire aconoscenza del percorso da far seguire ad ogni possibile datagramma.

III.4.5.3 Tabelle di instradamento

Il meccanismo operativo usato per l’instradamento in IP è basato su unatabella di instradamento che ogni host e ogni router mantiene allo scopo diconoscere le possibili destinazioni e i percorsi per raggiungerle. Si noti che nonsolo i router, ma anche gli host devono avere una tabella di instradamento.Questo perché ogni host ha la necessità di inviare datagrammi, se non quelli

61

altrui, almeno quelli che esso stesso genera.Una tabella di instradamento è costituita da coppie (R,I) dove R è

l’indirizzo della rete logica di destinazione (contenente quindi solo lacomponente Net_Id) e I è l’indirizzo IP completo del prossimo router lungo lastrada che porta alla sotto-rete di destinazione. La tabella di instradamentospecifica quindi solo un passo lungo il cammino verso la destinazione e noncontiene il cammino completo che il datagramma dovrà compiere. La tabella diinstradamento punta solo a router che possono essere raggiunti attraversandouna singola sotto-rete. Quando una sotto-rete di destinazione è raggiungibiledirettamente, ovvero si è arrivati all’ultimo router, nella sequenza dei router daattraversare, nella coppia (R,I) si sostituisce I con l’indicazione di instradare inmodo diretto.

La tabella, oltre alla coppia (R,I), può contenere anche una metrica chedefinisce la distanza dalla destinazione espressa secondo diverse unità dimisura: distanza fisica, numero di sotto-reti da attraversare, costo del percorso(espresso in affidabilità o tempo di attraversamento o grado di integritàinformativa etc.). Tale informazione può, opzionalmente, essere tenuta in contoper la decisione di instradamento, soddisfacendo così la richiesta dell’utenteespressa nel campo Service Type, (o per ottimizzare le decisioni prese mediantealgoritmi sia statici che dinamici che adattativi).

La Fig. 9 si riferisce ad una ipotetica sezione di Internet costituita daquattro sotto-reti fisiche e da tre router (R1, R2 e R3), e riporta anche la tabelladi instradamento di uno di questi (R2). Tale tabella illustra le decisioni che deveprendere il router R2 quando deve instradare un datagramma. In questo esempiosi assume anche che le sotto-reti fisiche coincidano con delle reti logiche e chequest’ultime non siano suddivise in sotto-reti logiche. Si noti che ogni routerdispone di due indirizzi IP, uno per ognuno delle sotto-reti fisiche (e dellerelative reti logiche) a cui è direttamente collegato. Ad esempio, R1 è noto,all’interno della sotto-rete coincidente con la rete logica con Net_Id=10, conl’indirizzo 10.0.0.5 e, all’interno della sotto-rete coincidente con la rete logicacon Net_Id=20, con l’indirizzo 20.0.0.5.

20.0.0.5

20.0.0.6

30.0.0.6 40.0.0.7

30.0.0.7

Rete logica10.0.0.0 R1 R2 R3

10.0.0.5

Rete logica20.0.0.0

Rete logica30.0.0.0

Rete logica40.0.0.0

62

Per raggiungere host

appartenenti alla rete logica:

instradare i datagrammi

secondo questa modalità:

20.0.0.0 inoltrare direttamente

30.0.0.0 inoltrare direttamente

10.0.0.0 Rilanciare verso l’indirizzo IP 20.0.0.5

(appartenente al router R1)

40.0.0.0 Rilanciare verso l’indirizzo IP 30.0.0.7

(appartenente al router R3)

Fig. 9 - Esempio di interconnessione di quattro sotto-reti e tabella di instradamento del routerR2.

La tabella mostra anche che la sua dimensione dipende dal numero di retilogiche interconnesse e cresce quando nuove reti logiche vi sono aggiunte manon dipende dal numero di host. Vediamo quindi come si applica quanto dettoin precedenza: al fine di nascondere il più possibile i dettagli inerenti lainter-rete, mantenere piccole le tabelle di instradamento e consentire uninstradamento efficiente, le tabelle contengono solo informazioni sulle retilogiche di destinazione e non sui singoli host.

Si noti anche che, siccome ogni router prende le sue decisioni in modoindipendente dagli altri, una comunicazione da A e B può seguire una stradadiversa da una comunicazione da B ad A. È quindi necessario prevedereopportuni meccanismi per assicurare una comunicazione bi-direzionale. Adesempio, in caso di percorsi diversi, il percorso da A a B potrebbe esseredisponibile e quello da B ad A potrebbe non esserlo.

Un’altra considerazione importante è che, sebbene ogni generico hostdebba avere una tabella di instradamento, ci si sforza di mantenere il più piccolepossibile le tabelle degli host forzando questi ultimi a far affidamento sui routernella maggior parte dei casi. Ad esempio, con riferimento alla situazionepresentata alla fine del paragrafo in cui si descriveva l’instradamento indiretto(§ III.4.5.1), la scelta di usare quest’ultimo solo per comunicazioni dirette adhost appartenenti alla stessa sotto-rete logica del mittente (nel caso dicoesistenza di diverse sotto-reti logiche in una stessa sotto-rete fisica), va inquesta direzione.

Questa tecnica è applicata anche più in generale. Se un router non trovauna strada nella sua tabella, allora indirizza i suoi datagrammi verso un “defaultrouter”. Il meccanismo di default (=mancanza) consiste nel fornire una sceltaobbligata, in mancanza di informazioni che possano contribuire a prenderescelte alternative. Un default router è generalmente un calcolatore abbastanza

63

potente e destinato principalmente ad operazioni di instradamento o, (semprepiù spesso, vista la crescita di Internet), un sistema progettato ad hoc. Ilmeccanismo del default router è usato quindi:

- sia da piccoli host, che possono anche inviare tutti i datagrammi non direttialla rete/sotto-rete logica cui sono collegati ad un default router. In tal caso laloro tabella di instradamento conterrà una sola strada per tutte le destinazionidiverse da quelle appartenenti alla loro stessa rete/sotto-rete logica;

- sia da router con una tabella di discrete dimensioni ma che tuttavia non copretutte le possibili destinazioni; quando a tali sistemi perviene un datagrammacon una destinazione non contemplata dalla tabella, essi rilanciano taledatagramma verso un default router.

Con riferimento alla tabella del router R2, mostrata nella Fig. 9, qualoraesistessero altre reti logiche interconnesse, oltre a quelle mostrate in figura, latabella stessa dovrebbe contenere:

- o altre righe, una per ogni altra rete logica interconnessa;- o una sola altra riga strutturata come segue:

Tutte le altre destinazioni Rilanciare verso l’indirizzo IP del default

router X

Tab. 5: Riga da aggiungere alla tabella di instradamento di R2

Nella Tab. 5 il default router X dovrebbe essere opportunamenteidentificato; la tabella di instradamento di X dovrebbe contenere leinformazioni necessarie per raggiungere tutte le altre destinazioni noncontemplate nella tabella di R2. Eventualmente tale meccanismo può essereusato in modo ricorsivo e quindi X può instradare datagrammi diretti versodestinazioni non conosciute da X stesso verso un altro router Y che svolgerebbequindi funzioni di default router di X.

Rimane da citare un caso speciale; come visto nel § III.4.1, è possibilechiedere che un datagramma segua un pre-determinato percorso per arrivare adestinazione (contenuto nel campo Source Route Option); in altre parole almomento dell’invio di un datagramma è possibile richiedere che esso passiattraverso una pre-definita serie di host e/o router. Ciò serve per scopi dicontrollo e di gestione.

Con queste premesse si può definire l’algoritmo di instradamento che ungenerico host o router, attua per ogni datagramma che riceve (assumiamo che ilsistema in questione abbia un indirizzo IP uguale a X).

Quando un sistema riceve un datagramma possono verificarsi dueeventualità:

64

- il datagramma ha come destinazione finale il sistema in questione;- il datagramma ha come destinazione finale un altro sistema e il sistema in

esame deve quindi rilanciarlo verso tale destinazione.Ambedue queste possibilità devono essere previste dall’algoritmo di

instradamento che è quindi:

Algoritmo attuato da X quando riceve un generico datagramma con indirizzo di

destinazione Y

1) estrai l’indirizzo IP di destinazione dal datagramma (=Y);2) se è stata richiesta una strada specifica (nel campo Source Route Option)

invialo verso tale strada;3) se l’indirizzo di destinazione, Y, coincide con X (cioè con se stesso), estraine

il contenuto informativo e consegnalo agli strati superiori per l’ulterioreelaborazione;

4) decrementa il Time to Live del datagramma (cfr § III.4.1); se il Time to Liveè arrivato a zero scarta il datagramma e danne comunicazione all’hostmittente (utilizzando il protocollo ICMP, cfr. § III.4.6);

5) altrimenti determina la componente Net_Id.Sub_Net_Id dell’indirizzo Y(usando la maschera di sotto-rete);

6) se la componente Net_Id.Sub_Net_Id di Y coincide con la corrispondentecomponente di X, invia il datagramma direttamente (cioè con instradamentodiretto; ciò implica tradurre l’indirizzo IP Y in indirizzo locale ed incapsulareil datagramma nell’unità di dati della sotto-rete in questione; in tal caso vienepresa in considerazione anche la componente Sub_Host_Id);

7) altrimenti, consulta la tabella di instradamento; se la componenteNet_Id.Sub_Net_Id di Y è compresa nella tabella di instradamento, instradail datagramma come specificato nella tabella;

8) altrimenti verifica se almeno la componente Net_Id è compresa nella tabelladi instradamento; in caso positivo instrada il datagramma come specificatonella tabella (nel caso in cui la componente Sub_Net_Id ha dimensioni nullequesto passo e il precedente si fondono nella stessa operazione);

9) altrimenti, se è stata specificata una strada di default, invia il datagramma aldefault router;

10) altrimenti dichiara un errore di instradamento (invocando eventualmenteICMP, cfr. III.4.6) e scarta il datagramma.

La definizione completa dell’algoritmo richiede delle precisazioni:- il passo 2, e cioè il caso di richiesta di una strada specifica, implica che X

65

deve instradare il datagramma seguendo le indicazioni contenute nel campoSource Route Option e non quelle che la sua tabella di instradamentosuggerisce per raggiungere la destinazione finale. Ciononostante deve tenersempre conto della sua tabella per instradare il datagramma verso il primohost o router specificato nella sequenza richiesta nel campo Source RouteOption; ad esempio un utente di X potrebbe voler inviare un messaggio a sestesso (per scopi di prova), facendolo però passare per un router Z; in tal casoX deve inviare il datagramma non alla destinazione finale (e cioè a X stesso)ma a Z, il quale poi lo ri-invierà a X;

- il passo 3, e cioè determinare se un datagramma è diretto a X stesso, vaulteriormente specificato; infatti, in primo luogo, un generico sistema puòavere più indirizzi (almeno due nel caso di un router), in secondo luogo Xpuò ricevere anche datagrammi di tipo broadcast e multicast; in entrambiquesti casi l’indirizzo di destinazione non coincide con X, ma X devecomunque accettare tali datagrammi, estrarne il contenuto informativo econsegnarlo agli strati superiori per l’ulteriore elaborazione;

Un’ultima questione è la seguente: l’algoritmo esposto riguarda sia un hostche un router e teoricamente è valido per entrambi. In pratica però possonoesserci delle differenze, dovute al fatto che in un host non sono implementati, ingenerale, tutti i protocolli che invece sono presenti in un router. Ad esempio, latabella di instradamento di un host è tipicamente configuratadall’amministratore di rete e non viene aggiornata dinamicamente. Nei router,invece, opportuni protocolli contribuiscono a creare e a mantenere aggiornate letabelle di instradamento (cfr; § III.4.5.4). D’altra parte ciò è naturale dalmomento che il router è preposto a svolgere funzioni che un generico host non ètenuto ad eseguire. Ciò premesso, ci si può chiedere se è opportuno che un hostsvolga comunque tutte le funzioni previste nell’algoritmo di instradamento. Inparticolare bisogna decidere se un generico host (non un router, ovviamente)deve rilanciare un datagramma non diretto a se stesso, contribuendo quindi inmodo attivo a gestire comunicazioni altrui. In tal caso l’host svolgerebbe difatto alcune funzioni di un router. La risposta è che si deve cercare di evitarlo.Questo per le seguenti ragioni:

- se un host riceve un datagramma non inviato a se stesso vuol dire che si èverificato un errore di instradamento, se l’host vi pone rimedio è difficile poiper il gestore di rete individuare l’errore;

- instradamenti addizionali rispetto a quelli previsti aumentano il trafficoglobale e sottraggono risorse di calcolo agli utenti degli host;

- i router si scambiano continuamente messaggi di errore e messaggi per crearee mantenere consistenti le tabelle di instradamento, gli host, in generale, no;

66

se un host instrada datagrammi senza partecipare a questo scambio diinformazioni, e quindi in sostanza ignorando lo stato della inter-rete in undato momento, si possono verificare situazioni di malfunzionamento anchegravi. Ad esempio, se un host accidentalmente manda in broadcast unmessaggio originariamente destinato ad un host X e tutti gli altri host (e nonsolo i router) rilanciano i datagrammi che gli pervengono, allora tutti gli hostcui arriva tale datagramma ne invieranno una copia a X che si vedrà quindirecapitare un elevato numero di copie dello stesso messaggio.

In conclusione un host, all’atto della ricezione di un datagramma, applicatipicamente solo i seguenti passi:

1) estrai l’indirizzo IP di destinazione dal datagramma (=Y);2) se l’indirizzo di destinazione, Y, coincide con X (cioè con se stesso), estraine

il contenuto informativo e consegnalo agli strati superiori per l’ulterioreelaborazione;

3) altrimenti dichiara un errore di instradamento e scarta il datagramma.

L’algoritmo di instradamento che un generico host o router, attua per ognidatagramma che genera esso stesso è simile a quello applicato per i datagrammiricevuti:

Algoritmo attuato da X quando genera un datagramma con indirizzo di destinazione Y

1) se è stata richiesta una strada specifica (nel campo Source Route Option)invialo verso tale strada;

2) se l’indirizzo di destinazione, Y, coincide con X (cioè con se stesso), estraineil contenuto informativo e consegnalo agli strati superiori per l’ulterioreelaborazione (può accadere per ragioni particolari, ad es. di controllo);

3) altrimenti determina la componente Net_Id.Sub_Net_Id dell’indirizzo Y(usando la maschera di sotto-rete);

4) se la componente Net_Id.Sub_Net_Id di Y coincide con la corrispondentecomponente di X, invia il datagramma direttamente (cioè con instradamentodiretto; ciò implica tradurre l’indirizzo IP Y in indirizzo locale ed incapsulareil datagramma nell’unità di dati della sotto-rete in questione; in tal caso vienepresa in considerazione anche la componente Sub_Host_Id);

5) altrimenti, consulta la tabella di instradamento; se la componenteNet_Id.Sub_Net_Id di Y è compresa nella tabella di instradamento, instradail datagramma come specificato nella tabella;

6) altrimenti verifica se almeno la componente Net_Id è compresa nella tabelladi instradamento; in caso positivo instrada il datagramma come specificato

67

nella tabella (nel caso in cui la componente Sub_Net_Id ha dimensioni nullequesto passo e il precedente si fondono nella stessa operazione);

7) altrimenti, se è stata specificata una strada di default, invia il datagramma aldefault router;

8) altrimenti dichiara un errore di instradamento, notificandolo agli stratisuperiori (di X stesso) e scarta il datagramma.

In conclusione, è utile sottolineare quanto segue. In IP, ildisaccoppiamento tra la fase di determinazione delle tabelle di instradamento(cfr. III.4.5.4) e la relativa consultazione, fa si che, di fatto, non e' necessarioattuare la funzione decisionale per ogni datagramma. In altri terminisupponendo che in un certo intervallo di tempo la tabella di instradamento nonmuti, allora il processamento di un datagramma IP non è poi operativamentemolto diverso da quello di un modo orientato alla connessione (come adesempio ATM). In entrambi i casi, un opportuno campo dell'intestazione(indirizzo di destinazione in IP, VPI/VCI in ATM) funge da puntatore ad unatabella la quale fornisce l'identificativo della linea di uscita su cui instradarel'unità informativa. La differenza sta nelle dimensione del campo e nellemodalità di ricerca, queste ultime possono essere più efficienti in ATM che nonin IP. In particolare, in IP, la scansione della tabella per ricercare l'informazionevoluta avviene mediante la tecnica del "longest prefix matching". Bisogna cioècercare un campo di dimensioni variabili; infatti l'algoritmo di instradamentoparte dell'indirizzo IP di destinazione e cerca nella tabella la più lunga stringa incomune con l'indirizzo di destinazione, a partire dai bit più significativi. Lacoincidenza tra indirizzo di destinazione e stringa trovata nella tabella puòessere completa, riguardare solo la parte Net_ID, o essere nulla. Invece, inATM o in altri protocolli con connessione l'operazione eseguita è denominata"table lookup" e riguarda un campo di dimensioni costanti. E' evidente chequest'ultima operazione è alquanto più semplice del "longest prefix matching"(cfr. IV.2).

Per mostrare come sia di fondamentale importanza limitare la complessità deimeccanismi di instradamento si ritiene opportuno illustrare come la tecnica del “supernetaddressing” sia implementata nelle tabelle di instradamento. Si è detto che per limitare l’usodi reti logiche di classe B si è deciso di consentire una certa violazione della suddivisione inclassi degli indirizzi IP (“supernet addressing”, cfr. § III.4.3). Ovvero si è permesso diattribuire più reti logiche ad una stessa organizzazione. In tal modo una data organizzazione,invece di chiedere una rete logica di classe B e non utilizzare tutti i relativi indirizzidisponibili, può chiedere un certo numero di reti logiche di classe C, fino a soddisfare le sueesigenze. Affinché però questo insieme di reti logiche appaia all’esterno come un’unica retelogica è stato necessario introdurre alcune modifiche ai protocolli di instradamento; questo

68

modo di operare è stato denominato “classless interdomain addressing (o routing)”.In teoria non sarebbe però necessaria alcuna modifica a quanto esposto sinora; tutte le

reti logiche di classe C, relative alla stessa organizzazione, sarebbero contemplate nelle tabelledi instradamento e tutte avrebbero la stessa informazione di instradamento; ovvero siavrebbero tante coppie (R,I) con diversi valori di R, ma con lo stesso valore di I. Siccome sivuole però limitare la dimensione delle tabelle, al fine di diminuire il tempo di ricerca nellestesse, è stato introdotto il classless interdomain addressing, il quale consente di inglobaretutte le reti logiche di una stessa organizzazione in una singola informazione di instradamento.Se ad esempio, tutti gli indirizzi IP da 194.0.0.0 a 194.255.255.255 sono assegnati all'Europa,per tutti i router fuori dall'Europa è sufficiente un'unica riga nella tabella di instradamento(contenente l'indirizzo 194.0.0.0 e la maschera 254.0.0.0) per indirizzare tutte le 65536 retilogiche di classe C attribuite all'Europa. La maschera identifica quali sono i bits daconsiderare significativi. All'interno dell'Europa, questi indirizzi possono poi essere assegnatiin blocchi contigui a diverse regioni geografiche o a specifici Internet Service Provider,diminuendo così le dimensioni delle tabelle di instradamento anche per i router interniall'Europa.

I relativi dettagli non sono qui esposti, ma il risultato è quello voluto: inserire nellatabella una sola riga per tutte le reti logiche coinvolte nella “supernet” (cfr [COM91]). Se siadotta tale metodologia gli algoritmi di instradamento devono però essere opportunamentemodificati. Infine si fa presente che il supernet addressing è applicabile non solo per aggregarereti logiche di classe C, ma anche per aggregare reti di classe B (e sostituire quindi una rete diclasse A).

Si sottolinea che, a seguito dell'introduzione di tale tecnica, la classificazione degliindirizzi in classi precedentemente esposta tende a divenire obsoleta. Gli operatori di retetendono a fare riferimento direttamente alle informazioni di instradamento contenute nelletabelle mediante la tecnica del "longest prefix matching" e quindi identificano le reti logichesemplicemente mediante le maschere di rete, indicando il prefisso comune e quindi evitandoun esplicito riferimento alla classe. Tutte le classi C dell'esempio appena riportata appaiono airouter esterni all'Europa come un'unica rete logica, di una classe che non è tra quelleprecedentemente definite. Ciò giustifica anche il nome "classless". Infine, si nota che talemodo di operare equivale ad introdurre un (parziale) legame tra indirizzi IP e posizionegeografica, contrariamente alle scelte originali (cfr. III.4.5.4); è evidente che tale legamefacilita l'instradamento, ma pone vincoli sull'assegnazione degli indirizzi stessi. Ad esempio,nel caso delle reti telefoniche, il prefisso telefonico internazionale identifica una data nazione;all’interno di questa, il prefisso interurbano identifica un distretto e il numero di utente siriferisce ad uno specifica linea all’interno di quel distretto. Questo modo di operare semplificanotevolmente la ricerca di una strada verso una data destinazione.

III.4.5.4 Determinazione delle tabelle di instradamento

Una volta precisate le procedure operative con cui host e router inviano idatagrammi verso le destinazioni volute, disponendo di tabelle diinstradamento, occorre stabilire come queste ultime vengono definite.

Le tabelle di instradamento sono, in generale, dinamiche; all’attodell’accensione, ogni sistema (host o router) inizializza la sua tabella diinstradamento (o per mezzo di informazioni conservate in un dispositivo dimemoria di massa o interrogando degli opportuni server). In seguito, i sistemiche dispongono di opportuni protocolli, detti protocolli di instradamento,aggiornano o incrementano le loro tabelle con nuove informazioni di

69

instradamento. Una singola informazione di instradamento consiste di unacoppia (R,I) dove R è l’indirizzo della rete logica di destinazione e I èl’indirizzo IP completo del prossimo router lungo la strada che porta alla sotto-rete di destinazione.

Come accennato in precedenza, sono solo i router che devononecessariamente rilanciare datagrammi generati da altri sistemi; le funzioni diinstradamento che i router devono svolgere, sono quindi più complesse diquelle eseguite dagli host. I router devono cioè eseguire nella sua completezzal’algoritmo descritto nel paragrafo precedente. Inoltre un host ha, in generale,una sola interfaccia di rete e quindi non deve anche decidere verso qualeinterfaccia inviare un dato datagramma. Viceversa un router dispone perdefinizione di più interfacce di rete (ovvero di diversi collegamenti verso altresotto-reti) e deve perciò necessariamente scegliere verso quale di queste inviareun dato datagramma. Esso svolge cioè le stesse funzioni logiche che, in altrereti di telecomunicazioni (ed anche all’interno di alcune sotto-reti checostituiscono Internet), sono svolte da sistemi denominati commutatori. A partela differenza di nomenclatura, un router infatti non è altro che un commutatore,anche se, per principi architetturali e tecnica costruttiva è alquanto diverso da,ad esempio, un commutatore telefonico. D’ora in avanti si farà quindi esclusivoriferimento ai router.

In aggiunta all’informazione contenuta in una generica coppia (R,I), unrouter ha anche bisogno di conoscere quale interfaccia di rete usare perraggiungere il sistema I. Ovvero, verso quale sotto-rete, tra quelle a cui èdirettamente collegato, inviare un generico datagramma per fargli raggiungere ilsistema I. L’informazione di instradamento completa sarà perciò: perraggiungere la rete logica con Net_Id R, invia il datagramma verso il sistema I,usando l’interfaccia di rete F. Da un punto di vista operativo, la coppia (R,I)diventa quindi una terna (R,I, F). Il terzo elemento, F, può essere contenutonella tabella di instradamento stessa, oppure può essere tenuto in contomediante altre soluzioni implementative.

Un router può implementare o meno i protocolli di instradamento. Nelsecondo caso la tabella di instradamento sarà definita manualmentedall’amministratore di rete e resterà invariata fino a successive operazioni digestione, eseguite sempre da un operatore. Nel primo caso invece i protocolli diinstradamento si occupano automaticamente di acquisire nuove informazioni diinstradamento (ovvero terne (R,I, F)) e di aggiornare di conseguenza le tabelle.

La seconda soluzione è tipicamente adottata in router di piccoledimensioni ed in zone dell’inter-rete che possano essere consideraterelativamente stabili, sia dal punto di vista della configurazione fisica che da

70

quello della tipologia e della quantità del traffico smaltito. L’amministratore direte configura opportunamente le tabelle in base ad informazioni in suopossesso e non vi è altro da aggiungere.

Nel seguito ci occuperemo quindi della prima soluzione, in cui le tabellesono create ed aggiornate per mezzo dei protocolli di instradamento.Osserviamo però che sono comunque possibili soluzioni miste, in cui una primaconfigurazione è manuale ed i successivi aggiornamenti sono governati daiprotocolli di instradamento.

I protocolli di instradamento esaminano la configurazione della inter-rete,ed eventualmente lo stato di occupazione delle risorse dei sistemi componenti,ad intervalli di tempo pre-definiti. In seguito a tali operazioni, definiscono leinformazioni di instradamento, che quindi sono aggiornate nel tempo, e lecomunicano ai router coinvolti. Fisicamente, i protocolli di instradamento sonotipicamente implementati negli stessi sistemi che svolgono funzioni di router.

Quando un protocollo di instradamento determina una strada per una datadestinazione, e la comunica ad un router, il router stesso la memorizza nella suatabella e continua ad utilizzarla per un tempo pre-definito. Trascorso tale tempo,a meno che la stessa strada non gli sia comunicata di nuovo, il router potrà nonritenerla più valida. Se la strada cambia (ad esempio a causa di un guasto o diuna modifica dell’inter-rete), i protocolli di instradamento se ne accorgeranno ecomunicheranno al router la relativa nuova informazione di instradamento. Sela strada per raggiungere una data destinazione cambia prima che il router nericeva comunicazione, può succedere che un datagramma venga inviato versouna strada non corretta. In tal caso, un opportuno messaggio di errore, generatodal protocollo ICMP (cfr § III.4.6), notificherà al router questo evento. Ilprocesso di aggiornamento delle tabelle continua finché i router rimangono inattività. In seguito ad un eventuale disattivazione il processo ricomincia.

La necessità di un aggiornamento dinamico è dovuta al fatto che Internetnon può essere considerata stabile, nuovi host e sotto-reti vengono aggiunti odeliminati frequentemente e molti percorsi che prima erano disponibili possononon esserlo più o viceversa. Inoltre, in caso di guasti, alcune strade non sonoutilizzabili. Infine, se i protocolli di instradamento usano un algoritmoadattativo (cfr [BLE]), allora l’aggiornamento deve anche tener conto dellostato di occupazione delle risorse di rete. Le tabelle di instradamento devonoquindi essere aggiornate continuamente, anche ad intervalli di pochi secondi. Inconclusione, i protocolli di instradamento possono quindi essere definiti comequei protocolli che consentono ai router di comunicare tra loro al fine didefinire le strade da usare per rilanciare i datagrammi verso le destinazionivolute.

71

La questione di creare e mantenere consistenti le tabelle di instradamento èdi per se molto complessa; se inoltre si vuole che le decisioni di instradamentosiano sempre ottimizzate in funzione di distanza, affidabilità, efficienza equalità di servizio allora il problema può apparire insolubile in terminieconomicamente accettabili. Una descrizione completa di tali meccanismi èmolto al di là degli scopi di questa trattazione. Nel seguito si forniranno perciòsolo alcuni concetti di base.

La rete ARPANET, nucleo originario di Internet, era di dimensionilimitate; inoltre essa era amministrata da un’unica autorità, che poteva decidereautonomamente come gestire la rete e garantire che tutti i possibili percorsifossero mantenuti consistenti e percorribili. Con il passare del tempo Internet siè estesa e comprende non solo diverse autorità amministrative, ma anchediverse nazioni. Finora abbiamo considerato gli host e i router di Internet soloin termini tecnici; siamo ora costretti a introdurre anche delle entitàamministrative. Al fine di definire con più dettaglio i protocolli diinstradamento dobbiamo quindi introdurre una nuova definizione:

si definisce come sistema autonomo un insieme di host, router esotto-reti controllate da un’unica autorità amministrativa; sidistinguono quindi router interni ad un sistema autonomo e routeresterni a questo

Un’autorità amministrativa è libera si scegliere qualsiasi protocollo diinstradamento, all’interno del suo sistema autonomo; i sistemi autonomi usanoquindi, in generale, diversi protocolli di instradamento. Ogni sistema autonomodeve però affidare in modo specifico ad uno o più dei suoi router il compito diinformare il mondo esterno della sua topologia, cioè comunicare quest’ultimaagli altri sistemi autonomi e nella fattispecie ad uno o più router all’uopodedicati da ognuno degli altri sistemi autonomi. Questi router “di frontiera”hanno perciò il compito di consentire il colloquio tra sistemi autonomi diversi equindi tra diversi protocolli di instradamento. Si può fare un paragone tra igenerici router sinora trattati e quelli di frontiera.

Cosi’ come i router consentono il colloquio tra sotto-reti diverse, così irouter di frontiera consentono il colloquio tra sistemi autonomi diversi, conriferimento però solo alle informazioni di instradamento. Un router di frontieracontinua a svolgere anche le normali funzioni di un router generico.

La nozione di sistema autonomo ha portato a definire due classi diprotocolli di instradamento usati per creare ed aggiornare le tabelle diinstradamento:

- Interior Gateway Protocols (IGP), usati all’interno di un sistema autonomo

72

(questa dizione risente della precedente nomenclatura usata per indicare irouter, e cioè gateway)

- Exterior Gateway Protocols (EGP) usati per le comunicazioni tra routerappartenenti a diversi sistemi autonomi e deputati allo scambio diinformazioni per informare i rispettivi sistemi autonomi della topologia dialtri sistemi autonomi e viceversa.

Nel seguito si discuteranno queste due classi di protocolli.Per meglio comprendere quanto segue è utile definire la nozione di

instradamento basato su informazioni parziali. Il concetto alla base di questoinstradamento è che non è necessario disporre in ogni router di informazioni diinstradamento riguardanti tutte le possibili destinazioni. L’importante è che taliinformazioni siano “consistenti” e che tutte le destinazioni siano prima o poicontemplate in almeno uno dei router coinvolti. Ad esempio in un incrociostradale non sono riportate le indicazioni per andare ovunque, ma solo uninsieme ristretto di destinazioni e bisognerà, in generale, attraversare diversiincroci prima di vedere apparire l’indicazione per una data destinazione finale.

L’instradamento con informazioni parziali funziona dunque se prima o poiconduce ad un router dove è contemplata la destinazione finale di interesse,ovvero se le informazioni fornite sono consistenti.

In Internet esistono alcuni router, detti “router di nucleo” (core router) checontengono informazioni di instradamento sufficienti per inviare undatagramma verso qualunque destinazione. Ogni sistema autonomo devecomunicare ai core router quali reti logiche fanno parte del sistema autonomostesso. In tal modo quando ad un core router si chiede un’informazione diinstradamento relativa ad una data rete logica X, il core router è a conoscenzache quella rete logica si trova in un dato sistema autonomo Y; esso può quindicomunicare al richiedente che la rete logica X si trova nel sistema autonomo Y.Un datagramma che ha come destinazione la rete logica X, potrà quindi essereinviato ad un router di frontiera del sistema autonomo Y; qui arrivato, iprotocolli di instradamento interni al sistema autonomo Y potranno suggerire lastrada per arrivare alla rete logica di destinazione.

Il vantaggio principale dell’instradamento con informazioni parziali è cheevita di dover fornire a tutti i router le informazioni per raggiungere tutte ledestinazioni. Il suo svantaggio è che a volte può succedere di dover transitareper un dato router, dove sono citate tutte le informazioni di instradamento,anche se esiste una strada più breve per arrivare a destinazione.

Ciononostante, la questione di assicurare la consistenza di un sistemacomplesso come Internet rimane complessa, anche perché la Net_Id di unindirizzo non è strutturata in modo gerarchico, né esiste necessariamente (cfr.

73

fine del III.4.5.3) una corrispondenza, pre-fissata e deducibile dall’esamedell’indirizzo, tra una Net_Id e la posizione geografica della relativa sotto-rete.Ad esempio le reti logiche 151.100 e 153.100 possono trovarsi in Italia, mentrela rete logica 152.100 potrebbe trovarsi ovunque nel mondo.

Le comunicazioni tra sistemi autonomi e core router sono effettuatemediante gli Exterior Gateway Protocol; l’instradamento all’interno di unsistema autonomo e la raccolta di dati da inviare ai core router avviene permezzo degli Interior Gateway Protocols. I messaggi di tutti protocolli diinstradamento sono sempre trasportati all’interno di datagrammi IP.

Alcuni tra i più importanti Interior Gateway Protocols sono:- GGP- SPREAD- SPF e OSPF- RIP- HELLO

Il modo in cui questi protocolli determinano le tabelle di instradamento può esserevario; si possono utilizzare diversi algoritmi, ognuno dei quali ha i suoi pro e contro.

Il GGP (Gateway to Gateway Protocol) era usato originariamente in ARPANET.GGP misura la distanza tra origine e destinazione in “salti”, ovvero in numero di sotto-

reti da attraversare, ed usa un algoritmo, detto di Bellman-Ford, che determina la strada daseguire minimizzando il numero di salti; uno dei suoi svantaggi è che non è detto che unnumero inferiore di salti equivalga ad una strada più veloce e/o più breve; ricordiamo che lesotto-reti non sono tutte uguali; ve ne sono di lente e di veloci, di grandi e di piccole, dicongestionate e di non congestionate. Per alleviare questo problema, molti router GGPattribuiscono artificialmente ad una rete con un elevato ritardo di trasferimento un numero di“salti” maggiore di uno. Il ritardo di trasferimento qui considerato è uno di riferimento,costante; non sono tenute in considerazioni situazioni di congestione; in altre parolel’algoritmo non è adattativo. Un altro svantaggio di GGP è che non è facilmente scalabile ecioè, all’aumentare delle dimensioni del sistema autonomo, le sue prestazioni peggioranorapidamente. I tempi di risposta sono elevati ed è richiesta una rilevante mole di scambi dimessaggi.

SPF (Shortest Path First) richiede che ogni router conosca tutta la topologia di rete,rappresentata con un grafo; dal momento che la topologia cambia continuamente (per guastied aggiunte od eliminazioni di collegamenti e di host), un continuo scambio di messaggimantiene aggiornata la topologia memorizzata da ogni router. La strada migliore viene poideterminata localmente (dato che ogni router conosce l’intera topologia) grazie ad unalgoritmo detto di Dijkstra, che calcola la più breve distanza verso la destinazione, secondodiversi criteri.

Il principale vantaggio di questo algoritmo è la velocità; al momento di determinare unastrada l’algoritmo risponde immediatamente senza bisogno di interrogare altri router. Losvantaggio principale è che per mantenere aggiornata la topologia di rete, è necessario uncontinuo scambio di messaggi, anche quando non ve ne è bisogno.

OSPF (Open Shortest Path First) è una estensione di SPF. I suoi principali vantaggi

74

sono: a) è disponibile gratuitamente, al contrario di SPF che è proprietario; b) includel’instradamento basato sul Service Type e quindi tiene conto delle richieste degli utenti intermini di prestazioni (cfr § III.4.1); c) consente di bilanciare il carico in rete; d) consente didividere gerarchicamente un sistema autonomo; e) le sue comunicazioni prevedonoun’autenticazione per garantire la sicurezza.

RIP (Routing Information Protocol) è simile a GGP, minimizza la distanza in salti traorigine e destinazione e, come GGP, aumenta artificialmente il numero di salti di un camminoattraverso reti “lente”. RIP mantiene una tabella di instradamento in ogni sistema, questatabella è aggiornata ogni 30 secondi con informazioni ricevute dai sistemi vicini. È uno deiprotocolli più usati, non perché abbia particolari vantaggi rispetto agli altri, ma perché è statodistribuito insieme al sistema operativo Unix, godendone la popolarità.

HELLO è un esempio di protocollo in cui la metrica usata per valutare la distanza èbasata sul ritardo di attraversamento piuttosto che sul numero di salti. Per ritardo diattraversamento si intende quello attualmente subito in un dato momento e quindi HELLOtiene conto di eventuali condizioni di congestione, ovvero è adattativo. Per fare questoHELLO deve innanzi tutto sincronizzare i clock dei diversi router e poi far si che i router sicomunichino non solo informazioni topologiche ma anche informazioni relative al ritardo diattraversamento; ciò viene realizzato mediante l’uso di indicazioni temporali, dette “time-stamps”. Come anche altri protocolli, HELLO può soffrire di instabilità, se cambia troppovelocemente le strade che consiglia di usare. Se una strada è libera allora un router vi indirizzamolto traffico, allora tale strada diviene congestionata e il router indirizza il traffico versoun’altra strada; ma allora la strada di prima torna ad essere libera e così via.

Per evitare queste oscillazioni i cambiamenti delle strade consigliate non sono moltoveloci e il cambiamento avviene solo se esiste una rilevante differenza tra le due strade.

Uno dei più comuni Exterior Gateway Protocols ha lo stesso nome:L'Exterior Gateway Protocol (EGP) svolge tre funzioni:

- individuazione dei router adiacenti con cui scambiare le informazioni di instradamento; peradiacenza si intende quella logica; i router delegati allo scambio di informazioni possonoessere separati anche da altri router;

- verifica continua della funzionalità dei router interlocutori;- scambio periodico delle informazioni di instradamento, contenute in appositi messaggi;

queste riguardano la sola raggiungibilità delle reti, non la distanza.EGP non consente ad un router “non-core” di comunicare strade al di fuori del suo

sistema autonomo; un router “non-core” può comunicare solo strade appartenenti al sistemaautonomo di cui fa parte. EGP non tiene conto di una metrica di distanza, comunica solo unastrada da seguire. Dal momento che non può sapere se una strada conviene rispetto ad un’altrane comunica una sola. Da ciò deriva anche la ragione per cui un router “non-core” puòcomunicare solo strade appartenenti al sistema autonomo di cui fa parte. Infatti, dal momentoche ogni IGP può usare una sua metrica, diversa da quella usata in altri sistemi autonomi, nonavrebbe senso per un router “non-core” comunicare strade attraverso altri sistemi autonomi(visto che non ne conosce le relative prestazioni in termini di prestazioni del trasferimento didati, ad esempio del ritardo).

Il protocollo BGP (Border Gateway Protocol) è una evoluzione dell'EGP. Per loscambio di messaggi tra le entità vengono utilizzati i servizi di trasporto offerti da TCP. Ilprotocollo effettua la verifica dello stato di un collegamento o di un host inviandoperiodicamente messaggi detti di “keep alive“ (il periodo raccomandato è di 30 sec.). Rispettoa EGP, fornisce funzionalità aggiuntive: le informazioni sulla raggiungibilità delle sotto-retidi destinazione includono il percorso completo che il traffico deve seguire attraverso un

75

sistema autonomo per raggiungere determinate sotto-reti di destinazione. Queste informazionisono sufficienti a costruire il grafo di connettività dei sistemi autonomi; eventuali percorsichiusi (loop) possono essere poi rivelati ed eliminati con opportune politiche di gestione.L'informazione sulla raggiungibilità delle reti ha ovviamente maggior impatto nel caso in cuisia presente, lungo il percorso tra un sistema autonomo sorgente e uno di destinazione, uncerto numero di altri sistemi autonomi con funzioni di transito; in caso contrario l'impiego diBGP od EGP è pressoché equivalente.

Il protocollo BGP consente di utilizzare opportune politiche di restrizione per il trafficoin transito, stabilite dal gestore del sistema e codificate in tabelle di configurazione. Ciòconsente al protocollo una scelta tra i diversi instradamenti eventualmente disponibili e lapossibilità di effettuare una opportuna ri-distribuzione del traffico.

Infine, al processo di instradamento prende parte anche l’ICMP. Infatti,oltre a notificare al mittente l’eventuale mancato recapito di un datagramma, ilprotocollo ICMP prevede un messaggio per la modifica delle informazionicontenute nelle tabelle di instradamento. Qualora un datagramma vengainstradato erroneamente verso un router, quest’ultimo provvede ad inviare allasorgente un opportuno messaggio ICMP, che modifica le informazioni dellatabella di instradamento del mittente (cfr § III.4.6).

III.4.6� Messaggi di errore e di controllo (ICMP)

Come già detto, il protocollo IP non è affidabile. Se un router non riesce adinstradare o a consegnare un datagramma o se riscontra situazioni anomale (tracui congestione di rete) deve poter notificare tali eventi al mittente deldatagramma, affinché siano attuate opportune operazioni per correggere ilproblema. Se un host di destinazione è stato disattivato, il mittente di undatagramma inviato verso tale host deve esserne informato. Si ricorda ancheche, in questo capitolo, con il termine sistema si indica in modo indifferenziatosia un host che un router.

Possibili problemi possono essere:- un dispositivo di rete (incluse le linee di collegamento) non funziona

correttamente o non funziona del tutto;- il sistema di destinazione è temporaneamente o permanentemente

disconnesso dalla rete;- il contatore del Time to Live arriva a zero;- i router o le linee intermedie sono talmente congestionate da non poter gestire

il traffico in transito.Per consentire ai sistemi di potersi scambiare informazioni circa tali

situazioni, è stato definito un apposito protocollo. Tale protocollo, denominatoInternet Control Message Protocol, (ICMP) è una parte integrante di IP e deveessere incluso in ogni implementazione di IP.

I messaggi di ICMP sono trasportati in rete per mezzo dei datagrammi IP.

76

Il messaggio ICMP viene incapsulato nella parte dati del datagramma IP. Esso ècostituito da una parte dati (ICMP Data) e da una intestazione, come è possibilevedere nella Fig. 10.

IntestazioneICMP

ICMP Data

⇓ ⇓ ⇓Intestazione IP IP Data

Fig. 10 - Trasporto dei messaggi ICMP all’interno di datagrammi IP

In caso di malfunzionamento della rete, ICMP provvede ad uno scambio dimessaggi fra i sistemi coinvolti per notificare l’errore o indicare le circostanzeinaspettate che causano un comportamento anomalo. I messaggi di ICMPviaggiano in rete secondo le stesse modalità seguite dal traffico di utente. Ildestinatario di un messaggio ICMP non è un programma applicativo od unutente ma è una entità dello strato IP. In altre parole ICMP fornisce i mezzi peruno scambio di informazione tra il software IP di un sistema ed ilcorrispondente software IP di un altro sistema. ICMP può quindi essereconsiderato un sub-strato di IP (visto che serve a trasportare messaggi tra dueentità IP) ma è funzionalmente al di sopra di IP (visto che i suoi messaggigovernano il funzionamento di IP).

ICMP può essere usato sia da router che da host (anche se per questi ultimisono previste alcune limitazioni). Il suo principale vantaggio è che fornisce unapiattaforma unica per lo scambio di qualsiasi informazione di controllo. Lafunzione di ICMP è solo di notifica degli errori al sistema di origine e nonspecifica le azioni che devono essere prese per rimediare agli errori ed aimalfunzionamenti; sarà poi il sistema di origine a porre in relazione ilparticolare errore con il relativo programma applicativo (ad esempio con unprotocollo di instradamento, o con IP) ed a decidere cosa fare per correggere ilproblema.

ICMP notifica eventuali errori solo al sistema che ha originato undatagramma e non a sistemi intermedi lungo la strada attraversata daldatagramma stesso. Questo perché ogni datagramma contiene solo l’indirizzodel mittente e quello della destinazione e quindi non è possibile, esaminando undatagramma, scoprire che strada ha percorso; questa informazione non puònemmeno essere ricavata dalle tabelle di instradamento, lette “a ritroso”, siaperché queste ultime cambiano continuamente, sia perché le tabelle riportano

77

solo un passo del cammino seguito e non il cammino completo. Ne segue che,quando un datagramma arriva ad un determinato sistema, quest’ultimo non hamodo di sapere che strada ha percorso il datagramma, ma solo da dove viene equindi può notificare un errore solo al sistema di origine del datagramma. Laconclusione è che, se causa del problema è un sistema intermedio, ICMP non lopuò identificare; può solo notificare che esiste un problema ma non quale è.

Un altro punto importante è che, siccome i messaggi di ICMP viaggianocome comuni datagrammi IP, anch’essi possono essere soggetti ad errore econtribuire alla congestione di rete. La procedura di gestione dei datagrammiprevede un’unica differenza tra i datagrammi che trasportano i messaggi ICMPe gli altri: non vengono generati messaggi ICMP in seguito ad errori causati dadatagrammi che trasportano messaggi ICMP; ciò serve ad evitare messaggi dierrore relativi a messaggi di errore.

Si tenga presente che ogni messaggio ICMP è in relazione ad uno specificodatagramma (e non potrebbe essere altrimenti visto che IP è un protocollo senzaconnessione); un messaggio ICMP contiene quindi anche un identificativo delparticolare datagramma che ha generato l’errore o la situazione anomala.

Alcuni dei messaggi previsti da ICMP e le loro funzioni sono i seguenti:- "Echo Request" e “Echo Reply"; un sistema che vuole verificare se un altro

sistema è raggiungibile (e quindi se la strada è percorribile) ed è attivo, inviaun messaggio "Echo Request"; il messaggio contiene anche una parte datiche può essere un insieme di caratteri casuali o predeterminati. Possibiliopzioni sono la lunghezza della parte dati ed il numero di messaggi di provainviati. Il sistema a cui perviene un "Echo Request" risponde con un “EchoReply", ri-inviando i dati che ha ricevuto; il sistema richiedente può cosìanche valutare eventuali statistiche sul trasferimento, come ritardo minimo,medio e massimo e grado di integrità informativa;

- "Destination Unreachable": viene emesso da un router per notificare alsistema mittente che non è in grado di instradare un datagramma; contiene uncampo che specifica perché la destinazione non è raggiungibile: rete osistema non raggiungibile, rete o sistema sconosciuti, segmentazionenecessaria ma non attuata perché il bit DF era posto ad 1 (cfr. Tab. 2), rete osistema non raggiungibile con il tipo di servizio richiesto (riportato nelcampo Service Type, cfr. ancora Tab. 2), proibizione amministrativa per lacomunicazione con una rete o un sistema, etc.;

- "Source Quench": il sistema destinazione informa il sistema sorgente che iltraffico generato è superiore alle sue capacità ricettive. Usualmente i sistemigenerano un "Source Quench" ogni volta che sono costretti a scartare undatagramma. Il messaggio contiene anche un identificativo del datagramma

78

che è stato scartato. La sorgente provvede a ridurre il numero di datagrammiinoltrati in rete finché smette di ricevere messaggi "Source Quench"; quandociò avviene la sorgente ritorna gradualmente verso il ritmo di emissioneoriginario;

- "Redirect": un router può informare un sistema sorgente che l'instradamentoprescelto non è il migliore o è sbagliato e ne notifica uno nuovo; questomeccanismo integra i meccanismi di inizializzazione ed aggiornamento delletabelle di instradamento descritti nel § III.4.5. Se una strada cambia ed unsistema invia erroneamente un datagramma lungo quella la strada, unmessaggio di "Redirect" risolve il problema. Inoltre grazie ai messaggi"Redirect" i sistemi possono imparare nuove strade. Si noti che,normalmente, solo gli host e non i router ricevono messaggi "Redirect"; irouter usano tipicamente i protocolli descritti nel § III.4.5;

- "Time Exceeded for a Datagram": serve ad informare l'host sorgente che undatagramma IP è stato eliminato dalla rete per aver superato il limitetemporale di esistenza nella rete (campo Time to Live, cfr Tab. 2); si ricordache lo scopo di questo campo è evitare che un datagramma possa percorrerepercorsi chiusi (loop) nella rete senza giungere a destinazione, o esseretrasferito in un tempo eccessivamente lungo;

- "Parameter Problem on Datagram": serve a comunicare ad un host sorgenteche sono stati rivelati errori nell'intestazione di un datagramma;

- "Timestamp Request" e "Timestamp Reply": il primo viene inviato da unasorgente per richiedere alla destinazione un’informazione temporale (tempolocale), il secondo viene utilizzato per la risposta; opportuni campi all’internodi questi messaggi consentono una sincronizzazione degli orologi dei duehost con un’accettabile precisione;

- "Information Request" e "Information Reply": originariamente utilizzati daglihost per ottenere l'indirizzo Internet delle reti logiche a cui sono collegate,attualmente si usano invece i protocolli RARP o BOOTP o DHCP;

- "Address Mask Request" e "Address Mask Reply": vengono utilizzati daglihost per richiedere ad opportuni server (tipicamente svolgenti anche funzionidi router) la “maschera di sotto-rete” (cfr; § III.4.5.1).

III.4.7� Domain Name System

Gli indirizzi IP di 32 bit sono quelli effettivamente usati dal protocollo IP(cfr § III.4.3). In alternativa a questi indirizzi abbiamo già descritto la notazionedotted.

Anche se quest’ultimo formato consente una più agevole rappresentazionedegli indirizzi, gli utenti preferiscono usare indirizzi ancora più facilmente

79

pronunciabili, memorizzabili e che, possibilmente, forniscano un’idea di doveun sistema si trova e a quale organizzazione appartiene.

Per tale ragione, in Internet è stato implementato un meccanismo checonsente di utilizzare, oltre alla notazione dotted, anche un altro tipo dinotazione. Ad esempio, un particolare sistema con indirizzo IP:

“10010111.01100100.00001000.00010010”

la cui relativa notazione dotted è:

“151.100.8.18”

può essere messo in corrispondenza con una ulteriore notazione, dettamnemonica:

“infocom.ing.uniroma1.it”

Si vede subito come un indirizzo espresso in questa forma alternativa (chenel seguito chiameremo nome), oltre ad essere più facilmente memorizzabiledagli utenti (umani), rende subito chiaro che si tratta di un sistema delDipartimento Infocom, della Facoltà di Ingegneria, dell’Università di Roma 1,dell’Italia. Inoltre, se gli amministratori di rete scelgono i nomi in modoopportuno, è possibile anche cercare di “indovinare” nomi non conosciuti. Lerelazioni tra questi tre tipi di notazione sono illustrati, per l’esempio specifico,in Fig. 11.

10010111 01100100 00001000 00010010

151. 100. 8. 18

infocom.ing.uniroma1.it

indirizzo IP

notazione dotted

notazione mnemonica o “nome”

Fig. 11 - Notazione mnemonica di un indirizzo IP, o nome

E’ importante sottolineare che l’indirizzo usato da IP è sempre una stringadi 32 bits e le altre due rappresentazioni devono essere preventivamente tradotte(o “risolte”) da opportuni protocolli prima di essere utilizzate da IP perl’effettivo scambio di informazione.

Il passaggio da notazione dotted a indirizzo di 32 bit (e viceversa) è banalein quanto implica una semplice conversione decimale-binario (o binario-decimale). La traduzione tra indirizzo IP binario (o dotted) e nome può essereinvece alquanto complessa. Questa traduzione è attuata da un protocollo di altolivello, implementato in un meccanismo denominato Domain Name System(DNS).

80

Il DNS può essere visto come un’agenda telefonica o come un elencotelefonico; siccome può essere difficile ricordare dei numeri telefonici, risultautile porli in corrispondenza con i nomi delle persone (o di enti) a cui sonoassociati. L’agenda telefonica di ognuno di noi, e anche un singolo elencotelefonico, contengono però solo un sotto-insieme dei numeri telefonici dellarete telefonica mondiale. Il DNS deve invece consentire di porre incorrispondenza qualunque nome con il relativo indirizzo IP. In definitiva ilDNS è simile ad un unico elenco telefonico, comprendente però tutti coloro chedesiderano esservi inseriti, a livello mondiale, consultabile in modo automaticoe senza che l’utente finale debba compiere operazioni specifiche. Infatti, gliutenti di Internet usano direttamente i nomi, senza avere nemmeno visibilità deiveri indirizzi IP che a questi corrispondono. Sono le applicazioni usate dagliutenti ad invocare il DNS e a chiedere a quest’ultimo le traduzioni nomi-indirizzi.

Il nucleo originale di Internet usava un insieme di nomi non suddivisogerarchicamente; i nomi erano assegnati da un’unica autorità centrale e lacorrispondenza nomi-indirizzi poteva essere contenuta in un unico archivio,memorizzato in un calcolatore che tutti potevano interrogare, o che potevaessere distribuito periodicamente. Come per altre problematiche affrontatesinora, la crescita di Internet ha costretto ha cambiare sistema.

L’analisi dell’attuale DNS è interessante, anche perché fornisce unesempio di una base di dati distribuita, organizzata gerarchicamente e secondoil paradigma client-server. DNS contiene infatti componenti client ecomponenti server. Quelle client sono tipicamente implementate nelleapplicazioni usate dagli utenti (ad. es. nei browser, cfr. II); quelle server sonoresidenti in opportuni sistemi che svolgono il servizio di traduzione a favore deiclient.

L’attuale DNS ha due aspetti; il primo è astratto, specifica la sintassi deinomi e le regole per decidere chi li attribuisce; il secondo specifical’implementazione di un algoritmo distribuito per tradurre o “risolvere” unnome in un indirizzo IP e viceversa. Corrispondentemente, il seguito di questoparagrafo è diviso in due parti: attribuzione dei nomi e traduzione dei nomi inindirizzi e viceversa. Ribadiamo ancora che, quando un utente chiede unacomunicazione verso un sistema, identificando quest’ultimo con un nome, ènecessario che il DNS traduca il nome nel relativo indirizzo IP, prima cheinizino tutte le operazioni poste in essere dai protocolli di comunicazione,incluso il protocollo IP. E’ sempre possibile, tuttavia, che un utente usidirettamente l’indirizzo IP di destinazione; in tal modo il DNS non saràinvocato e saranno possibili comunicazioni anche in occasioni di

81

malfunzionamento del DNS stesso. Capita infatti che un utente riceva unmessaggio di errore che gli comunica che un dato host non esiste, anche quandociò non è vero; in questi casi la responsabilità può essere del DNS ed ilproblema è superabile utilizzando direttamente l’indirizzo IP dell’host inquestione (se lo si conosce, ovviamente).

III.4.7.1 Attribuzione dei nomi

L’attuale DNS ha una struttura gerarchica; tale struttura sembra essere lapiù conveniente, se non l’unica praticabile, per gestire un insieme di nomi dielevata numerosità e variabile nel tempo. L’insieme dei nomi è primapartizionato in un certo numero di sotto-insiemi dall’INTERnet NetworkInformation Center (INTER-NIC); il compito di assegnare i nomi all’interno diuno di questi sotto-insiemi è delegato ad un’autorità di livello inferiore che puòpartizionare il suo sotto-insieme in altri sotto-insiemi e così via. Un nome èquindi composto da una serie di sotto-nomi separati da un punto. Ogni puntopuò separare un’autorità da quella che gli è gerarchicamente inferiore. Adesempio, INTER-NIC ha assegnato all’Italia il sub-nome “it” delegandoun’altra autorità ad assegnare tutti i nomi il cui ultimo sub-nome è “it”. Conriferimento all’esempio precedente, all’Università di Roma “La Sapienza” èstato assegnato il sub-nome “uniroma1”, alla Facoltà di Ingegneria è statoassegnato il sub-nome “ing”. Infine ad un particolare host del DipartimentoInfocom è stato assegnato il sub-nome “infocom”. Il nome risultante perquest’ultimo host è quindi “infocom.ing.uniroma1.it”.

Come si vede il principio gerarchico è utile e garantisce nel contempol’unicità dei nomi. Infatti, come per gli indirizzi IP, anche i nomi devono essereunici in tutta l’inter-rete.

È necessario sottolineare che la gerarchia con cui sono assegnati i nomi inInternet segue la struttura delle organizzazioni che sono responsabili di parti deldominio dei nomi e non è necessariamente in relazione con la struttura delleinterconnessioni fisiche.

Questo sia perché le sotto-reti fisiche non sono necessariamentegerarchiche sia perché la struttura fisica delle sotto-reti e la struttura gerarchicadelle autorità che assegnano i nomi non necessariamente coincidono.

Ad esempio un’unica rete in area locale di un’università potrebbeconnettere sia gli host del Dipartimento di Informatica che quelli delDipartimento di Elettronica. Ciononostante i relativi nomi possono essereorganizzati in modo gerarchicamente diverso.

Al primo livello gerarchico, l’insieme di tutti i nomi è stato diviso in unprimo numero di sotto-insiemi che consentono due tipi di classificazione, una

82

geografica ed una basata sulla tipologia delle organizzazioni che ne fanno parte.Ognuno di tali sotto-insiemi è denominato dominio di livello massimo (“toplevel domain”); i possibili top level domain sono riportati nella Tab. 6. Quelli aldi sotto della linea in grassetto, nella classificazione per tipologia, sono statiintrodotti recentemente e ancora poco diffusi.

Ognuno dei top level domain è quindi partizionato in un certo numero disub-domini; ognuno di tali sub-domini può a sua volta essere partizionato insub-sub-domini e così via.

Una generica organizzazione può scegliere di registrarsi secondo laclassificazione per tipologia o secondo la classificazione geografica (laclassificazione geografica degli Stati Uniti è ulteriormente divisa per gli statidella federazione: New York=NY, California=CA, Indiana=IN, etc.). Per motivistorici, le organizzazioni americane hanno scelto in maggioranza laclassificazione per tipologia (anche perché in un certo periodo questa eral’unica esistente), mentre quelli degli altri paesi hanno seguito prevalentementela classificazione geografica.

83

Classificazione per tipologia

Nome del dominio Tipo di organizzazione

COM Commerciali

EDU Accademiche e didattiche

GOV Statali

MIL Militari

NET Centri di gestione

ARPA ARPANET (obsoleto)

INT Organizzazioni internazionali

ORG Altre organizzazioni

FIRM Aziende, affari

STORE Merce in vendita

WEB Enfatizzante il WWW

ARTS Enfatizzante arte e cultura

REC Enfatizzante intrattenimento

INFO Enfatizzante fornitori di informazioni

NOM Enfatizzante nomenclature personali

classificazione geografica

Nome del

dominio

USA IT DE FR UK JP etc.

nazione USA Italia Germania Francia Gr. Bret. Giappone etc.

Tab. 6 - Classificazione dei nomi in domini

Ad esempio le Università di Columbia (New York), Berkeley (California)e Purdue (Indiana) hanno scelto come sub-domini columbia.edu, berkeley.edu epurdue.edu piuttosto che ny.usa, ca.usa e in.usa rispettivamente (anche perché èpiù significativa la prima scelta che ci fa capire che si tratta di organizzazioniaccademiche e ce ne dice il nome).

La Fig. 12 riporta un esempio di una parte dell’albero dei nomi (l'attualealbero conta diversi milioni di nomi). Ad esempio, “uniroma1” è un sub-dominio del top level domain “it”; “ing” è un sub-dominio di “uniroma1” equindi un sub-sub-dominio di “it”.

84

. Root Domain

usa

berkeley rutgers

... netmil org edu

cany

gov

nsf

com

ibm dec

it

uniroma1

ing

infocom

Fig. 12 - Esempio di parte dell’albero di nomi

Un nome nel DNS può essere in corrispondenza con diversi tipi diindirizzi. In altri termini ad ogni nome è assegnato un tipo che specifica se quelnome si riferisce ad un host, ad un mailer (cioè ad un sistema con compiti digestione della posta elettronica), etc. Quando la componente client di DNSchiede di risolvere un nome deve anche specificare che tipo di nome è. Adesempio quando un applicativo di posta elettronica chiede a DNS di risolvereun nome deve specificare che l’indirizzo che DNS fornisce in risposta deveessere quello di un “mailer” ovvero di un sistema che gestisce per gli utenti laposta elettronica; quando un applicativo TELNET chiede a DNS di risolvere unnome deve specificare che ai desidera l’indirizzo di un host con cui stabilire unasessione telnet. Inoltre un dato nome può riferirsi a più di un tipo di indirizzo.L’applicazione client di DNS che richiede una traduzione nome-indirizzo,specifica quindi anche il tipo del nome e la componente server risponde conl’indirizzo corrispondente a quel nome e di quel tipo.

Infine la sintassi del nome non ne specifica il tipo e il numero di sub-nomiche costituisce un nome non è fisso. Ad esempio può esistere un nomecomposto da due sub-nomi (uniroma2.it) o da tre sub-nomi (www.ibm.com) oda cinque sub-nomi (markov.istel.ing.unipg.it).

85

III.4.7.2 Traduzione dei nomi in indirizzi e viceversa

DNS include un affidabile ed efficiente algoritmo distribuito per tradurrenomi in indirizzi e viceversa. È distribuito in quanto è costituito da unamolteplicità di sistemi che co-operano tra loro. È efficiente in quanto moltinomi possono essere tradotti localmente senza generare traffico in Internet; èaffidabile in quanto il guasto di una singola macchina non pregiudica ilfunzionamento dell’intero sistema. In questo paragrafo ci occuperemo dellatraduzione (o risoluzione) di un nome in un indirizzo IP. L’operazione inversaprocede secondo modalità analoghe.

La parte server di DNS è costituita da un certo numero di sistemiindipendenti e co-operanti chiamati name server. Un name server non è altroche una componente server dell’algoritmo, eseguito da un generico calcolatore.Spesso tale programma è eseguito su di un calcolatore dedicato a questo scopoed allora il calcolatore stesso è denominato name server. La componente clientdell’algoritmo, denominato name resolver, usa uno o più name server pertradurre un nome. I name server sono organizzati logicamente secondo unastruttura gerarchica ad albero. La Fig. 13 mostra un esempio, avente scopoesclusivamente didattico, di una parte di tale struttura. I messaggi diinterrogazione e di risposta di DNS sono trasportati, come tutto il traffico inInternet, da IP ed usano come strato di trasporto il protocollo UDP.

��

��

��

��

��

��

��

��

��

��

� ��

Fig. 13 - Struttura gerarchica dei name servers

La radice dell’albero è un name server (denominato root server)responsabile dei top-level domain (definiti nella Tab. 6); ogni top-level domainè a sua volta servito da un name server ed il root server è in grado di identificare

86

quale name server è responsabile per ognuno di essi. Dato un nome da tradurre,il root server può quindi rivolgersi all'opportuno server di top-level domain(ovvero conosce l’indirizzo IP del server voluto). Al terzo livello troviamo iname-server responsabili di un sub-dominio. I server di secondo livelloconoscono l'indirizzo IP dello specifico server di terzo livello a cui rivolgersi.Ognuno dei server di terzo livello risponde solo della traduzioni di nomi delproprio sub-dominio. Ogni name server ha in memoria informazioni relativeagli host del dominio immediatamente inferiore.

L’albero continua così ad estendersi fino al livello dell’ultimo sub-sub-dominio esistente. Si noti che il name server di un certo livello gerarchico nondeve conoscere tutti i nomi degli host ad esso appartenenti; dato un nome datradurre, deve solo sapere a quale server di livello gerarchico inferiorerivolgersi, se ne esistono. Data la struttura gerarchica dei nomi ciò è abbastanzasemplice. Se, ad esempio si richiede al root server di risolvere il nome“infocom.ing.uniroma.it”, tale server indirizzerà la richiesta al serverresponsabile per il top-level domain “it”; questo indirizzerà la richiesta al serverresponsabile del sub-dominio “uniroma1.it” e cosi via finché si incontra unserver che conosce l’indirizzo del nome completo.

Le linee che uniscono i server nella Fig. 13 non corrispondononecessariamente a linee fisiche; esse mostrano solo le relazioni logiche tra iname server e quali altri server un dato name server può interrogare.

Nella pratica, i singoli server possono essere dislocati ovunque all’internodi Internet e spesso una stessa macchina svolge funzioni di name server perdiversi livelli gerarchici. Inoltre non è raro che un’organizzazione riunisca in ununico server le informazioni relative ai nomi di tutti i suoi sub-domini.

In altre parole, la struttura logica rappresentata in Fig. 13, non ènecessariamente quella reale; possono esserci eccezioni a qualunque livello.Ritroviamo qui un elemento comune ad altre caratteristiche di Internet. Nelcorso di questa trattazione si è cercato di dare una certa sistematicitàall’esposizione. Spesso però Internet (a causa del modo in cui si è evoluta)sfugge ad un inquadramento in paradigmi ben definiti e, pur nel rispetto deiprotocolli, sono possibili numerose eccezioni e soluzioni alternative ad una datamodalità di funzionamento.

Come appena accennato la risoluzione di un indirizzo avviene in modo“top-down”, iniziando dalla radice dell’albero e procedendo attraverso i serverdi livello gerarchico inferiore. Esistono due modalità per interrogare un server:modalità ricorsiva e modalità non-ricorsiva.

Nella modalità ricorsiva, quando si interroga un server, è responsabilità diquest’ultimo interrogare altri server fino a risolvere completamente il nome; a

87

traduzione ultimata, il primo server interrogato risponderà al sistema che hainoltrato la richiesta, comunicandogli l’indirizzo richiesto.

Nella modalità non-ricorsiva, il primo server interrogato risponderàindicando al sistema richiedente solo a quale altro server rivolgersi (ovverocomunicandogli il relativo indirizzo IP, non il nome, altrimenti sarebbenecessario risolvere anche quest’ultimo). Nell’esempio riportato prima, il rootserver risponderà dicendo di rivolgersi al server responsabile del top leveldomain “it”; in seguito, il sistema che ha inoltrato la richiesta si rivolgerà alserver “it”; quest’ultimo, se la richiesta che gli perviene è di tipo non ricorsiva,comunicherà di rivolgersi al server “uniroma1.it” e così via. Viceversa se larichiesta fosse stata ricorsiva, sarebbe stato il root server ad interrogare tutti glialtri e, ultimato il processo, a rispondere al client.

La parte client dell’algoritmo deve quindi conoscere necessariamentel’indirizzo di un solo, qualsiasi, name server. Da lì potrà poi continuare la suaricerca. Questo significa che la configurazione iniziale di un generico host devecontenere anche l’indirizzo IP di almeno un name server. Ovvero, un genericohost, deve avere le seguenti informazioni per poter scambiare dei dati attraversoInternet:

- il proprio indirizzo IP;- la maschera di sotto-rete;- una tabella di instradamento, includente almeno l’indirizzo IP di un router di

default;- l’indirizzo IP di un name server.

Tali informazioni possono essere fornite manualmente o ottenute medianteopportuni protocolli aggiuntivi, alcuni dei quali già citati (ad.es., RARP, BootP,DHCP, ICMP). Si noti che, in mancanza dell’indirizzo IP di un name server,l’host in questione potrebbe teoricamente scambiare dati, ma dovrebbe usare equindi conoscere l’indirizzo IP di ogni destinazione.

Eventualmente si può fornire ad un host anche l’indirizzo di un secondoname server, per ragioni affidabilistiche, detto name server di “backup”.

Per assicurare poi che ogni name server possa raggiungere gli altri, èsufficiente che esso conosca l’indirizzo del root server. In aggiunta, un nameserver può avere l’indirizzo del name server ad esso immediatamente superioreo di altri name server gerarchicamente superiori, inferiori, uguali o trasversali(come giudicato opportuno dall’amministratore di rete).

L’algoritmo appena descritto ha tre svantaggi: a) la gran parte dellerichieste degli utenti fa riferimento a nomi locali, risalire ogni volta fino al rootserver è inefficiente; b) il root server è sottoposto ad un carico di elaborazionemolto rilevante (anche se più calcolatori possono funzionare in parallelo per

88

svolgere tale compito); c) un guasto del root server o di un server di alto livellopregiudicherebbe il funzionamento dell’intero DNS.

Per ovviare a questi problemi l’algoritmo è stato integrato con dellefunzionalità dette di “cache” (=nascondiglio, magazzino nascosto). Ogni serverconserva in una memoria (memoria cache) i nomi che è riuscito a risolvereinsieme all’indirizzo del name server che ha operato la traduzione. Se gli vienerichiesta di nuovo la stessa traduzione non ha bisogno di rivolgersi nuovamenteal root server (statisticamente è probabile ricevere più volte, in tempi diversi,una richiesta di informazioni per lo stesso indirizzo). Tale meccanismo funzionaa tutti i livelli gerarchici. Ad esempio, se un name server negli USA ha risolto ilnome infocom.ing.uniroma1.it nel relativo indirizzo IP, e un sistema gli chiededi nuovo di risolvere lo stesso nome, tale name server conoscerà già la risposta.Inoltre, se allo stesso server viene chiesto di risolvere il nome“energetica.fisica.uniroma1.it”, non si rivolgerà al root server ma al serverresponsabile del dominio “uniroma1.it”, di cui “ha imparato” l’indirizzo IPdurante la precedente richiesta.

Le informazioni memorizzate nella cache hanno un “tempo di vita”trascorso il quale vengono cancellate; ciò poiché le associazioni nomi-indirizzipossono cambiare nel tempo (ed alcuni nomi od indirizzi possono cessare diesistere). Quando si memorizza una nuova informazione nella memoria cache,ci si scrive anche il suo tempo di vita; quest’ultimo può essere comunicato dachi fornisce l’informazione; il name server interrogato potrebbe infatti essere ingrado di conoscere la "stabilità" dell'informazione comunicata.

Quando un name server risolve un nome avvalendosi di informazioniregistrate nella cache, comunica anche da chi ha avuto quelle informazioni.Inoltre attribuisce a tali informazioni un’etichetta denominata “non di autorità”.In tal modo il richiedente sa che l’informazione ricevuta non è “sicura” e, sel’associazione nome-indirizzo non risulta più valida, quando usata, ilrichiedente stesso sa a chi rivolgersi per avere una traduzione “sicura”, senza farricorso al root server. Un sistema che inoltra una richiesta può specificare se siaccontenta di una risoluzione “non di autorità”, ovvero ottenuta grazie almeccanismo di cache, oppure se ha bisogno di una “risposta di autorità”. Inquest’ultimo caso il DNS non sfrutterà il meccanismo di cache e si rivolgeràdirettamente a chi è in grado di dare un’informazione sicura ed aggiornata circaun’associazione nome-indirizzo. Non solo i name server ma anche tutti gli hoste tutti i router memorizzano, in genere, nella loro cache i nomi precedentementetradotti.

Concludiamo con esempio, illustrante una possibile procedura dirisoluzione di un nome. Se un host vuole risolvere l'indirizzo

89

“st.ryukoku.ac.jp”, per prima cosa controlla se la corrispondenzanome-indirizzo IP è contenuta nella sua cache; se non c'è, cerca, sempre nellasua cache, un server di uno dei sub-domini dell'host cercato, “ryukoku.ac.jp”,“ac.jp” o “jp”; se non lo trova interroga il name server della sua zona, cheripeterà la stessa procedura; qualora anch’esso non trovi una corrispondenzanella sua cache si rivolgerà (tramite il root server) ad un name server deldominio “jp”; quest'ultimo fornirà l'indirizzo di un server nel domain “ac.jp” ecosì via fino ad arrivare alla traduzione. L'host locale memorizzerà nella suacache l’indirizzo ottenuto e tutti quelli incontrati in questo iter per futureeventualità.

Grazie a tale procedura DNS risulta essere molto efficiente ed affidabile.Inoltre per nomi già conosciuti la procedura è estremamente rapida. A titolo diverifica si può provare a chiedere per due volte consecutive la risoluzione dellostesso nome. La seconda richiesta sarà esaudita in tempi più rapidi, a meno chel’informazione in questione non fosse già contenuta nella cache del sistemarichiedente.

Infine, per assicurare il funzionamento del DNS per ogni nome di Internet,si richiede che un'organizzazione cui sia assegnato un dominio o un sub-dominio di nomi si impegni a mantenere un name server che gestisca i suoinomi ed un sistema di backup di tale name server.

III.4.8� Esempi

Per concludere il capitolo si ritiene utile presentare degli esempi cheillustrano il funzionamento di alcune procedure sinora introdotte.

La Fig. 14 mostra un sistema in cui un utente vuole stabilire una sessione“ftp” (cfr. par. II) con un sistema denominato “nic.switch.ch”, al fine dieseguire un trasferimento di files. L’utente digita quindi il comando “ftpnic.switch.ch”. Il comando viene comunicato ad una entità dello stratoapplicativo che implementa il protocollo ftp. Per prima cosa, questa entitàinvoca il DNS per risolvere il nome del destinatario. La componente client diDNS, residente nel sistema in questione, sfruttando i protocolli UDP e IP,manda un messaggio di interrogazione alla rispettiva componente server e,ottenuta la risposta, comunica all’entità richiedente il relativo indirizzo IP didestinazione. Solo a questo punto l’entità ftp può chiedere di instaurare unaconnessione ftp con l’host di destinazione (ftp è un servizio con connessione).A tal fine essa invoca i servizi di TCP e IP. Affinché IP possa inviare idatagrammi in cui sono contenuti i dati generati dall’entità ftp, IP stesso devestabilire verso quale sistema instradarli. L’entità IP nel sistema in questione

90

applicherà quindi il suo algoritmo di instradamento, consultando la relativatabella di instradamento.

Un passo obbligato di tale algoritmo è quello di determinare se l’indirizzodi destinazione appartenga alla stessa rete/sotto-rete logica del mittente o meno.Supponiamo che vi appartenga e che quindi i datagrammi vadano inviatidirettamente e non attraverso il router di default. Bisognerà ora determinarequale indirizzo locale corrisponde all’indirizzo IP di destinazione. A tal fine IPinvocherà il protocollo ARP, il quale risponderà comunicando l’indirizzo localeEthernet (poiché abbiamo supposto che la sotto-rete in questione fosse unaLAN Ethernet, cfr Fig. 14) corrispondente all’indirizzo IP di destinazione.Finalmente il datagramma potrà essere incapsulato nell’unità di dati dello stratoLLC; il risultato di questa operazione, includente la PCI di strato LLC, saràincapsulato nell’unità di dati dello strato MAC; quest’ultima sarà quindiconsegnata allo strato fisico per essere poi fisicamente trasmessa sul bus dellaLAN. Qualora il sistema di destinazione non fosse appartenuto alla stessarete/sotto-rete logica, i datagrammi sarebbero stati inviati verso il router didefault; ARP sarebbe stato invocato per determinare l’indirizzo Ethernetcorrispondente a quello IP del router di default.

Si noti infine che tutte le operazioni sopra descritte con riferimento allostrato IP ed agli strati ad esso inferiori, vanno eseguite per ogni datagramma dainviare (cfr. par. III.1 per le implicazioni di questo modo di operare sulleprestazioni dei sistemi basati su IP).

91

�� !�

��"#��"��$��%�&��'%�'(

")��**��+��,�$� -%./%�%�-(

��0��1$2�+��%�&��'%�'(

��

��)��**�� -%./%�%�-

�++��""��"��"�3

!�1��1��#��"��4��"��0��

��2�0"�

5 �

��1��1��#��"��4��*��

��1��'��")��**�6��+��

�"")��**��

��'��1�� -%./%�%�-

��+��1�--1��1� 1�71 �1-��0��8�'��

�� !�

client

server

Fig. 14 – Risoluzione di nomi ed instradamento

Consideriamo ora la Fig. 15, in cui si assume che un utente, usando unapplicativo browser www e residente nell’host denominatoinfocom.ing.uniroma1.it, voglia stabilire una connessione http con un sistemaremoto (www.ibm.com). La componente client di www deve rivolgersi allacomponente server di www, residente nel sistema denominato www.ibm.com.Da un punto di vista logico le rispettive entità comunicheranno direttamente traloro (cfr [ROV95]), ma, ovviamente, perché ciò accada dovranno essere attuate,tra le altre, tutte le procedure viste con riferimento alla figura precedente. LaFig. 15 mette in evidenza cosa accade quando mittente e destinatario nonappartengano alla stessa sotto-rete fisica. In questo caso si assume che sianocoinvolti più router, di cui due rappresentati in modo esplicito. Sonorappresentate anche le relazioni tra i sotto-sistemi di diversi strati con i relativiprotocolli coinvolti. Si noti che i protocolli di strato superiore a IP agiscono “daestremo a estremo”, ovvero senza coinvolgere i sistemi intermedi. Si osserviinfine che, siccome il sistema destinatario del comando dovrà rispondere allerichieste del mittente, anche il sistema denominato www.ibm.com dovràinvocare il DNS e i protocolli di tipo ARP, per far giungere le sue risposte alsistema che ha originato il comando stesso.

92

�"��&&&

��

��

��

9-�%

��2��%��4%0��%��

��#��&&&

��

��

��

9-�%.

&&&%�7�%��

--1--1--1--1--1--

��0��

��

��

9-�%

��0��

��

��

9-�%.

��1�'��+1::&&&%�7�%��

��

9-�% ��0� ��;��4

!�

��

��

Fig. 15 – Esecuzione di un comando di utente

III.5� I protocolli di strato 4

Finora si è descritto come IP possa trasferire datagrammi attraversoInternet. L’indirizzo di destinazione IP fa riferimento in modo generico ad unsistema ma non distingue a quale utente o a quale applicazione è diretto undatagramma. In Internet, uno dei compiti dei protocolli di strato 4, ovvero UDP(User Datagram Protocol) e TCP (Transmission Control Protocol), è quindiquello di distinguere tra i diversi programmi applicativi ed i diversi utenti chefanno uso di un sistema, consentendogli di inviare e ricevere datagrammi,indipendentemente l’uno dall’altro.

Molti dei sistemi connessi ad Internet usano sistemi operativi multi-utentee multi-tasking (=multi-compito); ovvero consentono a più utenti e a piùapplicazioni di utilizzare il calcolatore “simultaneamente” (in realtà secondo ilprincipio del “time-sharing”). Più in generale si parla di processi, ed i sistemi dicalcolo che consentono di eseguire più processi contemporaneamente sono detti“multi-processing”.

Il termine processo comprende sia programmi applicativi di sistema cheprogrammi applicativi direttamente usati da un utente umano. Un processo èeseguito da una o più entità e offre il risultato delle operazioni che svolge aquello che, in terminologia OSI, è definito utente (cfr. [ROV95]).

93

Un processo di strato applicativo è il destinatario finale di un datagrammae quindi un protocollo di strato 4 deve poter indirizzare i datagrammiconsegnatigli dallo strato IP ad uno specifico processo applicativo.

A tal fine occorre stabilire delle opportune procedure. I processi sonocreati e distrutti dinamicamente ed un mittente non sa, in generale, a qualeprocesso di un sistema remoto riferirsi. Vi è inoltre l’esigenza di potermodificare un processo senza dover poi rendere noto a tutti i possibili mittentiquesto cambiamento. Le destinazioni finali dovrebbero quindi essereidentificate in base alle funzioni che eseguono e non in base allo specificoprocesso che le implementa. Infine, in un sistema che consente ad un unicoprocesso di gestire più funzioni, è necessario decidere a quale di queste funzioniil mittente fa riferimento.

Per queste ragioni, invece di pensare ad un processo come alladestinazione finale, si è stabilito che ogni sistema contenga un insieme di “puntidi destinazione” chiamati “porte”. Ogni porta è identificata da un intero positivoe sarà poi il sistema operativo del sistema a mettere in corrispondenza ogniporta con un relativo processo. In terminologia OSI, una porta non è altro che ilService Access Point (SAP) dello strato 4, ovvero un punto, situato allafrontiera tra strato TCP e strato dei servizi applicativi, che identifica in modounivoco una specifica entità di destinazione, responsabile del processo didestinazione.

Per poter inviare un datagramma al processo voluto, un mittente devequindi conoscere sia l’indirizzo IP che la porta di destinazione (o SAP di strato4). Si pone perciò il problema di come assegnare i numeri di porta. Sono statedefinite due possibili tecniche per assegnare i numeri di porta, ambedue usatecontemporaneamente in Internet:

- assegnazione universale (“universal assignment”): la Internet AssignedNumber Authority (IANA) ha definito un insieme di numeri di porta in modoche ad un dato processo applicativo è associato uno specifico numero diporta; ad es. in UDP la porta numero 53 è associata al processo cheimplementa il DNS; i numeri di porta così predefiniti sono denominati “wellknown ports” (porte conosciute) e tutti coloro che implementano softwareapplicativo per Internet tengono conto di queste assegnazioni; in tal modo,quando si vuole indirizzare una unità di dati ad uno specifico processo si saquale numero di porta usare; le well known ports sono definite in modospecifico nell’ambito dei protocolli UDP e TCP (cfr. i paragrafi seguenti);

- assegnazione dinamica (“dynamic binding”=legame dinamico): alcuniindirizzi di porta, ovvero alcuni interi positivi non sono stati assegnati anessun specifico processo; quando un processo applicativo ha bisogno di

94

inviare dei dati ad un altro processo applicativo, negozia con quest’ultimouno specifico indirizzo di porta, tra quelli non già assegnati. L’indirizzo diporta prescelto viene usato solo durante il trasferimento di dati in questione equindi rilasciato al termine della sessione di trasferimento. Tale indirizzo diporta potrà quindi, in seguito, essere usato da altri processi.

Spesso una porta dispone anche di una memoria, che realizza una fila diattesa per tutti i datagrammi inviati a quella porta (qualora siano possibilisituazioni di congestione). I processi applicativi possono specificare, ed inseguito modificare, la dimensione della fila di attesa. Quando la fila è piena,eventuali unità di dati entranti saranno scartate.

In conclusione, ogni unità di dati di strato 4 deve contenere delleinformazioni atte ad identificare sia la porta di destinazione che quella diorigine. Quest’ultima informazione è necessaria per consentire al processo didestinazione di rispondere a quello mittente.

I concetti generali introdotti in questo paragrafo saranno applicati, neiprossimi paragrafi, ai protocolli UDP e TCP.

III.6� Il protocollo UDP

Il protocollo UDP è un protocollo estremamente semplice. La sua funzioneprincipale è quella di indirizzare una porta specifica; la modalità ditrasferimento è senza connessione e non fornisce alcuna garanzia sulla qualitàdi servizio. Non esegue recupero di errore, controllo di flusso e ri-ordinamentodelle unità informative. Le unità di dati di UDP sono di lunghezza variabile esono denominate datagrammi utente. L’intestazione del datagramma utentecontiene i seguenti campi (cfr. Tab. 7):

- gli indirizzi delle porte di origine e di destinazione;- la lunghezza del datagramma utente;- una “checksum” (=somma di verifica), il cui uso è opzionale, dell’intero

datagramma utente.All’intestazione segue un campo contenente i dati di utente, ovvero i dati

generati da un processo applicativo.

0 16 31Porta di origine Porta di destinazione

Lunghezza del datagramma utente UDP ChecksumData

...

Tab. 7 – Formato dell’unità di dati di UDP

95

UDP accetta dal livello superiore dati senza vincoli sulla loro lunghezza,eventualmente li frammenta e li invia in datagrammi IP distinti (Fig. 16).

Intestazione UDP(contiene l’indirizzo di

porta)

UDP Data

⇓ ⇓ ⇓Intestazione IP

(contiene l’indirizzo IP)IP Data

Fig. 16 – Incapsulamento del datagramma utente UDP nel datagramma IP

La checksum del datagramma utente è opzionale; in tal modo si può fare ameno di usarla, quando non necessario, e ridurre quindi il carico elaborativo perla trasmissione e la ricezione di un datagramma utente UDP. Infatti se si usanoreti altamente affidabili, la verifica di errori non è strettamente necessaria.

E' necessario però osservare che IP non effettua alcun controllo di erroresul campo informativo del datagramma IP, per cui, quando si usa UDP comeprotocollo di strato 4, la checksum di UDP costituisce l'unico strumento perverificare che i dati siano giunti a destinazione correttamente. Qualora talecontrollo venga impiegato, esso riguarda non solo tutto il datagramma utenteUDP, ma anche un cosiddetto pseudo header, aggiuntivo a quello di UDP emostrato in Tab. 8. Lo pseudo-header viene considerato al solo fine del calcolodella checksum (non viene trasmesso alla destinazione) e risulta costituito da:

- gli indirizzi IP della sorgente e della destinazione (contenuti nell'intestazionedel datagramma IP);

- il codice IP che identifica il protocollo UDP (cfr. campo Protocol type, Tab. 2nel § III.4.1);

- la lunghezza del datagramma utente UDP;- un byte di padding (=”riempitivo”) per fare in modo che la lunghezza

complessiva sia multipla di 16 bit.In altri termini la checksum di cui sopra controlla non solo l’intero

datagramma utente UDP ma anche gli indirizzi IP contenuti nel datagramma IPche ha trasportato il datagramma utente in questione. Il motivo per cui vieneconsiderato tale pseudo header è quello di verificare che il datagramma utenteUDP abbia raggiunto la destinazione corretta, ossia un dato utente didestinazione in un dato sistema di destinazione. Il solo esame del datagrammautente UDP non fornirebbe tale garanzia in quanto non contiene l’indirizzo delsistema di destinazione.

96

0 8 16 31Source IP Address

Destination IP AddressPadding Protocol UDP Length

Tab. 8 - Formato dello pseudo-header in UDP

A conclusione del paragrafo, si riportano, a titolo di esempio alcuni degliindirizzi di porta, assegnati da IANA in UDP. La Tab. 9 riporta alcune dellewell known ports di UDP.

Intero positivo che

identifica la porta

parola chiave Descrizione del processo associato

11 USERS elenca gli utenti attivi in un sistema

17 QUOTE citazione del giorno

42 NAMESERVER name server di un sistema

53 DOMAIN DNS

67 BOOTPS server del protocollo Bootstrap

68 BOOTPC client del protocollo Bootstrap

69 TFTP Trivial File Transfer Protocol

123 NTP Network Time Protocol

… … …

Tab. 9 - Alcune well known ports in UDP

III.7� Il Protocollo TCP

TCP è un protocollo con connessione, controllo e recupero di errore,controllo di flusso, ri-ordinamento delle unità informative e indirizzamento diuno specifico utente all’interno di un host. Trasferisce un flusso informativocontinuo e bi-direzionale ma non strutturato ed effettua operazioni dimultiplazione e de-multiplazione. Sebbene la sua notorietà deriviprincipalmente dal suo uso in Internet, TCP è sufficientemente generale dapoter essere usato anche in altri ambienti (rete telefonica commutata, LAN,MAN, X.25, etc.).

Come spiegato in precedenza (cfr. par. III.5) un indirizzo IP identifica soloun sistema e non gli utenti o i processi residenti in un sistema. Compito di TCPè quindi anche quello di distinguere tra i diversi programmi applicativi ed idiversi utenti che fanno uso di uno stesso sistema.

97

Come avviene per UDP, si è stabilito che ogni sistema contenga uninsieme di punti di destinazione chiamati porte. Anche in TCP, ogni porta èidentificata da un intero positivo. L'indirizzo di un utente di strato TCP èdenominato "port", mentre l'indirizzo completo nell’insieme dei protocolli TCPe IP è denominato "socket" ed è costituito da:

port@IP_Address=port@Host_Id.Net_Id.

La componente "port" è contenuta nell'intestazione dell’unità di dati diTCP, mentre la componente IP_Address è contenuta nell'intestazione dell’unitàdati di IP. Questo significa che tutte le sessioni di comunicazione in atto tra duespecifici sistemi useranno lo stesso indirizzo IP di sorgente e lo stesso indirizzoIP di destinazione; saranno perciò distinte solo a strato TCP. Ne segue chequeste sessioni possono essere viste come “multiplate” su di un unico indirizzoIP ovvero su di un unico “canale” IP di comunicazione (non su una connessioneIP; qui la dizione multiplazione va usata con cautela dal momento che IP è unprotocollo senza connessione).

Anche in TCP, come in UDP, gli indirizzi delle porte possono essere fissatia priori per uno specifico processo, ovvero essere decisi dinamicamente. In altritermini si possono usare sia l’assegnazione universale che quella dinamica.

La gestione delle porte in TCP è però più complessa di quella in UDPpoiché alla stessa porta può corrispondere più di un processo. TCP è unprotocollo con connessione, a differenza di UDP, e quindi ciò che ha maggioresignificato è la definizione di una connessione. In TCP una connessione èidentificata da una coppia di socket, relativa ai due processi che hanno stabilitola connessione. Ad esempio una connessione tra la porta 1069 dell’host151.100.8.18 e la porta 25 dell’host 160.80.4.1 sarà identificata dalla coppia:

“[email protected]”, “[email protected]”.

Grazie a tale meccanismo, un indirizzo di porta di un sistema puòsupportare connessioni multiple; la porta 1069 dell’host 151.100.8.18 potrebbegestire contemporaneamente le seguenti connessioni (ed anche altre):

“[email protected]”, “[email protected]”

“[email protected]”, “[email protected]”

questo perché, lo ribadiamo, ogni connessione è identificata dalla coppiasocket indirizzo e socket destinazione e non solo dal socket di destinazione.

98

La Tab. 10 riporta alcune delle well known ports di TCP. Si noti chealcune di queste sono uguali a quelle definite in UDP, mentre altre non sonopresenti in UDP (e viceversa).

Intero positivo che

identifica la porta

parola chiave Descrizione del processo associato

11 USERS elenca gli utenti attivi in un sistema

17 QUOTE citazione del giorno

20 FTP-DATA File Transfer Protocol (dati)

21 FTP File Transfer Protocol

23 TELNET Protocollo Telnet

25 SMTP Simple Mail Transfer Protocol

42 NAMESERVER name server di un sistema

53 DOMAIN DNS

79 FINGER Processo che da informazioni sugli

utenti residenti in un sistema

119 NNTP USENET News Transfer Protocol

… … …

Tab. 10 - Alcune well known ports in TCP

A conclusione della descrizione del meccanismo di indirizzamento delleporte aggiungiamo che è tipicamente responsabilità dei processi applicativipresentare agli utenti umani un’interfaccia che faciliti tale operazione. Si vuolecioè evitare che gli utenti debbano conoscere ed usare direttamente gli indirizzidi porta. Internet vuole essere un ambiente in cui le operazioni che gli utentidevono eseguire per comunicare tra loro siano le più semplici possibili (“userfriendly”). Un esempio di funzionalità introdotte a tal fine, e non strettamentenecessarie per il funzionamento di Internet, è stato dato con il Domain NameSystem. Un altro esempio che qui si introduce è l’indirizzamento automaticodelle porte, eseguito da alcuni processi applicativi:

- se si vuole stabilire una sessione telnet, sarà l’applicativo omonimo adindirizzare automaticamente le informazioni verso la porta 23;

- se si vuole trasferire un file, usando ftp, l’applicazione che implementa taleprotocollo indirizzerà opportunamente i dati verso le porte 20 e 21;

- se si vuole inviare un messaggio di posta elettronica si userà un indirizzo deltipo: [email protected]; il protocollo SMTP, implementato negliapplicativi di posta elettronica porrà in corrispondenza il nome “tizio” conun’opportuna porta e farà arrivare il messaggio all’utente voluto. Si noti che,

99

se in questo esempio avessimo indirizzato il messaggio solo all’indirizzo IPdell’host e cioè a “infocom.ing.uniroma1.it“, il sistema di destinazione nonsarebbe stato in grado di determinare a quali degli utenti attestati sul sistemastesso è diretto il messaggio.

TCP accetta dal livello superiore dati senza vincoli sulla loro lunghezza, liframmenta e li invia in datagrammi IP distinti (Fig. 17).

Intestazione TCP(contiene l’indirizzo di

porta)

TCP Data

⇓ ⇓ ⇓Intestazione IP

(contiene l’indirizzo IP)IP Data

Fig. 17 - Incapsulamento dell’unità dati di TCP in datagrammi IP

Poiché IP offre un servizio di consegna non garantito, TCP deve verificarela corretta ricezione dei datagrammi ed, eventualmente, attuare le procedurenecessarie per la ri-trasmissione. Inoltre è compito di TCP verificare che idatagrammi giungano a destinazione nella stessa sequenza con cui sono statitrasmessi, che non vi siano duplicati o datagrammi mancanti. Questefunzionalità vengono garantite mediante la numerazione delle unità dati emediante l'invio di messaggi di conferma ("acknowledgement") da parte delladestinazione. TCP offre anche meccanismi di controllo di flusso in grado diimpedire il sovraccarico della rete e quindi situazioni di congestione.

Evidentemente tutte le funzionalità fornite da TCP hanno un costo intermini di aumento del ritardo di trasmissione e di aumento della quantità diinformazioni che devono essere trasferite nella rete (“overhead”); ciononostanteTCP può essere impiegato anche in reti ad alta velocità. In alcuni esperimenti sisono raggiunte portate utili di 8 Mbit/s su di una Ethernet con capacità ditrasferimento pari a 10 Mbit/s ed è stato dimostrato che in canali opportuni èpossibili raggiungere portate utili dell’ordine di 1 Gbit/s. Nel seguito vengonodescritti con più dettaglio i meccanismi sin qui elencati e vengono illustratealcune possibili estensioni di TCP per migliorarne le prestazioni in reti ad altavelocità.

Infine si ricorda che, essendo TCP un protocollo con connessione, sarannopresenti le fasi di instaurazione, trasferimento dati ed abbattimento.

100

III.7.1� Formato dell’unità dati

Le unità di dati dello strato TCP sono dette segmenti. Il segmento ècomposto da una intestazione e da un campo informativo, che contiene i dati diutente. Il formato del segmento TCP è illustrato nella Tab. 11. Ogni rigacontiene 32 bits.

0 4 10 16 24 31

Source Port Destination Port

Sequence Number

Acknowledgement Number

Offset Reserved Control Window

Checksum Urgent Pointer

Options Padding

Data

Data

...

Tab. 11- Formato del segmento TCP

I campi definiti nella Tab. 11 hanno i seguenti significati e funzioni:

- Source Port (Porta di Origine) (16 bit): definisce l'indirizzo logico delprocesso sorgente dei dati;

- Destination Port (Porta di Destinazione) (16 bit): definisce l'indirizzo logicodel processo destinatario dei dati;

- Sequence Number (Numero di Sequenza) (32 bit): numero di sequenza intrasmissione; contiene il numero di sequenza del primo byte di dati contenutinel segmento a partire dall'inizio della sessione TCP (se SN=m ed ilsegmento contiene n bytes il prossimo SN sarà pari a m+n); la numerazionedei segmenti è quindi effettuata non numerando i segmenti stessi (come inX.25), ma gli ottetti in essi contenuti;

- Acknowledgement Number (Numero di Riscontro) (32 bit): numero disequenza in ricezione; nei segmenti in cui il bit ACK, presentato più avanti, èposto al valore binario “1”, questo campo contiene il numero di sequenza delprossimo byte che il sistema che emette tale segmento si aspetta di ricevere;nel caso di connessioni interattive bi-direzionali si usa quindi il meccanismodenominato “addossamento” (o “piggybacking”) dei riscontri; ovvero siutilizzano segmenti contenenti dati di utente per inviare i riscontri al

101

trasmettitore senza dover, a tal fine, inviare dei segmenti appositi;- Offset (4 bit): contiene il numero di parole di 32 bit contenute

nell'intestazione di TCP; l'intestazione di TCP è sempre costituita da unnumero di bit multiplo di 32 (questo campo è necessario poiché il campoOptions è di dimensioni variabili);

- Reserved (6 bit): riservato per usi futuri, per ora contiene degli zeri.- Control bit (6 bit): i bit di controllo sono:

• URG: viene posto uguale al valore binario “1” quando il campoUrgent Pointer (definito in seguito) contiene un valore significativo;

• ACK: viene posto uguale al valore binario “1” quando il campoAcknowledgement Number contiene un valore significativo;

• PSH: viene posto uguale al valore binario “1” quando l'applicazioneesige che i dati forniti vengano trasmessi e consegnati all'applicazionericevente prescindendo dal riempimento delle memorie allocate fraapplicazione e TCP e viceversa (solitamente infatti è il riempimentodelle suddette memorie che scandisce la trasmissione e la consegnadei dati);

• RST: viene posto uguale al valore binario “1” quando unmalfunzionamento impone il reset della connessione;

• SYN: viene posto uguale al valore binario “1” solo nel primosegmento inviato durante il “3-way handshaking” (stretta di mano atre fasi, una fase di sincronizzazione fra le entità TCP, cfr. § III.7.2);

• FIN: viene posto uguale al valore binario “1” quando la sorgente haesaurito i dati da trasmettere.

- Window (Finestra) (16 bit): dimensione della finestra; contiene il numero dibytes che, a cominciare dal numero contenuto nel campo AcknowledgementNumber, il destinatario del segmento può inviare al mittente del segmentostesso senza ricevere riscontri (cfr. § III.7.4);

- Checksum (16 bit): contiene l’informazione di controllo che permetteall’entità TCP ricevente di verificare la correttezza del segmento ricevuto;

- Urgent Pointer (Puntatore Urgente) (16 bit): contiene il numero di sequenzadel byte che delimita superiormente i dati che devono essere consegnatiurgentemente al processo ricevente. Tipicamente sono messaggi di controlloche esulano dalla comunicazione in senso stretto. A tale traffico ci si riferiscedi solito con il nome di “out-of-band“ (fuori banda);

- Options (Opzioni) (di lunghezza variabile): sono presenti solo raramente: lepiù note sono End of Option List, No-operation e Maximum Segment Size(MSS). Ci si soffermerà, in seguito, solo sull'ultima opzione citata;

102

- Padding (Riempitivo) (di lunghezza variabile): contiene sempre degli zeri.Serve come riempitivo aggiunto per far sì che l'intestazione abbia unalunghezza multipla di 32 bit.

Si noti che le unità di dati di TCP possono trasportare solo messaggi dicontrollo (ad. es. per instaurare o abbattere una connessione) o solo dati diutente o entrambi. TCP usa il campo Control per specificare la funzione ed ilcontenuto di un segmento. Ciò consente l’addossamento o “piggybacking” delleinformazioni di controllo, ovvero le informazioni di controllo (ad. es. iriscontri) possono essere trasportate da segmenti che contengono ancheinformazione di utente.

III.7.1.1 Calcolo della checksum

Come avviene in UDP, la checksum di TCP controlla non solo l’interosegmento TCP ma anche gli indirizzi IP contenuti nel datagramma IP che hatrasportato il segmento in questione. Il controllo riguarda quindi anche unopseudo header, mostrato in Tab. 12, che viene considerato al solo fine delcalcolo della checksum e che risulta costituito dagli indirizzi IP della sorgente edella destinazione (contenuti nell'intestazione del datagramma IP), dal codice IPche identifica il protocollo TCP (cfr. campo Protocol type, Tab. 2 nel § III.4.1),dalla lunghezza del segmento TCP e da un byte di padding per fare in modo chela lunghezza complessiva sia multipla di 16 bit. Il motivo per cui vieneconsiderato tale pseudo header è, come nel caso di UDP, quello di verificareche il segmento TCP abbia raggiunto la destinazione corretta, ossia un datoutente di destinazione in un dato sistema di destinazione. Il solo esame delsegmento TCP non fornirebbe tale garanzia in quanto non contiene l’indirizzodel sistema di destinazione.

0 8 16 31

Source IP Address

Destination IP Address

Padding Protocol TCP Length

Tab. 12 - Formato dello pseudo-header

III.7.2� Instaurazione e rilascio di una connessione

Il protocollo TCP è un protocollo orientato alla connessione. Questosignifica che l’entità TCP residente nel sistema mittente deve instaurare unaconnessione con l’entità TCP residente nel sistema di destinazione, prima che lafase di trasferimento delle informazioni possa avere inizio. Le due entità TCP

103

interagenti si sincronizzano scambiandosi il proprio numero di sequenza intrasmissione iniziale, che rappresenta il numero a partire dal quale tutti i bytetrasmessi saranno sequenzialmente numerati, una volta instaurata laconnessione. In altre parole il numero di sequenza in trasmissione non puòiniziare da un dato valore fisso; ogni volta che si instaura una nuovaconnessione bisogna scegliere il numero di sequenza in trasmissione da cuipartire in modo opportuno e mediante un’opportuna sincronizzazione reciproca.

Tale sincronizzazione è necessaria per risolvere potenziali situazionianomale; si ricorda che IP non è affidabile e quindi i datagrammi IP possonoessere persi, ritardati, duplicati o consegnati fuori sequenza. Vedremo che TCPri-trasmette i segmenti che considera persi dopo un tempo pre-definito(time-out di ritrasmissione). Nel caso in cui un segmento fosse effettivamenteandato perso, questo modo di operare risolve il problema, ma se un segmentosubisce un ritardo di trasferimento superiore al time-out di ritrasmissione, TCPlo considera perso anche se in realtà non lo è, e quindi lo ritrasmette. Aldestinatario possono quindi pervenire più copie dello stesso segmento. Se unsegmento e le possibili copie di esso non sono numerati in modo opportuno,l’entità TCP ricevente non ha modo di interpretare correttamente i segmentiricevuti.

Ad esempio, se il primo segmento, emesso per chiedere di instaurare unaconnessione, fosse numerato a partire da un valore fisso (poniamo uguale ad“1”), e se tale segmento fosse molto ritardato e quindi ritrasmesso (sempre conun numero di sequenza in trasmissione pari ad 1), all’entità riceventearriverebbero due distinte richieste di instaurazione. Poiché l’entità riceventenon avrebbe modo di sapere che in realtà si tratta di una sola richiesta,tenterebbe di instaurare due connessioni e risponderebbe due volte all’entitàtrasmittente. Ma l’entità trasmittente non saprebbe come interpretare la secondarisposta relativa ad una richiesta di instaurazione che tale entità non ha maieffettuato. D’altra parte non si può nemmeno pensare di risolvere questaambiguità scartando quella che sembra essere una copia dello stesso segmento,poiché potrebbe accadere che un’entità voglia effettivamente instaurare due opiù connessioni. Ad esempio, un browser WWW può instaurare più connessioniTCP per trasferire diverse parti di uno stesso documento (immagini, suoni, etc.),un utente potrebbe desiderare di stabilire due connessioni TCP per trasferirecontemporaneamente due files usando FTP, etc.

Possono quindi sorgere dei problemi se segmenti originali e ri-trasmessiarrivano mentre una connessione sta per essere instaurata, ma anche sesegmenti ri-trasmessi arrivano dopo che una connessione è stata instaurata, odopo che sia stata rilasciata. In quest’ultimo caso, ad esempio, l’entità

104

trasmittente vedrebbe arrivare un segmento relativo ad una connessione cheessa considerava già terminata e quindi non saprebbe come gestire talesegmento.

Esiste anche la possibilità che un segmento appartenente ad una “vecchia”connessione arrivi ad un sistema dopo che tra gli stessi processi relativi a quelsegmento sia stata instaurata una “nuova” connessione; in tal caso un “vecchio”segmento si inserirebbe tra i dati relativi ad una diversa connessione. Infine c’èpossibilità di confusione quando un sistema cessa di funzionare e perde tracciadelle connessioni che altri sistemi considerano ancora in atto. Il progetto di unbuon protocollo deve poter tener in conto qualunque tipo di evento, perimprobabile che possa sembrare. Per risolvere questi problemi, TCP ricorre allasincronizzazione dei numeri di sequenza in trasmissione e in ricezione.

In TCP il primo numero di sequenza in trasmissione è posto uguale ad unnumero pseudo-casuale; tale dizione è usata per significare che la procedurausata produce un numero che di fatto è deterministico ma che, per certi fini, puòessere considerato casuale. I successivi numeri di sequenza sono poideterminati in accordo alla regola già definita. Per generare il primo numero disequenza, in modo pseudo-casuale, ogni sistema usa un contatore di dimensionipari a quelle del campo contenente il numero di sequenza (32 bit, cfr. Tab. 11);il contatore può quindi assumere un valore variabile tra 1 e 2^32; il contatore èincrementato a passi di 4 µs usando un orologio locale (clock), nonsincronizzato con altri sistemi ed impiega circa 4.77 ore (4µs*2^32) percompiere un ciclo completo, dopo di che il processo ricomincia.

Quando si inizia una nuova connessione, il primo numero di sequenza intrasmissione è posto uguale al valore assunto in quel momento da questocontatore. Il sistema destinatario risponde con un numero di sequenza inricezione (Acknowledgement Number) uguale a quello in trasmissione delmittente, aumentato di un’unità, ed usa un numero di sequenza in trasmissioneuguale al valore del suo contatore, il quale non è in nessuna relazione pre-stabilita con quello del mittente. Infine il mittente a sua volta risponde aldestinatario ponendo il suo numero di sequenza in ricezione pari al numero disequenza in trasmissione del destinatario aumentato di un’unità; ciò fatto puòcominciare a trasmettere dati di utente, ovvero considera instaurata laconnessione. Il destinatario comincia a trasmettere solo dopo aver ricevuto ilterzo segmento. Questo meccanismo è denominato three way handshake (strettadi mano a tre fasi).

Dal momento che il campo contenente il numero di sequenza impiega circa4.77 ore per compiere un ciclo completo, e poiché il contatore vieneincrementato ad una velocità molto superiore a quella relativa al numero di

105

sequenza di una qualsiasi connessione (almeno alle attuali velocità ditrasferimento disponibili in Internet), questo meccanismo risolve i problemivisti sopra. Il primo numero di sequenza in trasmissione si sceglie quindi inmodo pseudo-casuale tra 1 e 4294967296; in tal modo è estremamenteimprobabile che due segmenti portino informazioni non coerenti; ad esempio sedue segmenti sono relativi a connessioni diverse, avranno dei numeri disequenza abbastanza “lontani” tra loro (cfr. anche § III.7.3 e III.7.4).

La Fig. 18 mostra in dettaglio la procedura three way handshake. Quandodeve essere instaurata una connessione a livello di strato di applicazione fra undato processo applicativo, denominato ULP A (ULP=Upper Layer Protocol),residente nel sistema A, ed un ULP B, residente nel sistema remoto B, il primopasso che si deve compiere è l'invio di una “active open”, primitiva di Richiestadi Servizio, da parte dell'ULP A all’entità TCP A, con la quale quest'ultimaviene messa al corrente di tale desiderio. L’entità TCP A risponde ad ULP Atramite la primitiva open id, primitiva di Risposta di Servizio, ed avvia ilmeccanismo 3-way handshaking inviando, all’entità TCP ricevente, TCP B, unprimo segmento. Tale primo segmento, denominato SYN e contenente il bitSYN posto al valore logico “1”, ha un numero di sequenza in trasmissione(denominato Initial Sequence Number - ISN), pari al valore assunto dalcontatore residente nel sistema A, poniamo pari a x. Nella Fig. 18, per ognisegmento scambiato, sono indicati tra parentesi:

- il primo valore assunto dal campo Sequence Number, ISN;- il valore assunto dal campo Acknowledgement Number, Ack. N;- la scritta SYN e/o ACK quando i relativi bit sono posti al valore logico “1”.

� !�"�

�#!�"�

#��

!��$��

%$��

%$��

� !�&�

�#!�&�

%$��

%$��

&� ��$��

�'��(�)�� *�(�+��,-'

.'��(�)�� *�(�+&#/+�&��,-0�+��,�'

1'�&#/)�� *&#/+�&��,�0�'

Fig. 18 - Procedura di instaurazione di una connessione TCP

106

Alla ricezione di tale primo segmento, il TCP B risponderà, nel caso sitrovi nelle condizioni di poter accettare la connessione (cioè nel caso abbiaricevuto precedentemente una passive open dall'ULP B), con un segmento incui sono posti al valore logico “1” sia il bit SYN che il bit ACK; in talesegmento il campo ISN del ricevitore è posto uguale al valore assunto dalcontatore residente in B, poniamo pari a y; il campo Acknowledgement Numberè posto pari all’ISN del mittente aumentato di un’unità, x+1. La procedura siconclude con l'invio da parte del TCP A, una volta ricevuto il segmento SYN,di un segmento denominato ACK (in cui il bit ACK è posto al valore logico“1”). Il valore del campo Acknowledgement Number è ora pari a y+1. Laricezione del segmento SYN permetterà al TCP A di informare il proprio ULPA, mediante una primitiva open success, che la connessione è stata attivata. Nelfrattempo, il TCP B completerà la procedura informando il proprio ULP dellaricezione del segmento ACK conclusivo, con una primitiva open success.

A proposito del generatore di numeri di sequenza abbiamo osservato che,aggiornandosi ogni 4 microsecondi, esso presenterà lo stesso numero ogni 4.77ore circa. Per evitare la possibilità di confondere i numeri di sequenza deisegmenti è sufficiente fare in modo che il segmento rimanga in rete per untempo limitato. A questo scopo provvede il campo Time-To-Live (TTL) delprotocollo IP che svolge quindi un servizio anche a favore del protocollo TCP,oltre a quella relativa ad IP stesso, che, ricordiamo, risolve eventuali problemidi instradamento non corretto e non rilevato dai protocolli a ciò preposti.

Il rilascio di una connessione avviene mediante un meccanismo di 3-wayhandshaking modificato. Si ricorda che una connessione TCP è bi-direzionale epuò essere vista come due flussi di dati indipendenti, uno per ciascunadirezione. Quando un programma applicativo non ha più dati da inviareordinerà a TCP di chiudere la connessione in una direzione. TCP finirà ditrasmettere i dati restanti (eventualmente rimasti nella memoria ditrasmissione), attenderà il relativo riscontro ed invierà un segmento con il bitFIN posto al valore logico “1” (denominato segmento FIN). L’entità TCPricevente invierà un riscontro del segmento FIN ed informerà il “suo”programma applicativo che non ha più dati da ricevere e quindi da trasferirgli.Una volta che la connessione è stata chiusa in una direzione, l’entità TCPricevente non accetterà più dati di utente da quella direzione. Nel frattempo idati continueranno a fluire nell’altra direzione, finché anche quest’altra nonverrà chiusa. Fin tanto che almeno una direzione è attiva, i riscontricontinueranno invece ad essere inviati anche da chi ha chiuso la connessionenella prima direzione (e ricevuti dall’entità TCP ricevente).

I dettagli di questa procedura sono più complessi di quella di

107

instaurazione. Questo perché, informare un’applicazione che è pervenuta unarichiesta di chiudere una direzione della connessione ed ottenerne una risposta,potrebbe richiedere un tempo considerevole (implicante ad esempioun’interazione umana).

La procedura di rilascio (o di abbattimento) di una connessione TCP èillustrata nella Fig. 19. Si notino, oltre ai valori assunti dai campi SequenceNumber (Seq. N.), Acknowledgement Number (Ack. N), FIN e ACK, ledifferenze rispetto alla procedura di instaurazione. Quando l’entità TCP Briceve un segmento FIN, invece di rispondere immediatamente con un altrosegmento FIN, comunica prima a TCP A di avere ricevuto tale segmento, conun segmento di riscontro (ed evita così che TCP A continui ad inviare altrisegmenti FIN); quindi informa l’applicazione in B della richiesta di chiusura edaspetta che quest’ultima risponda (questa è la fase che potrebbe richiedere unacerta attesa, dovuta ad un’interazione con un utente umano). Quando finalmentel’applicazione risponde, TCP B invia un segmento FIN a TCP A; quest’ultimaentità riscontra tale segmento e le procedura si completa.

TCP B TCP A

1) FIN_segment (FIN, Seq. N.=x)

2) ACK_segment (ACK, Ack N.=x+1)

3) FIN_segment (ACK, Ack N.=x+1, Seq. N.=y)

4) ACK_segment (ACK, Ack N.=y+1)

L’applicazione chiededi chiudere la connessione,TCP invia il segmento FIN

TCP accettail segmento ACK

TCP accettail segmento FIN

e informa l’applicazionedella richiesta di chiusura

TCP accettail segmento FIN

L’applicazione chiudela connessione, TCP invia

il segmento FIN

TCP inviail segmento ACK

TCP accettail segmento ACK

possibileinterazione umana

TCP inviail segmento ACK

Fig. 19 - Procedura di abbattimento di una connessione TCP

Infine se una connessione non può essere chiusa secondo la proceduranormale, a causa di situazioni anomale, o se un programma applicativo èforzato a chiudere immediatamente una connessione, TCP prevede unaprocedura di reset. Tale procedura consiste nell’inviare un segmento con il bitRST posto al valore logico “1”. Alla ricezione di tale segmento la connessione èimmediatamente terminata senza scambio di ulteriori messaggi e TCP ne

108

informa i programmi applicativi.

III.7.2.1 Dimensione massima di un segmento

Quando l’entità TCP trasmittente invia il primo segmento (SYN) perinstaurare una connessione con un’entità TCP remota, essa può inserire in talesegmento un'informazione che rappresenta la massima dimensione del campodei dati di utente di un segmento (Maximum Segment Size - MSS) che è ingrado di trattare. L’entità ricevente risponde comunicando la propria MSS. Conlo scambio di queste informazioni le due entità TCP interagenti stabiliscono lamassima lunghezza dei segmenti che si scambieranno.

La scelta della MSS da parte di ciascuna delle due entità dipende da duefattori: la dimensione della memoria a disposizione delle entità TCP e ladimensione della Maximum Transfer Unit (MTU, cfr § III.4.2); ricordiamo chela MTU è la dimensione massima dell’unità di dati di una sotto-rete(tipicamente quella a cui è direttamente connesso il sistema relativo ad una dataentità). La MTU è resa nota, sia all’entità IP che all’entità TCP, dal softwareche interfaccia TCP/IP ad una data sotto-rete (tale software è denominato“driver” di rete).

Il calcolo della Maximum Segment Size (MSS) viene effettuato sottraendoalla MTU la dimensione delle intestazioni dei datagrammi IP e dei segmentiTCP (ovvero delle PCI di entrambe queste unità di dati). Nel calcolo, unproblema potrebbe essere rappresentato dalla variabilità della dimensione delleintestazioni di IP e TCP ma in realtà, fatta eccezione per i rari casi in cui siusano le opzioni, si avrà sempre a che fare con entrambe le intestazioni aventidimensioni pari a 20 bytes.

Una volta che le due entità hanno determinato le proprie MSS e si sonocomunicati a vicenda i relativi valori, esse si accordano su di una MSS comune,da usare per i segmenti che si scambieranno. Di solito, si sceglie il valoreminimo tra la MSS offerta dall’entità TCP di destinazione e quella relativa almittente.

Esistono però dei casi in cui questo non succede, per cui il protocollo IPpuò dover operare una frammentazione dei datagrammi alla sorgente. Nel casoin cui l'opzione di scelta della MSS non venga utilizzata, si impone l'uso, perdefault, di una MSS pari a 536 byte. Una tale MSS, aggiunta ai 40 bytes delleintestazioni dà luogo ad un datagramma IP di dimensione pari a 576 bytes,ovvero un datagramma che tutti i sistemi di Internet devono necessariamenteaccettare e gestire (cfr. § III.4.2)

Oggi si va però delineando la possibilità di usare valori molto più grandidella MSS. In passato si raccomandava, nel caso di sistemi appartenenti a sotto-

109

reti differenti, ed interconnesse quindi da almeno un router, di usare una MSS di536 byte; attualmente si usano valori anche molto più grandi e sono stateavanzate proposte che, nel contesto di una MAN, come FDDI, porterebbero allapossibilità di usare MSS di 4096 byte. Questo al fine di aumentare l’efficienza ela velocità del collegamento.

III.7.2.2 Trasmissione di dati urgenti (out of band)

A volte è necessario inviare dei dati urgenti (denominati “out of band”,fuori banda) senza aspettare che l’entità ricevente finisca di elaborare i datiprecedentemente trasmessi. Si fa notare che una rilevante quantità di datipotrebbe essere “in viaggio” verso l’entità ricevente, memorizzata nei routerlungo il cammino della connessione e nella coda di entrata dell’host remoto.

Ad esempio, quando TCP è usato per stabilire una sessione Telnet(emulazione di terminale), un utente potrebbe decidere di inviare un segnaledetto di “interrupt” che termini immediatamente l’applicazione remota. Ciòpotrebbe avvenire sia in occasione di malfunzionamenti dell’applicazionesull’host remoto, o semplicemente perché l’utente non vuole aspettare che unprocesso termini la sua esecuzione.

Il segnale di interrupt (tipicamente “control C”) deve poter essere inviatosenza aspettare che l’host remoto elabori tutti i dati già inviati, altrimenti unutente non sarebbe in grado di far cessare l’esecuzione di un programma almomento voluto.

A tal fine TCP prevede l’invio di “dati urgenti” che hanno priorità su tuttigli altri dati già inviati e vengono trasmessi immediatamente al processoremoto; quando i dati urgenti sono stati elaborati, il processo remoto riprende inesame i dati “normali”. Il meccanismo usato da TCP per inviare dati urgenticonsiste nel porre al valore logico “1” il bit URG di un segmento e di inserirenel campo Urgent Pointer il numero di sequenza del byte che delimitasuperiormente i dati che devono essere consegnati urgentemente al processoricevente.

III.7.3� Controllo e recupero di errore

La strategia utilizzata per il controllo di errore in TCP è simile a quellausata nel LAP-B (cfr. [BLE]) ed è basata sull’uso di finestre in trasmissione edin ricezione. Nel seguito si suppone noto tale meccanismo, ovvero l’invio diriscontri (“acknowledgement”) per segnalare la corretta ricezione di un’unitàdati e la funzione delle finestre in trasmissione ed in ricezione. Ricordiamo soloche il meccanismo della finestra in trasmissione rende possibile inviare un certonumero di unità di dati prima di ricevere un riscontro (al contrario dei

110

meccanismi che prevedono un riscontro per ogni unità dati, come Stop andWait). Grazie a tale modo di operare, è possibile incrementare la portata delcollegamento, dal momento che, entro il limite stabilito dalla finestra intrasmissione, il mittente non deve aspettare un riscontro ogni volta che deveinviare un’unità dati.

TCP considera il flusso di dati in trasmissione come una sequenza di ottetti(o bytes) e quindi la finestra in trasmissione opera a livello di ottetto invece chea livello di trama o di pacchetto, come in X.25. Gli ottetti sono numeratisequenzialmente a partire dal numero pseudo-casuale (ISN) scelto durante lafase di instaurazione, ovvero ogni byte trasmesso ha un suo numero d’ordine.

La finestra in trasmissione specifica quindi il numero di ottetti (bytes) chepossono essere inviati senza ricevere un riscontro; analogamente la finestra inricezione specifica il numero di ottetti che possono essere accettati fuorisequenza. In TCP la dimensione della finestra in trasmissione coincide conquella della finestra in ricezione. La dimensione di finestra specifica quindi siail numero di bytes che un’entità TCP può trasmettere senza ricevere riscontri,sia il numero di bytes che un’entità TCP è in grado di ricevere fuori sequenza.

Per analizzare più in dettaglio questa procedura, consideriamo unaconnessione a strato TCP e prendiamo in esame una sola direzione deltrasferimento di dati bidirezionale in atto tra due entità TCP; nell’altro verso ditrasferimento si avrà una situazione speculare. Nell’ambito del prescelto versodi trasferimento, una entità TCP avrà il ruolo di mittente mentre l’altraassumerà quello di destinatario. In TCP la dimensione della finestra intrasmissione non è scelta dal mittente ma è comunicata al mittente daldestinatario.

Ogni volta che l’entità destinataria emette un segmento verso quellamittente, comunica nel campo Window (16 bits) la larghezza (in bytes) dellafinestra di trasmissione che l’entità mittente deve usare (coincidente con ladimensione della finestra in ricezione). Ciò spiega anche perché finestra intrasmissione ed in ricezione coincidano: sarebbe infatti strano che il destinatariocomunichi al mittente che questi può emettere un certo numero di bytes equindi non li accetti perché arrivano fuori sequenza (il che non è responsabilitàdel mittente). Sempre per questo motivo la finestra è chiamata in TCP“Advertised Window”, ovvero finestra “comunicata” o “pubblicizzata” (daldestinatario al mittente). L’entità mittente dovrà usare tale valore della finestradi trasmissione fino a che non riceve dal destinatario un successivo segmentocon una diversa dimensione di finestra. La dimensione della finestra variaquindi dinamicamente nel tempo. Nel seguito esaminiamo il funzionamentodello schema assumendo che tale dimensione sia pari ad un dato valore fisso W.

111

Ad esempio, all’inizio di una connessione e quando l’entità mittente nonha ancora trasmesso nessun dato di utente e quindi non ha ricevuto nessunriscontro relativo a tali dati, essa può emettere solo W bytes; trasmessi questideve interrompere la trasmissione di dati di utente fino a che non riceva almenoun riscontro.

I riscontri sono di tipo cumulativo; ovvero il destinatario conferma laricezione dell’ultimo byte di una sequenza di dati ricevuta completamente inmodo corretto, ovvero senza errori e senza elementi mancanti. In particolarel’entità destinataria comunica a quella mittente il prossimo byte che si aspetta diricevere (nel campo Acknowledgement Number), significando così che tutti iprecedenti bytes sono stati ricevuti.

Alla ricezione di un riscontro il mittente “sposterà in avanti” la finestra epotrà inviare ancora, senza ulteriori riscontri, bytes con un numero di ordinecompreso tra x e x+W, dove x è il numero contenuto nel campoAcknowledgement Number dell’ultimo riscontro ricevuto. In altre parole, manmano che il mittente riceve riscontri, che gli assicurano che parte dei datitrasmessi sono arrivati a buon fine, può trasmettere altri dati.

Il meccanismo di recupero di errore è basato su di un meccanismo detto di“time-out” (fuori tempo massimo). L’entità mittente, dopo avere inviato unsegmento aspetta un tempo pre-definito (TO) e, se non riceve un riscontro,assume che il segmento si sia perso.

Questo modo di operare, basato su riscontri cumulativi, presenta siavantaggi che svantaggi.

Vantaggi:- il destinatario può determinare in modo semplice quali riscontri inviare;- la perdita di un riscontro non causa necessariamente una ri-trasmissione;

Svantaggi:- il mittente non riceve riscontri riguardanti tutti i dati che ha trasmesso, ma

solo il numero d’ordine dell’ultimo byte del flusso di dati ricevutocorrettamente dal destinatario.

Quest’ultima caratteristica può condurre a potenziali inefficienze:supponiamo che:

- la dimensione della finestra in trasmissione sia di 5 000 bytes- l’Initial Sequence Number, scelto durante la fase di instaurazione, sia pari a

1 000 000- il mittente abbia ricevuto un riscontro relativo al byte di numero di ordine

1 001 000 (ovvero il destinatario ha ricevuto tutti i primi 1000 bytes, ed inviaun Acknowledgement Number pari a 1 001 001, ovvero aspetta di ricevere unbyte con questo numero d’ordine).

112

Il mittente può emettere 5000 bytes; assumiamo che effettivamente liemetta, in 5 segmenti contenenti ciascuno 1 000 bytes, arrivando così al numerod’ordine 1 006 000. Supponiamo però che al destinatario siano pervenuti gliultimi 4 000 bytes ma non i primi 1 000 dei 5 000 trasmessi (ovvero che riceva4 dei 5 segmenti inviati). Il destinatario non può confermare la ricezione degliultimi 4 000 bytes, poiché i riscontri sono di tipo cumulativo, e quindicontinuerà a riscontrare solo i primi 1000, originariamente pervenuti, inviandoancora un Acknowledgement Number pari a 1 001 001.

Supponiamo che scada il time-out relativo al primo segmento trasmesso. Aquesto punto il mittente potrebbe avere due scelte: 1) ri-trasmettere tutti i 5segmenti; 2) ri-trasmettere solo il primo segmento. Nel primo caso siri-trasmettono inutilmente 4 segmenti, nel secondo il mittente ri-trasmette soloun segmento, ma deve però aspettare un riscontro prima di poter trasmettereancora e quindi le prestazioni saranno simili, quando si verifica l’evento appenadescritto, a quelle di un meccanismo di tipo Stop and Wait.

Lo standard comunemente accettato di TCP prevede di seguire il secondotipo di comportamento.

L’unico modo di superare queste inefficienze sarebbe quello di introdurreuna modifica al protocollo che consenta al destinatario di informare il mittentedella eventuale corretta ricezione di segmenti che siano giunti a destinazionefuori sequenza. In tal modo si potrebbe attuare un meccanismo di ri-emissioneselettiva.

Torniamo ora al meccanismo del time-out ed in particolare a come vienedeterminato il valore dell’intervallo di tempo (denominato TO), trascorso ilquale un’entità TCP mittente considera un segmento perso e quindi lori-trasmette.

Definiamo come Round-Trip Delay (RTD) (ritardo di andata e ritorno) iltempo impiegato da un’unità di dati per andare dal mittente al destinatario etornare indietro. Il RTD è quindi pari alla somma dei seguenti tempi:

- ritardo di trasferimento in un verso della comunicazione;- ritardo di trasferimento nell’altro verso;- tempo necessario al destinatario per rispondere (tempo di risposta);(si noti che il ritardo di trasferimento può essere diverso da una direzioneall’altra della comunicazione).

Normalmente, l’intervallo di tempo TO è scelto pari a (o maggiore di)RTD. Per poter operare, TCP deve conoscere il TO e quindi è necessariodeterminare il RTD. Ciò implica valutare sia il tempo di risposta che il ritardodi trasferimento nei due versi della comunicazione.

La determinazione del tempo di risposta è semplice. La determinazione del

113

ritardo di trasferimento, invece, se può essere abbastanza agevole in unaspecifica sotto-rete non lo è in Internet: una data connessione può attraversareuna sola LAN ad alta velocità o seguire un percorso attraverso numerosi router,attraversando sotto-reti con modeste capacità di trasferimento, in diversicontinenti. Inoltre il tempo di trasferimento dipende significativamente daquanto è carica la porzione di inter-rete attraversata. Se si attraversa una sotto-rete congestionata, un segmento impiegherà molto tempo per arrivare adestinazione. Ne segue che il RTD può variare significativamente ancheall’interno della stessa connessione. Ad esempio, la Fig. 20 mostra il ritardo ditrasferimento subito da 100 successivi segmenti in una specifica sotto-rete.

10090807060504030201000

2

4

6

8

10

12

��

� ��*�'

Fig. 20 - Esempio dell’andamento del ritardo di attraversamento di una sotto-rete

Come si vede il ritardo di trasferimento cambia in modo rilevante da unistante all’altro, all’interno della stessa connessione. Inoltre è facilmenteintuibile che esso possa variare in modo ancora più rilevante da connessione aconnessione. Ciò significa che non è consigliabile scegliere un valore di TOfisso, a priori; se venisse scelto un valore di TO piccolo, l’entità trasmittenteri-invierebbe senza scopo un segmento che non è andato perduto ma che èancora “in viaggio”; se venisse scelto un valore di TO grande, l’entitàtrasmittente dovrebbe aspettare inutilmente prima di poter assumere che unsegmento sia andato perso.

Per tale motivo, TCP prevede di usare un valore di TO che variaadattativamente nel tempo. Un’entità TCP mittente misura, a cadenzapre-stabilita o segmento per segmento, il round trip delay e varia il suo TO diconseguenza; se sta trattando una connessione caratterizzata da un alto valore

114

del ritardo di trasferimento sceglierà un alto valore per il TO e viceversa. E’evidente che la misura del round trip delay e la conseguente scelta del TO sonoun aspetto abbastanza critico di TCP. Una scelta errata porterebbe a moltiinconvenienti. Ad esempio, si consideri la seguente successione di eventi:

- se la rete è congestionata, i ritardi di trasferimento aumentano;- a causa di una scelta errata del valore di TO, alcuni segmenti vengono

considerati persi, anche se in realtà non lo sono, e quindi vengonori-trasmessi;

- ciò aumenta la congestione che causa ancora ri-trasmissioni finché la portatatende a zero.

D’altra parte, anche in assenza di situazioni così critiche, una scelta erratadel TO implica una perdita di efficienza e una minore velocità di trasferimento.

Si noti infine che, se si effettuasse il recupero di errore a strati inferiori, sotto-rete persotto-rete, sarebbe possibile avere stime più precise sul ritardo di trasferimento; ma in Internetciò richiederebbe sia la cooperazione tra sotto-reti diverse, sia che il controllo di errore siaeffettuato anche da ogni sistema di interconnessione. Ricordiamo infatti che TCP/IP assumesolo che ognuna delle sotto-reti interconnesse sia capace di trasferire informazione, senzarichiedere particolari prestazioni; quindi implementa tutte le funzioni che ritiene necessarie,tra cui il controllo di errore. Se alcune o tutte queste funzioni non erano state svolte da unaparticolare sotto-rete, TCP/IP le realizza; se erano già state svolte le duplica, realizzandolenuovamente.

Come per altre problematiche, si è scelta invece una soluzione che sia la più semplicepossibile e che non sia legata a particolari tecnologie delle sotto-reti componenti Internet.

Il prossimo paragrafo è dedicato alle procedure di misura del round tripdelay ed alla scelta adattativa di un opportuno valore di TO.

III.7.3.1 Stima del valore di TO (time-out di ri-trasmissione)

Il valore di RTD è più precisamente definito come l’intervallo di tempoche intercorre fra l'istante in cui si inizia la trasmissione di un segmento el'istante in cui se ne riceve il riscontro.

Un’entità TCP mittente inizializza un temporizzatore (timer) nell'istante incui inizia la trasmissione di un segmento; trascorso un tempo pari a TO, se nonriceve un riscontro, ri-trasmette il segmento. Stimare il RTD di un segmento èin teoria abbastanza semplice; ogni qualvolta TCP trasmette un segmento nememorizza il suo istante di partenza in una memoria dedicata a contenere leinformazioni di gestione della connessione; alla ricezione di un riscontro, cheinformi della corretta ricezione del segmento in questione, si può agevolmentecalcolare il RTD.

Purtroppo la situazione è più complessa poiché un riscontro si può riferireai dati complessivamente ricevuti fino ad un certo momento e non al

115

ricevimento di uno specifico datagramma. Inoltre si pone il problema di comecalcolare il RTD quando vi sono ri-trasmissioni, ovvero se calcolare il RTD apartire dall’invio del datagramma originale o di quello ri-trasmesso; in realtànessuna di queste due opzioni fornisce una stima soddisfacente del RTD.

La soluzione scelta è la seguente: si definisce un round trip delay medio(RTDM), calcolato con un’operazione di media tra successive misure di roundtrip delay; in particolare l’operazione di media utilizzata è di tipo “a mediamobile pesata” (weighted running average), calcolata con la seguente formula:

RTDM=α*precedente_valore_del_RTDM+(1-α)*corrente_valore_del_RTD

il valore del peso α deve essere scelto opportunamente; minori valori di questoparametro corrispondono ad un veloce aggiornamento del RTDM; maggiorivalori rendono il RTDM insensibile a brevi variazioni del ritardo ditrasferimento.

Il valore di TO viene quindi scelto uguale a:

TO=β*RTDM

dove β è un altro parametro da scegliere opportunamente.Per quanto riguarda il problema delle ri-trasmissioni, nel calcolo del

RTDM, TCP ignora i riscontri di segmenti ri-trasmessi, ed aggiorna il RTDMsolo con riferimento a segmenti che sono stati trasmessi una sola volta.

Infine, per assicurare la stabilità dell’algoritmo, TCP usa anche una tecnicadetta di “back-off”; ogni volta che deve ri-trasmettere un segmento, moltiplicail valore di TO precedentemente calcolato per un opportuno valore, finché ilsegmento non va a buon fine. Normalmente il valore di TO viene raddoppiatoad ogni ri-trasmissione fino al raggiungimento di un fattore moltiplicativo pari a64, ottenuto alla settima trasmissione; oltre questo valore la connessione vienere-inizializzata (con una procedura di reset). Il valore di TO tornerà al valoreprecedente solo dopo la ricezione di un riscontro relativo ad un segmento che èstato trasmesso una sola volta.

III.7.4� Controllo di flusso

Il controllo di flusso, in questo contesto, è definito come una proceduraattuata in modo coordinato da due entità TCP, una trasmittente ed unaricevente. Tale procedura è intesa a limitare il flusso dei dati trasmessi, infunzione delle risorse a disposizione nei sistemi terminali e prescindendo daltraffico presente nella inter-rete. Lo scopo del controllo di flusso è di evitareche un mittente invii dei segmenti ad un destinatario che, in quel momento, nonè in grado di riceverli, a causa di indisponibilità di risorse sia di elaborazione

116

che di memorizzazione. Tale meccanismo è indispensabile in Internet dovesistemi di dimensioni e capacità di calcolo molto diverse comunicano tra loro: ilpiù lento dei due deve poter rallentare l’emissione di informazione dell’altro.

Definiamo invece come controllo di congestione la funzione avente loscopo di evitare o di risolvere eventuali situazioni di sovraccarico all’internodella inter-rete.

Il controllo di flusso nel protocollo TCP è implementato sfruttando lostesso meccanismo usato per il controllo di errore e denominato “a finestrascorrevole” (sliding window), orientata al byte. Consideriamo anche in questocaso una connessione a strato TCP e prendiamo in esame una sola direzione deltrasferimento di dati bidirezionale in atto tra due entità TCP; nell’altro verso ditrasferimento si avrà una situazione speculare.

Si è già detto che ogni volta che l’entità destinataria emette un segmentoverso quella mittente, comunica nel campo Window la larghezza (in bytes)della finestra di trasmissione che l’entità mittente deve usare (W). L’entitàmittente dovrà usare tale valore della finestra di trasmissione fino a che nonriceve dal destinatario un successivo segmento con una diversa dimensione difinestra.

Alla ricezione di un riscontro il mittente potrà inviare ancora, senzaulteriori riscontri, bytes con un numero di ordine compreso tra x e x+W, dove xè il numero contenuto nel campo Acknowledgement Number dell’ultimoriscontro ricevuto. Trasmessi questi il mittente deve interrompere latrasmissione di dati di utente fino a che non riceva almeno un riscontro.

(L’entità mittente può però inviare i riscontri, relativi all’altro verso ditrasmissione, purché non usi la tecnica dell’addossamento, inviando quindianche dati di utente).

D’altra parte la dimensione della finestra rappresenta anche la quantità didati che l’entità destinataria è disposta a ricevere (funzione della capacità dicalcolo e della dimensione della memoria in ricezione). L’entità destinatariapuò quindi variare dinamicamente la dimensione della finestra in funzione dellesue esigenze e limitare il ritmo di trasferimento qualora non sia in grado digestirlo. Ad esempio, se il destinatario comunica al mittente una dimensione difinestra pari a zero, interromperà completamente l’invio di dati. Il mittente haperò il diritto di usare tutte le opportunità di trasmissione concesse dalle finestreprecedentemente comunicate.

Si noti infine che tale meccanismo giustifica, in parte, la tecnica usata inTCP per la numerazione in bytes dei campi Sequence Number eAcknowledgement Number, in quanto consente una maggiore flessibilità nelmodulare la dimensione della finestra.

117

III.7.5� Controllo di congestione

Il controllo di congestione ha lo scopo di evitare o di risolvere eventualisituazioni di sovraccarico all’interno della inter-rete. Il meccanismo slidingwindow di TCP funziona però da estremo ad estremo e quindi, in linea diprincipio, non può essere usato in modo efficiente per il controllo dicongestione.

Tuttavia seppure in modo implicito, e con alcune limitazioni, lo schemasliding window di TCP può proteggere sia il destinatario che, in caso dicongestione, la inter-rete. Se la porzione di inter-rete attraversata dai segmentidi una data connessione è congestionata, al mittente arriveranno, per una datalarghezza di finestra, meno riscontri; ciò forza il mittente ad emettere menoinformazione. Inoltre, siccome TCP effettua misurazioni sul round trip delay, ilvalore del time-out (TO) sarà stimato in modo opportuno e si eviterannori-trasmissioni inutili che porterebbero ad un aumento della congestione inveceche ad una sua diminuzione. Inoltre un’entità TCP destinataria può utilizzare ilround trip delay come misura di congestione e quindi per decidereopportunamente la larghezza della finestra da comunicare all’entità mittente.

Infine il meccanismo di ri-trasmissione a intervalli crescenti descritto inprecedenza (back-off) coopera in modo significativo a ridurre la congestione.

Tutto questo significa che, calibrando opportunamente i parametri delprotocollo, si può effettuare non solo un controllo di flusso ma anche uncontrollo di congestione.

Le prime implementazioni di TCP utilizzavano per il controllo della congestione, inaggiunta ai meccanismi sopra descritti, anche il protocollo ICMP. Ricordiamo infatti cheICMP può rallentare il ritmo di trasmissione del sistema mittente, mediante l'invio dimessaggi opportuni (Source Quence), nel momento in cui il sistema destinatario si trovi adover rifiutare datagrammi a causa della mancanza di risorse di memoria (cfr. § III.4.6).

Questo meccanismo di ICMP, nel caso di rapide variazioni del traffico, sembrò però deltutto insufficiente nel contesto di reti ad alta velocità (ad es. LAN). Si propose, quindi, findalla seconda metà degli anni '80, di implementare un controllo della congestione basato solosui time-out e che prescinda da ICMP. Il modulo ICMP, tuttora implementato nei sistemiterminali e nei sistemi di interconnessione, continua comunque a svolgere le altre suefunzioni.

Nelle implementazioni attuali si considera quindi lo scadere di un time-out come unsintomo di congestione delle risorse di interconnessione e si usano nuovi algoritmi per porrerimedio a tali situazioni. Ad esempio, l'algoritmo CUTE (Congestion control Using Time-outsof the End-to-end layer) fissa il valore della finestra a disposizione del mittente, non pari alvalore comunicato dal destinatario (advertised window), ma variabile tra un minimo e unmassimo. Tale algoritmo utilizza i seguenti parametri e modalità di funzionamento:- Massimo: è il valore massimo della finestra in trasmissione: in generale è pari al valore

della dimensione di finestra offerta dal destinatario;- Minimo: è il valore minimo della finestra: tipicamente pari alla dimensione di una MSS

(cfr. § III.7.2.1);

118

- Inizializzazione: rappresenta il valore iniziale della finestra: su reti molto cariche èpreferibile partire dal valore minimo;

- Incremento: si incrementa la dimensione della finestra, di un valore pari ad un segmento,ogni N segmenti ricevuti correttamente dall’entità TCP di destinazione (senza però maisuperare il valore massimo);

- Decremento: si decrementa la dimensione della finestra ogni volta che scade un time-out; ildecremento può essere di diversi tipi:• sudden, (improvviso, repentino) la dimensione della finestra è posta uguale al valore

minimo;• gradual, (graduale) la dimensione della finestra viene ridotta di un segmento;• binary, (binario) la dimensione della finestra viene divisa a metà.

Normalmente i parametri vengono scelti in modo che l’incremento della dimensionedella finestra sia lento ed il suo decremento veloce, per evitare problemi di instabilità.

III.7.6� Estensioni di TCP per le applicazioni in reti ad alta velocità

Le estensioni che sono state proposte per TCP sono funzionali ad un suomigliore comportamento in reti ad alta velocità. Il protocollo TCP, infatti, cosìcome si presenta nella sua implementazione tradizionale, non offre prestazioniottimali. In quest'ottica sono state studiate alcune modifiche orientate amigliorare l'efficienza del protocollo in questo nuovo scenario.

Innanzitutto viene osservato che in Internet il prodotto della capacità ditrasferimento per il ritardo di propagazione tende ad aumentare. Quindi unprimo passo per migliorare le prestazioni è quello di offrire al protocollo lapossibilità di operare con una finestra massima più ampia di quella che ha ora adisposizione; i 16 bit del campo Window attualmente limitano la ampiezzadella finestra a 65536 byte mentre, per aumentare la portata dei dati, sarebbeopportuno che tale campo avesse una dimensione di 32 bit. A questo scopo èstata introdotta la "Window Scale Option", che permette a due entità TCP chevogliano instaurare una connessione, di accordarsi, durante la fase diinstaurazione, sulla dimensione massima del campo Window.

Il più rilevante limite delle implementazioni tradizionali di TCP risiede,però, nella scarsa accuratezza con cui viene stimato il Round Trip Delay deisegmenti trasmessi. In certi casi l'aggiornamento della stima si basa su di unsolo segmento per finestra, creando quindi notevoli problemi di "aliasing"dovuti alla stima ed alla incapacità di adattarsi a rapidi cambiamentinell'andamento del traffico. L'inadeguatezza di questo metodo cresce inoltre alcrescere delle dimensioni della finestra disponibile. D'altra parte, anche se siaumenta la frequenza di campionamento, rimane sempre il problema dellaincapacità di stimare il Round Trip Delay, nel caso in cui avvengano delleri-trasmissioni di un segmento. Questo perché quando si riceve il riscontro di unsegmento ri-trasmesso non si è in grado di capire se tale riscontro si riferisca alsegmento originario o a quello ri-trasmesso.

119

Una soluzione a questo problema viene offerta dalla "Timestamp Option".Usando tale opzione il mittente scrive l’istante di partenza su ogni segmentotrasmesso in modo tale che il destinatario, quando ne invia il riscontro, possascrivere sul segmento di risposta l’istante di partenza del segmento a cui ilriscontro stesso si riferisce. In trasmissione basterà operare una semplicedifferenza per avere un’accurata misurazione del Round Trip Delay.

Un'ulteriore limitazione alle prestazioni del TCP risiede nel fatto che ildestinatario non ha la possibilità di informare il mittente della eventuale correttaricezione di segmenti che siano giunti a destinazione fuori sequenza. Persuperare tale problema è stata definita la opzione SACK (SelectiveAcknowledgement), che consente di confermare la corretta ricezione di unparticolare segmento (invece che di procedere in modo cumulativo) e quindiconsente di attuare un meccanismo di ri-emissione selettiva.

Il problema principale che le nuove implementazioni di TCP incontrerannosarà quello relativo alla compatibilità nelle interazioni con le versionitradizionali. Tutte le implementazioni dovrebbero ignorare le opzionisconosciute che vengono inserite nei segmenti SYN utilizzati durantel’instaurazione della connessione. D'altra parte è possibile che taluneimplementazioni di TCP diano luogo a malfunzionamenti nel momento in cuiricevono un segmento, diverso dal SYN, contenente opzioni sconosciute. Lasoluzione prospettata è quindi quella di usufruire delle estensioni al protocollo,in segmenti diversi dal SYN, solo se lo scambio di opzioni, durante la fase diinstaurazione, ha indicato che entrambe le implementazioni sono in grado dicomprendere le estensioni stesse.

III.8� Un protocollo di gestione: SNMP

Simple Network Management Protocol (SNMP) è un protocollo digestione; fornisce informazioni relative a configurazioni, errori e allarmi disistemi remoti. Come il nome suggerisce, è uno strumento abbastanza sempliceper la gestione di reti, che si appoggia su di un limitato "ManagementInformation Base" (MIB) standard per la descrizione delle risorse gestite. IlMIB specifica quali sono le informazioni che un sistema deve contenere per finigestionali e l’uso che se ne può fare. Ad esempio MIB specifica che si devemantenere un contatore degli ottetti ricevuti su ogni interfaccia di rete; altrevariabili previste da MIB possono essere il tempo da cui è in funzione unsistema, il numero dei datagrammi ricevuti o trasmessi, i diversi time-out usatidai protocolli etc. MIB classifica queste variabili in 8 categorie (sistema,interfacce, indirizzi, ip, icmp, tcp, udp, egp). SNMP è facilmente

120

implementabile e consente la gestione delle variabili descritte nel MIB, e quindidelle risorse, e la gestione di situazioni anomale mediante delle segnalazioninon sollecitate.

Il maggior vantaggio di SNMP risiede proprio nella sua semplicità chepermette una facile ingegnerizzazione di rete con modesti consumi di risorse dielaborazione e di memorizzazione. Inoltre, la struttura del protocollo e del MIBsono sufficientemente semplici per garantire l'inter-operabilità tra stazioni digestione e sistemi controllati provenienti da diversi costruttori.

A fronte di tale semplicità, però, la piattaforma gestionale contrappone unlimitato insieme di primitive ed una limitata sicurezza delle informazioniscambiate tra stazione di controllo e sistemi controllati.

III.9� Accesso ad Internet tramite un Internet Service Provider

A conclusione della descrizione delle modalità di funzionamento diInternet, riteniamo utile riprendere quanto detto nell'Introduzione, circal'accesso ad Internet tramite un ISP.

La trattazione fin qui svolta ha fatto riferimento a sistemi (host)direttamente connessi ad Internet e dotati di un proprio, stabile ed univocoindirizzo. Questo non è il caso di sistemi che si connettono ad Internet per iltramite di un Internet Service Provider (ISP), usando tipicamente la retetelefonica commutata, ovvero la probabile maggioranza dei lettori di questamonografia. A tali host non è stato assegnato un indirizzo IP stabile ed univocosecondo le regole descritte in precedenza. In particolare, quando uno di questihost si connette at Internet tramite un ISP, prima di poter iniziare effettivamenteuno scambio informativo con altri host, riceve dall'ISP delle opportuneinformazioni di configurazione, tra cui un indirizzo IP, l'indirizzo del router didefault (cfr. III.4.5.3) e quello del name server (cfr. III.4.7).

L'indirizzo IP ricevuto può essere assegnato dall'ISP secondo duemodalità:

1. L'ISP dispone di un certo insieme di indirizzi IP univoci e consignificato globale che assegna dinamicamente a quegli host che in undato momento gli richiedono di connettersi ad Internet. Ognuno diquesti host è caratterizzato da un dato indirizzo IP solo per il tempodurante il quale è connesso ad Internet; quando l’host termina diusufruire dei servizi Internet, quell’indirizzo IP sarà assegnato ad unaltro host che, in un tempo successivo, chiederà di connettersi adInternet.

2. L'ISP assegna ai suoi utenti indirizzi IP che hanno solo un significato

121

locale e, non essendo visibili all’esterno, possono essere scelti in modoarbitrario. Sarà poi compito del fornitore di servizi porre incorrispondenza tali indirizzi con specifiche sessioni di comunicazione.

Ciò significa che un utente di questo tipo è raggiungibile dall'esterno solotramite il suo ISP, dal momento che l'utente in questione, non disponendotipicamente di un indirizzo stabile ed univoco in Internet non è "conosciuto"dagli altri sistemi connessi ad Internet (cfr. III.4.4). Quando un host si connettead Internet secondo questa modalità è necessario usare anche un ulterioreprotocollo che governa lo scambio di informazioni e di comandi tra utente efornitore di servizi. Un esempio di tale protocollo è PPP (Point to PointProtocol).

IV� Evoluzione di Internet

Nel seguito la rete B-ISDN con i suoi protocolli ed architetture saràindicata semplicemente con il termine ATM, mentre la rete Internet conl’insieme dei protocolli TCP/IP e la relativa architettura sarà indicata comeTCP/IP.

TCP/IP e ATM possono essere considerati due tra i principali paradigmi dicomunicazione emersi negli ultimi anni. L’evoluzione e l’eventualeintegrazione di queste tecnologie determinerà le modalità di funzionamentodelle future reti di telecomunicazioni che dovranno soddisfare le crescentiesigenze dell’utenza in termini sia di qualità che di funzionalità del servizio. Glioperatori dovranno fornire servizi di telecomunicazione caratterizzati da:

- sofisticate funzionalità: comunicazioni interattive multimediali,comunicazioni con configurazione punto-multipunto e multipunto-multipunto, mobilità personale e di terminale, sicurezza e confidenzialitàdell’informazione trasferita e prestazioni addizionali integranti i servizi dibase;

- garanzia della qualità del servizio offerto in termini di: ritmo binario ditrasferimento, ritardo di trasferimento e sua variabilità, tasso di perdita diinformazione, ritardo di accesso al servizio.

Non va inoltre trascurato che la definizione delle modalità di trasferimentodeve tenere in conto le esigenze dell’operatore tra le quali: compatibilità coneventuali soluzioni pre-esistenti e agevole transizione verso nuove tecnologie,flessibilità, efficienza nell’utilizzo delle risorse e nella gestione della rete.

L’evoluzione di TCP/IP e di ATM ha motivato un ampio dibattito nellacomunità scientifica ed economica; in una prima fase tale dibattito è statocaratterizzato da un’accesa contrapposizione dei fautori dei due modelli che

122

proponevano l’adozione di uno di questi, criticando la validità dell’altro. Piùrecentemente l’opinione prevalente si è modificata e tende ad ipotizzare unaintegrazione dei due paradigmi.

In particolare i sostenitori dell’ATM si ponevano come traguardo larealizzazione di una rete unica per il trasporto ubiquitario di qualsiasi tipo diinformazione (la B-ISDN), soddisfacendo così il bisogno di integrare servizidistributivi e interattivi, modi di trasferimento a pacchetto e a circuito perconseguire significativi vantaggi in termini di economia, programmazione,sviluppo, implementazione e gestione delle reti. Si tratta, come si può vedere, diun obiettivo ambizioso: fare evolvere le reti in area geografica, partendo dallarete telefonica analogica, attraverso la IDN e la N-ISDN e integrando reti perdati pre-esistenti per convergere verso la B-ISDN.

La filosofia seguita dai fautori di TCP/IP è invece diametralmente opposta.Si prende atto che il tentativo, perseguito già dai proponenti del modello OSI, diuniformare il più possibile i diversi sistemi di telecomunicazione fino agiungere ad uno standard unico, non ha avuto il successo sperato. Negli ultimidecenni si sono infatti sviluppate soluzioni molto diverse tra loro: reti in arealocale (Ethernet, Token ring, Token bus, etc.), reti in area metropolitana (FDDI,DQDB), reti proprietarie (DECnet, SNA), rete telefonica, N-ISDN, circuitidiretti, Frame Relay, SMDS, etc. La realizzazione di questi sistemi ha richiestonotevoli investimenti ed è difficile pensare che essi possano essere sostituiti,anche nel medio termine, da una nuova, unica rete. Inoltre si fa notare cheun’unica rete difficilmente può rispondere in modo esauriente ed efficiente alleesigenze di un generico utente; ad es. le LAN consentono alte velocità ditrasferimento ma sono limitate geograficamente; il viceversa accade per leWAN.

D’altra parte è sicuramente vero che gli utenti desiderano una connettivitàuniversale ed è quindi necessario far si che utenti connessi a reti diversepossano colloquiare tra loro.

Per rispondere a questa esigenza è stato introdotto il concetto di inter-rete,e cioè di una infrastruttura il cui elemento distintivo è rappresentatodall’insieme di procedure e di risorse di inter-lavoro necessarie perinterconnettere reti diverse ed eterogenee. Internet non è altro che un esempio diinter-rete.

Si vede dunque come l’approccio seguito dai due paradigmi in questionesia diverso: ATM tende ad unificare, TCP/IP prende atto delle diversità e cercadi far interagire sistemi diversi. Ambedue le soluzioni presentano comunque latipositivi e negativi e ciò giustifica la diversità di opinioni prima accennata.

123

Nel seguito si analizzeranno i diversi scenari evolutivi che appaiono essereoggi i più probabili per Internet (cfr. IV.1). Discuteremo prima alcune soluzioniproposte per migliorare le prestazioni di TCP/IP in termini di portata (cfr. IV.2)e per garantire agli utenti una pre-determinata qualità di servizio (cfr. IV.3).Quindi daremo alcune cenni sulla nuove versione di IP (IPv6) (cfr. IV.4) e sulletecniche per supportare la mobilità in Internet (Mobile IP) (cfr. IV.5).

Anche se questa trattazione è dedicata a TCP/IP, ATM continua a svolgereun ruolo importante. Per questo motivo, prima di dedicarsi agli scenari evolutivisopra descritti è utile riassumere pregi e difetti delle due tecniche e relativiscenari evolutivi.

IV.1� TCP/IP e ATM: verso l’integrazione

Per far fronte alle crescenti esigenze dell’utenza, sia ATM che TCP/IPstanno rapidamente evolvendo in un crescente clima di interazione e diintegrazione che ha in parte sostituito la precedente competitività.

Mentre però ATM ha avuto fino ad oggi uno sviluppo inferiore alleaspettative dei suoi promotori, Internet è enormemente cresciuta da una piccolacomunità di utenti a una popolazione di diversi milioni di hosts attestati sudecine di migliaia di sotto-reti interconnesse.

Nonostante il successo, TCP/IP soffre di alcune limitazioni strutturali. Lanatura senza connessione di IP, fonte, in parte rilevante, dell’attuale successo,rende impossibile riservare le risorse di rete ed assicurare così servizi ditrasferimento in tempo reale con garanzia della qualità di servizio e raggiungereelevate prestazioni in termini di ritmo binario di trasferimento. Sembrerebbedunque impossibile usare TCP/IP così come è oggi per fornire servizi ditelefonia di base, video conferenza e diffusione televisiva, a meno, e solo entrocerti limiti, di sovra-dimensionare le risorse di rete.

Per questa ragione la IETF ha proposto il concetto di “Integrated Serviceson Internet” (IS), secondo il quale un nuovo modello architetturale, insieme aduna nuova generazione di protocolli (IPv6, RSVP, RTP, DiffServ etc.), dovràfornire servizi in tempi reale e con garanzia della qualità di servizio.

Una inter-rete di tipo IS può essere realizzata anche sfruttando l’attuale,eterogenea, infrastruttura di inter-rete, ma è sicuramente di più agevoleattuazione se si può utilizzare un’architettura di rete che forniscaintrinsecamente una pre-determinata qualità di servizio ed elevate prestazioni intermini di portata, quale la B-ISDN/ATM.

E’ utile riassumere i principali vantaggi e possibili svantaggi delparadigma TCP/IP.

124

Vantaggi:- TCP/IP è attualmente diffuso in modo talmente capillare che è difficile

ipotizzare una soluzione che non tenga conto degli investimenti necessari percambiare una tecnologia così largamente utilizzata;

- IP è senza connessione; ciò significa che:1. deve “solo” inoltrare le unità di dati ma non fornire funzionalità di

controllo di errore e di flusso e può quindi operare al di sopra di diversetipologie di sotto-rete;

2. non deve mantenere informazioni sullo stato delle connessioni, dalmomento che queste ultime non esistono; ciò implica semplicità erobustezza;

3. il software può essere molto semplice: in una rete funzionante con unamodalità con connessione, circa il 90% del codice serve a gestiresituazioni di errore;

4. è scalabile: eventuali guasti possono essere semplicemente “aggirati”dal protocollo IP;

5. è facilmente ri-configurabile: l’aggiunta o l’eliminazione di host o sotto-reti non implicano complesse operazioni di gestione di rete;

Svantaggi:- prestazioni limitate in termini di portata; l’inoltro delle unità di dati è gestito

in modo software e ciò conduce ad un inevitabile collo di bottiglia seraffrontato ad una commutazione hardware, tipico di un modo ditrasferimento con connessione;

- assenza della scelta e della garanzia di una pre-determinata qualità delservizio offerto;

- altre problematiche, quali lo spazio di indirizzi limitato, l’assenza disicurezza e confidenzialità nel trasporto dell’informazione, la limitatagerarchia di livelli di indirizzi, di connettività e di responsabilità di gestione el’assenza della gestione della mobilità, possono essere considerati superati daIPv6 (cfr. IV.4) e Mobile IP (cfr. IV.5).

Per ciò che riguarda l’ATM, essendo questa tecnica nata comeinfrastruttura di trasporto ad alte prestazioni si era pensato che avrebbe trovatola sua prima diffusione nel mercato delle reti private; infatti le LAN ATM sonostati i primi prodotti commerciali basati su questa tecnica. Contrariamente aquesta aspettativa, la vendita di LAN ATM non ha avuto il successo sperato.Tra le motivazioni della scarsa penetrazione commerciale di tali prodotti sonosicuramente da citare le seguenti:

- solo un limitato numero di utenti (ad es. progettisti CAD/CAE) è oggiinteressato ad avere una capacità di trasferimento individuale dell'ordine di

125

155 Mbit/s; per questa ragione si sono definiti standard ATM a velocitàinferiore (25 Mbit/s);

- l'incremento prestazionale di collaudate tecnologie per l'interconnessione inarea locale (switched Ethernet e fast Ethernet, 100baseT, 100VG/AnyLan eGigabit Ethernet) ha portato ad offrire prestazioni in termini di portatacomplessiva ancora inferiori ma tuttavia paragonabili a quelle dell'ATM ecomunque rispondenti alle esigenze degli utenti; a differenza delle LANATM queste soluzioni sono compatibili con i sistemi già installati edeconomicamente più vantaggiose;

- la promessa connettività globale ATM sembra essere ancora lontana neltempo (posto che veramente ci sarà) e quindi installare una LAN ATM noncomporta i vantaggi derivanti dall'adottare una tecnologia che consentirebbeun agevole accesso alle reti in area geografica;

Nonostante la delusione nel mercato delle LAN, l'ATM sembra peròguadagnare terreno nel campo delle reti pubbliche e geografiche. In tale campoè usato come infrastruttura di trasporto al servizio di altri protocolli di rete (tracui ovviamente IP).

Tra i vantaggi e gli svantaggi del paradigma ATM sono da citare:Vantaggi:

- commutazione molto veloce, standard ed economica, realizzata in hardware- scalabilità in termini sia di capacità di trasferimento che di commutazione;- potenziale supporto di scelta e garanzia della Qualità di Servizio;

Svantaggi:- le funzioni di multiplazione e di commutazione sono molto semplici ma

quelle di segnalazione non lo sono: il funzionamento di una rete ATMrichiede una complessa infrastruttura software per il trattamentodell'informazione di controllo;

- non è compatibile all'indietro con le soluzioni attualmente esistenti; ciòimplica che l'interlavoro con altre sotto-reti è abbastanza complesso;

- non dispone di capacità di broadcast mentre quelle di multicast richiedonocomplesse procedure per essere attuate (entrambe sono invece richieste damolti protocolli usati attualmente in Internet, ad esempio per la risoluzionedegli indirizzi).

Sembra quindi che entrambi i paradigmi abbiano limiti. D'altra parte lasoluzione di adottare l'intero insieme dei protocolli TCP/IP logicamente situatoal di sopra dell'intero insieme dei protocolli ATM presenta significativisvantaggi:

- duplicazione delle funzionalità di instradamento e di gestione e aggiunta diulteriori funzionalità di gestione per gestire le interazioni tra i due paradigmi;

126

- difficoltà nell'implementare procedure per la risoluzione degli indirizzi (daindirizzi IP a indirizzi ATM e viceversa) in assenza di semplici funzionalitàdi broadcast e multicast;

- parziale perdita dei vantaggi derivanti dalla modalità di trasferimento senzaconnessione di IP;

- difficoltà nel determinare la durata di una connessione ATM per il trasportodi datagrammi IP;

- inefficienza del processo di instaurazione di una connessione ATM per iltrasporto di singoli o poco numerosi datagrammi IP (richiesti ad esempionelle procedure di risoluzione di indirizzi e di interrogazione del DNS);

- difficoltà nello sfruttare la potenziale garanzia di Qualità di Serviziopromessa dal paradigma con connessione dell'ATM quando al di sopra diesso si usa un protocollo senza connessione quale IP; se la soluzione fosseusare RSVP allora la complessa segnalazione ATM diverrebbe in qualchemodo ridondante;

- seri problemi di scalabilità;- problematiche di sicurezza e confidenzialità: in una soluzione IP su ATM un

utente potrebbe stabilire una connessione verso una destinazione permessa aldi là di un sistema firewall e quindi inviare pacchetti con differentiintestazioni ottenendo così accesso a destinazioni proibite;

In conclusione il problema maggiore che si deve affrontare non è tantol'evoluzione della tecnologia ma come gestire il cambiamento dalle reti attualia quelle future e come integrare con efficienza vecchie e nuove soluzioni.

Oggi poche persone ritengono che ATM diverrà ubiquitario, anzi moltipropongono di trasportare IP direttamente su SDH o su WDM, cancellandoquindi completamente l’ATM. Ciononostante, anche prestando fede alle ipotesipiù pessimistiche per ATM (che comunque non sono da tutti condivise) bisognaconsiderare che sono state ormai installate numerose reti ATM e risultaeconomicamente svantaggioso non continuare ad usarle.

Ciò comporta che la più probabile soluzione è una qualche forma diintegrazione di TCP/IP e di ATM, in cui però TCP/IP svolge un ruolopredominante mentre ATM, eventualmente privato di alcune sue funzionalità,svolge un ruolo di supporto. Lo scenario più credibile a medio termine ècomunque quello in cui le attuali applicazioni continueranno ad esseresupportate dall'insieme dei protocolli TCP/IP mentre nuove applicazioni conrequisiti di tempo reale e di Qualità di Servizio garantita potranno usare siaancora TCP/IP (integrato però da altre funzionalità come RSVP o DiffServ) chedirettamente l'ATM, qualora questo fosse disponibile. L’ATM sarà comunque

127

probabilmente impiegato nella sezione interna di rete (o più generalmente confunzionalità di “backbone”).

Ciò pone il problema dell’inter-lavoro tra questi due paradigmi.Inizialmente sia ATM Forum che IETF hanno lavorato a soluzioni persupportare l’insieme dei protocolli TCP/IP logicamente situato al di sopradell’intero insieme dei protocolli ATM. Sono stati definiti diversi standard comeClassical IP over ATM (RFC 1577/2225), Multiprotocol over ATM (MPOA),LAN Emulation (LANE); queste proposte non hanno avuto il successo sperato,a causa dei problemi delineati sopra.

La tendenza attuale è invece quella di integrare TCP/IP con ATMselezionando però solo alcune funzionalità dell'ATM stesso, ovvero escludendole funzioni di trattamento di chiamata e di instradamento.

A questo proposito è utile notare che la dizione ATM viene oggi spessousata in due accezioni diverse; nel suo significato originale comprende, comedetto sopra, l’intero paradigma, compresi i protocolli di segnalazione per iltrattamento di chiamata, per l'indirizzamento e per l'instradamento (e.g. Q.2931,segnalazione NNI, P-NNI etc.); in altri termini è trattata come una soluzione distrato 3. In una accezione più recente, per ATM si intende solo il formatodell’unità di dati e le relative architetture di commutazione, ovvero ATM ètrattata come una soluzione di strato 2. Per evitare confusioni, nel seguito siindicherà con il termine “ATM completo” (o ATM come strato di rete) il primosignificato e “ATM non completo” (o ATM come strato di collegamento) ilsecondo. L’integrazione dei paradigmi TCP/IP e ATM tende all’unione diTCP/IP con un ATM non completo.

Con queste premesse, possiamo ora esaminare i più importanti fattorievolutivi di Internet, iniziando dalle tecniche proposte per migliorare leprestazioni in termini di quantità di informazione trasferibile (o portata).

IV.2� Soluzioni per migliorare le prestazioni di portata

Uno dei maggiori limiti attuali di TCP/IP è costituito dalle limitazioni intermini di portata derivanti dal collo di bottiglia causato dai router, in cuil’inoltro dei datagrammi si basa su funzioni eseguite via software. Si ricordache un router deve esaminare l’intestazione di ogni datagramma IP, consultarela tabella di instradamento e quindi decidere verso quale terminazione di uscitainstradare il datagramma stesso; inoltre ogni router deve aggiornarel’intestazione (e.g., campo TTL) ed eventualmente frammentare il datagramma.In altri termini la funzione decisionale deve essere eseguita per ognidatagramma. Tale modo di operare limita significativamente le prestazioni in

128

termini di portata. Infatti, la complessità del trattamento logico dei datagramminon consente di sfruttare appieno gli elevati ritmi binari (dell’ordine deiTerabit/s) oggi disponibili a livello di strato fisico. Al contrario, in un modo ditrasferimento orientato alla connessione, la funzione decisionale è eseguita solodurante la fase di instaurazione, dopo di che tutte le unità di dati appartenenti aduna stessa connessione sono instradate verso la stessa terminazione di uscita,eseguendo solo un’operazione di traduzione di etichetta (tecnica della“commutazione di etichetta” o label switching). In quest’ultimo caso, la fase ditrasferimento dei dati, successiva a quella di instaurazione, può essere eseguitadirettamente in hardware e quindi in modo efficiente e veloce.

E’ bene precisare che, in IP, il disaccoppiamento tra la fase di determinazione delletabelle di instradamento e la relativa consultazione, fa si che, di fatto, non e’ necessario attuarela funzione decisionale per ogni datagramma. In altri termini supponendo che in un certointervallo di tempo la tabella di instradamento non muti, allora il processamento di undatagramma IP non è poi operativamente molto diverso da quello di una cella ATM. Inentrambi i casi, un opportuno campo dell'intestazione (indirizzo di destinazione in IP,VPI/VCI in ATM) funge da puntatore ad una tabella la quale fornisce l'identificativo dellalinea di uscita su cui instradare l'unità informativa. La differenza sta nelle dimensione delcampo e nelle modalità di ricerca, queste ultime possono essere più efficienti in ATM che nonin IP. In particolare, in IP, la scansione della tabella per ricercare l'informazione volutaavviene mediante la tecnica del "longest prefix matching". Bisogna cioè cercare un campo didimensioni variabili; infatti l'algoritmo di instradamento parte dell'indirizzo IP di destinazionee cerca nella tabella la più lunga stringa in comune con l'indirizzo di destinazione, a partire daibit più significativi. La coincidenza tra indirizzo di destinazione e stringa trovata nella tabellapuò essere completa, riguardare solo la parte Net_ID, o essere nulla. Invece, in ATM o in altriprotocolli con connessione l'operazione eseguita è denominata "table lookup" e riguarda uncampo di dimensioni costanti. E' evidente che quest'ultima operazione è alquanto più semplicedel "longest prefix matching".

L’ATM opera secondo quest’ultimo approccio e ciò spiega le elevateprestazioni in termini di portata ottenibili mediante questa tecnica ed isignificativi vantaggi attribuitigli, quando confrontata a TCP/IP:

- commutazione molto veloce, standard ed economica, realizzata in hardware;- scalabilità in termini sia di capacità di trasferimento che di commutazione.

Si evidenzia inoltre che questa caratteristica è una delle principalimotivazioni a sostegno dell’uso dell’ATM. Se il paradigma TCP/IP potessevantare prestazioni di commutazione paragonabili a quelle dell’ATM, cadrebbeuna delle sostanziali ragioni che giustificano l’introduzione di questa tecnica inInternet.

Le limitazioni di portata dei router tradizionali usati in Internet divengonosempre più evidenti con la progressiva crescita del traffico nella stessa. Al fine

129

di migliorare le prestazioni dei router si seguono attualmente tre diversiapprocci:1- miglioramento delle prestazioni dei router tradizionali mediante gli

sviluppi della tecnologia (processori e memorie più veloci, architettureinnovative, algoritmi di consultazione delle tabelle di instradamento piùefficienti, etc.) o mediante la semplice replicazione degli apparati;

2- integrazione delle funzionalità di un router IP con le capacità dicommutazione di una matrice di commutazione veloce (e.g., ATM); questoapproccio è noto anche con il termine “commutatori multi-strato ocommutatori di strato 3”;

3- uso di tecniche di inter-lavoro IP<->ATM, al fine di trattare la maggiorparte possibile del traffico direttamente “in ATM”.Al solito, oltre alle prestazioni in termini assoluti, uno dei fattori che

determina il successo di una soluzione è la compatibilità all’indietro. Da questopunto di vista gli approcci appena esposti sono in ordine di compatibilitàall’indietro decrescente: il primo non richiede alcuna modifica, il secondoimplica l’aggiunta di alcuni protocolli ad hoc, il terzo prevede modifichesostanziali.

Ciò giustifica il fatto che i sistemi già presenti sul mercato e implementatio in via di implementazione appartengano principalmente alle prime duecategorie, con prevalenza della prima.

Tuttavia, in una prospettiva a più lungo termine, occorre rilevare che se ilprimo degli approcci di cui sopra potrà forse soddisfare anche nel mediotermine le esigenze di Internet per quanto riguarda la sua tradizionale tipologiadi traffico (e.g., dati), è difficile pensare che possa far fonte anche ad altriservizi di telecomunicazioni, quali voce, video e in generale servizimultimediali.

A meno di sviluppi tecnologici attualmente non prevedibili, la portata diuna rete basata solo sulla commutazione “software” tipica di IP non può trattarei volumi di traffico tipici di una rete geografica integrata nei serviziNel seguito di questo capitolo si esporranno i primi 2 approcci di cui sopra,scartando il terzo per le ragioni esposte alla fine del IV.1 .

IV.2.1� Routers veloci

I routers ad alta capacità sono attualmente noti come Gigabit routers.Poiché la lunghezza media di un datagramma IP è dell’ordine di 2000 bit[JAM97, NEW97], un gigabit router deve avere una capacità di processamentoe di inoltro di 500 000 datagrammi/s per ogni Gbit/s di traffico trattato (il collo

130

di bottiglia è nella funzione decisionale e la complessità di questa èproporzionale ai datagrammi trattati e non ai bit).

Prestazioni dell’ordine di centinaia di migliaia di datagrammi/s trattati nonsono possibili con i router tradizionali. L’architettura fisica di un gigabit routerè basata su di una matrice di commutazione invece che sul classico “backplanebus” (Fig. 21).

Matrice dicommutazione

Processoredi controllo

1

N

.

.

.

.

.

.Line card

Forwardingengine

Forwardingengine

Line card

Fig. 21- Architettura fisica di un gigabit router

Le “line card” contengono le componenti di strato fisico necessarie perinterconnettere il router alle linee esterne. La matrice di commutazione è usataper interconnettere le varie componenti del router. Le “forwarding engines”esaminano le intestazioni dei datagrammi, determinano verso qualeterminazione di uscita instradarli e aggiornano l’intestazione (e.g., campo TTL).Il processore di controllo esegue i protocolli di instradamento e determina letabelle di instradamento che saranno poi copiate in (o consultate da) ognunadelle “forwarding engines”. Il processore di controllo si occupa anche difunzioni di gestione, trattamento di situazioni di errore e di datagrammi cherichiedono particolari operazioni. La matrice di commutazione offre unacapacità aggregata molto superiore a quella di un convenzionale bus.

Diversi prodotti commerciali basati su questa architettura sono oggidisponibili. Nel seguito si esamineranno degli esempi di gigabit router. Loscopo è quello di delineare le modalità di funzionamento ed identificare i punticritici di questi sistemi. I valori prestazionali hanno quindi solo un significato di“case study”, anche perché l’evoluzione in questo campo è talmente rapida darendere presto obsoleta un’analisi basata su di un determinato prodotto.

Due esempi di gigabit router sono:- il Multigigabit Router; usa una matrice con 15 porte ognuna delle quali con

131

capacità di 3.3 Gbit/s [JAM97, NEW97];- il NetStar GigaRouter; usa una matrice con 16 porte ognuna delle quali con

capacità di 1 Gbit/s [JAM97, NEW97].La forwarding engine può essere una componente fisicamente separata o

essere integrata sia con le line card che con il processore di controllo. Nel primocaso il ritmo di inoltro dei datagrammi può essere variato indipendentementedalla capacità aggregata, regolando il rapporto tra forwarding engines e linecards; questo è l’approccio seguito nel Multigigabit Router. Il NetStarGigaRouter integra invece una forwarding engine con ogni line card.

Si noti che la forwarding engine è comunque necessaria in un routermentre non lo è in un commutatore ATM classico; è quindi chiaro chequest’elemento è il collo di bottiglia dell’intero sistema.

Due approcci sono stati proposti per far lavorare una forwarding enginealla velocità voluta:

- usare forwarding engines implementate “in silicio”;- adottare un processore “general purpose” ma molto veloce e con una

memoria cache integrata capace di contenere un significativo numero dicorrispondenze indirizzi di destinazione->terminazioni di uscita (ovvero di“strade”).

Per implementare una forwarding engine in silicio è necessario mantenerenella sua memoria una tabella di instradamento, strutturata ad albero. Unatabella tipica di 250 000 strade richiede circa 4 Mbytes di memoria (compatibilecon le disponibilità attuali di SRAM). Il numero di accessi alla memoria perogni strada da cercare è circa 1 + logN, se N è il numero di strade nella tabella.Se si assume una SRAM con tempo di accesso di 10 ns, una ricerca di stradarichiede 200 ns e la forwarding engine può gestire 5 milioni di datagrammi alsecondo, corrispondenti a 10 Gbit/s di traffico (con datagrammi di lunghezzamedia di 2000 bit). Nel caso di datagrammi lunghi 40 bytes può ancora gestire1.6 Gbit/s. Se la dimensione della tabella di instradamento aumenta si possonousare tecniche di ricerca più sofisticate che riducono il numero di accessi allamemoria.

Il NetStar GigaRouter include una forwarding engine in ogni line card conuna connessione verso la matrice di commutazione di capacità pari a 1 Gbit/s.La forwarding engine supporta una tabella di instradamento capace di contenere150 000 strade. In quest’ultimo caso la determinazione di una strada richiede 3µs, con una corrispondente massima velocità di inoltro dei datagrammi di 333333 datagrammi/s; a causa però di limitazioni delle line cards usate in questorouter la massima velocità di inoltro risulta essere di 136 000 datagrammi/s.Questo valore non è sufficiente a sfruttare a pieno la velocità fisica delle sue

132

porte (1 Gbit/s) con datagrammi di lunghezza media di 2000 bit (sarebberonecessari 500 000 datagrammi/s).

La forwarding engine del Multigigabit Router usa un processore “generalpurpose” con una memoria cache integrata capace di contenere un significativonumero di strade. Tale cache contiene le 9000 strade più recentementeindividuate. Una memoria esterna contiene invece la tabella di instradamentocompleta capace di contenere diverse centinaia di migliaia di strade.

Le sue prestazioni sono:– se tutte le destinazioni sono trovate in cache -> 11 M datagrammi/s;– hit ratio dell’80% -> 6.5 M datagrammi/s (target perché la forwarding engine

non sia un collo di bottiglia);– hit ratio dello 0% -> 3.2 M datagrammi/s.

Come si vede le prestazioni variano significativamente in funzione dellaprobabilità di trovare una strada nella memoria cache senza la necessità diandarla a reperire nella memoria esterna (il che ovviamente richiede più tempo).Vi è un dibattito in corso riguardante l’utilità delle memorie cache, o in altritermini se il traffico Internet possiede una sufficiente “località” da renderevantaggioso l’uso di questo meccanismo. Analisi di traffico hanno mostrato unhit ratio di circa il 95% con una cache contenente 6000 strade ma è dubbio setale dato sia significativo in generale.

Al contrario una forwarding engine implementata in silicio non ha bisognodel meccanismo di “caching” e quindi le sue prestazioni sono indipendenti dalfenomeno appena discusso.

Comunque, in entrambe le soluzioni appena esaminate, i datagrammimulticast, eventuali operazioni di filtraggio legate a funzioni di firewall edatagrammi con opzioni non usuali sono trattati direttamente dal processore dicontrollo e quindi a più bassa velocità.

Si è già detto che un limite di queste soluzioni è che, nonostante le più alteprestazioni rispetto ai router tradizionali, il volume di traffico che i gigabitrouter consentono di gestire non appare adeguato alle esigenze tipiche di unarete geografica integrata nei servizi.

Un altro limite è che, come ogni altra soluzione puramente hardware,questi sistemi mancano di flessibilità: le applicazioni e quindi i profili ditraffico cambiano nel tempo. Ad esempio:

- il traffico multicast potrebbe aumentare significativamente (applicazionimultimediali e diffusive)

- l’introduzione di IPv6 (cfr. IV.4) porta ad un quadruplicamento delladimensione delle tabelle di instradamento (indirizzi di 128 bit invece che di32 come in IPv4);

133

- la differenziazione della qualità di servizio (e.g. RSVP e DiffServ) implica lanecessità di implementare un instradamento basato non solo sull’indirizzo didestinazione ma anche su altre informazioni.

Una soluzione fissa non può tener conto di questi cambiamenti e quindidifficilmente può essere considerata come una soluzione di lungo termine.

IV.2.2� Commutatori multi-strato

L’alternativa ai sistemi appena esaminati è una soluzione di tipo software,ma basata su un’architettura fisica molto veloce e con l’aggiunta di protocolliad hoc per superare il collo di bottiglia dovuto al trattamento software stesso. Ilnome deriva dal fatto che combinano l’alta velocità di un commutatore “distrato 2” con il software di IP “di strato 3”. In realtà tale nomenclatura non è deltutto corretta in quanto gli autocommutatori usati possono svolgere, nell’ambitodelle sotto-reti di appartenenza, funzioni di strato 3 e tipicamente il protocolloIP è logicamente situato al di sopra dei protocolli di strato 3 delle sotto-reti cheinterconnette, per cui può essere considerato come un protocollo di strato 3 “dilivello più alto”.

L’architettura fisica è simile a quella mostrata in Fig. 21. La matrice dicommutazione usata è tipicamente ATM. Si sottolinea però che queste soluzioniusano del paradigma ATM solo il formato dell’unità di dati e le relativearchitetture di commutazione, ma non i relativi protocolli di segnalazione e lemodalità generali di funzionamento dell’intero paradigma, altrimenti nonsarebbero altro che dei normali autocommutatori ATM, con ciò che neconsegue. In altri termini ricadremmo nella tipologia delle soluzioni basate suinterlavoro tra IP e ATM, ovvero assumeremmo che alcune sezioni di reteoperino secondo il paradigma ATM, il che ad oggi non appare probabile (cfr.fine del IV.1. In particolare un vero e proprio commutatore ATM è orientatoalla connessione, mentre sono i protocolli non orientati alla connessione (IP)che sono oggetto dei commutatori multi-strato e più in generale dei router. Ilvantaggio di usare una matrice ATM è già stato esposto.

Le soluzioni in esame sono basate sul concetto di “flusso” e sono stateproposte quasi contemporaneamente da diversi gruppi di ricerca [e.g. NEW96,NEW97]. Il concetto di flusso si basa sulle seguenti considerazioni. Alcuneapplicazioni “preferiscono” un trasferimento con connessione:

- traffico con requisiti di tempo reale o con altri requisiti di qualità di servizio;- traffico con lunghi tempi di attività;Altre applicazioni “preferiscono” un trasferimento senza connessione:

- traffico con bassi tempi di attività (e.g. protocolli di routing o di ricerca DNS,interrogazione di database, etc.);

134

- traffico senza particolari esigenze di qualità di servizio e sporadico;Per questo secondo tipo di traffico è altamente inefficiente instaurare una

connessione; inoltre, una rete con connessione soffre degli svantaggi esposti inIII.1. D’altra parte una rete senza connessione non soddisfa le esigenze deltraffico appartenente alla prima categoria: la funzione decisionale deve essereeseguita datagramma per datagramma e non è possibile garantire una qualità diservizio. Quest’ultima affermazione è particolarmente importante; non si staparlando infatti di difficoltà ma di impossibilità: In una rete senza connessionenon ha senso parlare di garantire la qualità di servizio vista da un utente poichéla rete “vede” solo datagrammi isolati e non associa tra loro tutti i datagrammiemessi da un dato utente nell’ambito di una stessa applicazione. Manca quindil’oggetto su cui applicare determinati meccanismi di controllo del traffico: laconnessione o, in mancanza di essa, un’associazione logica tra piùdatagrammi.

Se si stabilisce almeno quest’ultima associazione, allora diviene possibilesia evitare di esercitare la funzione decisionale datagramma per datagramma siaprendere in considerazione meccanismi per la garanzia della qualità di servizio.Tutti i datagrammi appartenenti ad uno stesso flusso vengono trattati allo stessomodo, in modo analogo alle unità di dati appartenenti ad una stessaconnessione, in una rete con connessione. L’informazione riguardante versoquale terminazione di uscita instradare un datagramma è ora associata al flussocui il datagramma stesso appartiene.

Si noti comunque che l’associazione logica tra più datagrammi è già in séuno degli elementi distintivi del concetto di connessione, mancando ancora perarrivare a quest’ultima le fasi di instaurazione e di abbattimento e quindi ancheun accordo preventivo tra i sistemi comunicanti prima di iniziare l’effettivotrasferimento dei dati.

In una rete con connessione è necessario mantenere informazioni di statoall’interno dei commutatori. Tali informazioni sono quelle che specificanocome trattare una unità di dati appartenente ad una data connessione. Ogni unitàdi dati contiene un apposito campo (ad es., la coppia Virtual Circuit Identifier,Virtual Path Identifier, VCI/VPI, in ATM). Quando un nodo riceve una unità didati, esso usa questo campo come puntatore ad una tabella in cui sono contenutele informazioni che specificano come trattare tale unità di dati. Un esempio ditale tabella è quella di corrispondenza tra etichette (o VCI) entranti ed uscentida un nodo, in base alla quale avviene la commutazione di etichetta.Tipicamente le informazioni di stato vengono comunicate e memorizzatedurante la fase di instaurazione per essere poi eliminate durante la fase di

135

abbattimento. In un nodo sono quindi necessari tanti stati quante sono leconnessioni attive.

Ciò è però vero anche in una rete senza connessione, qualora si definiscaun’associazione logica tra più datagrammi, al fine di implementare efficientifunzioni di commutazione e di offrire garanzie di qualità di servizio.

In una rete con connessione le informazioni di stato sono mantenute su unabase da estremo a estremo, cioè riguardano l’intero percorso della connessione,e sono di tipo “hard”, cioè una volta stabilite rimangono inalterate fino a chenon siano esplicitamente cancellate.

Una rete è però molto più semplice e robusta se lo stato è mantenuto sololocalmente piuttosto che su base da estremo a estremo e se lo stato è “soft”invece che “hard”. Uno stato “soft” è uno stato mantenuto per migliorare leprestazioni di rete ma non è cruciale per il funzionamento della stessa; ha unlimitato “tempo di vita” e, in mancanza di aggiornamenti periodici, perde divalidità. In tal modo molte condizioni di errore sono corrette semplicementelasciando “scadere” lo stato.

Un flusso è definito come una sequenza di datagrammi emessi da unaparticolare sorgente e diretti verso una particolare destinazione, nonchéaccomunati dalla strada seguita e da eventuali politiche di gestione locali; unflusso realizza cioè l’associazione logica tra più datagrammi di cui si è parlatoprima. In una rete senza connessione svolge parte dei ruoli di una connessionein una rete con connessione e consente, almeno in linea di principio, diaffrontare le problematiche appena discusse. Le informazioni di stato relative aiflussi sono mantenute mediante stati “soft”. Il concetto di flusso èesplicitamente previsto in IPv6 (cfr. IV.4).

L’introduzione dei flussi ha quindi come obiettivi:- poter garantire la qualità di servizio;- ottenere la massima efficienza nell’implementazione di IP usando sistemi di

commutazione molto veloci;- mantenere alcune caratteristiche positive del paradigma senza connessione;

Quest’ultimo vantaggio è ottenibile in quanto, come si chiarirà nel seguito,in una rete operante secondo il concetto dei flussi è ancora possibile trattare idatagrammi in modo isolato, cioè eseguire la funzione decisionale datagrammaper datagramma e quindi anche soddisfare le esigenze di applicazioni chepreferiscono un trattamento senza connessione. Inoltre la tipologia soft deglistati è più in armonia con la filosofia originale di Internet in quanto rende menocritica la collaborazione tra sistemi diversi.

Una rete senza connessione che supporti i flussi realizza un compromessotra le modalità di trasferimento con e senza connessione. Le principali soluzioni

136

proposte per supportare il concetto di flusso in un router IP possono essereclassificate in due categorie.

Nella prima categoria (ad es., la soluzione IP Switching) i router ricavanol’associazione tra datagrammi e flussi dall’esame del traffico in transito (o,nell’ipotesi di usare IPv6, da un apposito campo dell’intestazione deldatagramma).

Lo scopo di IP Switching è quello di realizzare una efficienteimplementazione di IP usando una matrice di commutazione ATM. Si usahardware ATM standard, privato però del software di controllo originale, al finedi consentirgli di operare in modalità senza connessione. I datagrammi IPvengono incapsulati in unità di dati ATM (previo incapsulamento AAL). Alposto del software ATM completo si inserisce il software di IP (con tutti glialtri relativi protocolli, e.g. protocolli di instradamento, di risoluzione degliindirizzi etc.) e due protocolli ad hoc; il primo è usato per consentire al modulodi controllo di inter-affacciarsi all’hardware ATM; il secondo serve adaggiungere ad IP le funzionalità necessarie per gestire i flussi.

Il risultato è un router IP con la capacità di trasferire direttamente ledecisioni relative all’instradamento all’hardware responsabile dellacommutazione (ATM). Il nome deriva dal fatto che, previa un’associazione traspecifici datagrammi e un flusso, questa soluzione consente di commutare idatagrammi appartenenti ad un flusso “bypassando” la parte router del sistemauna volta che quest’ultima ha trasferito le informazioni di instradamento alcommutatore ATM.

Nel suo funzionamento base, ogni router tratta i datagrammi secondo lemodalità standard di IP, ma esamina anche i datagrammi in transito al fine dicapire se questi appartengano ad un flusso o meno. Quest’ultima operazione èbanale nell’ipotesi di usare IPv6, in quanto l’appartenenza di un datagramma adun flusso è esplicitamente indicata. In IPv4 il riconoscimento del flusso è unapolitica locale basata sull’esame di altre informazioni contenutenell’intestazione (e.g., indirizzi e porte di sorgente e destinazione, tipo diservizio e protocollo di strato superiore usato).

Una volta che un flusso è stato riconosciuto come tale, i protocolli di IPswitching associano ogni flusso ad un dato VCI (Virtual Circuit Identifier)ATM e costituiscono la tabella di corrispondenza tra VCI entranti ed uscenti daun nodo, in base alla quale avviane la commutazione di etichetta ATM. In talmodo la funzione di commutazione viene “passata” ad ATM, con i conseguentimiglioramenti prestazionali.

137

Queste soluzioni possono trattare quindi contemporaneamente datagrammiin modalità standard ed in modalità flusso, fornendo così una significativaflessibilità ed elevate prestazioni. Questo è un vantaggio rispetto alla soluzioneclassica di trasportare IP su ATM completo, in quanto non richiede di stabilireconnessioni ATM anche per il traffico che “preferisce” un trasferimento senzaconnessione. Ciò implica una significativa riduzione del traffico di segnalazionee delle risorse di elaborazione.

Il principale svantaggio attuale è legato all’operazione di riconoscimentodei flussi. Le prestazioni dell’IP switch dipendono in modo sostanziale daquesta operazione: se, ad esempi, non si riconosce nessun flusso le prestazionisono identiche a quelle di un router tradizionale. La classificazione deidatagrammi in flussi è legata alle tipologie del traffico in Internet le quali sonoalquanto variabili. Inoltre questa soluzione si basa su protocolli proprietari, nonuniversalmente accettati.

Nella seconda categoria di cui sopra, le soluzioni proposte per supportare ilconcetto di flusso in un router IP sono principalmente “orientate alla topologia”.

Tali soluzioni (denominate di tipo Tag Switching) equivalgono adintrodurre un nuovo strato protocollare immediatamente al di sotto di IP. Idatagrammi IP vengono incapsulati nell’unità di dati di questo strato. Lafunzione basilare di questo incapsulamento è quella di etichettare ognidatagramma IP con un specifico campo (denominato tag, o label).L’instradamento del datagramma sarà quindi effettuato non sulla basedell’intestazione del datagramma IP, ma sulla base del campo tag (o label).

Assumendo che tutti i datagrammi siano opportunamente etichettati, lacommutazione può avvenire direttamente in hardware secondo la tecnica della“commutazione di etichetta” (o label switching o tag switching). I nodiattraversati non esaminano quindi l’intestazione del datagramma IP per fini diinstradamento.

Un insieme di nodi operanti secondo una soluzione di tipo Tag Switchingcostituisce un dominio Tag Switching. All’interno di tale dominio, vengonostabiliti dei percorsi, denominati “tunnel” (gallerie). Ogni tunnel è associato aduna data etichetta. Tutti i datagrammi etichettati con una data etichettapercorreranno lo stesso tunnel godendo di significative prestazioni in termini diportata. Si noti che i nodi attraversati secondo questa tecnica sono trasparenti adIP. Dal punto di vista di quest’ultimo, un datagramma viene esaminato soloprima di entrare in un tunnel e dopo la sua fuoriuscita dal tunnel stesso, ovverosolo alle frontiere del dominio Tag Switching. L’unica eccezione a questo mododi procedere riguarda il campo Time to Live di IP che deve essere

138

opportunamente aggiornato. Quando un datagramma attraversa un dominio TagSwitching deve emergerne con lo stesso valore del TTI che avrebbe avuto inseguito all’attraversamento della stessa sequenza di nodi mediante un inoltro ditipo IP classico.

E’ ovvio che il punto critico di questo modo di procedere risiede nellafunzione di etichettatura dei datagrammi e in quella di costituzione della tabelladi corrispondenza tra etichette entranti ed uscenti da un nodo, in base alla qualeavviane la commutazione di etichetta. Questa tabella, denominata TagInformation Base (TIB), non è concettualmente diversa dalle tabelle diinstradamento usate in IP; la differenza risiede nelle dimensioni dei campi checontiene, nella sua dimensione complessiva e nel modo in cui è stabilita emantenuta.

Si noti che tutta questa soluzione può essere anche vista semplicementecome un trasporto di IP mediante un protocollo orientato alla connessione,come ATM. In altri termini, nelle sue modalità generali sin qui descritte, il TagSwitching non è molto diverso da ATM: è sufficiente sostituire il Tag con lacoppia VCI/VPI.

In altre parole le etichette o tag svolgono la stessa funzione della coppiaVCI/VPI in ATM o del campo DLCI in Frame Relay. L’insieme di etichetteassegnate ad un datagramma crea un percorso da estremo a estremo che è similead una connessione.

Ciononostante Tag Switching può essere alquanto più semplice dell’ATMcompleto. I fattori di semplificazione riguardano il modo in cui la tabella TIB èstabilita e mantenuta. Nell’ipotesi più semplice la TIB è precostituita e legataalla topologia della rete, invece che stabilita su base chiamata. In altri termini,mentre in ATM completo le etichette vengono create ed assegnate in seguito arichieste degli utenti e mediante operazioni di segnalazione, in Tag Switching itunnel possono essere stabiliti in modo aprioristico rispetto al traffico che viinsisterà ed in modo legato solo alla topologia di rete. Ancora in altri termini,per chi conosce l’ATM, si può dire che in tal caso i tunnel svolgono unafunzione molto simile ai Virtual Paths di ATM.

Una simile soluzione è, in linea di massima, più indicata nella sezioneinterna di rete. Infine notiamo che non sono state fatte esplicite ipotesi sulprotocollo di rete adoperato. Quest’ultimo può essere quindi diverso da IP, cosìcome le specifiche sotto-reti sopra le quali si pone Tag Switching possonoessere di qualsiasi tipo. Ciò non toglie che Tag Switching è pensato conparticolare riguardo ad IP mentre per le funzioni di strato inferiore si pensa adATM (non completo).

139

Una soluzione di tipo Tag Switching proposta da Cisco è stata fatta propriada un gruppo di lavoro dell’IETF e si è evoluta utilizzando anche elementi dialtre soluzioni (tra cui ARIS di IBM e IP Switching) nella soluzionedenominata Multi-Protocol Label Switching (MPLS), attualmente oggetto distandardizzazione. Nel seguito descriveremo in maggiore dettaglio MPLS.

IV.2.3� Multi-Protocol Label Switching (MPLS)

Ogni pacchetto MPLS contiene un'intestazione costituita da:- Label (20 bit): è l'etichetta di instradamento;- Class of Service, COS (3 bit): specifica le modalità con cui trattare il

pacchetto;- Time to Live, TTL (8 bit): analogo al campo TTL di IP;- Indicatore dello stack di etichetta (1 bit)

L'intestazione di MPLS è incapsulata tra quella di strato 2 e quella di strato3. Lo strato 3 può essere IP, ma anche un altro protocollo (da qui il nome). Nelseguito faremo riferimento ad IP, assumendo quindi che i datagrammi IP sianoincapsulati nei pacchetti MPLS.

Scopo di MPLS è quello di commutare un pacchetto e di eseguire il “labelswapping” (ovvero cambiare l’etichetta), senza dover ri-esaminare ad ognirouter l'intestazione dei datagrammi IP contenuti nei pacchetti MPLS. Uninsieme di entità di rete operanti secondo MPLS costituisce un dominio MPLS.Un dominio MPLS è caratterizzato da due componenti funzionali: l’Inoltro ed ilControllo.La componente di Inoltro (o fase attuativa)

L’inoltro dei pacchetti avviene tramite “label swapping” ovvero modificadell’etichetta. MPLS utilizza il campo etichetta come un puntatore ad unaapposita tabella, Label Information Base (LIB). Ogni riga della tabella LIB sicompone di una etichetta di ingresso, di una etichetta di uscita, dell’interfacciadi uscita e di informazioni sul livello di collegamento in uscita. Se un nodoMPLS trova un ingresso alla propria tabella pari all'etichetta di un pacchettoentrante, allora modifica l' etichetta e l’informazione di livello di collegamentoe inoltra tale pacchetto sull’interfaccia di uscita appropriata.

La decisione di inoltro è indipendente dal tipo di comunicazione. L’unicadifferenza tra il caso “unicast” ed il caso “multicast” è che in questo secondocaso si possono avere più insiemi di dati (etichette di uscita, interfaccia di uscitaed informazione del livello di collegamento). La componente di inoltro èsostanzialmente disaccoppiata dalla componente di controllo, per cui è possibilesviluppare nuovi sistemi di instradamento senza modificare il sistema di inoltro.La componente di inoltro è indipendente dai protocolli di strato di rete.

140

La componente di ControlloLa componente di controllo è responsabile della creazione delle

associazioni tra etichette e strade da percorrere e della distribuzione di questeassociazioni tra i vari nodi del dominio MPLS.

Gli elementi distintivi di un dominio MPLS sono: apparati interni aldominio, apparati posti alla frontiera del dominio, protocolli che implementanola componente di controllo. Descriveremo ora tali elementi (cfr. Fig. 22).

a) Label Edge Router, LER: sono apparati che svolgono completamente lefunzioni di instradamento di livello 3 (e.g. IP) e che sono disposti sullafrontiera del dominio MPLS. All'ingresso del dominio MPLS, incapsulanoi datagrammi IP in pacchetti MPLS, generando la relativa intestazione.All'uscita del dominio MPLS estraggono i datagrammi IP dai pacchettiMPLS rimuovendo i relativi campi. Poiché possiedono tutte le funzioni diinstradamento IP, essi forniscono servizi di strato di rete, includendo anchefunzioni di sicurezza, di addebito e di classificazione della qualità diservizio. Un LER non ha la necessità di avere un hardware dedicato confunzioni di Label Switching ma è sufficiente che vi sia installato unapposito software.

b) Label Switched Router, LSR: possiedono le funzionalità di LabelSwitching; svolgono la commutazione dei pacchetti in funzione del campoetichetta. Assumendo che tutti i pacchetti siano opportunamente etichettati,la commutazione può avvenire direttamente in hardware secondo la tecnicadella “commutazione di etichetta” (o label switching). Tale modalità èmolto più veloce del processo di analisi della tabella di instradamento incerca del "longest matching", tipico di IP.

c) Label Distribution Protocol, LDP:MPLS necessita di un protocollo (Label Distribution Protocol, LDP) perdistribuire le etichette, ovvero per attribuire opportuni valori al campoetichetta e per costruire le tabelle di corrispondenza tra etichette entranti eduscenti da un nodo, in base alla quale avviene la commutazione di etichettae si crea un cammino (Label-Switched Path, LSP).Non è ancora chiaro quale protocollo di userà a tal fine, se un protocollo adhoc, RSVP, o opportune estensioni dei protocolli di instradamento IP.Un LSP è simile ad un circuito virtuale ATM. I router MPLS possononegoziare la semantica di ogni etichetta, ovvero le modalità con sui trattarela relativa unità informativa. Per permettere una maggiore scalabilità della

141

soluzione e per consentire una varietà di funzionalità di instradamento, unLSP può essere instaurato in seguito a quattro diversi tipi di richieste:1) Richiesta di carattere gestionale, corrispondente ad un LSP semi-

permanente;2) Richiesta azionata da una procedura di controllo (ad es. aggiornamento

di tabelle di instradamento);3) Richiesta azionata da un aggregato di flussi (dove un aggregato di

flussi è definito come un insieme di flussi aventi gli stessi requisitiprestazionali e che devono percorrere la stessa strada);

4) Richiesta azionata da un singolo flusso di utente.In altre parole, un'etichetta può essere associata: i) ad un percorso semi-permanente ii) ad un percorso determinato dai protocolli di instradamentoIP (o più specificatamente all’informazione di raggiungibilità di strato IP);iii) ad un aggregato di flussi; iv) ad un singolo flusso.E' ovvio che queste quattro alternative sono in ordine crescente dicomplessità. Nel primo caso e nel secondo caso ci troviamo di fronte aduna soluzione orientata alla tipologia (potremmo parlare di una soluzionepermutata nel primo caso e di una permutata "dinamica" nel secondo). Ilterzo caso è simile ad un VP ATM, ovvero si aggregano più flussisemplificando così sia lo scambio di segnalazione che il trattamento deisingoli pacchetti. Il quarto caso corrisponde ad un circuito virtualeinstaurato in seguito a richieste dell'utenza ed è del tutto paragonabileall'ATM in quanto a complessità.Ad ogni modo, in seguito alla distribuzione delle etichette, vengono createle tabelle di corrispondenza LIB tra etichette entranti ed uscenti da un nodo(cfr.Fig. 23).All'interno di un dominio MPLS i livelli di qualità di servizio sonodeterminati dai valori delle etichette e del campo COS. All'uscita di undominio MPLS la relativa intestazione è rimossa ed il datagramma vieneconsegnato al prossimo router secondo la modalità tradizionale. Questaoperazione è compiuta da un apposito LER.

142

Fig. 22 - Esempio di dominio MPLS, di LSR, LSP e LER

Router MPLS a MPLS b MPLS c

Datagramma datagramma+etich. La

Dominio MPLS

Et ichet t a en tra nte pross im o n odo Nu o v a et ichettaLa Rc LbLe Rf Lf

datagramma+etich. Lb Datagramma

Router

Fig. 23 - Esempio di dominio MPLS e della LIB del router MPLS b.

I vantaggi di MPLS risiedono in:� una veloce e semplice modalità per la classificazione e l'inoltro dei

pacchetti;� a differenza di IP, l'instradamento deciso mediante l'attribuzione di una data

etichetta, può essere basato non solo sull'indirizzo di destinazione, ma anchesu altri fattori (e.g., prestazioni, politiche di gestione, etc. )

� un efficiente meccanismo di tunneling.La ultime due caratteristiche risultano molto utili, specialmente per

ingegnerizzare opportunamente una "core network".

143

Infatti MPLS non è importante solo per le alte prestazioni in termini diportata (ricordiamo che i Gigabit routers sono già una risposta, seppur parziale,a questa problematica). Altrettanto, se non più importanti sono:1) il supporto all'ingegnerizzazione di rete2) la possibilità di realizzare Virtual Private Networks (VPN)3) la flessibilità e la facilità di evoluzione4) una più semplice integrazione con ATM.

Un'ultima osservazione è in merito al paragone tra ATM completo eMPLS; poiché queste due soluzioni sembrano molto simili, ci si può chiedereperché la comunità Internet vede con più favore MPLS. La risposta, data peròsoprattutto dai costruttori di routers, è che ATM completo presenta i seguentisvantaggi rispetto a MPLS:

- maggiore overhead dovuto all'intestazione- necessità di usare contemporaneamente routers IP e commutatori ATM con

conseguente duplicazione di gestioneTutto ciò è particolarmente vero se l'instaurazione dei Label-Switched

Path, LSP avviene secondo le prime tre modalità presentate sopra, ovvero se èazionata da una procedura di gestione, di controllo o da un aggregato di flussi.In tal caso la core network tratta un numero di LSP sicuramente molto minoredi quello relativo ad LSP associati a singoli flussi. Va da se, infine, che lasoluzione MPLS è particolarmente indicata nella sezione interna di retepiuttosto che in quella di accesso. Tutto quanto è contenuto in un datagrammaIP è completamente trasparente a un router MPLS, LSR, che quindi non "vede"eventuali funzioni implementate nei campi dei datagrammi IP

IV.3� Soluzioni per migliorare la Qualità di Servizio

Internet ha tradizionalmente fornito un solo tipo di servizio, quello delcosiddetto “best-effort” in cui tutti i datagrammi sono trattati allo stesso modo.L’attuale Internet è costituita da una moltitudine di sotto-reti, basate sutecnologie e architetture molto diverse tra loro, interconnesse per mezzo delprotocollo IP. Come è noto, quest’ultimo non fa alcuna ipotesi sui servizi fornitidagli strati ad esso inferiori, se non una semplice e generica capacità ditrasferire delle unità di dati senza alcun porre alcun vincolo sulla qualità diservizio disponibile. IP fornisce dunque un servizio privo di connessione, nonaffidabile e soggetto a perdita, duplicazione e consegna fuori sequenza delleunità informative; queste ultime possono inoltre subire un ritardo alquantovariabile e non pre-definito. In altri termini IP cerca di fare del suo meglio pertrasferire l’informazione di utente ma non può fornire alcuna garanzia

144

prestazionale. Un generico utente che attua uno scambio informativo attraversoInternet può sperimentare prestazioni estremamente diverse in funzione sia delparticolare corrispondente scelto sia del tempo.

I principali parametri prestazionali cui gli utenti sono interessati sono:- il ritardo;- la sua variazione;- la portata;- il tasso di perdita delle unità informative.

In Internet, il compito di rendere la qualità di servizio adeguata alleesigenze degli utenti è delegata a protocolli di strato di trasporto residenti neisistemi terminali (tipicamente TCP). E’ però opportuno mettere in evidenza che,se un protocollo di strato di trasporto può sopperire ai fenomeni di perdita diinformazione, mediante il meccanismo della ri-trasmissione di unitàinformative colpite da errori, non ha margini di manovra significativi perquanto riguarda il ritardo e la portata. Inoltre il meccanismo della ri-trasmissione non è compatibile con le esigenze dei servizi con requisiti ditempo reale.

Si vede dunque come non è in generale pensabile di porre rimedio adeventuali deficienze del servizio di strato di rete solo con meccanismi cheoperano nei sistemi terminali. E’ quindi necessario intervenire all’interno dellarete. Nel seguito si esamineranno tre importanti metodologie sinora proposteper fornire servizi di qualità accettabile, non mutuamente escludentisi. Sidescriveranno prima gli approcci denominati IntServ (cfr. IV.3.2) e DiffServ(cfr. IV.3.3) e quindi tecniche di instradamento adattative, aventi lo scopo dimigliorare la QdS (QoS routing, cfr. IV.3.4). Infine si presenteranno alcuneconclusioni (cfr. IV.3.5).

Prima però di affrontare in dettaglio questa problematica è utile introdurrealcuni concetti generali (IV.3.1).

IV.3.1� Introduzione alla Qualità di Servizio (QdS)

Con riferimento al concetto di QdS, una prima distinzione chiave è quellatra prestazioni garantite e non. Nel primo caso, l'operatore fornisce un serviziogarantendo determinati livelli prestazionali. Nel secondo caso, l'operatore cercadi fare del suo meglio, ma non è affatto escluso che gli utenti possano portare acompimento uno scambio di informazioni con le prestazioni volute. Unaseconda distinzione è quella tra garanzie deterministiche e garanzieprobabilistiche. Nel primo caso il raggiungimento di un determinato livelloprestazionale è sempre assicurato; nel secondo caso, si afferma solo che undeterminato livello prestazionale viene fornito con una certa probabilità, nota a

145

priori e nell’ambito di uno specifico modello aleatorio del fenomenoconsiderato.

Infine, la QdS percepita da un generico utente può essere classificata indue diverse categorie: QdS a livello di chiamata (QdS-chiamata) e QdS durantela fase di trasferimento dell'informazione (QdS-trasferimento).

La prima può essere definita solo in reti in cui il generico utente, prima dipoter trasferire informazioni, deve instaurare una connessione e quindi,implicitamente o esplicitamente, chiedere un'autorizzazione. In altri terminiprima di iniziare il trasferimento dei dati si è sottoposti ad un controllo diaccesso. Si noti che la connessione di cui sopra non è necessariamente riferitaallo strato di rete, ma potrebbe anche essere relativa allo strato di trasporto o aquello di applicazione; ciò significa che questa modalità si applica sia a reti conconnessione sia a reti senza connessione, ma in cui comunque è prevista unaforma di controllo di accesso che si esplica con riferimento a quella chepotremmo definire genericamente come "chiamata".

In presenza di un tale controllo di accesso, si ha interesse a valutare conquale probabilità una richiesta di chiamata sia accettata o meno. La QdS-chiamata misura quindi tale aspetto. Un predeterminato livello di QdS-chiamatapuò essere fornito da un operatore solo su base probabilistica, dal momento chenon è possibile prevedere in generale quanti utenti esprimeranno una richiestadi servizio. Inoltre un operatore può fornire garanzie di QdS-chiamata solodimensionando opportunamente la rete e limitando il numero dei suoi abbonati.Si tratta perciò di operazioni che si esplicano con una scala temporaleabbastanza grande.

Il caso in cui non vi sia un controllo di accesso (come in Internet) puòessere visto come un caso limite in cui la QdS-chiamata è sempre garantita, nelsenso che la rete non oppone mai un rifiuto ad una richiesta di servizio.

La QdS-trasferimento fa invece riferimento alle prestazioni percepite dagliutenti durante la fase di trasferimento, tipicamente espressa in termini deiseguenti parametri prestazionali: ritardo, variazione del ritardo, tasso di perditadelle unità informative, portata. La QdS-trasferimento può essere caratterizzatada prestazioni garantite solo in presenza di un controllo di accesso.

La modalità di allocazione delle risorse determina le caratteristicheprestazionali di una infrastruttura di telecomunicazione. Prendiamo ora inesame le tre alternative possibili per l'allocazione delle risorse e ne deduciamole implicazioni sulla QdS-chiamata e sulla QdS-trasferimento.

146

Pre-assegnazione individualeQuesta modalità si applica a reti con connessione a commutazione di

circuito. Durante la fase di instaurazione l'utente chiede l'assegnazione di unadeterminata quantità di risorse. L'operatore, qualora verifichi la disponibilità ditali risorse, le assegna individualmente a chi ne ha fatto richiesta; ciò significache tali risorse possono essere usate esclusivamente dall'utente a cui sono stateassegnate. Esiste dunque un controllo di accesso. Le relative implicazioni sono:

Per la QdS-chiamata si possono fornire garanzie dimensionandoopportunamente la rete e limitando il numero dei suoi abbonati. Per la QdS-trasferimento si possono fornire garanzie deterministiche. Il principalesvantaggio di questa strategia è la possibile inefficienza nell'uso delle risorse.La Fig. 24 mostra un esempio di pre-assegnazione individuale: tre richieste dichiamata sono presentate alla rete, ognuna delle quali "contiene" tre unitàinformative, numerate da 1 a 3. Una di queste chiamate (la B) è rifiutata ma laQdS-trasferimento di quelle accettate è garantita. Le unità informative dellechiamate A e C arrivano a destinazione senza subire perdite ed in modotemporalmente trasparente.

�

��

� � �

� � �

��

� � �

� � �

��

Fig. 24 - Pre-assegnazione individuale

Assegnazione a domandaQuesta modalità si applica a reti senza connessione a commutazione di

pacchetto (e.g. l'attuale Internet). Non esiste una fase di instaurazione e l'utentepuò emettere informazioni in qualsiasi momento senza chiedere un assensopreventivo all'operatore. Le risorse di rete non sono assegnate ma condivise tratutti gli utenti presenti, non essendo previsto un controllo di accesso. Le relativeimplicazioni sono:

Per la QdS-chiamata ci troviamo nel caso limite in cui la QdS-chiamata èsempre garantita, nel senso che la rete non oppone mai un rifiuto ad unarichiesta di servizio.

147

Nessuna garanzia né deterministica né probabilistica può essere offerta perla QdS-trasferimento. Il principale vantaggio di questa strategia è la possibileefficienza nell'uso delle risorse e la semplicità, come ampiamente discussonell'introduzione alla Internet attuale. La Fig. 25 mostra un esempio diassegnazione a domanda: tre richieste di chiamata (immaginate a strato ditrasporto o di applicazione, ma non di rete) sono presentate alla rete, ognunadelle quali "contiene" tre unità informative, numerate da 1 a 3. Nessuna diqueste è rifiutata ma la QdS-trasferimento non è garantita. Nell'esempio, leunità informative delle chiamate A e C subiscono perdite ed il trasferimentonon è temporalmente trasparente.

��

��

� � �

��

� � �

� �

��

��

��

Fig. 25 - Assegnazione a domanda

Pre-assegnazione collettivaQuesta modalità si applica a reti con connessione a commutazione di

pacchetto (e.g. ATM). Durante la fase di instaurazione l'utente chiedel'assegnazione di una determinata quantità di risorse. L'operatore, qualoraverifichi la disponibilità di tali risorse, le assegna in modo virtuale a chi ne hafatto richiesta; ciò significa che le risorse di rete sono assegnate in modocollettivo agli utenti abilitati. Esiste dunque un controllo di accesso. Le relativeimplicazioni sono:

Per la QdS-chiamata si possono fornire garanzie dimensionandoopportunamente la rete e limitando il numero dei suoi abbonati. L'operatoreaccetta richieste di chiamata solo finché reputa di poter garantire determinatilivelli prestazionali. La fase di accettazione è basata su di un'opportunaconoscenza (probabilistica) del traffico che sarà emesso dall'utenza. Per la QdS-trasferimento si possono quindi fornire garanzie probabilistiche. Il principalevantaggio di questa strategia è la possibile efficienza nell'uso delle risorse conlo svantaggio di una complessità maggiore della alternativa precedente. La Fig.

148

26 mostra un esempio di pre-assegnazione collettiva: tre richieste di chiamatasono presentate alla rete, ognuna delle quali "contiene" tre unità informative,numerate da 1 a 3. Una di queste chiamate (la B) è rifiutata ma la QdS-trasferimento di quelle accettate è garantita, seppure su base probabilistica. Leunità informative delle chiamate A e C arrivano a destinazione subendo perditee ritardi di trasferimento variabili, ma in modo controllato e caratterizzati dauna nota distribuzione di probabilità.

��

��

� � �

��

� � �

��

� � �

Fig. 26 - Pre-assegnazione collettiva

Dalla discussione precedente dovrebbe essere chiaro che l'attuale Internet,siccome utilizza una assegnazione a domanda, non può fornire nessuna garanziaa livello di QdS-trasferimento. Infatti è una rete senza connessione e non attuaun controllo di accesso.

E' allora evidente che per fornire tali garanzie occorre modificare questedue caratteristiche.

Prima di entrare nel dettaglio di questa problematica discutiamo dueaspetti che potrebbero migliorare le prestazioni percepite dagli utenti, ma chenon appaiono soddisfacenti, nel quadro di una Internet che abbia pretese difornire livelli prestazionali simili a quelli di altri paradigmi di rete pubblica,come ATM. Ciò al fine di "sgombrare il campo" e poterci quindi concentraresul problema in esame.

Un primo aspetto è quello legato a strategie di controllo del trafficoreattive. Una strategia di controllo del traffico può essere reattiva o preventiva.Nel primo caso, non si esercita un controllo di accesso, ed in presenza disituazioni di congestione, la rete reagisce, limitando o azzerando l'emissione diemissione di informazione da parte degli utenti. E' evidente che una similestrategia non può essere usata in presenza di requisiti di tempo reale (ad es., unaconversazione telefonica o video-telefonica interattiva); ciò è vero a meno che,

149

e solo entro certo limiti, le sorgenti di traffico abbiano delle caratteristiche diadattatività; ovvero la codifica di sorgente usata consenta di limitare il ritmobinario di emissione, seppure a scapito della qualità.

Invece una strategia di controllo del traffico preventiva evita a priorisituazioni di congestioni, mettendo a disposizione degli utenti un serviziocaratterizzato da opportuni valori di una o più metriche appositamente pre-definite. Questa strategia è tipicamente attuata mediante una metodologia basatasu tre fasi:

- la richiesta, da parte di un utente, di un dato servizio, corredata di unapreventiva dichiarazione circa il tipo di traffico che andrà ad emettere e circale prestazioni che richiede alla rete (Dichiarazione dei Parametri di Utente);

- una verifica, da parte della rete, della disponibilità di risorse per far frontealle richieste dell’utente senza mettere a repentaglio le prestazioni di servizigià promessi ad eventuali altri utenti (Controllo di Ammissione di Chiamata);

- un controllo da parte della rete, in caso di accettazione della richiestadell’utente, mirante ad accertare che quest’ultimo emetta traffico in accordo aquanto dichiarato nella prima fase (Policing).

Un secondo aspetto riguarda la possibilità di fornire determinati livelli diQdS-trasferimento senza attuare un controllo di accesso e con una modalitàsenza connessione. Si potrebbe argomentare che un opportunodimensionamento (o sovra-dimensionamento) delle risorse di rete possa fornirelivelli prestazionali accettabili, anche se non garantiti. Ciò in linea di principio èvero: in alcuni casi è sufficiente ingegnerizzare opportunamente la rete. Si pensia una LAN Ethernet: essendo una rate privata, si sa a priori quanti utenti nepossono usufruire e quindi un opportuno dimensionamento può portare a unaQdS-trasferimento pienamente accettabile (si noti però che questa è sempre unaforma di controllo di accesso). Purtroppo nel caso di Internet la fornitura di unaaccettabile QdS-trasferimento mediante semplice dimensionamento è didifficile attuazione, per i seguenti fattori:

- l’estrema variabilità delle sotto-reti interconnesse da Internet, caratterizzateda prestazioni che, per quanto riguarda ad esempio la portata, possonovariare in un campo di diversi ordini di grandezza;

- la variabilità del traffico offerto, che comprende diverse tipologie di servizio;- la mera vastità ed eterogeneità di Internet, la sua natura de-centralizzata e la

mancanza del controllo di una singola autorità amministrativa. Ad esempio,molti Service Providers attuano politiche di "over-subscription", ovveroaccettano richieste di abbonamenti in numero molto superiore alle risorsedisponibili; in molti casi si accetta un numero di utenti tale da portare i tassi

150

di perdita di datagrammi al 20% o in alcuni casi al 70%.Ciò conduce a “istanze localizzate di ingegnerizzazione di rete sub-

standard, incapaci di trasportare il traffico offerto” [FER98]. Ovvero, alcunearee di Internet, in alcuni periodi, esibiscono alti livelli di congestione eprestazioni inadeguate, mentre in altre aree la situazione è pienamentesoddisfacente; l'utente è pero interessato alla qualità di un servizio su base daestremo a estremo e quindi se solo una delle sezioni attraversate offre unservizio inadeguato è l'intero percorso da estremo a estremo a soffrirne.

La conclusione è quindi che appare consigliabile introdurre forme dicontrollo di accesso e modificare il paradigma senza connessione di Internet. Sinoti però che un corretto dimensionamento di rete è comunque essenziale,anche in presenza di sofisticati sistemi per il controllo del traffico. Infatti, unarete non dimensionata in modo opportuno, mal si presta all’implementazione dischemi per garantire una pre-determinata QdS-trasferimento. In un ambienteeterogeneo in cui co-esistono diversi livelli di QdS-trasferimento richiesti,inclusi utenti che non ne richiedono alcuno, gli schemi che garantiscono laQdS-trasferimento difendono un sotto-insieme di utenti, ma a scapito di altri.D’altra parte è difficile prevedere che tutte le tipologie di utenti siano disposti apagare le maggiori tariffe necessariamente implicate da servizi a qualitàgarantita. In ogni caso è evidente che, anche in presenza solo di utenti disposti asottoscrivere servizi ad alta qualità, una non buona ingegnerizzazione portacomunque a spreco di risorse in quanto la rete sarà costretta a rifiutare in molteoccasioni delle richieste di servizio, poiché non ne può garantire le prestazioni.

Le tradizionali tecniche di dimensionamento, di ingegnerizzazione e diprincipi architetturali di rete devono quindi continuare a giocare un ruolofondamentale anche in uno scenario di servizi a qualità garantita. Ciò puòapparire ovvio ma si tratta di un aspetto spesso sotto-valutato.

Si esaminerà ora la prima delle metodologie elencate sopra: l'approccioIntServ.

IV.3.2� Approccio Integrated Services (IntServ)

In risposta alle esigenze precedentemente espresse, la IETF ha istituito ilWorking Group “Integrated Services” con lo scopo di definire un’architettura diriferimento, ottenuta mediante integrazioni della classica architettura diInternet, per supportare diverse classi di servizio in aggiunta alla tradizionale“best-effort”, garantendone alcune caratteristiche prestazionali. Ricordiamo chea tal fine è necessario introdurre una forma di controllo di accesso e modificareil paradigma senza connessione. Circa quest'ultimo punto, non si introduce una

151

connessione vera e propria, ma si ricorre al concetto di flusso (cfr. il capitolo“Soluzioni per migliorare le prestazioni di TCP/IP”, IV.2). Nel seguito talearchitettura sarà denominata Integrated Services, (IntServ). Le classi di serviziodi IntServ, se supportate dai routers attraversati da un “flusso di datagrammi”garantiscono al flusso stesso pre-determinate prestazioni [WHI97]. Il trafficonon appartenente ad una classe di servizio IntServ sarà trattato ancora inmodalità best-effort e potrà usare le risorse eventualmente lasciate libere daiflussi a qualità di servizio garantita. I livelli prestazionali forniti ad una dataclasse di servizio sono richiedibili su base flusso; ovvero una data applicazioneterminale richiede alla rete determinate prestazioni e il relativo flussoinformativo sarà trattato dalla rete in modo da soddisfare le richiestedell’applicazione. Le richieste delle applicazioni sono comunicate ai routers permezzo di procedure gestionali o per mezzo di opportuni protocolli (tipicamenteRSVP, cfr. il seguito del capitolo).

Tali richieste determinano l’ammontare delle risorse (e.g., banda e buffer)che devono essere riservate al flusso in questione lungo il suo cammino daorigine e destinazione. Nel determinare l’allocazione delle risorse necessaria asoddisfare una determinata richiesta, ogni router deve tener in conto leprestazioni ed i livelli di qualità di servizio forniti dalla particolare sotto-rete acui è collegato (ovvero le caratteristiche dello strato di collegamento che stausando). Nel caso in cui la sotto-rete in esame è, a sua volta, capace di garantireuna data qualità di servizio (e.g. ATM), il router è responsabile di “negoziare”con tale sotto-rete la fornitura di un collegamento adeguato e tale da soddisfarela richiesta che il router stesso ha ricevuto. I protocolli del router, come in ogniarchitettura a strati, faranno poi uso dei servizi offerti dallo strato inferiore(ovvero di tale collegamento) per fornirli, arricchiti delle proprie funzionalità,agli strati superiori.

Questo meccanismo di “mapping” tra la qualità di servizio offerta dallostrato di collegamento e le richieste che pervengono al router dipendeovviamente dalla particolare sotto-rete a cui il router è collegato. Un appositoWorking Group dell’IETF si occupa di tale questione (Integrated Services overSpecific Lower (or Link) Layers).

Ogni router deve poi esercitare un controllo di ammissione per assicurareche le richieste siano accettate solo se esistono risorse sufficienti a garantire leprestazioni volute. Nel fare questo controllo il router terrà conto dellecaratteristiche del traffico che l’applicazione andrà ad emettere; caratteristichequeste che saranno comunicate dall’applicazione all’atto della richiesta. Unavolta che questa procedura è stata attuata in ogni router attraversato da un datoflusso, quest’ultimo può aspettarsi di ricevere un servizio con pre-determinate

152

caratteristiche prestazionali. Inoltre la rete applica anche delle procedure di“policing” e di “traffic shaping” atte a garantire che il traffico emesso dalleapplicazioni sia conforme a quanto queste avevano dichiarato nella fase dirichiesta.

Come si vede questo meccanismo è del tutto identico, nelle sue lineegenerali, al controllo del traffico di tipo preventivo in ATM.

Le differenze rispetto a quest’ultima tecnica sono sostanzialmente due:- il protocollo usato per comunicare le richieste e per riservare le risorse è,

come si vedrà in seguito, diverso (ovvero RSVP);- l’architettura IntServ è pensata per poter essere applicata al di sopra di

pressoché qualsiasi altra sotto-rete, in accordo alla filosofia di Internet,mentre il controllo del traffico dell’ATM si applica solo all’ATM stesso.

Tuttavia, da un punto di vista concettuale, le due tecniche sono simili evedremo che la proposta IntServ soffre di alcuni limiti imputati ad ATM. Inparticolare un’architettura che garantisca una Qualità di Servizio ènecessariamente complessa. Si può quindi dire che IntServ conteneva in nucegli stessi problemi del paradigma ATM, emersi già alcuni anni prima cheIntServ fosse proposta. I fautori dell’ATM ammettono infatti che nel suoinsieme questa è una tecnica complessa se rapportata all’Internet attuale, ma loè per delle buone ragioni: garantire la qualità di servizi eterogenei, alcuni conrequisiti di tempo reale e di multimediali ed implicanti l’instaurazione dicircuiti virtuali anche di tipo multi-punto non è questione che ammetta semplicisoluzioni.

Nel seguito si discuteranno le classi di servizio attualmente previste inIntServ, e formalmente specificate per essere usate da RSVP, ed il protocolloRSVP stesso [WHI97].

Le classi di servizio attualmente definite, in aggiunta alla classica BestEffort sono:

- Servizio garantito (Guaranteed Service);- Servizio a carico controllato (Controlled Load Service).

Il “Servizio garantito” fornisce un determinato ritmo binario ditrasferimento, un limite superiore al ritardo da estremo a estremo e l’assenza diperdita di unità informative. Ogni router assegna ad un flusso a “Serviziogarantito” una quantità di banda e una quantità di buffer per mezzo di unmodello del flusso ad “approssimazione fluidica” [PAR96].

L’applicazione che richiede il servizio deve fornire un insieme di parametriche descrivono il traffico che andrà ad emettere, Tspec (5 parametri) ed uninsieme di parametri che (uniti ai precedenti) specificano le prestazioni attese,Rspec (2 parametri).

153

Il traffico a “Servizio garantito” è controllato (policed) all’ingresso dellarete e “shaped” all’interno della stessa per assicurarne la conformità all’insiemeTspec. I datagrammi che l’applicazione emette in modo non conforme alcontratto sono trattati come traffico “best-effort”.

Il "Servizio a carico controllato" non fornisce particolari garanzieprestazionali. L’applicazione sorgente comunica un insieme di parametridescrittivo, Tspec, e la rete si impegna a trattare il relativo flusso “come untraffico di tipo best-effort in una rete non eccessivamente caricata”. Ladifferenza importante rispetto al semplice traffico best-effort è che leprestazioni viste da questo traffico non degradano quando il traffico in reteaumenta. Al contrario un flusso di tipo best-effort soffrirà maggiori perdite eritardi all’aumentare del traffico globale in rete. Come nel caso precedente iltraffico di tipo “Servizio a carico controllato” è controllato (policed)all’ingresso della rete e “shaped” all’interno della stessa per assicurarne laconformità all’insieme Tspec. I datagrammi che le applicazioni emettono inmodo non conforme al contratto sono trattati come traffico “best-effort”. Ladifferenza sostanziale di questo servizio rispetto a quello best-effort è che esso èsottoposto ad un controllo di accesso, mentre il best-effort no.

IV.3.2.1 Il protocollo RSVP

RSVP (ReSource reserVation Protocol) [BRA97], è un protocollo diprenotazione usato in router di tipo IntServ per garantire una pre-determinataqualità di servizio in reti IP.

E’ stato progettato per consentire a mittenti, destinatari e routers dicomunicare tra loro per stabilire opportuni stati e modalità di trattamento deidatagrammi all’interno dei router, al fine di supportare le classi di servizioprecedentemente definite.

RSVP si basa su stati di tipo “soft” ed è iniziato dal destinatario. Ciò è daconfrontare con gli analoghi protocolli dell’ATM che sono di tipo “hard” ediniziati dal mittente. Le principali caratteristiche di RSVP sono le seguenti:

- è basato sul concetto di flusso;- il nodo mittente informa i nodi destinatari del tipo di traffico che andrà ad

emettere e le caratteristiche prestazionali di cui necessita;- il destinatario (o i destinatari nel caso di comunicazione punto-multipunto)

informa i router a monte delle caratteristiche del traffico che intende riceveree richiede una data qualità di servizio per il flusso che riceverà (essendo talequalità di servizio quella che gli era stata comunicata dal mittente);

- tali router interpretano i messaggi RSVP ricevuti, determinano le risorsenecessarie per fornire i richiesti livelli prestazionali al traffico in questione e,

154

se tali risorse sono disponibili, le riservano al flusso in questione;- il router istruisce quindi i suoi moduli attuativi di trattare i datagrammi

appartenenti ad un dato flusso in modo tale che l’attraversamento del routerstesso avvenga in accordo a determinate caratteristiche prestazionali (e.g.,mediante opportune discipline di coda);

- la gestione delle risorse è gestita attraverso stati “soft”; se la richiesta di cuisopra non è ri-inviata periodicamente entro intervalli di tempo pre-stabiliti, lerisorse allocate vengono rilasciate;

- il protocollo è basato su un paradigma punto-multipunto; il caso punto-puntoè trattato come caso particolare; da questa scelta deriva anche la comodità diusare un algoritmo iniziato dal destinatario; si nota infatti che untrasferimento di informazione di tipo punto-multipunto è gestibile in modopiù semplice se le richieste sono originate dal destinatario;

- lavora su base “hop-by-hop” invece che su base da estremo a estremo comel’analogo meccanismo in ATM; ciò significa che potrebbe accadere che unsingolo router rifiuti una richiesta accettata invece da tutti gli altri router inun cammino origine-destinazione, determinando così uno spreco di risorsenei routers che hanno accettato un richiesta non esaudibile in tutto ilcammino percorso;

- soffre di problemi dovuti al fatto che gli attuali protocolli di instradamentocome RIP e OSPF determinano una strada tra origine e destinazione che siala più breve possibile secondo una certa metrica e non una stradacaratterizzata da determinati livelli di qualità di servizio (cfr. QoS routing,IV.3.4).

Si descriverà ora tale protocollo in maggior dettaglio [WHI97], conriferimento ad una sola sessione di comunicazione, assunta di tipo punto-multipunto (caso più generale).

RSVP identifica una sessione di comunicazione per mezzo di alcuniparametri (indirizzo del nodo sorgente, tipo del protocollo di trasporto, porta didestinazione). Ogni operazione di RSVP si applica ai datagrammi appartenentiad una sessione e quindi ogni messaggio RSVP deve includere i parametri dellasessione a cui si riferisce. RSVP non include funzionalità di instradamento masfrutta all’uopo i servizi offerti dal protocollo di rete al di sopra del quale èlogicamente situato. La sua funzione è prenotare delle risorse lungo uncammino identificato dai protocolli di instradamento dello strato di rete. Nesegue che tutti i messaggi di RSVP e i successivi datagrammi appartenenti aduna data sessione seguiranno la strada scelta dai protocolli di instradamento. LaFig. 27 mostra un esempio del funzionamento di RSVP in una sessione punto-

155

multipunto comprendente un mittente (S1) e tre destinatari (RCV1-3), lungo deicammini che attraversano quattro routers (R1-4).

R1 R2 R3

R4

S1RCV2

RCV1

RCV3

ResvResvTearPathErr

PathPathTearResvErrResvConf

Mittente

Destinatari

Fig. 27 - Messaggi del protocollo RSVP

I messaggi più importanti di RSVP sono Path (emesso dal mittente) e Resv(emesso dai destinatari). Il messaggio di Path serve ad instaurare opportuni statinei routers attraversati, finalizzati al trattamento dei messaggi Resv chesuccessivamente essi riceveranno e a comunicare ai destinatari le caratteristichedel traffico che il mittente genererà e le caratteristiche del cammino percorso. Ilruolo dei messaggi di Resv è invece quello di richiedere ai routers coinvoltil’allocazione di opportune risorse.

Quando S1 vuole iniziare una sessione a qualità garantita, secondo unadelle due classi di servizio sopra definite, inizia ad emettere messaggi di Pathverso R1; questi a sua volta li rilancia verso R2, R3 e R4, seguendo il camminodeciso dai protocolli di instradamento (cfr. anche Fig. 28).

��!� ��

RSVP Host(SND)

RSVP Host(RCV)

RSVP Router RSVP Router

PATH

Fig. 28 - Invio dei messaggi di Path

156

Ogni messaggio di Path contiene:- Phop: l’indirizzo dell’ultimo router a monte che ha rilanciato il messaggio di

Path; questa informazione serve al router a valle per instradare i successivimessaggi provenienti nella direzione inversa;

- Sender Template: identifica il mittente e la sessione; serve ad associare ifuturi datagrammi ad una data sessione; consiste nell’insieme di parametridefinito in precedenza (indirizzo del nodo sorgente, tipo del protocollo ditrasporto, porta di destinazione); in IPv6 potrebbe essere sostituitodall’apposito campo Flow ID; il suo ruolo è analogo a quello del VCI inATM;

- Sender Tspec: identifica le caratteristiche del traffico che il mittente andrà ademettere e le prestazioni richieste;

- Adspec: opzionale, identifica le caratteristiche del cammino da estremo aestremo; può essere usato dai destinatari per meglio determinare il livello diprestazioni disponibili e quindi le risorse di cui chiederanno l’allocazione.

Ogni router che riceve un messaggio di Path ne controlla la validità; incaso negativo risponde con un messaggio di PathErr a colui dal quale lo haricevuto. In caso positivo il router:

- crea una variabile di stato, indirizzata da Sender Template e contenente Phop,Sender Tspec, e Adspec; se già esisteva una variabile di stato indirizzata dallostesso Sender Template, la aggiorna; Phop sarà usato per indirizzare imessaggi Resv ricevuti dal nodo/router a valle e diretti verso il nodo/router amonte;

- inizializza un timer, scaduto il quale, se non si sono ricevuti altri messaggi diPath relativi alla stessa sessione che avrebbero l’effetto di ri-inizializzarlo, lavariabile di stato relativa alla sessione in questione viene cancellata. Tramitel’uso di questo stato soft la tipica “robustezza” ai malfunzionamenti diInternet viene preservata;

- rilancia il messaggio di Path verso il/i nodo/i/router a valle, dopo averaggiornato i campi Phop e Adspec.

- genera messaggi di Path ogni qual volta rileva cambiamenti nella variabile distato, a intervalli periodici per “rinfrescare” gli stati dei nodi/router a valle eogni volta che i suoi protocolli di instradamento comunichino uncambiamento di strada per raggiungere le destinazioni della sessione inesame. In ognuno di questi casi il router aggiorna i campi Phop e Adspec.

Quando un mittente vuole chiudere una sessione può inviare un messaggioPathTear; questo serve a cancellare tutte le variabili di stato dei routerattraversati da una data sessione, senza aspettare che si cancellino in seguito

157

allo scadere dei timer, e quindi è utile per liberare in minor tempo risorseimpegnate e non più necessarie.

Si è detto che nel messaggio di Path può essere opzionalmente contenutol’oggetto Adspec; in tal caso, nel percorrere il cammino mittente-destinazione, ilmessaggio di Path “colleziona” alcuni dati riguardanti l’intero cammino tra cui:

- minimo ritardo di trasferimento (cioè il ritardo che subirebbe un datagrammain assenza di ritardi dovuti ad accodamento, ovvero in condizioni di retescarica)

- la minima banda disponibile;- la massima dimensione dell’unità di dati;- il numero di router con funzionalità RSVP attraversati;- un bit che identifica l’eventuale attraversamento di router privi di

funzionalità RSVP, i quali potrebbero invalidare l’intera operazione.L’oggetto Adspec contiene almeno uno di due diversi tipi di sub-oggetti, in

accordo alla classe di servizio richiesta: Guaranteed Service o Controlled LoadService (cfr. il paragrafo precedente). L’assenza di uno dei due indica aldestinatario che la relativa classe di servizio non è supportata da almeno uno deisistemi attraversati; si può anche omettere deliberatamente uno dei due sub-oggetti per forzare tutti i destinatari di una sessione punto-multipunto ascegliere la stessa classe di servizio.

Tali sub-oggetti trasportano dei parametri che possono essere utilmenteusati dai destinatari per scegliere l’ammontare di risorse di cui chiederel’allocazione.

Nel caso in cui l’oggetto Adspec è incluso nel messaggio di Path, ilmodello di prenotazione è denominato One Pass With Advertisement (OPWA),altrimenti è noto come One Pass semplice. In quest’ultimo caso i destinatarihanno poche informazioni a disposizione su come scegliere le risorse di cuichiedere l’allocazione, per cui la relativa scelta sarà sicuramente non ottimale epotrebbe essere tale da non riuscire a garantire le prestazioni richieste dalmittente. Con la modalità OPWA l’applicazione richiedente una data sessionepuò riuscire a determinare quella che sarà la Qualità di Servizio da estremo aestremo prima di iniziare ad inviare dati di utente, in modo molto simile alparadigma ATM. Nel seguito si farà riferimento al caso di OPWA.

Assumiamo inoltre che il mittente scelga di non inviare il sub-oggettoControlled Load Service, ed invii quindi il sub-oggetto Guaranteed Service,restringendo così il destinatario a scegliere la classe di servizio GuaranteedService (che è la più complessa da attuare).

Quando il destinatario riceve un messaggio di Path, sulla base delleinformazioni ivi contenute, calcola l’ammontare di risorse di cui chiedere

158

l’allocazione ai router a monte. Le relative modalità sono esposte in [WHI97,PAR96]. A questo punto il mittente può creare il messaggio Resv ed inviarloal/ai router da cui ha ricevuto il messaggio di Path ed identificato/i dal campoPhop. (cfr. anche Fig. 29)

��

RSVP Host(SND)

RSVP Host(RCV)

RSVP Router RSVP Router

RESV

Fig. 29 - Invio dei messaggi di RESV

Il messaggio Resv contiene i seguenti campi:- stile di prenotazione: (Fixed Filter, Shared Explicit o Wildcard Filter);

riguarda il modo in cui diversi messaggi Resv relativi alla stessa interfacciadel router, sono uniti insieme prima di essere passati al modulo di controllodel router; quest’ultimo riserva le risorse relative ad una certa interfaccia inmodo aggregato e relativo ad un insieme di richieste, invece che in modoindividuale; queste modalità di stile di prenotazione sono legate al tipo disessione (punto-punto, punto-multipunto) ed anche al tipo di applicazionesupportata (e.g. video-conferenza);

- FilterSpec: usato per identificare la sessione ed uguale a Sender Template;- Flowspec: contiene le caratteristiche del traffico e le risorse di cui si chiede

l’allocazione;- ResvConf (opzionale): contiene l’indirizzo del destinatario; la funzione di

questo campo è chiedere a colui il quale il messaggio Resv è inviato, diconfermarne la ricezione con un messaggio ResvConf.

Quando il router a monte riceve un messaggio di Resv:- unisce questo messaggio ad altri eventuali messaggi Resv provenienti dalla

stessa interfaccia di rete, secondo le modalità dello stile di prenotazione(Fixed Filter, Shared Explicit o Wildcard Filter), per produrre dei campicumulativi Flowspec e FilterSpec;

- invia il campo cumulativo FlowSpec al modulo di controllo del router stesso;questi applica i meccanismi di controllo di ammissione e di policing perdecidere se accettare o meno la richiesta. In caso negativo risponde a coluiche gli ha inviato il messaggio Resv con un messaggio ResvErr. In caso

159

positivo, aggiorna le relative variabili di stato e invia un messaggio di Resvverso il nodo/router a monte nel cammino in questione (il cui indirizzo avevaconservato quando il messaggio di Path originario lo aveva attraversato); ilmessaggio Resv inviato può risultare dalla combinazione di diverse richiestericevute dai nodi/router a valle, in funzione dello stile di prenotazione (FixedFilter, Shared Explicit o Wildcard Filter);

- come nel caso del messaggio di Path, anche quello di Resv viene generato edinviato al nodo a monte, immediatamente ogni qual volta rileva cambiamentinella variabile di stato, e a intervalli periodici per “rinfrescare” gli stati deinodi/router a monte; anche questo stato e quindi gestito in modo soft ed aiutaa preservare la tipica “robustezza” ai malfunzionamenti di Internet;

- istruisce i moduli attuativi di trattare i datagrammi appartenenti alla sessionein questione in modo tale che ad essi siano assegnate delle risorse sufficientia garantire le prestazioni richieste dal mittente.

Questo ultimo è un punto particolarmente importante. Esistono diversemodalità per trattare le unità informative in modo tale che l’attraversamento diun router avvenga in accordo a determinate caratteristiche prestazionali; tra lepiù importanti citiamo alcune discipline di coda proposte a tal fine [e.g. KLE75,KES97, DEM89, PAR96], ricordando che la definizione di un’opportunadisciplina di coda (o scheduling) è un aspetto chiave di un’architettura IntServ:

- diverse code FIFO in parallelo, ognuna dedicata ad una quota parte ditraffico;

- code con priorità;- fair queuing e weighted fair queueing;- weighted round robin e deficit weighted round robin;- generalized processor sharing.

Nel caso di RSVP si suggerisce di usare quest’ultima disciplina [PAR96,WHI97]. A titolo di esempio la Fig. 30 mostra la disciplina weighted fairqueueing: i pacchetti entranti vengono smistati in più code, una per ogni flusso.Ognuna di queste code è servita con una velocità (ovvero con un peso, weight)che è funzione delle prestazioni richieste dal flusso relativo. Si noti che il nododeve gestire un numero di code pari al numero di flussi presenti. Persemplificare questa gestione un'alternativa è quella di aggregare i flussicaratterizzati dalle stesse prestazioni in classi. In tal caso il numero delle code èpari al numero delle classi e quindi si ottiene una significativa semplificazione(cfr. Fig. 31).

160

Fig. 30 - Modalità di funzionamento di weighted fair queueing, per flussi

Fig. 31 - Modalità di funzionamento di weighted fair queueing, per classi

L'intero approccio IntServ è mostrato in Fig. 32 .

161

#��

!��

2�3��!� �

Linea di Ingresso

Linea di Uscita

"��

!� ��

#� ��

�� !� ��

4�� &��

�� 5" ��# ��5"

Fig. 32 - Architettura di IntServ

Il processo di cui sopra è iterato in tutti i router del cammino in questionee, se si conclude ovunque in modo positivo, il mittente può inviare dati con lagaranzia che saranno consegnati a destinazione in accordo alle desideratecaratteristiche prestazionali.

Notiamo, che nell’ambiente RSVP, la prenotazione delle risorsecorrisponde all’instaurazione di un VC nell’ambiente ATM. La corrispondenzatra i paradigmi IntServ e ATM per il supporto della qualità di servizio èmostrata in Fig. 33.

RSVPInstradamento

senza connessioneFlow

SpecsFlow IDs

PacketScheduling

ATMSignaling

TrafficContract

VP/VCITraffic

Managem.

ISInternet

ATM

Applicazione

Richiesta diQoS

Garanzie diQoS

Instradamentosu base VC

Fig. 33 - Corrispondenza tra i paradigmi ATM e RSVP

162

RSVP è stato indicato da molti come la soluzione che avrebbe risolto ilimiti di Internet per ciò che concerne la garanzia di qualità di servizio. Lacomunità Internet sta però oggi sostenendo che questo protocollo è moltocomplesso e ha seri limiti di scalabilità; in altre parole può funzionare bene perun numero ristretto di applicazioni, in alcune aree della rete, ma non è in gradodi poter essere implementato in tutta Internet e per un rilevante numero diutenti. Alcuni degli stessi progettisti di RSVP si sono espressi in tal senso,mettendo in evidenza che questo protocollo è stato pensato per supportareproprio un numero relativamente ristretto di applicazioni (e.g. video-conferenzeche tipicamente non sono oggi molto numerose e consumano una rilevantequantità di banda) ma che mal si adatta a trattare gran parte del trafficoincludendo, ad esempio, le applicazioni WWW e la telefonia.

Si è detto infatti che in una rete con connessione è necessario mantenereinformazioni di stato all’interno dei commutatori. Tali informazioni sono quelleche specificano come trattare una unità di dati appartenente ad una dataconnessione. Quando un nodo riceve una unità di dati, esso usa un appositocampo come puntatore ad una tabella in cui sono contenute le informazioni chespecificano come trattare tale unità di dati. Tipicamente le informazioni di statovengono comunicate e memorizzate durante la fase di instaurazione per esserepoi eliminate durante la fase di abbattimento. In un nodo sono quindi necessaritanti stati quante sono le connessioni attive.

Ciò è però vero anche in una rete senza connessione, qualora si definiscaun’associazione logica tra più datagrammi, al fine di implementare efficientifunzioni di commutazione e di offrire garanzie di qualità di servizio.

E' evidente che i requisiti di memorizzazione (e.g. dimensione dellatabella) e la complessità (ricerca di un particolare valore nella tabella e relativotrattamento dell'unità di dati) sono proporzionali al numero di stati che ènecessario mantenere. Ad esempio, un servizio di telefonia con voce codificataADPCM richiede 32 kbit/s. Trascurando gli overhead, se consideriamo unalinea ad alta capacità (OC12, 622 Mbit/s) è necessario mantenere circa 20000flussi. Ciò significa che il router deve gestire 20000 code e che bisognamantenere 20000 stati per ogni linea, con ciò che questo comporta in termini didimensioni della tabella, complessità, segnalazione RSVP, etc.

Tra l'altro questo approccio rappresenta un cambiamento sostanzialedell'architettura di Internet, in cui si prevede che il trattamento di singoli flussisia ristretto solo ai sistemi terminali e non nella rete. I requisiti posti ai routerssono notevoli: devono implementare RSVP, il controllo di ammissione dichiamata, la classificazione dei datagrammi e opportune discipline di coda, alposto della semplice FIFO sinora usata. Inoltre per garantire una prestazione da

163

estremo a estremo occorre che questo approccio sia implementato in tutti irouter; una installazione incrementale di IntServ è perciò problematica.

Si ritrovano quindi molti degli elementi espressi a sfavore della B/ISDN-ATM ed in particolare la ricorrente critica di una eccessiva complessità. Questonon deve stupire: come già affermato, il concetto alla base sia di RSVP che delcontrollo di traffico in ATM è infatti lo stesso; potranno esistere delledifferenze e dei vantaggi dovuti allo schema scelto ma la questione di fondonon è molto diversa. Ad esempio nulla vieta di implementare RSVP in una reteATM, sostituendo parte delle modalità di controllo del traffico di quest’ultimoparadigma con il protocollo RSVP: la soluzione rimarrà comunque complessa.

Nel tentativo di trovare delle soluzioni a questa problematica e migliorarele caratteristiche di scalabilità sono state suggerite diverse soluzioni:

- la prima è quella di cercare di aggregare il più possibile diversi flussi diutente in un unico flusso RSVP, diminuendo così il numero degli statinecessari e la relativa complessità; recentemente RSVP è stato modificatoappunto per trattare in modo più semplice aggregati di flussi, per instauraredelle "strade esplicite (ovvero dei tunnel, in modo simile a MPLS) e pereseguire altri compiti di segnalazione. Questa non appare però essere unasoluzione risolutiva;

- la seconda è quella di confinare l’operazione di RSVP nella sezione diaccesso alla rete, confidando che la sezione interna di rete: i) o saràgenerosamente dimensionata, ii) o funzionerà in accordo a paradigmi ingrado di fornire una migliore qualità di servizio (e.g. ATM, MPLS oDiffServ);

- la terza è quella di rinunciare completamente a RSVP in favore dell'approccioDiffServ.

L'approccio DiffServ sarà descritto in un paragrafo successivo. Nelprossimo paragrafo si apre invece una parentesi nel discorso qui sopra iniziato,per trattare un protocollo di strato di trasporto per il supporto di servizi conrequisiti di tempo reale. Tale protocollo completava l'architettura IntServ, primache la soluzione appena esposta fosse messa in discussione.

IV.3.2.2 Il protocollo RTP

La IETF ha definito un nuovo protocollo di strato di trasporto (Real TimeTransport Protocol, RTP) [RFC 1889, RFC 1890] che, assumendo di potersfruttare i servizi di un sistema per l’allocazione delle risorse (tipicamenteRSVP, nel progetto originario), estende le funzionalità di TCP per il supporto diapplicazioni con requisiti di tempo reale e con configurazione punto-multipunto.

164

RTP lavora affiancando TCP, fornendo un trasferimento affidabile daestremo a estremo di servizi come video-conferenza, telefonia, e serviziinterattivi audio/video/dati.

Tra le funzionalità di RTP sono da includere l’identificazione del payloade il cosiddetto time-stamping. Quest’ultima funzione è particolarmenteimportante. E’ noto infatti che, in una rete orientata al pacchetto, un flusso diunità informative può incontrare diverse situazioni di accodamento nelcammino tra origine e destinazione; alcune unità informative sono ritardate piùdi altre e il ritardo di trasferimento può presentare una variabilità (jitter); in altreparole la rete non è temporalmente trasparente. Poiché un’applicazione conrequisiti di tempo reale ha invece tipicamente bisogno di un servizio ditrasferimento con jitter molto limitato o addirittura inesistente, è necessarioprevedere, nel sistema di destinazione, un’operazione di equalizzazione deiritardi, così da fornire all’applicazione destinataria un flusso di unitàinformative ritardate in modo costante rispetto ai relativi istanti di emissionealla sorgente.

La procedura di equalizzazione dei ritardi prevede di memorizzare le unitàinformative in un apposito buffer (detto di play-out) prima di consegnarleall’applicazione ricevente. In questo buffer, le unità informative che arrivano adestinazione sono costrette a subire un ulteriore ritardo; tale ritardo èdifferenziato e funzione di quello che le unità informative avevano subito inrete: unità che erano state poco ritardate sono ritardate ancor di più mentrequelle che avevano subito più ritardo sono consegnate prima, in modo che tuttesiano poi consegnate allo strato applicativo con lo stesso ritardo. La Fig. 34mostra questo meccanismo.

!�� "��6

Playout delay

Packet delay

Emissione deipacchetti

Playout

Pacchettoscartato

Fig. 34 - Buffer di playout

Il sistema di equalizzazione deve però essere a conoscenza dell’istante incui ogni unità informativa è stata emessa dal mittente, per poter stabilire inquale istante la stessa unità debba essere consegnata all’applicazione ricevente.

165

Nel caso di applicazioni a ritmo binario di trasferimento costante la soluzione èsemplice: è sufficiente conoscere l’intervallo di tempo che intercorre tra ogniunità informativa; nel caso invece di applicazioni a ritmo binario ditrasferimento variabile, bisogna “accludere” ad ogni unità informativaun’informazione che consenta di risalire alla conoscenza del relativo istante diemissione. Ciò è ottenuto mediante la procedura del “time-stamping”, ovveroogni unità informativa è “marcata” con il proprio istante di emissione così comeogni lettera affrancata è marcata con il timbro dell’ufficio postale diaccettazione (da cui il nome).

Inoltre un “feedback” sulla qualità di ricezione e servizi di identificazionedei destinatari sono forniti dal protocollo Real Time Transport Control Protocol(RTCP) che è una parte integrante di RTP ad aiuta a controllarne ilfunzionamento.

Sebbene molte implementazioni attuali di RTP lavorino al di sopra di UDPin un ambiente IP, RTP è stato progettato per essere usato in modo indipendentedai protocolli di strato inferiore utilizzati (ad es. potrebbe essere implementatoal di sopra di ATM). Al contrario di TCP, che è stato pensato per operare in unostrato protocollare autonomo, RTP è stato pensato per lavorare in modostrettamente legato alle applicazioni.

La Fig. 35 mostra un esempio di applicazione di RTP in una sezione diInternet. In una sessione multimediale ogni componente è trasportata in modoseparato tramite una sessione RTP con i relativi pacchetti RTCP che controllanola qualità della sessione RTP stessa. Ad esempio, in una video-conferenza lecomponenti audio e video sono trasportate per mezzo di distinte connessioniRTP. Ciò consente anche ad un utente di ricevere, se lo desidera, una solacomponente. L’eventuale coordinamento di più componenti di una sessionemulti-mediale non è effettuato da RTP ma è delegato ad altri protocolli.

166

Applicazione “real time”

RTP e RTCP

UDP

Applicazione “real time”

RTP e RTCP

UDP

Router 1 Router 2RTP

RTCP

RTP

RTCP

RSVP RSVP

Fig. 35 - Esempio di applicazione di RTP

Come si è detto, RTP completa l'architettura IntServ. La Fig. 36 mostratale architettura, in cui a strato IP si prevedono le due versioni di questoprotocollo 4 e 6 (cfr. IV.4). L'introduzione dell'approccio DiffServ ha peròmodificato questa visione, come sarà discusso nel prossimo paragrafo.

RSVP

Applicazioni in tempo reale

RTP/RTCP

UDP

Applicazioni senzarequisiti di tempo reale

TCP

IPv4/IPv6

Underlying Data Link Technologies

Fig. 36 - Architettura protocollare ISA

167

IV.3.3� Approccio Differentiated Services (DiffServ)

Affinché una inter-rete possa fornire una pre-determinata qualità diservizio, è necessario che l’applicazione che esprime una data richiesta in talsenso generi un’informazione di controllo con la quale richiede a tutti i nodicoinvolti nel cammino origine-destinazione di trattare la propria informazionein un determinato modo; ovvero in modo tale che le prestazioni da estremo aestremo soddisfino le esigenze dell’applicazione e giustifichino il pagamento diuna corrispondente tariffa. Si tratta quindi di una forma di “controllo adistanza” che prende la forma di un contratto tra utente e rete ed in cui, se iltraffico in ingresso è conforme ad opportune caratteristiche, il traffico in uscitadalla rete manterrà delle corrispondenti caratteristiche poiché la rete non avràesercitato su di esso distorsioni superiori ad una pre-stabilita soglia.

Per esercitare questo controllo a distanza e perché quindi la rete possafornire garanzie agli utenti, la rete stessa deve mantenere opportuneinformazioni di stato nei sistemi attraversati, affinché questi ultimi possanotrattare il traffico relativo ad una data applicazione in accordo alle modalitàvolute dall’applicazione stessa. Il mantenimento di tali stati e lo scambio dellarelativa informazione di controllo possono essere attuati in diversi modi (e.g.ATM o RSVP) ma rimangono il punto critico degli schemi che garantisconouna qualità di servizio.

Esiste però un’alternativa al mantenimento di stati nei nodi (per ogniflusso) e agli schemi di prenotazioni di risorse. Tale alternativa consistenell’uso di meccanismi per l’allocazione preferenziale delle risorse, creandodiversi livelli di “best-effort”. In tal caso non esistendo più una garanziaprestazionale, non è necessario mantenere stati (per ogni flusso) nei nodi di retee servizi “better-than-best-effort” di diversi livelli possono essere implementaticon relativa semplicità anche in reti di rilevanti dimensioni.

Attualmente gli schemi proposti nell’ambito di tale approccio si basanosulla modifica dei meccanismi di trattamento dei datagrammi a livello di stratodi rete (tipicamente in IP) nei nodi attraversati. Ogni datagramma viene trattatoin accordo al valore di un opportuno campo nell’intestazione del datagramma.L’intera operazione non corrisponde quindi altro che all’introduzione di diversi"livelli di priorità". L’informazione su come trattare un certo datagramma èquindi trasportata dal datagramma stesso, evitando la necessità di scambiareinformazioni di controllo e di mantenere degli stati nei sistemi attraversati. Daun punto di vista logico è come si creassero diverse Internet sovrapposte,ognuna delle quali tratta una quota parte del traffico nella modalità classica,cioè best-effort; siccome però ogni quota parte del traffico è trattata in modo

168

separato dalle altre, in accordo alle sue esigenze, ciò che si crea è una serie dilivelli qualitativi, dal best-effort di base a diversi ordini di better-than-best-effort.

Si noti però che non è sufficiente implementare una disciplina di servizioche semplicemente serva datagrammi di più alta priorità prima di eventualidatagrammi di più bassa priorità, ma si tratta di servire i datagrammi in accordoalle esigenze espresse tramite l’informazione trasportata in un apposito campo(ad esempio, datagrammi con esigenze di tempo reale dovranno essere servitilimitando il più possibile la variabilità del ritardo). Un ruolo chiave è quindiquello delle discipline di coda.

Questo approccio è noto come “Differentiated Services” (DiffServ) eassume che il traffico in ingresso alla rete sia marcato con un determinatolivello di priorità e quindi policed e/o shaped prima di entrare nella rete stessa.All’interno della rete opportune discipline di coda (e.g. fair queuing o weightedfair queueing) provvedono a trattare i datagrammi secondo diverse modalità infunzione dei relativi livelli di priorità. Le modalità di tariffazione sarannofunzione del livello di priorità scelto.

Il comportamento complessivo di tali schemi, privi di informazioni di statoe operanti in modo autonomo nodo per nodo, in modalità senza connessione ètale da fornire diversi livelli di servizio e non presenta problemi di scalabilità.Ovviamente, perché ogni utente possa “vedere” determinate prestazioni, l’interainter-rete deve essere dimensionata in modo opportuno, nell’ambito di ognunadelle classi di servizio supportate ovvero nell’ambito di ognuno dei servizidifferenziati supportati.

Ricordiamo che il requisito chiave è la scalabilità, ovvero DiffServ devepoter lavorare nell'intera Internet e ad altissime velocità (Gbit/s). Ciò ha laseguente catena di implicazioni:

- Non è possibile mantenere all'interno della rete un numero di stati funzionedei flussi trattati;

- L'assenza degli stati suggerisce che la indicazione del servizio voluto deveessere trasportata all'interno di ogni datagramma;

- Ogni router tratta un datagramma in accordo all'indicazione del serviziovoluto, trasportata in un campo opportuno, denominato "campo DS";

- La semantica del campo DS deve essere molto semplice (pochi bit)Il meccanismo di DiffServ è quindi il seguente:

- ai bordi della rete i datagrammi vengono classificati, in funzione dei requisitiprestazionali richiesti

- questa classificazione si traduce in un particolare valore del campo DS- ogni valore del campo DS corrisponde ad una classe di servizio

169

- il datagramma viene immesso in rete- all’interno di ogni router sono definiti dei Per Hop Behaviour (PHB), ovvero

delle modalità di trattamento dei datagrammi per ogni classe di serviziodefinita;

- quando un router riceve un datagramma esamina il campo DS e quindi lotratta in accordo alla relativa classe di servizio

- accade quindi qualcosa di simile al meccanismo classico di RSVP: unopportuno campo funge da puntatore ad una tabella in cui sono contenuteinformazioni su come trattare il datagramma; la differenza chiave è però chele alternative possibili sono pari al numero delle classi e non al numero deiflussi.

Si noti che DiffServ specifica solo il campo DS ed i PHB; è poiresponsabilità dell'operatore decidere quali particolari prestazioni farcorrispondere ad una coppia DS-PHB. Inoltre DiffServ non specifica dei"servizi". Il servizio percepito dall'utente è semplicemente il risultato dei PHB.

Perché un utente possa ricevere un Servizio Differenziato deve stabilire unaccordo con un operatore (o Internet Service Provider, ISP). Tale accordo èdenominato Service Level Agreement (SLA) e specifica la classe di serviziosupportata a l'ammontare di traffico consentito (ovvero le prestazioni chel'utente si aspetta di ricevere). Un SLA può essere statico o dinamico Un SLAstatico è negoziato per un periodo abbastanza lungo (mesi o anni, su baseamministrativa). Un SLA dinamico richiede invece un apposito protocollo disegnalazione tra utente e ISP, al fine di negoziare il relativo accordo. A tal finesi può usare RSVP, ma sottolineiamo che ciò avviene solo tra utente e ISP e nonall'interno della rete.

In base al SLA negoziato il traffico emesso dall'utente viene classificato edanche controllato per verificare che rientra nel'ambito dell'accordo. Eventualetraffico emesso in disaccordo all'SLA viene scartato (o trattato come best-effort). La Fig. 37 mostra questo trattamento ai bordi di rete.

170

"��2�� 6��'�+��: ��++��

6��0��

Fig. 37 - Trattamento del flusso di utente ai bordi della rete

Si definisce inoltre come "dominio DS" un insieme di router DS contigui,che operano in accordo ad una politica comune, ad un dato insieme di PHB esotto il controllo di un'unica entità amministrativa. I router posti alla frontiera diun dominio vengono denominati Edge Router (ER). Il responsabile di undominio DS ne stabilisce PHB e relativi livelli prestazionali e negozia SLA coni suoi utenti. Si definisce invece come regione DS un insieme di domini DScontigui; ogni dominio DS è indipendente dagli altri e sceglie autonomamentePHB e associazioni tra campi DS e prestazioni. Opportuni SLA sono stabiliti trai diversi domini DS (cfr. Fig. 38 e Fig. 39). Quando un datagramma passa da undominio all'altro può essere sottoposto alle stesse funzioni eseguite ai bordidella rete (cfr. Fig. 37), ovvero può essere ri-classificato e ri-marcato, inaccordo al SLA stabilito in quella interfaccia.

��0��"��

��0��2��<�8�

2��"��

0��

Fig. 38 - Dominio DS

171

�� $�( �� $�(

=��>5��

=��>8�

8�

Fig. 39 - Regioni e domini DS e SLA stabiliti tra domini o tra un dominio e i suoi utenti

Si è detto che gli SLA possono essere statici o dinamici. La prima fase diimplementazione di DiffServ prevede SLA statici. L'introduzione di SLAdinamici consentirebbe una maggiore flessibilità ed un migliore efficienza; adesempio un ISP potrebbe avere necessità di smaltire un traffico più elevato equindi negoziare con un suo ISP corrispondente una variazione del SLA. Ciòrichiede però un coordinamento tra le entità coinvolte ed un appositoprotocollo. E' inoltre ovvio che bisogna applicare gli SLA dinamici solo adaggregati di traffico e non a flussi individuali, altrimenti ricadremmo neiproblemi di scalabilità di IntServ. La struttura di rete per una regione DS conSLA dinamici è mostrata in Fig. 40.

In tale architettura distinguiamo diverse entità, oltre agli host di utente:- Leaf Router, LF: sono l'interfaccia tra utente e rete, eseguono le funzioni di

classificazione, marcatura e policing/shaping, relativi all'SLA tra utente eISP;

- Core Router, CR: sono router interni, ad alta capacità; eseguono solo i PHBtipici di un dominio DS

- Edge Router, ER: in aggiunta alle funzionalità dei CR, fungono da interfacciatra diversi domini DS, eseguendo ove necessario le funzioni diclassificazione, marcatura e policing/shaping, relativi all'SLA tra i duedomini coinvolti

- Bandwidth Broker, BB: negozia dinamicamente i SLA tra diversi domini,configurando gli ER di conseguenza; a tale fine deve usare un appositoprotocollo. Per semplicità in Fig. 40 è previsto un solo BB, ma potrebbeesistere diversi BB, con la conseguente necessità di coordinarsi tra loro,sempre per mezzo di un opportuno protocollo.

172

�� $�( �� $�(

=��>=��>8�<��

8�<�7

0��

��

� �

8�<��

=��>

��&��'��;��

Fig. 40 - Architettura di rete per DiffServ con SLA dinamici

Nell’ambito del paradigma DiffServ sono state avanzate diverse propostespecifiche sia per quanto riguarda i PHB che per quanto riguarda il formato delcampo DS. L'approccio DS può essere applicato sia in IPv4 che in IPv6; infattitutte e due le versioni dispongono di un campo nell'intestazione del datagrammache può essere usato come campo DS. Per quanto riguarda IPv4, il campodisponibile a tale fine è il campo Type of Service (TOS, di 8 bit).

Si noti che paradossalmente questo campo era stato introdotto in IPv4 sinnelle specifiche originali di questo protocollo proprio per lo stesso scopo percui ora si propone di usarlo. Citando dalle specifiche di IP [RFC791, Settembre1981]:campo Type Of Service (TOS):specifica parametri della qualità di servizio richiesti dall’utente; un sub-campo(3 bit) con valori da 0 a 7 indica la priorità del datagramma; un sub-camposuccessivo è composto da tre bits che possono essere utilizzati per richiedereparticolari caratteristiche: D-bit (low delay), T-bit (alto throughput), R-bit (altareliability); i restanti due bit erano riservati per usi futuri (cfr. Fig. 41).

173

�� !" #!��$�" �� !" #!��%��&��'��$�" �&��'��(�)��&��*��+��,!�!��-��%��(��)��.��.��.��.��.��.��.��.��.��/��/��/��/��/��/��/��/��&010�0�10��/��/��/��&��/��/��/��/��/��/��/��/��/��/��.��.��.��.��.��.��.��.��.

��,�� 2��&�!��

�� 3�1��2��3�1��1&2�21401��,�� 5*��

Fig. 41 - Formato del campo TOS "storico" (1981)

Nella [RFC1349, 1992] uno dei due bit riservati è stato aggiunto alsecondo sub-campo di cui sopra risultando nella seguente semantica dei 4 bitseguenti i primi tre, i quali continuano ad identificare l’importanza di undatagramma in scale di priorità:

- 1000 minimizzare il ritardo- 0100 massimizzare la portata (throughput)- 0010 massimizzare l’affidabilità (reliability)- 0001 minimizzare il costo- 0000 servizio normale.

Di fatto l’uso del campo TOS è attualmente opzionale e risulta raramentetenuto in conto nelle implementazioni, proprio in favore di una maggioresemplicità. La soluzione DiffServ ne rilancia l’uso proponendo di usarlo inmodo obbligatorio per lo meno in tutti i router appartenenti ad una sezione diInternet che intenda offrire tali funzionalità. DiffServ definisce un nuovoformato per il campo TOS (che sarà poi applicato anche in IPv6), ri-nominandolo campo DS. Per maggiori dettagli circa tale formato e circa i PHBattualmente definiti si rimanda, ad esempio, a [XIA99 riferimenti ivi contenuti].

In conclusione, DiffServ è significativamente diverso da IntServ. Ilnumero di stati è funzione del numero delle classi e non del numero dei flussi.Le operazioni di classificazione e marcatura sono eseguite solo ai bordi dellarete o tra diversi domini DS. Una implementazione graduale è possibile poichérouter non DS-compatibili possono semplicemente ignorare il campo DS,

174

trattando i datagrammi in modalità best-effort. Siccome i datagrammi DS sonotrattati con priorità, in almeno alcuni router, le loro prestazioni saranno sempremigliori di quelle del traffico best-effort e miglioreranno sempre più, man manoche altri router DS vengono installati.

DiffServ è quindi una soluzione di compromesso tra l'attuale best-effort eIntServ. Parte dalla assunzione che una soluzione con garanzie della qualità diservizio è troppo complessa per essere attuata nel medio termine e si propone difornire solo dei diversi livelli di “Qualità del Servizio” su base best-effort inmodo abbastanza predicibile e con la capacità di offrire un servizio specifico aspecifiche classi di utenti ed applicazioni. Sottolineiamo però che in tal modonon si offrono garanzie prestazionali. Potrebbe accadere che un rilevantenumero di utenti faccia richiesta di servizio usando una classe di una datapriorità, ma che le risorse di rete non siano sufficienti a trattare il traffico di taleclasse con prestazioni adeguate. Ciò perché le risorse non sono assegnate subase flusso, ma semplicemente divise tra le classi supportate. DiffServ tratta inmodo separato le varie classi, proteggendo il traffico di una classe da quellodelle altre, ma la congestione è sempre possibile all'interno di ciascuna classe.

Notiamo anche che nella Internet attuale esistono già oggi diversi InternetService Provider, ISP che forniscono agli utenti servizi di qualità diversa(grazie ad accordi multi-laterali tra diversi fornitori) e che, di conseguenza,chiedono il pagamento di diverse tariffe. In altri termini una Internet con serviziin qualche modo differenziati esiste già (un esempio significativo è costituitodalle Intranet). Un utente può quindi già oggi scegliere di abbonarsi ad un ISPche fornisce una migliore o peggiore "Qualità di Servizio”. Ma: i) il livello diservizio per cui si paga è applicato a tutto il traffico generato da un dato utente;ii) una data qualità di servizio è offerta solo nell'ambito della rete propria di unISP (o al più nell'ambito di una "federazione" di ISP, ottenuta, tramite accordimulti-laterali) ma in genere un ISP non può garantire ai suoi clienti che questisperimenteranno la stessa “Qualità di Servizio” in ogni momento e ovunque sitrovi in Internet il corrispondente con cui un dato cliente vuole dialogare. Inaltri termini una certa “Qualità di Servizio” è fornita solo in determinate sub-aree di Internet e in certi periodi di tempo. L’introduzione di DiffServestenderebbe la possibilità di qualità di servizio differenziate in tutta Internet, inmodo standard ed ampliandone le possibilità di scelta. Inoltre gli ISPpotrebbero seguire politiche di tariffazione differenziate, facendo pagare di piùgli utenti (o alcune applicazioni di un utente) che attribuiscono uncorrispondente valore al servizio offerto e quindi potrebbero reperire ledisponibilità finanziarie per installare risorse addizionali al fine di servireancora meglio le rispettive utenze. Non si dimentichi che l’attuale tariffazione

175

“flat rate”, applicata in modo preponderante in Internet, avrà sicuramentecontribuito allo sviluppo di Internet, ma ne ostacola ora un’ulteriore crescita,poiché gli ISP non trovano una sensibile convenienza ad offrire servizi dimigliore qualità se questi non comportano maggiori guadagni.

Prima di concludere il paragrafo presentiamo nella Fig. 42 quello che èritenuto da molti come uno dei più credibili scenari a medio termine per offrireuna migliore qualità di servizio in Internet: ovvero una soluzione ibrida IntServ-DiffServ. In particolare in questa soluzione il paradigma IntServ è applicatonelle sezione di accesso (o meglio in singole sotto-reti di accesso), mentre lasoluzione DiffServ è applicata all'interno della rete. Un opportuno BandwidthBroker (centralizzato in figura, ma in realtà distribuito) coordina le diverseparti. Nella figura sono anche esplicitati i flussi di informazione di utente, lasegnalazione RSVP (che attraversa trasparentemente la sezione DiffServ) e lasegnalazione necessaria per coordinare, tramite il BB, le entità di frontiera.

ER

DS-R R

Host RR

RR

R

��&��'��;��

ER

ER ER

ER

ER��

DS-R

��4��

ER: Edge RouterDS-R: DiffServ RouterR: RSVP router

flussi di utenteprotocollo ad hoc per il coordinamento con il BBprotocollo RSVP

Fig. 42 - Soluzione ibrida IntServ-DiffServ

IV.3.4� Ingegneria del traffico e QoS-routing

Gli schemi sinora presentati (IntServ e DiffServ, ma anche ATM) cercanodi fornire delle prestazioni differenziate a diversi utenti e classi di traffico,soprattutto quando il traffico offerto alla rete è elevato. Quando la rete è

176

relativamente scarica la necessità di questi schemi è molto minore e leprestazioni sarebbero soddisfacenti anche con una modalità best-effort.L'ingegneria del traffico cerca appunto di evitare la congestione di rete,dimensionando opportunamente le risorse. La congestione può essere dovuta oa mancanza di risorse di rete o a una non uniforme distribuzione del traffico.Nel primo caso tutta le rete e congestionata e l'unica soluzione è aggiungerealtre apparecchiature, collegamenti, router, etc.

Nel secondo caso, alcune parti della rete sono congestionate mentre altresono scariche. Una rete può essere non uniformemente caricata perché gli utentipresentano richieste distribuite appunto in modo non uniforme e perché moltidei protocolli di instradamento in Internet, scelgono la strada più breve, senzatenere in conto lo stato di occupazione delle risorse (cfr. III.4.5.4). Unasoluzione a questo problema è quella di usare protocolli di instradamento chedeterminino le strade tenendo in conto opportuni vincoli (instradamento convincoli, constraint based routing).

Un particolare esempio di instradamento con vincoli e quello con vincolidi Qualità di Servizio, QdS (Quality of Service routing, QoS-routing). In talcaso, si assume che l'utente richieda un servizio con una certa QdS. I protocollidi instradamento non solo scelgono una strada da origine a destinazione mascelgono una strada che soddisfi i requisiti di QdS, ovvero lungo la quale visiano sufficienti risorse. Più in generale un instradamento con vincoli consideraoltre alla QdS anche altri vincoli, tra cui politiche di gestione. Il suo scopo è siadi fornire una certa QdS, che aumentare l'utilizzazione delle risorsedistribuendo opportunamente il traffico ed evitando colli di bottiglia(effettuando un bilanciamento di carico, load balancing). Tali protocolli devonoquindi considerare non solo la topologia di rete ma anche lo stato dioccupazione delle risorse, i requisiti degli utenti ed eventuali altre politiche digestione dell'amministratore di rete. Ne segue che invece di scegliere uncammino breve ma congestionato, scelgono un cammino magari più lungo mapiù scarico. Un instradamento con vincoli deve realizzare due funzioni:

- Scambio di informazioni: è necessario che i router si scambino opportuneinformazioni sulla base delle quali prendere le loro decisioni. Taliinformazioni non riguardano più la sola topologia di rete. E' ovvio chediverse scelte sono possibili in tal senso, tra cui molto importanti sono lemodalità e la frequenza con cui queste informazioni sono scambiate(tipicamente alcune decine di secondi);

- Scelta delle strade: sulla base delle informazioni scambiate, i router devonoscegliere le strade; è ovvio che la complessità di questa funzione è maggioredi quella in assenza di vincoli e dipende dalla particolare metrica usata (ad

177

es., numero di salti, banda disponibile, affidabilità, ritardo, jitter, costo). Inalcuni casi il problema può avere una complessità notevole (e.g., algoritmipolinomiali o NP completi). Le strade possono essere pre-calcolate per classidi traffico o addirittura per ogni richiesta di utente.

Un instradamento con vincoli ha pro e contro. I contro sono un aumento dii) complessità, ii) requisiti di memoria, iii) informazione di segnalazione, iv)instabilità; infine cammini più lunghi significano più risorse usate: è quindinecessario un compromesso tra il bilanciamento del carico e le risorse usate. Ipro sono una migliore efficienza d'uso delle risorse ed una migliore QdSpercepita dagli utenti. Da questo punto di vista un instradamento con vincoli ècomplementare agli schemi di controllo del traffico (e.g. IntServ e DiffServ) enon ad essi sostitutivo. In ogni caso vi è una sostanziale indipendenza nel mododi operare. Nel caso di DiffServ, il fatto di distribuire meglio il traffico aiutaDiffServ a lavorare meglio. Nel caso di IntServ, abbiamo detto che RSVP segueil percorso scelto dai protocolli di instradamento. L'allocazione delle risorse èeffettuata da RSVP, ma il messaggio di Path segue la strada decisa daiprotocolli di instradamento; se questi ultimi scelgono un percorso tenendo inconto le richieste di QdS sarà più probabile che RSVP riesca a stabilire unintero percorso con le caratteristiche richieste dall'utenza.

Nel caso di MPLS, l'instradamento con vincoli è indipendente dai percorsi(LSP) scelti da MPLS. L'instradamento con vincoli sceglie i suoi percorsi ed infunzione di questi MPLS sceglie i suoi. Quando però MPLS e l'instradamentocon vincoli sono usati insieme si aiutano a vicenda e costituiscono unostrumento molto potente a disposizione degli ingegneri del traffico.

IV.3.5� Conclusioni

Per concludere diamo prima una visione d'insieme [XIA99] di quantodescritto in dettaglio sinora e quindi proponiamo alcune considerazioni finali.

Gli utenti negoziano dei SLA con un ISP. Il SLA specifica i servizi chesaranno offerti all'utente. Un SLA può essere statico o dinamico. Nel primocaso l'utente può emettere informazione in qualsiasi momento, nel secondol'utente usa RSVP per chiedere servizi a domanda. All'ingresso di un dominioDS i datagrammi vengono classificati e marcati. All'interno del dominio i Corerouters implementano solo dei PHB e non scambiano messaggi di segnalazione.Alla frontiera tra diversi domini i datagrammi vengono ri-classificati e ri-marcati. Uno o più Bandwidth Bokers coordinano le entità di frontiera deidiversi domini e allocano le risorse, ma sempre con riferimento a flussiaggregati.

178

MPLS stabilisce dei percorsi (tunnel) tra opportune coppie origine-destinazione; all’ingresso di un dominio MPLS vengono generate le etichette edi campi COS dei pacchetti MPLS, sulla base della classificazione deidatagrammi e di politiche di gestione. All’interno di un dominio MPLS lacommutazione è effettuata solo sulla base dei campi MPLS; i campi contenutinei datagrammi IP non sono esaminati. Un router MPLS quindi non "vede"eventuali funzioni implementate nei campi dei datagrammi IP. L'intestazioneMPLS è rimossa all'uscita dal dominio MPLS. L'instradamento con vincolidetermina percorsi soggetti a requisiti di QdS e di politiche di gestione. Loscopo è di soddisfare i requisiti di QdS utilizzando nel contempoefficientemente le risorse di rete. Opportune unità di inter-lavoro devono esserepreviste tra sezioni di rete operanti con diversi paradigmi; ad esempio tra RSVPe DiffServ e tra DiffServ e MPLS.

Veniamo ora ad alcune considerazioni finali. Il termine complessità, comesvantaggio imputato a molte soluzioni proposte è ricorrente. In realtà, l’interaquestione della complessità, deve essere affrontata opportunamente. E’ noto cheInternet è nata come una piccola rete al servizio di enti accademici e di ricerca esi è poi enormemente sviluppata fino a raggiungere la situazione attuale. Nonbisogna però dimenticare che, nonostante tale sviluppo, la quantità di trafficotrattata dai router IP è ancora inferiore a quella relativa alle reti in areageografica (e.g., la rete telefonica), essendo proprio queste ultime a farsi caricocon i loro sistemi (non IP) del trasporto di una rilevante quantità di dettotraffico. Inoltre molte delle risorse di rete IP sono ancora di proprietà dimedio/piccole istituzioni e molte aree di utenza contribuiscono in modosignificativo alla gestione del traffico, ruolo questo che, nelle “classiche” reti ditelecomunicazioni è delegato ad operatori di rete con capacità logistiche efinanziare molto più rilevanti. Quest’ultimo punto è spesso stato indicato comeuno dei vantaggi di Internet, ma, come nel caso della modalità di trasferimentosenza connessione, ne costituisce attualmente un limite.

E’ infatti evidente che, quando si tratta di far evolvere i sistemi di rete persupportare servizi di una certa complessità, servendo una vasta popolazione diutenti, sono necessari investimenti e tempi di attuazione di una certa rilevanza.E’ chiaro allora come, quando un piccolo Internet Service Provider o addiritturauna piccola istituzione si trovino di fronte alla eventualità di dover sostituiretutti i loro router e collegamenti di rete con sistemi di capacità e costo moltosuperiori, essi tendano a giudicare pressoché tutte le soluzioni proposte cometroppo complesse.

179

Si pensi a come si potrebbe reagire se la rete telefonica mondiale oggi nonesistesse e qualcuno proponesse di implementarla dal nulla con tutto ciò checomporta: reti di accesso e di distribuzione, collegamenti di transito, centrali dicommutazione, sistemi di segnalazione e di gestione, etc. Chiunque direbbe chesi tratta di una soluzione troppo complessa!

Bene, l’evoluzione di Internet verso una inter-rete ad alta velocità congaranzie della qualità di servizio implica un ordine di complessità sicuramenterilevante e guarda caso si pone lo stesso obiettivo che i fautori della B-ISDN/ATM si erano posti. A parte delle differenze sia marginali che riguardantil’intera filosofia di funzionamento, una Internet evoluta nel senso primadescritto non è molto diversa dalla proposta B-ISDN/ATM, dal punto di vistadella complessità globale.

L’Internet attuale, infatti, non fa altro che cercare di sfruttare moltesoluzioni e sistemi già esistenti; ma, se si tratta di arrivare ad una rete a largabanda integrata nei servizi con garanzia della qualità di servizio, allora, lasoluzione basata su Internet potrà presentare dei vantaggi ma non è sicuramenteattuabile in modo semplice.

Il fatto è che le attuali reti in area geografica sono state poste in opera in unperiodo di tempo molto lungo e da operatori di rete con significative capacitàfinanziarie (spesso con l’aiuto diretto dei rispettivi Governi nazionali) consistemi di tariffazione e prospettive di sviluppo che giustificavano gliinvestimenti necessari.

Questo ci porta alla questione della tariffazione e delle opportunità diguadagno: finché si tratta di far evolvere una ristretta rete dedicataall’accademia, secondo le modalità sinora seguite, le soluzioni, a prescinderedai loro meriti tecnici saranno sempre considerate come troppo complesse. Seinvece, come sempre più appare essere il caso, esiste una domanda di servizi daparte di una vasta popolazione di utenti disposti a pagare per detti servizi, allorala questione della complessità deve essere in qualche modo rivista. Bisognaaccettare la prospettiva che creare una inter-rete con le caratteristiche sinoraevidenziate richiede necessariamente sforzi tecnici ed economici nontrascurabili, e non è questione che possa essere risolta con soluzioni tecnichemiracolistiche. Infatti, oggi non esistono infrastrutture di rete per supportarerilevanti quantità di traffico, a larga banda, con caratteristiche di multimedialitàe di configurazioni multipunto-multipunto e con garanzia della qualità diservizio.

In quest’ottica, considerando in qualche modo superata la questione dellacosiddetta eccessiva complessità delle soluzioni proposte, e venendo a questionipiù prettamente tecniche, un elemento importante è quello della divisione tra

180

rete di accesso e rete interna. Un altro elemento è la differenziazione di Internetin diverse sub-aree che, pur mantenendo la possibilità di inter-lavorare, sianocaratterizzate da diverse prestazioni, modalità di gestione, tipologia di apparatiusati ed opportune limitazioni di accesso.

Emerge quindi una visione di Internet per certi versi ancora più eterogeneadi quella attuale ma strutturata in modo tale che alcune sue aree sianointernamente più omogenee. In altre parole invece di avere un’eterogeneità“diffusa” si potrebbe mirare ad un’eterogeneità concentrata solo nelle differenzetra specifiche sub-aree. Qui, per sub-aree, non si fa necessariamente riferimentoad una porzione fisicamente e geograficamente limitata di Internet (ovvero aduna data sotto-rete) ma ad un suo sotto-insieme di tipo logico ed eventualmentegeograficamente distribuito.

Questa visione, di medio termine, è giustificata da diversi fattori adassunzioni fra i quali:

- difficilmente si convergerà verso una sola tecnologia di strato di“collegamento”: ATM non sostituirà tutti i sistemi attuali e continueranno adesistere diversi paradigmi di comunicazione che necessiteranno di potercolloquiare tra loro;

- TCP/IP sarà il minimo comune denominatore di Internet: tutti i sistemi adessa collegati potranno colloquiare grazie alle funzionalità di tali protocolli;l'indirizzamento e l'instradamento saranno quelli IP.

- all’interno di specifiche sub-aree, di dimensioni quindi più limitate rispettoall’intera Internet, si potranno implementare meccanismi per la Qualità diServizio (e.g. RSVP) senza eccessivi problemi di complessità e scalabilità;

- determinate sub-aree potranno essere costituite interamente da tecnologiesofisticate, come ATM;

- la sezione di accesso sarà quella che avrà le maggiori caratteristiche dieterogeneità e necessiterà di soluzioni per l’inter-lavoro;

- la sezione interna dovrà essere generosamente dimensionata in modo dagarantire una “Qualità di Servizio” accettabile a tutti e tale da non costituireun collo di bottiglia nel trasferimento di dati tra sub-aree di accesso consofisticate funzionalità e prestazioni;

- le sezioni di accesso potranno lavorare in accordo a diverse soluzioni, dallapiù semplice ed economica best-effort attuale, passando a schemi di tipoIntServ o DiffServ, per arrivare a reti ATM.

- la sezione interna potrà lavorare o in accordo al paradigma DiffServ e/oMPLS o ancora più semplicemente essere pesantemente sovra-dimensionata.

Per concludere si citano altri due punti di una certa importanza. Si è vistocome la soluzione MPLS e ATM non completo vadano verso la direzione di

181

una rete che sembra essere più di tipo permutato che non commutato, e proprioper questo sono più indicate nella sezione interna di rete. Infatti in quest’ultimail traffico risulta dall’aggregazione di numerosi utenti e presenta caratteristichestatistiche di minore variabilità e maggiore predicibilità (oltre a consentirepotenzialmente un maggiore guadagno di multiplazione).

Estremizzando le soluzioni di cui sopra si arriva a prospettare una sezioneinterna di rete che operi pressoché interamente in modalità permutata(sfruttando eventualmente tecniche di permutazione veloci e flessibili). Sequesto è il caso allora tale sezione può essere notevolmente semplificatasostituendo alle soluzioni di cui sopra una rete ad alta capacità, ATM permutatao addirittura SDH o WDM. Queste ultime soluzioni sono già state implementateda alcuni operatori.

Il secondo punto riguarda la questione della tariffazione. Non è dasottovalutare infatti che l’attuale tariffazione “flat rate”, applicata in modopreponderante in Internet, avrà sicuramente contribuito al suo sviluppo intermini di popolazione di utenti ma ne ostacola ora una ulteriore crescita da unpunto di vista qualitativo e di quantità di traffico supportato. Si puòargomentare che gli ISP non trovano una convenienza ad offrire servizi dimigliore qualità se questi non comportano maggiori guadagni. Nel caso in cuiuna rilevante frazione di utenti trovasse utile e fosse disposta a pagare in modoadeguato tali servizi, l’intera questione della complessità sarebbe certamenterivista in quanto l’implementazione di sofisticate risorse di rete avrebbe unagiustificazione economica che oggi sembra non avere, se non in misura limitatae comunque certo non tale da rivoluzionare l’intera Internet. Non va infinedimenticato che, nonostante lo sforzo impiegato dalla comunità scientifica neldefinire tutte le soluzioni sin qui presentate, esiste un approccio alternativo, chepotremmo definire di forza bruta. Non sono pochi, infatti, coloro i qualisostengono che si potrebbero evitare tutte le problematiche di complessità,semplicemente mediante un pesante sovra-dimensionamento delle risorse direte….

IV.4� IPv6

Il protocollo IPv4 è stato standardizzato nel 1981. Come sinora discusso, lesue caratteristiche hanno facilitato la ben nota diffusione di Internet, ma, anchea causa di questa enorme diffusione, IPv4 appare non essere più adeguato asoddisfare le accresciute esigenze dell'utenza. In particolare, si è detto che lamodalità senza connessione e lo schema di indirizzamento universale di IP nehanno determinato la semplicità implementativa ed hanno significativamente

182

contribuito allo sviluppo di Internet, ma proprio questi punti di forzacostituiscono oggi i principali limiti di IPv4 e richiedono di introdurre unanuova versione di questo protocollo. Infatti, la modalità best effort non consentedi fornire servizi con una prefissata qualità di servizio, mentre lo spazio diindirizzi di IPv4 è in via di esaurimento. La nuova versione di IP è denominataIP versione 6, IPv6 (la nomenclatura versione 5 era stata temporaneamenteassegnata ad un protocollo per il supporto di flussi con requisiti di tempo realeed è poi caduta in disuso). IPv6 è stato anche denominato per un certo periodocome "IP new generation", IPng.

Nel seguito esporremo le caratteristiche principali di IPv6, rimandando allerelative RFC o, ad esempio, a [GAI97], [STA96] per maggiori dettagli. Laproblematica del supporto di servizi con una prefissata qualità di servizio è statadiscussa in IV.3. La problematica dell'esaurimento dello spazio di indirizzi èstata invece accennata in III.4.3. In particolare si è detto che la scelta di unoschema di indirizzamento gerarchico può risultare in indirizzi non utilizzati equindi in sprechi. Gli indirizzi corrispondenti alla parte Host_Id di una data retelogica, non usati dall’organizzazione responsabile della corrispondente Net_Id,non possono essere usati da nessun altro; ciò spiega l’attuale penuria di indirizziIP, a fronte dei 3 758 096 384 indirizzi teoricamente disponibili per le prime treclassi e dei 2^32 (=4 294 967 296) possibili indirizzi totali; penuria questa chealtrimenti non apparirebbe comprensibile, visto che l'attuale numero di host èsicuramente inferiore a questa cifra (il numero di utenti di Internet dovrebbeessere di circa 300 milioni entro la fine del 2000). Va però detto che il numerodi utenti appare destinato a sestuplicarsi entro la fine del 2005.

Un altro fenomeno, destinato per altro a incidere profondamente sullaorganizzazione della nostra vita domestica e lavorativa, è rappresentato dalladiffusione di “utensili” informatici in aggiunta agli ormai tradizionali PC. Siprevede una esigenza di elaborazione “ovunque” (ricreativi, elettrodomestici,autoveicoli, controllori di traffico, ecc.) realizzata con “processori” e conassociati mezzi di comunicazione via Internet. La prospettiva è trasformare“prodotti” in “servizi”, consentendo una larga varietà di applicazionipersonalizzate. Si parla di un numero di “utensili” informatici che nel 2010potrebbe raggiungere la quota di un miliardo. A questi si aggiungono i terminalimobili, che, in prospettiva, richiederanno anch'essi un indirizzo IP.

Gli accessi ad Internet sono inoltre destinati ad assumere unaconfigurazione unificata per qualunque tipo di applicazione o di servizio (voce,dati, immagini, ecc.), magari supportati da un DNS evoluto che distingua il tipodi servizio richiesto, indirizzando una richiesta di comunicazione non soloverso un dato utente, ma anche verso uno specifico apparecchio di quell'utente

183

(cosa che in parte avviene già oggi). Ad esempio, un utente potrebbe essereidentificato globalmente da un opportuno nome. Un DNS evoluto potrebbeprovvedere sia a rintracciare l'attuale posizione dell'utente, (tramite Mobile IP,cfr. IV.5), sia a indirizzare una chiamata verso uno specifico tipo di terminaleappartenente a quell'utente: una chiamata vocale verso un telefono cellulare,una posta elettronica verso il calcolatore posizionato nel luogo di lavoro, unachiamata videotelefonica verso un opportuno terminale, etc.

La conseguenza ovvia di queste tendenze è un incremento vertiginosodelle esigenze di indirizzamento e quindi dello spazio di indirizzi di IPv6.

La comunità Internet era conscia di questo problema già da diversi anni;addirittura, nel 1991, si prevedeva l'esaurimento degli indirizzi di classe B nel1994. L'introduzione del classless interdomain addressing (o routing) (cfr. finedel III.4.5.3) ha alleviato il problema, rinviando tale esaurimento ad una datastimata (forse ottimisticamente) intorno al 2010, ma, come si è detto, questatecnica aumenta la complessità del'instradamento IP. La conclusione di questeconsiderazioni è che IP necessita di uno nuovo schema di indirizzamento.

IV.4.1� Caratteristiche generali

Una volta riconosciuta la necessità di cambiare il protocollo di rete diInternet, operazione sicuramente non semplice, si è deciso di introdurre anchealtri miglioramenti. Nel seguito elenchiamo gli obiettivi che IPv6 si prefigge, edinsieme le sue caratteristiche generali [GAI97], [STA96]. Circa lanomenclatura, IPv6 definisce con il termine "nodo" un qualunque dispositivoche implementa IPv6, sia esso un host o un router, mentre la sua unità di dati èdenominata "pacchetto", invece che datagramma.

IV.4.1.1 Nuovo piano di indirizzamento

Il piano di indirizzamento dovrà avere le seguenti caratteristiche:- introduzione di una gerarchia degli indirizzi che faciliti l'assegnazione degli

stessi e le operazioni di instradamento; se lo spazio di indirizzi èsufficientemente grande, l'assegnazione degli indirizzi risulta più semplice edè anche possibile che ogni sistema sia in grado di "autoassegnarsi" unindirizzo, evitando agli utenti le operazioni di configurazioni ed ottenendocosì capacità di "plug and play" (molto vantaggiose soprattutto per gli utentimeno esperti); un generoso dimensionamento dello spazio degli indirizziconsente anche di introdurre una gerarchia molto articolata, il che facilitanotevolmente il compito di individuare le strade.

- introduzione di diverse tipologie di indirizzi, ognuna delle quali pensata peruna specifica funzione;

184

- lo spazio di indirizzi dovrà avere una dimensione tale da non rischiare futuriesaurimenti, tenendo conto che una stima di diverse decine di indirizzi perogni abitante del pianeta non è irrealistica e che un indirizzamento gerarchicoconduce ad inevitabili sprechi.

In accordo a queste considerazioni, l'indirizzo di IPv6 è una stringa binariadi 128 bits. Gli indirizzi possibili diventano quindi 2128, con un incremento di unfattore pari a 296 rispetto a IPv4. Si tratta di un numero difficilmenteapprezzabile: si pensi che con IPv6 sarebbe possibile avere 665*10^21 indirizziIP per ogni metro quadro del pianeta (ed anche quest'ultimo numero risulta nonfacile da immaginare). Anche se tali indirizzi saranno assegnati in modo nonefficiente, la loro numerosità sembra sufficiente.

IV.4.1.2 Miglioramenti prestazionali

L'intestazione dell'unità di dati di IPv6 si compone di una parte "base"sempre presente e di una parte opzionale. L'intestazione base (denominata IPv6header) ha un numero di campi inferiore a quella di IPv4. Diverse funzionalitàdi IPv6 sono realizzate mediante campi opzionali che vengono aggiuntiall'intestazione nella parte, appunto, opzionale, solo quando sono realmentenecessari (questi campi opzionali sono denominati Extension Headers). Molti diquesti campi opzionali non sono esaminati necessariamente da tutti i nodiattraversati. Questa scelta semplifica e velocizza il trattamento dei pacchetti diIPv6, rispetto a IPv4 e ne aumenta la flessibilità, in quanto sarà più semplice infuturo aggiungere opzioni attualmente non previste. L'intestazione base di IPv6ha una lunghezza fissa, contrariamente a IPv4; la frammentazione dei pacchettiIP (cfr. III.4.2) è eseguita solo alla sorgente e non più in tutti i routerattraversati. Queste caratteristiche semplificano notevolmente il cosiddetto"critical router loop", ovvero quell'insieme di funzioni che riguardano iltrattamento base dei pacchetti e quindi tutti quei pacchetti che non hannorichieste particolari, se non quella di giungere a destinazione (attualmente lagran parte del traffico). E' questo insieme di funzioni quello che determina inmodo significativo le prestazioni dei router e quindi è opportuno semplificarloil più possibile. A titolo di raffronto, l'intestazione tipica di un datagrammaIPv4 è grande 24 bytes, di cui solo 8 sono usati per gli indirizzi e il resto dacampi che non sempre sono necessari. L'intestazione base di IPv6 è grande 40bytes di cui 32 sono usati per gli indirizzi.

IV.4.1.3 Supporto della qualità di servizio

IPv6 dovrà consentire di associare ogni pacchetto ad una determinataclasse di servizio. Ogni pacchetto dovrà essere quindi trattato dai sistemi

185

attraversati in modo da soddisfare i requisiti prestazionali della classe a cuiappartiene, introducendo opportuni politiche di disciplina di coda e di prioritàrelative. Un apposito campo dell'intestazione base di IPv6 (flow label) consentedi associare un pacchetto ad un dato flusso ovvero di identificare tutti ipacchetti che fanno parte di uno stesso flusso. Tale campo è usato per fornireservizi con una prefissata qualità di servizio (cfr. IV.3) (unitamente all’indirizzoIP di sorgente e di destinazione).

IV.4.1.4 Flessibilità nell'indirizzamento

IPv4 definisce due tipologie di indirizzi "unicast" e "multicast". A questetipologie IPv6 aggiunge quella di "anycast". Un indirizzo anycast è un indirizzodi gruppo a cui però risponde il nodo "più vicino" ad un nodo dato, dove ilconcetto di vicinanza è espresso in un'opportuna metrica. Questa tipologia diindirizzi è molto utile per individuare e quindi interrogare dei servers, siano essidefault router, name servers, time servers, etc e facilita le operazioni diconfigurazione dei nodi. IPv6 fornisce anche un meccanismo di indirizzamentounificato per Internet e per le Intranet, superando alcune soluzioni transitoriedefinite per IPv4. Sono previsti indirizzi di tipo globale, locale e indirizzi cheidentificano un singolo "link", ovvero un singolo collegamento (ad es., uncircuito diretto numerico, una porta di un LAN switch, etc.). Gli indirizziglobali sono quelli con significatività nell'intera Internet, quelli locali sono usatiper nodi interni alle Intranet, mentre quelli di link sono usati dagli operatori perscopi di gestione e di generale funzionamento dell'Internet. Sono anche previsteclassi di indirizzi compatibili con indirizzi IPv4, OSI SNAP e Novel IPX;queste ultime classi di indirizzo facilitano l'inter-lavoro di IPv6 con taliparadigmi (si pensa che tale inter-lavoro sarà necessario solo in un periodo ditransizione, dopo il quale tutto il traffico dovrebbe convergere verso IPv6).

IV.4.1.5 Facilitazione della conversione tra indirizzi IP e indirizzi locali (ARP)

Si è detto che il problema di tradurre indirizzi globali IP in indirizzi localiè risolto in IPv4 o mediante interrogazioni diffusive o mediante interrogazionidi opportuni servers (cfr. par. III.4.4). Una comunicazione diffusiva è ricevutada tutti i sistemi presenti. Ciò causa inefficienza. IPv6 semplifica questafunzione ricorrendo in alcuni casi ad interrogazioni di tipo multicast invece chebroadcast.

IV.4.1.6 Facilitazione della configurazione dei nodi (plug and play)

La configurazione di un host connesso ad Internet non è oggi banale, perun utente non esperto. Occorre fornire l'indirizzo IP dell'host stesso, lamaschera di sotto-rete, l'indirizzo del router di default e del name server. Nel

186

caso di utente connessi ad Internet tramite un ISP, queste informazioni vengonogeneralmente fornite dall’ISP stesso (cfr. fine del III.4.4).

Si è anche detto (cfr. III.4.3) che nel caso di indirizzi IPv4, invece di usarela notazione binaria si può usare una notazione decimale. La notazione inquestione si ottiene separando i 32 bits in 4 campi di 8 bits ciascuno; questicampi si esprimono poi in decimale invece che in binario, separandoli con unpunto. Ad esempio l’indirizzo IP di un particolare sistema, espresso in unastringa di 32 bits e nella relativa notazione decimale è:

10010111 01100100 00001000 00010010

151. 100. 8. 18

Nel caso di IPv6 si usa un accorgimento analogo; i 128 bits dell'indirizzovengono considerati come 8 numeri interi senza segno, ognuno di 16 bit;ognuno di questi numeri è scritto in esadecimale e separato dal precedente conil segno ":". Un indirizzo IPv6 espresso in questa notazione potrebbe essere adesempio:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210La notazione esadecimale è sicuramente più semplice rispetto ad una

stringa binaria di 128 bits, ma ciononostante risulta molto complesso epotenzialmente fonte di errori configurare manualmente dei nodi, usandoindirizzi così lunghi. IPv4 aveva già introdotto dei meccanismi per laconfigurazione automatica degli host (e.g., Dynamic Host ConfigurationProtocol, DHCP). IPv6 rende ancora più sentita l'esigenza di tali meccanismi ene definisce nuove versioni che consentono la configurazione automatica deglihost (anche per ciò che attiene ai loro nomi, tramite un'interazione con il DNS).

IV.4.1.7 Funzioni di sicurezza

Nell'attuale Internet, funzioni di sicurezza possono essere implementate suuna base da estremo a estremo (e.g., Secure Socket Layer, SSL), ma la retestessa non le fornisce. IPv6 introduce, in rete, sia funzioni di autenticazione(che accertano l'identità degli utenti) che di crittografia (che proteggono daascolti non desiderati). In altri termini, è la rete a fornire comunicazioni sicure,anche in assenza di appositi meccanismi implementati nei sistemi terminal.

IV.4.1.8 Supporto della mobilità

Questo tema è trattato in IV.5. Qui accenniamo solo che in IPv4 ilsupporto della mobilità è realizzato mediante l'aggiunta di protocolli ad hoc(Mobile IP). In IPv6 si vorrebbe invece che fosse lo stesso protocollo IP a

187

fornire, se non in modo completo tale funzionalità, almeno degli strumenti chefacilitino la mobilità di utente.

IV.4.1.9 Transizione da IPv4 a IPv6

Questa è una delle problematiche più delicate. Più volte nel corso di questatrattazione si è sottolineato che la cosiddetta "backward compatibility" è unelemento chiave nel giudicare la bontà di una nuova soluzione e che moltesoluzioni, seppure valide, non hanno avuto successo perché troppo complessarisultava la migrazione da un protocollo ad un altro.

A titolo di aneddoto, si tenga conto che la rete ARPANET originariausava, al posto di IP, un protocollo denominato Network Control Protocol. Nel1983 il Dipartimento della Difesa degli Stati Uniti decretò la sostituzione delNetwork Control Protocol con TCP/IP mediante una transizione di tipo “flagday”, ovvero contemporanea in tutti i nodi di rete. I nodi coinvolti eranoabbastanza pochi e sicuramente non paragonabili e quelli dell'Internet attuale,eppure la transizione fu molto complessa e pose molti problemi. Si pensi a cosasignificherebbe sostituire i protocolli nell'Internet attuale in un solo giorno!

Infatti, anche se si vuole cambiare "solo" la versione del protocollo e nonl'intera filosofia di funzionamento del protocollo stesso, l'entità delle modifiche,tra le quali soprattutto il piano di indirizzamento, richiede di pianificare conattenzione il passaggio dalle versione 4 alla 6. In particolare si è prevista nonuna transizione di tipo "flag day" ma una transizione di tipo graduale può essereattuata, ad esempio, mediante un "dual stack" (pila protocollare duale); alcuninodi di rete implementeranno contemporaneamente le due versioni in modo daconsentire un transitorio dalla durata di diversi mesi, se non di anni. In altreparole, alcuni sistemi di rete cominceranno ad implementare IPv6, insieme aIPv4. Opportune funzionalità consentiranno la coesistenza delle due versioni e,quando un significativo numero di sistemi disporrà di IPv6, il software di IPv4comincerà ad essere eliminato, finché rimarrà solo IPv6.

E' quindi evidente che uno dei fattori critici di questa migrazioneriguarderà le gestione contemporanea delle due versioni. Un datagramma IPv4o un pacchetto IPv6 saranno riconosciuti dai sistemi che li trattano mediante lalettura del campo Vers (cfr. III.4.1). Le unità dati di ognuna delle due versionisaranno consegnate al relativo "stack" o pila protocollare. Si noti infatti che ilcampo Vers e’ l’unico a conservare la stessa posizione nel pacchetto IPv6rispetto a IPv4: cio’ consente la discriminazione dei due protocolli. Il punto piùcomplesso riguarda la gestione degli indirizzi e gli instradamenti: un nodo conil dual stack userà IPv4 e indirizzi di 32 bits per comunicare con nodi IPv4,mentre userà IPv6 ed indirizzi di 128 bits per comunicare con nodi IPv6. Un

188

insieme contiguo di nodi che implementano IPv6 è denominato isola IPv6.Affinché tale approccio possa funzionare è necessario che le isole IPv6 (chesaranno, almeno nelle fasi iniziali appunto "isole" in un"mare" di sistemi IPv4),siano tra loro interconnesse. Tale interconnessione sarà realizzata, ad esempio,mediante dei "tunnel" nell'Internet attuale e quindi in IPv4. Cioè un pacchettoIPv6 sarà incapsulato all'interno di un datagramma IPv4 e da questi trasportato,rendendo quindi possibile l’instradamento di tale pacchetto nella attualeInternet (cfr. IV.5.4). Il numero di isole IPv6 crescerà fino a consentirel'interconnessione diretta di alcune di esse, senza il bisogno di usare tunnel. Glihost IPv6 avranno poi la possibilità di comunicare con host IPv4 tramiteun'opportuna classe di indirizzi IPv6, basata sull’inserimento di un indirizzoIPv4 all'interno di un indirizzo IPv6, in cui sono posti a zero i primi 128-32=96bit dell’indirizzo IPv6 (cfr. IV.4.4). Il numero di sistemi con IPv6 cresceràsempre più, finché i sistemi con IPv4 perderanno la possibilità di essereconnesse direttamente ad Internet [GAI97].

Nonostante tali accorgimenti la complessità di questa migrazione è tale chead oggi il numero di sistemi con IPv6 è ancora molto limitato ed è costituito perlo più da soluzioni sperimentali. Recentemente l'IETF si è espressaraccomandando con forza la transizione ad IPv6, sottolineando che:

- lo spazio di indirizzi di IPv4 si sta esaurendo ad un velocità superiore aquella sinora prevista

- secondo molte previsioni è probabile che nel 2010 tutto il traffico mondialesia "pacchettizzato" e che usi come protocollo di rete IP, incluso il trafficodelle attuali reti telefoniche (previsione forse ottimistica per IP)

- il bisogno di servizi con requisiti di tempo reale è sempre più sentito.

Dopo aver introdotto le caratteristiche generali di IPv6, ne descriviamo orale principali modalità operative.

IV.4.2� Terminologia

La terminologia utilizzata da IPv6 differisce, in parte, da quella relativa aIPv4. E' opportuno quindi riportare alcune definizioni, anche perchécontengono delle sfumature indicative del diverso approccio seguito da IPv6rispetto a IPv4.� un “Nodo” è ogni dispositivo che implementa IPv6;� un “Router” è ogni Nodo che inoltra pacchetti IPv6 non esplicitamente

indirizzati ad uno dei suoi indirizzi IPv6;� un “Host” è ogni Nodo che non è un Router;� si definisce “Strato Superiore” (in inglese “upper layer”) uno strato

189

protocollare immediatamente sopra IPv6, ad esempio i protocolli di trasportoTCP e UDP, i protocolli di controllo come ICMP, i protocolli diinstradamento come OSPF e tutti i protocolli (sia Internet che di stratoinferiore) che vengono inviati attraverso “Tunnel” protocollari (ovveroincapsulati in IPv6) ad esempio: IPX, AppleTalk o lo stesso IPv6;

� si definisce “Link” un mezzo di comunicazione usato da un Nodo pertrasferire informazione; il relativo strato protocollare è quello di link, ovverolo strato immediatamente sottostante IPv6. Esempi di link sono: retiEthernet, collegamenti PPP, X.25, Frame Relay, o reti ATM., ma anche deicollegamenti basati su tunnel attraverso IPv6 o IPv4;

� si definiscono “Vicini” (Neighbor) i nodi connessi allo stesso link;� si definisce “Interfaccia” il punto di connessione di un Nodo ad un link;� si definisce “Indirizzo” un identificatore di strato IPv6 di una interfaccia o di

un insieme di interfacce;� si definisce IPv6 header, la parte base dell'intestazione, sempre presente in

un pacchetto;� si definisce Extension Header una parte addizionale dell'intestazione,

presente solo opzionalmente e dedicata a specifiche funzioni.

IV.4.3� Formato dell'unità di dati

Il pacchetto IPv6 è progettato in modo da essere analizzato e processato ilpiù velocemente possibile dai Router IPv6. A tal fine ed a differenza deidatagrammi IPv4 che hanno un header di lunghezza variabile, in IPv6 l’header èstata suddiviso in due parti, una di lunghezza fissa che contiene lo "strettonecessario" ed una di lunghezza variabile (eventualmente anche assente)contenente ulteriori informazioni. Il pacchetto IPv6 ha dunque la strutturariportata in Fig. 43.

V P F L NHeader (Obbligatorio) Estensioni (Opzionali) Payload

Fig. 43 - Formato generale del pacchetto IPv6.

Passiamo ora ad analizzare in dettaglio i componenti dell’intestazione,iniziando dalla parte obbligatoria dell’header (Fig. 44):

190

Versione Priorità Flow LabelPayload Length Next Header Hop Limit

Source Address

Destination Address

Fig. 44 - Formato della parte base dell’header IPv6.

Il significato e la dimensione dei campi sono i seguenti:Versione (4 bits): Contiene il valore 6, per distinguere i pacchetti che

usano il protocollo IPv6 da quelli IPv4. Tale distinzione èpero tipicamente attuata mediante un opportunoidentificatore dell’unità di dati dello strato inferiore chetrasporta il pacchetto.

Priorità (4 bits): Consente ad una sorgente di associare ai pacchettiemessi un codice che rappresenta la classe di servizio e lapriorità relativa del pacchetto all’interno della classe. Almomento sono definiti due gruppi di classi di servizio: concontrollo di congestione, come ad esempio il traffico TCP,e senza controllo di congestione, ad esempio traffico UDP.All’interno di ciascuna classe di servizio sono poi definitidiversi livelli relativi di priorità,; tali livelli di prioritàservono a classificare il traffico; questa informazione potràpoi essere utilizzata dai Router per ottimizzare il trasportodei pacchetti (e per prendere opportune decisioni riguardoalle modalità con cui servire i pacchetti, soprattutto in casodi congestione).

Flow label (24 bits): Quando questo campo è diverso da zeroidentifica, insieme al campo Source Address, un flusso. Ilprotocollo IPv6 non da istruzioni specifiche riguardo acome comportarsi in base all’etichetta di un pacchetto: ècompito di altri protocolli gestire questo campo ecoordinarne l’utilizzo tra i vari Router. Anche la scelta delleetichette da associare ai flussi (operazione eseguita dallasorgente) può essere fatta in accordo ad apposite regole.

191

Tutti i pacchetti associati allo stesso flusso dovranno averecaratteristiche comuni in modo tale che i Router nonabbiano bisogno di processare ogni volta l’interaintestazione del pacchetto prima di prendere delle decisioni,ma possano applicare direttamente le decisioni già prese pergli altri pacchetti appartenenti allo stesso flusso (cfr. IV.3).

Lunghezza del Payload(16 bits): Rappresenta la lunghezza del payload, in ottetti

Next Header (8 bits): Indica o il tipo dell’Extension Header successivo,se ne esiste uno, oppure il protocollo di strato superiore acui il pacchetto deve essere consegnato. È stato anchedefinito un valore speciale (59) per rappresentare lamancanza di un ulteriore Extension Header. E' unageneralizzazione del campo Protocol di IPv4.

Hop limit (8 bits): il campo Time To Live (TTL) di IPv4 è statoribattezzato Hop Limit; ricordiamo che in IPv4 la specificainiziale del campo Time to Live indicava quanto tempo undatagramma può rimanere all'interno della inter-rete.Quando un host genera un datagramma, inizializza questocampo con il valore del tempo concesso al datagrammastesso per attraversare l’inter-rete. Questo valore vienedecrementato da ogni router incontrato nel camminopercorso dal datagramma. Quando il valore di questocampo sarà nullo, il relativo datagramma verrà scartato.Questa tecnica impedisce ad un datagramma di viaggiareindefinitamente nella rete, se, a causa di errori, il suoinstradamento risultasse in un cammino chiuso o, in ognicaso, di evitare tempi di trasferimento eccessivamentelunghi. Già in IPv4, però, il valore di questo campo èattualmente definito non in secondi ma in “salti” (hops). Persalto si intende l’attraversamento di un router e quindi undatagramma può attraversare al massimo 256 routers primadi essere scartato. In IPv6 si adotta lo stesso approccio.

Source address (128 bits)Destinat. Address (128 bits): Questi due campi, contengono gli indirizzi IPv6

della sorgente e del destinatario. Come già sottolineato,questi indirizzi non identificano un sistema finale (un host oun Router), ma sono assegnati a delle interfacce di rete.Ciascuna interfaccia può avere più di un indirizzo

192

“unicast”, ma ogni indirizzo “unicast” è associato ad unsolo Nodo (ovviamente la corrispondenza, anche se nonbiunivoca, è necessaria al fine di far arrivare i pacchetti aldestinatario)

Veniamo ora agli Extension Header. Questi campi costituiscono una delleprincipali innovazioni nel formato dell’unità di dati di IPv6 e consentono digestire le funzionalità di rete più avanzate (dall’instradamento alla privacy);inoltre aggiungono flessibilità al protocollo, in quanto risulta semplice definirenuove funzionalità aggiungendo un Extension Header che lascia immutato ilresto del protocollo. Un altro aspetto importante è che ciascun ExtensionHeader può essere rintracciato rapidamente (e quindi processato in modoindipendente dagli altri), grazie al campo Next Header. Si noti che sial'intestazione base di IPv6 (IPv6 Header), che ogni Extension Headerdispongono di un campo Next Header, che identifica appunto l'ExtensionHeader successivo. L'unico Header sempre presente è quello base (IPv6Header); se a questo non ne seguono altri, il campo Next Header contienetipicamente l'identificativo del protocollo di strato superiore a cui il pacchettodeve essere consegnato (informazione analoga al campo "Protocol" di IPv4).Viceversa, se all'Header base seguono degli Extension Header, il campo NextHeader contiene un identificativo del prossimo Extension Header. Il processo siripete per ogni Extension Header presente fino all'ultimo, che riportal'identificativo del protocollo di strato superiore a cui il pacchetto deve essereconsegnato. Si noti che tutti gli Extension Header sono inseriti dalla sorgente epossono essere solo modificati ma non eliminati dai router intermedi.

Gli Extension Header sinora definiti sono i seguenti:Hop-by-Hop options Header: Definisce delle opzioni che, se presenti,

vanno processate da ogni Router attraversato dal pacchetto. Questa estensione èprogettata in modo tale da funzionare come “punto di inserimento” di istruzionida processare in ogni Router, quindi deve fornire anche informazioni su come ilRouter si deve comportare se non è in grado di gestire l’istruzione trasportata edeve inoltre poter specificare se durante il percorso le informazioni contenutenell’estensione possono cambiare. In questo caso è necessario escludere laverifica di questo campo dai sistemi di protezione e sicurezza, gestiti da estremoad estremo.

Routing Header: svolge una funzione simile a quella della Source RouteOption di IPv4. Contiene una lista di uno o più nodi intermedi attraverso i qualisi vuole che transiti il pacchetto; è caratterizzato anche da un campo che indicala lunghezza dell’Extension Header stesso, da un campo che ne specifica il tipo

193

ed infine da un campo che indica il numero di nodi presenti nella lista, ma chedevono ancora essere visitati. L’informazione relativa al tipo di Routing Headerè importante; finora è stato standardizzato il tipo 0. Usando questo tipo diRouting Header, l’indirizzo di destinazione non viene posto nel campoDestination Address dei pacchetti IPv6; al contrario in quest’ultimo campoviene posto l’indirizzo del prossimo Router elencato nel Routing Header,mentre l’indirizzo di destinazione viene posto come ultimo indirizzo della listanel Routing Header. La lista non viene consultata finché il pacchetto nonraggiunge la sua prima destinazione, a quel punto si consulta la lista perverificare se si è giunti a destinazione, in caso negativo si modifica di nuovo ilcampo Destination Address e si aggiorna il numero di nodi che devono ancoraessere visitati. Questo modo di procedere consente un aumento di efficienzarispetto all’esaminare il Routing Header sempre, ad ogni “salto”.

Fragment Header: Contiene informazioni per la frammentazione e la ri-aggregazione delle unità informative. È importante sottolineare che in IPv6tutte le funzioni di segmentazione e di riaggregazione sono effettuate daestremo a estremo (source e dest) e non coinvolgono i Router intermedi, che inquesto modo non si devono preoccupare di processare il contenuto deipacchetti, risparmiando capacità elaborative. Questo metodo di gestione dellasegmentazione comporta ovviamente che i nodi agli estremi conoscano, oalmeno abbiano a disposizione dei mezzi per scoprire, la minima MTUsupportata dal collegamento.

Encapsulating Security Payload Header: Questo è uno degli ExtensionHeader che consentono di gestire le questioni legate alla sicurezza. In IPv6 taliquestioni sono state tenute in considerazione come specifiche dello strato di rete(IP). In questo modo è possibile fornire un elevato grado di sicurezza anche alleapplicazioni che ignorano tali problematiche. Le questioni legate alla sicurezzapossono essere affrontate da due punti di vista: quello della autenticazione(“Authentication”) e quello della sicurezza. Nel primo caso, si vuole accertarel’identità di chi origina i pacchetti e la non manomissione da parte di terzi deglistessi; nel secondo si vuole proteggere l'informazione trasmessa da ascolti nondesiderati (privacy). L’Header ESP si occupa di quest’ultima funzionalità.

Authentication Header: svolge le funzioni di autenticazione accennatenel punto precedente

Destination Options Header: Contiene informazioni che possono essereesaminate solo dai nodi di destinazione (che possono essere sia il solodestinatario, che i Router esplicitamente inclusi nel Routing Header). Il formatoutilizzato per questo Header è lo stesso che si usa per l’hop-by-hop optionsHeader. Le “destination options” sono di fondamentale importanza per gestire

194

in modo agile i protocolli end-to-end; infatti, inserendo i messaggi di controllodi questi protocolli direttamente in una destination option è possibile evitarel’invio di un pacchetto di controllo ad hoc e separato, aumentando cosìl’efficienza del collegamento.

Gli Extension Headers devono essere inseriti nel seguente ordine,all’interno del pacchetto:

IPv6 Header: È la parte obbligatoria di ciascun pacchetto IPv6, comedescritto qui sopra. Viene ovviamente posta al primo posto in modo davelocizzare le operazioni di instradamento in tutti quei casi in cui i Router nondevono compiere nessuna modifica, né alcun tipo di processamento sullarestante parte del pacchetto IPv6.

Hop-by-Hop options Header: Questa parte opzionale della PCI, trasportadelle informazioni che, se presenti, devono essere esaminate da ogni Router cheprocessa il pacchetto. È quindi importante che tali informazioni sianoposizionate all’inizio del pacchetto IP.

Destination options Header 1: Contiene le sole opzioni che devono essereprocessate dal primo Router e da tutti i Routers elencati nel Routing Header.Viene posto prima dell’elenco dei nodi da attraversare (contenuto nel RoutingHeader) in modo da avere tempo per iniziare a processare le opzioni mentre siriceve il resto del pacchetto.

Routing Header: Viene inserito appositamente dopo le destination optionsin modo da segnalare quali nodi devono esaminare quest’ultime

Fragment Header: E’ gestito da estremo a estremo (vedi sopra); vienequindi posto nella parte finale dell’intestazione del pacchetto, dovendo essereanalizzato solo alla destinazione finale.

Authentication Header: Consente alla rete di autenticare l’intero pacchettoIP; essendo anche questo elemento gestito da estremo ad estremo, non puòessere usato per autenticare quei campi che possono essere modificati durante ilpercorso.

Encapsulating security payload Header: E’ utilizzato al fine di proteggereil pacchetto IP dal punto di vista della sicurezza (intesa come privacy), puòagire sia su tutto il pacchetto che sul solo payload e fornire sia riservatezza cheuna verifica dell’integrità informativa.

Destination options Header 2: Contiene le opzioni che non devono essereprocessate dai Routers intermedi ma solamente dalla destinazione finale.

195

La seguente figura (Fig. 45) mostra degli esempi di pacchetti IPv6. Nelprimo esempio è presente solo l'IPv6 header, che punta al protocollo TCP,ovvero comunica che il contenuto del payload del pacchetto deve essereconsegnato a tale protocollo di strato superiore. Negli altri due esempi sonopresenti degli Extension Header e l'intestazione globale del pacchetto è sempreconclusa con l'indicazione del protocollo TCP, come destinatario del payload.

Header IPv6

Next Header =TCP

Header TCP+

Data

Header IPv6 Routing Header

Next Header =Routing Header

Next Header =TCP

Header TCP+

Data

Frammento di:Header IPv6 Routing Header Fragment Header

Next Header =Routing Header

Next Header =Fragment Header

Next Header =TCP

Header TCP+

Data

Fig. 45 - Esempi di pacchetti IPv6

IV.4.4� Schema di indirizzamento

Gli indirizzi IPv6 sono lunghi 128 bit; tale dimensionalità lascia unagrande libertà nella gestione della numerazione.

Nell’allocazione degli indirizzi IPv6 sono state tenute in considerazioneanche le necessità relative all’integrazione con diversi tipi di rete già esistentied il supporto per diversi tipi di indirizzi. Sono definite tre principali tipologiedi indirizzi: unicast, anycast e multicast; il loro significato è stato brevementeaccennato in precedenza. E’ stato anche detto che la maggiore dimensionalitàdello spazio di indirizzi consente di introdurre una gerarchia più articolata diquella relativa a IPv4 e quindi di facilitare le operazioni di instradamento. Ungenerico indirizzo IPv6 è quindi diviso in campi. Il primo campo è un prefissodi dimensione variabile, il cui significato è mostrato nella Tab. 13. Tale tabellamostra anche i possibili valori dei prefissi e la corrispondente frazione dellospazio totale dedicato ad indirizzi che iniziano con un certo prefisso.

196

Prefisso Frazione dellospazio di

indirizzamento

Allocazione

0000 0000 1/256 Riservato0000 0001 1/256 Non assegnato0000 001 1/128 Nsap0000 010 1/128 Ipx0000 011 1/128 Non assegnato0000 1 1/32 Non assegnato0001 1/16 Non assegnato001 1/8 Non assegnato010 1/8 Indirizzi Unicast basati sul provider011 1/8 Non assegnato100 1/8 Riservato per indirizzi Unicast su base geografica101 1/8 Non assegnato110 1/8 Non assegnato1110 1/16 Non assegnato1111 0 1/32 Non assegnato1111 10 1/64 Non assegnato1111 110 1/128 Non assegnato1111 1110 0 1/512 Non assegnato1111 1110 10 1/1024 Indirizzi per uso Locale al link1111 1110 11 1/1024 Indirizzi per uso Locale al sito1111 1111 1/256 Indirizzi Multicast

Tab. 13 – Schema di allocazione degli indirizzi

Gli indirizzi il cui prefisso è costituito dal valore 1111 1111 sono indirizzidi tipo multicast. Un indirizzo multicast identifica un insieme di interfacce. Unpacchetto indirizzato ad un indirizzo multicast viene consegnato a tutti i nodifacenti parte di tale insieme, ovvero a tutti i membri di un “gruppo multicast”.Oltre alla tipica funzione di comunicazione per servizi di utente punto-multipunto (già definita in IPv4), in IPv6 gli indirizzi Multicast sostituisconoquelli “broadcast” in alcuni funzionalità gestionali.

Si è detto che in IPv4 si usano comunicazioni diffusive (ovvero broadcast)per alcune funzionalità di rete (ad es. risoluzione di indirizzi, ARP) è che talemodalità genera inefficienze in quanto una comunicazione diffusiva è ricevutada tutti i sistemi presenti, anche da quelli che non sono potenzialmenteinteressati. IPv6 semplifica questa funzione ricorrendo ad interrogazioni di tipomulticast invece che broadcast. In tal modo le interrogazioni sono ricevute solodall'insieme di nodi che hanno effettivamente necessità di riceverle e che sisono registrati a tal fine. Inoltre, se esiste la necessità di comunicareinformazioni a tutti i nodi presenti su un dato link o in una data sotto-rete, IPv6

197

può definire un indirizzo multicast che consente di raggiungere tutti i nodipresenti su quel link o su quella sottorete.

Gli indirizzi che iniziano con un prefisso diverso da 1111 1111 sonoinvece di tipo unicast o anycast.Un indirizzo di tipo Unicast identifica una interfaccia di un Nodo. Sono statidefiniti diversi tipi di indirizzi Unicast:� indirizzi "basati" sul provider: sono assegnati in base al provider a cui un

nodo fa riferimento; sono indirizzi con significatività globale. Dopo ilprefisso sono presenti cinque diversi campi:

- Registry ID: identifica l'autorità di registrazione che attribuisce ilcampo Provider ID dell'indirizzo ad uno specifico Provider

- Provider ID: identifica uno specifico provider che attribuisce poi ilcampo Subscriber ID dell'indirizzo

- Subscriber ID: identifica un utente del provider descritto dal campoProvider ID

- Subnet ID: identifica un insieme contiguo di nodi dell'utente descrittodal campo Subscriber ID

- Interface ID: identifica una singola interfaccia di nodo appartenenteall'insieme contiguo di nodi descritto dal campo Subnet ID.

� indirizzi Unicast su base geografica: sono assegnati all'utente in base alla suaposizione geografica, al momento non sono stati definiti in dettaglio.

� indirizzi locali al link: hanno significatività locale e non possono essereintegrati nello schema di indirizzamento globale; vengono quindi usati percomunicare all’interno di un link o di una sottorete, tipicamente per fini diauto-configurazione e di ricerca di nodi vicini (neighbor discovery)

� indirizzi locali al sito: hanno significatività locale e non possono essereintegrati nello schema di indirizzamento globale; vengono quindi usati soloper comunicare all’interno di un determinato dominio; rispetto ai precedentihanno però il vantaggio che, previa solo la sostituzione di opportuni prefissi(introducendo ad esempio la gerarchia dei prefissi "basati" sul provider)possono acquisire significatività globale. Questi indirizzi sono quindi indicatiper dei nodi di un'organizzazione che, in una prima fase, non sono connessialla Internet globale ma che in prospettiva intendono esserlo.

Altri indirizzi Unicast hanno il prefisso 0000 0000 (designato come"riservato" e da non confondere con la dizione "non assegnato"). Tali indirizziincludono le seguenti tipologie:� indirizzi IPv6 compatibili IPv4: sono indirizzi pensati appositamente per

gestire la lunga transizione tra IPv4 ed IPv6 e sono costituiti da 96 zeri seguitidai 32 bit dell’indirizzo IPv4. In questo modo è molto semplice utilizzare dei

198

tunnel in IPv4: l’indirizzo IPv4 di uscita del tunnel può essere dedottodall’indirizzo IPV6.

� indirizzo loopback: questo indirizzo (0:0:0:0:0:0:0:1) viene utilizzato dalNodo IPv6 per inviare pacchetti a se stesso (per scopi gestionali, i.e., diprova); pacchetti con questo indirizzo non devono mai essere inviati al difuori dal singolo Nodo.

� Indirizzo non specificato (0:0:0:0:0:0:0:0): indica l'assenza di un indirizzo,non deve mai essere assegnato ad un interfaccia e può essere usato comeindirizzo mittente di un nodo in fase di auto-configurazione.

Sono anche previste classi di indirizzi pensati per facilitare l'inter-lavorocon indirizzi ISO/OSI NSAP (Network Service Access Point) (con prefisso0000 001) e Novel IPX (con prefisso 0000 010); tali indirizzi sono derivati daquelli NSAP o IPX in modo analogo a quanto appena descritto con riferimentoagli indirizzi IPv4.

Un indirizzo anycast è un indirizzo di gruppo a cui però risponde solo ilnodo "più vicino" ad un nodo dato, dove il concetto di vicinanza è espresso inun'opportuna metrica. Un indirizzo di tipo Anycast identifica quindi un insiemedi interfacce tra loro alternative (i pacchetti sono però inviati solo ad una diqueste interfacce). Gli indirizzi Anycast sono scelti all’interno dello stessospazio di indirizzi scelto per gli indirizzi unicast, è compito dei Router non solosapere che ad un determinato indirizzo anycast corrisponde un certo insieme diindirizzi unicast, ma anche di scegliere, secondo la metrica prescelta, il più“vicino”. Gli indirizzi con la dizione "non assegnato" in Tab. 13, non sonoancora stati definiti.

In conclusione, sottolineiamo solo che la gerarchia appena discussa, ed inparticolare quella relativa agli indirizzi basati sul provider e quelli assegnati subase geografica, consentono, grazie alla presenza di diversi livelli gerarchici, difacilitare significativamente le operazioni di instradamento.

IV.5� Mobile IP

Mobile IP è stato progettato per soddisfare i bisogni della crescentepopolazione di utenti di calcolatori portatili che desiderano collegarsi adInternet, anche quando mutano la loro posizione geografica. Negli ultimi anni siè assistito infatti ad una crescita del numero di tali calcolatori (laptop enotebook), che divengono sempre più potenti, eguagliando in capacità dielaborazione molti sistemi fissi.

E' inoltre ben nota la costante crescita del mercato dei dispositivi percomunicazioni senza filo (wireless). Seppure sino a qualche tempo fa la gran

199

parte di essi era dedicata a servizi voce, la tendenza è che gli attuali terminalievolvano per consentire una sempre più piena connettività ad Internet. Ilpercorso di evoluzione parte dai terminali GSM, arricchiti in una prima fase dalprotocollo Wireless Application Protocol, WAP (che consente un accesso adInternet semplificato). In un secondo tempo, la disponibilità del sistema GeneralPacket Radio Service, GPRS consentirà una maggiore velocità di accesso,insieme ad un modo di trasferimento a pacchetto, aumentando così la flessibilitàe la convenienza di accesso ad Internet (essendo, tra l'altro, il traffico tariffatonon più a tempo, ma in base alla quantità di informazione trasferita). A mediotermine il processo si conclude con il sistema Universal MobileTelecommunications System, UMTS, che aumenta ancora la velocità e laflessibilità di accesso, nonché la tipologia dei servizi disponibili.

E più che probabile dunque che i terminali mobili costituiranno unasempre crescente frazione dei sistemi connessi ad Internet. E' quindi importanteintegrare il protocollo IP con funzioni per il supporto della mobilità. Nel seguitoviene descritto il protocollo di base di Mobile IP ed alcuni protocolli aggiuntivi;sono inoltre poste in evidenza le procedure per l’ottimizzazionedell’instradamento (route optimization) e ulteriori argomenti di attualitàcorrelati con Mobile IP. Per maggiori dettagli si rimanda, oltre che alle relativeRFC (RFC2002, 2003-2006), ad esempio a [PER97], ed ai riferimenti ivicontenuti.

Prima di descrivere Mobile IP si ritiene utile premettere alcuneconsiderazioni generali circa il concetto di mobilità.

IV.5.1� Il concetto di mobilità

La tematica generale dei sistemi di telecomunicazione mobili è al di fuoridegli scopi di questa trattazione. Diamo quindi nel seguito solo alcuni concettigenerali, utili alla comprensione della tecnica Mobile IP; in particolareintroduciamo i concetti di: i) mobilità di terminale; ii) portabilità; iii) mobilitàpersonale.

IV.5.1.1 Mobilità di terminale

Il termine mobilità ha diverse accezioni, nelle attuali reti ditelecomunicazioni. Una prima accezione riguarda la cosiddetta mobilità diterminale, ovvero la possibilità di accedere ad un servizio di telecomunicazionemediante un terminale senza fili; tale tipologia di terminale consente all’utenteuna certa capacità di movimento. La situazione più semplice è quella in cui unterminale mobile può connettersi via radio con una sola stazione base(denominata stazione radio-base). Quest’ultima può eventualmente essere

200

connessa ad una rete fissa e quindi consentire all’utente di mettersi incomunicazione con utente appartenenti a tale rete fissa. Un esempio di questasoluzione è costituito da un telefono senza fili (cordless), la cui corrispondentestazione radio-base è connessa alla rete telefonica fissa. E’ evidente che quandoil terminale esce dalla zona di copertura della stazione radio-base l’utente nonha più modo di comunicare (qui e nel seguito per “zona di copertura”intendiamo una area geografica all’interno della quale la qualità del segnalescambiato tra terminale mobile e stazione radio-base è ritenuta sufficiente).

Questo caso non rappresenta una vera rete mobile, ma semplicemente unaestensione delle modalità di accesso ad una data rete fissa, mediante unsegmento radio che appare all’utente come un semplice “filo” virtuale,continuazione di quello fisso relativo al suo attacco di utente. In altri termininon vi sono funzionalità di commutazione e di instradamento aggiuntive; dalpunto di vista della rete telefonica nulla è cambiato.

Le ben note reti telefoniche cellulari (di cui il sistema GSM costituisce unodegli esempi più importanti) sono un’estensione della situazione appenadescritta. Nel seguito descriveremo brevemente i principi generali di tali reti. Atal fine prenderemo a prestito alcuni termini ed alcune funzionalità del GSM;tuttavia le procedure descritte ed alcuni relativi termini non rispecchianoesattamente quelli del GSM, ma ne sono una versione semplificata.

La copertura di un certo territorio è realizzata mediante un certo numero distazioni radio-base. Un dato terminale di utente si connette ad una determinatastazione radio-base e, tramite questa, accede ai servizi di telecomunicazionedesiderati. La scelta di una particolare stazione radio-base può esseredeterminata da diversi criteri (principalmente sulla base della qualità delsegnale scambiato tra terminale e stazione radio-base). La stazione radio-base èpoi collegata sia alle altre stazioni radio-base che, eventualmente, a reti fisse,mediante opportuni collegamenti, di cui non ci occupiamo. In tal caso la retedeve disporre di funzionalità di commutazione e di instradamento al fine diconsentire a chi origina una chiamata di raggiungere il destinatario voluto. Lestazioni radio-base sono tipicamente installate in modo tale da consentire unacopertura completa del territorio prescelto. Quando un terminale esce dalla zonadi copertura di una determinata stazione radio-base, entra nella zona dicopertura di una altra (o di più altre) stazioni radio-base.

Si supponga ora che un utente abbia iniziato una comunicazionetrovandosi nella zona di copertura di una stazione radio-base X. Se l’utente simuove, ma rimane sempre nella zona di copertura di X fino al termine dellacomunicazione, le altre stazioni radio-base non risultano coinvolte. In seguitoun utente può dare origine ad un’altra chiamata nella zona di copertura di

201

un’altra stazione radio-base, ripetendo la situazione appena descritta. Se invecel’utente, durante una comunicazione, nel muoversi, esce dalla zona di coperturadi X, per entrare in quella di un’altra stazione Y, si pone il problema di“trasferire” la comunicazione dalla stazione radio-base X alla stazione radio-base Y. I due estremi della comunicazione in atto (origine e destinazione,denomini nel seguito A e B) rimangono invariati, essendo uno di questi ilterminale mobile in oggetto (A) e il secondo un altro terminale (B) che puòessere sia un terminale mobile che un terminale appartenente ad una rete fissaposta in corrispondenza con le stazioni radio-base.

Cambia invece il percorso seguito dalla informazione scambiata: talepercorso, in una prima fase, passa attraverso la stazione radio-base X, mentre inuna seconda fase della comunicazione passa attraverso la stazione radio-base Y.Ad esempio, la Fig. 46 mostra due zone di copertura X e Y, le relative stazioniradio-base, un terminale mobile A, un terminale fisso B ed alcuni collegamentie sistemi che pongono in comunicazione tra loro le stazioni radio-base. I sistemiindicati con la lettera N seguita da un numero rappresentano dei nodi di rete(commutatori). In questa figura è possibile vedere come il percorso seguitodell'informazione per andare da A a B (ipotizzato per semplicità uni-direzionale) debba cambiare nel passaggio dalla zona di copertura X a quella Y.Infatti in una prima fase il percorso coinvolge i sistemiA->X->N1->N2->N3->N4->B

In una seconda fase il percorso seguito è invece:A->Y->N5->N4->B

202

��

A

B

X Y

Y

X

H

N1

N2

N3

N4

N5

Fig. 46 - Esempio di handover

Se si vuole evitare che la comunicazione in atto sia interrotta nel passaggioda una zona di copertura all’altra, occorre predisporre opportune funzionalità.L’operazione di “passaggio” della comunicazione da una stazione base all’altraè definita “handover”. Un handover richiede in generale l’esecuzione di diverseoperazioni, sia da parte del terminale, sia da parte delle stazioni-radio basecoinvolte, sia da parte di opportuni sistemi di rete. In particolare, occorremonitorare continuamente sia la qualità del segnale scambiato tra il terminale ela stazione radio-base che si sta usando in un dato momento (stazione X), sial’eventuale presenza del segnale emesso da altre stazioni radio base (e.g., Y). Intal modo, quando la qualità del segnale scambiato tra terminale A e stazione Xscende al di sotto di una certa soglia, e nel contempo ci si accorge che un’altrastazione base, Y, consentirebbe di scambiare informazione con una qualitàsuperiore, si effettua un handover tra stazione X e quella Y.

Ciò implica chela stazione Y debba predisporsi ad accogliere la chiamata che gli

viene trasferita da X, inoltrandone poi la relativa informazione versoil terminale B, con cui A era in corrispondenza;

- la stazione X cessi di trattare la chiamata;

203

- opportuni sistemi di rete tengano conto che il percorso seguito dallacomunicazione è mutato e quindi predispongano tutti i nodi coinvoltial fine di assicurare che lo scambio informativo tra A e B possaseguire il nuovo percorso.

Sempre con riferimento alla Fig. 46 , nell'intersezione tra le due zone dicopertura, il terminale mobile A è in grado di scambiare segnali con entrambe lestazioni radio-base e l'handover avviene in corrispondenza della lineatratteggiata, H.

E’ facile immaginare come la definizione delle complesse funzionalità diuna rete cellulare non si esaurisca nelle poche righe sin qui presentate. Adesempio la problematica dell’instradamento risulta più complessa che in retifisse. Infatti, nelle reti radio-mobile cellulari un indirizzo telefonico è incorrispondenza con un dato terminale, ma la posizione geografica diquest’ultimo varia nel tempo. L’algoritmo di instradamento deve quindistabilirne la localizzazione in modo dinamico, prima di poter scegliere unastrada attraverso la quale fargli pervenire una data informazione. Infatti, unnumero telefonico di un terminale cellulare non fornisce alcuna indicazione sudove esso si trovi in un certo momento.

Bisogna quindi che la rete conosca in ogni istante la posizione di ogniterminale, ovvero in quale zona di copertura esso si trova e da quale stazioneradio-base può eventualmente essere servito. Tale informazione è memorizzatain una opportuna base di dati. Ad esempio, nel sistema GSM, un unica base didati contiene sia dati riguardanti il profilo di utente che la sua attuale posizioneed è denominata Home Location Register (HLR). L'area in cui un dato utente sitrova in un dato momento è denominata area di localizzazione.

Quando si vuole effettuare una chiamata verso un certo terminale mobile ènecessario conoscere sia la sua attuale area di localizzazione che altreinformazioni che caratterizzano il terminale stesso (ad esempio informazioniche consentano di accertare l'identità del terminale, piani tariffari, etc.). Quandosi vuole effettuare una chiamata, si può quindi interrogare l'HLR e reperire tuttele informazioni volute.

Ciò implicherebbe però, in generale, un rilevante scambio di informazionedi segnalazione in quanto, per ogni chiamata, è necessario interrogare l'HLR etrasferire numerose informazioni. Per limitare tale scambio informativo è stataintrodotta un'altra entità logica, denominata Visitor Location Register (VLR).Nella rete sono presenti un certo numero di VLR; per semplicità assumiamo chead ogni area di localizzazione sia associato un VLR. Quando un terminale entraper la prima volta in una certa area di localizzazione, i suoi dati vengono copiatidal HLR al VLR dell'area "visitata" (da cui il nome).

204

Quando si vuole effettuare una chiamata verso un certo terminale, siinterroga l'HLR, che fornisce l'identificazione del VLR in cui il terminale èregistrato in quel momento. Gli altri dati necessari sono reperiti localmente nelVLR. Quando è invece il terminale in questione a voler effettuare una chiamata,esso non ha necessità di reperire i dati che lo riguardano nel HLR, in quantopuò trovarli nel VLR. Inoltre per comunicazioni iniziate e terminate in una areaservita da un certo VLR non è necessario interrogare l'HLR.

L’informazione di localizzazione è contenuta in tre luoghi: nel HLR, nelVLR e nel terminale. Questa informazione cambia nel tempo ed è quindinecessario mantenere una consistenza tra queste entità. Quando un terminalecambia area di localizzazione, le sue informazioni devono essere copiate nelVLR della nuova area di localizzazione e cancellate da quello vecchio.

Il cambiamento avviene normalmente quando il terminale decide dicambiare area di localizzazione; sono eseguite le seguenti procedure:

- aggiornamento della memoria del nuovo VLR a richiesta del terminale- aggiornamento della memoria dell’HLR a richiesta del nuovo VLR- cancellazione delle informazioni dal vecchio VLR a richiesta dell’HLR

Tale scambio di informazioni è descritto in Fig. 47:1 il terminale prende l’iniziativa del cambiamento di area di localizzazione e

comunica al nuovo VLR la sua presenza nella relativa area di localizzazione,Y;

2 il nuovo VLR notifica questo evento all’HLR (ovvero gli notifica che d'ora inpoi il terminale A si trova nella sua area di localizzazione e quindi se un altroterminale intende mettersi in contatto con A, l'HLR deve indirizzare larelativa chiamata verso l'area Y)

3 l’HLR cancella le informazioni di utente nel vecchio VLR4’ e ne riceve conferma4 in parallelo l’HLR dà conferma al nuovo VLR5 quest’ultimo dà conferma al terminale

205

HLR

Vecchio VLR,area X

3

4’

4

2

15

Area XArea Y

Nuovo VLR,area Y

A

Fig. 47 - Scambio di informazione in seguito ad una variazione della posizione del terminale

Quanto detto sinora completa la discussione dei principi generali di unarete radio-mobile, utili ai fini dell’introduzione di Mobile IP.

Tornando quindi a discutere di mobilità in senso generale, una ulterioreprecisazione riguarda le modalità secondo cui l’handover è operato. Inparticolare una procedura di handover può essere:� non avvertibile dall’utente (seamless handover): in tal caso i sistemi di rete

riescono a gestire il passaggio da una stazione radio-base ad un’altra senzache l’utente ne abbia percezione. Ciò tipicamente richiede che il nuovopercorso sia stabilito prima che il precedente sia abbattuto e quindi che esistaun certo intervallo di tempo in cui la rete mette a disposizione dell’utentedue percorsi di rete;

� avvertito dall’utente (handover non seamless): in tal caso l’utente percepisceuno scadimento della qualità di servizio durante l’handover (o perfino unabreve interruzione del collegamento), ma non è forzato ad interrompere lacomunicazione e ad iniziarne un’altra ex-novo.

E’ evidente che, in mancanza di una procedura di handover, l’utentesarebbe invece costretto a re-inizializzare la comunicazione in corso, quandomuta zona di copertura, con gli svantaggi che ciò comporta (ovvero la chiamatasarà terminata e quindi instaurata ex-novo).

Si noti che l’eventuale necessità di terminare forzatamente una chiamata, edi doverne iniziare una nuova quando si muta zona di copertura, è sicuramentefonte di fastidi per un servizio telefonico, ma può essere ancora più scomodaper un utente interessato ad applicazioni cosiddette di “mobile computing”,

206

come l’accesso di Internet. In tal caso l’utente dovrebbe ri-avviare l’ambiente dicomunicazione prescelto.

IV.5.1.2 Portabilità

Un’altra accezione del termine mobilità fa riferimento alla possibilità diaccedere ad una rete di telecomunicazioni da diverse locazioni fisse,mantenendo la propria identità, ed è più propriamente nota con il termine diportabilità. L’utente accede alla rete mediante sistemi con filo e dunque fissi,ma ha la possibilità di connettersi alla rete da qualunque punto di accesso,invece che da uno solo. Nell’Internet attuale, un host caratterizzato da undeterminato indirizzo IP può essere connesso solo tramite la sotto-rete a cuiquell’indirizzo appartiene (cfr. III.4). Ciò significa che se ad un calcolatore (siaesso portatile o da scrivania) è attribuito un certo indirizzo IP, quel calcolatorenon può essere spostato in un'altra locazione e quindi di nuovo connesso adInternet, a meno di non cambiarne l’indirizzo IP. In tal caso non è possibile, adesempio, recarsi ad una riunione di lavoro, fuori dalla propria sede abituale,portarsi un calcolatore portatile e ivi connettersi ad Internet. Un simile tentativodi connessione sarebbe rifiutato dalla sotto-rete di accesso “ospite”.

Disporre di funzioni di portabilità significa invece che una simileprocedura è permessa e quindi un utente può connettersi ad Internet tramitediverse reti di accesso in diverse locazioni geografiche.

Un’altra situazione di interesse è quella in cui un utente si connette adInternet usando come rete di accesso una rete mobile, magari cellulare. Peresemplificare supponiamo di disporre di un calcolatore collegato ad un modeme quindi ad un terminale mobile telefonico GSM, che si connetta ad Internettramite un Service Provider. A tal fine è necessario comporre il numerotelefonico del Service Provider e quindi eseguire le procedure legate all’accessoad Internet. In tal caso si può pensare che l’utente Internet disponga di unafunzione di mobilità piena, in quanto può muoversi liberamente e perfinocambiare zone di copertura mediante handover gestiti dal GSM stesso. In realtà,dal punto di vista di IP, l’utente non è mobile ma fisso. Infatti il “punto dientrata” in Internet non varia, al variare della posizione dell’utente, ma rimanesempre lo stesso, quello del Provider. L’intera rete GSM appare ad IP come unsemplice “link” di strato inferiore e l’indirizzo IP che identifica l’utente nonvaria nel corso di una sessione di comunicazione. Un tal modo di operare hasignificativi svantaggi.

Intanto richiede di effettuare sempre una chiamata telefonica verso ilproprio Provider, ovunque ci si trovi. Se, ad esempio, un utente è interessato

207

solo a funzioni di portabilità, e si reca in un'altra nazione, per accedere adInternet deve comporre il numero telefonico del proprio Provider, sostenendo icosti di una chiamata telefonica internazionale. Inoltre, anche a prescindere datali costi, tale modo di operare è inefficiente; se l'utente in visita in un'altranazione vuole accede ad un sito Internet locale, deve passare sempre attraversoil proprio Provider, seguendo così un percorso molto più lungo del necessario equindi sprecando risorse di rete.

Lo stesso accade se consideriamo un host dotato di un indirizzo IP stabile, invece che unhost a cui è il Provider ad attribuire un indirizzo IP (potendo essere quest'ultimo sia unindirizzo con significato globale attribuito in modo dinamico, sia un indirizzo con significatoesclusivamente locale, cfr. III.9). In tal caso, si può immaginare di installare un modemcollegato da un lato alla rete telefonica e dall'altro alla sotto-rete a cui appartiene l'indirizzostabile in questione; l'utente tramite una chiamata telefonica diretta verso quel modem accedead Internet tramite la "sua" sotto-rete e può sfruttare le funzioni di mobilità di una retetelefonica cellulare.

Inoltre, anche ammettendo che un utente possa accedere ad Internet tramiteun accesso messogli a disposizione da un’ente ospite (e quindi con un indirizzoIP diverso da quello proprio), l’utente stesso non vedrebbe riconosciuta la suaidentità dalla rete. Ciò implica che eventuali comunicazioni ad esso dirette nonlo raggiungerebbero nella sua nuova posizione, ma in quella originale. Questadisfunzione può non essere importante quando si accede ad Internet per reperireinformazioni o per consultare la propria casella di posta elettronica, ma diventagrave nel caso di servizi interattivi e/o con requisiti di tempo reale. Inoltre, perragioni di sicurezza, sempre più organizzazioni consentono l'accesso ai propriservizi solo ad host con determinati indirizzi IP (ovvero quelli appartenenti alleloro sotto-reti). Usare un indirizzo IP"ospite" impedisce quindi di usufruire didiversi servizi.

Poiché Internet intende offrire sempre più servizi interattivi (ad es.telefonia, vide-telefonia, etc.), e poiché le questioni legate alla sicurezzadivengono sempre più importanti, diventa fondamentale integrare IP confunzioni di mobilità.

IV.5.1.3 Mobilità personale.

Un'ultima distinzione tra le accezioni del termini mobilità è quella tramobilità di terminale e mobilità personale. Nei classici paradigmi dicomunicazione vi è la tendenza ad identificare un terminale con l’utente (o gliutenti) che ne fa (fanno) uso e l’indirizzo si riferisce al terminale ma anche, perestensione, all’utente. Il concetto di mobilità è stato però esteso dalla mobilitàdi terminale e cioè dalla possibilità di accedere ad un servizio di

208

telecomunicazione con un terminale in movimento (vedi sopra) alla mobilitàpersonale. Nel primo caso l’indirizzo è legato ad un terminale fisico;quest’ultimo può spostarsi da un luogo ad un altro ma permane un’associazionetra terminale ed utente, ovvero l’indirizzo è legato ad uno specifico terminale.Nel secondo caso (mobilità personale) l’indirizzo è legato all’utente che puòquindi "registrarsi" su diversi terminali, ovvero usare diversi terminalimantenendo la propria identità.

Il sistema GSM è un esempio di tale nuovo concetto di mobilità: un utenteè identificato da un indirizzo contenuto in una apposita scheda (SIM): inserendoquest’ultima in un terminale si personalizza il terminale stesso. Le chiamateindirizzate verso quell’utente saranno instradate sul terminale su cui l’utentestesso si è registrato e la tariffazione delle chiamate effettuate da un terminalesarà addebitata all’utente registrato su quel terminale.

Tale possibilità è in progetto di essere estesa anche alle reti non mobili: unutente potrà registrarsi su qualunque terminale, sia fisso che mobile, e la rete,per instradare l’informazione verso un dato utente, dovrà determinare su qualeterminale un dato utente è registrato, poi dove quel terminale si trova in queldato momento (se si tratta di un terminale mobile) e quindi scegliere una stradache porti a quel terminale.

IV.5.1.4 Conclusioni sul concetto di mobilità

Con queste premesse, possiamo tornare ad occuparci di Mobile IP.Dovrebbe essere ora chiaro come introdurre funzioni di mobilità a livello dellostrato IP può dare benefici all'utenza. Scopo base di Mobile IP è consentire adun utente di accedere ad Internet da diverse locazioni, mantenendo la propriaidentità, in modo tale che le comunicazioni dirette ad un dato utente sianoinstradate verso la posizione in cui quell'utente si trova in un dato momento.Sarebbe inoltre auspicabile che una comunicazione in corso non venisseinterrotta in seguito allo spostamento dell'utente, se questi usa terminali senzafilo. Infine è utile tenere presente che se si accede ad Internet tramite una retemobile (e.g., GSM) possono combinarsi due diverse gestioni della mobilità, adue strati protocollari diversi. A livello dello strato di "link", (tale il GSM èpercepito da IP), il GSM consente di cambiare area di localizzazione,mantenendo attiva la comunicazione, come spiegato sopra. A questo livello siaggiunge la gestione della mobilità a strato IP, che può intervenire,individuando un diverso "punto di accesso ad Internet, qualora ciò sia ritenutoopportuno. La mobilità IP può agire poi anche indipendentemente dall'uso diuna rete mobile, fornendo prestazioni di portabilità.

209

Il seguito di questa trattazione è organizzato come segue: iniziamo con ildescrivere le caratteristiche generali di Mobile IP (IV.5.2), introduciamo quindila relativa terminologia (IV.5.3), descriviamo le principali procedureprotocollari (IV.5.4) e concludiamo con i futuri sviluppi di questa tecnica(IV.5.5).

IV.5.2� Caratteristiche generali

Dalla trattazione precedente (cfr. III.4) è noto come gli indirizzi IP sianousati per identificare un determinato sistema terminale. Inoltre un indirizzo IP èsemanticamente equivalente al relativo "nome" o indirizzo mnemonico delsistema DNS. In altre parole, per identificare un particolare nodo tra le decine dimilioni di computer che costituiscono la rete Internet si può usare sia unindirizzo IP che il relativo indirizzo mnemonico (previa risoluzione diquest'ultimo tramite il DNS).

Gli indirizzi IP sono usati per individuare una strada tra origine edestinazione. L'indirizzo di destinazione è in corrispondenza con la posizionegeografica della destinazione, tramite le informazioni presenti nelle tabelle diinstradamento. Queste ultime sono infatti stabilite proprio a partire dallaposizione della sotto-rete a cui un dato indirizzo appartiene. La sotto-rete diappartenenza è denominata Home-Network (=rete di casa). Ne segue che non èpossibile accedere ad Internet tramite una sotto-rete diversa dalla propriaHome-Network, senza perdere la possibilità di essere rintracciati; inoltreopportune procedure protocollari proibiscono ad un host di usare il proprioindirizzo in sotto-reti diverse dalla relativa Home-Network.

Questo modo di operare è in conflitto con le funzioni di mobilità: da unaparte, un calcolatore mobile ha bisogno di avere un indirizzo IP stabile al fine diessere costantemente identificato e rintracciato dagli altri calcolatori di Internet;d’altra parte, se l’indirizzo è stabile, l'informazione è indirizzata sempre versolo stesso luogo e quindi non è possibile fornire mobilità. Il problema è risolto daMobile IP, che estende il protocollo IP attribuendo simultaneamente aicalcolatori mobili due indirizzi IP, uno per l’identificazione (stabile), l’altro peressere raggiunto quando si trova lontano dalla sua "Home-Network"(dinamico).

Mobile IP può essere considerato come l’unione di tre sottosistemiprincipali. Il primo, è un meccanismo di "scoperta" (discovery) del "secondoindirizzo", quello dinamico; quando un calcolatore si sposta dalla sua Home-Network va alla ricerca di un nuovo indirizzo che userà per le comunicazionieffettuate tramite altre sotto-reti.

210

Il secondo meccanismo consente, una volta che il calcolatore portatileconosca questo secondo indirizzo IP, (corrispondente al nuovo punto diconnessione), di comunicare alla Home-Network tale nuovo indirizzo e quindila corrispondente localizzazione.

Infine, Mobile IP definisce semplici meccanismi per consegnareinformazione al calcolatore portatile quando questo non è connesso alla suaHome-Network.

Prima di procedere diamo un cenno ad una tecnica alternativa per supportare laportabilità in Internet, senza modificarne eccessivamente i protocolli.

Tale tecnica si basa sul protocollo Dynamic Host Configuration Protocol (DHCP).DHCP attribuisce un indirizzo IP ad un nodo che ne fa richiesta e quindi consente anche acalcolatori lontani dalla Home-Network (o del tutto sprovvisti di un proprio indirizzo) diconnettersi ad Internet. Assumendo che il protocollo DHCP sia sufficientemente diffuso, sipotrebbe procedere come segue. Un calcolatore, in visita presso una data sotto-rete, interrogail server DHCP locale e si fa consegnare un indirizzo IP (indirizzo "ospite"). Ciò risolve ilproblema per le comunicazioni uscenti. Per quelle entranti, una possibile soluzione è quella disfruttare il DNS. In questa alternativa il calcolatore dopo aver ottenuto un indirizzo in qualitàdi ospite, comunica al DNS che l'associazione tra indirizzo mnemonico e indirizzo IP ècambiata e quindi se qualcuno chiede di contattarlo, tramite il suo nome, il DNS dovrà fornirel'indirizzo IP ospite invece che quello home (posto che ne possieda uno). Si noti che in talcaso il calcolatore deve essere ricercato obbligatoriamente tramite il suo nome e non tramitel'indirizzo IP. Ciò comporta significativi svantaggi:- le funzionalità fornite sono di portabilità ma non di mobilità, l'handover non può essere

seamless: se il calcolatore cambia posizione tutte le informazioni già inviate al precedenteindirizzo ospite andranno perse; in seguito ad un cambiamento di posizione occorrerà ri-avviare l'ambiente di comunicazione prescelto;

- TCP tiene traccia degli indirizzi IP sorgente e destinazione delle connessioni che gestisce.La conversione tra nome e indirizzo IP viene eseguita solo all’inizio della connessione. Sel'associazione tra nome e indirizzo cambia durante la connessione, la connessione stessaviene abbattuta. Lo stesso può accadere a strato applicativo: molte applicazioniidentificano un nodo Internet tramite il suo nome solo in una fase iniziale per poi usare ilrelativo indirizzo IP;

- La risoluzione tra nome e indirizzo è memorizzata (in cache) in molti sistemi dal DNS (cfr.III.4.7). Se tale associazione cambia nel tempo, tutti coloro che faranno uso di associazioniche nel frattempo sono mutate non riusciranno a rintracciare il destinatario voluto.

- La necessità di modificare l'associazione tra nome ed indirizzo pone problemi di sicurezzae di carico elaborativo al DNS. Il DNS si trova tipicamente nel cuore amministrativo delleaziende connesse in Internet, ogni protocollo progettato per modificare i dati in essopresenti dovrà essere estremamente ben progettato, implementato ed amministrato. Si puòcomunque essere certi che è necessario ancora molto lavoro prima che i responsabili di reteconsentano a migliaia (o milioni) di nodi mobili di manipolare i loro archivi. Sarànecessario tra l'altro completare alcune tecniche crittografiche che solo ora cominciano adessere standardizzate nell'ambiente DNS.

IV.5.3� Terminologia

Introduciamo le seguenti definizioni:Node: un host o un router.

211

Mobile-Node: un calcolatore che usufruisce di prestazioni di mobilità; unMobile-Node è in grado di continuare a comunicare conaltri nodi Internet, mantenendo la propria identità ed avendoun suo indirizzo IP stabile, indipendente dal suo "point ofattachment" ad Internet.

Correspondent-Node: un generico calcolatore con cui un Mobile-Node sta

comunicando. Un Correspondent-Node può essere siamobile che fisso.

Home-Address: un indirizzo IP univocamente e stabilmente assegnato adogni Mobile-Node; l'indirizzo stabile identifica globalmentein Internet il sistema; rimane lo stesso indipendentementedal punto in cui il Mobile-Node si connette ad Internet.

Home-Network: la "sotto-rete di casa", a cui appartiene l'indirizzo stabile diun sistema; il relativo prefisso di rete è cioè compatibilecon l’Home-Address attribuito al Mobile-Node. Èimportante notare che i meccanismi standard diinstradamento utilizzati in Internet invierebbero ciascundatagramma IP indirizzato al Mobile-Node esclusivamentealla Home-Network.

Visited-Network: una sotto-rete visitata da un Mobile-Node, purché diversadalla propria Home-Network.

Foreign-Network: altra dizione equivalente alla Visited-Network.Home-Agent: un'entità logica residente in un router che fa parte della

Home-Network del Mobile-Node; la sua funzione è quelladi tener memoria dell'attuale localizzazione di tutti iMobile-Nodes appartenenti alla sua sotto-rete e di farpervenire ai Mobile-Nodes in visita presso altre sotto-retil'informazione ad essi indirizzata.

Tunnel: percorso seguito dai datagrammi IP per raggiungere unMobile-Node presso una Visited-Network; il tunnel èrealizzato secondo opportune modalità di incapsulamento;il tunnel consente di far pervenire informazione al Mobile-Node quando non è connesso alla sua Home-Network.

Foreign-Agent: un'entità logica residente in un router della sotto-retevisitata da un Mobile-Node (Visited-Network); coopera conl’Home-Agent per completare la consegna dei datagrammiIP al Mobile-Node che si trova in visita nella relativaVisited-Network.

212

Visitor list: la lista dei Mobile-Nodes in visita presso un Foreign-Agent.Care-of-Address: indica il punto di terminazione di un Tunnel verso un

Mobile-Node per i datagrammi IP ad esso inviati mentre èlontano da casa.Esistono due tipi di Care-of-Address:il Foreign-Agent-Care-of-Address è l’indirizzo del Foreign-Agent presso cui il Mobile-Node è in visita; è uno dei duepossibili punti di terminazione del tunnel;il Collocated-Care-of-Address è un indirizzo, appartenentealla Visited-Network, che viene assegnato in mododinamico ad un Mobile-Node quando è in visita presso laVisited-Network stessa (tipicamente mediante DHCP oPPP); è l'altro dei due possibili punti di terminazione deltunnel; Il Mobile-Node usa il suo Home-Address comesource address di tutti i datagrammi IP che emette, tranne incasi particolari (legati a richieste di registrazione) in cui usail Collocated-Care-of-Address.

Mobility Agent: un Home-Agent o un Foreign-Agent.Mobility Binding: l’associazione di un Home-Address con un Care-of-Address

per tutta la durata dell’associazione stessa.Link: un dispositivo oppure un mezzo mediante il quale il

Mobile-Node può comunicare a livello di link-layer.Link-layerAddress: l’indirizzo utilizzato per identificare il punto d’arrivo di una

comunicazione su un link fisico. Tipicamente un indirizzoMAC.

AgentAdvertisement: i Foreign-Agents inviano degli "Advertisement" (=avviso,

annuncio, comunicazione, pubblicità) per segnalare la loropresenza su un link, a questo scopo usano un appositomessaggio che è costruito allegando una estensione specialead un messaggio "router advertisement" (quest'ultimo è unmessaggio standard di ICMP).

Mobility SecurityAssociation: un insieme di contesti di sicurezza tra una coppia di nodi

che possono essere utilizzati per lo scambio di messaggirelativi a Mobile IP. Ogni contesto indica: un algoritmo,una modalità di autenticazione, un segreto (una chiave

213

condivisa, o una appropriata coppia di chiavi pubbliche oprivate), lo stile di "replay protection" in uso.

Security parameterindex (SPI): un indice che identifica un contesto di sicurezza tra una

coppia di nodi, scelto tra tutti i contesti disponibili nella"mobility security association".

IV.5.4� Descrizione del protocollo

Mobile IP è un metodica che consente di svolgere tre funzioni tra lorocollegate:

- Agent Discovery: i Mobility Agents (Home e Foreign), rendono nota la loropresenza su ciascun link cui sono collegati (e su cui sono configurati perfornire quel servizio).

- Registration: quando un Mobile-Node è lontano dalla sua Home-Network(cioè è collegato ad una Foreign Network) si registra presso l’Home-Agentdella sua Home-Network con il Care-of-Address a lui assegnato dalla ForeignNetwork a cui è connesso.

- Tunneling: per fare in modo che i datagrammi IP siano consegnati alMobile-Node, quando questo è lontano da casa, l’Home-Agent deve inviarlial Care-of-Address (sia esso il Collocated o il Foreign-Agent-Care-of-Address) mediante un tunnel.

La procedura seguita è la seguente:� I Mobility Agents, si “rendono noti” mandando dei messaggi di

Advertisement. Un Mobile-Node “impaziente” può opzionalmentesollecitare un messaggio di advertisement.

� Dopo aver ricevuto un messaggio di advertisement, un Mobile-Nodedetermina se è collegato alla sua Home-Network oppure no. Nel caso in cuiun Mobile-Node determini di essere connesso alla sua Home-Network, leprocedure seguite sono quelle standard di IP.

� Quando un Mobile-Node si trova in visita presso una Visited-Network, puòseguire due modalità alternative: 1) ottiene un Collocated-Care-of-Address(ovvero l'indirizzo dinamico) tipicamente mediante DHCP o PPP e quindi siregistra (direttamente o tramite il Foreign-Agent) presso il suo Home-Agent,ovvero gli comunica il suo Collocated-Care-of-Address, e quindi la suaposizione; 2) in seguito all'ascolto (o alla sollecitazione) degli AgentAdvertisement del Foreign-Agent si registra presso quest'ultimo,comunicandogli quindi la sua presenza; il Foreign-Agent comunica quindiall'Home-Agent del Mobile-Node la presenza del Mobile-Node presso la suaVisited-Network, insieme al Foreign-Agent-Care-of-Address (ovvero uno

214

dei suoi indirizzi, a cui riceverà i datagrammi destinati al Mobile-Node).� I datagrammi IP inviati (dai Correspondent-Nodes) al Mobile Node seguono

l'instradamento classico e quindi pervengono all'Home-Network del Mobile-Node; quando questo si trova presso una Visited-Network, tali datagrammiIP sono intercettati dall’Home-Agent e ri-inviati al Mobile-Node medianteun tunnel che parte dall’Home-Agent e finisce: o al Collocated-Care-of-Address, e quindi direttamente al Mobile-Node (nella prima alternativa dicui al punto precedente) o al Foreign-Agent-Care-of-Address e quindi alForeign-Agent (nella seconda alternativa di cui al punto precedente); inquesto secondo caso è compito del Foreign-Agent rilanciare tali datagrammial Mobile-Node. Quest'ultima operazione è possibile in quanto: 1) il Mobile-Node si trova nella stessa sotto-rete del Foreign-Agent; ii) il Mobile-Node siè registrato presso il Foreign-Agent, e quindi quest'ultimo è a conoscenzadella presenza del Mobile-Node nella sua sotto-rete e del suo Home-Address.

� Nella direzione opposta, i datagrammi IP inviati dal Mobile-Node sonoconsegnati alla loro destinazione usando i meccanismi standard diinstradamento di IP e non passano attraverso l’Home-Agent.

E' opportuno aggiungere qualche parola sul concetto di tunnel.L'operazione di "tunnelling" è attuata mediante una procedura diincapsulamento. Ovvero una certa unità di dati viene incapsulata all'interno diun'altra unità di dati, di strato protocollare concettualmente inferiore, e daquesta trasportata. Ciò corrisponde a creare un percorso (tunnel) a livello diquesto strato inferiore ed all'interno del quale l'unità dati incapsulata viaggia,senza essere esaminata dalle entità dello strato incapsulante. Ad esempio, neltrasporto di IP mediante la rete telefonica commutata, un circuito telefonico puòessere visto come un tunnel che trasporta datagrammi IP. I nodi della retetelefonica non esaminano né trattano i datagrammi IP, che sono quinditrasportati trasparentemente. I datagrammi IP vengono inseriti nel tunnel edestratti invariati all'uscita dello stesso. Il meccanismo del tunneling è usato insvariate applicazioni (e ad ogni strato di una generica architettura protocollare).

In Mobile IP è usato per gestire i due indirizzi associati ad un Mobile-Node (stabile e dinamico, ovvero Home-Address e Care-of-Address). Idatagrammi inviati dai Correspondent-Node hanno come indirizzo didestinazione l'Home-Address. Quando l'Home-Agent li rilancia verso il Mobile-Node, non può certo usare l'Home-Address come indirizzo di destinazione, madeve usare il Care-of-Address (Collocated o Foreign-Agent che sia). D'altraparte l'identità del Mobile-Node è associata all'Home-Address. L'Home-Agentrealizza quindi un tunnel. La modalità più semplice di incapsulamento è

215

denominata IP-in-IP (è possibile usarne di alternative, ma questa deve esseresempre supportata).

L'Home-Agent incapsula il datagramma ricevuto da un Correspondent-Node in un altro datagramma IP (da cui il nome IP-in-IP), in cui pone comeindirizzo di destinazione il Care-of-Address (Collocated o Foreign-Agent chesia) e come indirizzo sorgente se stesso. Quando tale datagramma arriva alCare-of-Address, il datagramma originale in esso contenuto (ed in cui ècontenuto l'Home-Address come indirizzo di destinazione e l'indirizzo disorgente originale del Correspondent-Node) viene de-capsulato, ovvero estrattodal tunnel e consegnato al Mobile-Node. In tal modo la destinazione IP"stabile" (coincidente con l’indirizzo Home-Address del Mobile-Node) non èrilevata dai router interposti tra la Home-Network e la posizione corrente delMobile-Node. Rimane comunque compito di ciascun Home-Agent, intercettarei datagrammi IP destinati all’Home-Address di ogni "suo" Mobile-Node.

In Fig. 48 è riportato l’instradamento dei datagrammi IP verso e da unMobile-Node, quando questo è lontano dalla sua Home-Network. In questafigura si assume che il Mobile-Node si sia già registrato presso il suo Home-Agent, comunicandogli quindi la sua nuova posizione (ovvero il suo Care-of-Address) e che il Mobile-Node stia usando un Foreign-Agent-Care-of-Addressdella sotto-rete visitata. La comunicazione si svolge secondo le seguenti fasi:� Un datagramma diretto verso il Mobile-Node arriva alla Home-Network

attraverso l’instradamento IP standard.� Il datagramma è intercettato dall’Home-Agent ed inviato attraverso un

tunnel al Foreign-Agent-Care-of-Addres.� Il datagramma è estratto dal tunnel dal Foreign Agent e rilanciato al Mobile-

Node. Al Mobile-Node perviene lo stesso datagramma emesso dalCorrespondent-Node, con gli stessi valori dei campi di indirizzo di sorgentee di destinazione.

� Per i datagrammi inviati dal Mobile-Node, l’instradamento standard di IPconsegna ciascun datagramma alla sua destinazione.

216

CorresopondentNetwork

Home Network Visited Network

MobileNode

CorrespondentNode

HomeAgent

ForeignAgent

��

Source = Home AddressDest= Correspondent Node

Source = Home AgentDest= Foreign Agent

Source = Correspondent nodeDest= Home Address

Fig. 48 - Il meccanismo di instradamento di Mobile IP

Per il funzionamento di Mobile IP vengono scambiati una grande varietà dimessaggi di segnalazione; a questo scopo Mobile IP sfrutta sia messaggi ICMP(come specificato in RFC 1256), inviati periodicamente dai Mobile Agents suilink a cui sono collegati, sia pacchetti UDP inviati alla porta 434 dei MobilityAgents. Tali messaggi consentono di svolgere le seguenti funzioni:Agent Advertisement: Consentono ai Mobile-Nodes di capire se sono

collegati ad un Foreign-Agent o se sono ancora nellaloro Home-Network. Questo messaggio può contenereun Care-of-Address che può essere "preso" dalMobile-Node ed usato per richiedere una registrazione.

Agent Solicitation: Vengono inviati dagli stessi Mobile-Nodes, quandohanno bisogno di informazioni relative al protocolloMobile IP (o quando si accorgono di un "movimento"da un cambiamento di qualche parametro di rete)

Per svolgere le procedure di registrazione vengono invece inviati degliopportuni datagrammi IP, usando il protocollo di trasporto UDP, questimessaggi consentono di svolgere le seguenti funzioni:Registration Request: Vengono inviati dai Mobile-Nodes all’Home-Agent,

oppure al Foreign-Agent, a seconda che si stia

217

cercando di registrare un Collocated-Care-of-Addressoppure un Foreign-Agent-Care-of-Address. Inquest’ultimo caso il Foreign-Agent inoltra a sua voltala richiesta di registrazione all’Home-Agent.

Registration Reply: Questi messaggi di segnalazione vengono utilizzatidagli agenti che gestiscono la mobilità per risponderealle richieste di registrazione. Riportano, tra le altreinformazioni, anche la durata di tempo per cui laregistrazione (Mobility Binding) sarà consideratavalida.

Securing theRegistration Procedure: Per rendere sicure le procedure di registrazione è

prevista una serie di messaggi rivolti allo scambio dichiavi segrete e contesti di sicurezza.

Dalla descrizione di Mobile IP possiamo notare delle similitudineconcettuali con il meccanismo adottato nel GSM. In entrambi i case esistonodue entità:� una entità che registra stabilmente le informazioni degli utenti, inclusa la

loro attuale posizione geografica (HLR nel GSM, Home-Agent in MobileIP);

� un'altra entità che si prende cura degli utenti quando questi si trovanolontano da casa (VLR nel GSM, Foreign-Agent in Mobile IP).

IV.5.5� Sviluppi futuri

Il prodotto delle attività del Gruppo di Lavoro (Working Group) IETF chesi occupa di Mobile IP può essere diviso in due parti: l’insieme di protocollifinora succintamente esposti, che fanno parte dello standard Mobile IP (sonoquindi delle RFC che portano la dicitura Standard Track), e diversi "Internet-Drafts" (ovvero delle proposte, ancora non approvate dalla comunità Internet).E' importante sottolineare che gli Internet-Drafts possono essere citati solocome "work in progress" e quindi non è affatto detto che il contenuto di questiDraft si traduca in degli standards (cfr. I.1). Ciononostante, nel seguitodescriveremo alcune interessanti proposte di estensioni a Mobile IP, non ancorastandard, ma che almeno nelle loro linee originali potrebbero diventarlo.

IV.5.5.1 Route Optimization (ottimizzazione della strada):

Uno dei principali svantaggi di Mobile IP consiste nella cosiddetta "stradaa triangolo" (triangle routing, cfr. Fig. 48): l'informazione dal Mobile-Node al

218

Correspondent-Node segue la strada decisa dai protocolli di instradamento equindi è "ottimizzata" in funzione dei criteri adottati dai protocolli diinstradamento. Invece l'informazione che segue la direzione opposta (daCorrespondent-Node a Mobile-Node) passa sempre attraverso il Home-Agent.Ciò può dar luogo a considerevoli inefficienze: si pensi ad un Mobile-Node invisita presso una sotto-rete di un altro continente ed in comunicazione con unsito colà situato. Il percorso che l'informazione segue per andare dal Mobile-Node al Correspondent-Node è molto più breve di quello in senso inverso. Nelcaso di servizi interattivi e/o con requisiti di tempo reale potrebbero crearsiserie difficoltà.

Purtroppo la necessità di far transitare l'informazione attraverso l'Home-Agent è dovuta all’esigenza di non modificare il modo di operare deiCorrespondent-Nodes e quindi di tutti gli attuali sistemi di Internet (ritroviamosempre il problema della backward compatibility o compatibilità all'indietro).Se si rinuncia a questa assunzione e quindi si ammette la possibilità di gestire lamobilità modificando anche i Correspondent-Nodes (che possono essere altrinodi mobili, ma saranno in una prima fase soprattutto siti Internet fissi), allora èpossibile modificare Mobile IP, evitando il triangle routing. Infatti, è possibilestabilire un flusso di informazioni di segnalazione avente lo scopo di informaredirettamente i Correspondent-Node dell'attuale posizione di un Mobile-Nodecon il quale intendono comunicare (tali informazioni sono denominate bindingupdates). Qualora i Correspondent-Node coinvolti fossero a conoscenza di taleinformazione, potrebbero inviare informazione direttamente ai Mobile-Node,senza più la necessità di passare attraverso l'Home-Agent.

Altre problematiche relative all'introduzione di questa metodologia sonosoprattutto quelle relative alla sicurezza. Bisogna infatti evitare che falsecomunicazioni dirottino il traffico dalle destinazioni volute ad altre. Per taleragione, nelle attuali proposte, si pensa che il compito di avvertire iCorrespondent-Node del cambiamento di posizione di un Mobile-Node debbaessere di pertinenza degli Home-Agent e non direttamente dei Mobile-Nodes. Intal modo i meccanismi possono essere più sicuri.

IV.5.5.2 Mobile IPv6

L’estensione a IPv6 del protocollo di supporto alla mobilità (Mobile IPv6)è molto più che una revisione e una correzione di Mobile IP. Infatti laproblematica del “mobile computing” è stata tenuta in considerazione sin dalleprime specifiche di IPv6 e pertanto risulta quasi integrata nello strato IP stesso.Nell'ipotesi di adottare IPv6, non è più necessario modificare i Correspondent-Nodes, alla ricerca di una "Route Optimization" in quanto, se tutti i nodi

219

implementano IPv6, essi risultano già compatibili con il suddetto modo dioperare. In altre parole, i Correspondent-Node sono direttamente informatidell'attuale posizione di un Mobile-Node con il quale intendono comunicare(mediante opportuni "binding updates").

Inoltre, non vi è più bisogno dei Foreign-Agent. Ne segue che la Visited-Network non deve essere necessariamente a conoscenza del fatto che al suointerno si trovano in visita dei terminali mobili, poiché la mobilità è gestita daiterminali mobili stessi. Questo è un significativo vantaggio di Mobile IPv6rispetto a Mobile IPv4.

Un altro punto a favore di Mobile IPv6 è la possibilità di sfruttareefficientemente le cosiddette destination options incluse nel protocollo IPv6.Tali informazioni possono essere incluse alla fine di ogni pacchetto IPv6 evengono esaminate solamente dal destinatario del pacchetto. Quindi non c’èbisogno di inviare degli appositi pacchetti ai Correspondent-Nodes pertrasmettere i “binding updates” (ovvero i messaggi che aggiornano leinformazioni sulla localizzazione di un Mobile-Node), ma le stesseinformazioni possono essere incluse alla fine di un qualsiasi pacchettoscambiato tra i due nodi (ad esempio quello relativo ad un pacchetto di ACKdel protocollo TCP).

IV.5.5.3 Seamless Handover

Un’altra area molto attiva del Working Group di Mobile IP è quella che sioccupa dell’ottimizzazione del protocollo per poter supportare Mobile IP insistemi senza filo (wireless). A questo proposito è bene ricordare la differenzatra la mobilità di un calcolatore portatile che viene disconnesso da una certasotto-rete (fissa) e poi riconnesso ad una diversa sotto-rete, e la mobilità tipicadi un sistema wireless (cfr. IV.5.1). In quest’ultimo caso la velocità con cuiavviene la connessione e la disconnessione può anche essere molto elevata(dipende dalle aree di copertura dei sistemi wireless e dalla velocità relativa concui si muove il Mobile-Node). Quindi è importante pensare a dei protocolli checonsentano di gestire rapidamente la mobilità e di evitare che si verifichinoperdite dei pacchetti che arrivano al Care-of-Address subito dopo che il Mobile-Node si è spostato su di un nuovo Care-of-Address. Per risolvere questoproblema è stato progettato (ma ancora non standardizzato) un protocollo diseamless handover, grazie al quale il Mobile-Node può accordarsi con il suo ex-Foreign-Agent, a cui notifica il suo nuovo Care-of-Address. Sarà poi compitodel vecchio Foreign-Agent inviare i pacchetti "ancora in viaggio" al nuovoCare-of-Address.

220

V� Bibliografia

Tutte le RFC e gli Internet-Drafts possono essere ricercate nel sitowww.ietf.org. Altri siti contenenti ulteriori informazioni sugli argomenti trattatisono i seguenti:http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/http://www.3com.com/technology/tech_net/white_papers/http://www.data.com/tutorials/http://pubpages.unh.edu/~mraman/MPLSFINAL/mpls.htmhttp://www.techguide.com/http://protocols.com/papershttp://www.rad.com

[BLE] N. Blefari-Melazzi, M. Listanti, A. Roveri: “Reti per ApplicazioniTelematiche”, dispense in distribuzione a cura degli autori.

[BRA97] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin: RFC 2205“Resource ReSerVation Protocol (RSVP) - Version 1 FunctionalSpecification”. 1997

[COM91] D. Comer: “Internetworking with TCP/IP”, Volume I - Principles,Protocols and Architecture. Prentice Hall, 1991.

[COM94] D. Comer, D. Stevens: “Internetworking with TCP/IP”, Volume IIand III. Prentice Hall, 1994

[CYP92] J. Cypser: "Communications for Cooperating Systems, OSI, SNAand TCP/IP, Addison-Wesley, 1992.

[DEM89] A. Demera, S. Keshav, and S. Shenker: “Design and Analysis of aFair Queuing Algorithm", ACM SIGCOMM'89, Austin, September1989.

[FER98] P. Ferguson, G. Huston: “Quality of Service in the Internet: Fact,Fiction, or Compromise?”, sottomesso a INET'98, 21-24 July 1998,Geneva, Switzerland.

[GAI97] S. Gai: "Guida a IPv6", McGraw Hill, 1997[GAL92] R. Gallager, D. Bertsekas: "Data Networks", Prentice Hall, 1992.[JAM97] J. Jamison, R. Wilder: "vBNS: the Internet fast lan for research and

education", IEEE Communications Magazine, Vol. 35, N.1, January1997.

[KES97] S. Keshav: "An Engineering Approach to Computer Networking",Addison-Wesley, 1997.

[KLE75] L. Kleinrock: "Queuing Systems, Volume 2: Computer

221

Applications", Wiley Interscience, 1975.[NEW96] P. Newman et. al.: “Flow Labelled IP: A Connenctionless Approach

to ATM”, Ipsilon Network Inc., Proc. IEEE Infocom, San Francisco,paper 10b2.1, pp 1251-1260, Marzo 1996.

[NEW97] P. Newman, T. Lyon, G. Minshall, H. Luston: “IP switching andgigabit routers", IEEE Communications Magazine, Vol. 35, N.1,January 1997.

[PAR96] A. Parekh, R. Gallagher: “A Generalized Processor SharingApproach to Flow Control”, The single node case and the multiplenode case, Transactions on Networking, Vol. 1, N.3, 1993 e Vol. 2,N. 2, 1996.

[PER97] Charles E. Perkins: "Mobile IP, IEEE Communications Magazine",May 1997

[RAM94] Ramteke: "Networks", Prentice Hall, 1994[ROV95] A. Roveri: “Reti di Telecomunicazioni”, Principi Generali, Scuola

Superiore G. Reiss Romoli, L’Aquila, 1995.[STA96] William Stallings: "IPv6: The New Internet Protocol", IEEE

Communications Magazine, July 1996[TAN96] A. Tanenbaum, "Computer Networks", Prentice Hall[WHI97] P. P. White: “RSVP and integrated services in the Internet: a

tutorial”, IEEE Communications magazine, Vol. 35, N. 5, May 1997.[XIA99] X.Xiao, L.M.Ni: “Internet QoS: a big picture”, IEEE Network,

March/April 1999, pag.8-18.[WST95] G. R. Wright, W. R. Stevens: "TCP/IP Illustrated", Vol 1, 2;

Addison-Wesley

222

V.1� Lista delle figure e delle tabelle

Fig. 1 – Esempio di funzionamento di NFS .............................................................................16Fig. 2 - Esempio di interconnessione di due sotto-reti .............................................................22Fig. 3 – Esempio di architettura di sistema di interconnessione...............................................24Fig. 4 – Esempio di architettura di sistema di interconnessione, nel caso di adozione di un

protocollo aggiuntivo e comune a tutti i sistemi coinvolti ...............................................27Fig. 5 - Esempio di interconnessione di tre sotto-reti ...............................................................29Fig. 6 - Struttura esemplificativa di Internet.............................................................................32Fig. 7 - Esempio di sistemi connessi a più di una sotto-rete.....................................................50Fig. 8 - Esempio di incapsulamento del datagramma IP in unità di dati caratteristiche delle

sotto-reti attraversate.........................................................................................................55Fig. 9 - Esempio di interconnessione di quattro sotto-reti e tabella di instradamento del router

R2......................................................................................................................................62Fig. 10 - Trasporto dei messaggi ICMP all’interno di datagrammi IP .....................................76Fig. 11 - Notazione mnemonica di un indirizzo IP, o nome.....................................................79Fig. 12 - Esempio di parte dell’albero di nomi .........................................................................84Fig. 13 - Struttura gerarchica dei name servers ........................................................................85Fig. 14 – Risoluzione di nomi ed instradamento ......................................................................91Fig. 15 – Esecuzione di un comando di utente .........................................................................92Fig. 16 – Incapsulamento del datagramma utente UDP nel datagramma IP ............................95Fig. 17 - Incapsulamento dell’unità dati di TCP in datagrammi IP..........................................99Fig. 18 - Procedura di instaurazione di una connessione TCP ...............................................105Fig. 19 - Procedura di abbattimento di una connessione TCP................................................107Fig. 20 - Esempio dell’andamento del ritardo di attraversamento di una sotto-rete...............113Fig. 21- Architettura fisica di un gigabit router ......................................................................130Fig. 22 - Esempio di dominio MPLS, di LSR, LSP e LER ....................................................142Fig. 23 - Esempio di dominio MPLS e della LIB del router MPLS b. ...................................142Fig. 24 - Pre-assegnazione individuale ...................................................................................146Fig. 25 - Assegnazione a domanda .........................................................................................147Fig. 26 - Pre-assegnazione collettiva ......................................................................................148Fig. 27 - Messaggi del protocollo RSVP ................................................................................155Fig. 28 - Invio dei messaggi di Path .......................................................................................155Fig. 29 - Invio dei messaggi di RESV ....................................................................................158Fig. 30 - Modalità di funzionamento di weighted fair queueing, per flussi............................160Fig. 31 - Modalità di funzionamento di weighted fair queueing, per classi ...........................160Fig. 32 - Architettura di IntServ..............................................................................................161Fig. 33 - Corrispondenza tra i paradigmi ATM e RSVP ........................................................161Fig. 34 - Buffer di playout ......................................................................................................164Fig. 35 - Esempio di applicazione di RTP..............................................................................166Fig. 36 - Architettura protocollare ISA...................................................................................166Fig. 37 - Trattamento del flusso di utente ai bordi della rete..................................................170Fig. 38 - Dominio DS .............................................................................................................170Fig. 39 - Regioni e domini DS e SLA stabiliti tra domini o tra un dominio e i suoi utenti....171Fig. 40 - Architettura di rete per DiffServ con SLA dinamici ................................................172Fig. 41 - Formato del campo TOS "storico" (1981) ...............................................................173Fig. 42 - Soluzione ibrida IntServ-DiffServ ...........................................................................175Fig. 43 - Formato generale del pacchetto IPv6. ......................................................................189Fig. 44 - Formato della parte base dell’header IPv6...............................................................190

223

Fig. 45 - Esempi di pacchetti IPv6..........................................................................................195Fig. 46 - Esempio di handover................................................................................................202Fig. 47 - Scambio di informazione in seguito ad una variazione della posizione del terminale

........................................................................................................................................205Fig. 48 - Il meccanismo di instradamento di Mobile IP .........................................................216

Tab. 1 - Architettura protocollare di Internet............................................................................34Tab. 2 - Formato del datagramma IP ........................................................................................39Tab. 3 - Formato degli indirizzi ................................................................................................47Tab. 4 - Indirizzi speciali ..........................................................................................................49Tab. 5: Riga da aggiungere alla tabella di instradamento di R2 ...............................................63Tab. 6 - Classificazione dei nomi in domini.............................................................................83Tab. 7 – Formato dell’unità di dati di UDP ..............................................................................94Tab. 8 - Formato dello pseudo-header in UDP.........................................................................96Tab. 9 - Alcune well known ports in UDP ...............................................................................96Tab. 10 - Alcune well known ports in TCP ..............................................................................98Tab. 11- Formato del segmento TCP......................................................................................100Tab. 12 - Formato dello pseudo-header ..................................................................................102Tab. 13 – Schema di allocazione degli indirizzi .....................................................................196

Internet: Architettura, Principali Protocolli e Linee...

Documents

Transcript of Internet: Architettura, Principali Protocolli e Linee...