Re: questions

[newbie <m1lu@yahoo.com>]

Emmanuel:

Thanks for the clearifation.

More questions interleaved.

--- Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>
wrote:
> newbie wrote:
> > 
> > Hi:
> 
> Hi -mll,
> 
> > I have some questions on
> > "draft-ietf-udlr-lltunnel-02.txt".
> > 
> > 2) can anyone here explain scenario 1 to 4?
> 
> The IESG members asked us to make some clarification
> in the document
> (draft-ietf-udlr-lltunnel-03.txt should come out
> very soon). We have made slight
> modifications to section 5, it might be clearer now
> ?:
> 
> 5. Emulating a broadcast bidirectional network
> 
>    The simplest to use solution is to emulate a
> broadcast capable link
>    layer network. This will allow the immediate
> deployment of existing
>    higher level protocols without change. Though
> other network
>    structures, such as NBMA, could also be emulated,
> a broadcast network
>    is more generally useful. Though a layer 3
> network could be emulated,
>    a link layer network allows the immediate use of
> any other network
>    layer protocols, and most particularly allows the
> immediate use of
>    ARP.
 
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.

>    A link layer (LL) tunneling mechanism which
> emulates bidirectional
>    connectivity in the presence of a unidirectional
> link will be
>    described in the next section. We first consider
> the various
>    communication scenarios which characterize a
> broadcast network in
>    order to define what functionalities the link
> layer tunneling
>    mechanism has to perform in order to emulate a
> bidirectional
>    broadcast link.
> 
>    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:
> 
>    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.
 
>    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?
 
>    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?
 
>    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?
 
>    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?

>    Note that regular IP forwarding over such an
> emulated network (i.e.
>    using the emulated network as a transit network)
> works correctly; the
>    next hop address at the receiver will be the
> unidirectional link
>    address of another router (a feed or a receiver)
> which will then
>    relay the packet.
> 
> 
> > 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?

> Hope this helps !
> 
> Emmanuel

TIA

best regards

-mll
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com