Re: questions

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

mll,

newbie wrote:

> For sentance "The simplest to use solution is to
> emulate a broadcast capable link layer network", do
> you mean "The simplest solution is to ..."? I guess it
> is wording problem.

You are rigth.

Concerning the scenarios. The LLTM mechanism provides a means fo emulating a
broadcast-type connectivity between nodes (feeds and receivers) that are
connected by a *UDL*.

The list of scenarios enumerates all the scenarios that would potentially occure
if feeds and receivers were connected by a *BDL* (e.g. Ethernet).

In other words, imagine all the possible scenarios between hosts that are
connected on a Ethernet LAN. Basically, a host can send unicast packets
(point-to-point) to another host or a host can send a multicast packets to all
hosts (point-to-multipoint). Connectivity is bidirectional among hosts.

In the presence of a UDL, we have two sets of hosts: feeds and receivers. We
want to keep the same level of connectivity between these hosts as if they were
connected by a *BDL*. That is why we enumerated the list of communication
scenarios between feeds and receivers as if they were connected by a BDL.

The LLTM is there to *EMULATE* this "full" connectivity which is not possible
because of the UDL.


> >    Here we enumerate the scenarios which would be
> > feasible on a
> >    broadcast network, i.e if feeds and receivers
> > were connected by a
> >    bidirectional broadcast link:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the starting point of the assumption


> >    Scenario 1: A receiver can send a packet to a
> > feed (point-to-point
> >      communication between a receiver and a feed).
> >
> 
> I am having hard time to picture this scenario.

If a feed and a receiver were connected by a *BDL*, a receiver could send a
Ucast packet to a feed. Right ?

> >    Scenario 2: A receiver can send a
> > broadcast/multicast packet on the
> >      link to all nodes (point-to-multipoint).
> >
> 
> Which "the link"? the UDL link?

We make the assumption here that the link is bidirectional but in reality (with
a UDL) this scenario will only be possible using the LLTM.

> 
> >    Scenario 3: A receiver can send a packet to
> > another receiver (point-
> >      to-point communication between two receivers).
> >
> 
> >From one receiver to another receiver, so the first
> receiver is feeder relative to the second one. I mean
> that the relationship between feeder and receiver is
> relative, right?

Not really, refer to the terminology section (section 2).


> >    Scenario 4: A feed can send a packet to a
> > send-only feed (point-to-
> >      point communication between two feeds).
> >
> 
> so the second feeder (relative to its receivers) is
> receiver relative to its feeder, right?

same as above

> >    Scenario 5: A feed can send a broadcast/multicast
> > packet on the
> >      unidirectional link to all nodes
> > (point-to-multipoint).
> 
> >    Scenario 6: A feed can send a packet to receiver
> > or a receive capable
> >      feed. This is the default communication over a
> > unidirectional link.
> >
> >    These scenarios are possible on a broadcast
> > network. Scenario 6 is
> >    already feasible on the unidirectional link. The
> > link layer tunneling
> >    mechanism should therefore provide the
> > functionality to support
> >    scenarios 1 to 5.
> >
> 
> By the term "feasible" here, you mean that the current
> routing software can accommondate this scenario
> without supporting this draft/future RFC, right?

I am just saying that on a UDL, when sending a packet from a feed to a
receiver/receive capable feed, the link is used in a "native way". I am not
talking about routing consideration.

Now if you want to run common routing protocols between a feed and a receiver, I
do not see how your receiver would send its routing information to the feed
without LLTM, unless you hack/make weird configuration of your routing
protocols.


> > > 2) In section 6:
> > >
> > > A datagram is delivered from the network layer to
> > the
> > > link layer of the unidirectional interface (see
> > Figure
> > > 2). It is then encapsulated behind a MAC header
> > > corresponding to the unidirectional link. This
> > packet
> > > cannot be sent over the link and is then processed
> > by
> > > the tunneling mechanism.
> > >
> > > The packet is encapsulated behind an IP header
> > whose
> > > destination is the IP address of a feed
> > bidirectional
> > > interface (f1b or f2b), also called the tunnel
> > > end-point.
> > >
> > > f1b or f2b, according to the figure 1, was the
> > > interface(s) connecting to bidirectional internet.
> > But
> > > the text in section 6 seems to say that the tunnel
> > > goes through the bidirectional internet, instead
> > of
> > > forming a virtual symmetric link between f1u and
> > x1u.
> >
> > ^^^
> >
> > ?
> > Humm, I am not sure I understand what you are
> > explaining. In other words section
> > 6.1 says that: if the IP layer of receiver delivers
> > a packet to the link layer
> > of the unidirectional interface, then the MAC packet
> > is encapsulated behind a IP
> > header (with some encapsulation scheme) and sent to
> > a feed via the
> > "bidirectional network".
> >
> > -> A (connectionless) tunnel is set between a
> > receiver and a feed, encapsulated
> > packets go from a receiver to a feed only. There is
> > no "virtual symmetric link".
> >
> 
> I guess tha my question was not clear. the section 6.1
> means to me that the tunnel is established between r1u
> and f1b (from receiver prospective), am I right?

When you send your encapsulated packet from receiver 1 to feed 1, the source IP
addr of the delivery IP header is r1b and destination IP addr is f1b.

cheers,
Emmanuel