AX.25 SPECIFICHE DEL PROTOCOLLO - LIVELLO 2
Ricavato da:
"AX.25 link-layer spec." de AK1A;
"AX.25 amteur packet radio link-layer protocol" de WB4JFI.
Traduzione di IW1AYD.
AX.25 link-layer protocol.
Questo protocollo e' conforme alle raccomandazioni ISO 3309, 4335
(includendo DAD 1&2) e 6256 high-level data link control (HDLC) e usa della
terminologia rintracciabile in questi documenti. Questo protocollo e' anche
conforme alla ANSI X3.66, che descrive ADCCP, in modo bilanciato.Questo
protocollo e' scritto per poter lavorare egualmente bene in ambienti
radioamatoriali sia half che full duplex.Questo protocollo permette che sia
stabilito piu' di un collegamento al livello due (link layer) per
apparecchiatura, sempre che questa lo permetta. Questo protocollo segue
anche, in linea di principio, la raccomandazione CCITT X.25, con eccezioni
per quanto riguarda: estensione campo d' indirizzo; aggiunta delle
Unnumbered Information (UI) frame. La maggior parte dei protocolli di link-
layer a livello due danno per inteso che la comunicazione avvenga tra una
grossa apparecchiatura, detta DCE o Data Circuit-terminating Equipment,
collegata a diverse altre piu' piccole, dette DTE o Data Terminating
Equipment . Una tale assegnazione di funzioni non e' auspicabile in un mezzo
condiviso qual' e' il tipico canale radioamatoriale. AX.25 presuppone che
tutti e due le terminazioni della linea siano bilanciate, ovvero elimina
entrambe le classi di apparecchiature descritte. AX.25 considera una nuova
classe di apparecchiature (devices) i DXE. Devices capaci di svolgere sia i
compiti di un DCE che di un DTE in egual misura, bilanciati
Struttura del pacchetto.
Le trasmissioni a livello due in Packet Radio (d' ora in poi P.R.) sono
costituite da piccoli "blocchi", pacchetti (frames). Ogni frame e' l'
insieme di parti piu' piccole unite in sequenze logiche univoche, detti
fields (campi).
Primo
bit
trasmesso.
+-----------------------------------------------------------------------+
! Flag ! Address ! Control ! FCS ! Flag !
+-----------------------------------------------------------------------+
! 01111110 ! 112/560 bits ! 8 bits ! 16 bit ! 01111110 !
+-----------------------------------------------------------------------+
Esempio di pacchetto U o S.
+------------------------------------------------------------------------+
!Flag ! Address !Control ! PID ! Info ! FCS ! Flag!
+------------------------------------------------------------------------+
!01111110! 112/560 Bits ! 8 bits ! 8 bits ! N*8 bits ! 16 bits ! 01111110!
+------------------------------------------------------------------------+
Esempio di pacchetto I.
Definizione di campo.
Ogni pacchetto e' formato da piu' campi. Ogni campo, field, e' composto
da gruppi di otto bit, octets o bytes, e ha specifiche funzioni.
Flag Field.
Campo Flag. Dato che il P.R. e' un protocollo orientato al bit, l' unico
modo per avvertire il corrispondente del termine di un pacchetto e della
partenza di un altro, per evitare overrun e perdite di dati, e' l' invio di
un campo di delimitazione per l' inizio e la fine di ogni frame. Questo
campo viene chiamato FLAG field, consiste di un bit a 0 seguito da sei bit a
1 e di nuovo da uno 0, ovvero dal byte: 01111110 (7E esadecimale). Come si
vedra' di seguito, vi sono dei meccanismi che eseguono il bit stuffing per
evitare il ripetersi di questo ottetto "all' interno" di un frame, le uniche
volte in cui questa sequenza e' non solo permessa ma valida sono l' inizio e
la fine di ogni pacchetto valido. Esiste la possibilita' di utilizzare
questo segnale come idle (mantenimento della portante modulata dal segnale),
infatti il corrispondente ogni volta che termina di decodificare un byte
cosi' composto attende il prossimo come inizio valido del pacchetto a
seguire. Se il prossimo byte sara' di nuovo un flag viene mantenuto lo stato
iniziale di attesa della parte utile del pacchetto, questo ciclo puo' esser
ripetuto. Ecco che quindi viene utilizzato il FLAG iniziale ripetuto piu'
volte per dare maggior margine di "assestamento" alle catene RTX analogiche.
Address Field.
Il campo d' indirizzamento, Address, viene usato per conoscere origine e
destinazione di ogni singolo frame. Nella raccomandazione CCITT X.25, questo
campo e' lungo al massimo un byte. Quindi permette al massimo 256
utilizzatori per ogni canale P.R. livello 2. Ancora, siccome alcuni bit di
questo campo hanno altri usi, non sono tutti dedicati all' indirizzamento,
questo farebbe cadere il numero di utilizzatori contemporanei al livello di
30 per ogni canale. Entrambe le raccomandazioni HDLC e ADCCP permettono l'
estensione del campo d' indirizzamento. Il protocollo amatoriale AX.25
prevede quindi, per comune decisione, l' estensione dell' ADDRESS field per
permettere l' inserzione dei nostri nominativi, sia del destinatario
(destination) che del mittente (source)in ogni pacchetto. Piu' avanti verra'
descritto il modo con il quale questo elongamento viene ottenuto.
Control Field.
Il campo di controllo viene usato per identificare il tipo di frame e
altri attributi della connessione a livello 2. E' lungo un byte.
Campo PID .
Protocol Identifier field: campo identificatore di protocollo. E' usato
solo nei pacchetti d' informazione, identifica che tipo di livello 3 e' in
uso, ammesso che ve ne sia uno. La sua decodifica ha questi valori:
M L
S S
B B
xx00xxxx Per usi futuri.
xx01yyyy AX.25 level 3 layer implementato
xx10yyyy AX.25 " " " " " " " "
11110000 Layer 3 non implementato.
11111111 Sequenza di ESCAPE, il prossimo byte sara' di PID.
Dove:
x. indica bit non importanti.
y. indica ogni possibile combinazione.
Information Field.
Campo d' Informazione. Questo e' l' unico campo del pacchetto che
contiene le informazioni utili. Il resto dei campi introduce overhead, in
quanto non trasporta informazioni degli utilizzatori ma "solo" dati di
funzionamento del protocollo. Il field d' Informazione e' valido solo per
tre tipi di pacchetti: I frames, UI, frames e FRMR frames. Ovvero:
Information frames; Unnumbered Information frames; FRaMe Rejected frames. Il
campo I puo' essere lungo sino a 256 bytes, comunque la sua lunghezza deve
essere un multiplo pari di bytes, al minimo due bytes. Tutti i dati che
inseriti all' interno vengono inseriti all' interno dell' I field vengono
passati in modo "trasparente" dal mittente al destinatario lungo il link.
Salvo per l' inserzione di un bit a 0 necessaria per evitare che un FLAG
compaia all' interno del campo dati (bit stuffing).
Frame Check Sequence.
Campo di controllo del pacchetto, e' un numero composto espresso in 16
bit e viene calcolato sia dal destinatario che dal mittente di ogni
pacchetto. Il mittente lo calcola e lo inserisce nel pacchetto a spedire, il
destinatario lo ricalcola (in base ai dati ricevuti) e lo controlla con
quello speditogli nel frame. Ha compiti di verifica dell' integrita' del
pacchetto dopo la trasmissione attraverso il mezzo, viene calcolato secondo
l' algoritmo suggerito nella raccomandazione ISO 3309 (HDLC).
Bit Stuffing.
Per assicurarsi che la sequenza di bits del campo di FLAG non compaia
all' interno degli agli campi, questo invaliderebbe il pacchetto, prima che
ogni singolo frame venga trasmesso, ne viene eseguita una scansione, con una
finestra di cinque bits mobile lungo il pacchetto. Se all' interno della
finestra vi sono piu' di cinque bits a 1 viene aggiunto, questo viene
scoperto alla letture del quinto bit consecutivo a "1", tra il quinto e il
sesto viene aggiunto uno "0". Si elimina cosi' la possibilita' che vi sia in
un punto qualsiasi, partendo da un un bit qualsiasi dopo il byte di FLAG, il
valore assegnato per il campo FLAG. Il ricevente arrivato al quinto bit
consecutivo a "1" salta automaticamente il sesto bit, che sara' lo zero
introdotto precedentemente, prima di passare i dati ai"livelli" piu' alti di
gestione del pacchetto.
Bit Order of Transmission.
Ordine di trasmissione dei bit. Con l' eccezione dell' FCS (Frame Check
Sequence), tutti gli altri campi di ogni pacchetto AX.25 vengono trasmessi
partendo dal Least Significant Bit (LSB), bit meno significativo. In accordo
con la pratica HDLC il campo FCS vede come primo bit trasmesso il Most
Significant Bit, bit piu' significativo.
Frame Abort.
Termine trasmissione pacchetto, forzato. Se un pacchetto deve essere
terminato prematuramente, devono essere trasmessi almeno quindici bit
consecutivi a "1", senza bit stuffing.
Invalid Frame.
Pacchetto non valido. Ogni pacchetto piu' corto di 136 bits, o non
incluso nei campi di FLAG (un byte con valore binari"011111"), o non
composta da byte allineati (bytes incompleti, numero di bits non divisibile
per 8 senza resto), verra' considerata invalida da questo livello.
Address Field Encoding.
Codifica del campo d' indirizzo. Il campo d' indirizzo di tutti i
pacchetti viene codificato con i nominativi dei radioamatori, sia mittente
che destinatario. Se viene usato un ripetitore a livello 2, il suo
nominativo sara' riportato sempre nel campo d' indirizzamento. AX.25 segue
la forma prevista dal protocollo HDLC per elongare il campo d'
indirizzamento, per farvi "entrare" tutti i dati a noi necessari.HDLC, per
elongare il campo d' indirizzamento, prevede che il bit meno significativo
di ogni byte se settato a "1" indichi che il byte successivo conterra'
ancora un dato utile d' indirizzamento. Viceversa quando il bit sara' a
zero, dara' il termine del campo. Questo bit viene chiamato "extender bit"
(bit d' estensione). Per creare spazio all' e.b., i nominativi vengono
shiftati di un bit a sinistra (vedi TRACE ON/OFF nella sua tipica
visualizzazione a ottanta colonne).
Non-Repeater Address-Field Encoding.
Codifica del campo indirizzo per frame non indirizzato o proveniente
tramite un ripetitore.
+--------------------------------------------------------+
! Campo d' Indirizzo !
+--------------------------------------------------------+
! Indirizzo di destinazione ! Indirizzo del mittente !
+--------------------------------------------------------+
! A1 A2 A3 A4 A5 A6 A7 ! A8 A9 A10 A11 A12 A13 A14 !
+--------------------------------------------------------+
Se non viene usato un ripetitore a livello 2 la codifica viene dell'
indirizzo e' la seguente: nominativo del mittente, chi spedisce; nominativo
del destinatatrio, chi dovra' ricevere il pacchetto. Questi due nominativi
sono gli unici necessari per un frame a livello 2, AX.25 link layer. Nel
caso di due nominativi del tipo XXNYYY-N, avremo quattordici bytes (il
trattino dell' SSID non viene trasmesso ma riaggiunto localmente) da usarsi
per l' indirizzamento. Questi quattordici bytes massimi d' indirizzamento
per il livello 2 sono a loro volta suddivisibili in due sottocampi,
indirizzo mittente e indirizzo destinatario, lunghi a loro volta sette bytes
ciascuno. L' ordine di trasmissione prevede ,temporalmente, prima il
sottocampo destinatario, poi il sottocampo del mittente; questo per dar
agio al decodificante di comprendere, prima della fine di ogni frame, se
questo e' indirizzato a lui. Quindi avremo il sottocampo destinatario nei
bytes da A1 a A7, seguira' nei bytes da A8 a A14 il sottocampo mittente.
Entrambi i sottoc. hanno la medesima configurazione, l' ultimo byte, il
settimo per il destinatario e il quattordicesimo per il mittente,
contengono la codifica per il Secondary Station IDentifier (identificatore
secondario di stazione), SSID. Questo permette un uso piu' omogeneo del
proprio nominativo per ogni stazione o digipeater o gateway che si intenda
installare.
Destination Sub-Field Encoding.
Codifica del sottocampo di destinazione. Data l' eguaglianza di codifica
tra i due sottocampi vedremo ora quella relativa al sottoc. destinatario.
+-------------------------------------+
! BYTES ! ASCII ! BIN.DATA ! HEX DATA !
+-------+-------+----------+----------+
! A1 ! I ! 01001001 ! 49 !
! A2 ! W ! 10101110 ! AE !
! A3 ! 1 ! 00110001 ! 31 !
! A4 ! A ! 01000100 ! 41 !
! A5 ! Y ! 01011001 ! 59 !
! A6 ! D ! 01000100 ! 44 !
! A7 ! -SSID ! CRRSSID0 ! nn !
+-------------------------------------+
! MSB 76543210 LSB !
! posizione bit !
+-------------------------------------+
Dove:
1> Il byte A1 e' il primo ad esser trasmesso , il bit 0 inizia la
trasmissione (LSB), seguira' fino al bit 7 (MSB). Iniziera' il
percorso quindi il bit 0 del byte A2 ... fino al termine.
2> Il bit 0 (LSB) di ogni byte e' il bit di estensione per l'
indirizzo HDLC , settato a 0 in ogni byte salvo che nell' ultimo byte
utilizzato per il campo d' indirizzamento. Li' sara' settato a uno,
per dare il termine del campo, ovvero di tutti i sottocampi usati.
Vedere paragrafo successivo.
3> I bit marcati "R" sono bit riservati, non usati nel presente
protocollo. Utilizzabili in network locali. Vanno posti a 1, se non
usati, come visto qui.
4> I caratteri del nominativo devono essere in alfabeto standard
ASCII ed unicamente maiuscoli, viene quindi eseguito lo shift di un
bit a sinistra per creare spazio al bit di estensione dell'
indirizzo. Se il nominativo e' piu' corto dello spazio da occupare, 6
bytes (6 caratteri), viene riempito lo spazio mancante tra la fine
del nominativo e SSID (che non viene mosso!) con degli spazi.
5> I bits nel byte riservato all' SSID sono intenzionalmente non
caricati con una maschera prefissata. Viene lasciato al singolo il
compito di utilizzarlo come meglio aggrada per estendere il
protocollo.
Level 2 Repeater Address Field Encoding.
Se un pacchetto e' destinato a viaggiare attraverso uno o piu'
digipeaters a livello 2 viene aggiunto un sottocampo d' indirizzamento che
conterra' il/i nominativo/i del/i digipeater/s da usarsi. Questo abilita la
condivisione di un canale da parte di piu' digi., cosa non possibile, o che
comunque creava problemi, con protocolli precedenti. L' ultimo byte del
sottocampo d' indirizzo, del mittente, avra' il bit in posizione zero, LSB
settato a "1". Questo indichera' che seguono altri sottocampi d' indirizzo.
Allo stesso modo il primo sottocampo d' estensione, contenente il call del
primo digipeater, nel caso di piu' digipeater, avra' il bit zero del byte
A21 (14+7=21) posto a uno. Questo sempre per indicare che il prossimo byte
e' di Extended Address Area (Area d' Estensione d' Indirizzo). Qui di
seguito viene data la tabella esplicativa per il terzo sottocampo d'
indirizzo. In questo caso il medesimo nominativo, dell' esempio precedente,
viene usato come digipeater a livello 2.
+-------------------------------------+
! BYTES ! ASCII ! BIN.DATA ! HEX DATA !
+-------+-------+----------+----------+
! A15 ! I ! 01001001 ! 49 !
! A16 ! W ! 10101110 ! AE !
! A17 ! 1 ! 00110001 ! 31 !
! A18 ! A ! 01000100 ! 41 !
! A19 ! Y ! 01011001 ! 59 !
! A20 ! D ! 01000100 ! 44 !
! A21 ! SSID ! HRRSSID1 ! nn !
+-------------------------------------+
! MSB 76543210 LSB +
! posizione bit !
+-------------------------------------+
(Osservare il byte A21, bit 7 e 0)
Dove:
1> Il byte piu' in alto, A15, viene trasmesso per primo. Di quello e
dei bytes successivi viene trasmesso per primo il bit in posizione 0,
LSB.
2> Come per i campi d' indirizzo destinatario e mittente il bit in
posizione 0 di ogni byte e' il bit che segnala l' estensione del
campo d' indirizzamento, e' settato a 0 dappertutto salvo nell'
ultimo byte, A21, dove e' a "1" per indicare la continuazione dell'
indirizzo nel prossimo byte.
3> I bit denominati R sono sempre riservati.
4> Il bit denominato H, vale "0" se il pacchetto non e' stato ancora
ripetuto dal digipeater specificato e "1" viceversa.
Control Field Format.
Formato del campo di controllo. Il campo di controllo e' responsabile
dell' identificazione del tipo di pacchetto rappresentato, e' necessario per
definire il tipo e l' uso delle informazioni presenti nei pacchetti.Permette
il mantenimento del controllo degli eventi di link (collegamento-
connessione) tra le stazioni.
La costruzione del campo di controllo di AX.25 e' ripresa dalla
raccomandazione CCITT X.25 per operazioni bilanciate (LAPB), con in piu' l'
aggiunta di un sottocampo di controllo ulteriore ripreso da ADCCP per
permettere trasmissioni circolari e a stazioni non connesse.
Vi sono tre tipi principali di pacchetti in AX.25:
1) Information frame o I frame;
2) Supervisory frame o S frame;
3) Unnumbered frame o U frame .
Rispettivamente, I f. ... pacchetti d' Informazioni, S f. ... pacchetti
di Supervisione del protocollo e U f. ... pacchetti d' informazione senza un
bersaglio finale specifico. Il formato del control field e' il seguente:
+-------------------------------------+
! TIPO ! BIT CAMPO CONTROLLO !
! PACCHETTO ! M posizione L !
! ! 7 6 5 ! 4 ! 3 2 1 ! 0 !
+-------------+-------+---+-------+---+
! I frame ! N(R) !P/F! N(S) ! 0 !
+-------------+-------+---+-------+---+
! S frame ! N(R) !P/F! S S 0 ! 1 !
+-------------+-------+---+-------+---+
! U frame ! M M M !P/F! M M 1 ! 1 !
+--------------------------------------
Dove:
1> Il bit 0 (LSB) e' il primo trasmesso, il bit 7 e' l' ultimo.
2> N(S) e' il numero progressivo della sequenza di pacchetti
trasmessi. Il bit 2 e' il meno significativo (LSB).
3> N(R) e' il numero progressivo della sequenza di pacchetti ricevuti
. Il bit 6 e' il meno significativo.
4> S sono i bit usati in modo Supervisor.
5> M sono i bit usati in modo Unnumbered.
6> Il bit P/F e' il sottocampo di Poll/Final. La sua funzione verra'
descritta piu' avanti.
Control Field Definitions.
Definizioni del campo di controllo.
Information Frame Control Field
Disposizione del campo di controllo per un pacchetto di tipo
Informazione. Tutti i pacchetti di tipo I, ovvero con dati d' utente
presenti, hanno il bit 0 del campo di controllo settato a "0". N(S) e' il
numero del pacchetto nella sequenza di trasmissione, il numero del pacchetto
che viene trasmesso. N(R) e' il numero di pacchetto che ci si aspetta di
ricevere (numero ultimo pacchetto ricevuto + 1). La messa in sequenza di
questi numeri verra' comunque meglio esposta piu' avanti.
Supervisory Frame Control Field.
Disposizione del campo di controllo per i pacchetti di Supervisione. I
pacchetti di tipo S si distinguono per avere il bit 0 del campo di controllo
a "1" e il bit 1 a "0". I pacchetti di tipo S permettono lo scambio d'
informazioni specifiche al mantenimento del link (connessione,
collegamento). Servono quindi per lo scambio di acknoweledge (RR), le
richieste di ritrasmissione dei pacchetti di tipo I, piu' in generale sono i
messaggi di servizio. Dato che i frame di tipo S non contengono campo dati,
le sequenze di conteggio in ricezione e trasmissione non sono affette da
questi pacchetti.
Unnumbered Frame Control Field.
Pacchetti d' informazione non numerati. Gli U frame hanno nel campo di
controllo entrambi i bit 0 e 1 settati a "0". Sono responsabili dello
scambio di alcuni messaggi di controllo al disopra dei compiti dei pacchetti
di tipo S. Sono anche responsabili dell' instaurazione e caduta del
collegamento (UA). I pacchetti di tipo U sono anche responsabile della
ricezione e trasmissione di informazione al di fuori del normale controllo
di flusso. I pacchetti di tipo U possono contenere o non contenere il campo
dati.
Control Field Parameters.
Parametri del campo di controllo.
Sequence Numbers and Variables
Variabili e numeri di sequenza.A ogni pacchetto di tipo I sara' assegnato
un numero in sequenza con gli altri che lo precedono e quelli che lo
seguiranno dello stesso tipo (I). Questa numerazione va' da 0 a 7
(sottocampo di 3 bit), questo permette che vi siano fino a sette pacchetti
in attesa di essere spediti.
Send State Variable V(S).
Variabile di stato per la trasmissione. La variabile di stato per la
trasmissione e' una variabile interna e non viene mai trasmessa al
corrispondente. Contiene il numero di sequenza da assegnare al prossimo
pacchetto da trasmettere. Questa variabile viene aggiornata alla
trasmissione di ogni frame.
Send Sequence Number N(S)
Numero di sequenza in trasmissione. Questo numero e' presente all'
interno di ogni campo di controllo dei pacchetti di tipo I. Contiene il
numero di sequenza del pacchetto che sta' per essere trasmesso. Giusto un
istante prima della effettiva trasmissione di ogni pacchetto di tipo I ,
N(S) viene aggiornato al valore di V(S) (che nel frattempo viene
riaggiornato).
Receive Status Variable V(R)
Variabile di stato per la ricezione. Questa variabile contiene il numero
di sequenza del prossimo pacchetto di tipo I da riceversi (vedi V(S) per la
trasmissione). Questa variabile viene aggiornata ogni volta che venga
ricevuto il pacchetto voluto, numerato correttamente (ovvero con N(S)
trasportato dal pacchetto uguale alla V(R) corrente), senza errori.
Received Sequence Number N(R)
Numero di sequenza ricevuto. Si trova nei pacchetti di tipo I e S. Prima
di ogni trasmissione questa variabile viene aggiornata al valore di V(R),
viene cosi' resa implicita la conferma positiva a tutti i pacchetti, di tipo
I, correttamente ricevuti fino a N(R)-1 incluso.
Poll/Final (P/F) Bit
Il bit di P/F puo' essere utilizzato in tutti i tipi di pacchetti. Viene
usato in modo comando (poll, leggi richiesta-ricerca) per richiedere una
risposta immediata. Nel pacchetto di risposta a quel comando lo stesso bit
avra' il senso di response (leggi risposta, final leggi finale ... termine
esecuzione del comando richiesto). Solo una condizione di poll alla volta,
per DXE, puo' essere in attesa d' esecuzione remota.
Control Field Encoding.
Codifica del campo di controllo.
Information Frame Control Field
I pacchetti d' informazione, I, sono numerati sequenzialmente come dianzi
detto. Questo e' necessario per mantenere traccia e controllo del passaggio
di questi pacchetti attraverso i vari "stadi" del link (collegamento).
Questo e' il formato del campo di controllo per questo tipo di pacchetti.
Control Field Bits
+-----------------------+
! 7 6 5 ! 4 ! 3 2 1 ! 0 !
+-------+---+-------+---+
! N(R) !P/F! N(S) ! 0 !
+-----------------------+
Supervisory Frame Control Field
Campo di controllo per i pacchetti di supervisione. Questo tipo di
pacchetto viene usato in AX.25 solo come risposta a richieste fatte con
altri tipi di pacchetti.
+-------------------------------------+
! ! 7 6 5 ! 4 ! 3 2 ! 1 0 !
+-------------+-------+---+-----+-----+
!Receive ready! ! ! ! !
! RR ! N(R) !P/F! 0 1 ! 0 1 !
+-------------+-------+---+-----+-----+
!Re. not Ready! ! ! ! !
! RNR ! N(R) !P/F! 0 1 ! 0 1 !
+-------------+-------+---+-----+-----+
! Reject ! ! ! ! !
! REJ ! N(R) !P/F! 1 0 ! 0 1 !
+-------------------------------------+
Receive Ready (RR) Response
Letteralmente: pronto alla ricezione. Viene usato per i seguenti scopi:
1> Per indicare che chi trasmette RR e' pronto a ricevere pacchetti
di tipo I;
2> Per inviare ACK (ackoweledge, letteralmente accordo) ai pacchetti
di tipo I fin' ora ricevuti, includendo il frame N(R)-1;
3> Per ridare il via dopo una condizione di RNR allo scambio di dati
precedentemente bloccato.
Occorre far notare come lo stato dell' altro componente terminale del
link possa essere richiesto settando il bit di poll del sottocampo P/F.
Receive Not Ready (RNR) Response
Risposta di ricezione non possibile. Questo tipo d' indicazione viene
usata per indicare al trasmettitore dei pacchetti, di tipo I, che il
ricevitore e temporaneamente occupato e non puo' ricevere ancora altri
pacchetti. Ai pacchetti fino a N(R)-1 viene dato ACK. Ogni altro pacchetto
con numero di sequenza pari a N(R) o superiore, che sia anche gia' "sul"
link, non riceve acknoweledge dopo la trasmissione del comando di RNR. La
condizione di RNR puo' venir eliminata solo con l' invio di un UA, RR, REJ o
di un SABM. Il bit di P/F puo' venir usato in un frame RNR per interrogare
lo stato dell' altro partecipante al collegamento.
Reject (REJ) Response.
Responso di rifiuto. Il pacchetto di REJ viene usato per richiedere la
ritrasmissione di frames di tipo I al trasmettitore, a partire dal numero
N(R). Tutti i pacchetti gia' spediti con numeri di sequenza N(R)-1 o meno
ricevono ACK.
Solo una condizione di REJ e' permessa per ognuna delle due direzioni di
scambio. La condizione di REJ viene azzerata quando vengono ricevuti tutti i
pacchetti di tipo I fino all' ultimo che ha causato l' inizio della
condizione.
Come per le altre risposte di supervisione il bit di P/F puo' essere
usato nel pacchetto di REJ.
Unnumbered Type Frame.
Pacchetto d' informazione non numerato. Questo tipo di frame puo' essere
sia di comando che di risposta. Questo standard segue quanto piu' possibile
X.25. L' unica deviazione da quest' ultimo protocollo e' l' aggiunta dei
pacchetti non numerati d' informazione (UI) , presi dal protocollo ADCCP.
X.25 e' strutturato per lavorare in un ambiente full-duplex con una macchina
principale (DCE) e potenzialmente piu' utilizzatori (DTE).
L' ambiente radioamatoriale P.R. differisce sostanzialmente da questo
modello, almeno per quanto riguarda i due elementi citati. Non solo in campo
amatoriale esistono reti half-duplex, ma solo in campo radioamatoriale
esiste la specifica esigenza di condivisione delle risorse di un singolo
canale da parte di apparecchiature "duali", DTE/DCE. Per questa ragione
molti radioamatori hanno optato per uno standard che piu' facilmente di X.25
si adattasse alle nostre specifiche esigenze. X.25 e'stata facilmente
modificata per raggiungere i nostri scopi.
Tipologia dei pacchetti UI.
+-------------------------------------+
!DESCRIZIONE! ! ORDINE DEI BIT !
!CAMPO DI !TIPO! !
!CONTROLLO ! ! 7 6 5 4 3 2 1 0 !
+-----------+----+--------------------+
!Set Async. ! ! !
!Balance !CMD ! 0 0 1 P 1 1 1 1 !
!Mode-SABM ! ! !
+-----------+----+--------------------+
!Disconnect ! ! !
! DISC !CMD ! 0 1 0 P 0 0 1 1 !
! ! ! !
+-----------+----+--------------------+
!Disconn.ed ! ! !
!Mode !RES ! 0 0 0 P/F 1 1 1 1 !
! DM ! ! !
+-----------+----+--------------------+
!Unnumberd ! ! !
!Acknowel.ge!RES ! 0 1 1 F 0 0 1 1 !
! UA ! ! !
+-----------+----+--------------------+
!Frame ! ! !
!Reject !RES ! 1 0 0 F 0 1 1 1 !
! FRMR ! ! !
+-----------+----+--------------------+
!Unnumbered ! ! !
!Information!R/C ! 0 0 0 P/F 0 0 1 1 !
! UI ! ! !
+-------------------------------------+
Tipi di campi di controllo per i pacchetti U.
Set Asynchronous Balanced Mode (SABM) Command.
Questo comando e' usato per porre due stazioni in collegamento asincrono
in modo bilanciato, entrambi agiscono l' uno per l' altro come DCE e DTE. In
questo tipo di pacchetto non e' permesso il campo Informazione. Ogni
pacchetto "sul" link al momento della ricezione di questo comando resta
privo di ACK. (SABM letteralmente ... comando per il passaggio in modo
asincrono bilanciato).
Disconnect (DISC) Command.
Comando di disconnessione. E' usato per porre fine al collegamento, link,
tra due stazioni. Non e' permesso il campo I, ogni pacchetto in attesa di
ACK restera' tale.
Disconnected mode (DM) Response.
Risposta di disconnessione. Viene inviato da ogni stazione che riceva un
messaggio indirizzato a se stessa diverso da una SABM, mentre si trova
disconnessa. Inviato per richiedere un comando di set del modo, o per
indicare che al momento non c'e' possibilita' di connessione (BUSY). Il
frame di DM non puo' avere campo d' Informazione. Una stazione che si trovi
in uno dei due stati DCE o DTE rispondera' con un DM a ogni pacchetto che
non sia un SABM con il bit P/F settato a "1".
Unnumbered Acknoweledge (UA) Response.
Risposta di conferma non numerata. UA viene trasmesso per dare l'
accettazione di un pacchetto comandi di tipo U. Un comando ricevuto non
viene processato prima dell' invio del frame di UA in risposta. Il campo I
non e' permesso.
Frame Reject (FRMR) Response.
Risposta di rifiuto. Viene trasmessa per riportare all' altro lato (end)
del collegamento (link) che per qualche ragione l' esecuzione di un comando
o la ricezione di un pacchetto di tipo I, non puo' aver luogo e che l'
errore non e' recuperabile reinviando di nuovo il frame che ha dato il via
alla condizione. Questo succede, tipicamente, quando un pacchetto, senza
errori di FCS, e' stato ricevuto nelle seguenti condizioni:
1> La ricezione di un pacchetto con campi invalidi o con
comandi/responsi non implementati.
2> La ricezione di pacchetto d' informazione con un campo dati piu'
lungo del dovuto.
3> La ricezione di un pacchetto con N(R) fuori sequenza. Per esempio
nel caso che un pacchetto che ha gia' avuto ACK venga ritrasmesso o
N(R) sia comunque fuori sequenza rispetto a quanto atteso.
4> La ricezione di un pacchetto con il campo d' Informazione
nonostante non sia del tipo atto a possederlo o la ricezione non
corretta, per lunghezza, di pacchetti di tipo U o S.
Quando viene inviato un pacchetto FRMR, viene aggiunto un campo d'
informazione specifico. Questo campo, tre bytes, viene riempito con
informazioni riguardanti la causa dell' FRMR. Il suo contenuto viene esposto
qui di seguito:
+-------------------------------------------------+
! Information Field Bit !
!2 2 2 2 1 1 1 1 1 1 1 1 1 1 !
!3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 !
+--------+-+-+-+-+-----+-+-----+-+----------------+
! ! ! ! ! ! ! ! ! !Rejected Frame !
!0 0 0 0 !Z!Y!X!W! V(R)!C! V(S)!0! !
! ! ! ! ! ! ! ! ! !Control Field !
+-------------------------------------------------+
FRMR Frame Information Field.
Dove:
1> Il campo di controllo del frame rifiutato e' tolto pari pari dal
pacchetto che ha provocato l' inizio della sequenza e qui inserito.
2> V(S) e' la variabile di sequenza per la trasmissione del
dispositivo che invia FRMR, il bit 10 e' il LSB.
3> V(R) e' la variabile di sequenza per la ricezione del dispositivo
che invia FRMR, il bit 14 e' il MSB.
4> Se W e' alto, "1", il campo di controllo ricevuto era invalido o
non implementato.
5> Se X e' alto, "1", il pacchetto che ha provocato FRMR aveva un
campo Informazione mentre non era permesso perche' era di tipo U o S.
Il bit W deve essere settato in aggiunta a X.
6> Se Y e' settato a "1", il campo Informazione era piu' lungo di
quanto permesso dal device ricevente che sta' riportando la
condizione (quello che ha inviato FRMR appunto).
7> Se Z e' settato a "1", il campo di controllo ricevuto contiene un
numero N(R) di sequenza invalido (per chi lo sta' ricevendo).
8> I bit 8, e da 20 a 23 sono settati a 0. Il bit 12 e' settato a "0"
se il pacchetto ricevuto era un comando, a "1" se era un responso.
Unnumbered Information (UI) Frame.
Pacchetto d' informazione non numerato. Viene usato per trasferire
informazioni tra i due lati del collegamento al difuori del normale
controllo di scambio dati. Questo permette a campi d' informazione di
"viaggiare" avanti e indietro attraverso il link non usando il normale
controllo di flusso sequenziale . Salvo che, essendo questi frame non
numerati non possono ricevere ACK. Se uno di questi pacchetti viene perduto
non puo' essere recuperato in nessun modo.
Questo tipo di frame non e' previsto dal protocollo X.25, la sua
struttura aggiunta viene ripresa da ADCCP per permettere il passaggio di
informazioni "sul" link evitando d' interferire con i livelli superiori.
Link Error Recovery.
Vi sono diversi meccanismi, all' interno del protocollo, per recuperare
gli errori dovuti al collegamento senza provocarne la caduta. Questi
malfunzionamenti possono avvenire sia per problemi di DTE/DCE, da entrambi i
lati, sia per problemi del mezzo/mezzi usati per stabilire il link.
Invalid Frame or FCS Error.
Se viene ricevuto un pacchetto invalido o con FCS invalido (Frame Check
Sequence), viene "scaricata" (non visualizzata) e nessun altra azione viene
intrapresa.
Device Busy Condition.
Condizione di apparecchiatura occupata. Quando un DTE/DCE diventa
temporaneamente occupato per qualsiasi azione richiesta dall' altro DCE/DTE,
inviera' un pacchetto RNR. Questo dara' all' altro lato del link l'
informazione che il lato opposto del collegamento non ha la possibilita' di
trattare altre frames di tipo I. Questo stato viene resettato, da chi lo ha
iniziato, con un UA, RR, REJ o con un comando di SABM.
Send Sequence Number Error.
Se il numero di sequenza, N(S), trasportato da un frame di tipo I, anche
se privo di altri tipi di errore non e' quello atteso, dopo la comparazione
con la variabile di ricezione V(R), e occorso un errore nella sequenza di
trasmissione. Il campo d' Informazione viene scaricato. Il ricevitore non
dara' l' ACK per questo frame o ogni altro frame fino a che N(R) ricevuto
non sara' pari a V(R) atteso.
Il campo(i) di controllo del frame(s) di tipo I errato(i) viene(vengono)
decodificato(i). Le funzioni di supervisione vengono eseguite, cio' fa'
quindi cambiare lo stato del bit P/F nei frames ritrasmessi.
Rejected (REJ) Error Recovery.
Recupero dell' errore di rifiuto. REJ viene usato per richiedere la
ritrasmissione di pacchetti, tipo I, a seguire un errore di sequenza nella
numerazione dei frames. Solo una condizione di REJ puo' esistere per ognuno
dei due lati, volta per volta. La condizione di REJ viene azzerata quando
viene ricevuto il pacchetto I richiesto.
Un dispositivo che riceva il comando di REJ azzerera' l' errore
ritrasmettendo il frame di tipo I indicato con N(R) nel pacchetto di REJ.
Time-out Error Recovery.
Quando un pacchetto viene "perso" durate il suo viaggio nel mezzo, sia
esso un singolo frame o l' ultimo di un gruppo, non c'e' modo di scoprire e
riparare immediatamente questo errore. Il ricevitore si accorge di mancanze
nei gruppi di dati ricevuti solo per differenze nei numeri di sequenza dei
frames che lo trasportano e vengono ricevuti correttamente. Se il frame non
ascoltato non ha frames successivi bisogna attendere il primo frame
trasmesso successivamente per avere notizia dell' errore di sequenza. Per
migliorare questa situazione il trasmettitore e' stato dotato di un timer
(contatore) che da' l' indicazione "da quanto e' stato trasmesso l' ultimo
pacchetto": T1. Viene fatto partire al momento della trasmissione di ogni
pacchetto e fermato all' arrivo dell' acknoweledge (conferma di avvenuta
ricezione) relativo a quel pacchetto. Se l' intervallo tra la trasmissione
del pacchetto e la ricezione dell' ACK supera un certo ammontare di tempo,
si ha la ritrasmissione del pacchetto che non ha ricevuto conferma (rif.
FRACK). Il timer, che si incrementa in funzione del tempo trascorso, viene
comparato con un parametro caricato a priori. Questo parametro variera' in
funzione del mezzo di trasmissione.
Quanto visto occorre solo durante la fase di trasferimento informazioni
tra un DXE e l' altro. Nella situazione di due DXE connessi, basso livello
di scambio informazioni, viene mantenuta l' integrita' del link attraverso
l' invio di pacchetti. Questa operazione si chiama polling. Il momento in
cui inviare un pacchetto avente questa funzione viene deciso dallo scadere
del timer T3. Quando T3 va' in time-out viene inviato un pacchetto RR o RNR
con il bit di poll settato, comando, e iniziata la procedura di Waiting
Ackoweledge (attesa ACK).
Rejection Error.
Errore di rifiuto. Questo tipo di errore puo' verificarsi quando un
pacchetto error-free (senza errori) ha uno dei problemi seguenti:
1> Campi di controllo o di risposta invalidi.
2> Formato del pacchetto invalido.
3> N(R) invalido, perche' non atteso di quel valore.
4) Il campo d' Informazione e' piu' lungo di quanto il device
accetti.
Quando avviene questo errore, non vengono piu' accettati pacchetti di
tipo I (salvo per l' utilizzo del bit P/F) fino a che non venga risolta la
situazione. La condizione d' errore e riportata al corrispondente
trasmettendogli un pacchetto di risposta FRMR.
Primary/Secondary versus Balanced Operation.
Comparazione tra operazioni bilanciate e non. Esistono due classi
principali di connessione a livello di link. La prima, LAP Link Access
Procedure non e' bilanciata il servizio reso considera il DCE master e il
DTE slave (DCE primario, l' altro lato DTE secondario). La seconda, LAPB
Link Access Procedure Balanced nella quale entrambi i "lati" della
connessione sono uguali per richieste di connessioni e altri comandi.
Potenzialmente esiste solo un DCE e molti DTE, ma entrambi i lati possono
scambiarsi comandi. (Semplicisticamente, due potenziali corrispondenti
possono in ogni momento connettersi e diventare alternativamente, quasi
nello stesso momento dato il simplex, inviarsi comandi e risposte ... mentre
tutti gli altri in ascolto sono solo DTE ...)
Primary/Secondary (LAP) Operation.
Operazioni di tipo primario da/a secondario.LAP e' un vecchio tipo di
procedure per il controllo di connessione, dove la maggior parte d'
intelligenza veniva supposta presente in grossi mainframe ,computer (DCE),
mentre gli utilizzatori avevano a disposizione piccole quantita' d'
intelligenza locale (DTE). Dato che il controllo di ogni network richiede
molte attivita' di mantenimento puro rispetto alla quantita' d' informazione
scambiate, era giusto far compiere la maggior parte delle operazioni di
mantenimento al piu' potente mainframe e avere giusto quel minimo di risorse
e intelligenza necessarie a sostenere in modo molto meno sofisticato il link
da parte dei terminali.
Balanced (LAPB) Operation.
LAPB e' una versione leggermente modificata di LAP. Quest' ultimo e'
stato modificato per permettere operazioni bilanciate dai due lati del link.
Nella versione ufficiale di X.25 vi e' sempre un solo DCE e potenzialmente
molti DTE ma i due operano in maniera uguale piuttosto che in modo
master/slave (primario/secondario).
LAPB viene usato per l' Amateur Radio Packet Network. Anche nel caso vi
sia un network controller (oggetto di supervisione instradamento
reindirizzamento) le procedure di link bilanciato migliorano l'
operativita'.
Connection Operation.
Pensando a un network amatoriale e' certamente la miglior soluzione
quella di avere un livello 2 in grado di esser trasferito attraverso tutti i
vari mezzi a rf a noi disponibili. Per esempio basti pensare al tipo di
collegamento piu' semplice tra due stazioni, o allo stesso ma effettuato
attraverso un network controller. Ovviamente in quest' ultimo caso il
network c. sara' da considerarsi il DCE e le due stazioni che per tramite
suo stabiliscono il link saranno considerate DTE. Quindi il device che
ricevera' la richiesta di connessione va visto in quel momento come DTE
(basso livello). Questa semplicissima regola elimina ogni ambiguita' che
altrimenti potrebbe impedire il buon funzionamento della rete stessa.
N.B.: Vi sono diverse modifiche minori riguardo a protocollo ufficiale
X.25. Queste sono state inserite solo dove era assolutamente necessario per
permetterne il funzionamento nei nostri mezzi a rf condivisi. Dato che X.25
e' stato disegnato per lavorare con un DCE che parli con piu' DTE, non
potrebbe lavorare propriamente dove si tratta invece di diversi DCE
collegati a diversi DTE sul medesimo canale.
LAPB Procedures.
Quanto segue descrive le procedure usate per il set-up, la connessione,
il mantenimento, lo scambio d' informazioni e la disconnessione di un link
bilanciato tra un DTE e DCE e viceversa. Queste procedure sono prese da X.25
salvo le necessarie modifiche.
Address Field Operation.
Modalita' d' utilizzo del campo d' indirizzamento e dei sottocampi
medesimi. Tutti i pacchetti devono contenere il campo d' indirizzamento,
costruito secondo le specifiche gia' dette. Tutti i pacchetti devono avere
in questo campo l'indirizzo di destinazione e quello del mittente, nell'
ordine come scritto. Questo permette la condivisione (sharing) del canale da
parte di piu' links. L' indirizzo di destinazione e' sempre l' indirizzo
della stazione che riceve il pacchetto, mentre l' indirizzo del mittente e'
l' indirizzo di chi trasmette il pacchetto. L' indirizzo di stazione puo'
essere di gruppo o club, se le operazioni da punto a multipunto sono
permesse. Circa l' utilizzo di indirizzi diversi dai nominativi
radioamatoriali sono in corso ulteriori studi.
Command/Response Procedure.
Procedura Comandi/Responsi. AX.25 liv. 2 versione 2.0 implementa l'
informazione di Comando/Responso nel campo d' Indirizzo. Vengono usati due
bit per mantenere la compatibilita' verso le versioni piu' basse. I due bit
sono nei sottocampi d' indirizzo mittente e destinatario, il settimo bit
dei byte A7 e A14. Un device funzionante a revisione due puo' verificare se
il corrispondente ha pure implementato il livello due tramite il controllo
dei due bit 7 del byte di SSID. Se entrambi i bit sono a zero o a uno, il
corrispondente stara' usando il vecchio protocollo. La nuova versione avra'
uno dei due bit sempre settato a uno, dipendentemente dal fatto che il frame
di comando o di risposta a un comando. La codifica e' qui di seguito
riportata.
+----------------------------------------------------------------+
! Tipo di pacchetto ! Dest. SSID C-bit ! Mitt. SSID C-bit !
+----------------------------------------------------------------+
! Versione precedente ! 0 ! 0 !
! Versione precedente ! 1 ! 1 !
! Risposta (V 2.0) ! 1 ! 0 !
! Comando (V 2.0) ! 0 ! 1 !
+----------------------------------------------------------------+
Dato che tutti i pacchetti sono da considerarsi di risposta o di comando
ogni device avra' uno dei due bit settato a uno. L' uso dell' informazione
di comando/risposta permette di usare anche i pacchetti di tipo S per
questo scopo. Mantenendo cosi' un corretto controllo del link durante la
fase di scambio informazioni.
Poll/Final (P/F) Bit Functions.
Il prossimo frame ritornato da un device che abbia ricevuto un SABM o un
comando DISC con il bit P settato a uno sara' un UA o un responso di DM con
il bit F settato sempre a 1.
Il frame ritornato in risposta a un pacchetto di tipo I con il bit P a
uno , ricevuto durante la fase di trasferimento informazioni, sara' un RR,
RNR o una risposta di REJ con il bit F settato a uno.
Lo stesso per un pacchetto di comando Supervisory, sempre inviato durante
lo scambio d' Info. frames.
Il bit P viene settato congiuntamente alla condizione di recupero del
time-out di T1.
Quando non e' usato il bit di P/F e' a zero.
LAPB Connection Establishment.
Quando un device (sia DCE che DTE) voglia stabilire una connessione con
un altro device, dovra' trasmettere un pacchetto di comando di SABM al
device voluto e far partire un contatore di time-out, T1 (time-out timer).
Se l' altro device e' presente ed e' abilitato trasmettera' a sua volta al
richiedente un pacchetto di responso UA e, nello stesso istante, rimettera'
a zero entrambe le variabili di stato interne (V(R) e V(S)). Dall' altro
lato la ricezione di un pacchetto di responso UA causera' nel device
richiedente la connessione il fermo del contatore T1 e l' azzeramento delle
stesse variabili di stato.
Se l' altro lato non risponde prima che T1 arrivi al suo valore di time-
out, il richiedente, allo scadere di T1, reinviera' un pacchetto di comando
SABM e fara' ripartire T1. Questo riprovarci nel tentativo di stabilire la
connessione continuera' fino all' esaurimento del numero di tentativi
possibili. Questo numero e' immagazzinato nella variabile N1; il valore di
N1 e' variabile in funzione della frequenza del canale di link (HF,VHF o
piu'), del tipo di operazioni a partire (terra-terra o terra-spazio; piu'
semplicemente file transfer o semplice QSO), della velocita' di
comunicazione. Questa variabile (N1) verra' vista meglio successivamente.
Information Transfer.
Trasferimento d' informazioni. Quando la connessione e' gia' stata
stabilita con le modalita' gia' prese in considerazione, entrambi i devices
sono abilitati a ricevere, trasmettere e processare pacchetti di tipo I,S o
U.
Sending of I Frames.
Trasmissione pacchetti tipo I. Quando una delle due stazioni ha delle
Informazioni da trasmettere le inserira' e le trasmettera' in pacchetti di
tipo Information con N(S), numero di sequenza all' interno del sottocampo
N(S) del campo di Controllo, pari al valore corrente della variabile di
stato V(S). Quando il pacchetto verra' trasmesso V(S) verra' incrementata di
uno.
Una qualsiasi delle due stazioni non trasmettera' piu' pacchetti di tipo
I, se la sua variabile di stato in trasmissione e' uguale all' ultimo N(R)
ricevuto dall' altro lato piu' sette (ovvero non vi possono essere piu' di
sette pacchetti mancanti di acknoweledge per parte, lungo il percorso). Se
tenta di trasmettere ancora pacchetti di tipo I la "finestra" di controllo
del flusso dati sara' superata e ne nascera' una situazione d' errore.
Se un device e' in condizione di busy (non disponibile, utilizzabile),
puo' continuare a inviare I frames all' altro device purche' questo non sia
a sua volta non disponibile per lo scambio.
Se un device e' nello stato di frame-rejection (ha inviato REJ), non
inviera' pacchetti di tipo I.
Receiving I Frames.
Se un device riceve pacchetti di tipo I validi (con FCS corretto e con il
numero di sequenza in TX uguale alla sua variabile di stato per la ricezione
presente) e non e' in condizione di non disponibilita', accettera' il
pacchetto ricevuto. Incrementera' quindi la sua variabile di stato per la
ricezione di uno, ed eseguira' una delle seguenti funzioni:
1> Se c'e' un pacchetto di tipo I da trasmettere potra' trasmetterlo con
N(R) eguale alla sua nuova V(R) dando anche l' ACK (acknoweledge).
Alternativamente , potra' trasmettere prima un pacchetto di RR con N(R)
sempre uguale a V(R), per inviare ACK, quindi trasmettere il pacchetto di
tipo I.
2> Se non vi sono frames di tipo I in attesa di esser trasmessi, il
device che ha appena ricevuto si limitera' ad inviare un frame di RR con
N(R) uguale a V(R).
Se il device non e' disponibile (si trova in stato di busy), potra'
ignorare ogni frame di tipo I ricevuta e limitarsi a riportare il suo stato
di busy.
Se esiste la condizione di device non disponibile, l' altra stazione che
ricevera' un responso in tal senso dovra' eseguire un poll (ricerca, per
cambio di stato in questo caso) verso il corrispondente, periodicamente fino
a quando lo stato della prima stazione da busy passi a ready.
La ricezione di pacchetti di tipo I con il campo informazione di
lunghezza zero verra' riportata al livello superiore senza trasferimento del
campo d' informazione.
Quando venga ricevuto un pacchetto di tipo I con FCS corretto, ma il suo
numero di sequenza in trasmissione (N(R)) non sia pari al numero di sequenza
in ricezione (V(R)) , il frame sara' scaricato e verra' inviato un
pacchetto di REJ contenente il numero di sequenza in ricezione atteso,
quello dell' ultimo frame ricevuto correttamente, piu' uno (con base 8
pero'!). Ogni frame fuori sequenza verra' trattato in questo modo. La
variabile di stato per la ricezione del corrispondente e il bit di poll,
scritti nel pacchetto fuori sequenza ricevuto, vengono esaminati prima della
cancellazione, daranno (eventualmente) luogo agli interventi previsti per l'
altro senso di comunicazione.
Receiving Ackoweledgment.
Ogni volta che vengano ricevuti pacchetti di tipo I o S correttamente,
anche se in condizioni di non disponibilita', N(R) del pacchetto ricevuto
viene controllato per verificare se contiene ACK per pacchetti , di tipo I,
gia' trasmessi e in attesa di conferma. Quindi se il pacchetto attuale
riporta ACK per pacchetti in questo stato T1 viene resettato. Se T1 viene
resettato e vi sono ancora pacchetti in attesa di conferma (oustanding sent
frames), T1 uno stesso verra' fatto ripartire . Se T1 arrivera' al time-out
verra' dato l' avvio alla procedura di ritrasmissione.
Receiving Reject.
Quando si riceva un pacchetto di REJ, la stazione trasmittente I frames a
cui si riferisce il REJ dovra' settare la sua variabile di stato per la
trasmissione con il valore riportato dal pacchetto di REJ nel suo campo di
Controllo. A questo punto il device ritrasmettera' tutti i pacchetti in
attesa al prossimo occasione disponibile conformandosi alle seguenti regole:
1> Se il device non sta' trasmettendo al momento, e il canale e' libero,
potra' iniziare la ritrasmissione immediatamente.
2> Se il device sta' operando in ambiente full-duplex (f.-d.
environment) e sta' trasmettendo pacchetti S o U, terminera' la trasmissione
di questi e poi passera' alla ritrasmissione dei pacchetti di tipo I
richiesti.
3> Se il device sta' operando in ambiente full-duplex e trasmettendo
frames di tipo I, quando ricevera' il pacchetto di REJ, abortira' il frame
corrente e iniziera' la ritrasmissione dei pacchetti di tipo I richiesti.
4> Il device potra' terminare il frame di tipo I in corso, o inviarne
anche altri della sequenza corrente a patto che non si superi la finestra di
controllo del flusso (flow control window) gia' vista, pari a massimi sette
pacchetti in attesa di ACK.
Se il device riceve il pacchetto di REJ con anche il bit di poll settato,
rispondera' con un pacchetto di RR o RNR che abbia il bit di final settato
(Poll/Final bit vedi Control Field).
Receiving an RNR Frame.
Ricezione di un pacchetto Receiver-Not-Ready. Ogni volta che viene
ricevuto un pacchetto RNR, il device potra' trasmettere o ritrasmettere
tutti i pacchetti del tipo I che abbiano il numero di sequenza in
trasmissione eguale a quello che riporta il numero di sequenza in ricezione
trasportato dal pacchetto RNR. Se il timer T1 va' in time-out dopo la
ricezione di un frame RNR, verra' eseguita una procedura di attesa conferma
(attesa dell' acknoweledgement). Il bit di poll puo' venir usato in unione
ai pacchetti di tipo S per testare lo stato della stazione non disponibile .
Nessun altro tipo di pacchetto potra' essere trasmesso se non un
Supervisory, fino al momento della ricezione di un pacchetto che indichi il
cambio stato dell' altra apparecchiatura fino ad allora busy.
Sending a Busy Indication.
Trasmissione dell' indicazione di apparecchiatura non disponibile. Ogni
volta che un device entra nella condizione di non disponibilita' (busy),
deve indicarlo al corrispondente. Lo fara' inviando un pacchetto di risposta
RNR alla prossima opportunita'. Mentre un device si trova nella condizione
di busy puo' ricevere e processare pacchetti di tipo S, se questi avranno il
bit di poll settato a uno il device rispondera' con un pacchetto di RNR e il
bit di final settato pure a uno alla prossima opportunita' possibile. Per
dimostrare di aver eliminato la condizione di busy il device dovra' inviare
un pacchetto di tipo RR o REJ riportanti il numero di sequenza in ricezione
(N(R)) eguale al valore della variabile di ricezione (V(R)) corrente. Questa
possibilita' di diversa indicazione dipende dalla buona o cattiva ricezione
dell' ultimo pacchetto.
Waiting Acknoweledgement.
Ogni apparecchiatura (device) dovra' mantenere al suo interno un
variabile di conteggio per la ritrasmissione, questa sara' posta a zero ogni
volta che venga ricevuto un ACK per un pacchetto di tipo I (anche quando si
ricevano pacchetti di tipo UA o RNR, o quando frames di tipo I o S
trasportino numeri di N(R) piu' alti dell' ultimo N(R) ricevuto, a
significare che altri pacchetti di tipo I hanno avuto ACK).
Ogni volta che il timer T1 va' in time-out, il device deve entrare in una
sequenza di recupero della condizione (recovery routine), la variabile di
conteggio delle ritrasmissioni verra' incrementata di uno e un' altra
variabile interna (X) verra' posta al valore corrente della variabile di
stato per la trasmissione.
Il device fara' quindi ripartire il timer T1, impostera' la sua variabile
di stato per la ricezione all' ultimo numero di sequenza ricevuto e
ritrasmettera' i corrispondenti pacchetti di tipo S o I con il bit di poll
settato a uno.
La condizione data dalla routine di recupero e ripartenza del timer T1
viene resettata quando il device riceve un pacchetto di tipo S valido e con
il bit di F settato a uno.
Se il device riceve un pacchetto di tipo S valido e con il bit final
settato a uno e N(R) all' interno dell' intervallo tra la variabile di stato
per la trasmissione e la variabile interna X ,caricata all' inizio della
routine di recupero per T1, la condizione viene resettata e la variabile di
stato per la trasmissione N(R) viene impostata con il valore di N(R)
ricevuto.
Se un device riceve un pacchetto del tipo visto nel paragrafo precedente
ma con il bit di final a zero, non viene inizializzato il timer T1. Il
sottocampo N(R) viene utilizzato lo stesso per reimpostare la variabile di
stato per la trasmissione. Il device potra' recuperare l' ultima frame di
tipo I (anche se questa ha gia' ricevuto ACK) impostare il bit di poll a uno
e ritrasmetterla se il timer T1 non e' andato di nuovo in time-out nel
frattempo.
Quando la variabile di conteggio delle ritrasmissioni raggiungera' il
valore N2 (Retry, numero tentativi di riesecuzione funzione), il device
iniziera' le procedure di reset del link piu' avanti descritte.
Link Disconnetting.
Durante la fase si scambio informazioni, entrambi le apparecchiature
possono iniziare la disconnessione inviando un pacchetto DISC. Il device
inviante fara' quindi partire il suo timer T1 e attendera' una risposta. Se
non arriva una risposta valida prima dello scadere di T1, verra' reinviato
DISC e T1 ripartira'. Questo sempre fino al valore di N2 volte, il device
che richiede DISC entrera' direttamente in stato di disconnessione.
Quando viene ricevuto un pacchetto DISC, il ricevente deve restituire un
pacchetto di responso UA (Unnumbered Ack.) e entrare in stato di
disconnessione.
Disconnected State.
Dopo aver trasmesso un frame DISC e ricevuto un frame UA, o inviando un
frame UA dopo aver ricevuto un frame DISC, il device entrera' nello stato di
disconnessione.
In questo stato ogni apparecchiatura puo' iniziare la procedura di
partenza del link con ogni altro device (link set-up). Puo' quindi
rispondere a un SABM e stabilire una connessione, o puo' reagire al SABM con
l' invio di un pacchetto con il responso DM.
Ogni stazione che riceva un comando di DISC mentre gia' si trova in stato
di disconnessione inviera' comunque un pacchetto di risposta DM.
Ogni device che riceva un frame di comando diverso da SABM o da UI
(Unnumbered Info.) con il bit di poll settato a uno, rispondera' con un
frame di DM con il bit di final settato a uno. Ogni altro campo sara'
ignorato.
Quando un device e' entrato nello stato di disconnessione in seguito a
una condizione d' errore interno o esterno (presumibilmente indotto dall'
altro end), lo segnalera' inviando un frame di responso DM piuttosto che un
frame di comando DISC. Verra' fatto partire T1, se andra' in time-out prima
della ricezione di un SABM o di un DISC, verra' fatto ripartire T1 e
reinviato DM. Questo sempre fino al valore di N2 ritrasmissioni, superato il
quale il device restera' in stato di disconnessione e nessun' altra azione
verra' intrapresa.
Resetting Procedure.
La procedura viene utilizzata per reinizializzare in entrambe le
direzioni di flusso dopo un errore non recuperabile. Questa procedura di
reset viene utilizzata solo durante la fase di trasferimento informazioni
del protocollo AX.25.
Un device potra' richiedere un reset inviando un pacchetto di SABM. Una
stazione che riceva un frame di SABM da un altra stazione alla quale era
connessa inviera' a sua volta un frame di UA indietro alla prima buona
occasione. Entrambi i device azzereranno le loro variabili di stato per la
ricezione e la trasmissione. Ogni condizione di busy eventualmente esistente
viene eliminata.
E' possibile iniziare la procedura di disconnect invece che quella di
reset.
Uno dei due device potra' inviare un frame di responso DM richiedendo
all' altro l' inizio della procedura di reset del link, dopo aver trasmesso
DM in device passera' in disconnect state.
Un device puo' richiedere l' inizio della procedura di reset del link
inviando un pacchetto di responso FRMR.
Dopo aver trasmesso FRMR, il device entrera' in stato di pacchetto
rifiutato (frame rejeted state). Questa condizione verra' eliminata quando
il device che ha trasmesso FRMR ricevera' un SABM o un comando DISC dall'
altro capo. Ogni altro pacchetto di comando ricevuto causera' la
ritrasmissione di FRMR con il medesimo campo d' Informazione gia' inviato.
Il device che trasmette FRMR fara' nel contempo partire il timer T1. Se
non avra' ricevuto i pacchetti gia' detti, al time-out del contatore
ritrasmettera' FRMR e fara' ripartire T1, come descritto in "Waiting
Acknoweledgement". Se FRMR verra' trasmesso N2 volte senza successo, il
device passera' il link sara' resettato.
Rejection Conditions.
Condizioni per il rifiuto di pacchetti. Un device puo' iniziare la
procedura di reset del link quando un pacchetto che sia valido come FCS e
campo d' indirizzamento ma durante lo fase di scambio pacchetti di tipo I
questo abbia uno o piu' dei seguenti problemi:
1> Il pacchetto porta un comando o un responso non conosciuto al
ricevente;
2> Il campo d' informazione e' piu' lungo di 256 bytes.
Un device iniziera' sempre la procedura di reset quando riceva responsi
di DM o FRMR durante la fase di scambio informazioni.
Un device iniziera' sempre la procedura di reset ogni volta riceva un
frame di UA o un non sollecitato pacchetto di responso con il bit di final
settato a uno.
Collision Recovery.
Recupero delle collisioni.
Collision Recovery in a Half Duplex Environment.
Recupero delle collisioni in ambiente half-duplex. Collisione di
pacchetti di ogni tipo in questo ambiente vengono gestite essenzialmente
grazie a T1 e alla variabile di ritrasmissione N2. Non vengono intraprese
altre speciali misure.
Collision in a Full Duplex Environment.
Collisioni in ambiente full-duplex. Non si tratta in realta' di vere
collisioni, ma hanno molto piu' a che fare con un device che non riesce a
seguire il ritmo di due canali realmente contemporanei.
Collision of Unnumbered Commands.
Collisioni di pacchetti di Comando non numerati. Se i comandi inviati da
entrambi i lati sono uguali, entrambi i devices invieranno un pacchetto di
UA alla prima buona occasione e sempre entrambi entreranno nello stato
indicato.
Se si tratta di comandi Unnumbered differenti inviati nel medesimo tempo,
entrambi i device entreranno nello stato di disconnessione e trasmetteranno
un pacchetto DM alla prima opportunita'.
Collision of a DM with a SABM or DISC.
Collisione di DM con SABM o DISC. In questo caso viene trasmesso da uno
dei due lati un frame, non sollecitato dall' altro, di DM. Puo' avvenire una
collisione tra il DM e un SABM o un DISC. Per prevenire la cattiva
interpretazione di un simile DM, tutti i frames di DM non trasmessi su
richiesta del corrispondente verranno spediti con il bit di final a zero.
Viceversa tutti i frames SABM o DISC avranno il bit di poll a uno, non vi
potra' quindi essere nessuna confusione tra un DM richiesto o non richiesto.
Connectionless Operation.
Operazioni in stato di disconnessione. Tra le possibilita' d' operazione
ve n'e' una che non e' veramente fattibile al livello due. Questo modo
definito "a tavola rotonda" (roundtable) implica che diversi radioamatori
siano impiegati assieme nella stessa discussione. L' unico modo per
simularlo durante una connessione e' che ognuno sia connesso a tutti i
membri del gruppo. Questo vuol dire un pacchetto separato trasmesso da
ognuno per ogni altro ogni volta che si debbano scambiare informazioni.
ovviamente non e' un sistema praticabile. La via che molti OM entusiasti del
P.R. hanno scelto per simulare questo approccio e' al difuori della
connessione in AX.25 , ma usa la costruzione del pacchetto tipica di AX.25.
Il protocollo permette dei pacchetti di tipo speciale denominati UI
(Unnumbered Information). E' auspicabile che quando si svolgono operazioni
di questo tipo tutti i corrispondenti indirizzino i loro pacchetti a un
nome-nominativo prescelto. Cosi' con i comandi di monitor sara' possibile
escludere il normale traffico.
Questa mancanza di operazioni stile roundtable e' un problema del livello
due, si suppone che il livello 3 possa risolvere piu' elegantemente il
problema. Per ora il modo indicato appare un accettabile ripiego.
Tenete ben in mente che questo modo e' in assenza di connessione, tutti i
meccanismi di recupero per i pacchetti eventualmente persi che si basano
sulla flow window sono assenti. Se un pacchetto viene perso non ne esiste
traccia in nessun luogo e perso senza speranza. Questo in particolare per
collisioni di frames UI, un pacchetto di tipo Ui che collida con un altro
pacchetto di tipo qualsiasi non e' piu' recuperabile.
List of System Defined Parameters.
Lista dei parametri di sistema definiti.
Timers
E' raccomandato l' uso di tre timer per il mantenimento dell' integrita'
di un link in AX.25.
Il primo timer , T1, viene usato per dare la sicurezza in caso di attese
per responsi a riceversi che questa non si prolunghi oltre un certo limite
di tempo dopo la trasmissione di un pacchetto. Questo timer non puo' essere
espresso in tempo assoluto, dato che il tempo necessario per trasmettere un
pacchetto vari molto in funzione della velocita' di trasmissione stessa
usata dal livello 1. T1 deve essere almeno doppio rispetto al tempo
necessario per trasmettere un frame di lunghezza massima al corrispondente
dall' altro lato del link, questo da' un certo margine, sempre al
corrispondente, per dar tempo di processare quanto eventualmente vi sia da
eseguire/decodificare prima di trasmettere una risposta.
Il secondo timer, T2, da' il ritardo tra la ricezione di un pacchetto di
tipo Information valido e la trasmissione del pacchetto di risposta
collegato. Questo ritardo puo' essere necessario per permettere al DXE
ricevente di stabilire se esistono altri pacchetti, dopo il primo appena
ricevuto. Se vengono ricevuti piu' pacchetti un DXE puo' attendere e dare
ACK complessivamente, fino a un massimo di un ACK valido per sette
pacchetti, piuttosto che ad ogni singolo frame. T2 non e' mandatorio ma la
sua implementazione e' raccomandata per migliorare l' efficenza del canale.
Resta da notare che in un canale full-duplex l' ACK non deve essere
ritardato piu' di K/2 pacchetti per avere la massima velocita' di
trasferimento.
il terzo timer, T3, viene fatto partire quando T1 non e' in uso per
essere sicuri che un pacchetto di Supervisory sia inviato periodicamente sul
link per mantenerlo quanto piu' costantemente sotto controllo (wakeup or
keep alive timer). La raccomandazione e' che ogni qualvolta non vi siano
pacchetti di tipo I o pacchetti con il bit di poll settato in attesa di ACK
(durante la fase di trasferimento d' informazioni), vengano inviati dei
pacchetti di RR o RNR con il poll bit settato a uno. Questo ad ogni scadere
di T3, il cui valore e' definito localmente. La temporizzazione di T3
dipende drammaticamente dalle diverse costanti d' uso del livello 1, per
questa ragione e' ancora soggetto ad ulteriori studi.
Maximum Numbers of Retryes N(2).
Massimo numero di tentativi per la ritrasmissione, ogni volta che T1 va'
in time-out subisce una variazione dinamica dal valore predefinito. Varia
molto in funzione delle costanti d' uso per il livello 1, tipicamente vale
16.
Maximum Number of Bytes in an I Field N(1).
Il massimo numero di bytes (octets) permesso nel campo d' Informazione e'
di 256 (0-255). Possono esserci solo campi d' informazione con numero pari
di bytes.
Maximum Number of I Frames Outstanding (K)
Il massimo numero di pacchetti in attesa di conferma e' sette. Puo'
essere ridotto in ogni momento per migliorare le caratteristiche di
particolari trasferimenti.
Released By Sergio Centroni, I1TMH @ I1TMH.
Ritorna a Software Radioamatoriale by
IW3FQG