Un po' di storia: differenze tra le versioni

Da AMPR ARI.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
Nessun oggetto della modifica
 
(14 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
Il 25 agosto 1984 Brian Kantor [WB6CYT]<ref>ARDC memorial https://www.ardc.net/in-memoriam-brian-kantor-wb6cyt-1953-2019/</ref> presentò il seguente manoscritto all'incontro del Los Angeles Amatuer Packet Radio Group.
Il 25 agosto 1984 Brian Kantor [WB6CYT]<ref>ARDC memorial - https://www.ardc.net/in-memoriam-brian-kantor-wb6cyt-1953-2019/</ref> presentò il seguente manoscritto<ref>A Proposed Network for the interconnection of Amateur Digital Packet Radio Stations - https://wiki.ampr.ari.it/images/1985_Kantor.pdf</ref> all'incontro del Los Angeles Amatuer Packet Radio Group.
Vi sono le considerazioni alla base della nascita di AMPRNET decretandone la nascita.
Vi sono le considerazioni alla base della nascita di AMPRNET decretandone la nascita e il riferimento a due aspetti fondamentali: la scelta dell'impiego di TCP/IP e la registrazione della sottorete 44.0.0.0/8 avvenuta a cura di Hank Magnuski [KA6M]<ref>https://en.wikipedia.org/wiki/Hank_Magnuski</ref>.


=== Premesse ===
La crescita delle comunicazioni digitali nel servizio radioamatoriale negli ultimi anni è stata a dir poco incredibile. Più di ogni altra cosa, la pronta disponibilità di comunicazioni digitali a pacchetto utilizzando sofisticati controllori di pacchetti come i dispositivi Vancouver [VADCG], Tucson [TAPR] e GLB ha introdotto le comunicazioni a pacchetto a molti radioamatori che altrimenti non sarebbero stati coinvolti nelle comunicazioni digitali. Oltre alla funzione di controllori di pacchetti come sofisticati sostituti delle telescriventi meccaniche, forniscono un mezzo per la creazione di sistemi di messaggistica e bacheche consentendo la connessione diretta ai personal computer.
La crescita delle comunicazioni digitali nel servizio radioamatoriale negli ultimi anni è stata a dir poco incredibile. Più di ogni altra cosa, la pronta disponibilità di comunicazioni digitali a pacchetto utilizzando sofisticati controllori di pacchetti come i dispositivi Vancouver [VADCG], Tucson [TAPR] e GLB ha introdotto le comunicazioni a pacchetto a molti radioamatori che altrimenti non sarebbero stati coinvolti nelle comunicazioni digitali. Oltre alla funzione di controllori di pacchetti come sofisticati sostituti delle telescriventi meccaniche, forniscono un mezzo per la creazione di sistemi di messaggistica e bacheche consentendo la connessione diretta ai personal computer.


Riga 9: Riga 10:


Tecnicamente, molti ripetitori vocali hanno caratteristiche di risposta audio che, sebbene non realmente evidenti con le trasmissioni vocali, introducono distorsioni significative che riducono l'affidabilità della ritrasmissione digitale. Inoltre, il codice Morse o gli identificatori vocali, i toni di telemetria della frequenza o dell'intensità del segnale e i segnali acustici di "superamento" possono essere confusi come segnali di pacchetto dai controllori di pacchetti meno sofisticati.
Tecnicamente, molti ripetitori vocali hanno caratteristiche di risposta audio che, sebbene non realmente evidenti con le trasmissioni vocali, introducono distorsioni significative che riducono l'affidabilità della ritrasmissione digitale. Inoltre, il codice Morse o gli identificatori vocali, i toni di telemetria della frequenza o dell'intensità del segnale e i segnali acustici di "superamento" possono essere confusi come segnali di pacchetto dai controllori di pacchetti meno sofisticati.
Socialmente, i toni stridenti del modem generati dalle apparecchiature a pacchetto sono estremamente fastidiosi per gli utenti voce, causando disturbi, interferenze e generale disappunto. Inoltre, molti controllori di pacchetti riconoscono solo i toni del modem a pacchetto, quindi non riconoscono che una frequenza è occupata quando è occupata da trasmissioni vocali e possono trasmettere disturbando una conversazione vocale esistente.
I ripetitori digitali, noti come digipeaters, forniscono un mezzo per ritrasmettere automaticamente i segnali dei pacchetti, ma poiché i pacchetti di riconoscimento devono essere restituiti dall'estremità lontana della connessione sul percorso di collegamento possibilmente multi-hop, la velocità effettiva di trasmissione è notevolmente ridotta. Inoltre, attualmente non esiste alcun controllo delle collisioni quando i segnali vengono ripetuti in formato digitale. Pertanto, in caso di collisione di pacchetti, gli attuali digipeater non sono in grado di rilevare la collisione e ritrasmettere il pacchetto distrutto dalla collisione. La stazione originaria deve quindi attendere la mancanza di riconoscimento dall'estremità lontana della connessione e inviare nuovamente il pacchetto. La ripetizione dei pacchetti inviati dalla stazione di origine può benissimo occupare grandi quantità della capacità di trasmissione disponibile di una rete.
=== La soluzione di rete ===
Riteniamo che la soluzione a questi problemi risieda in una rete dedicata per le comunicazioni a pacchetto, proprio come le reti a commutazione di pacchetto che spostano regolarmente milioni di caratteri di dati ogni giorno attraverso il paese e in tutto il mondo.
La rete è semplice. Ogni comunità (o area geografica) ha almeno un Packet Network Controller [PNC] che funge da gateway di rete che costituirebbe l'accesso alla rete a pacchetti per quell'area. Queste stazioni funzionerebbero automaticamente, senza operatore umano, e servirebbero a fornire connessioni per gli utenti locali e di rete. Ciascun PNC avrebbe almeno un PNC vicino e potrebbe stabilire connessioni logiche verso e attraverso i PNC adiacenti.
AMPRNET<ref>Ringrazio Hank Magnuski, KA6M per il nome della rete</ref> è strutturato come una rete di PNC, ciascuno dei quali ha uno o più PNC vicini a cui può connettersi tramite collegamenti radio. Ciascuno di questi PNC è connesso ad altri PNC e così via, finché tutti i PNC nella rete non sono raggiungibili tramite uno o più hop. Le connessioni tra PNC non adiacenti vengono effettuate facendo in modo che i PNC adiacenti trasmettano i pacchetti tra i due endpoint della connessione logica.
Ogni PNC ha una tabella di instradamento che descrive almeno un percorso verso ogni altro PNC accessibile. Utilizzando questa tabella, è possibile per qualsiasi PNC contattare qualsiasi altro PNC, possibilmente attraverso una serie di salti di relè intermedi. La tabella di instradamento viene creata e aggiornata dinamicamente man mano che la topologia della rete cambia con i nodi che entrano ed escono dal servizio.
===La rete vista dall'utente===
La connessione tramite la rete viene stabilita in due fasi distinte. Innanzitutto, un utente si connette al PNC locale. Abbiamo scelto l'uso del valore ssid (campo di identificazione secondaria della stazione) 14 (quattordici in base dieci) come designatore riservato per le stazioni PNC, quindi una connessione avviata (ad esempio) da un TNC TAPR potrebbe apparire come
CONNECT WB6CYT-14
che ordinerebbe alla tua stazione di connettersi al PNC gestito da WB6CYT. Sullo schermo verrà visualizzato il messaggio "connesso", seguito dal messaggio "rete pronta".
Successivamente, dovrai istruire il PNC a tentare di connettersi alla stazione che desideri chiamare. Per fare ciò è necessario conoscere l'identificativo del PNC che serve la sua zona. Quindi, ad esempio, per contattare Harold Price a Los Angeles, potresti chiedere al PNC di connetterti alla sua stazione a pacchetti tramite uno dei PNC di Los Angeles:
CONNECT NK6K@WB6YMH
(il -14 è implicito qui)
supponendo che WB6YMH stesse operando con quel PNC. La rete si occuperà di stabilire la connessione e di tutto l'instradamento dei pacchetti necessari. Al termine della conversazione, la disconnessione da una delle due estremità causerà la chiusura anche della connessione virtuale sulla rete. Si noti che le connessioni possono essere interamente locali e coinvolgere solo il PNC locale; ciò fornisce una connessione ripetuta su area locale più affidabile rispetto all'attuale tecnologia digipeater.
Prevediamo che il PNC fornisca anche altri servizi.
Tra quelli previsti ci sono:
+ Chi è nell'elenco
+ Stato della rete
+ Server di data e ora
+ Monitoraggio della sicurezza del sito
===Protocolli di rete===
Sebbene esistano molte proposte per stabilire un protocollo standard per il collegamento di stazioni a pacchetto amatoriali, attualmente non esistono risultati sperimentali che dimostrino un chiaro vantaggio per una scelta rispetto ad un'altra.
Il protocollo scelto deve tenere conto di due diversi aspetti della rete. Innanzitutto c'è la questione del trasporto tra i nodi della rete e, in secondo luogo, il formato dei dati trasportati dalla rete. Questi non sono necessariamente risolti dalla stessa risposta.
Il protocollo di trasporto descrive il metodo scelto per trasportare i messaggi tra i nodi della rete. Mentre per una linea fissa sarebbe sufficiente un semplice collegamento seriale ASCII, per i collegamenti radio più comuni si dovrebbe scegliere un mezzo affidabile. Nella nostra ricerca, abbiamo scoperto che l’attuale implementazione del protocollo AX.25 (utilizzato da TAPR, VADCG, GLB e altri) sarebbe utile. Dispone di rilevamento e correzione degli errori, è efficiente e sia il software che l'hardware per il suo utilizzo sono prontamente disponibili. Per questi motivi abbiamo scelto di utilizzare il protocollo AX.25 per la maggior parte dei collegamenti radio nodo-nodo della rete.
Il protocollo di comunicazione AMTOR presenta anche alcuni vantaggi distintivi per i collegamenti che si trovano sulle bande amatoriali HF. Nei casi in cui i collegamenti tra i nodi della rete debbano estendersi per grandi distanze, si potrebbe utilizzare il protocollo AMTOR e riteniamo sia adatto allo scopo.
Il formato dei messaggi trasportati dalla rete è indipendente dal protocollo di trasporto utilizzato. Poiché si prevede che i collegamenti svaniranno e subiranno interferenze e che i nodi falliranno, è saggio utilizzare un protocollo sufficientemente robusto da risolvere molti di questi problemi. Dopo approfondite ricerche in letteratura e considerando la base di software e sistemi già installati, abbiamo scelto il meccanismo Internet TCP/IP per il protocollo dei messaggi <ref>Una nota speciale per ringraziare Phil Karn, KA9Q per il suo suggerimento che TCP/IP potesse funzionare su AX.25 - Phil, è stata un'idea brillante e ha risolto un problema di cui discutevamo da qualche tempo</ref>.
TCP/IP è progettato per funzionare con un sistema di trasporto inaffidabile e le sue prestazioni migliorano quando il sistema di trasporto sottostante è più affidabile. Incorpora meccanismi di riassemblaggio e riordino dei pacchetti in grado di far fronte ai pacchetti persi, ai pacchetti ricevuti fuori ordine e ai pacchetti duplicati. Poiché lo schema di instradamento di rete descritto di seguito ospiterà un nodo guasto instradandolo attorno fintanto che esiste un percorso tra i nodi di rete endpoint di una connessione, è stato un grande vantaggio scegliere il protocollo TCP/IP che utilizzasse correttamente tale funzionalità .
TCP/IP presenta anche altri vantaggi che riteniamo lo collochino come il principale contendente per il protocollo di messaggistica interno. È stato dimostrato da oltre 10 anni di utilizzo su DOD Arpanet/Milnet/Internet; sono disponibili implementazioni per sistemi informatici che vanno dai mainframe VAX al PC IBM; è completamente definito e documentato; esistono già altre strutture che utilizzano il protocollo TCP/IP per il trasferimento di file e l'utilizzo di computer remoti; e gran parte del software necessario
per implementare TCP/IP è disponibile gratuitamente.
Pertanto, si prevede di implementare la rete in modo tale che tutte le comunicazioni tra PNC vengano eseguite utilizzando datagrammi del protocollo Internet [IP] per consentire la massima flessibilità nell'instradamento e nel trasporto dei dati, indipendentemente dal tipo di collegamento utilizzato tra i nodi. Ciò consente l'interconnessione diretta a Internet o qualsiasi altra rete compatibile con IP, qualora lo si desideri.
Hank Magnuski, KA6M, ha ottenuto l'assegnazione di un numero di rete Internet di Classe A per la radio a pacchetto amatoriale.<ref>Ciò è registrato nella Comunicazione della Difesa Network Information Center dell'Agenzia come numero di rete 044.xxx.xxx.xxx AMPRNET come documentato in Internet RFC 870 dell'ottobre 1983 - https://datatracker.ietf.org/doc/html/rfc790</ref> Si prevede che a ciascun PNC verrà assegnato il proprio blocco univoco di numeri host. Nel caso di PNC prodotti, gli indirizzi host PNC verranno assegnati al momento della spedizione dell'unità. Per le unità homebrew, un registro centrale assegnerà il numero. Poiché questi numeri sono lunghi 24 bit, sono disponibili diversi milioni di numeri. Il numero identifica semplicemente l'indirizzo PNC ed è molto simile a un numero di serie hardware.
Non è necessario modificarlo quando un PNC viene venduto o spostato o gli viene assegnato un nuovo nominativo. Per quelli di voi che hanno familiarità con Internet, viene utilizzato un protocollo di risoluzione degli indirizzi per mappare dinamicamente i numeri degli indirizzi Internet PNC sul nominativo PNC.
===Instradamento sulla rete===
Le tabelle di routing vengono create e gestite automaticamente dai nodi della rete. Alla prima attivazione o dopo un reset del sistema, il PNC non ha connessioni con le stazioni vicine. Ogni volta che un PNC non ha connessioni invia periodicamente un messaggio beacon broadcast (probabilmente ogni 10 minuti) finché non ha stabilito almeno una connessione con un PNC vicino. Quando un PNC vicino riceve un tale beacon, tenta di aprire una connessione con il PNC che invia il messaggio beacon. Ogni volta che viene rilevata un'attività di rete da nodo a nodo, le tabelle di instradamento vengono aggiornate da tutti i PNC che hanno ricevuto i messaggi in modo che ciascuno possa comprendere la connettività di rete più recente. Le tabelle di routing possono anche essere scambiate per fornire aggiornamenti.
Se un PNC già presente nella tabella di instradamento non è stato attivo per un certo periodo di tempo, viene inviato un messaggio a quel PNC per verificare che sia ancora attivo. Questo si chiama ping e verrà probabilmente eseguito dopo che sono trascorsi 30 minuti di inattività.
Se un tentativo di comunicazione con un PNC vicino fallisce per qualsiasi motivo, durante il normale inoltro dei pacchetti o a causa di un ping non riuscito, il PNC verrà eliminato dall'elenco delle connessioni aperte e dalla tabella di instradamento e non verrà più utilizzato per l'inoltro dei pacchetti. dal PNC che rileva il guasto. Pertanto, la rete si riprenderà e indirizzerà qualsiasi guasto che non isoli un nodo. Quando il PNC guasto si ripristina, il suo segnalatore o altre attività avviseranno i vicini che è tornato in servizio.
Non è necessario che le connessioni tra PNC siano collegamenti radio.
Saranno impiegabili anche modem, linee fisse, fibre ottiche o altri mezzi. In questi casi i messaggi inviati dal PNC su questi collegamenti sono identici a quelli che avrebbero viaggiato sul circuito radio virtuale AX.25, quindi non ci sarà alcuna differenza di funzionamento con questi altri tipi di collegamenti.
===Ringraziamenti===
I miei più sentiti ringraziamenti a Mike Brock WB6HHV, per i suoi preziosi suggerimenti sulla progettazione della rete, nonché per il suo aiuto nella preparazione di questo documento.
I miei ringraziamenti vanno anche alle numerose persone del Vancouver Amateur Digital Computer Group e della Tucson Amateur PacketRadio Inc, e a Phil Karn KA9Q, Rod Hart WA3MEZ, Harold Price NK6K e Skip Hansen WB6YMH per i loro contributi e suggerimenti.


==Riferimenti utili==
==Riferimenti utili==
<references />
<references />
==Note==
Il testo originale è stato liberamente tradotto da Gian Leonardo Solazzi [IW2NKE] il 16 febbraio 2024

Versione attuale delle 14:41, 16 feb 2024

Il 25 agosto 1984 Brian Kantor [WB6CYT][1] presentò il seguente manoscritto[2] all'incontro del Los Angeles Amatuer Packet Radio Group. Vi sono le considerazioni alla base della nascita di AMPRNET decretandone la nascita e il riferimento a due aspetti fondamentali: la scelta dell'impiego di TCP/IP e la registrazione della sottorete 44.0.0.0/8 avvenuta a cura di Hank Magnuski [KA6M][3].

Premesse

La crescita delle comunicazioni digitali nel servizio radioamatoriale negli ultimi anni è stata a dir poco incredibile. Più di ogni altra cosa, la pronta disponibilità di comunicazioni digitali a pacchetto utilizzando sofisticati controllori di pacchetti come i dispositivi Vancouver [VADCG], Tucson [TAPR] e GLB ha introdotto le comunicazioni a pacchetto a molti radioamatori che altrimenti non sarebbero stati coinvolti nelle comunicazioni digitali. Oltre alla funzione di controllori di pacchetti come sofisticati sostituti delle telescriventi meccaniche, forniscono un mezzo per la creazione di sistemi di messaggistica e bacheche consentendo la connessione diretta ai personal computer.

Mentre un certo uso del packet radio è stato fatto sulle bande HF inferiori a 30 MHz a velocità di trasmissione dati inferiori, l'attività maggiore è attualmente su VHF-FM (in particolare 2 metri). Poiché la comunicazione VHF dipendente è limitata (al massimo) a un centinaio di miglia da una stazione domestica all'altra, il numero di stazioni che possono essere contattate tramite packet radio è alquanto limitato.

Poiché le trasmissioni digitali vengono convertite in e da segnali audio utilizzando la tecnologia modem standard, è possibile inviare trasmissioni a pacchetti tramite normali ripetitori vocali. Tuttavia, questa pratica presenta problemi sia tecnici che sociali, che la rendono poco saggia.

Tecnicamente, molti ripetitori vocali hanno caratteristiche di risposta audio che, sebbene non realmente evidenti con le trasmissioni vocali, introducono distorsioni significative che riducono l'affidabilità della ritrasmissione digitale. Inoltre, il codice Morse o gli identificatori vocali, i toni di telemetria della frequenza o dell'intensità del segnale e i segnali acustici di "superamento" possono essere confusi come segnali di pacchetto dai controllori di pacchetti meno sofisticati.

Socialmente, i toni stridenti del modem generati dalle apparecchiature a pacchetto sono estremamente fastidiosi per gli utenti voce, causando disturbi, interferenze e generale disappunto. Inoltre, molti controllori di pacchetti riconoscono solo i toni del modem a pacchetto, quindi non riconoscono che una frequenza è occupata quando è occupata da trasmissioni vocali e possono trasmettere disturbando una conversazione vocale esistente.

I ripetitori digitali, noti come digipeaters, forniscono un mezzo per ritrasmettere automaticamente i segnali dei pacchetti, ma poiché i pacchetti di riconoscimento devono essere restituiti dall'estremità lontana della connessione sul percorso di collegamento possibilmente multi-hop, la velocità effettiva di trasmissione è notevolmente ridotta. Inoltre, attualmente non esiste alcun controllo delle collisioni quando i segnali vengono ripetuti in formato digitale. Pertanto, in caso di collisione di pacchetti, gli attuali digipeater non sono in grado di rilevare la collisione e ritrasmettere il pacchetto distrutto dalla collisione. La stazione originaria deve quindi attendere la mancanza di riconoscimento dall'estremità lontana della connessione e inviare nuovamente il pacchetto. La ripetizione dei pacchetti inviati dalla stazione di origine può benissimo occupare grandi quantità della capacità di trasmissione disponibile di una rete.

La soluzione di rete

Riteniamo che la soluzione a questi problemi risieda in una rete dedicata per le comunicazioni a pacchetto, proprio come le reti a commutazione di pacchetto che spostano regolarmente milioni di caratteri di dati ogni giorno attraverso il paese e in tutto il mondo.

La rete è semplice. Ogni comunità (o area geografica) ha almeno un Packet Network Controller [PNC] che funge da gateway di rete che costituirebbe l'accesso alla rete a pacchetti per quell'area. Queste stazioni funzionerebbero automaticamente, senza operatore umano, e servirebbero a fornire connessioni per gli utenti locali e di rete. Ciascun PNC avrebbe almeno un PNC vicino e potrebbe stabilire connessioni logiche verso e attraverso i PNC adiacenti.

AMPRNET[4] è strutturato come una rete di PNC, ciascuno dei quali ha uno o più PNC vicini a cui può connettersi tramite collegamenti radio. Ciascuno di questi PNC è connesso ad altri PNC e così via, finché tutti i PNC nella rete non sono raggiungibili tramite uno o più hop. Le connessioni tra PNC non adiacenti vengono effettuate facendo in modo che i PNC adiacenti trasmettano i pacchetti tra i due endpoint della connessione logica.

Ogni PNC ha una tabella di instradamento che descrive almeno un percorso verso ogni altro PNC accessibile. Utilizzando questa tabella, è possibile per qualsiasi PNC contattare qualsiasi altro PNC, possibilmente attraverso una serie di salti di relè intermedi. La tabella di instradamento viene creata e aggiornata dinamicamente man mano che la topologia della rete cambia con i nodi che entrano ed escono dal servizio.

La rete vista dall'utente

La connessione tramite la rete viene stabilita in due fasi distinte. Innanzitutto, un utente si connette al PNC locale. Abbiamo scelto l'uso del valore ssid (campo di identificazione secondaria della stazione) 14 (quattordici in base dieci) come designatore riservato per le stazioni PNC, quindi una connessione avviata (ad esempio) da un TNC TAPR potrebbe apparire come

CONNECT WB6CYT-14

che ordinerebbe alla tua stazione di connettersi al PNC gestito da WB6CYT. Sullo schermo verrà visualizzato il messaggio "connesso", seguito dal messaggio "rete pronta".

Successivamente, dovrai istruire il PNC a tentare di connettersi alla stazione che desideri chiamare. Per fare ciò è necessario conoscere l'identificativo del PNC che serve la sua zona. Quindi, ad esempio, per contattare Harold Price a Los Angeles, potresti chiedere al PNC di connetterti alla sua stazione a pacchetti tramite uno dei PNC di Los Angeles:

CONNECT NK6K@WB6YMH (il -14 è implicito qui)

supponendo che WB6YMH stesse operando con quel PNC. La rete si occuperà di stabilire la connessione e di tutto l'instradamento dei pacchetti necessari. Al termine della conversazione, la disconnessione da una delle due estremità causerà la chiusura anche della connessione virtuale sulla rete. Si noti che le connessioni possono essere interamente locali e coinvolgere solo il PNC locale; ciò fornisce una connessione ripetuta su area locale più affidabile rispetto all'attuale tecnologia digipeater.

Prevediamo che il PNC fornisca anche altri servizi. Tra quelli previsti ci sono:

+ Chi è nell'elenco

+ Stato della rete

+ Server di data e ora

+ Monitoraggio della sicurezza del sito

Protocolli di rete

Sebbene esistano molte proposte per stabilire un protocollo standard per il collegamento di stazioni a pacchetto amatoriali, attualmente non esistono risultati sperimentali che dimostrino un chiaro vantaggio per una scelta rispetto ad un'altra.

Il protocollo scelto deve tenere conto di due diversi aspetti della rete. Innanzitutto c'è la questione del trasporto tra i nodi della rete e, in secondo luogo, il formato dei dati trasportati dalla rete. Questi non sono necessariamente risolti dalla stessa risposta.

Il protocollo di trasporto descrive il metodo scelto per trasportare i messaggi tra i nodi della rete. Mentre per una linea fissa sarebbe sufficiente un semplice collegamento seriale ASCII, per i collegamenti radio più comuni si dovrebbe scegliere un mezzo affidabile. Nella nostra ricerca, abbiamo scoperto che l’attuale implementazione del protocollo AX.25 (utilizzato da TAPR, VADCG, GLB e altri) sarebbe utile. Dispone di rilevamento e correzione degli errori, è efficiente e sia il software che l'hardware per il suo utilizzo sono prontamente disponibili. Per questi motivi abbiamo scelto di utilizzare il protocollo AX.25 per la maggior parte dei collegamenti radio nodo-nodo della rete.

Il protocollo di comunicazione AMTOR presenta anche alcuni vantaggi distintivi per i collegamenti che si trovano sulle bande amatoriali HF. Nei casi in cui i collegamenti tra i nodi della rete debbano estendersi per grandi distanze, si potrebbe utilizzare il protocollo AMTOR e riteniamo sia adatto allo scopo.

Il formato dei messaggi trasportati dalla rete è indipendente dal protocollo di trasporto utilizzato. Poiché si prevede che i collegamenti svaniranno e subiranno interferenze e che i nodi falliranno, è saggio utilizzare un protocollo sufficientemente robusto da risolvere molti di questi problemi. Dopo approfondite ricerche in letteratura e considerando la base di software e sistemi già installati, abbiamo scelto il meccanismo Internet TCP/IP per il protocollo dei messaggi [5].

TCP/IP è progettato per funzionare con un sistema di trasporto inaffidabile e le sue prestazioni migliorano quando il sistema di trasporto sottostante è più affidabile. Incorpora meccanismi di riassemblaggio e riordino dei pacchetti in grado di far fronte ai pacchetti persi, ai pacchetti ricevuti fuori ordine e ai pacchetti duplicati. Poiché lo schema di instradamento di rete descritto di seguito ospiterà un nodo guasto instradandolo attorno fintanto che esiste un percorso tra i nodi di rete endpoint di una connessione, è stato un grande vantaggio scegliere il protocollo TCP/IP che utilizzasse correttamente tale funzionalità .

TCP/IP presenta anche altri vantaggi che riteniamo lo collochino come il principale contendente per il protocollo di messaggistica interno. È stato dimostrato da oltre 10 anni di utilizzo su DOD Arpanet/Milnet/Internet; sono disponibili implementazioni per sistemi informatici che vanno dai mainframe VAX al PC IBM; è completamente definito e documentato; esistono già altre strutture che utilizzano il protocollo TCP/IP per il trasferimento di file e l'utilizzo di computer remoti; e gran parte del software necessario per implementare TCP/IP è disponibile gratuitamente. Pertanto, si prevede di implementare la rete in modo tale che tutte le comunicazioni tra PNC vengano eseguite utilizzando datagrammi del protocollo Internet [IP] per consentire la massima flessibilità nell'instradamento e nel trasporto dei dati, indipendentemente dal tipo di collegamento utilizzato tra i nodi. Ciò consente l'interconnessione diretta a Internet o qualsiasi altra rete compatibile con IP, qualora lo si desideri.

Hank Magnuski, KA6M, ha ottenuto l'assegnazione di un numero di rete Internet di Classe A per la radio a pacchetto amatoriale.[6] Si prevede che a ciascun PNC verrà assegnato il proprio blocco univoco di numeri host. Nel caso di PNC prodotti, gli indirizzi host PNC verranno assegnati al momento della spedizione dell'unità. Per le unità homebrew, un registro centrale assegnerà il numero. Poiché questi numeri sono lunghi 24 bit, sono disponibili diversi milioni di numeri. Il numero identifica semplicemente l'indirizzo PNC ed è molto simile a un numero di serie hardware. Non è necessario modificarlo quando un PNC viene venduto o spostato o gli viene assegnato un nuovo nominativo. Per quelli di voi che hanno familiarità con Internet, viene utilizzato un protocollo di risoluzione degli indirizzi per mappare dinamicamente i numeri degli indirizzi Internet PNC sul nominativo PNC.

Instradamento sulla rete

Le tabelle di routing vengono create e gestite automaticamente dai nodi della rete. Alla prima attivazione o dopo un reset del sistema, il PNC non ha connessioni con le stazioni vicine. Ogni volta che un PNC non ha connessioni invia periodicamente un messaggio beacon broadcast (probabilmente ogni 10 minuti) finché non ha stabilito almeno una connessione con un PNC vicino. Quando un PNC vicino riceve un tale beacon, tenta di aprire una connessione con il PNC che invia il messaggio beacon. Ogni volta che viene rilevata un'attività di rete da nodo a nodo, le tabelle di instradamento vengono aggiornate da tutti i PNC che hanno ricevuto i messaggi in modo che ciascuno possa comprendere la connettività di rete più recente. Le tabelle di routing possono anche essere scambiate per fornire aggiornamenti.

Se un PNC già presente nella tabella di instradamento non è stato attivo per un certo periodo di tempo, viene inviato un messaggio a quel PNC per verificare che sia ancora attivo. Questo si chiama ping e verrà probabilmente eseguito dopo che sono trascorsi 30 minuti di inattività.

Se un tentativo di comunicazione con un PNC vicino fallisce per qualsiasi motivo, durante il normale inoltro dei pacchetti o a causa di un ping non riuscito, il PNC verrà eliminato dall'elenco delle connessioni aperte e dalla tabella di instradamento e non verrà più utilizzato per l'inoltro dei pacchetti. dal PNC che rileva il guasto. Pertanto, la rete si riprenderà e indirizzerà qualsiasi guasto che non isoli un nodo. Quando il PNC guasto si ripristina, il suo segnalatore o altre attività avviseranno i vicini che è tornato in servizio.

Non è necessario che le connessioni tra PNC siano collegamenti radio. Saranno impiegabili anche modem, linee fisse, fibre ottiche o altri mezzi. In questi casi i messaggi inviati dal PNC su questi collegamenti sono identici a quelli che avrebbero viaggiato sul circuito radio virtuale AX.25, quindi non ci sarà alcuna differenza di funzionamento con questi altri tipi di collegamenti.

Ringraziamenti

I miei più sentiti ringraziamenti a Mike Brock WB6HHV, per i suoi preziosi suggerimenti sulla progettazione della rete, nonché per il suo aiuto nella preparazione di questo documento.

I miei ringraziamenti vanno anche alle numerose persone del Vancouver Amateur Digital Computer Group e della Tucson Amateur PacketRadio Inc, e a Phil Karn KA9Q, Rod Hart WA3MEZ, Harold Price NK6K e Skip Hansen WB6YMH per i loro contributi e suggerimenti.

Riferimenti utili

  1. ARDC memorial - https://www.ardc.net/in-memoriam-brian-kantor-wb6cyt-1953-2019/
  2. A Proposed Network for the interconnection of Amateur Digital Packet Radio Stations - https://wiki.ampr.ari.it/images/1985_Kantor.pdf
  3. https://en.wikipedia.org/wiki/Hank_Magnuski
  4. Ringrazio Hank Magnuski, KA6M per il nome della rete
  5. Una nota speciale per ringraziare Phil Karn, KA9Q per il suo suggerimento che TCP/IP potesse funzionare su AX.25 - Phil, è stata un'idea brillante e ha risolto un problema di cui discutevamo da qualche tempo
  6. Ciò è registrato nella Comunicazione della Difesa Network Information Center dell'Agenzia come numero di rete 044.xxx.xxx.xxx AMPRNET come documentato in Internet RFC 870 dell'ottobre 1983 - https://datatracker.ietf.org/doc/html/rfc790

Note

Il testo originale è stato liberamente tradotto da Gian Leonardo Solazzi [IW2NKE] il 16 febbraio 2024