Network association algorithm

[Javier Cardona]

Dan, John,

The patch linked below modifies dhclient to override the broadcast
address of a network interface with an anycast address.  This option
is configured in dhclient.conf with the new directive anycast-mac :

interface "msh0" {
  anycast-mac ethernet c0:27:c0:27:c0:27;
}

When that option is present, all DHCP broadcast traffic out of msh0
will be sent to the anycast-mac address.  The IP address is left
unchanged (i.e. 255.255.255.255), which avoids having to change
anything on the dhcp server side.  We tested it with a vanilla dhcp
server running on the MPP(s).

Let me know if you would like me to package this in an RPM or if there
is anything special that needs to be done to integrate this with NM.

Cheers,

Javier

The patch:  https://cozybit1.dnsalias.org/~javier/patches/dhclient-3.0.5-anycast.patch

On 5/9/07, Michail Bletsas <mbletsas at laptop.org> wrote:
> Javier,
>
> I think that your approach fits perfectly with our latest connection
> flowchart and I would like to see it implemented asap.
>
> M.
>
>
>
>
>
> "Javier Cardona" <javier at cozybit.com>
> 05/04/2007 02:39 PM
>
> To
> "John Watlington" <wad at laptop.org>
> cc
> "Dan Williams" <dcbw at redhat.com>, "Michail Bletsas" <mbletsas at laptop.org>,
> "OLPC Devel" <devel at laptop.org>
> Subject
> Re: Network association algorithm
>
>
>
>
>
>
> 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
>
>
>
>


-- 
Javier Cardona
cozybit Inc.
p 415 974 6770
f 415 974 6771
c 415 630 0627
e javier at cozybit.com