Re: Difference between INRIA and WIDE idea

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

Dear all,

For information INRIA I-D is available at:

http://www.inria.fr/rodeo/personnel/eduros/various/draft-ietf-udlr-llencap-00.txt


Yongguang Zhang <ygz@isl.hrl.hac.com> wrote:

> At 07:52 PM 11/26/97 +0900, IZUMIYAMA Hidetaka wrote:
> >Dear all,
> >
> >I summarize the major difference between INRIA and WIDE
> >for discussion of UDLR mailing list.
> >
> >         %%%            %%%%
> >
> >1.The tunnel among the feeds
> >
> >  INRIA wrote nothing about the tunnel among feeds.
> >
> >  I think that the feeds must set up the
> >  tunnel each other as mesh topology to exchange the
> >  information for routing protocol.
> >
> >  (ex.1 OSPF)
> >  One of feeds will be a DR of a UDL.
> >  To do this, feeds must exchange the OSPF
> >  message(ex. HELLO message,etc.) each other.
> >
> >  (ex.2 DVMRP)
> >  One of feeds will be a DR of a UDL.
> >  To do this, feeds must exchange the DVMRP
> >  message(ex. PROBE messages,etc.).
> 
> 
> I agree that we should provide a mechanism for feeds to communicate with
> each other.  Instead of a mesh of tunnels, I suggest an "all-feeds" 
> multicast (AFM) group.  Since we assume that UDL feeds cannot receive
> (see I-D), the feeds must depend on AFM to send/receive multicast/broadcast
> on the UDL subnet.  Each feed should join an Internet multicast group
> pre-assigned for AFM.  (If UDL feeds can indeed receive, AFM will be a 
> local multicast in the UDL.)

I would like to go back to the definition of a feed: A router connected
to an unidirectional link through a send-only interface. 

If the UDL is a broadcast satelite link, a feed is capable of receiving
data from the link. The up-link (dish + transmission equipment) also
allows the reception of data from the link via the same dish, it can
behave as a receiver.

I am wondering if a sat link is a particular case of UDL with feeds
beeing capable of receiving data ?

If it is not, we can consider a feed as having a bidirectional
interface. Then we may not need of tunnels or AFM communication BETWEEN
feeds.


> >2.The tunnel from receiver to feeds
> >
> >  In section 5.3.4. of INRIA's I-D,
> >  a Receiver maintains the all active feeds' list and
> >  select one feeds'.
> >
> >  I think a receiver doesn't need to maintain the
> >  list of all active feeds. Normally a receiver sets up 
> >  a the tunnel to one of feeds.
> 
> 
> INRIA's I-D maintains a list of all active feeds because
> it relies on the list to send a message to "all-feeds".
> If we have AFM (as described above), we may not need to
> keep the list.
> 
> Another usage of the list is for efficient implementation
> of "any-feed" semantics (for example, if a receiver wishes
> to send a message to all receivers, it can tunnel to "any-feed").
> But before we have "anycast", we may want to either keep the
> list and pick one randomly each time, or pick one permanently
> (if you know the distance of all active feeds, it will
> be good to pick one closest).  Maybe keeping the list is a
> good idea.

We can do something like:

If a receiver wants to send a broadcast/multicast msg over the sat link,
it encapsulates it in a AFM packet (and sends it via regular
connections). However this supposes the receiver is connected to an ISP
which supports Multicast routing.

If a receiver wants to communicate with another receiver, it chooses
(randomly ?) a feed and sends encapsulated packets to it. The feeds
receives the datagram, decapsulates the payload and forwards it to the
destination over the sat link.

 
> >4.Requirement for on-demand ARP
>...
>...
> Did we have a rough consensus on last IETF about using GRE?

This depends on the mechanism which is used to maintain tunnels. 

In DTCP, a receiver periodically asks a feed if it can keep on using a
tunnel. It joins to the request its MAC address. In this case, GRE is
not necessary because the MAC address is passed to the feed via the DTCP
protocol.

In INRIA I-D, the HELLO protocol maintains a tunnel between a receiver
and a feed. A receiver tunnels periodically its MAC address to every
feed (it may be very interesting here to us AF). For that reason we use
GRE to distinguish the type of encapsulated data (IP or ARP). See
Section 6 of the I-D.

Emmanuel