Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Ethernet Framing
#1
@pe1rxq  Please tell me more about how you take advantage of Ethernet framing with DML.

My initial thought was that you could use kernel bridging/switching, or even an actual network switch, to automatically pass packets between multiple radios.  This would work for person-to-person stream, but I suspect the vast majority of streams will be person-to-group.  Ethernet doesn't support that very well, unless you start tapping into Multicast on Ethernet.  But even then it only supports 23 bits of multicast addressing (https://networklessons.com/multicast/mul...ss-mapping) AND your endpoints would have to handle the multicast subscriptions, etc.

It's also only good for a single local broadcast domain, which doesn't lend itself well for large scale, distributed networks.  It's a layer 2 protocol, not a layer 3 protocol.  So you couldn't use the native Ethernet packet switching to, say, link your repeater, my repeater, and 75 other repeaters together without first encapsulating the Ethernet frame in an IP, and probably TCP, and probably another application on top of that, packet.

I like Ethernet as a starting point because it's pretty close to what we're doing anyway, and I'm all about borrowing from successful systems where it makes sense to.  But I'd like to understand your reasoning for sticking strictly to Ethernet frames.
73 de KR6ZY
-Mark
Reply
#2
No problem, I am happy to explain.
The DML protocol itself is indeed a TCP/IP based protocol. Various DML nodes link to each other and exchange data about the streams they have available (either themselves, or from other nodes). This is done using SHA hashes.
When a leaf node (e.g. a repeater) requests a stream from another repeater it will be done based on these hashes.
Identifying a stream for the user is done based on a domain like name. (e.g. our local 70cm repeater's stream is called 'pi2ehv.ampr.org' which is a lot easier to remember than '175a3d60bff6f7acec91e018f0d527abae5b69f6237304ec2a67a7a03bb0c103')
A stream can also have aliases. For analog audio repeaters it is for example convenient to also have a CCS7 ID (just like DMR/D-STAR) since you can link using DTMF commands.

DML itself is completly agnostic about the data send. It could be audio (of any codec type), data (like FPRS) or video (I have used it to distribute live webcams)

When stream data is send it done in packets. Each packet will be accompanied by a timestamp and a cryptograpic signature.

And now for the Ethernet part:
For audio each data packet will be accompanied by a sender address. If the repeater is receiving an analog audio packet it of course has no idea who it is, so it will use its own callsign to encode an 'eth_ar' Ethernet address.
If the audio is coming from e.g. a FreeDV2400B user we have a sender address and can use it as is.
Since we use our callsign as a base for the eth_ar addresses we can guarantee that they are globallly unique and can be used to identify the sender.
In this case we do not need a destination address since we already handle that by choosing the correct DML stream (e.g. linking to another repeater, a single person or a group)

On the link level the sender and destination address will work exactly as you would expect from a layer 2 protocol.
The only thing special is that on a local level a HAM will usually be broadcasting (and thus using the broadcast destination address) as our conversations are in general intended for everyone who happens to be listening to that channel.
Reply
#3
(12-13-2019, 11:04 AM)pe1rxq link Wrote: No problem, I am happy to explain.
The DML protocol itself is indeed a TCP/IP based protocol. Various DML nodes link to each other and exchange data about the streams they have available (either themselves, or from other nodes). This is done using SHA hashes.
When a leaf node (e.g. a repeater) requests a stream from another repeater it will be done based on these hashes.
Identifying a stream for the user is done based on a domain like name. (e.g. our local 70cm repeater's stream is called 'pi2ehv.ampr.org' which is a lot easier to remember than '175a3d60bff6f7acec91e018f0d527abae5b69f6237304ec2a67a7a03bb0c103')
A stream can also have aliases. For analog audio repeaters it is for example convenient to also have a CCS7 ID (just like DMR/D-STAR) since you can link using DTMF commands.

DML itself is completly agnostic about the data send. It could be audio (of any codec type), data (like FPRS) or video (I have used it to distribute live webcams)

When stream data is send it done in packets. Each packet will be accompanied by a timestamp and a cryptograpic signature.

And now for the Ethernet part:
For audio each data packet will be accompanied by a sender address. If the repeater is receiving an analog audio packet it of course has no idea who it is, so it will use its own callsign to encode an 'eth_ar' Ethernet address.
If the audio is coming from e.g. a FreeDV2400B user we have a sender address and can use it as is.
Since we use our callsign as a base for the eth_ar addresses we can guarantee that they are globallly unique and can be used to identify the sender.
In this case we do not need a destination address since we already handle that by choosing the correct DML stream (e.g. linking to another repeater, a single person or a group)

On the link level the sender and destination address will work exactly as you would expect from a layer 2 protocol.
The only thing special is that on a local level a HAM will usually be broadcasting (and thus using the broadcast destination address) as our conversations are in general intended for everyone who happens to be listening to that channel.

I'm still not understanding how any of this benefits by keeping an Ethernet frame format on the RF.  Worse, you're saying you don't use the Destination, so you're wasting 6 bytes of on-air data!  Everything you're doing at the RF level has to be encapsulated in TCP/IP to be sent anywhere, so you've got Ethernet on top of TCP, on top of IP, on top of Ethernet locally but probably not Ethernet between here and the destination, and even if it were Ethernet the whole way, they're different broadcast domains.  You're not performing Ethernet switching at the application layer.

I just don't see how using a Layer 2 protocol to route between devices on a global network is a good idea.  And if you're not using other Ethernet devices to provide any routing/switching for you, I don't see the benefit of sticking to an Ethernet frame on the RF protocol.

As for base37:  I was mistaken earlier, I thought your system only allowed for 6 characters which I was STRONGLY (and wrongly) opposed to.  I see now it allows for 8 characters, but only A-Z, 0-9 (and a null string terminator.)  It encodes the call-sign into 42 bits, and maps those to the 48 bits of an Ethernet MAC address in a way that's compatible with the Ethernet protocol.  A few things:
  • Did you notice that you can actually use base38 and still fit in 42 bits?  log2(38^8)=41.98 bits.
  • Rather than spending one of your 8 characters on a null terminator, instead use the base3[78] value of 0 to indicate an invalid character or some character you're willing to not allow a callsign to start with, and just keep decoding your base38 value until you reach 0.  This way, you can use all 8 characters without having to spend one on a null.

If I can understand the benefit to honoring Ethernet MAC address requirements (eg: multicast bits, etc), I might be talked into supporting an 8 character base38 encoding scheme for M17.  But I'm honestly not seeing the benefit, and would much rather have a 9 character base40 encoding scheme.
73 de KR6ZY
-Mark
Reply
#4
The null character is not needed for terminating. If you want to use the full 8 characters that is fine, the termination is simply implicitly at character 9.
The null character is only needed for callsigns with less than 8 characters.
And having base 38 is not needed, there are only 36 valid characters in an ITU callsign with the null character as a 'not used' you get 37.

I never proposed to use the Ethernet frame format as is.
I propose to use a frame format that can be translated to and from an ethernet frame format.
It works already with FreeDV 2400 modes which definitly do not have 6 bytes to spare on each frame.

Global linking indeed needs a higher level protocol, entirely different from the on air protocol.
But at both ends of the link the sender needs to be identified, and it might as well be in an ethernet like format.

An alternative would be to use yet another global lookup table like dmr uses.... I really hate that.
Reply
#5
I just ran across this today: [url="https://github.com/darconeous/ham-addr/blob/master/n6drc-arnce.md"]https://github.com/darconeous/ham-addr/blob/master/n6drc-arnce.md[/url]
which seems like a fairly well thought-out approach for reversibly mapping call signs to/from bit strings, in a way that maps quite naturally to IPv6.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)