To sort of summarize, then, with this msgSpec, including overall size, structure and priority (1 / sanguinity) specified in 6 or 7 bytes, will fit a 64bit register, with room, for low-level routing. Add a 32bit register to the 64bit register, and you can fit the 11 or 12 bytes to fully specify the FEC encoding, for hardware assisted en/de/coding. I thought this may be important. On the right track?

thanks ,
robert

On 12/20/2015 09:33 AM, Robert Withers wrote:
Ok, let me make one last change to this 7 byte alternate proposal for the message specification. In the first 3 bytes with 4 fields, use supersymmetry to specify 6bits per field. SO the alternate would look like below...

The whole point of the multicast symbol is to provide for low-level routers to not even have to decode the asn.1 header and distinguish all our message and header types. Just grab the first byte and mask the upper 6bits and shift, there is a destination specifier, at least in the large, as an alternate tunneling capability and would support reuse of 4byte IP addresses for NAT.  If we loose that and knock sanguinity back to 2bits, then we are down to a 6 byte spec + payload.  I'm mulling iot over, obviously.

msgSpec: 7 bytes binary encoded


--
. .. .. ^,^ robert

--
. .. .. ^,^ robert