Re: Comments to UDRL draft

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

>> Harri Hakulinen wrote:
>>
>> However, as you mention it, an ARP traffic such as ARP responses
>> encapsulated by receivers and sent to feeds may generate a sinificant
>> traffic.
>
>That's why I think that ARP issue should be left out of UDRL spec.
>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 ?

I agree with you, we should not deal with ARP issues in UDLR WG, it is
not intended though. ARP was just mentioned to point out pbs which
occure in UDL environment. 

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.


>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.

If there is no MAC encapsulation, the link layer could not perform here
MAC filtering on the destination address. All packets would be directly
delivered to the corresponding queues (IP, ARP, etc) without correct
filtering. In somehow let's imagine what would happen to an Ethernet
link if Ethernet frames had no destination addresses, all the hosts
would accept them...


>Why not to stay in IP level and use some of already known 
>tunneling mechanisms ?

The very nice and important feature of the link layer mechanism is to be
completly transparent to the IP layer. The IP layer has no knowledge of
the underlying transmission technology but assumes that it is
bidirectional. Therefore, it seems much more appropriate to trigger
any process to emulate a bidirectional connectivity at link layer level.

As result, the receive-only interface of a receiver is configured as a
'classical interface' with its IP address and netmask. No particular
entry is added to the network layer (extra tunnel, etc) and therefore
most protocols run fine. We have been testing succesfully dynamic
multicast routing over a year on a sat link and RIP on local networks
(Ethernet links with unidirectional emulation !).

Emmanuel