ArNet: Difference between revisions

From ciapini
Jump to navigation Jump to search
No edit summary
No edit summary
 
(194 intermediate revisions by 2 users not shown)
Line 1: Line 1:
e' un protocollo per lo scambio di piccoli blocchi di dati (da 16 a 1024 byte) tra piccoli gruppi di nodi (massimo 256), connessi da un mezzo fisico comune.
[[Category:Telecom]]
''protocollo per micro-reti''


== Livello fisico ==
http://ciapini.wiki.contaminati.net/sites/ciapini/images/Decapsulation.gif


=== Caratteristiche del mezzo trasmissivo ===
http://nebbia.esiliati.org/repos/cesco/armando/armando.X/net/arnet/


* condiviso tra i nodi
Un protocollo che implementa i livelli '''datalink''' (ISO/OSI 2), '''rete''' (ISO/OSI 3) e '''trasporto''' (ISO/OSI 4) per lo scambio di piccoli blocchi di dati (da 0 a 1024 byte) tra piccoli gruppi di nodi (fino a 254), connessi da un mezzo fisico trasmissivo condiviso. E' pensato per essere appggiato su [[arPhy]].
* half-duplex
* senza meccanismi di collision detect
* con rilevazione di canale occupato (opzionale)
* in condizioni di terminale nascosto


=== Modulazione ===
Diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.


usa schemi di modulazione ask, psk o fsk, con costellazioni di dimensione da 2 a 32.
arNet si preoccupa sempre di:


== Livello datalink + rete + trasporto ==
* [[#Default header|framing]]
* [[#Indirizzamento|indirizzamento]]


diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.
ed opzionalmente di:


arNet si preoccupa SOLO (e non sempre) di: addressing, routing, error detecting, error handling, ordering, media access control
* [[#VC Header|Virtual Circuit]]
* [[#VC Header|Packet reordering]]
* [[#EC Header|Error detection & control]]
* controllo di flusso
* routing
* media access control


altre features vanno implementate altrove: datagram/virtual circuit transport, crittografia...


i nodi possono essere terminali o router
un ''pacchetto'' arNet e' composto da:
* l'''header'', composto da uno a 16 [[#Header Block]] da 4 byte ognuno
* il ''payload'', zero a 256 Payload Block da 4 byte ognuno, fino ad un totale di 1024 bytes di payload


il routing si basa su due livelli di indirizzo:
la lunghezza dell'intero messaggio e' pari a 4 + (header_size * 4) + payload_size bytes
* un ''indirizzo del terminale'', valido tra i terminali che condividono il canale fisico
* un ''indirizzo del segmento'', che identifica il canale fisico


minimo: 4 bytes


=== Framing ===
massimo: 4 + (2^4) * 4 + (2^10) = 1092 bytes


um messagio arNet e' composto da:
== indirizzamento fisico ==
* un [[#Blocco start]] di 8 simboli
* uno o piu [[#Blocchi header]] da 4 byte ognuno, con [[#FEC]] e [[#Interleaver]]
* zero o piu [[#Blocco DATA|blocchi dati]] da 16 byte ognuno, con [[#FEC]], [[#Interleaver]] e (opzionalmente) [[#Cifratura]]


=== Controllo di Errore ===
l'indirizzo fisico e' di 8 bit


per resistere agli errori di trasmissione, gli header e i dati passano attraverso un [[#FEC]].
il multicast e' semplicemente un indirizzo di ricezione secondario sui client


==== FEC ====
src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi


algoritmo di FEC: [[Hadamard code]]
l'indirizzo 0 e' broadcast.


la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).
== Routing ==
== Virtual circuit ==


anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione.
arNet definisce un virtual circuit tra due nodi mediante un VCI di 16 bit.
un circuito e' un canale virtuale half duplex indicato dalla tripla src/dst/vci.


se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.
l'instaurazione del circuito puo avvenire con un handshake a 1 o 3 vie.


questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole.
== Packet reordering ==


d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (''n'' = 128bit, se si usano input ''k'' di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma:
* SequenceNumber (24bit) numero di sequenza dei data blocks del payload
# crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco.
# dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard.


alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per ''k'' maggiore di 7 [http://www.math.unl.edu/~djaffe2/papers/sevens.html].
== Accesso multiplo al mezzo condiviso ==


la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi:
La mancanza di controllo di collisione e la scarsa larghezza di banda per i quali e' progettato arNet impongono uno schema di accesso al mezzo che minimizzi le collisioni e le ritrasmissioni.
# 2^(8-1) * 16 = 2048 bit nel caso di FEC con input a 8 bit.
# (2 * 2^(4-1)) * 16 = 256 bit nel caso di FEC con input a 4 bit (ogni carattere 2 input).  


prendendo il secondo caso, con un alfabeto di 16 toni per simbolo, quindi 4 bit, la latenza sarebbe di 64 simboli, che a 32 simboli per secondo farebbe 2 secondi per 16 caratteri.
ci sono due scenari:


la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile, vedi interleaving.
=== Reservation mode ===


letture:
richiede la presenza di un router sul canale, e organizza una multiplazione deterministica a divisione di tempo e - se disponibile - divisione di frequenza (canale).


* http://www.ece.ualberta.ca/~hcdc/Library/ErrorContrClass/DecodingBasic.pdf
* [[#Slot_Reservation_Request_Header]]
* https://en.wikipedia.org/wiki/FX.25_Forward_Error_Correction
* [[#Slot_Reservation_Reply_Header]]


=== Contention mode ===


ognuno fa come cazzo gli pare


==== Interleaver ====
== Header Block ==


i possibili problemi 'descrivibili' del path di trasmissione sono:
sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di zero o piu blocchi dati.


problemi di spettro:
il primo blocco e' chiamato '''default header''' ed e' sempre presente.
* interferenze coerenti (toni sovrapposti a uno dei nostri bin)
* errori della risposta in frequenza (equalizzazione..)


entrambi comportano il danneggamiento sistematico di una o piu determinate lettere dell'alfabeto in ogni simbolo
I blocchi header successivi sono opzionali e sono distinguibili a seconda del '''header type'''. Puo esistere un solo header per ogni '''header type'''


problemi nella sequenza di simboli:
=== Default header ===
* disturbo impulsivo prolungato su tutto lo spettro
* disturbo impulsivo ciclico su tutto lo spettro


che comportano la perdita di piu simboli contigui o la perdita sistematica di un determinato simbolo.
E' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale. Dev'essere implementato su ogni nodo.


per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza/fase.
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||2b (protocol)
||4b (header_size)
||10b (payload_size)
|style="color:blue"|8b (src)
|style="color:blue"|8b (dst)
|}


prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri.
campi:
* '''protocol''' numero di protocollo. arNet = 0b01
* '''header_size''' numero di header che seguono il '''default header'''.
* '''payload_size''' dimensione del blocco dati che segue in byte, viene poi paddato fino a un multiplo di 4
* '''src''' indirizzo fisico del mittente
* '''dst''' indirizzo fisico del destinatario


con un hadamard code, si possono correggere fino ad 1/4 dei bit del codice.
=== VC Header ===


prendiamo come casi peggiori possibili
* la tripla (src, vci, sequence) e' un id univoco del pacchetto nel canale.
* la perdita sistematica di 1 bit del simbolo
* la perdita di un intero sottoblocco


questo significa che in ogni sottoblocco si possono danneggiare (non contemporaneamente) fino a:
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
* 4 simboli
||4b (htype)
* 4 toni ?
||1b (ACKreq)
||1b (ACK)
||10b ()
||8b (sequence)
||8b (acknowledge)
|}


il sistema piu rudimentale e' l'interleaving elicoidale, ad esempio una rotazione nel senso della sequenza combinata con una rotazione nel senso del simbolo.
* '''htype''' tipo header 0x6
l'incremento sarebbe di un bit/simbolo in senso verticale e di un sottoblocco + un simbolo in senso orizzontale
* '''ACKreq''' il mittente attende un ACK per eliminare dal buffer il pacchetto
 
* '''ACK''' conferma ricezione pacchetto
<source lang="C">
* '''sequence''' numero di sequenza del pacchetto. puo incrementare oppure tornare a zero.
uint8_t InterleaveBlock(uint8_t *InData, int16_t *DataMatrix, uint8_t *ModulationSymbolsBuffer){
* '''acknowledge''' conferma della sequenza mittente
  uint8_t BitPos, SymbolOffset, BitOffset;
  for (uint8_t FECBlock = 0; FECBlock < HadamardCodesPerInterleaverBlock; FECBlock++){
      BlockEncodeChar(DataMatrix, InData[FECBlock]);
      for (uint8_t FECBit = 0; FECBit < HadamardCodeSize; FECBit++){
BitPos = (FECBlock * HadamardCodeSize) + FECBit;
BitOffset = BitPos % BitsPerModulationSymbol;
SymbolOffset = ((FECBit * HadamardCodeSize) + FECBlock) % SymbolsPerInterleaverBlock;
ModulationSymbolsBuffer[SymbolOffset] |= (DataMatrix[FECBit] & 0b1) << BitOffset;
// printf("%u,%u,%u\n", SymbolOffset, BitOffset, BitPos);
      }
//      printf("\n in FEC: ");
//      printbuf(DataMatrix, HadamardCodeSize, 8);
  }
}
</source>
 
che produce una disposizione [http://ciapini.contaminati.net/wiki/images/Interleaver8.png], dove il colore e' l'ordine dei bit in ingresso (dal blu al rosso), la x e' il tempo e la y il simbolo in uscita
 
 
 
==== Soft-Decision ====
 
nella catena di demodulazione si possono ottenere diversi indici di affidabilita
* rapporto tra il tono di picco e la media degli altri toni
* valore del picco carattere nella trasformata di hadamard
 
una cosa MOLTO carina da fare (dato che siamo in uno dei pochi casi in cui le risorse di calcolo sono ben piu grandi della banda) e' avere una qualche strategia di soft-decision pilotata dai valori in uscita dalla fft, magari triggerata da differenze tra l'energia nei bin inferiori a una data soglia.
 
 
 
=== Controllo di Flusso ===


=== EC Header ===


 
conferma che il messaggio e' stato trasportato senza essere danneggiato. se c'e' pericolo di perdita integrale del pacchetto, conviene usarlo assieme ad un header VC.
 
== Cifratura ==
 
algoritmo di cifratura: AES-256 (blocco 128 bit, chiave 256 bit)
 
la chiave e' composta di 64 caratteri esadecimali
 
il blocco crittato e' sempre di 16byte
 
*http://www.literatecode.com/aes256 sembra ok, volendo si puo ottimizzare qualcosa per i 16bit
*http://libtom.org/?page=features&newsitems=5&whatfile=crypt se non e' troppo grosso, e' il piu portabile
*http://gladman.plushost.co.uk/oldsite/AES/
*http://axtls.sourceforge.net/
*http://www.matrixssl.org/
*http://polarssl.org/
*http://www.yassl.com/yaSSL/Products-cyassl.html
 
 
==== Blocco start ====
 
indica l'inizio di una trasmissione. precede sempre un blocco HEADER.
 
questo riferimento deve avere autocorrelazione tendente a zero, essere abbastanza lungo (raro) da evitare false partenze, abbastanza corto da non creare overhead. viene usato per la sincronizzazione di simbolo e per l'equalizzazione.
 
lunghezza 8 simboli. 4 simboli alla frequenza/fase base e 4 all'estremo opposto della costellazione di simboli (frequenza massima/fase +180).
 
letture:
* http://www.ece.ualberta.ca/~hcdc/Library/NagKhaSchBur06.pdf
* http://www.argreenhouse.com/society/TaCom/papers99/32_5.pdf
* https://en.wikipedia.org/wiki/Gold_code
 
 
 
==== Blocchi header ====
 
sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di zero o piu blocchi dati.
 
il primo blocco e' chiamato '''default header''' ed e' sempre presente.
 
i blocchi header successivi sono indicati dall' '''header type'''
 
i blocchi header subiscono tutti block-coding -> interleaving
 
la lunghezza dell'intero messaggio sara sempre 4 + (hnum * 4) + (siz * 16) bytes
 
 
 
===== Default header =====
 
e' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale e dell'ordinamento dei pacchetti
 
dev'essere implementato su ogni nodo


{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
|style="color:blue"|8b (src)
||4b (htype)
|style="color:blue"|8b (dst)
||2b (algo)
||3b (hnum)
||1b (ARQ)
||5b (siz)
||1b (ACK)
||8b (cnt)
||24b (value)
|}
|}


campi:
* '''htype''' tipo header 0x2
* '''hnum''' numero di header da 4 byte che seguono il default header.
* '''algo''' algoritmo (00 = CRC-24 di OpenPGP)
* '''siz''' dimensione del blocco dati che segue in multipli di 16byte
* '''ARQ''' se 1, abilitita la modalita' ARQ stop-and-wait: il nodo mittente manda il pacchetto seguente solo dopo la conferma con un ACK da parte del destinatario.
* '''src''' indirizzo del mittente
* '''ACK'''' se 1, conferma la corretta ricezione dell'ultimo pacchetto
* '''dst''' indirizzo del destinatario
* '''value''' valore crc di tutto il blocco dati
* '''cnt''' contatore incrementale dei pacchetti inviati dal nodo con tupla (src,dst). un salto nella numerazione implica perdita pacchetti.


il multicast e' semplicemente un indirizzo di ricezione secondario sui client
letture:
* [http://www.ece.cmu.edu/~koopman/thesis/maxino_ms.pdf The Effectiveness of Checksums for Embedded Networks]
* [http://www.zlib.net/crc_v3.txt A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS]


src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi
=== Segment Access Advertisement Header ===
 
l'indirizzo 0 e' broadcast.
 
===== Segment Access Advertisement Header =====


il pacchetto viene mandato esclusivamente dai router per istruire i nodi che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale
il pacchetto viene mandato esclusivamente dai router per istruire i nodi che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale


il routing e' un instradamento tra segmenti diversi. ogni segmento ha un indirizzo.
il routing e' un instradamento tra segmenti diversi. ogni segmento ha un indirizzo e un livello.
 
un indirizzo globale e' composto dall' ''indirizzo del segmento'' concatenato coll' ''indirizzo del nodo''


tutti i nodi che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni.
tutti i nodi che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni.
Line 234: Line 156:
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (htype)
||8b (tframe)
||8b (segaddr)
||8b (segaddr)
||8b (chanload)
||8b (timeframe)
||4b (congclient)
||8b (beacon_period)
||4b (reserved_window)
|}
|}


* '''htype''' tipo header 0x1
* '''htype''' tipo header 0x1
* '''tframe''' dimensione timeframe del segmento in multipli di 100msec. il prossimo SAAH verra spedito dopo questo periodo.  
* '''timeframe_size''' dimensione timeframe del segmento in multipli di 16byte trasmessi al bitrate corrente.  
* '''beacon_period''' il prossimo SAAH verra spedito dopo questo periodo misurato in timeframe_size, non necessariamente dallo stesso router.  
* '''segaddr''' indirizzo del segmento di rete
* '''segaddr''' indirizzo del segmento di rete
* '''chanload''' numero di client attivi sul canale
* '''reserved_window''' l'offset del primo slot libero sul canale di default. i client che non hanno prenotato uno slot attenderanno almeno reserved_window*timeframe prima di trasmettere.
* '''congclient''' numero di client che hanno comunicato congestione in output. i client senza congestione in output attenderanno almeno tframe*(congclient/chanload) prima di inviare.


il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router
il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router
Line 255: Line 177:
* https://en.wikipedia.org/wiki/Scheduling_algorithm
* https://en.wikipedia.org/wiki/Scheduling_algorithm


===== Global Routing Advertisement Header =====
=== Global Routed Transport Header ===


il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete
viene usato dai nodi per mandare dati in maniera routed (ossia tra nodi che stanno su un segmento potenzialmente diverso).  
 
===== Global Routed Transport Header =====
 
viene usato dai nodi per mandare dati in maniera routed (di solito a nodi che stanno su un segmento (canale) diverso da quello corrente).  


{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (htype)
|style="color:blue"|4b (ttl)
|style="color:blue"|4b (ttl)
||1b (fecn)
||2b (seglevel)
||1b (becn)
||
||8b (segsrc)
||8b (segsrc)
||8b (segdst)
||8b (segdst)
Line 274: Line 192:
* '''htype''' tipo header 0x2
* '''htype''' tipo header 0x2
* '''ttl''' numero di hop massimi di routing. viene decrementato ad ogni hop.
* '''ttl''' numero di hop massimi di routing. viene decrementato ad ogni hop.
* '''fecn''' forward congestion notification. il nodo ha la coda di output piena e ha bisogno di trasmettere prima possibile. 0 normale, 1 congestionato.
* '''seglevel''' livello gerarchico del segmento.
* '''becn''' backward congestion notification. il nodo ha la coda di input piena e chiede che gli si mandino i dati piu tardi possibile. 0 normale, 1 congestionato.
* '''segsrc''' id del segmento di rete del mittente.  
* '''segsrc''' id del segmento di rete del mittente.  
* '''segdst''' id del segmento di rete del destinatario.  
* '''segdst''' id del segmento di rete del destinatario.  
se segsrc e segdst sono entrambi uguali al segaddr, allora il router funge da repeater


* i client ignorano i messaggi con segaddr diverso dal proprio
* i client ignorano i messaggi con segaddr diverso dal proprio
Line 288: Line 203:
* http://hondo.informatik.uni-freiburg.de/pubs/MANET-trade_offs.pdf
* http://hondo.informatik.uni-freiburg.de/pubs/MANET-trade_offs.pdf


===== CRC header =====
=== Slot Reservation Request Header ===
 
per avere conferma che il messaggio e' stato trasportato senza essere danneggiato


{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (htype)
||4b (crctype)
||5b (queue_size)
||24b (crc)
||2b (fecn)
||2b (becn)
||1b (slotresreq)
||1b (repeatreq)
|}
|}


* '''htype''' tipo header 0x3
Request-To-Send (RTS), richiesta di prenotazione slot.
* '''crctype''' tipo crc (0x0000 = CRC-24 di OpenPGP)
* '''crc''' valore crc di TUTTO il blocco dati
 


* queue_size
* '''fecn''' forward congestion notification. il nodo ha la coda di output piena e ha bisogno di trasmettere prima possibile. da 00 normale a 11 congestionato.
* '''becn''' backward congestion notification. il nodo ha la coda di input piena e chiede che gli si mandino i dati piu tardi possibile. da 00 normale a 11 congestionato.
* '''slotresreq''' prenotazione di slot tempo/canale. il nodo non trasmette dati e fanno fede per la prenotazione i valori del suo default header.
* '''repeatreq''' richiesta di ripetizione del pacchetto da parte del router.


===== Transport Reliability header =====
=== Slot Reservation Reply Header ===
 
quando il FEC non basta...


{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (htype)
||4b (arqtype)
||8b (src)
||8b (cnt)
||8b (dst)
||2b (channel)
||5b (timeframe_offset)
||5b (window_size)
|}
|}
Il router risponde alle prenotazioni di slot tempo/canale con questo header.


* '''htype''' tipo header 0x4
* '''htype''' tipo header 0x4
* '''arqtype''' schema arq: 0x0 = "Stop-and-wait ARQ", 0x1 = "Go-Back-N ARQ", 0x2 = "Selective Repeat ARQ"
* '''src''' nodo che deve trasmettere
* '''arqaction''' arq action (ack, nack, retransmit)
* '''dst''' nodo che deve ricevere
* '''arqvalue''' arq value (cnt, back)
* '''channel''' canale sul quale si devono collocare i due nodi
 
* '''timeframe_offset''' momento nel quale va avviata la transazione in tempo*bloccodati
letture:
* '''window_size''' durata massima della transazione in blocchi dati
 
http://www.isode.com/whitepapers/stanag-5066.html


===== Timing Header =====
=== Timing Header ===


{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
Line 331: Line 250:
|}
|}


* '''htype''' tipo header 0x5
* '''htype''' tipo header 0x8
* '''date''' days from epoch
* '''date''' days from epoch
* '''time''' seconds of day
* '''time''' seconds of day


===== Media Access Control =====
=== Global Routing Advertisement Header ===
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
|}
 
* '''htype''' tipo header 0x6


==== Blocco DATA ====
TODO il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete


sempre 16 bytes di dati netti
== Letture ==
 
subisce: ''cifratura -> block-coding -> interleaving''
 
letture:


https://en.wikipedia.org/wiki/Communications_protocol
* http://www.cc.gatech.edu/~sakhshab/evoarch.pdf
* https://savannah.nongnu.org/projects/lwip/
* https://en.wikipedia.org/wiki/UIP_%28micro_IP%29
* http://www.canfestival.org/
* http://sourceforge.net/projects/opensourcehdlc/
* https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
* http://www.isode.com/whitepapers/stanag-5066.html
* http://www.isode.com/whitepapers/messaging-protocols-for-hf-radio.html
* http://wireless.nmsu.edu/hf/papers/ies02.pdf
* https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1605761
* http://stackoverflow.com/questions/321423/parsing-binary-data-in-c
* http://www.pouzinsociety.org/images/PSOC-MovingBeyondTCP.pdf
* http://repository.wit.ie/1489/1/2010_MobiOpp_jronan_kwalsh_final.pdf
* https://www.tapr.org/pdf/CNC1986-LinkLevelProtocolsRevisited-KA9Q-WB6RQN.pdf Link Level Protocols Revisited


== CLI ==


----
[[Armando47/ArNetCLI]] e' una interfaccia testuale al protocollo arnet implementata su [[Armando47]]

Latest revision as of 18:16, 10 April 2017

protocollo per micro-reti

Decapsulation.gif

http://nebbia.esiliati.org/repos/cesco/armando/armando.X/net/arnet/

Un protocollo che implementa i livelli datalink (ISO/OSI 2), rete (ISO/OSI 3) e trasporto (ISO/OSI 4) per lo scambio di piccoli blocchi di dati (da 0 a 1024 byte) tra piccoli gruppi di nodi (fino a 254), connessi da un mezzo fisico trasmissivo condiviso. E' pensato per essere appggiato su arPhy.

Diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.

arNet si preoccupa sempre di:

ed opzionalmente di:


un pacchetto arNet e' composto da:

  • l'header, composto da uno a 16 #Header Block da 4 byte ognuno
  • il payload, zero a 256 Payload Block da 4 byte ognuno, fino ad un totale di 1024 bytes di payload

la lunghezza dell'intero messaggio e' pari a 4 + (header_size * 4) + payload_size bytes

minimo: 4 bytes

massimo: 4 + (2^4) * 4 + (2^10) = 1092 bytes

indirizzamento fisico

l'indirizzo fisico e' di 8 bit

il multicast e' semplicemente un indirizzo di ricezione secondario sui client

src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi

l'indirizzo 0 e' broadcast.

Routing

Virtual circuit

arNet definisce un virtual circuit tra due nodi mediante un VCI di 16 bit. un circuito e' un canale virtuale half duplex indicato dalla tripla src/dst/vci.

l'instaurazione del circuito puo avvenire con un handshake a 1 o 3 vie.

Packet reordering

  • SequenceNumber (24bit) numero di sequenza dei data blocks del payload

Accesso multiplo al mezzo condiviso

La mancanza di controllo di collisione e la scarsa larghezza di banda per i quali e' progettato arNet impongono uno schema di accesso al mezzo che minimizzi le collisioni e le ritrasmissioni.

ci sono due scenari:

Reservation mode

richiede la presenza di un router sul canale, e organizza una multiplazione deterministica a divisione di tempo e - se disponibile - divisione di frequenza (canale).

Contention mode

ognuno fa come cazzo gli pare

Header Block

sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di zero o piu blocchi dati.

il primo blocco e' chiamato default header ed e' sempre presente.

I blocchi header successivi sono opzionali e sono distinguibili a seconda del header type. Puo esistere un solo header per ogni header type

Default header

E' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale. Dev'essere implementato su ogni nodo.

2b (protocol) 4b (header_size) 10b (payload_size) 8b (src) 8b (dst)

campi:

  • protocol numero di protocollo. arNet = 0b01
  • header_size numero di header che seguono il default header.
  • payload_size dimensione del blocco dati che segue in byte, viene poi paddato fino a un multiplo di 4
  • src indirizzo fisico del mittente
  • dst indirizzo fisico del destinatario

VC Header

  • la tripla (src, vci, sequence) e' un id univoco del pacchetto nel canale.
4b (htype) 1b (ACKreq) 1b (ACK) 10b () 8b (sequence) 8b (acknowledge)
  • htype tipo header 0x6
  • ACKreq il mittente attende un ACK per eliminare dal buffer il pacchetto
  • ACK conferma ricezione pacchetto
  • sequence numero di sequenza del pacchetto. puo incrementare oppure tornare a zero.
  • acknowledge conferma della sequenza mittente

EC Header

conferma che il messaggio e' stato trasportato senza essere danneggiato. se c'e' pericolo di perdita integrale del pacchetto, conviene usarlo assieme ad un header VC.

4b (htype) 2b (algo) 1b (ARQ) 1b (ACK) 24b (value)
  • htype tipo header 0x2
  • algo algoritmo (00 = CRC-24 di OpenPGP)
  • ARQ se 1, abilitita la modalita' ARQ stop-and-wait: il nodo mittente manda il pacchetto seguente solo dopo la conferma con un ACK da parte del destinatario.
  • ACK' se 1, conferma la corretta ricezione dell'ultimo pacchetto
  • value valore crc di tutto il blocco dati

letture:

Segment Access Advertisement Header

il pacchetto viene mandato esclusivamente dai router per istruire i nodi che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale

il routing e' un instradamento tra segmenti diversi. ogni segmento ha un indirizzo e un livello.

tutti i nodi che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni.

i nodi fanno il possibile per non trasmettere durante la trasmissione del SAAH.

i router presenti sul segmento devono concordare sulle informazioni contenute in questo pacchetto e trasmetterlo a turno.

4b (htype) 8b (segaddr) 8b (timeframe) 8b (beacon_period) 4b (reserved_window)
  • htype tipo header 0x1
  • timeframe_size dimensione timeframe del segmento in multipli di 16byte trasmessi al bitrate corrente.
  • beacon_period il prossimo SAAH verra spedito dopo questo periodo misurato in timeframe_size, non necessariamente dallo stesso router.
  • segaddr indirizzo del segmento di rete
  • reserved_window l'offset del primo slot libero sul canale di default. i client che non hanno prenotato uno slot attenderanno almeno reserved_window*timeframe prima di trasmettere.

il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router

letture:

Global Routed Transport Header

viene usato dai nodi per mandare dati in maniera routed (ossia tra nodi che stanno su un segmento potenzialmente diverso).

4b (htype) 4b (ttl) 2b (seglevel) 8b (segsrc) 8b (segdst)
  • htype tipo header 0x2
  • ttl numero di hop massimi di routing. viene decrementato ad ogni hop.
  • seglevel livello gerarchico del segmento.
  • segsrc id del segmento di rete del mittente.
  • segdst id del segmento di rete del destinatario.
  • i client ignorano i messaggi con segaddr diverso dal proprio
  • i router invece li inoltrano

letture:

Slot Reservation Request Header

4b (htype) 5b (queue_size) 2b (fecn) 2b (becn) 1b (slotresreq) 1b (repeatreq)

Request-To-Send (RTS), richiesta di prenotazione slot.

  • queue_size
  • fecn forward congestion notification. il nodo ha la coda di output piena e ha bisogno di trasmettere prima possibile. da 00 normale a 11 congestionato.
  • becn backward congestion notification. il nodo ha la coda di input piena e chiede che gli si mandino i dati piu tardi possibile. da 00 normale a 11 congestionato.
  • slotresreq prenotazione di slot tempo/canale. il nodo non trasmette dati e fanno fede per la prenotazione i valori del suo default header.
  • repeatreq richiesta di ripetizione del pacchetto da parte del router.

Slot Reservation Reply Header

4b (htype) 8b (src) 8b (dst) 2b (channel) 5b (timeframe_offset) 5b (window_size)

Il router risponde alle prenotazioni di slot tempo/canale con questo header.

  • htype tipo header 0x4
  • src nodo che deve trasmettere
  • dst nodo che deve ricevere
  • channel canale sul quale si devono collocare i due nodi
  • timeframe_offset momento nel quale va avviata la transazione in tempo*bloccodati
  • window_size durata massima della transazione in blocchi dati

Timing Header

4b (htype) 11b (date) 17b (time)
  • htype tipo header 0x8
  • date days from epoch
  • time seconds of day

Global Routing Advertisement Header

TODO il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete

Letture

CLI

Armando47/ArNetCLI e' una interfaccia testuale al protocollo arnet implementata su Armando47

Retrieved from "http://ciapini.wiki.esiliati.org/index.php?title=ArNet&oldid=1785"