[Fwd: [Debian-net-admin] autonet design]

[Thomas Hood]

Chris Hanson gave me permission to forward this message that he
originally posted to the debian-net-admin mailing list.  // Thomas

-------- Original Message --------
Subject: [Debian-net-admin] autonet design
Date: Mon, 08 Mar 2004 13:18:57 -0500
From: Chris Hanson <cph at zurich.csail.mit.edu>
Reply-To: debian-net-admin at zurich.csail.mit.edu
To: debian-net-admin at zurich.csail.mit.edu

Now that I've got a few minutes, I'll try to explain my current
thinking about autonet.

The general architecture is pretty simple, consisting of three basic
layers.  I'll ignore the communication mechanism for now, as that
isn't a critical detail; DBUS is one possible choice.

The "physical" layer is responsible for monitoring network devices for
connectivitity.  It consists of a collection of modules, each of which
supports a different type of network device.  The input to this layer
is a set of active network devices (e.g. from hotplug) and the output
consists of appropriate "connected"/"disconnected" messages for each
device.  The programs ifplugd and waproamd should fit into this layer
with little modification.

The "link" layer is responsible for probing the network attached to a
connected device, in order to determine as much as possible about it.
It consists of a set of modules, each of which implements a particular
kind of probe.  All of these probes operate directly on the link level
of the networking stack, as the IP address hasn't yet been configured.
The programs guessnet, laptop-net's arp-discovery, and ifscout are
examples of this layer's modules, but I will probably write my own
modules here.

The input to the link layer consists of messages identifying a network
device to be examined, plus any relevant configuration information
needed by the module.  The output is information about the connected
network.

The most important modules for the link layer support the ARP and
DHCPINFORM protocols.  I have just finished the ARP module, and plan
to write the DHCPINFORM module next.

The final layer is the "binding" layer, which is responsible for
binding a network device to an IP address and network.  This layer
consists of a program that takes as input a set of network
descriptions and the outputs from the other two layers, and uses that
to bind a device.

What makes the binding layer different from other such programs is
that it operates by deduction rather than by prescription.  The
binding layer's inputs are almost entirely comprised of network/host
descriptions.  The inputs from the link layer filter and augment the
network descriptions in the configuration.  When a particular network
description is identified as the one an interface is connected to, the
actions needed to configure the interface's IP layer can be derived
from the network description.

For example, here's a fragment of a configuration:

    <interface id="wired-interface" mac="00:09:6b:bf:40:57" type="ethernet">
      <metric>0</metric>
      <driver>e1000</driver>
    </interface>

    <network address="18.43.0.0/16" type="ethernet">
      <host address="18.26.0.18"><service protocol="dns" /></host>
      <host address="18.24.0.120"><service protocol="dns" /></host>
      <host address="18.26.0.36"><service protocol="dns" /></host>
      <dns-domain name="csail.mit.edu" />
      <dns-search>
	<dns-domain name="csail.mit.edu" />
	<dns-domain name="ai.mit.edu" />
	<dns-domain name="mit.edu" />
      </dns-search>

      <host address="18.43.0.172" mac="00:09:6b:bf:40:57">
	<dns-name>kleph</dns-name>
      </host>

      <host address="18.43.0.1" mac="00:e0:2b:82:5b:00">
	<dns-name>anacreon</dns-name>
	<gateway>
	  <destination>any</destination>
	</gateway>
      </host>
    </network>

The information in this configuration is entirely descriptive.  But
if the ARP module probes eth0 and discovers 18.43.0.1, then the
binding layer knows everything it needs to know in order to configure
the interface: (1) all the DNS information is given; (2) the gateway
is identified; and (3) the IP address of the interface is identified
by matching the MAC address of the interface with the MAC address of
the "kleph" host.

If the configuration file is pre-processed before use, the IP-address
information can be obtained from DNS, further reducing size and
complexity of the description.

If there is a DHCP server on the network, the DHCPINFORM probe will
discover most or all of this information, and consequently it need not
be written down in the configuration file.  The configuration just
needs to say whether the IP address is static or is allocated by the
DHCP server, and supply other info that the DHCP server doesn't offer.

The binding layer is not yet written.  But there is a working design
for the configuration language, of which the above is a sample.

As usual, any comments or criticism are welcomed.

Chris