Re: Comments to UDRL draft

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

> From: Harri Hakulinen NRC/Tre <Harri.Hakulinen@research.nokia.com>
>...
> Section 6 says:
> > This mechanism has been designed to work for 
> > any topology regardless of the number of feeds and
> > receivers. In particular, the special case of 
> > a single send-only feed and multiple receivers
> > is among the topologies supported.
> 
> I would claim, that it is not supported in
> particularly scalable way. In Section 8.1 it 
> is assumed, that normal (ethernet)style ARP
> is used in broacast feed.
> 
> This implies, that if there is large number
> of receivers in one feed (that seems to be
> possible in 27 Mbits DVB link), huge amount
> of ARP traffic is generated and must be 
> processed by all receivers ?

The link layer tunneling mechanism was designed in a scalable way
without considering higher level protocols. The DTCP protocol does not
generate significant traffic whatever the number of feeds or receivers.

However, as you mention it, an ARP traffic such as ARP responses
encapsulated by receivers and sent to feeds may generate a sinificant
traffic. 

In this particular case of UDLs, we should think of redesigning ARP
mechanisms in order to not overload the internet with responses. Beside
ARP, IGMP is another protocol which is not well designed to work with
UDLs. This is one item to talk about in Chicago...


> Section 6.1 says:
> & 4) an IP address different from the previous cases 
> &    (any IP address): the datagram is discarded. 
> &    Packets whose destination does not belong to 
> &    the unidirectional link are discared. Routing
> &    is not allowed, see Section 8.2.
> 
> Why discarded ?
> 
> I guess it is job of routing protocols to
> affect to routing tables so, that these
> packets are not send to tunnel, if that
> is what is wanted (as is said in 8.2 ). 

In this case, routing IP traffic can be performed efficiently without
the need of routing the traffic from the receivers to the feeds using
the link layer tunneling mechanism.

RIP as an example: a receiver must not take into account routes
announced by feeds.

If it does, it will encapsulate IP datagrams (link layer tunnel) and
will send the packets to the corresponding feed. This feed will then
decapsulates the IP packets and will forward them to the next
terrestrial router.

If it does not, the receiver has learnt how to reach the destination
from a terrestrial neighbore router and will forward the traffic to
it. 

In both cases the packets reach their destination. However the second
is prefered because:
  - there is no processing due to the link layer encapsulation as in
  the first case
  - use of 'classical routing': no extra [IP,GRE] header added to every 
  IP packet, does not overload unnecessary the Internet
  - the packet follows the 'physical shortest path' to the destination
  which is not the case when packets are encapsulated


> And, if this approach is selected, as well you 
> should NOT send via tunnel unicast packets that
> belong to the unidirectional network, because 
> obviously they are routed there anyway, even if
> they are not send via tunnel.

The link layer tunneling mechanism provides a means for emulating an UDL
in a broadcast local network. Every node connected to this udl should
listen to/talk to each other. When a receiver sends a packet to receiver
unidirectional interface, the packet should be received as it was coming
from the udl, i.e. its ttl must be decreased only by 1 and not by
[number of routers] if the packet was sent via the Internet without
encapsulation. Furthermore, the ARP protocol may be required to work
between receivers, this is only possible using the link layer tunneling
mechanism.

> Sometimes, like in Mobile IP it is requirement to 
> tunnel all "return traffic" back to "home subnet".
> Why it is denied here ?

For technical reasons (see above), it seems more efficient to prevent
the whole traffic from being routed to the feed/"home subnet". 

Maybe there are security or commercial reasons to consider this ?


> 
> Section 7.1 says:
> > In our case, only the support of the MAC addressing
> > scheme of the unidirectional link MUST be implemented.
> > Note, this MAC level packet can carry an IP packet or
> > an ARP packet.
> 
> What is ment here ? Somehow this sentence is
> contradigting with previous Section (7.) ?

I have just read this part and it is a bit confusing. I will make it
clearer, it is meant MAC>GRE>IP in 7.1 and 7.


> Section 7.2 says:
> 
> > An alternative is to encapsultate the MAC level packet
> > within IP. The protocol field in the IP datagram is 
> > then set to the MAC level type of the unidirectional link.
> 
> IP protocol = MAC level type ?
> What are these MAC level types ?

They are not defined yet !

Standard MAC level types should be defined for specific UDLs such for
satellite links (IETF ipsat ?). And then specified as "Internet Assigned
Numbers"...

Emmanuel Duros
+--------------------------------------------------------------------+
|http://www.inria.fr/rodeo/personnel/eduros                          |
|INRIA Sophia Antipolis              | Projet RODEO                  |
|2004, Route des Lucioles BP 93      | Phone : +33 (0)4 92 38 79 42  |
|06902 Sophia Antipolis CEDEX France | Fax   : +33 (0)4 92 38 79 78  |
+--------------------------------------------------------------------+