Address Resolution Protocol

[Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>]

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