Re: Address Resolution Protocol

[jfijolek@usr.com]

Izu,
        I am an author of the MCNS data over cable telephony return 
specification (available at www.cablemodem.com). We have similar multicast 
problems which require IpinIP solution like yours. For ARP we use gleaning of IP
address/hw address from DHCP transactions. Tables are constructed thru the IP 
administration and may be aged by re-registration at some interval. Aging could 
also be based on the DHCP lease time.
Jack Fijolek
3Com Cable Access 

______________________________ Reply Separator _________________________________
Subject: Address Resolution Protocol
Author:  Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr> at Internet
Date:    07/24/97 02:25 PM


     
     
Izu,
     
I read your IDs, the first thing I am interesting in discussing is about 
MAC addresses and address resolution protocols.
     
It seems relevant to think that receivers will have a MAC address per 
interface. Similarly to the Ethernet standard, we need an Address 
Resolution Protocol to address particular receiver but as we saw it ARP 
can not work over unidirectional links.
     
Your proposition consists of perdiocally sending MAC addresses from 
receivers to feeds (BTW, I have not seen in the description of the 
Address Assign Table timeouts that would delete too old entries?). This 
rises the problem of how often do we need to announce this information 
compared to the number of receivers (scalability pb).
     
A similar mechanism to ARP [rfc826] could be used for the unidirectional 
links. The main difference resides in the fact that feeds only ask for 
the MAC address of the next hop as they want to forward a packet to
it. Consequently as the corresponding receivers replies, less traffic is 
generated on the back channels.
     
The choice of using periodical announcements of MAC addresss (1) or "an 
on demand address resolution" (2) may lead to a different choice of 
tunneling mechanism.
     
Indeed, if (1) is chosen an IP>IP encapsulation is sufficient, according 
to your mechanism MAC addresses are part of messages sent periodically 
with IP.
     
If (2) is chosen we may have to use another type of encapsulation such 
as Generic Routing Encapsulation [rfc1701-1702] in order to encapsulate 
ARP responses in IP pakets. GRE allows the encapsulatation of IP, ARP 
and other various protocols over IP. In our case only IP and ARP are 
necessary.
     
I come to the point of what mechanism should we be using, is there any 
preference/other choice?
     
Emmanuel
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
  (IMA Internet Exchange 2.02 Enterprise) id 3D75B910; Thu, 24 Jul 97 08:41:37
-0500
Received: from chouette.inria.fr by usr.com (8.7.5/3.1.090690-US Robotics)
	id HAA06014; Thu, 24 Jul 1997 07:43:32 -0500 (CDT)
Received: by chouette.inria.fr (8.8.5/8.8.5) id OAA07512 for udlr_m; Thu, 24 Jul
1997 14:25:38 +0200 (MET DST)
Received: from sophia.inria.fr by chouette.inria.fr (8.8.5/8.8.5) with ESMTP id
OAA07506 for <udlr-m@chouette.inria.fr>; Thu, 24 Jul 1997 14:25:37 +0200 (MET
DST)
Received: from chouette.inria.fr by sophia.inria.fr (8.8.6/8.8.5) with ESMTP id
OAA01036 for <udlr@sophia.inria.fr>; Thu, 24 Jul 1997 14:25:36 +0200 (MET DST)
Received: by chouette.inria.fr (8.8.5/8.8.5) id OAA07502; Thu, 24 Jul 1997
14:25:36 +0200 (MET DST)
Date: Thu, 24 Jul 1997 14:25:36 +0200 (MET DST)
Message-Id: <199707241225.OAA07502@chouette.inria.fr>
From: Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>
To: udlr@sophia.inria.fr
Subject: Address Resolution Protocol
Reply-to: Emmanuel.Duros@sophia.inria.fr