continua (next page) Index of UNOFFICIAL Circumvesuviana Home Page Frasi Famose index main index Questo sotto è uno scritto che ho presentato nella primavera del '94 al corso di Tecniche Numeriche ed Analogiche.


Qualche precisazione, prima di passare al testo: i disegni sono di Gisa (una splendida pulzella che seguì il corso con me), e la collaborazione morale è di Oreste (nel senso che Gisa almeno fece i disegni sulla base delle mie indicazioni!).

Below, a little article I wrote some time ago studying internetworking and TCP/IP.

Sapendo che sarebbe stata argomento di esame per altri studenti in quella e nelle sessioni successive, mi sono permesso di aggiungere un capitolo autocelebrativo che parla dello strato MAC della rete PNet. E così il sottoscritto e la rete PNet sono diventati argomento di esame all'Università degli Studi di Salerno!

Il testo di riferimento dovrebbe essere Internetworking with TCP/IP, versione inglese perché più chiara di quella italiana.


Sommario.

  1. MAC (medium access control)
  2. Strategie per l'allocazione dei canali
  3. Il protocollo Aloha
  4. Dopo l'Aloha: altri protocolli ad accesso multiplo
  5. Protocolli senza collisione
  6. Protocolli a contesa limitata
  7. Reti locali: lo standard IEEE 802
  8. Lo standard IEEE 802.3 e la Ethernet
  9. Lo standard IEEE 802.4: token bus
  10. Lo standard IEEE 802.5: token ring
  11. Reti locali: quale scegliere?
  12. Confronto tra PBX su ISDN e LAN
  13. Reti a fibre ottiche
  14. Reti via satellite
  15. Reti a radiopacchetti
  16. Lo strato MAC della rete PNet

Livello MAC - il sottostrato di accesso al mezzo

MAC (MEDIUM ACCESS CONTROL)

Questo testo tratta il sottostrato di accesso al mezzo - cosa avviene a livello logico sulla linea durante lo scambio messaggi. Considerazioni probabilistiche e dati strettamente numerici sono stati omessi per semplicità; si rimanda al testo di Tanenbaum per i dettagli.

A livello MAC trattiamo:

Nota: salvo dove diversamente indicato, sono stati usati indifferentemente i termini "nodo" e "stazione", "frame" e "pacchetto", "net" e "rete", etc.

STRATEGIE PER L'ALLOCAZIONE DEI CANALI

La strategia più semplice è quella di assegnare ad ogni utente una "fetta" della banda utile di trasmissione e del canale (doppino telefonico, etc). Questo metodo di allocazione statica è detto multiplexing a divisione di frequenza (FDM: frequency division multiplexing). Nel caso ci siano n utenti, la larghezza di banda viene divisa in n porzioni di uguali dimensioni e dunque, avendo ogni utente la propria banda "privata" di frequenza, non ci sono interferenze. Chiaramente questo sistema non può essere efficiente nei casi in cui il numero di utenti non sia "abbastanza fisso": se l'evento di richiesta di entrata in rete e/o uscita dalla rete si verifica spesso, si può avere sovraffollamento (che costringerà a ridurre la grandezza della banda assegnata ad ogni singolo utente) o sottosfruttamento del canale trasmissivo (a causa delle molte "sottobande inutilizzate"), o ancora nel caso in cui il traffico di dati sia molto irregolare (è abbastanza comune un rapporto 1000 a 1 tra il traffico di punta e il traffico medio), per cui una divisione uniforme della banda di trasmissione comporta o spreco o sovraffollamento.

Prima di considerare altre strategie per un'allocazione dinamica dei canali, bisogna valutare cinque fattori importanti:

  1. modello di stazione: se ogni nodo (stazione) della rete è indipendente o meno dagli altri; nel primo caso se è possibile determinare la probabilità di generazione di un frame in un intervallo di tempo definito; questo modello presuppone stazioni che generino un carico di lavoro generalmente costante e che non svolgano altri task durante la trasmissione di un pacchetto;
  2. ipotesi di singolo o canale: quando tutti gli scambi di messaggi avvengono su di un singolo canale; eventuali priorità sono determinate a livello software e il problema principale è determinare la possibilità di trasmettere ("una stazione non può sollevare la mano per richiedere l'attenzione dell'insegnante");
  3. ipotesi di collisione: quando due o più stazioni trasmettono contemporaneamente, si verifica una collisione - è sufficiente che almeno un bit di una stazione venga trasmesso contemporaneamente ad un bit di un'altra per generare problemi di decodifica di un pacchetto; chiaramente in caso di collisione i pacchetti dovranno essere ritrasmessi (a meno di mezzi trasmissivi particolari, come per esempio i segnali radio, in cui si possa spesso risalire al pacchetto originale per le proprietà del mezzo; nel caso dei segnali radio, l'"effetto cattura" del segnale "più forte");
  4. suddivisione del tempo: considerando il tempo come "risorsa", si può suddividerlo in slot (intervalli discreti) in modo che un nodo sia autorizzato a trasmettere solo in momenti ben precisi (all'inizio di uno slot); questa "forzatura" permette in genere di migliorare le prestazioni (sull'Aloha, descritto più avanti, le raddoppia);
  5. rilevamento della portante (carrier detect, monitoring della linea): una informazione extra sulla possibilità di trasmissione da parte di una stazione è il carrier detect - una stazione non inizierà a trasmettere se il canale risulta già occupato, ed eventualmente fermerà la trasmissione in corso se "avverte" una collisione durante una sua trasmissione.

IL PROTOCOLLO ALOHA

Click here for Piccole Tracce! Il protocollo Aloha puro risale al 1971. Il problema da risolvere era nel numero non piccolissimo di sistemi e nella possibilità di utilizzare come canale trasmissivo solo un sistema radio, a causa della posizione geografica dei sistemi (sparsi sulle isole Hawaii). La soluzione studiata fu particolarmente semplice: permettere ai nodi della rete di trasmettere ogniqualvolta lo desiderassero - fra l'altro non c'era altra alternativa, dal momento che per il tipo di mezzo trasmissivo usato (segnali radio) il tempo per ottenere informazioni del tipo "carrier detect" era dell'ordine dei millisecondi, contro i microsecondi delle reti su cavo. A questo punto il problema si ridusse alla gestione delle collisioni; ascoltando (monitoring) il canale, un sistema può capire se il pacchetto che sta ancora trasmettendo è stato "distrutto" o meno, e nel caso di collisioni, aspetta per un periodo di tempo casuale (nel senso di "non sempre lo stesso", per evitare che tutti i nodi, usando questa strategia, si continuino a bloccare a vicenda), dopodiché riprova a trasmettere il pacchetto, fino a ottenere una trasmissione corretta. L'integrità di un pacchetto è verificabile dal destinatario grazie ad un checksum a fine pacchetto. Il checksum ha l'importante caratteristica di variare notevolmente quand'anche un solo bit del pacchetto sia stato modificato (dal rumore radio o per una collisione).

Per quanto "anarchica" possa sembrare tale strategia, in condizioni ottimali si riesce ad usare il canale trasmissivo per un buon 18%, che è un risultato notevole per sistemi che trasmettono quando desiderano e senza controllare la portante. Dato che Aloha viaggia a 9600 baud, il throughput generale è dunque intorno ai 175 bytes/secondo, sufficienti per una decina di terminali alfanumerici (sembrano pochi, ma nel 1971 erano davvero tantissimi...).

Una variante di Aloha fu proposta nel 1972. Il tempo viene diviso in slot (intervalli discreti) e dunque una trasmissione non può cominciare se non all'inizio di uno slot. Ponendo dunque dei margini "discreti" sul tempo, ed imponendo pacchetti di lunghezza fissa, si riesce ad aumentare l'utilizzo del canale trasmissivo fino al 36%, praticamente un raddoppio delle prestazioni rispetto al sistema Aloha puro.

DOPO L'ALOHA: ALTRI PROTOCOLLI AD ACCESSO MULTIPLO

In più allo stile "accesso multiplo" dell'Aloha, consideriamo ora la possibilità di verificare la portante sulla linea, e cioè verificare da parte di un nodo che nessun altro nodo stia trasmettendo. Il modello più semplice è chiaramente quello di aspettare, per poter effettuare la trasmissione, che il canale sia libero (CSMA 1-persistente, cioè Click here for Rino Cammilleri home site! carrier-sense-multiple-access in cui la probabilità di trasmettere un pacchetto appena si libera il canale è 1). Se avviene una collisione, il trasmittente aspetta per un intervallo di tempo casuale e poi ritenta l'invio con la stessa strategia - gli intervalli devono essere necessariamente casuali altrimenti potrà capitare che due sistemi si trovino sempre sincronizzati a trasmettere contemporaneamente con conseguente blocco della rete. Questa non è la strategia statisticamente migliore (arriva ad un 50% di sfruttamento del canale trasmissivo); la versione 0.5-persistente ha un utilizzo del canale superiore al 70% e la 0.01-persistente sfiora il 90%. Una strategia CSMA non persistente (cioè che diventi "intelligentemente sempre meno avida" dopo ogni rilevamento di collisione con un suo pacchetto) è curiosamente un po' meno efficiente della 0.01-persistente.

Si può ancora migliorare la strategia se c' la possibilità di ascoltare (monitoring) la linea per scoprire, durante la trasmissione stessa, se sono avvenute delle collisioni (CSMA/CD: carrier-sense multiple-access con collision-detect). Nel caso una stazione verifichi una collisione durante una sua trasmissione, interrompe immediatamente la trasmissione liberando subito il canale, senza tenerlo inutilmente occupato. Il canale resta così "mediamente più libero" e quindi l'efficienza sale ulteriormente.

PROTOCOLLI SENZA COLLISIONE

Cosa si fa quando il mezzo trasmissivo non permette una verifica delle collisioni? Via radio, o su un cavo particolarmente lungo, o ancora con un rapporto tra larghezza di banda e lunghezza pacchetto molto grande (come per le fibre ottiche), non si possono verificare in tempo ragionevole le eventuali collisioni, specialmente quelle durante il "periodo di contesa".

Nel metodo "a mappa di bit", prima di ogni slot viene inviato sulla linea un pacchetto di bit di "contesa": se il sistema n desidera trasmettere un pacchetto, allora trasmette un 1 nel bit n-esimo del pacchetto di contesa. Se in tale pacchetto è stato settato a 1 un solo bit, allora il sistema che l'ha trasmesso è autorizzato a trasmettere un pacchetto dati; se più persone contemporaneamente hanno richiesto la linea (più bit a 1 nel pacchetto di contesa), allora il pacchetto di contesa viene ritrasmesso, sperando che i tempi casuali di attesa per una mancata trasmissione facciano ridurre il numero di sistemi desiderosi di trasmettere. Quando il numero di sistemi è piccolo rispetto alla grandezza media dei pacchetti ordinari, questo sistema è particolarmente efficiente e virtualmente elimina qualsiasi collisione. Quando il numero di sistemi è grande, per ridurre ragionevolmente la grandezza del pacchetto di contesa, anziché assegnare un bit ad ogni sistema si assegna un bit a più sistemi, per cui ci potranno essere contese solo se più sistemi assegnati in gruppo allo stesso bit tentano di trasmettere Click here for Ozzy Osbourne site! contemporaneamente. Tragicamente, quando il numero di stazioni non sia esattamente una potenza di 2, ci troveremo di fronte a stazioni "più privilegiate" rispetto ad altre nel senso che un bit assegnato ad un gruppo con una stazione in più rispetto ad un altro andrà più probabilmente a 1 a parità di traffico medio. Inoltre nel caso di traffico relativamente basso in una rete con molti nodi, una stazione deve comunque aspettare l'intero pacchetto di contesa prima di poter trasmettere.

Un metodo che risolve entrambi i problemi citati del metodo a mappa di bit è il BRAP (broadcast recognition with alternating priorities: riconoscimento di broadcast con priorità alternate). In pratica si permette ad una stazione di cominciare a trasmettere il suo pacchetto di dati non appena questa ha inserito un 1 nel pacchetto di contesa; il successivo pacchetto di contesa comincerà col bit della stazione (o del gruppo di stazioni) successivo. L'efficienza sale in quanto i ritardi delle singole stazioni non sono indipendenti tra loro ma sono in linea di massima "collegati". Il BRAP soffre in pratica solo quando il sistema non è particolarmente caricato e il pacchetto di contesa non è piccolissimo: quest'ultimo infatti continua a girare per intero finché una stazione non decide di trasmettere inserendo un bit 1 nella "sua" posizione (avendo quindi da attendere non poco).

Il protocollo MLMA (multi-level multi-access) aggira questo problema facendo trasmettere "a pezzi" l'indirizzo della stazione che vuole trasmettere. Immaginando di avere numeri di stazioni compresi tra 000 e 999 decimale, vengono trasmessi tre pacchetti di contesa da 10 bit in cui una stazione che desideri trasmettere invia un 1 nell'n-esimo bit del p-esimo pacchetto (la stazione 345 setta a 1 il bit 3 del primo dei tre pacchetti da 10 bit). In questo semplice esempio, per mille stazioni si può risolvere la contesa con soli 30 bit; si può migliorare ancora un p tale sistema usando numerazioni alternative alla decimale che tengano conto del numero dei nodi.

PROTOCOLLI A CONTESA LIMITATA

Le due strategie generali - gestione delle collisioni (come nel CSMA) e "non gestione" delle collisioni (come nell'Aloha) - hanno i loro pro e contro in linea di massima opposti per quel che riguarda il ritardo sulla linea con carico basso e l'efficienza della linea con carico alto (i protocolli senza collisione hanno una maggiore efficienza in caso di carico alto, mentre quelli "non collisione" hanno un ritardo minore se il carico è basso).

Il protocollo di "attraversamento adattabile dell'albero" prevede che durante il primo bit del pacchetto di contesa tutti i nodi possano tentare di acquisire il canale. Se un solo sistema tenta di trasmettere e ci riesce, allora non ci sono problemi. Se avviene una collisione, allora durante lo slot successivo, solo una metà dei nodi viene autorizzata a "tentare" la trasmissione. Si procede "dimezzando" di volta in volta il gruppo autorizzato al tentativo fino a che non si arriva ad autorizzare alla trasmissione un solo nodo.

Il protocollo dell'urna è simile a quello dell'attraversamento adattabile dell'albero; in pratica possiamo immaginare che le stazioni siano disposte in cerchio, ed una "finestra" scorra intorno. Sono autorizzati a trasmettere i soli n nodi interni alla finestra; se avviene una trasmissione corretta o non avviene alcuna trasmissione, la finestra si sposta sulle successive n stazioni, altrimenti la finestra viene ridotta a n/2 stazioni e si ritenta la procedura, fino al termine delle collisioni (somiglia un po' al token passing, con la differenza che questo tipo di token abilita più di un nodo). Chiaramente Click here for dr. Arpaia's home page! a livello software resta da decidere "quando" far tornare alto il valore di n (per esempio raddoppiare le dimensioni della finestra quando non vi siano state collisioni per due slot consecutivi).

RETI LOCALI: LO STANDARD IEEE 802

L'IEEE (Institute of Electrical and Electronic Engineers) ha raggruppato in un unico documento gli standard dei tre sistemi più usati per le reti locali; il documento IEEE 802 è diviso in cinque punti:

LO STANDARD IEEE 802.3 E LA ETHERNET

La Ethernet della Xerox è sicuramente il più famoso prodotto utilizzante il protocollo CSMA/CD, tanto che è servito come base per lo standard IEEE 802.3. Tale documento descrive i protocolli CSMA/CD 1-persistenti operanti a velocità comprese tra 1 e 10 Mbps. I cavi usati comunemente sono di due tipi: l'"Ethernet spesso" per le distanze medio-lunghe (un cavo particolarmente spesso; il documento IEEE suggerisce che sia giallo) e l'"Ethernet sottile" per le brevi distanze (per esempio il comune RG-58).

Per determinare eventuali problemi a livello di cavi (prese difettose, connettori allentati, etc) si usa una tecnica di riflettometria nel dominio del tempo - viene inviato lungo il cavo un segnale che, "riflettendosi" al primo ostacolo che incontra, restituisce un'informazione ben precisa sulla posizione dell'ostacolo col tempo che impiega a "tornare".

Tutte le implementazioni dell'802.3 utilizzano la codifica Manchester diretta, in pratica una transizione da -0.85V a +0.85V sulla linea indica la trasmissione di un bit 0, una transizione da +0.85V a -0.85V indica la trasmissione di un bit 1, e 0V indica inattività. Il transceiver (transmitter/receiver) è un oggetto fisicamente montato sul cavo, che lascia "passare" i dati, potendo "leggerli" e potendo "inserirne", senza disturbare la comunicazione (per esempio, i noti connettori BNC a "T"). Il cavo del transceiver connette il transceiver alla piastra d'interfaccia nel computer. Per l'802.3 la lunghezza massima del cavo è dell'ordine di poche centinaia di metri; per coprire distanze maggiori si possono connettere più cavi attraverso un ripetitore - che amplifica e ritrasmette il segnale nelle due direzioni. Per l'organizzazione della rete, a distanze maggiori di 200 metri, oltre al ripetitore, possono essere necessarie altre apparecchiature, quali per esempio il router (ripetitore) ed il bridge (ripetitore "intelligente", cioè che lascia passare, dopo averli esaminati, solo i frame che devono raggiungere l'altro segmento della rete).

Ogni pacchetto (frame) dell'802.3 inizia con una stringa di 7 byte (detta preambolo) che serve a sincronizzare i clock di ricevitore e trasmettitore. Dopo il preambolo c'è un byte di "inizio frame" e di seguito un indirizzo per la destinazione e uno per la provenienza. In un byte dell'indirizzo di destinazione viene specificato uno 0 per indirizzi ordinari, o 1 per indirizzi di gruppo - quest'ultimo caso è il "multicasting": trasmissione di un pacchetto a più stazioni contemporaneamente; se il pacchetto è trasmesso a tutte le stazioni allora si parla di "broadcasting". Quindi c'è un campo che indica la lunghezza del numero di byte presenti nel campo dati, fino a 1500; quindi il campo dati vero e proprio della lunghezza appena indicata, quindi c'è un campo di padding ("riempimento extra"), lungo da 0 a 46 bytes, ed infine 4 bytes di checksum (un CRC, controllo di ridondanza ciclica, che come già detto ha la caratteristica importante di variare fortemente se cambia anche un solo bit del campo dati). Il campo di padding serve ad "allungare il pacchetto" nel caso la sua lunghezza sia inferiore a 46 bytes - infatti una lunghezza finale anomala del pacchetto è ulteriore indicazione di una possibile avvenuta collisione. Se una stazione si "accorge" di una collisione durante una sua trasmissione, allora genera un po' di "rumore" per facilitare la rilevazione della collisione alle altre stazioni, e quindi aspetta, come da definizione CSMA/CD, per un intervallo di tempo casuale prima di ritentare la trasmissione. Si fa in modo di aumentare tale intervallo di tempo esponenzialmente al numero di collisioni consecutive. Il checksum finale è indispensabile per verificare l'integrità dei dati - non è detto che un pacchetto trasmesso senza collisioni non possa essere stato alterato in qualche modo dal rumore presente sulla linea. Una installazione-tipo di 50 stazioni, con frame da 512 byte ha un'efficienza media del canale superiore al 70%.

LO STANDARD IEEE 802.4: TOKEN BUS Click here for Tempi site!

Le particolari esigenze della General Motors portarono allo sviluppo di un protocollo noto come token bus (poi standardizzato nell'IEEE 802.4). Alla GM, per la struttura delle linee di produzione, avevano bisogno di conoscere in modo deterministico il tempo massimo di attesa per un sistema per trasmettere, cosa che l'802.3 non poteva garantire a causa della sua natura probabilistica.

I sistemi collegati in token bus sono organizzati in modo tale che un solo sistema alla volta ha il controllo della rete, che è assegnato dal "possesso" del token, un pacchetto di byte che i sistemi si "passano" ogniqualvolta verifichino di aver trasmesso correttamente un pacchetto o comunque entro un determinato periodo di tempo (un sistema può trasmettere più pacchetti "piccoli", se ne ha, fino a che "ha tempo"; allo scadere del timer deve comunque cedere il token alla stazione successiva). Dunque se ci sono n sistemi e il tempo per trasmettere un pacchetto è t, un sistema dovrà aspettare al più n*t prima di trasmettere. Il "cammino" del token attraverso la rete a livello logico forma un anello, anche se a livello fisico la rete è strutturata "a bus" perché alla GM temevano che un'interruzione di un solo nodo avrebbe pregiudicato il funzionamento dell'intera rete. Nell'anello logico ogni nodo conosce l'indirizzo del nodo precedente e del nodo successivo, informazioni necessarie a gestire gli eventi di entrata ed uscita di un nodo in rete oltre che di token passing. Quando l'anello logico viene inizializzato, le stazioni vengono inserite nell'ordine dei loro indirizzi, dal più basso al più alto. Il passaggio del token partirà e proseguirà con questo stesso ordine. Una stazione che non abbia dati da trasmettere passerà subito il token al nodo successivo.

Ogni sistema del token bus viene visto in linea di massima come un insieme di quattro sottosistemi ordinati per priorità, per cui è possibile in pratica assegnare "fette" precise del timer di controllo del token ad ogni sottosistema. Per esempio, in una rete operante a 10 Mbps con 50 stazioni, si può stabilire che i sottosistemi a più alta priorità possano "assorbire" un terzo della larghezza di banda del traffico:

10 Mbps / 50 / 3 = 200 kbps / 3 = 66 kbps = 8 kbyte/sec circa,

che è sufficiente per un canale vocale (ad una qualità audio leggermente superiore a quella telefonica), per ogni stazione connessa in rete.

A livello fisico il token bus usa un cavo coassiale a larga banda da 75 Ohm, solitamente usato per la TV via cavo. Le modulazioni usate sono la FSK (frequency shift keying, modulazione numerica di frequenza, con continuità di fase o con coerenza di fase) e PSK (phase shift keying, modulazione numerica di fase); rispetto alla codifica Manchester dell'802.3 si ha la possibilità di trasmettere segnali particolari, diversi dal bit 0 e dal bit 1. Tali segnali sono per esempio i delimitatori di inizio e fine pacchetto - per cui la decodifica risulta facilitata una volta riconosciuti, e non c'è bisogno di un campo lunghezza nel pacchetto in quanto la lunghezza si evince dalla quantità di dati contenuta appunto tra i due delimitatori. Prima del delimitatore di inizio è posta una stringa di preambolo di lunghezza non fissa (almeno un byte); subito dopo il delimitatore vi è un byte di frame-control usato per la gestione interna della rete (token passing, entrata/uscita di un nodo, risoluzione contese "a chi spetta il token", etc); dopo ci sono gli indirizzi di destinatario e mittente del pacchetto, quindi il blocco dati (fino a 8182 bytes) ed infine, prima del delimitatore di fine, i 4 bytes di checksum. I campi di indirizzo e di checksum sono costruiti allo stesso modo di quelli dell'802.3; il blocco dati è molto più lungo grazie alla presenza dei timer di controllo del token - per cui non si rischia che una stazione tenga troppo a lungo impegnata la rete, lasciando per la possibilità di trasmettere blocchi non piccolissimi quando non ci sia grosso traffico.

Come fanno nuovi nodi ad entrare nell'anello logico? Il possessore del token, periodicamente, invia un pacchetto di "invito" all'entrata; se qualcuno risponde in tempo utile (e deterministico), viene accettato in rete. Nel caso che più di un sistema risponda, la contesa viene risolta con un algoritmo con numeri casuali. Chiaramente in caso di traffico medio-alto (basta confrontare i valori dei timer dal momento in cui si cede il token al momento in cui lo si i riottiene), non ci saranno "inviti" ad entrare in rete per non sovraccaricare inutilmente la stessa. Un nodo, prima di uscire dall'anello logico, appena ricevuto il token, invia un pacchetto "sto uscendo" e smette di trasmettere; nel pacchetto è indicato il suo successore in modo che tutti i nodi sappiano aggiornarsi la mappa dell'anello logico. L'inizializzazione della rete avviene in un modo un po' barbaro: se un sistema nota traffico zero sulla linea per un periodo di tempo ragionevole, richiede il token, e non ottenendo risposta per un certo periodo, assume di essere l'unico nodo e si crea dunque un nuovo token per cui il nuovo anello logico conterrà solo quel sistema. Man mano si aggiungeranno nuovi nodi come sopra descritto.

Cosa succede quando un sistema si guasta? Se un nodo non riesce a trasferire il token al suo successore perch questi non risponde, allora manda un pacchetto "chi era il successore del nodo guasto?". Se qualcuno risponde, il nodo guasto viene eliminato dall'anello logico e si prosegue normalmente, altrimenti viene i inviato un pacchetto "c'è ancora qualcuno vivo?" e si risolve la situazione con lo stesso algoritmo casuale delle contese. Se si guasta proprio il nodo che aveva il token, dato che ogni stazione ha un timer extra (con questo dovrebbero essere una decina in tutto, ed infatti l'802.4 è "per natura" più complesso dell'802.3), si accorgono tutte che il token non "circola" da troppo tempo ed allora lo richiedono e le eventuali contese vengono risolte col solito algoritmo.

LO STANDARD IEEE 802.5: TOKEN RING

Dalla token bus alla token ring il passaggio è relativamente semplice (l'anello "logico" della token bus diventa anello "fisico" nella token ring); le implicazioni però non sono altrettanto semplici.

Il punto è questo: in una rete operante a 1 Mbps, un bit per essere trasmesso ha bisogno di 1 microsec, che alla velocità tipica di propagazione di 200 metri/microsec implica che un bit "impegna" 200 metri di cavo, per cui un anello fisico di 1000 metri può dunque "contenere" al più 5 bit contemporaneamente - non è ragionevole pensare che sulla linea possa rimanere un intero pacchetto. Dato che per "ascoltare" un bit prima di ritrasmetterlo si impiega appunto "1 bit" di tempo (nell'esempio di sopra: 1 microsec) e dato che nella rete più di pochi bit per volta non ci sono, la stazione che trasmette avrà in ritorno dopo pochissimo tempo gli stessi bit appena trasmessi - che possono essere usati per verificare che la trasmissione sia stata corretta. Una volta che l'ultimo bit trasmesso è ritornato "sano e salvo" ed il checksum risulta corretto, si può finalmente considerare un'altra trasmissione o la cessione del token ad un altro sistema. Chi riceve un pacchetto lo ritrasmette al mittente con un solo bit modificato (quello che indica "ricezione ok"); nel caso di broadcasting bisogna progettare un meccanismo di riscontro più sofisticato. In condizioni di basso traffico, il token gira velocemente in attesa che qualcuno lo sfrutti per trasmettere qualcosa; in condizioni di traffico medio-alto il token passerà di stazione in stazione permettendo a tutte di trasmettere, potendo raggiungere così un'efficienza della rete vicina al 100%.

La IBM ha sviluppato la sua token ring usando la codifica Manchester differenziale - una transizione della tensione da +V a -V o da -V a +V, differente dalla transizione precedente, indica un bit 1 anziché 0; per la token ring dell'IBM il valore di V è compreso tra 3V e 4.5V. La scelta della Manchester differenziale è obbligata dal fatto che è importante non introdurre una componente continua nella tensione di anello. La token ring IBM viaggia a 4 Mbps, il massimo previsto dall'802.5.

Anche se a livello fisico rimane pur sempre un anello, l'impiego di centri di cablaggio permette di aggirare il problema evitando che un guasto ad un nodo comprometta il funzionamento dell'intera rete; in questi in pratica succede che al "venir meno" di un nodo, si chiude subito un circuito che esclude tale "fetta" di cavo dalla rete, ovvero viene ricostruito ad hardware ed in modo trasparente l'anello fisico.

Nella token ring, quando non c'è traffico, il token è di soli tre bytes; quando una stazione decide di usarlo, lo reinvia in linea cambiandone un solo bit per far capire che non si tratta di un token "utilizzabile" da altri, e per dargli un significato di "preambolo di pacchetto". Subito dopo infatti sono presenti gli indirizzi di destinatario e mittente, quindi il blocco dati (di qualsiasi grandezza) ed infine il solito checksum, seguito da un byte di delimitatore di fine pacchetto e da un byte di frame-status. I due delimitatori sono sequenze non valide della codifica Manchester differenziale, ovvero sono transizioni [+V,+V] e [-V,-V]; il frame-status finale indica se la destinazione era presente o meno e se il pacchetto è stato recapitato o meno. Il secondo byte del token indica la priorità del pacchetto: se una stazione vuole trasmettere un pacchetto con priorità n, deve aspettare di "catturare" un token con priorità minore o uguale di n e addirittura può "prenotarsi" il prossimo token sempreché non sia già stata effettuata una prenotazione a priorità più alta. Questo sistema è reso meno rude da una complessa serie di regole per cui una stazione deve alternare giocate "al rialzo" con altrettante giocate "al ribasso", anche se non è impossibile che una stazione rimanga in attesa eterna perché ha da trasmettere solo pacchetti di bassa priorità. Generalmente il possesso del token è limitato a 10 msec, salvo stabilire un valore diverso al momento dell'installazione/configurazione della rete.

La gestione dell'anello è demandata ad un nodo "primus inter pares" che ha il compito di verificare il corretto funzionamento della rete; un protocollo di contesa garantisce che se anche venisse a mancare un tale nodo (detto nodo monitor), si provvede subito a "rieleggerlo". Il nodo monitor verifica che il token non sia perso, agisce in caso di anello "spezzato" e ricerca pacchetti "orfani". Se si accorge che c'è un pacchetto trasmesso da una stazione che subito dopo è andata down, "pulisce" l'anello e invia un nuovo token. Se un pacchetto passa due volte per il nodo monitor, viene comunque eliminato e tale decisione viene segnalata in un bit del preambolo. Se la lunghezza del cavo e la velocità operativa sono tali da "contenere" in rete tutti e 24 bit del token, allora il nodo monitor vi inserisce dei "bit di ritardo" in modo da lasciarlo circolare. Nel caso si spezzi l'anello, individua il nodo guasto trasmettendo un pacchetto particolare (detto beacon) e vedendo "fin dove arriva", dopodiché utilizza i bypass dei centri di cablaggio per ripristinare l'anello. A fronte di una maggiore semplicità di gestione e di un improbabile alto carico di lavoro del nodo monitor (in quanto le stazioni raramente si guastano), abbiamo lo svantaggio che se un nodo monitor per un guasto insiste che "è tutto a posto" anche se non è vero, tutti gli altri nodi si fideranno di questa informazione "senza contestare".

Alcune varianti del modello token ring sono: l'anello a slot (i pacchetti sono di lunghezza fissa, un bit all'inizio indica se il pacchetto contiene dati o meno) e l'anello ad inserimento di registri (ogni nodo ha dei buffer interni per i pacchetti, sia suoi che esterni, e l'algoritmo di gestione evita che la rete sia monopolizzata da una singola stazione).

RETI LOCALI: QUALE SCEGLIERE?

In linea di massima i tre standard descritti impiegano tecnologie simili ed ottengono prestazioni simili; dunque i problemi sono solo a livello commerciale e/o pratico. La nota ed economica Ethernet si può installare in pochissimo tempo, e, per bassi carichi, il ritardo in trasmissione è praticamente nullo; quasi sempre non esistono problemi di "il segnale arriva anche all'ultimo dei nodi", anche se non si usano modem o altri sistemi di amplificazione del segnale. Purtroppo l'efficienza globale tende a diminuire con l'aumentare della velocità, a causa delle collisioni e del carrier detecting: questa è una discriminante fondamentale se si prevedono alti carichi di lavoro. Una token bus può ancora ritenersi un buon compromesso: necessita di cavi facilmente reperibili e sufficientemente affidabili, gestisce priorità, è deterministica, molto produttiva anche con alti carichi di lavoro. Per contro richiede spesso modem e amplificatori a larga banda; per non parlare del protocollo complesso e oneroso nel caso di traffico medio-basso, e del fatto che per natura non si presta all'uso di fibre ottiche. La token ring, utilizzando connessioni punto-punto, può essere realizzata con qualsiasi tipo di trasmissione, dai piccioni viaggiatori alle fibre ottiche; i centri di cablaggio la rendono l'unica LAN in grado o di rivelare ed aggirare i guasti sul cavo senza intervento umano. Gli svantaggi della token ring sono per lo più sulle implicazioni della funzione di monitor - un nodo monitor "guasto ma non troppo", come già detto sopra, può essere un serio problema per la rete.

CONFRONTO TRA PBX SU ISDN E LAN

Il PBX (private branch exchange) permette, usando linee ISDN e la rete telefonica commutata presente praticamente dappertutto, di connettere tutti i sistemi in un grosso edificio e connetterli anche all'esterno in modo del tutto trasparente, senza bisogno di gateway o altro; può inoltre superare i 500 Mbps di produttività totale. I guai cominciano proprio con i canali ISDN, solo a 64 kbps, velocità che si presta tragicamente solo per applicazioni con pochi (o pochissimi) dati da trasferire; non è bello aspettare due minuti e mezzo per il trasferimento di un file da 1200 kbytes. Inoltre i PBX sono "a commutazione di circuito": i tempi di commutazione sono tali da renderlo valido se il traffico è "continuo", ma catastrofico se il traffico è irregolare ("a raffiche").

RETI A FIBRE OTTICHE

Nonostante il costo ben superiore ai tradizionali cavi in rame (doppino, coassiale, etc) le fibre ottiche stanno diventando, per velocità ed altre caratteristiche intrinseche (non sono soggette ad interferenze elettriche o elettromagnetiche, etc) sempre più interessanti per il rapporto prezzo/prestazioni.

La FDDI (fiber distributed data interface) è una LAN token ring su fibra ottica ad alte prestazioni (100 Mbps, 200 km, 1000 stazioni, max 1 errore ogni 25 miliardi di bit, anche se altre implementazioni offrono prestazioni ancora superiori); usa materiali non costosissimi quali fibre monomodali e diodi LED. Le specifiche prevedono due anelli, uno "in senso orario" ed uno "in senso antiorario", in modo che in caso di guasto su uno degli anelli, la rete può ancora continuare a funzionare; in caso di guasto sullo stesso punto di entrambi gli anelli, è possibile connettere tra loro le due coppie di estremità rotte ottenendo un unico anello. Le stazioni "economiche" non vengono necessariamente connesse ad entrambi gli anelli. Visto che la codifica Manchester richiederebbe almeno 200 Mbaud, si usa la codifica "4 su 5", cio 4 bit di dati vengono codificati in 5 bit sulla linea (quindi "ce la facciamo" ottenendo 80 Mbaud reali); metà delle combinazioni è riservata ai dati, l'altra metà si divide tra delimitatori e controllo in generale. La proprietà di auto-sincronizzazione della codifica Manchester si emula con preamboli molto lunghi e clock con tolleranza 0.005% (che significa che un pacchetto può contenere circa 4500 bytes senza che si rischi di perdere la sincronizzazione). Sono previsti pacchetti speciali per PCM o per dati ISDN.

Nella Fibernet II (praticamente una Ethernet su fibra ottica) si possono inserire nuove stazioni direttamente sul cavo di connessione tra sistema e transceiver; occorre ovviamente qualche accorgimento extra per rilevare possibili collisioni, per esempio: rilevamento della potenza (se un nodo rileva più "potenza" di quanta ne stia trasmettendo allora si ferma perché c'è stata sicuramente collisione con qualche altra stazione), durata dell'impulso (l'impulso "entrante" che dura di più di quello "uscente" indica una sicura collisione), ritardo nella ricezione (se una stazione "sente" arrivare segnali troppo presto in eco ai suoi allora sicuramente qualcun altro aveva gi trasmesso), monitoring "solo esterno" (un sistema che possa ascoltare solo gli altri anziché se stesso può capire subito se altri lo hanno "interrotto" mentre trasmetteva). La S/NET fu progettata per ottenere il massimo della velocità di commutazione. Ciascuna stazione ha due fibre da 20 Mbps; con un sistema di priorità e di interrupts si ottengono anche 80 Mbps di velocità di commutazione. La FASNET fu progettata come LAN ad alte prestazioni; utilizza due bus lineari unidirezionali; le due stazioni alle estremità cominciano a trasmettere ognuna su uno dei due bus, degli slot "caricabili" come dei vagoni vuoti di un treno; il "treno" viene "rigenerato" non appena arriva a destinazione. La ExpressNet usa più o meno lo stesso sistema, anche se il bus è uno solo ma è "piegato in due"; ogni stazione si collega al bus in due punti, esaminando il punto interno per sapere se il canale è libero e trasmettendo sul punto esterno. La Datakit usa due bus, uno di contesa ed uno di broadcast; come funzionamento somiglia in linea di massima ad un PBX.

RETI VIA SATELLITE

I satelliti di comunicazione hanno in genere una dozzina di trasponditori, ognuno dei quali copre una certa porzione della Terra sottostante. A causa della distanza (e quindi del ritardo di propagazione, intorno ai 270 msec), non è pensabile l'uso di protocolli CSMA/CD. Il sistema SPADE ha 794 canali PCM a 64 kbaud per ogni transponditore, canali usati a coppie per ottenere un servizio full-duplex; in più c'è un canale "comune" a 128 kbps; prevede al massimo una cinquantina di stazioni a terra che possiedono ciascuna uno slot da 1 msec (128 bit) sul canale comune col quale si assegnano il primo canale libero del satellite che trovano e lo "disallocano" appena hanno finito; questo sistema permette di fare "abbastanza comunicazione" tra i sistemi senza impegnare troppi preziosi canali del satellite. Quando il traffico non sia abbastanza regolare e continuo, si può riconsiderare il sistema Aloha, a costo di perdere un po' di efficienza per la mancata possibilità di "sentire" ci che si sta trasmettendo; l'Aloha a slot di tempo via satellite è ancora troppo critico per il traffico medio-alto, per cui è stato proposto un sistema Aloha "a prenotazione". Assegnato alle stazioni un gruppo di n slot consecutivi ("uno a testa"), quando una stazione lascia uno slot vuoto, permette ad un'altra di appropriarsene (se vuole evitarlo deve trasmettere qualcosa per generare una collisione: in quest'ultimo caso la contesa da' ragione alla ex proprietaria). Chiaramente il numero di utenti deve essere noto in anticipo, altrimenti c'è da studiare un altro sistema di contesa ed assegnare uno slot a più utenti.

RETI A RADIOPACCHETTI

Perché una rete a radiopacchetti? In particolari condizioni geografiche può non essere pensabile l'installazione di una rete su cavo per insufficienza di sistemi telefonici (aree rurali, Terzo Mondo, etc) o particolari situazioni delle stazioni: le stazioni mobili sono l'esempio più lampante (automobili della polizia, terminali installati su carrelli elevatori all'interno di un magazzino, etc); infine un traffico medio assolutamente basso rispetto al traffico di punta, o una non grande quantità di dati da trasferire o altre motivazioni che rendano la linea dedicata un vero spreco. Quali sono gli inconvenienti nella progettazione di una rete a radiopacchetti? Innanzitutto il tempo richiesto per un pacchetto per arrivare a destinazione: ogni ripetitore può far perdere tempo dell'ordine anche dei secondi, e comunque ogni ripetitore, appena ricevuto un pacchetto, deve decidere se inoltrarlo o meno (per evitare situazioni "ping-pong" e congestionamento della linea). Varie strategie prevedono che un pacchetto non possa attraversare più di n sistemi, per cui quando il "contatore di tappa" si trova azzerato, il pacchetto viene cancellato - con questo ci si assicura soltanto che il pacchetto più di n volte non "rimbalzerà"; una strategia aggiuntiva prevede un buffer per k pacchetti per cui nel caso se ne "ripresenti" uno già visto recentemente (perché nel buffer) allora non viene trasmesso.

Clicca qui per Asus A1370D La packet radio network dei radioamatori, descritta nel documento AX.25 (basato sul protocollo X.25), permette lo scambio dati a 1200 baud. Il documento AX.25 specifica il formato dei pacchetti ma non l'algoritmo di accesso al canale, per cui si possono usare sia l'Aloha puro che il CSMA - l'ambiente dei radioamatori è troppo caotico per considerare l'Aloha a slot. In particolare ogni stazione di radioamatore ha una sua sigla univoca a livello mondiale (callsign, da 4 a 6 caratteri alfanumerici), per cui è possibile specificare il "percorso esatto" che un pacchetto deve fare per arrivare a destinazione - questo dettaglio è infatti parte dell'AX.25.

Un'altra rete a radiopacchetto sicuramente nota è la rete radio cellulare. Un telefono cellulare trasmette in un canale intorno ai 450 o ai 900 MHz; il segnale viene captato dalla stazione a terra più vicina, che assegna al telefonino una frequenza precisa da utilizzare che viene "liberata" al termine della chiamata o quando il telefonino si sia spostato nel raggio di azione di un'altra stazione base.

LO STRATO MAC DELLA RETE PNET

La rete PNet è una rete geografica di sistemi amatoriali BBS (bulletin board systems) sparsi per l'Italia, progettata ed attivata nel 1991 e a tutt'oggi gestita da Alf.Mar. Visto che il mezzo trasmissivo usato è la normale linea telefonica commutata e che non ci sono esigenze di scambio pacchetti in tempo reale, il criterio principale nella progettazione della rete è stato l'economia di funzionamento: la trasmissione dei pacchetti avviene al più due volte al giorno, nelle fasce orarie di costo e traffico minore (tipicamente tra le 2 e le 6 del mattino); i pacchetti vengono spediti in un unico blocco compresso con i migliori algoritmi attualmente disponibili (ARJ, Pkzip, etc); il routing è influenzato dalle tariffe telefoniche; i modem usano protocolli non conformi agli standard CCITT ma più veloci (per esempio il protocollo Zyxel, che in condizioni ottimali supera i 2300 bytes per secondo in full duplex), etc. La maggioranza del traffico è in echo, cioè in broadcast: ogni sistema conserva copia del pacchetto in transito per il proprio "uso". Il disegno della rete è ad albero: ogni nodo ha un nodo "padre" di riferimento (uplink) che chiama per ottenere i pacchetti per lui in arrivo dal resto della rete (dal padre in su), ed uno o più nodi "figli" (downlink) che lo chiamano come loro nodo padre. La sequenza delle chiamate (polling) è sincronizzata in modo tale che ogni stazione della rete chiama l'uplink solo dopo che questi ha a sua volta chiamato il suo uplink. Se una stazione ha da trasmettere pacchetti verso il nodo padre, deve effettuare una chiamata di pre-polling per inviargli tali pacchetti prima che questi effettui a sua volta la sua chiamata di pre-polling: ogni stazione infatti deve mantenere l'invariante che all'eventuale pre-polling partono i pacchetti echo accumulati "da sé stessa in giù", e al polling si ricevono i pacchetti accumulati "su". Il fatto di non lasciare che tale invio avvenga direttamente nella chiamata di polling garantisce che un pacchetto arriva a destinazione entro la chiamata di polling del destinatario, cioè entro 24 ore, anche ai livelli attuali con oltre 150 sistemi in rete.

Alcuni bytes all'inizio di ogni pacchetto indicano funzioni speciali, quali per esempio messaggi non echo (diretti cioè ad una sola stazione), messaggi crittografati (l'algoritmo usato è il PGP, una variante del noto RSA), files binari (ridotti in formato uuencode se trasmessi in echo), richiesta di funzioni particolari (per esempio l'invio di un fax da un sistema remoto), gestione interna della rete (modifica del traffico echo, aggiunta di nuovi nodi e nuove regole di routing, richiesta informazioni sui files presenti sui sistemi, etc). Ogni pacchetto contiene la lista dei sistemi attraversati fino al destinatario (path, per l'identificazione dell'origine dei pacchetti e di eventuali problemi di pacchetti orfani nel routing); i pacchetti echo contengono inoltre la lista dei sistemi che hanno sicuramente ricevuto copia del pacchetto (seen-by, per evitare l'inoltro di pacchetti duplicati). Ogni nodo conserva i pacchetti ricevuti nell'ultima settimana: nel caso un nodo vada down per più di tre giorni, viene attivata una procedura di modifica del routing che in particolare permette di recuperare i pacchetti non ricevuti a causa del down.


Google
 
Web www.alfonsomartone.itb.it

Su una chiesetta romanica a Matrice

send e-mail - continua (next page)