Re: Comments to UDRL draft

[Harri Hakulinen NRC/Tre <Harri.Hakulinen@research.nokia.com>]

Hi,

It seems that we should discuss these issues first 
in the meeting, because it seems that we have quite
different models in ours minds. But here comes still
some opinnions/answers as starters.


EXT Emmanuel Duros wrote:
> >Harri Hakulinen wrote:
> >Actually, UDRL protocol should be capable to "signal" what
> >kind of ARP is used in this particular UDL.
> >I think that this was already in some version of the spec ?
>... 
> Concerning the spec of the udlr protocol, we refer to ARP in Section 7
> that describes the tunnel encapsulation format (backchannel). The
> backchannel carries MAC packets in which we can find (as an example) ARP
> or IP proto.

Yes, but there you assume, that ARP works just like in Ethernet.
I claim, that in cases where receivers are something like STB's
or PC's, they are not very much interested to keep track of MAC
addresses of another receivers. If they wan't to send something
to another receiver that is on the same link (subnet), they
can as well send it via "routing process", by using netmask
255.255.255.255 in tunnel interface. Feed router should be 
cabable to handle this "extra" traffic (it is really same for
the feed router, where the traffic that is going to feed comes.
And I assume that every feed router is cabable to route as much
traffic than feed can deliver.. ) .
 
> >Why MAC>GRE>IP  ??
> >I guess that you can encapsulate both ARP and IP
> >packets by using GRE without MAC.
> >So, why to send/use MAC here ?
> 
> The backchannel is intended to emulate a link layer via the
> encapsulation/decapsulation process. When a feed receives an
> encapsulated packet, the decapsulating process extracts the MAC packet
> and passes it to the link layer of the unidirectional interface.
> 
> Depending on the MAC destination address, various actions are taken (see
> Section 6.2). For example if it is a Broadcast/Multicast all nodes are
> supposed to receive it. The link layer delivers it locally and directly
> forwards it over the UDL.
> ...

It seems, that the same information is actually available in 
receiver IP address, at least if netmask is known, that's why
I think that no MAC addresses/ MAC framing is needed in tunnel.
Effectively, link layer interface in feed router that ends tunnel
can use information in receivers IP address to perform "MAC layer"
filtering, if needed. And one option is always to route every
IP packet.  

Receivers MAC address/framing makes sense in unidirectional 
broadcast link, but I don't see any particular reason to
use MAC framing in tunnel, you can as well "emulate" 
MAC-functionality if needed.

--
Harri.Hakulinen              
@research.nokia.com            Play the Snake 
Visual Communications          http://www.nokia.com/snake/
Tampere/Finland