On Thu, Feb 3, 2011 at 9:54 PM, Guy Harris <[email protected]> wrote: > > On Feb 3, 2011, at 8:47 AM, M.Baris Demiray wrote: > >> Hello again, >> >> I have solved almost all the problems that I mentioned below and now I >> am sure that I should ask for a new DLT value for STANAG 5066 [1] MAC >> (Medium Access Control Sublayer) PDUs. Currently I am able to dissect >> these PDUs using DLT number 147 (USER0) using Wireshark 1.4.3 and I'd >> like to have this dissector and corresponding DLT value in the main >> stream. >> >> I might add that STANAG 5066 SIS layer is already defined in Wireshark >> [2] yet it can only dissect the packets transferred between STANAG >> 5066 and its clients. > > OK, that answers the questions I asked in my previous message. > >> Now, what I propose is to have the same >> functionality for the interface between STANAG 5066 and HF modem as >> well. What else should I provide regarding this protocol to ask for a >> DLT value? > > So that protocol is presumably the one mentioned in the isode.com white paper:
Correct, > At the modem level, STANAG 5066 uses packets (DPDUs) of a size > appropriate to the modem speed. At 1200 bits/second 128 bytes will be used, > which is much less than the typical Unit Data. Benefits of using smaller > DPDUs include: In fact this is not what STANAG 5066 Annex H "Implementation Guide and Notes" section suggests. According to this section and the tests held by DRA (Defence Research Agency), 1) The throughput is not strongly sensitive to frame size 2) 200 bytes is a good 'compromise' selection for frame size Besides, STANAG 5066 has the ability of doing DRC (Data Rate Change) in accordance with SNR values so what is suggested by that white paper, I think, is not applicable. > • Acknowledgement is done for each DPDU, so if data loss > occurs when transmitting a DPDU, only that DPDU (and not the whole Unit Data) > need to be retransmitted. > • When higher precedence Unit Data arrives is sent for > transmission by a STANAG 5066 server, sending can begin after transmission of > the current DPDU (i.e., there is no need to wait for the full Unit Data > transmission). > Acknowledgements, often referred to as ARQ (Acknowledgement ReQuest), are > used for Reliable Unit Data and are made for each DPDU. In order to minimize > the number of turnarounds, sending of acknowledgements is delayed. A typical > sequence with two radios might be: > > • Radio 1 transmits to Radio 2 for 127 seconds; it sends a > number of DPDUs. > • Radio 2 transmits to Radio 1 for 127 seconds; it sends > acknowledgments for the DPDUs received from Radio 1; then it sends some DPDUs. > • Radio 1 transmits to Radio 2 for 127 seconds; it sends > acknowledgements for the DPDUs received from Radio 2; then it works out which > DPDUs failed to transmit last time and resends them; then it sends more DPDUs. > > with the packets for the MAC layer being the DPDUs. Is that correct? Precisely. Yet may be a little clarification is needed. You might have noticed that in my first e-mail I mentioned about DTS (Data Transfer Sublayer) and that one of our dissector methods has the name dissect_s5066dts() but now we are talking about MAC layer and all this may look like a confusion but it is not. As explained in Isode white paper there are three versions of STANAG 5066. MAC (Medium Access Control) layer was introduced in Edition 2 (which was later renamed as Edition 3) and designated to manage HF modem interface that DTS was designated to do the same before. Thanks, > - > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. -- M. Baris Demiray - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
