Network association algorithm

[Javier Cardona]

Hi John, Dan,


After chatting with Dan I finally understood your flowchart (pardon my
thickness,  I was having some nomenclature problems..).  I learned yesterday
that:

 1) "established MPPs" are MPPs with multiple mesh interfaces, at most one on
 each channel 1,6 and 11.  They are also called "school servers" and will not
 be moving around.

 2) "ad-hoc MPPs" are xo's that act as MPPs, as portals they were
originally conceived.

 3) Addresses are assigned by DHCP because link local addresses cannot be
 routed.  L3 routing is done by MPPs across mesh segments at different
 channels.

Based on this understanding, I would like to suggest a change in the way DHCP
is used in your proposal.  The current flow is:

       +           +
      / \         / \
     /   \ y     /   \ y
----+DHCP?+-----+ MPP?+----
     \   /       \   /
      \ /         \ /
       + n         + n
       |           |
       +-----------+
       |

This approach separates IP address assignment (DHCP) and MPP detection and path
selection.  I believe these two functions which can be combined in one:

1. xo sends a DCHP request to L2 address ANY_MPP.  This is a standard
DHCPREQUEST sent to a unicast address.  The only thing "non-standard" would be
done at the dhcp client:  this DHCPREQUEST would have the L2 anycast
address, the L3 broadcast address and would be injected at L2 using
the linux packet interface.

2. MPP assigns an IP address and sends a DHCPACK to the L2 address that was in
the DHCPREQUEST.  That's vanilla DHCP server.

3. The xo knows the DHCPACK comes from an MPP because it's a response from a
request sent to the ANY_MPP address.

Advantages:

1. Faster configuration.
2. No broadcast+anycast traffic, only anycast.
3. Replaces non-standard MPPREQs with standard DHCP

This model can also be used for ad-hoc MPPs.  In that case ad-hoc MPPs would
return gateway and DNS information but would not assign an IP address.

What do you think?

Javier