protocolli e telecomunicazioni - mondo...

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 7

1. INTRODUZIONE

L’ enciclopedia gratuita offerta su Internet, laormai famosa Wikipedia (http://en.wiki-

pedia.org/wiki/Main_Page), fornisce la defini-zione seguente del termine protocollo di comu-nicazione: a set of rules governing communica-tion between electronic devices.Dobbiamo notare che il generico termine pro-tocollo è riferito a varie altre categorie, oltrealle comunicazioni: diplomazia e politica,informatica, medicina e scienza, letteratura espettacoli. È interessante il fatto che per cer-care la definizione corrente del termine pro-tocollo con le sue varie accezioni, inclusaquella qui oggetto di trattazione nell’ambitodelle telecomunicazioni, sono state invocateuna complessa messe di protocolli di comu-nicazione: l’HTTP per dialogare con il pro-gramma applicativo che gestisce le pagineweb di Wikipedia; i protocolli della famigliaTCP/IP per effettuare un trasferimento affida-bile dei dati dal server remoto alla macchinaclient, per risalire dal nome del destinatarioal suo indirizzo di rete, per determinare unpercorso interno alle reti attraversate fino al-

l’indirizzo di destinazione, per mantenere lacontinuità del collegamento; i protocolli spe-cificati negli standard della famiglia IEEE 802per accedere attraverso la rete locale Ether-net alla quale la macchina cliente è connessanell’esempio in esame. Ma andiamo con ordi-ne, per dipanare la matassa di sigle che si af-fastella non appena si esamina anche la piùsemplice attività di interconnessione in rete.Il problema base della comunicazione tra en-tità remote può essere schematizzato comesegue: una popolazione di entità, consistentiin esseri umani o processi eseguiti automati-camente da macchine, in particolare compu-ter, e distribuiti geograficamente su una dataarea, hanno necessità di cooperare con altreentità facenti parte della medesima popola-zione per conseguire i propri obbiettivi funzio-nali. La “cooperazione” può essere vista in ge-nerale come l’evoluzione di una macchina astati distribuita, in cui ogni entità svolge azio-ni che dipendono dai dati e programmi/modidi procedere residenti localmente e dalle sol-lecitazioni esterne, in particolare dai risultatidelle comunicazioni con altre entità della po-

Tracciare l’evoluzione dei protocolli significa tracciare l’evoluzione delle teleco-

municazioni. Ovvero parlare di ICT anziché di TLC. Il valore aggiunto, insito nei

protocolli di rete, si è evoluto passando dalla correzione d’errore, alla gestione

del dialogo, alle funzioni collaborative per arrivare infine ai servizi applicativi, sem-

pre più sofisticati e orientati all’erogazione dei servizi web. La pietra miliare è il

modello OSI, sempre attuale, rivisto alla luce delle nuove tecnologie di rete wire-

less e dalla necessità di definire protocolli che supportino ambienti multimediali.

Andrea BaiocchiGiacomo Zanotti

PROTOCOLLIE TELECOMUNICAZIONIALLA RICERCA DEL VALOREAGGIUNTO

21

3.4

0

polazione. Informalmente, i protocolli specifi-cano le regole di questo tipo di interazione.Un semplice esempio, per rendere menoastratta la definizione, ma che non rende ne-cessariamente l’intera complessità che vi sinasconde, è una popolazione di esseri umanidispersi in un dato territorio che necessitanodi effettuare conversazioni a voce. Il problemadi comunicazione consiste, ridotto all’osso,nel fornire mezzi per cercare e allertare un de-stinatario da parte di un originatore, nel per-mettere il trasferimento intelleggibile dellavoce in modo bidirezionale tra le due parti du-rante la conversazione, eventualmente impie-gando risorse di comunicazione condivise daimembri della popolazione di utenti, nel forni-re i mezzi per terminare ordinatamente la con-versazione e rilasciare eventuali risorse condi-vise utilizzate. Altro esempio è l’esecuzione ditransazioni tra macchine (mail server) per ladistribuzione della posta elettronica. Anche inquesto caso il paradigma comporta la neces-sità di scoprire i potenziali partner, contattarli,negoziare le condizioni per l’esecuzione dellatransazione, trasferire dati e informazioni dicontrollo relativi alla transazione tra le mac-chine coinvolte, quindi terminare la transazio-ne. Ogni passo di questo processo in ognimail server è controllato da un programma(software). Questo software elabora i conte-nuti informativi scambiati (per esempio ese-gue traduzioni di codifica, memorizza in archi-vi) ed esegue i protocolli di comunicazioneche permettono la cooperazione tra i processiresidenti su macchine remote. In ambedue gliesempi, conversazioni e distribuzione dellaposta, sistemi intermedi con i loro protocolli,programmi e dati intervengono ad un livellopiù “basso” di quello dell’applicazione. Scopodei sistemi intermedi è fornire e controllare laconnettività e la qualità del servizio di rete: insintesi, trasferire dati all’interno della popola-zione di utenti in modo tecnicamente efficien-te (date le tecnologie disponibili) ed economi-camente conveniente (dati gli obiettivi e il va-lore dei servizi supportati).Cos’è quindi un protocollo di comunicazione?La definizione data all’inizio lo identifica co-me un insieme di regole che permettono unoscambio di informazioni tra apparati elettro-nici, o più in generale, come illustrato nei duesemplici esempi, tra processi applicativi (in

senso lato, inclusi dunque gli esseri umani). Ècruciale precisare il termine “scambio”: loscambio di informazioni fa pensare a un pas-saggio di dati da un’entità ad un’altra, even-tualmente in modo bidirezionale. Focalizzarel’attenzione sulla fase di “scambio” dei datielude però la parte forse più importante di unprotocollo che è il “controllo” della scambio,cioè la definizione di procedure distribuiteche permettono alle entità coinvolte di arriva-re a scambiare i dati, controllando le condi-zioni tecnico-economiche nelle quali lo scam-bio avviene (ecco il valore aggiunto!).A questo scopo un generico protocollo com-prende tre parti costitutive:❑ una sintassi, che precisa le strutture deimessaggi (formato, parti componenti, possi-bili valori attribuibili alle varie parti) usati nelprotocollo con finalità di controllo e di trasfe-rimento di dati;❑ una semantica, che stabilisce il significatodei particolari valori inseriti nelle parti di ognimessaggio e degli eventi che si presentanonell’evoluzione del protocollo, anche in rap-porto alle sequenza di messaggi scambiati apartire dall’inizio dell’interazione, e definiscequindi le azioni che una entità deve intrapren-dere; si tratta in sostanza della specificazionedella logica della macchina a stati eseguita daogni entità partecipe del protocollo;❑ temporizzatori, che presiedono alla corret-ta evoluzione nel tempo del protocollo, ovve-ro delle macchine a stati associate al proto-collo in ogni entità che prende parte alla suaesecuzione; scopo essenziale dei temporiz-zatori (timer) è regolare la “marcia” dell’evo-luzione del protocollo, verificando che letransizioni di stato avvengano in lassi di tem-po coerenti con una corretta funzionalità.Nel riquadro di p. 23 è illustrato qualcheesempio per ognuno dei tre concetti.Notiamo che, in un protocollo, le funzioni“collaborative”, anche quando comportanoattività basilari, possono richiedere l’utiliz-zo di algoritmi molto complessi o anchecondurre a situazioni (stati dell’automa)“indecidibili”. In questo ultimo caso, il pro-tocollo non è in grado di risolvere univoca-mente la situazione ma si limita ad “avvisa-re” tutti gli attori che partecipano al proces-so collaborativo che si è verificata una si-tuazione anomala e che dunque è necessa-


1

0

0

1

22

rio ritornare all’ultima situazione concorda-ta, annullando tutte le situazioni pendenti(processo di uccisione degli orfani). Unesempio classico è costituito dal processocollaborativo per cui si aggiornano contem-poraneamente più basi di dati distribuite.L’algoritmo utilizzato implica una regia piut-tosto complessa in più fasi (prepare, com-mit, rollback); in caso di problemi si tornaall’ultima condizione certa (rollback).In altre situazioni è necessario ricorrere adalgoritmi “a latere”, molto sofisticati e appa-rentemente scollegati dal processo in esa-me. Un esempio semplice, ma concreto, è co-stituito dalla banale richiesta di confermadella ricezione di un documento da parte deldestinatario (si intende qui la ricezione effet-tiva, ossia la verifica che il documento siastato effettivamente aperto sul PC del desti-natario e non il più semplice problema dellaconsegna “postale”). La certezza dell’effetti-vo display del documento si ottiene con algo-ritmi complessi di tipo “notarile” (ovvero ènecessario l’intervento di un garante “ester-no” che esegua ogni richiesta in duplice for-mato: in chiaro e “crittografata” con la chiavepubblica del mittente in modo che si possasempre dimostrare che non ci sono discre-

panze tra i documenti che il destinatario haaccettato di ricevere e quelli che gli vengonoeffettivamente consegnati).Nel seguito dell’articolo, dopo una breve sto-ria dei protocolli (paragrafo 2), sono presenta-te le idee di base ormai accettate e consolidatenelle architetture di protocolli di comunicazio-ne. In questo contesto sono introdotte le archi-tetture di comunicazione e si chiarisce il nessocon l’aggiunta di valore, caratteristica salientedi un vero protocollo (almeno di quelli utili). Èanche brevemente discusso l’impatto sulle ar-chitetture di protocolli di requisiti trasversali:la qualità di servizio, la sicurezza nella comuni-cazione e il risparmio energetico. Spazio è de-dicato nel paragrafo 4 a discutere il nesso tra ilmodello architetturale introdotto nel para-grafo 3 e la pila protocollare di Internet. Il para-grafo 5 contiene uno sguardo ad approcci “al-ternativi”, in particolare al cross-layering, per illoro interesse negli sviluppi di specifiche im-portanti tecnologie come il wireless.Esempi tratti dalle principali architetture diprotocolli sono diffusi nel testo nel tentati-vo di rendere afferrabile ogni definizioneastratta e di mostrare come si concretano lesoluzioni a problemi di comunicazione in re-te attraverso meccanismi protocollari.


1

23

0

0

0

1

Esempi di aspetti sintattici, semantici e di temporizzazione dei protocolli

Un’unità d’informazione (pacchetto) di un protocollo per il trasferimento dei dati in rete, quale per esempio IP, è descritta da una se-quenza di ottetti (byte) raggruppati a formare cosiddetti campi. Ogni campo può avere solo determinati valori (dominio) e rappresen-ta un elemento d’informazione portato dal pacchetto: per esempio alcuni byte contengono l’indirizzo del mittente del pacchetto (in-terfaccia di rete dalla quale è originato il pacchetto), altri, l’indirizzo del destinatario (interfaccia alla quale è connessa l’entità destina-taria finale del pacchetto). Altri byte possono contenere codici per il controllo di errori, altri il numero della versione del protocollo (an-che i protocolli di comunicazione hanno una vita ed evolvono, come il software che installiamo sui nostri computer: hanno quindi unnumero di versione, per motivi di verifica di compatibilità).Seguendo il filo di questo esempio, la semantica specifica la sequenza di operazioni da fare con un pacchetto da parte di una genericaentità di rete che lo riceve. Per esempio:1. verifica la presenza di errori nel pacchetto;2. se corretto, verifica se trattasi di versione compatibile con quelle disponibili localmente;3. verifica se l’indirizzo destinatario coincide con uno degli indirizzi attribuiti all’entità;4. in caso contrario, verifica se rientra tra gli indirizzi di una porzione di rete connessa all’entità, oppure se è un indirizzo di gruppo mul-ticast; in tal caso si passa al punto 6;5. scarta il pacchetto e notifica il mittente che l’indirizzo di destinazione non è noto;6. consulta la tabella di instradamento per decidere su quale porta di uscita rilanciare il pacchetto. Infine, un esempio di uso di temporizzatori si ha nel caso di controllo della corretta ricezione di un messaggio effettuato mediante ri-scontri: una entità A invia un messaggio a B ed attende da B una esplicita notifica di ricezione corretta del messaggio. Quando deveaspettare A? Come fa a sapere che “è troppo tardi”? Una risposta accurata può essere anche molto difficile da dare, per esempio nelcaso di ritardo di trasferimento tra A e B variabile da pacchetto a pacchetto. È però chiara l’esigenza di mettere un termine all’attesa delriscontro da parte di A per evitare di mandare il protocollo in uno stato di stallo. La soluzione adottata universalmente è definire un “ti-me-out”, cioè un contatore che scade dopo un tempo prefissato a partire dall’invio dei dati. Se entro questa scadenza non si è ricevu-to riscontro, si assume che i dati non siano giunti a destinazione. Porre una terminazione certa all’attesa del riscontro è un requisitoesattamente analogo a quello di terminazione di un algoritmo. Con la difficoltà enorme del fatto che l”algoritmo” in questione (ese-guito dal protocollo) è intrinsecamente di natura distribuita e prevede la collaborazione di sistemi di elaborazione remoti.

0

Spesso questi contengono sottigliezze edettagli che richiedono profonde conoscen-ze e riflessione attenta per essere compre-se; ma altrettanto spesso, procedure proto-collari infarcite di sigle e di tecnicismi sonoil buon senso codificato!

2. UNA BREVE STORIA

I primi protocolli nascono per risolvere il pro-blema della trasmissione remota di dati, in-trinsecamente legato al problema della con-divisione di una risorsa, ai tempi preziosissi-ma, quale la banda trasmissiva e la capacitàdi elaborazione.Normalmente sono noti con il nome di “proto-colli orientati al carattere” [1, 3] in quanto ilmeccanismo per gestire la “regia” del dialogoconsiste nell’eleggere alcuni caratteri a fun-zioni di controllo: per esempio un carattererappresenta l’inizio del blocco di dati (STX,Start of Text), un altro la fine (EOT, End of Tran-smssion), un altro ancora la conferma di rice-zione corretta – o meno – (ACK o NACK, Ack-nowledgement o Not Acknowledgement). Questi protocolli sono quasi sempre utilizzatisu una linea multipoint (ovvero su una lineacondivisa da più dispositivi), per cui é neces-sario introdurre un meccanismo selettivo ditrasmissione/ricezione (un meccanismo pos-sibile é il polling/selecting, ovvero l’appello aturno ciclico per autorizzare la trasmissione).I limiti di questi protocolli sono moltissimi.Ne elenchiamo i principali:❑ non trasparenza al testo. Il testo non puòcontenere caratteri codificati come uno deicaratteri di controllo (per evitare ambiguità).Il problema si supera con un ulteriore livellodi caratteri di controllo (DLE, Data Link Esca-pe, per segnalare che il carattere successivova inteso come testo e non come controllo);❑ non trasparenza al controllo. L’inserimentodi un nuovo carattere di controllo (per imple-mentare una nuova funzione), può far insor-gere ancora problemi di trasparenza;❑ assenza di controllo di flusso: non é possi-bile inviare un nuovo blocco di informazionise il ricevente non ha dato l’ACK a quello pre-cedente (al massimo si può pensare a dueblocchi, con una logica di ACK pari e dispari);❑ ambiguità nei caratteri di controllo. Spie-ghiamo con un esempio: un ACK può essere

interpretato a livello trasmissivo, oppure ap-plicativo, oppure transazionale (ho ricevuto ilblocco, l’ho ricevuto e l’ho passato all’appli-cazione, l’applicazione l’ha preso in carico edha logicamente chiuso la transazione). Que-sto problema é in assoluto il più grave inquanto rende il dialogo fortemente dipen-dente dal contesto in cui é inserito, a livellofisico e logico;❑ povertà del controllo di errore, basato suibit di parità;❑ impossibilità di gestire (orchestrare) piùflussi contemporanei.Un passo importante nell’evoluzione dei pro-tocolli é costituito dall’introduzione (da partedi IBM) dell’SDLC (Synchronous Data LinkControl, [2]), da cui é derivato l’importantissi-mo (e tuttora vivo) standard HDLC (Higher-Level Data Link Control, [4]). HDLC e SDLC so-no strutturalmente identici, ma sono utilizza-ti in contesti diversi. Non é importante capir-ne le differenze, ma é importante ragionaresulla novità introdotta.Essi sono chiamati “protocolli orientati albit” (in contrapposizione a quelli precedenti,orientati al carattere), perché si supera il con-cetto di carattere di controllo, ma si introdu-ce quello di “trama” o “cornice”. Ovvero labusta trasmissiva ha una struttura predefini-ta - inizio, campo indirizzo, caratteri di con-trollo, testo, controllo di errore, fine - per cuiuna sequenza di bit ha un significato per laposizione occupata all’interno della trama enon solo per la sua codifica. L’n-simo bytesarà sempre e solo un carattere di controllo(o di testo), in relazione alla sua posizione, ecosì sarà comunque interpretato.Con i protocolli orientati al bit si superanoenormi problemi.Il testo é trasparente ed indipendente dallacodifica, a patto di rendere univoca la delimi-tazione delle trame (per esempio con mecca-nismi di bit stuffing).Il campo indirizzo permette di indirizzare unnumero elevato di stazioni, lavorando su lineepunto a punto oppure su linee multipunto.Il campo controllo contiene molteplici fun-zioni; una delle più importanti é la numera-zione dei blocchi in trasmissione e ricezio-ne, secondo un modulo aritmetico predefi-nito (per esempio 8 o 128). I numeri in tra-smissione individuano la sequenza dei


1

0

0

1

24

blocchi in trasmissione, i numeri in ricezio-ne individuano il limite superiore dei bloc-chi ricevuti correttamente nel verso oppo-sto. Questo meccanismo (chiamato fine-stra) permette di avere un flusso trasmissi-vo regolabile, basato su meccanismi sem-plici e potenti di controllo di flusso e di erro-re. La regolazione del flusso riguarda ogniaspetto trasmissivo: sono infatti risolti pro-blemi di sequenzialità e di integrità (per ef-fetto della numerazione), di regolazionedella quantità di informazioni in transito (sipuò arrivare a spegnere completamente ildialogo in una direzione, non aggiornando illimite inferiore della finestra e quindi eserci-tare un completo controllo di flusso oppuredargli il massimo dell’apertura aggiornandocontinuamente il limite inferiore della fine-stra in trasmissione), di regolazione del tur-no (il flusso può essere mono o bidireziona-le, essendo i campi di controllo presenti an-che in un “frame” di tipo informativo).Il controllo di errore é basato su meccanismiCRC (Ciclic Redundancy Check) – ovvero sulcalcolo del resto utilizzando il testo come di-videndo e un polinomio standard come divi-sore; questo algoritmo rende la trasmissionepraticamente immune da errore (la probabi-lità di avere due testi differenti con il medesi-mo resto é praticamente nulla).I protocolli orientati al bit risolvono quindibrillantemente il problema della trasmissio-ne tra due entità. Lasciano però, purtroppo,aperti due problemi essenziali:❑ l’impossibilità di distinguere tra elementidi controllo trasmissivo ed elementi di con-trollo applicativo (l’ACK é ancora ambiguo –resistono ancora gli stessi problemi dei pro-tocolli orientati al carattere);❑ l’impossibilità di eseguire controlli selettiviall’interno del flusso trasmissivo (il non-ag-giornamento del limite inferiore della finestradetermina il blocco completo a livello tra-smissivo, senza la possibilità di operare inmodo selettivo su eventuali differenti flussiapplicativi in essere tra i due interlocutori).Contestualmente, dalla fine degli anni ’60, so-no stati messi a punto protocolli per il trasferi-mento dei dati a pacchetto in reti geografiche.Alcune delle idee più feconde sono maturatecon un lento processo di trial & error nell’am-bito del progetto ARPANET, il progenitore di

Internet (vedi http://www.isoc.org/inter-net/history/; [5]).I problemi della comunicazione di dati e lastrutturazione dei relativi protocolli hannoportato nei primi anni ’80 al maturare del co-siddetto modello OSI, oggetto del paragrafoseguente.

3. LE IDEE DI BASEDELLA MODERNA CONCEZIONEDEI PROTOCOLLI

Progettare e realizzare un protocollo è ad og-gi ancora un’arte, come alcuni amano dire, oforse più appropriatamente, un’opera di arti-gianato. Questo non toglie che nel tempo so-no stati sviluppati modelli e strumenti perrendere sistematico e verificabile il lavoro didefinizione e sviluppo di un protocollo.Il più famoso al riguardo è il modello OSI(Open System Interconnection), emesso co-me Standard ISO 7498 nel 1983 e recepitoquindi come Raccomandazione ITU X.200. Ilmodello si propone di definire una architet-tura funzionale completa per descrivere lacooperazione di processi remoti, residenticioè in sistemi distinti e comunicanti tra lo-ro, in altre parole in grado di trasferire strin-ghe binarie con date caratteristiche di pre-stazione in termini di capacità e affidabilità.Punti chiave del modello sono la decompo-sizione del complesso delle funzioni di co-municazione e di elaborazione locale del-l’informazione in sotto-insiemi strutturatigerarchicamente e la formalizzazione delleinterazioni e dei flussi informativi nelle varieinterfacce identificate nell’architettura.Questi aspetti sono l’eredità ancora viva delmodello OSI, perfettamente identificabili eanzi alla base dello sviluppo di standardcomplessi relativi a qualsiasi tipo di rete. Èquindi su questi aspetti che sarà posto l’ac-cento nel seguito; per una descrizioneesauriente del modello OSI si possono con-sultare, oltre agli standard, che ne sono lafonte primaria, molti lavori (ottima è la de-scrizione del modello OSI contenuta nelladocumentazione tecnica Cisco [6]).L’idea di base del modello è che l’eteroge-neità e la vastità delle funzioni coinvolte nelprocesso di cooperazione è affrontabile almeglio solo suddividendo queste funzioni in


1

25

0

0

0

1

0

gruppi omogenei per livello di astrazione deltrattamento delle informazioni e per affinitàtecnologica di realizzazione.L’equalizzazione del canale trasmissivo, ilrecupero del cronosegnale associato al se-gnale numerico ricevuto, la rivelazione dierrori nei blocchi di informazione trasferiti,l’instradamento dell’informazione tra i si-stemi terminali dello scambio informativoattraverso eventuali sistemi intermedi, latranscodifica dell’informazione tra formatidiversi di rappresentazione (per esempio,da mp3 a wav per un file audio; oppure tran-codifiche tra i diversi formati adottati per lavoce nelle reti cellulari o nell’interconnes-sione tra reti telefoniche e VoIP) sono tuttiesempi di funzioni generalmente eseguitein ogni singola istanza di cooperazione traprocessi remoti e chiaramente eterogeneetra loro. Le prime due funzioni possono es-sere realizzate tipicamente con hardware ofirmware e considerano l’informazione tra-sferita tra due sistemi adiacenti (senza si-stemi intermedi) come un semplice flusso disimboli, per esempio binari. La rivelazionedi errori è realizzabile solo articolandol’informazione in blocchi delimitati e strut-turati ed è spesso realizzata in software mi-croprogrammato su schede dedicate. L’in-stradamento è una funzione di natura logi-ca, che coinvolge più sistemi, richiede l’ese-cuzione di algoritmi e procedure tipicamen-te realizzati in software all’interno del ker-nel del sistema operativo e tratta informa-zioni assunte esenti da errori e strutturatein messaggi indirizzabili. Infine, la transco-difica si applica a dati di utente, è eseguitalocalmente dal processo che ha ricevutol’informazione, assunta esente da errori ericostruita nella sua interezza così come lasorgente l’ha generata.Anche dagli esempi appena accennati è evi-dente che si possono individuare gruppi difunzioni separati, la cui esecuzione implical’interazione di sistemi diversi, o meglio, diquelle parti dei sistemi che presiedono algruppo funzionale considerato. È anchechiaro che le funzioni così raggruppate nonsono svolte in un ordine qualsiasi, ma ordi-nate in modo gerarchico. Per il destinatariodell’informazione e con riferimento agliesempi fatti sopra, occorre prima rivelare il

flusso di informazione ricevuto, eseguendotra le altre l’equalizzazione e il recupero del-la sincronizzazione, quindi delimitare bloc-chi di informazione significativi e accertarsidella loro correttezza, recuperando even-tuali errori, e così via.Nasce quindi il fondamentale concetto distrato. Uno strato dell’architettura di comuni-cazione è l’insieme delle entità appartenentia tutti i sistemi che svolgono un dato gruppodi funzioni. Le entità in concreto sono codice,hardware, schede; la loro cooperazione av-viene mediante protocolli, che hanno appun-to lo scopo di svolgere le funzioni relative al-lo strato cui appartengono le entità. Dal con-cetto di strato e di stratificazione delle fun-zioni nasce il valore aggiunto: ogni strato ag-giunge “valore” al processo di cooperazionetra i processi remoti, mediante l’azione svol-ta dalle proprie entità nell’esecuzione deiprotocolli cui sono preposte. È per esempiovalore aggiunto il poter garantire l’affidabi-lità del trasferimento informativo ad un livel-lo desiderato data un’infrastruttura fisica diper se non soddisfacente i requisiti. Oppurela capacità di recapitare al corretto destinata-rio l’informazione che gli compete, permet-tendo in ultima analisi l’interconnessionemediante una rete con condivisione delle ri-sorse, piuttosto di una connessione direttafisica, con risorse dedicate, tra ogni coppia disistemi che debbano cooperare.Il meccanismo di comunicazione tra processiin un’architettura stratificata è accuratamen-te descritto dal modello OSI, ma può forseessere esemplificato e compreso nella suaessenza con un colorito esempio, ispirato daAndrew S. Tanenbaum [1, paragrafo 1.3]. Unfilosofo cinese e un bramino indiano deside-rano dialogare; dato che parlano lingue di-verse, ognuno dei due ingaggia un interpre-te, concordando una lingua comune (dalmandarino all’inglese uno, dal sanscrito al-l’inglese l’altro). Poiché i due interpreti a lo-ro volta si trovano uno a Pechino, l’altro aBenares, essi ingaggiano un telegrafistaognuno e incaricano i telegrafisti di trasmet-tere i messaggi originati dai filosofi e tradot-ti in inglese. È chiaro che il bramino cheesprime un pensiero sta (virtualmente) dia-logando con il filosofo cinese e NON con ilproprio interprete; per attuare questo dialo-


1

0

0

1

26

go tuttavia, egli affida fisicamente il propriomessaggio all’interprete, il quale a sua voltadialoga (virtualmente) con l’altro interprete;per far questo egli affida fisicamente il mes-saggio al telegrafista che lo trasmette trami-te un mezzo fisico di comunicazione al tele-grafista remoto. Approdato qui, il messaggiorisale la “pila” in senso inverso fino al filo-sofo. Il paradigma di comunicazione è quindi“orizzontale” virtualmente, cioè i protocollidi comunicazione e cooperazione sono ese-guiti tra entità alla pari (peer entities). È“verticale” nelle modalità di attuazione, cioèle entità di uno strato (dette appunto “uten-ti”) si affidano a quelle dello strato gerarchi-camente inferiore (dette “serventi”) per sup-portare il proprio dialogo (Figura 1).L’OSI individua sette strati (Figura 2). I quat-tro più in basso, in ordine Fisico (Physical),di Collegamento (Data Link), di Rete(Network) e di Trasporto (Transport) sonorelativi alle funzioni di trasferimento del-l’informazione. I tre più in alto, Sessione(Session), Presentazione (Presentation) eApplicativo (Application), sono relativi altrattamento locale dell’informazione. Que-sta particolare suddivisione non è che unatra le possibili (e certo non tra quelle dimaggior successo). Il concetto di strato fun-zionale è invece diventato pervasivo e costi-tuisce il mattone base di tutte le architettu-re di comunicazione concepite dagli anni’80 in poi (riquadro a p. 28).

Il modello introduce una descrizione genera-le degli strati e dei loro elementi componenti,riferendosi ad un generico (N)-strato, con Nintero positivo.Un elemento basilare dei protocolli è la defi-nizione delle unità informative scambiatedalle entità di un dato strato, le così dette(N)-PDU (Protocol Data Unit dello strato N).Le trame di un protocollo MAC, i segmentidel TCP, i pacchetti IP sono tutti esempi diPDU. Il contributo del modello OSI sta nel-l’aver formalizzato gli elementi comuni dicui ogni PDU è formata, astraendo dai det-tagli implementativi:❑ una PCI (Protocol Control Information),cioè l’insieme delle informazioni di controlloche occorrono perché la PDU concorra all’as-solvimento delle funzioni del protocollo;


1

27

0

0

0

1

Sorgente

Sistema terminale

Entità di strato CollettoreFl

usso

inte

r-st

rato

Flussi intra-strato

Flus

so in

ter-

stra

to

Sistema terminale Sistema intermedio

FIGURA 1Trasferimentodell’informazionein un’architetturaa strati

7 - Applicazione6 - Presentazione5 - Sessione

4 - Trasporto3 - Rete2 - Collegamento1 - Fisico

7 - Applicazione6 - Presentazione5 - Sessione

4 - Trasporto3 - Rete2 - Collegamento1 - Fisico

Funzioni di elaborazione

Rete di TLC

Funzioni di comunicazione

FIGURA 2Schema dell’architettura OSI

0

❑ una SDU (Service Data Unit), opzionale,parte dedicata al trasporto dei dati offertidallo strato superiore (Figura 3).È importante osservare che la definizione di(N)-PDU come unione di una (N)-PCI e di una(N)-SDU è ricorsiva, nel senso che a sua vol-ta la (N)-SDU corrisponde (nel caso più sem-plice) ad una (N + 1)-PDU. Il punto di vistadello strato N sulla (N)-SDU è che essa con-

tiene i dati del livello superiore (l’utente, insenso OSI naturalmente), affidati per il tra-sferimento alle entità dello strato N e trattaticome una “scatola nera”; il protocollo dellostrato N si impegna a effettuare il trasferi-mento consegnando i dati di utente alle en-tità di destinazione dello strato N + 1, dopoaver aggiunto il proprio “valore” (per esem-pio, garantito l’assenza di errori e di fuori se-quenza entro un fissato margine di probabi-lità di successo). Gli stessi dati, visti dal livel-lo N + 1, sono invece un gruppo strutturato dibit rappresentanti un messaggio dell’(N + 1)-protocollo (una (N + 1)-PDU), che può a suavolta essere separato in una parte che con-tiene informazioni di controllo, la (N + 1)-PCI,e in una eventuale che contiene i dati del li-vello superiore N + 2, la (N + 1)-SDU.Può sembrare un modello astratto, artificialee non corrispondente alla multiforme realtàdei protocolli reali. In effetti, è una delle chia-vi interpretative e di razionalizzazione nelladefinizione e sviluppo di protocolli più utili


1

0

0

1

28

I sette livelli proposti nel modello OSI

Livello “1”: il livello fisico. É responsabile della codifica del segnale a livello elettrico, delle procedure di “handshaking” per la creazio-ne e il mantenimento dei canali trasmissivi e anche delle specifiche strutturali dei connettori e dei mezzi di trasmissione. Le sue fun-zioni variano secondo la natura del canale trasmissivo.Livello “2” il livello di collegamento. É responsabile della correttezza e della integrità dei dati trasmessi. I meccanismi utilizzati sonoquelli descritti nel paragrafo 2.Livello “3”: il livello di rete. É responsabile dell’instradamento delle informazioni. É uno dei livelli più complessi e può essere “connes-so” o “non connesso”: un protocollo connesso invia dati al sistema terminale (DTE) destinatario solo dopo una fase di negoziazione incui i due DTE concordano sulla modalità di trasmissione (dal banale “essere pronti a ricevere” ad una complessa negoziazione sullaqualità del servizio). Ci sono ovviamente vantaggi (e svantaggi) in ognuna delle due soluzioni. Esempi di protocolli connessi sonol’X.25 e l’ATM; un esempio universale di protocollo non connesso é l’IP di Internet (per inciso, questa affermazione ci permette di capi-re perché Internet non é nativamente adatta a gestire connessioni in cui é richiesta una qualità garantita, ad esempio la voce!).Livello “4”: il livello di trasporto. É il primo livello di dialogo tra i due DTE ed é responsabile della correttezza della trasmissione daestremo a estremo (end-to-end). Notiamo che il livello “2” e “3” hanno un significato locale: solo i due interlocutori remoti possono in-fatti avere il controllo completo (e inconfutabile) della correttezza della trasmissione. Ciò é evidente in caso di anomalie della rete (per-dita di blocchi di informazione). Le funzioni del livello “4” variano in funzione della qualità della rete di trasporto. Altre importanti fun-zioni di questo livello sono il multiplexing (ovvero l’affasciamento contemporaneo di più connessioni eventualmente in essere tra i dueDTE remoti), il controllo di congestione e il controllo di flusso.Livello “5”: il livello di sessione. Cominciamo ad essere vicini al mondo applicativo. Il livello “5” si occupa degli strumenti che servonoalla gestione del dialogo applicativo (che può essere di natura estremamente varia: ad esempio un’applicazione che pilota una stam-pante remota, oppure due programmi che cooperano per eseguire una transazione congiunta). Il livello di sessione definisce ad esem-pio i turni di dialogo, mette delle “pietre miliari” per permettere ai programmi di sincronizzarsi su punti concordati, ad esempio in ca-so di anomalie nel flusso trasmissivo. É importante sottolineare che il significato di questi “paletti” é definito dall’applicativo che li uti-lizza; ancora dunque, come in tutta l’architettura OSI, essi sono un servizio fornito al livello superiore (l’applicazione, in questo caso)e dunque non hanno un significato assoluto.Livello “6”: é il livello di presentazione. Potrebbe essere inglobato nel livello di sessione. É responsabile della codifica e della presen-tazione dell’informazione. Livello “7”: il livello applicativo. Qui si possono ingenerare delle confusioni. Il livello applicativo infatti non definisce le “applicazioni”,ma i servizi applicativi. Servizio applicativo é ciò che serve all’applicazione finale (il processo di business) per lavorare in un ambienteaperto e distribuito. Un esempio di servizio applicativo universalmente utilizzato é la posta elettronica (non é essa stessa un’applica-zione, essendo l’applicazione il client di posta che permette di comporre il messaggio o l’applicazione verticale che muove informa-zioni usando i meccanismi di posta).

(N)-PDU

(N – 1)-PCI (N – 1)-SDU

(N – 1)-PDU

Livello N

Livello N – 1

FIGURA 3Struttura delle unità

informative nelmodello OSI

tra quelle fornite dal modello OSI. L’approc-cio a scatole cinesi, indipendenti nella defini-zione delle procedure interne, è l’elementoabilitante per uno sviluppo modulare e inte-roperabile di sistemi complessi, che vannospesso soggetti nel corso della loro vita adaggiornamenti tecnologici.Un esempio di annidamenti di PDU e aggiun-ta di informazioni di controllo da parte di en-tità di strati successivi è mostrato nella figura4. Per ogni strato la relativa PDU è esplicita-mente mostrata con la sua informazione dicontrollo (in verde) e la parte che ospita i da-ti dello strato superiore (in giallo). Ogni stra-to inserisce nella propria PCI quello che servealle funzioni del relativo protocollo di strato(indirizzi, campi di versione, di lunghezza equalificazione delle parti che seguono, nu-merazione per il controllo di sequenza, ri-scontri, flag per gestire la consegna dei dati,la loro eventuale frammentazione, campi dicontrollo di errore ecc.).Una PDU può ridursi alla sola PCI: con riferi-mento all’esempio in figura 4, i segmenti TCPusati dal destinatario dei dati come riscontrosono tipicamente (ma non necessariamente)ridotti alla sola intestazione di 20 byte. In ge-nerale, un protocollo si svolge attraverso loscambio di PDU tra le entità dei sistemi coin-volti. Le PDU assolvono compiti di controllo

(per esempio quelli richieste nel caso di in-staurazione di una connessione preliminar-mente all’invio dei dati), di gestione (peresempio PDU per verificare la presenza del-l’entità remota o per effettuare misure), di tra-sporto dei dati di utente. Nei protocolli mo-derni le PDU sono stringhe binarie, strutturatein “campi”, cioè composte di sequenze di bitche sono interpretate in funzione della posi-zione che esse occupano nell’ambito dellaPDU, del proprio contenuto binario e di altricampi della PDU. È fondamentale rammenta-re che i bit sono bit e la rappresentazione diuna PDU come composta da campi con i pro-pri nomi in bell’ordine, come nella figura 4, èsolo nella mente di chi concepisce il protocol-lo e non è “visibile” al codice o all’hardwareche lo esegue. È quindi fondamentale garanti-re la possibilità di delimitare le PDU e quindidi scomporle in modo univoco nei campi co-stituenti, comprese le opzioni e le variantipossibili (questa funzione si chiama parsing).Il formato delle PDU, sia esso specificato me-diante rappresentazione dei campi compo-nenti come nella figura 4 oppure con metodipiù sofisticati quali ASN.1 (come accade inmolti esempi di protocolli soprattutto di livel-lo applicativo), permette di descrivere gli ele-menti con i quali realizzare il servizio offertodal protocollo.


1

29

0

0

0

1

TCP header User data

IP header

Destination SAP Source SAP Control

DestinationAddressPreamble Source

AddressFrameType

User data

User data

User data CRC

Strato di Trasporto20 byte [+options] Variable ≥ 0

20 byte [+options] Variable ≥ 0

1 byte 1 byte 1 – 2 byte

8 byte 6 byte 6 byte 2 byte 4 byte46 – 1500 byte

Variable ≥ 0

Strato di Rete

Sotto-strato LLC

Sotto stratoMAC

Strato di Collegamento

FIGURA 4Esempio di relazione tra PDU: dall’alto verso il basso sono mostrati un segmento TCP, un pacchetto IP, una tramaLLC e una trama Ethernet

0

Un protocollo di strato Noffre servizio alle (N +1)-entità; esse possono stimolare le entità dellivello servente (lo strato N) mediante “primiti-ve” di servizio (Figura 5): per esempio, il trasfe-rimento di una PDU di dati di utente avvieneemettendo una primitiva di Data-Request, nel-la quale si passano come parametri quella chesarà la (N)-SDU e parametri aggiuntivi (para-metri di QoS, indirizzi di destinazione, specifi-che sulle modalità di trattamento dei dati daparte dell’(N)-protocollo, per esempio richie-sta di cifratura). Il protocollo dello strato N ef-fettua il trasferimento dei dati con tutti i mec-canismi che gli sono propri (per esempio quel-li di rivelazione e recupero degli errori), e pre-senta infine una primitiva di Data-Indication al-la (N + 1)-entità destinataria.In concreto le primitive possono essere se-gnali su circuiti interni a una macchina, inter-rupt (software o hardware), chiamate a fun-zioni o procedure nell’esecuzione di un pro-gramma, sia del sistema operativo sia di unprocesso di area utente, a seconda del livelloarchitetturale degli strati cui le primitive si ri-feriscono. Questa enorme varietà di modalitàrealizzative viene ricondotta a concetti sem-plici e unitari, di grande valore nel concepire,definire e sviluppare in concreto i protocolli.La razionalizzazione del funzionamento di unsistema inserito in una rete di comunicazionesi è dimostrata feconda. Non c’è standard disistemi di comunicazione che non descriva lefunzioni svolte strato per strato e quindi leprimitive per quanto riguarda le interfacce“verticali” e le procedure protocollari perquelle “orizzontali”, cioè tra entità alla pari insistemi remoti.Altri due concetti fondamentali e ricorrenti nei

sistemi di telecomunicazione sono la multi-plazione (con la corrispondente funzione in-versa di demultiplazione) e la connessione.In termini OSI un protocollo di strato N effet-tua multiplazione quando si pone al serviziodi una molteplicità di (N + 1)-entità (gli utentidel servizio erogato dal (N)-protocollo) e tra-sporta quindi con le proprie (N)-PDU flussi didati appartenenti a diverse relazioni tra en-tità di strato N + 1. Un esempio è il protocolloIP che trasporta segmenti appartenenti a di-verse connessioni di trasporto TCP, data-grammi di diversi flussi UDP e unità di dati dimolti altri protocolli. Un aspetto cruciale, im-mediatamente ovvio dal modello astrattodella multiplazione è che deve essere inseritanella (N)-PCI informazione sufficiente a iden-tificare a quale (N + 1)-entità è destinata unadata (N)-SDU. Nell’esempio del pacchetto IP,l’informazione in questione è l’indirizzo IPdell’interfaccia di destinazione del pacchettoe il campo Protocol Type che specifica a qualemodulo software del destinatario va conse-gnato il contenuto di dati del pacchetto IP.La connessione è un’associazione logica tradue o più entità remote che permette loro diistanziare e mantenere aggiornati coerente-mente i rispettivi stati di evoluzione nell’ese-cuzione di un protocollo di strato. Il concettodi connessione accoppiato con quello di ar-chitettura stratificata si rivela molto potente:esso permette di evidenziare in modo chiaroe di razionalizzare le interdipendenze tra si-stemi e tra diversi compiti svolti nel processodi comunicazione. Interagire con o senzaconnessione è lo spartiacque tra la possibi-lità di supportare qualità di servizio negozia-ta, affidabilità del trasferimento dei dati, e


1

0

0

1

30

(N + 1) - entità

(N + 1) - strato

(N) - strato

(N + 1) - entità

(N) - utente

(N) - SAP (N) - SAP

(N) - protocollo

(N) - fornitore

Rich

iest

a

Conf

erm

a

Indi

cazi

one

Risp

osta

(N) - utente

(N) - entità (N) - entità

FIGURA 5Interazioni tra strati

adiacenti perla fornitura

di un elemento diservizio secondo

il modello OSI

molti altri arricchimenti del servizio offertoda un protocollo e la semplicità di realizza-zione e quindi la parsimonia di risorse di me-moria e calcolo richieste. Per mantenere insequenza completa i diversi frammenti di da-ti trasferiti nell’ambito di un’interazione traentità remote, controllare il flusso o garantireun fissato grado di servizio (ritardo peresempio) sono necessari contatori e mecca-nismi di recupero dei dati mancanti. Questo èpossibile instaurando preventivamente unaconnessione (quindi inizializzando i contato-ri in modo coerente). D’altra parte questo ri-chiede buffer e esecuzione di molte istruzio-ni in entrambi i “capi” della connessione.Inoltre rende complicato adattarsi a variazio-ni del servizio offerto dagli strati sottostanti. È importante osservare che, coerentementecon il principio dell’indipendenza tra strati, lamodalità di funzionamento con o senza con-nessione di un (N)-protocollo non influenzaquelle dei protocolli degli strati adiacenti.Prendiamo il colloquio tra un PC di utente pri-vato e il web server del suo ISP. Lo strato fisicotra PC e modem ADSL è tipicamente realizzatocon interfacce USB (con connessione) ovveroEthernet (senza connessione). Al di sopra siusa il PPP (con connessione) o il MAC Ethernet(senza connessione). Tra modem ADSL e NASsi usa una connessione ATM (strato due). Perlo strato di rete, il terzo, si usa IP tra PC e webserver (senza connessione), al di sopra si usaTCP (con connessione) e al di sopra ancoraHTTP (senza connessione).Il vantaggio della modalità a connessione è lapotenziale ricchezza di funzioni eseguibili so-lo grazie all’associazione logica stabilita trale parti con la connessione; il vantaggio dellamodalità senza connessione è la semplicitàdelle entità che eseguono il protocollo1. Nonesiste una soluzione migliore dell’altra. Inogni sistema e strato l’una o l’altra sono lepiù indicate, dato il contesto. Molti protocollidi strato due sono realizzati con la possibilitàdi optare per l’una o l’altra modalità, in fun-zione degli scopi e delle risorse che le entitàcoinvolte possono dedicare all’interazione.

Importanti valori aggiunti dai protocolli di co-municazione riguardano aspetti trasversalidal punto di vista architetturale, nel sensoche il loro trattamento non può essere confi-nato in generale ad un ben determinato stra-to. Se ne citano qui tre: la Qualità di Servizio(QoS, Quality of Service), la sicurezza (nelsenso del termine anglosassone security, danon confondere con safety), il risparmioenergetico.La QoS si concreta in metriche di prestazionespecifiche dello strato nella quale si conside-ra: può riferisce al rapporto segnale-rumoreo BER (Bit Error Ratio) di un collegamentotrasmissivo nello strato fisico, alla portatamedia e al ritardo di una connessione nellostrato di trasporto, alla flessibilità d’uso delprotocollo da parte dell’utente nello stratoapplicativo. La “portata” della QoS è legataallo strato al quale essa è misurata: si trattaovviamente di QoS da estremo a estremo ne-gli strati alti, di QoS locale per gli strati bassi.Il progetto di un protocollo è sempre la rispo-sta a un’esigenza di QoS: gli algoritmi che nesono alla base, eseguiti dalle entità coinvoltenel protocollo hanno sempre obiettivi presta-zionali che mirano ad aggiungere funziona-lità al trasferimento di segnali permesso damezzi fisici di comunicazione allo scopo fina-le di supportare la cooperazione di processiapplicativi più o meno sofisticati.Gli aspetti di sicurezza sono anch’essi trasver-sali nel senso che possono essere introdotti inprotocolli di tutti gli strati: si pensi alla cifratu-ra a livello fisico, alla realizzazione di tunnelsicuri al livello rete, ai processi di autentica-zione al livello di collegamento o applicativotipici ormai della maggior parte delle nostreinterazioni in rete (dall’accesso alle reti cellu-lari o WiFi, alle connessioni PPP via modem,all’accesso a porzioni riservate di siti web oserventi di posta elettronica, ad applicazionidi commercio elettronico). Basti qui osservareche l’introduzione di funzioni di sicurezza(confidenzialità, autenticazione, integrità,non-ripudio, disponibilità) può tradursi in ag-giunta di procedure a protocolli esistenti, ma-gari attraverso campi opzionali o nuove PDUdefinite nel protocollo, oppure può tradursinella definizione di veri e propri nuovi proto-colli, il cui precipuo obiettivo di arricchimentodi valore è offrire servizi di sicurezza nell’am-


1

31

0

0

0

1

1 Una diffusa realizzazione (4.4BSD-Lite distribu-tion) di TCP e IP (il primo con connessione, il se-condo senza) consta di circa 15000 e 2000 righe dicodice rispettivamente.

0

bito dell’interazione tra utenti e/o processi.Infine, considerazioni di dissipazione dienergia nella comunicazione diventano im-portanti quando almeno alcuni dei sistemipartecipanti alle interazioni protocollari so-no alimentati a batteria, come nelle reti cel-lulari e wireless (WLAN, WPAN, reti di senso-ri). È intuitivo che i protocolli di livello fisicosiano interessati nella gestione dell’energia(si veda per esempio la funzione di controllodi potenza), ma non meno di questi sonocoinvolti nel risparmio energetico anche iprotocolli degli strati di collegamento, rete etrasporto. Due esempi per chiarire. Il recu-pero di errori mediante ritrasmissione ha uncosto energetico; l’urgenza e la stessa op-portunità di ritrasmettere una PDU di dati vaquindi bilanciata con il costo energetico chequesto comporta. Per sistemi che preveda-no un accesso multiplo coordinato da un ap-posito protocollo (si chiamano protocolliMAC, Medium Access Control), come la mag-gior parte dei sistemi di accesso wireless, leprocedure di accesso prevedono spesso lafunzione di ascolto del mezzo trasmissivoper evitare o almeno limitare le collisioni;una scheda wireless consuma una quantitàdi energia quasi uguale sia quando è in tra-smissione sia quando è in ascolto2. È chiaro

come anche l’aspetto energetico deve esse-re valutato nella definizione di protocolli chedebbano funzionare in sistemi alimentati abatteria.

4. UN CONFRONTO TRA OSIE TCP/IP

Le architetture a strati del modello OSI e diInternet sono rappresentate nella figura 6.Esistono infiniti commenti su tema del con-fronto tra le due; quasi tutti si arrampicanosui vetri cercando impossibili paragoni traprotocolli, strati e quant’altro.Vale qui sottolineare l’unica vera differen-za, concettuale e non strutturale. OSI nascecome un modello di riferimento, TCP/IP na-sce invece come pila di protocolli. OSI è ilrisultato di uno sforzo di modellizzazioneper creare regole di comportamento nell’in-terconnessione tra sistemi aperti. Proprioper questo OSI è più importante per quelloche non dice rispetto a quello che dice (OSIinfatti non dice nulla circa la dimensionedei sistemi, la loro dislocazione geografica,la qualità della rete di trasporto, sul nume-ro di macchine in cui le varie funzioni ven-gono realizzate ecc.). Nell’OSI la definizio-ne dei protocolli è stata aggiunta in un se-condo tempo e rappresenta la componentemeno significativa: i protocolli OSI sonomorti prima di nascere, uccisi dalla loro ge-neralità e universalità (che fa rima con am-biguità e complessità). TCP/IP è invece il ri-sultato di uno sforzo per realizzare un siste-ma di scambio dati semplice, robusto, di fa-cile e sicura interpretazione, implementabi-le in modo quick and dirty. Del resto il mot-to dell’IETF, l’ente che presiede allo svilup-po delle norme di riferimento per Internet,è We believe in rough consensus and run-ning code.Un altro punto importante è tenere presen-te che la razionalizzazione e astrazione defi-nita con il modello OSI è storicamente po-steriore alla concezione delle reti che oggiconosciamo come Internet; inoltre il puntodi vista preso da coloro che hanno sviluppa-to quest’ultimo paradigma è assumere perdato di fatto l’eterogeneità tecnologica del-le reti locali e geografiche usate per inter-connettere i sistemi di elaborazione (le co-


1

0

0

1

32

Come rinunciare alla connessione e mantenere uno stato:

HTTP e i cookies

Nel caso di un server applicativo che deve contemporaneamente trattarenumerose richieste di servizio da parte di una popolazione di client puòessere molto oneroso inizializzare e far evolvere uno stato per ogni singo-la comunicazione, Queste considerazioni hanno per esempio portato a de-finire il protocollo alla base del World Wide Web , l’HTTP, prevedendo unamodalità di comunicazione senza connessione (si dice che HTTP è state-less). Ogni interazione di un client con un server web si riduce ad unoschema query-response: il client chiede un contenuto, il server lo rintrac-cia, lo invia e ...si può dimenticare del client!Per estendere le capacità dei server web, ferma restando la natura state-less di HTTP, sono stati introdotti i cosiddetti cookies. Un server impac-chetta lo stato riguardante l’interazione con il client che lo ha contattato elo invia al programma client, il quale lega il cookie all’URL del sito che glie-lo ha inviato. Alla successiva interazione indirizzata a quell’URL da parte diquel client, il cookie viene inviato al server, così “rammentandogli” lo sta-to della precedente interazione. Un bell’esempio di come mantenere lasemplicità del paradigma di comunicazione connectionless e ottenere co-munque una “memoria”, magari con qualche rischio per la sicurezza.

2 Nel caso di schede WiFi l’ascolto (carrier sensing) costa circa l’80% delconsumo energetico richiesto in trasmissione.

siddette sotto-reti: reti SNA, DecNet, Apple-talk, LAN Ethernet, reti wireless) e puntare adefinire un livello di inter-rete per realizzarel’interconnessione globale (il collante uni-versale è IP) e fornire il supporto per l’ese-cuzione della più ampia varietà di processiapplicativi. Illustra efficacemente questaconcezione dell’architettura Internet il co-siddetto modello a clessidra, dovuto a Hen-ning Schulzrinne (Figura 7).Nell’architettura Internet si distingue quindiun livello di sotto-rete, che comprende glistrati bassi dell’architettura: può ridursi aglistrati fisico e di collegamento (come nel casodelle LAN e dell’ATM) può essere incredibil-mente complesso (si veda il caso delle retidorsali del GPRS).Sopra questo macro-livello basso si pone il li-vello unificante di inter-rete, la cui funzionespecifica è indirizzamento, multiplazione ecommutazione. Queste funzioni sono svolteda un unico protocollo, l’Internet Protocol(IP), corredato di alcuni altri protocolli ausi-liari (ICMP, ARP, RARP).Il primo strato con significato da estremo aestremo è quello sopra al livello IP, corrispon-dente grosso modo al livello di trasporto del-l’architettura OSI, così come il livello IP corri-sponde essenzialmente allo strato di rete. Idue principali protocolli di questo livello so-no il Transmission Control Protocol (TCP) e loUser Datagram Protocol (UDP).Infine, al di sopra del livello di trasporto sicolloca il livello applicativo, corrispondentepraticamente agli strati di utilizzazione delmodello OSI, cioè quelli di sessione, presen-tazione e applicativo vero e proprio.Da questa pur sommaria descrizione si notail blando grado di dettaglio con il quale nelmodello Internet si descrivono i livelli bassidell’architettura, rispetto all’attenzione inessi posta dal modello OSI e la prolissa e in-dustrialmente poco prolifica visione del mo-dello OSI relativamente agli strati alti, com-pattati dal modello Internet in un genericolivello applicativo, la cui effettiva realizza-zione è tutta demandata al software appli-cativo residente sui sistemi terminali e ineventuali sistemi intermedi (proxy, mediagateway ecc.). È chiaro che i due modelli ri-spondono a esigenze e visioni maturate inmondi diversi, almeno nel momento in cui i

modelli si affermarono (anni ’70 e primissi-mi anni ’80): l’industria dei computer e lecomunicazioni di dati per il modello Inter-net; il mondo delle telecomunicazioni clas-siche, telefoniche prima di tutto, per il casodel modello OSI. Traccia di questo si ritrova,tra gli altri aspetti, nella matrice dei princi-pali Enti di normativa promotori dello svi-luppo di nuovi protocolli: ITU-T, ETSI, 3GPPper le reti cellulari, le reti di trasporto e ingenerale tutte quelle con un forte contenu-to di tecnologia di telecomunicazione (vici-ne ai livelli più bassi dell’architettura: fisico,


1

33

0

0

0

1

OSI Reference Model TCP/IP Conceptual Layers

7

6

5

4

3

2

1

6

5

4

3

Application

Presentation

Session

Transport

Network

Data Link

Physical

TCP TransmissionControl Protocol

Ethernet, 802.3,802.5, FDDI,and so on.

Application

Network Interface

IP Internet Protocol

FIGURA 6Pile protocollari OSI e Internet a confronto

email www phone...

Ethernet PPP...

Copper fiber radio...

TCP UDP...

IP

SMTP HTTP RTP...

CSMA async sonet...

FIGURA 7Modello a clessidradell’architetturadi Internet

0

di collegamento); IETF, IEEE vari Fora e con-sorzi industriali per quanto riguarda Inter-net, le reti wireless, le reti in area locale, ingenerale quelle reti miranti in primo luogoall’interconnessione dei computer (vicineper lo più ai livelli dalla rete in su, quasiesclusivamente realizzate in software, alpiù firmware per il caso delle reti wireless edelle schede per LAN).La storia recente ha visto il crescente suc-cesso del modello Internet. Questo sposta-mento di paradigma avvenuto a partire dallametà degli anni ’90, manifestato anche nellaterminologia (si parla oggi di ICT, non di tele-comunicazioni), tra le molte conseguenze haavuto anche un significativo impatto sul mo-do di concepire, ideare, sviluppare e gestire iprotocolli. Da un approccio “telecom” con-notato da tecnologie ad hoc, spesso dipen-denti da specifici sviluppi hardware, comun-que con piattaforme di sviluppo che sologrossi laboratori aziendali specializzati po-tevano affrontare (esempio classico: ISDN),si è passati con il prevalere del modello In-ternet a protocolli realizzati soprattutto insoftware, sia nel kernel dei sistemi operativisia spesso con programmi che girano in userspace; sempre più spesso i protocolli sonomaterialmente realizzati usando codice sor-gente in C, java o altri linguaggi di livello re-lativamente alto; sempre più spesso c’è unintreccio inestricabile tra il software deicomputer e quello dei protocolli rivolti allasoluzione di problemi di comunicazione espesso il tutto è fornito come codice opensource, soprattutto con il progressivo affer-marsi di Unix nei suoi vari dialetti (vedi Linuxsui PC commerciali); anche i protocolli dei li-velli di collegamento del MAC e persino mol-te funzioni tradizionalmente appartenenti allivello fisico, sono oggi realizzati utilizzandoDSP o FPGA, con uno sforzo di sviluppo foca-lizzato sulla programmazione a livello relati-vamente alto, grazie agli strumenti di CAD ecompilazione che fungono da intermediaritra il codice sorgente prodotto dallo svilup-patore e quello che deve essere caricato nel-l’hardware. Queste tendenze hanno abbas-sato drammaticamente la soglia economicaper lo sviluppo, la sperimentazione, la valu-tazione e misura di protocolli di comunica-zione, nello stesso tempo fondendo le com-

petenze necessarie con quelle proprie dellacomputer industry. Se si vuole anche esserepolemici, queste tendenze hanno anche in-generato qualche confusione e concessospazio a tecnici di scarsa professionalità.

5. CROSS-LAYERING OVVEROIL MODELLO OSI ULTIMAPAROLA?

Le architetture stratificate poggiano su un as-sioma: le funzioni attivate per la cooperazionedi processi applicativi attraverso una rete dicomunicazione sono raggruppate in insiemiomogenei (gli strati) e i protocolli che realizza-no queste funzioni sono definiti all’interno diciascuno strato indipendentemente dagli altrise non per i vincoli imposti dalle interfacce trastrati adiacenti (le specifiche delle primitive diservizio tra strato utente e strato fornitore); inaltri termini, il servizio che le entità di unostrato si aspettano da quelle dello strato infe-riore è specificato a livello dell’interfaccia tra idue strati (il Service Access Point tra lo stratoN + 1 e N, (N)-SAP, vedi Figura 5), ma non èspecificato il modo in cui le entità dello stratoN devono poi realizzare quel servizio (i proto-colli dello strato N).È un tipo di approccio che fa tesoro dellamassima “divide et impera”, ed è un classicoesempio di decomposizione di quello chepuò essere concepito come un grande pro-blema di ottimizzazione vincolata in sotto-problemi collegati gerarchicamente, che pos-sono essere tuttavia risolti separatamente,raggiungendo tipicamente un sub-ottimo co-me soluzione globale (ma alla soluzione siarriva!). Questo è l’approccio che ha resopossibile la definizione delle reti cellulari,delle reti di trasporto (SDH, ottiche), dellastessa rete Internet.Esistono alcuni contesti dove l’ottimizzazioneperseguibile derogando alla rigida regola diseparazione dei protocolli di strati diversi èabbastanza pagante da superare i vantaggi diflessibilità e potenziale semplicità offerti dalladecomposizione in strati internamente indi-pendenti. In questi casi, gli algoritmi che sonosvolti dalle entità che partecipano al protocol-lo utilizzano informazioni (eventi, misure, da-ti) appartenenti anche ad altri strati per otti-mizzare le prestazioni ottenibili: si parla di


1

0

0

1

34

protocolli cross-layer. È questo un approccioche ha riscontrato una fortuna crescente negliultimi anni in almeno due contesti molto signi-ficativi: le reti wireless e il controllo della con-gestione nelle reti a pacchetto.Nel primo caso, quando si tratta di servireuna popolazione di utenti che condividonouna risorsa radio, esiste una relazione strettatra gli effetti di scelte effettuate nei protocol-li di livello fisico, MAC, di collegamento e direte. Per esempio, si pensi alle operazioni discheduling dei pacchetti effettuati da unastazione base, utilizzando come metricheguida la QoS differenziata da offrire ai diversiflussi di dati oppure criteri di fairness; si trat-ta di una funzione collocata tipicamente nel-lo strato di collegamento o di rete. È chiaroche questa funzione ha un nesso molto stret-to con la gestione delle risorse radio in termi-ni di quali codici, potenze, frequenze, timeslot usare in trasmissione, la codifica e mo-dulazione dei dati, tutte decisioni proprie deiprotocolli di strato fisico. Molti lavori sia teo-rici sia sperimentali hanno mostrato gli ampimargini di guadagno possibili se si formulaun problema congiunto (cross layer appunto)che tenga congiuntamente conto delle carat-teristiche del traffico e del canale radio [7, 8].In alcuni contesti, come le reti di sensori, ilcross-layering porta a definire problemi checoinvolgono congiuntamente anche più didue strati. I parametri da usare per trasmet-tere i dati (potenza, modulazione, codifica),quando trasmettere tenendo conto di obiet-tivi di portata (throughput) equità di acces-so e contenimento dell’interferenza o al li-mite delle collisioni, l’instradamento da se-guire secondo un paradigma di tipo multi-hop (raggiungere la destinazione con ununico passo, consumando maggiore poten-za e provocando più interferenza oppure ef-fettuare più passi, aggiungendo quindi ri-tardo, consumo energetico e risorse di cal-colo e memoria dei nodi intermedi?) sonotutti aspetti che devono essere consideratiassieme se si vuole raggiungere un’efficien-za ottima complessiva del sistema in termi-ni di prestazioni e costo. Nel caso delle retidi sensori, il problema è abbastanza delimi-tato e le condizioni operative sufficiente-mente “estreme” da motivare un approccioolistico, di tipo cross-layer, anziché lo svi-

luppo di protocolli indipendenti nel sensodelle architetture stratificate.Altro esempio di cross-layering è dato dallefunzioni di controllo di congestione, svoltanei protocolli di trasporto da estremo a estre-mo (per esempio mediante controlli a fine-stra variabile e adattiva, come nel TCP) e lepolitiche di scheduling e gestione delle codeinterne ai nodi della rete, le cosiddette politi-che di Active Queue Management, AQM.Queste ultime sono funzioni ovviamente ap-partenenti a protocolli dello strato di rete, mail loro effetto sulle decisioni e le prestazioniottenibili dai protocolli di trasporto sono taliche un approccio di ottimizzazione congiuntacross layer è posto all’attenzione della comu-nità di ricercatori e sviluppatori che lavoranosu questi problemi [9].Come tutti i modelli realmente utili, anche ilmodello OSI e gli analoghi modelli alternativiintroducono astrazioni e concetti di base, fon-damentali per uno sviluppo ordinato ed effi-cace di sistemi complessi, ma vanno capitinelle loro motivazioni e usati con capacità diadattamento ai contesti tecnologici e applica-tivi specifici, senza dogmatismo. Del resto an-che l’indipendenza funzionale e quindi realiz-zativa dei protocolli di strati distinti, infrantadall’ottimizzazione cross-layer, ha dimostratodi conseguire sì sub-ottimi, ma di potersi av-valere con estrema tempestività delle diversevelocità di evoluzione delle tecnologie basedei diversi strati: si veda l’esempio del Wi-Fi,nel quale il livello MAC è rimasto invariato nel-la sostanza dal 1997 a oggi3, mentre sono sta-te messe a punto quattro principali versionidel livello fisico (IEEE 802.11 base e successi-vamente IEEE 802.11b/a/g).

6. L’EVOLUZIONEDELLO STRATO APPLICATIVO

L’evoluzione del modello OSI é insita nella suastessa struttura; OSI é assolutamente genera-le. La generalità del modello OSI e del suo rivo-luzionario concetto di strato permette infatti dicambiare, sostituire, arricchire di funzioni uno“strato” senza alterare l’impalcatura.


1

35

0

0

0

1

3 Solo con gli imminenti standard IEEE 802.11e e802.11n si intende rimettere mano alla definizionedel protocollo MAC.

0

Le nuovi reti wireless (WiFi, WiMax) possonorimpiazzare le tecnologie esistenti dando mi-gliori o differenti servizi di connettività ai DTEfinali e lasciandone inalterate le funzionalitàapplicative. Se si hanno reti di trasporto a lar-ga banda o a qualità garantita, si possonocostruire sessioni multimediali in cui sonopresenti voce ed immagini. I principi noncambiano.A livello applicativo abbiamo avuto le evolu-zioni più significative – non in termini con-cettuali, ma in termini di completezza fun-zionale. Lo strato applicativo ha infatti trat-to enormi benefici dal Web, ambiento aper-to e distribuito. Ai tempi in cui l’OSI è statoconcepito, gli unici servizi applicativi ipotiz-zabili erano quelli associati al trasporto deidati (file transfer), alla consegna dei mes-saggi (posta elettronica) oppure alla coope-razione transazionale per eseguire funzionidistribuite ma necessariamente sincrone(CCR, Commitment and Concurrency Reco-very, utilizzato per transazioni a più livelli oaggiornamenti multipli di basi di dati); in so-stanza erano i servizi ipotizzabili in architet-ture costituite essenzialmente da mainfra-me ed elaboratori satellite. Il Web, ambiente naturale in cui eseguire ap-plicazioni con presentazione e metodi di ac-cesso standard, permette di arricchire enor-memente l’insieme dei servizi applicativi di-sponibili. Il connubio tra Web ed Internet, losviluppo di infrastrutture fisiche in cui le ser-ver farm sono sempre più un’appendice na-turale della rete di telecomunicazione, per-mettono di creare un midlleware applicativoin cui le applicazioni sono una collezione diservizi, invocati ed eseguiti sulla base dellenecessità, senza nulla imporre alla loro realedislocazione fisica.Nasce dunque l’idea dei Web Services, con-cettualmente analoghi agli Application Servi-ce Elements del modello OSI, ma molto piùuniversali.Il Web Service è un middleware che permet-te di trasformare un’applicazione (un pro-gramma che meccanizza un processo di bu-siness e produce dei risultati) in un “ogget-to”, dotato di attributi e metodi, utilizzabilecome un mattoncino del lego in un ambien-te distribuito ed aperto. Per far questo e’ ne-cessario disporre di una funzione di descri-

zione del servizio, di una sua catalogazionee di un meccanismo per poterlo invocare,passargli degli input e ricevere dei risultati.L’insieme di un’architettura aperta ed uni-versale come il TCP/IP e di applicazionicreate con la logica dei Web Services rap-presenta la realizzazione più significativadel modello concepito dalla ISO nei lontanianni ’80. Se poi pensiamo di aggiungere aquesti servizi anche un’autostrada intelli-gente che coordini il flusso di informazioniscambiate tra i vari moduli applicativi (confunzioni di gestione delle code, delle prio-rità, delle retry ecc.) - ossia di aggiungereciò che è comunemente chiamato enterpri-se bus - abbiamo creato una nuova imposta-zione dei sistemi informativi in cui l’enfasi sisposta dalla gerarchia dell’elaborazione al-la granularità delle funzioni applicative e al-la loro utilizzabilità nell’ambito delle appli-cazioni finali, sempre più governate dalla di-namica del business (SOA, Service OrientedArchitecture).Scendendo un po’ nei dettagli, i Web Servicedefiniti sono:• WSDL (Web Service Definition Language):descrive cosa fa un Web Service nonché lasua operatività (come può essere invocato,come gli si possono passare i parametri);• UDDI (Universal Discovery Descriptionand Integration): facilita la pubblicazione ela ricerca dei servizi disponibili. Sono dispo-nibili funzioni di “pagine bianche” e “paginegialle” (classificazioni per nome specifico ocategoria);• SOAP (Service Oriented Application Proto-col o Simple Object Application Protocol):offre – sulla base dello standard XML- mec-canismi standard per l’interscambio diinformazioni.Non è obiettivo di questo articolo descriverein dettaglio la logica dei Web Services (Mon-do Digitale ha già trattato questo argomentoin modo completo ed autorevole – si veda atale proposito “Un’introduzione ragionata almondo dei Web Services”, marzo 2004), maevidenziare il loro posizionamento nell’ambi-to del “valore aggiunto” ai protocolli di co-municazione. Abbiamo sostituito mainframe, calcolatorisatellite, terminali con PC e applicazioni inesecuzione presso Web Farms. Abbiamo


1

0

0

1

36

cambiato il terminale 3270 con una paginaWeb, abbiamo cambiato le logical unit di IBMcon l’HTTP, abbiamo introdotto l’IP come bu-sta universale per il trasporto e l’instrada-mento. Abbiamo insomma ottenuto ambientipiù flessibili, ma viviamo ancora dei concettiintrodotti dalla Service Definition del model-lo OSI. L’ISO 7498 ha ancora molto da inse-gnare a tutti, vent’anni dopo.

Bibliografia[1] Tanenbaum A.S.: Computer Networks. 4-th edi-

tion, Prentice Hall, 2003.

[2] IBM, Systems Network Architecture, 1978.

[3] Listanti M., et alii: Telematica. Capitolo del te-sto “Manuale di Informatica”, Calderini, 1986,p. 781-902.

[4] Elementi di procedura, descrizione della tramaHDLC e della modalita’ “balanced” e “normal”.

[5] Kleinrock L.: Queueing Systems. Computer ap-plications, Vol. II, Wiley, 1976.

[6] Modello OSI, Service Definition e Protocol Spe-cification.

[7] Song G., Li Y.: Cross-Layer Optimization forOFDM Wireless Networks - Part I: TheoreticalFramework. IEEE Transactions on WirelessCommunications, Vol. 4, n. 2, March 2005,p. 614- 624.

[8] Lau V.K.N., Kwok Y.-K.R.: Channel adaptivetechnologies and cross layer designs for wi-reless systems with multiple antennas. J. Wi-ley, 2006.

[9] Wang Jiantao, Li Lun, Low Steven H., Doyle JohnC.: Cross-Layer Optimization in TCP/IP networks.IEEE/ACM Trans. on Networking, Vol. 13, n. 3,Giugno 2005, p. 582-568.


1

37

0

0

0

1

GIACOMO ZANOTTI laureato in Ingegneria elettronica al Politecnico di Milano nel 1973, ha seguito dal nascere iltema dell’Information Communication Technology. Ha ricoperto incarichi di direttore marketing e di responsa-bile di Business Unit di system integration in primarie aziende di informatica e telecomunicazioni. Attualmen-te collabora in ITnet (Internet Service Provider del Gruppo Wind) alla definizione delle strategie di sviluppo bu-siness e allo sviluppo dei canali di vendita. Ha interesse all’ambiente accademico e tecnico-scientifico, chesviluppa come membro del consiglio AICA e con attività di docenza in Master organizzati da Università (Mila-no, Padova). Ha ricoperto per quattro anni il ruolo di membro italiano nella commissione Europea IST-prize.E-mail : [email protected]

ANDREA BAIOCCHI si è laureato in Ingegneria Elettronica nel 1987 e ha conseguito il Dottorato di Ricerca in “in-gegneria dell’Informazione e della Comunicazione” nel 1992 presso l’Università di Roma “La Sapienza”. Dalgennaio 2005 è Professore Straordinario nel settore Telecomunicazioni presso la Facoltà di Ingegneria dell’U-niversità “La Sapienza”.I principali contributi scientifici di Andrea Baiocchi sono sui modelli e algoritmi per il controllo del traffico in re-ti ATM e TCP/IP, sulla teoria delle code, sulla gestione delle risorse radio in reti cellulari. I suoi attuali interes-si di ricerca sono concentrati sui modelli per l’analisi e il dimensionamento di reti a pacchetto con controllodella congestione da estremo a estremo, secondo il paradigma del TCP, e sul “mobile computing,” in partico-lare adattamento del TCP al canale wireless e sulle gestione cross-layer delle risorse nell’interfaccia radio.Queste attività sono state e sono tutt’ora scolte nell’ambito di progetti sia nazionali (CNR, MIUR) sia interna-zionali (UE, ESA), ricoprendo anche posizioni di responsabile di unità di ricerca. Andrea Baiocchi ha al suo at-tivo oltre ottanta pubblicazioni su riviste scientifiche e su atti di conferenze internazionali, ha preso parte alleCommissioni Tecniche di Programma di sedici convegni internazionali, tutti nel settore delle reti di tlc; ha an-che fatto parte della redazione del Notiziario Tecnico di Telecom Italia per dieci anni.E-mail: [email protected]

protocolli e telecomunicazioni - mondo...

Documents