Re: Host Addressing Conventions [addr-conv 2.8]

Garrett.Wollman@uvm.edu Tue, 15 June 1993 17:47 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12041; 15 Jun 93 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12036; 15 Jun 93 13:47 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15225; 15 Jun 93 13:47 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA28543> for ietf-archive@nri.reston.va.us; Tue, 15 Jun 93 13:47:04 EDT
Received: from sadye.emba.uvm.edu by thumper.bellcore.com (4.1/4.7) id <AA28539> for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 15 Jun 93 13:47:02 EDT
Received: by sadye.emba.uvm.edu id AA14342 (5.65/6.02); Tue, 15 Jun 93 13:46:58 -0400
Date: Tue, 15 Jun 1993 13:46:58 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Garrett.Wollman@uvm.edu
Message-Id: <9306151746.AA14342@sadye.emba.uvm.edu>
To: Paul Francis--formerly Tsuchiya <francis@thumper.bellcore.com>
Cc: pip@thumper.bellcore.com
Subject: Re: Host Addressing Conventions [addr-conv 2.8]
In-Reply-To: <9306151724.AA14675@tsuchiya.bellcore.com>
References: <9306151724.AA14675@tsuchiya.bellcore.com>

<<On Tue, 15 Jun 93 13:24:35 EDT, francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) said:

> Is it an adjunct to router discovery?  I would like to minimize
> overlap with router discover.....

> Also, we are tying router discovery with auto host config (we'll
> demo this in Amsterdam).  I'm not sure if our how this matters,
> but I thought I'd throw it out.....

Well, what I've done is divide routers into two classes...

The ``Responsible Routers'' are all routers which could potentially
route packets between subnets of an area (even if the routing protocol
doesn't have them doing that at the moment).

The ``Other Routers'' are all routers which could not fill this role.
This also includes Responsible Routers when acting in a
non-Responsible role (i.e., as inter-area or exit routers).

Here's a diagram that I drew on the dinner table last night:

                            area1 | area2
      +---------+                 |
    +-+ router1 +-+               |
    | +----+----+ |               |
sn1 |      |      | sn2           |
    |  sn3 |      |               |
    |      |      | +---------+   |   /other
  +-+--------+    +-+ router3 +-------|connections
  | router2  |      +---------+   |   \in area2
  +----------+                    |


In this toy network, router1 and router2 are responsible for area1,
and they run some sort of routing protocol between them to figure out
a consistent view of which IDs are located on which wires and will be
forwarded by which routers.  Router3 is not responsible as far as
area1 is concerned, although it may (or may not) be in area2.

Hosts discover router3 using Router Discovery; area2 has a different
Pip address, so this makes sense.  Hosts discover router1 and router2
using HIP (the Host Identification Protocol); they treat router3
(which they learned about through RD) just as if it were another host,
for the purpose of directing packets toward it.  Routers discover
hosts in the same way that hosts discover other hosts: they send the
first packet multicast, and then wait for a ``you-found-me'' reply to
come back.

The significant changes that I have made from ESIS are:

- Hosts don't transmit Hello packets, only You-found-me packets.
- All the responsible routers send back You-found-me packets when they
  might be able to forward a packet to the host in question; each
  You-found-me includes a ``preference'' value so that hosts will not
  use a backup router unless the primary has timed out.

As I said, I'll try to write this up and send it in sometime today.

-GAWollman