Re: HIP, the Host Identification Protocol

[[e-mail]]

(My response to Paul's response to my initial proposal.)

<<On Wed, 16 Jun 93 12:59:39 EDT, [e-mail] (Paul Francis--formerly Tsuchiya) said:

>>  Responsible Router: A Pip router which is capable of routing from one

> Could this be changed to "area border router" or some such
> phrase?  Have a responsible router implies that some other
> router is irresponsible!  I can just see a future quote....
> We use ciscos as our responsible routers and wellfleets otherwise.

Well, I was trying to think up something suitably descriptive and
failed.  ``Intra-area router'' would work, I think.

>>  All systems shall periodically send a HELLO packet filled in with
>>  information about itself to the all-systems-multicast address (or a

> With ESIS, this is sent to all-routers.  This is preferable as it
> won't bother hosts that don't care to listen to the multicasts of
> other hosts.

Well, as I mentioned a few paragraphs below that, I wanted to give
systems the option of multicasting their HELLO in situations where
they would ordinarily have to send a multicast HELLO soon after
sending a required unicast HELLO.  (One of the hopes was that this
would lead to most systems eventually getting out of phase with their
neighbors, so that we don't have 50 systems on the same Ethernet all
transmitting their HELLOs at the same time...)

>>  
>>  Hosts
>>  -----
>>  When a host wishes to transmit a Pip packet to an in-area host, it
>>  should first search the ID table for an SNPA value.  If one is found,
>>  then the host is located on the same physical wire, and the packet can
>>  be sent directly.  If not, the sender should get a router list from
>>  the router table, and choose the entry from that list with the
>>  numerically smallest preference value that does not point to a stale
>>  entry in the ID table.
>>  
>>  If no SNPA was found, the sender should transmit the packet

> Why would a host ever have an ID entry without a corresponding
> SNPA entry?

It wouldn't.  I should have written, ``If no entry was found in the ID
table...''

> If the host has no ID entry at all, then it must send to the
> router because it doesn't know if the dest host is on the LAN
> or not.....

If the host has no ID entry at all, then it must look up to see if it
already knows the router from a previous transaction.  (One of the
purposes of having the routers transmit HELLO packets is so that the
hosts can keep track of which routers they have heard from recently;
if the host goes too long without hearing from a router which
previously responded, then it can automatically fall over to the
next-higher-preference-value router, /without/ (and this is important)
having to wiretap the intra-area routing protocol.

If the host has no router entry, then it sends the packet as a
multicast; the routers then hear this multicast and send back proxy
HELLOs to the sending host (if it is not on the same LAN segment);
this is how the router table is built.  Only one router will forward
the packet, but other routers which might be able to forward (if the
primary router goes down, for example) send back HELLOs as well, to
provide for the automatic fall-over.

> Also, I think router hellos should have a bit that indicates
> whether all systems that share a prefix with it are on the LAN
> or not.  Thus, for the more general case of LAN-based addressing,
> hosts can avoid sending hellos.....

Sure, that sounds reasonable to me.  No reason to burden a
single-segment area with useless information...

> With ISIS, all routers in the area keep routing table entries for
> all hosts in the area.

> If only the responsible router keeps the information, how can other
> routers do such things as load balancing?

Remember that /all/ routers which do intra-area routing are considered
responsible.  Here's an example of how we would do load-balancing...

Say our area consists of two LAN segments.  Both of these are served
by router1 and router2, which are the designated intra-area routers.
This means that both router1 and router2 know which IDs are present on
which wires.  They then agree between themselves that, for half of the
IDs on segment 2, router1 will use a preference of 0 and router2 will
use a preference of 1, with the roles reversed for the other half.
Now, when any /system/ on segment 1 wants to send to a first-half host
on segment 2, it gets back a preference-0 proxy HELLO from router1,
and a preference-1 proxy HELLO from router2; router1 also forwards the
packet to the destination host.  Now the sender will prefer to use
router1 to forward packets to that destination, unless it is down, in
which case it will automatically fall over to router2.

Note that it doesn't matter what kind of system is doing the
sending...

>>  
>>  As a specific example, say that the area consists of subnet1 and
>>  subnet2, which are interconnected by router1.  In addition, an exit
>>  router is located on subnet1, and an inter-area router on subnet2.  It
>>  is the responsibility of router1 to engage in Pip router discovery
>>  with the systems on subnet1 as a proxy for the inter-area router on
>>  subnet2, and with the systems on subnet2 for the exit router on
>>  subnet1.

> This still confuses me.  THe inter-area and exit routers will learn
> about each other via the routing protocol.  Router discovery is
> limited to a single subnet (LAN).

Right.  Don't forget that there are /hosts/ in this area, too!

-GAWollman

--
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
[e-mail] | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant