Subject: Multicast satellite link configuration

From: Emmanuel Duros <[email-masked]>
Date: Mon, 22 Sep 1997 16:22:57 +0200 (MET DST)

We have been using since beginning 97 a broadcast satellite link for IP
transmissions. The Up-link is located at INRIA Sophia-Antipolis (South
of France) and receivers are at UCL (London, England), GMD (Darmstadt,
Germany) and Eutelsat (Paris, France).

We now have support for multicast addressing and try to integrate this
link to the MBone. We have already done some experimentations
retransmitting the Sigcomm'97 sessions which was held in Cannes (16-18th
sept, France) to the MBone. However we are still trying to get the most
efficient configuration.

The up-link and receivers are PCs with FreeBSD OS and running mrouted
daemons. The up-link has a send-only interface whereas receivers have a
receive-only interface. They are configurable such as communication
cards with an IP address & netmask. These PCs are also connected to the
Internet via Ethernet Interfaces.

A particular feature of the satellite link is to be unidirectional. An
up-link can only send data, a receiver can only receive data. As a
result, mrouted daemons do not behave properly because receivers cannot
send its routing msg to the up-link, i.e. an up-link considers it has no
down-link neighbor multicast routers.

To figure this out, I implemented a tunneling mechanism at link layer
level which allows communication between a receiver and a feed. I create
a bidirectional network on top of the unidirectional link. Basically, as
a receivers "sends" a packet to its receive-only interface, the packet
is encapsulated behind an IP header whose destination address is the
up-link IP address. The packet is then sent through regular connections
to the up-link. As the up-link receives it, the packet is decapsulated
and delivered to higher layers as if it was coming from the send-only
interface.

With this mechanism, receivers can communicate with the up-link as if
they were connected by a bidirectional link, it is transparent at IP and
therefore application level. e.g from a receiver you can ping the
send-only interface of the up-link.

Here is the current setup of our network topology:

   |-------|		Multicast IP - Satellite link
   |up-link|-->------->------------->----------------->--------
   |-------| sat0           |                |                |
       | int0               |                |                |
       |                    | sat1           | sat2           | sat3
       |                   ----             ----             ----
       |            Paris | R1 |    London | R2 |     Darms.| R3 |
  -----------              ----             ----             ----
  |INRIA net|               | int1           | int2           | int3
  -----------         -------------       -------          -------
       |              | local net |       | UCL |          | GMD |
       |              -------------       -------          -------
       |                                     |                |
      ----------------------------------------------------------
      |                   INTERNET/MBONE                       |
      ----------------------------------------------------------

This brings out the following problem: how can I configure efficiently
the routing daemons on each side (up-link/receiver) to match with the
real topology?:

1) We want to route multicast datagrams over the satellite link via the
up-link and in spite of the Link Layer tunneling mechanism we do not
want to forward multicast traffic from receivers to the up-link. The
tunneling mechanism should only be used to send routing messages from
receivers to the up-link even if any types of traffic can be tunneled.

Example: There is a source of M IP at UCL, someone from INRIA (or close
to INRIA) joins the corresponding M group. R2 should not be the
forwarding router but UCL main M router.

mrouted-3.9b2 allows route filtering, should we filter on R2 all routes
coming from int2? As a result, no route is advertised to the up-link and
M traffic is then not forwarded by R2.

Another alternative is to play with metrics. Setting an infinite metric
on int2 discards all routes announced by down-stream M routers to
receivers. Is this better?

2) Receivers can be located 10th of km away from the up-link or much
further away such as in other countries. The up-link and the receivers
are still considered as "directly connected routers", what threshold
should we use at the up-link (sat0)? Setting a high threshold (>32) is
fine if we intend to send M IP to Germany/England but it is
inappropriate for the receiver in Paris. Indeed, we then have to use
high ttl value if we want to reach the local net in Paris whereas it is
in the same country.

Any comment on how to configure routing daemons on this specific
topology?

Emmanuel