ArNet: Difference between revisions
No edit summary |
|||
(23 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[Category:Telecom]] | |||
''protocollo per micro-reti'' | ''protocollo per micro-reti'' | ||
http://ciapini.wiki.contaminati.net/sites/ciapini/images/Decapsulation.gif | http://ciapini.wiki.contaminati.net/sites/ciapini/images/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]]. | 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]]. | ||
Line 10: | Line 12: | ||
arNet si preoccupa sempre di: | arNet si preoccupa sempre di: | ||
* [[# | * [[#Default header|framing]] | ||
* [[#Indirizzamento| | * [[#Indirizzamento|indirizzamento]] | ||
ed opzionalmente di: | ed opzionalmente di: | ||
* [[#VC Header|Virtual Circuit]] | |||
* [[#VC Header|Packet reordering]] | |||
* [[#EC Header|Error detection & control]] | |||
* controllo di flusso | |||
* routing | * routing | ||
* media access control | * media access control | ||
un ''pacchetto'' arNet e' composto da: | |||
* l'''header'', composto da uno a 16 [[#Header Block]] da 4 byte ognuno | * 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 ''payload'', zero a 256 Payload Block da 4 byte ognuno, fino ad un totale di 1024 bytes di payload | ||
Line 36: | Line 35: | ||
massimo: 4 + (2^4) * 4 + (2^10) = 1092 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 == | == Routing == | ||
Line 98: | Line 95: | ||
campi: | campi: | ||
* '''protocol''' numero di protocollo. arNet = | * '''protocol''' numero di protocollo. arNet = 0b01 | ||
* '''header_size''' numero di header che seguono il default header. | * '''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 | * '''payload_size''' dimensione del blocco dati che segue in byte, viene poi paddato fino a un multiplo di 4 | ||
* '''src''' indirizzo del mittente | * '''src''' indirizzo fisico del mittente | ||
* '''dst''' indirizzo del destinatario | * '''dst''' indirizzo fisico del destinatario | ||
=== VC Header === | === VC Header === | ||
* la tripla (src, vci, sequence) e' un id univoco del pacchetto nel canale. | * la tripla (src, vci, sequence) e' un id univoco del pacchetto nel canale. | ||
{|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) | ||
||1b () | ||1b (ACKreq) | ||
||1b () | ||1b (ACK) | ||
||10b ( | ||10b () | ||
|| | ||8b (sequence) | ||
||8b (acknowledge) | |||
|} | |} | ||
* '''htype''' tipo header 0x6 | * '''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. | * '''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. | |||
{|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) | ||
||2b ( | ||2b (algo) | ||
||1b (ARQ) | ||1b (ARQ) | ||
||1b (ACK) | ||1b (ACK) | ||
||24b ( | ||24b (value) | ||
|} | |} | ||
* '''htype''' tipo header 0x2 | * '''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. | * '''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 | * '''ACK'''' se 1, conferma la corretta ricezione dell'ultimo pacchetto | ||
* ''' | * '''value''' valore crc di tutto il blocco dati | ||
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] | |||
=== Segment Access Advertisement Header === | === Segment Access Advertisement Header === | ||
Line 278: | Line 275: | ||
* https://www.tapr.org/pdf/CNC1986-LinkLevelProtocolsRevisited-KA9Q-WB6RQN.pdf Link Level Protocols Revisited | * 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
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:
- Virtual Circuit
- Packet reordering
- Error detection & control
- controllo di flusso
- routing
- media access control
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:
- The Effectiveness of Checksums for Embedded Networks
- A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS
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:
- https://en.wikipedia.org/wiki/Time-division_multiplexing
- https://en.wikipedia.org/wiki/Time_division_multiple_access
- https://en.wikipedia.org/wiki/Dynamic_TDMA#Dynamic_TDMA
- https://en.wikipedia.org/wiki/Scheduling_algorithm
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:
- http://nms.lcs.mit.edu/papers/hbhfc-sensys04.pdf
- http://hondo.informatik.uni-freiburg.de/pubs/MANET-trade_offs.pdf
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
- 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