mesh portal discovery

[John Watlington]

On Jan 9, 2008, at 2:55 PM, Michail Bletsas wrote:

> David Woodhouse <dwmw2 at infradead.org> wrote on 01/09/2008 02:40:46 PM:
>
>
>> We can also
>> check the mesh path length to the origin of each RA we see, and  
>> choose
>> the best one.
>>
>
> The way this was originally implemented in a way that can be used  
> for any
> "well defined" service (not just network gateways),
> was to assign an anycast MAC address to such well defined services.
>
> So when a node is looking to see if there is another node providing  
> such a
> service in the mesh, all that it has to do is a path discovery for  
> the MAC
> address corresponding to that service. If the path discovery is
> successful, both the presence of the service as well as the optimal  
> path
> to it has been discovered.
>
> In the case of the mesh portal (A NAT Internet Gateway in our case) we
> need to get back the IP address of the gateway as well as DNS info.
> A simple python server listening at a predefined port was providing  
> that.
> That simple server has been replaced by a complete DHCP server in our
> current implementation.


The DHCP server was needed anyway.   And to implement shortest path
routing both for sent and received packets, we needed a mechanism for
receiving an IP address that reflected the nearest MPP anyway (or use  
NAT,
something we would like to avoid inside the school....)

wad