Subversion Repositories fermix-firmware

Rev

Blame | Last modification | View Log | RSS feed

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0045)http://www.ir3ip.net/iw3fqg/doc/ax25l2v2i.htm -->
<HTML><HEAD><TITLE>AX.25 SPECIFICHE DEL PROTOCOLLO - LIVELLO 2</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY  bgColor=#ffffff><PRE> AX.25  SPECIFICHE DEL PROTOCOLLO - LIVELLO 2
                                             </PRE><PRE> Ricavato da:
   "AX.25 link-layer spec." de AK1A;
   "AX.25 amteur packet radio link-layer protocol" de WB4JFI.
 Traduzione di IW1AYD.
   </PRE><PRE>   AX.25 link-layer protocol.
   </PRE><PRE>   Questo   protocollo  e'  conforme  alle  raccomandazioni  ISO  3309,  4335
(includendo  DAD 1&amp;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
   </PRE><PRE>  
   Struttura del pacchetto.
   </PRE><PRE>   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).
</PRE><PRE> Primo
 bit
 trasmesso.
 +-----------------------------------------------------------------------+
 !  Flag      !   Address    !    Control    !      FCS     !    Flag    !
 +-----------------------------------------------------------------------+
 !  01111110  ! 112/560 bits !    8 bits     !    16 bit    !  01111110  !
 +-----------------------------------------------------------------------+
                        Esempio di pacchetto U o S.</PRE><PRE> +------------------------------------------------------------------------+
 !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.
</PRE><PRE>   Definizione di campo.
   </PRE><PRE>   Ogni  pacchetto e'  formato da  piu' campi. Ogni campo, field, e' composto
da gruppi di otto bit, octets o bytes, e ha specifiche funzioni.
   </PRE><PRE>  
   Flag Field.
   </PRE><PRE>   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.
   </PRE><PRE>   Address Field.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Control Field.
   </PRE><PRE>   Il  campo di  controllo viene  usato per  identificare il  tipo di frame e
altri attributi della connessione a livello 2. E' lungo un byte.
   </PRE><PRE>   Campo PID .
   </PRE><PRE>   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:
   </PRE><PRE>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.</PRE><PRE>    Dove:</PRE><PRE>    x. indica bit non importanti.
    y. indica ogni possibile combinazione.
   </PRE><PRE>  
   Information Field.
   </PRE><PRE>   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).
   </PRE><PRE>  
   Frame Check Sequence.
   </PRE><PRE>   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).
   </PRE><PRE>  
   Bit Stuffing.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Bit Order of Transmission.
   </PRE><PRE>   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.
</PRE><PRE>  
   Frame Abort.
   </PRE><PRE>   Termine  trasmissione pacchetto,  forzato. Se  un  pacchetto  deve  essere
terminato   prematuramente,  devono  essere  trasmessi  almeno  quindici  bit
consecutivi a "1", senza bit stuffing.
   </PRE><PRE>  
   Invalid Frame.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Address Field Encoding.
   </PRE><PRE>   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).
   </PRE><PRE>  
   Non-Repeater Address-Field Encoding.
   </PRE><PRE>   Codifica  del campo  indirizzo per  frame non  indirizzato  o  proveniente
tramite un ripetitore.
   </PRE><PRE>         +--------------------------------------------------------+
         !    Campo d' Indirizzo                                  !
         +--------------------------------------------------------+
         ! Indirizzo di destinazione  ! Indirizzo del mittente    !
         +--------------------------------------------------------+
         ! A1  A2  A3  A4  A5  A6  A7 ! A8 A9 A10 A11 A12 A13 A14 !
         +--------------------------------------------------------+
   </PRE><PRE>   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.
   </PRE><PRE>  
   Destination Sub-Field Encoding.
   </PRE><PRE>   Codifica  del sottocampo  di destinazione. Data l' eguaglianza di codifica
tra i due sottocampi vedremo ora quella relativa al sottoc. destinatario.
   </PRE><PRE>  
                  +-------------------------------------+
                  ! 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         !
                  +-------------------------------------+
   </PRE><PRE>   Dove:
   </PRE><PRE>   1&gt;  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.
   </PRE><PRE>   2&gt;  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.
   </PRE><PRE>   3&gt;  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.
   </PRE><PRE>   4&gt;  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.
   </PRE><PRE>   5&gt;  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.
   </PRE><PRE>  
   Level 2 Repeater Address Field Encoding.
   </PRE><PRE>   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.
   </PRE><PRE>  
                  +-------------------------------------+
                  ! 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)
   </PRE><PRE>    Dove:
   </PRE><PRE>   1&gt;  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&gt;  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.
   </PRE><PRE>    3&gt; I bit denominati R sono sempre riservati.
   </PRE><PRE>     4&gt; Il bit denominato H, vale "0" se il pacchetto non e' stato ancora
   ripetuto dal digipeater specificato e "1" viceversa.
   </PRE><PRE>  
   Control Field Format.
   </PRE><PRE>   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.
   </PRE><PRE>   Vi sono tre tipi principali di pacchetti in AX.25:</PRE><PRE>                    1) Information frame o I frame;
                    2) Supervisory frame o S frame;
                    3) Unnumbered frame o U frame .
                                      </PRE><PRE>   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:
   </PRE><PRE>                  +-------------------------------------+
                  !    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 !
                  +--------------------------------------
   </PRE><PRE>      Dove:
   </PRE><PRE>   1&gt; Il bit 0 (LSB) e' il primo trasmesso, il bit 7 e' l' ultimo.
   </PRE><PRE>   2&gt;   N(S)  e'  il  numero  progressivo  della  sequenza  di  pacchetti
   trasmessi. Il  bit 2 e' il meno significativo (LSB).
   </PRE><PRE>   3&gt;  N(R) e' il numero progressivo della sequenza di pacchetti ricevuti
   . Il bit 6 e' il meno significativo.
   </PRE><PRE>   4&gt; S sono i bit usati in modo Supervisor.
   </PRE><PRE>   5&gt; M sono i bit usati in modo Unnumbered.
   </PRE><PRE>   6&gt;  Il bit  P/F e' il sottocampo di Poll/Final. La sua funzione verra'
   descritta piu' avanti.
   </PRE><PRE>  
   Control Field Definitions.
   </PRE><PRE>   Definizioni del campo di controllo.
   </PRE><PRE>  
      Information Frame Control Field
   </PRE><PRE>   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.
   </PRE><PRE>       Supervisory Frame Control Field.
   </PRE><PRE>   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.
   </PRE><PRE>      Unnumbered Frame Control Field.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Control Field Parameters.
   </PRE><PRE>   Parametri del campo di controllo.
   </PRE><PRE>  
         Sequence Numbers and Variables
   </PRE><PRE>   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.
   </PRE><PRE>         Send State Variable V(S).
   </PRE><PRE>   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.
   </PRE><PRE>  
         Send Sequence Number N(S)
   </PRE><PRE>   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).
   </PRE><PRE>  
         Receive Status Variable V(R)
   </PRE><PRE>   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.
   </PRE><PRE>  
         Received Sequence Number N(R)
   </PRE><PRE>   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.
   </PRE><PRE>  
         Poll/Final (P/F) Bit
   </PRE><PRE>   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.
   </PRE><PRE>  
   Control Field Encoding.
   </PRE><PRE>   Codifica del campo di controllo.
   </PRE><PRE>  
      Information Frame Control Field
   </PRE><PRE>   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.
   </PRE><PRE>                             Control Field Bits
                         +-----------------------+
                         ! 7 6 5 ! 4 ! 3 2 1 ! 0 !
                         +-------+---+-------+---+
                         !  N(R) !P/F!  N(S) ! 0 !
                         +-----------------------+
   </PRE><PRE>  
      Supervisory Frame Control Field
   </PRE><PRE>   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.
   </PRE><PRE>                  +-------------------------------------+
                  !             ! 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 !
                  +-------------------------------------+
   </PRE><PRE>  
         Receive Ready (RR) Response
   </PRE><PRE>   Letteralmente: pronto alla ricezione. Viene usato per i seguenti scopi:
   </PRE><PRE>   1&gt;  Per indicare  che chi  trasmette RR e' pronto a ricevere pacchetti
   di tipo I;</PRE><PRE>   2&gt;  Per inviare  ACK (ackoweledge, letteralmente accordo) ai pacchetti
   di tipo I fin' ora ricevuti, includendo il frame N(R)-1;
   </PRE><PRE>   3&gt;  Per ridare  il via dopo una condizione di RNR allo scambio di dati
   precedentemente bloccato.
   </PRE><PRE>   Occorre  far notare  come lo  stato dell'  altro componente  terminale del
link possa essere richiesto settando il bit di poll del sottocampo P/F.
   </PRE><PRE>  
         Receive Not Ready (RNR) Response
   </PRE><PRE>   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.
   </PRE><PRE>  
         Reject (REJ) Response.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   Come  per le  altre risposte  di supervisione  il bit  di P/F  puo' essere
usato nel pacchetto di REJ.
   </PRE><PRE>  
      Unnumbered Type Frame.
   </PRE><PRE>   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).
   </PRE><PRE>   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.
   </PRE><PRE>   Tipologia dei pacchetti UI.
   </PRE><PRE>                  +-------------------------------------+
                  !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    !    !                    !
                  +-------------------------------------+</PRE><PRE>   Tipi di campi di controllo per i pacchetti U.
   </PRE><PRE>  
   Set Asynchronous Balanced Mode (SABM) Command.
   </PRE><PRE>   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).
   </PRE><PRE>  
   Disconnect (DISC) Command.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Disconnected mode (DM) Response.
   </PRE><PRE>   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".
   </PRE><PRE>  
   Unnumbered Acknoweledge (UA) Response.</PRE><PRE>   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.
   </PRE><PRE>  
   Frame Reject (FRMR) Response.
   </PRE><PRE>   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:
   </PRE><PRE>   1&gt;   La  ricezione   di  un   pacchetto  con   campi  invalidi  o  con
   comandi/responsi non implementati.
   2&gt;  La ricezione  di pacchetto  d' informazione con un campo dati piu'
   lungo del dovuto.
   3&gt;  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&gt;  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.
   </PRE><PRE>   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:
   </PRE><PRE>  
            +-------------------------------------------------+
            !         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  !
            +-------------------------------------------------+
   </PRE><PRE>   FRMR Frame Information Field.
   </PRE><PRE>   Dove:
   1&gt;  Il campo  di controllo  del frame rifiutato e' tolto pari pari dal
   pacchetto che ha provocato l' inizio della sequenza e qui inserito.
   2&gt;   V(S)  e'  la  variabile  di  sequenza  per  la  trasmissione  del
   dispositivo che invia FRMR, il bit 10 e' il LSB.
   3&gt;  V(R) e'  la variabile di sequenza per la ricezione del dispositivo
   che invia FRMR, il bit 14 e' il MSB.
   4&gt;  Se W  e' alto,  "1", il campo di controllo ricevuto era invalido o
   non implementato.
   5&gt;  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&gt;  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&gt;  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&gt;  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.
   </PRE><PRE>  
   Unnumbered Information (UI) Frame.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Link Error Recovery.
   </PRE><PRE>   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.
   </PRE><PRE>    Invalid Frame or FCS Error.
   </PRE><PRE>   Se  viene ricevuto  un pacchetto invalido  o con FCS invalido (Frame Check
Sequence),  viene "scaricata"  (non visualizzata) e nessun altra azione viene
intrapresa.
   </PRE><PRE>    Device Busy Condition.
   </PRE><PRE>   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.
   </PRE><PRE>    Send Sequence Number Error.
   </PRE><PRE>   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.
   </PRE><PRE>  
    Rejected (REJ) Error Recovery.
   </PRE><PRE>   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.
   </PRE><PRE>  
   </PRE><PRE>  
   Time-out Error Recovery.
   </PRE><PRE>   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).
   </PRE><PRE>  
    Rejection Error.
   </PRE><PRE>   Errore  di rifiuto.  Questo tipo  di errore  puo'  verificarsi  quando  un
pacchetto error-free (senza errori) ha uno dei problemi seguenti:
   1&gt; Campi di controllo o di risposta invalidi.
   2&gt; Formato del pacchetto invalido.
   3&gt; N(R) invalido, perche' non atteso di quel valore.
   4)  Il campo  d' Informazione  e'  piu'  lungo  di  quanto  il  device
   accetti.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Primary/Secondary versus Balanced Operation.
   </PRE><PRE>   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 ...)
   </PRE><PRE>    Primary/Secondary (LAP) Operation.
   </PRE><PRE>   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.
   </PRE><PRE>    Balanced (LAPB) Operation.
   </PRE><PRE>   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'.
   </PRE><PRE>  
   Connection Operation.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   LAPB Procedures.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Address Field Operation.</PRE><PRE>   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.
   </PRE><PRE>  
   Command/Response Procedure.
   </PRE><PRE>   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.
   </PRE><PRE>    +----------------------------------------------------------------+
    ! 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         !
    +----------------------------------------------------------------+
   </PRE><PRE>   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.
   </PRE><PRE>  
   Poll/Final (P/F) Bit Functions.
   </PRE><PRE>   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.
   </PRE><PRE>  
   LAPB Connection Establishment.</PRE><PRE>   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.
   </PRE><PRE>  
       Information Transfer.
   </PRE><PRE>     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.
   </PRE><PRE>  
       Sending of I Frames.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   Se  un device  e' nello  stato di  frame-rejection (ha  inviato REJ),  non
inviera' pacchetti di tipo I.
   </PRE><PRE>  
   Receiving I Frames.
   </PRE><PRE>   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&gt;  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&gt;  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).
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Receiving Ackoweledgment.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Receiving Reject.
   </PRE><PRE>   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&gt; Se il device non sta' trasmettendo al momento, e il canale e' libero,
potra' iniziare la ritrasmissione immediatamente.
      2&gt;  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&gt; 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&gt; 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.
   </PRE><PRE>   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).
   </PRE><PRE>  
   Receiving an RNR Frame.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Sending a Busy Indication.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Waiting Acknoweledgement.
   </PRE><PRE>   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).
   </PRE><PRE>   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.
   </PRE><PRE>   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.</PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Link Disconnetting.
   </PRE><PRE>   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.
   </PRE><PRE>   Quando  viene ricevuto  un pacchetto DISC, il ricevente deve restituire un
pacchetto   di  responso   UA  (Unnumbered   Ack.)  e  entrare  in  stato  di
disconnessione.
   </PRE><PRE>  
   Disconnected State.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   Ogni  stazione che riceva un comando di DISC mentre gia' si trova in stato
di disconnessione inviera' comunque un pacchetto di risposta DM.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Resetting Procedure.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   E'  possibile iniziare  la procedura  di disconnect  invece che  quella di
reset.
   </PRE><PRE>   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.
   </PRE><PRE>   Un  device puo'  richiedere l'  inizio della  procedura di  reset del link
inviando un pacchetto di responso FRMR.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Rejection Conditions.
   </PRE><PRE>   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:
   </PRE><PRE>   1&gt;  Il pacchetto  porta un  comando o  un responso  non conosciuto  al
   ricevente;
   2&gt; Il campo d' informazione e' piu' lungo di 256 bytes.
   </PRE><PRE>   Un  device iniziera'  sempre la  procedura di reset quando riceva responsi
di DM o FRMR durante la fase di scambio informazioni.
   </PRE><PRE>   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.</PRE><PRE>  
   </PRE><PRE>   Collision Recovery.
   </PRE><PRE>   Recupero delle collisioni.
   </PRE><PRE>       Collision Recovery in a Half Duplex Environment.
   </PRE><PRE>   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.
   </PRE><PRE>  
       Collision in a Full Duplex Environment.
   </PRE><PRE>   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.
   </PRE><PRE>  
       Collision of Unnumbered Commands.
   </PRE><PRE>   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'.
   </PRE><PRE>  
       Collision of a DM with a SABM or DISC.
   </PRE><PRE>   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.
   </PRE><PRE>  
   Connectionless Operation.
   </PRE><PRE>   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.</PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   List of System Defined Parameters.
   </PRE><PRE>   Lista dei parametri di sistema definiti.
   </PRE><PRE>         Timers
   </PRE><PRE>   E'  raccomandato l'  uso di tre timer per il mantenimento dell' integrita'
di un link in AX.25.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>   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.
   </PRE><PRE>  
   </PRE><PRE>    Maximum Numbers of Retryes N(2).
   </PRE><PRE>   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.
   </PRE><PRE>  
    Maximum Number of Bytes in an I Field N(1).
   </PRE><PRE>   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.
   </PRE><PRE>  
    Maximum Number of I Frames Outstanding (K)
   </PRE><PRE>   Il  massimo numero  di pacchetti  in attesa  di conferma  e'  sette.  Puo'
essere   ridotto  in  ogni  momento  per  migliorare  le  caratteristiche  di
particolari trasferimenti.
   </PRE><PRE>   Released By Sergio Centroni, I1TMH @ I1TMH.  
   
</PRE>
<P><A href="http://www.ir3ip.net/iw3fqg/index.html">Ritorna a Software
Radioamatoriale by IW3FQG</A></P><!-- START RedMeasure V4 - Java v1.1  Revision: 1.8 -->
<!-- COPYRIGHT 2000 Red Sheriff Limited -->

<!-- START check_rs_frame -->
<SCRIPT LANGUAGE="Javascript">
<!--
check_rs_frame=1;
//-->
</SCRIPT>

<SCRIPT LANGUAGE="Javascript" SRC="/redSheriff/multiframe.js">
</SCRIPT>
<!-- END check_rs_frame -->

<script language="JavaScript">
<!--
var pCid="it_matrix-it_xoompay";
var w0=1;
var refR=escape(document.referrer);
if (refR.length>=252) refR=refR.substring(0,252)+"...";
//-->
</script>

<script language="JavaScript1.1">
<!--
var w0=0;
//-->
</script>

<script language="JavaScript1.1">
<!--
if (check_rs_frame)
{
       document.write("<script language='JavaScript1.1' src='http://server-it.imrworldwide.com/a1.js'><\/script>");
}
//-->
</script>

<script language="JavaScript">
<!--
if(w0 && check_rs_frame){
var imgN='<img src="http://server-it.imrworldwide.com/cgi-bin/count?ref='+
           refR+'&cid='+pCid+'" width=1 height=1>';
if(navigator.userAgent.indexOf('Mac')!=-1){document.write(imgN);
}else{
           document.write('<applet code="Measure.class" '+
           'codebase="http://server-it.imrworldwide.com/"'+'width=1 height=2>'+
           '<param name="ref" value="'+refR+'">'+'<param name="cid" value="'+pCid+
           '"><textflow>'+imgN+'</textflow></applet>');
           }
}
document.write("<COMMENT>");
//-->
</script>

<noscript>
<img src="http://server-it.imrworldwide.com/cgi-bin/count?cid=it_matrix-it_xoompay" width=1 height=1>
</noscript>
</COMMENT>

<!-- END RedMeasure V4 -->

</BODY></HTML>