[governance] Uni.X to Uni.X .NETworking - Getting Ready for WIMAX

[Jim Fleming]

Uni.X to Uni.X .NETworking - Getting Ready for WIMAX

WIMAX (unlike WIFI) is going to allow for a 10 mile radius. That will create
much
larger digital islands than the current $50-per-node WIFI technology. In
both cases,
the WIFI and WIMAX nodes will be 24x7 always on and will likely use 1s and
0s
to compose messages between nodes. Those 1s and 0s will likely be grouped
into
160 bit groupings because of the large base of legacy software and
wide-spread
knowledge base.

Reviewing the first 32 bits of the 160 bit message, we could have the
following:

4 bits with Channel ID (commonly 0100 or 0110)
4 bits fixed at 0101 which may have to stay that way for another decade
8 bits of addressing in the form SSSSDDDD with S for Source and D for
Destination
6 bits of addressing SSSDDD fixed at 000000 for a long time
10 bits for a message length field or other usage with all patterns legal
including all 0s

Looking at the 4 bit Channel ID, it may make more sense to consider it for
addressing
in the form SSDD with S for Source and D for Destination. If that is the
case, then 0100
would indicate communication from region 01 to region 00. The pattern 0110
would indicate
communication from region 01 to region 10. For transition purposes, it may
be better to
assume that only intra-region messages are supported. The pattern 0101 would
then be
similar to the second group of 4 bits and indicate region 01 to 01. When
dealing with new
technology there is sometimes merit in having patterns which are easy to
remember in the
early going to allow people to focus on more important topics.

With the above assumptions, the first 32 bits would appear to be:
SSDDSSDDSSSSDDDDSSSDDDLLLLLLLLLL
01010101SSSSDDDD000000LLLLLLLLLL

Since only half of the address bits would appear in a DNS A Record, the
following
distinctive pattern(s) would start to emerge in the left-most bits:
0101DDDD000
That results in 16 various /11 address blocks striped across the 32-bit
address space.
Since the entire address space is indexed by 64 bits, the above arrangement
would only
impact the 32-bit prefix. In the future, the other bits could be activated
as legacy systems
fall by the way-side and code is reduced to handle a more stream-lined
packet format.

The second group of 32 bits is a much more complex problem when moving from
a legacy
code base. Fourteen (14) address bits are certainly easy to encode and
testing shows they work.
The other 18 bits are much more complex yet offer all sorts of opportunities
for clever new
features. One school of thought takes the approach of using all 32 as 16+16
and another school
of thought recognizes that huge addresses are really not needed or desirable
because of
routing and/or political barriers and the second group of 32 bits is a place
where many hooks
can be located. In the DNS A Record, that results in a 16 bit string in the
middle of the 32-bit
prefix that may churn for some time. That may not be a bad thing with the
left-most 11 bits
(above) rather stable.

The third group of 32 bits is not as complex as the second group. They line
up as follows:

SD - 2 bits of address set to 00
SD - 2 bits of address set to 11
G - a guard bit or global bit set to 0 for local and 1 for global
TTT - the hop-count field

PP - 2 bits for the Protocols (ICMP, UDP, TCP, NOP)
SSSDDD - more address bits or protocol map index

16-bits for the checksum that could also be used for data with the NOP
protocol

The fourth and fifth groups of bits are very easy with 32 bits in the Source
and Destination fields.

In legacy systems, setting the TTL to 00111111 (63) is compatible with the
global hop-count above.
Many modern operating systems currently set it to 64 knowing it will
immediately roll to the
desired value in the NAT device, also called the Provider Edge (PE) device.
With the SD bits
above in the DNS A record, the DNS can be used to adjust what appears to be
the hop-count.

_______________________________________________
governance mailing list
governance at lists.cpsr.org
https://ssl.cpsr.org/mailman/listinfo/governance