[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about tunneling proposals
Hello,
I have recently joined this mailing list. I'm currently working on UDLR for
Inria. After sorting out the different ideas in the proposals, I think
a few questions covering various points are relevant.
*******************************************************************************
First concerning WIDE's proposal that appeared in the mailing list (28/2):
> 3. Routing Protocols
>
> Here, the configuration
> when using OSPF as routing protocol and "Gated" as routing program
> is described.
>
> Communication from the feed to the receiver is done through UDL.
>
> By setting the interface "if0" in the file "gated.conf" of the feed
> to a lower cost than the terrestrial path's one,
> the UDL is given priority to a path of the Internet.
>
> On the other hand,
> the communication from the receiver to the feed
> passes through, in practice, some terrestrial networks.
> Because of the overhead of IP within IP tunneling,
> this path had better not be used.
> Therefore,
> by setting interface "if0" in the file "gated.conf" of the receiver
> to a higher cost than the terrestiral path's one,
> all packets except for those
> related to the routing protocols
> are denied passage through the tunneling network.
Since this setting is static, I wonder which cost is chosen and how, and
which metric is used. If the metric is hops count the setting of
interface "if0" of the feed to a lower cost seems quite natural, whereas
setting interface "if0" of the receiver to a higher cost in order to
avoid traffic over the tunnel doesn't seem straightforward. How do you
proceed? How is topology change taken into account?
> (2) Disadvantages
> - The routing information from the receivers to the feed
> pass through the tunneling network with an overhead.
> But I think it is not so major disadvantage
> because the routing traffic is smaller than the data traffic.
Ok, but how much overhead does is produce? And how does it scale if tunnels
from a receiver are set with numerous feeds? We can sure have point to
multipoint tunnels as described in Meyer (draft-ietf-rps-tunnels-00.txt,
november 1996), but the receivers should know all the feeds and we still
have a scalability problem.
*******************************************************************************
Second, concerning AEROSPACE's internet draft <draft-stepanek-vipre-00.txt>
> 1.4. Virtual Packet Relays
>
> Packets originating on downlink nodes which are destined
> for uplink nodes can be sent out the unidirectional interface of the
> downlink node, as if this interface were bidirectional.
>
> However, this approach assumes that uplink and
> downlink nodes are connected on a bidirectional network. It also
> fails to handle the asymmetric nature of the bidirectional link it
> approximates. In other words, the routing protocols in use will have
> to be configured to reflect the high cost of the virtual IP hop from
> receiver to uplink site.
>
> In effect, a Virtual Packet Relay creates a virtual network over
> which IP packets can flow as if there is a reverse path on the
> unidirectional link. Bandwidth of this path is limited by the
> underlying bandwidth of the bidirectional internet, so bandwidth
> management of the reverse link is important.
Ok, you say protocols will have to be configured to reflect the high cost
of the virtual IP hop. But how do you do it? Otherwise questions mostly
are the same as the ones for Wide. It seems both solutions are close.
In both proposals there is a virtual reverse link to elude routing
protocols as if there were a bidirectional satellite link. The real
difference I can see is that Aerospace is going deeper in the level of
abstraction. Only routing traffic is using this virtual reverse satellite
link in Wide's proposal. What about Aerospace? I guess all traffic from
receivers to feeds isn't encapsultad, but I don't see this point anywhere
clearly addressed in the draft. Could you have a word about that?
Thierry. <thierry.ernst@sophia.inria.fr>