The IP Over NBMA (ION) Archive

[Karthik Muthukrishnan <karthikm@terrabit.casc.com.casc.com>]

	An Additional Requirement of RFC 1293 compliant Routers - A Proposal
	--------------------------------------------------------------------
		Karthik Muthukrishnan (karthikm@casc.com)
		July 20, 1996.

Explanation of Notation 
-----------------------
X.1 is an IP address where X is the network number and "1" is used to notate
the host id on that network. To be CIDRized, regard "1" and "X" as 
variable length. However, X.1 and X.2 refer to two distinct interface 
addresses on the same sub(super)net. Y.1 is an interface on a net neccesarily
distinct from that of X.1.


Configuration Example:
---------------------


|------------------------|
|   RTR 1       	 |
|   IP ADDRESSES:        |
|   X.1, Y.1, Z.1        |
|       	         |
|       	         |
|-------------\----------|
             / \
            /   \
   DLCI=20 /     \  DLCI=30
          /	  -------------\
         /		       	\
        /			 \
|------/-----------------|   |----\---------------------|
|   RTR 2                |   |	 RTR 3  		|
|   IP ADDRESSES:        |   |	 IP ADDRESSES:  	|
|   Y.2, Z.2             |   |	 X.2, Y.3       	|
|       		 |   |				|
|       		 |   |				|
|------------------------|   |--------------------------|


The Problem
-----------
I beleive there is a problem for routing protocols such as OSPF which, 
in some modes (such as Point-to-Multipoint), rely upon dynamic discovery of 
neighbors to establish full routing connectivity.

o RTR 3 comes up, sees DLCI 30 come up, does an INARP with local address = X.2.
	o RTR 1 responds with X.1 per RFC 1293 (subnet match). 
	o RTR 1 updates its ARP cache with the tuple "X.2 DLCI 30". 
	o RTR 3 receives the INARP response and is satisfied. Its ARP cache 
	  has the entry "X.1, DLCI 30"
o RTR 2 comes up, sees DLCI 20 come up, INARPs with local address Y.2.
	o RTR 1 responds with Y.1.
	o RTR 1 updates its ARP cache with the tuple "DLCI 20, Y.2".
	o RTR 2 receives the INARP response and is satisfied. Its ARP cache 
	  has the entry "Y.1, DLCI 20"

Since OSPF is based on LIS type connectivity, RTR1 will never establish 
neighbor relationships with RTR 3 since Y.3 "never came up". Of course, 
RTR 1 could INARP DLCI 30 with Y.1 and Z.1 to learn about Y.3, but that 
would require a large number of INARPs to be sent from a RTR with a large 
number of IP addresses. Typically, I would imagine that RTR 1 would have 
a large set of IP addresses and RTR 2 and 3 would have a significantly 
smaller number of addreses. In such a case, it would greatly reduce
address resolution traffic if RTR 2 and RTR 3 INARPed with (Y.2 and Z.2) 
and (X.2 and Y.3) respectively.

The Proposal
------------
Make it a "MUST" requirement of RFC 1293 compliant routers to INARP once 
with each of its IP addresses. In the example, RTR 3 would send 2 INARP 
requests with X.2 and Y.3. RTR1 would respond with X.1 and Y.1 respectively 
and update its ARP cache with X.2 and Y.3. Similarly, RTR 1 would update its 
ARP cache with Y.2 and Z.2 as well.

Of course, what if RTR 1 saw DLCI 30 come up before RTR 3 did ? RTR 1 would 
INARP with X.1, Y.1 and Z.1. But given that RTR 1 is likely to be a more busy 
router it is unlikely that this mis-synch will happen with each of RTR 2 
and RTR 3.