Many distributed applications may benefit from a high bandwidth connection to the Internet. However, this requires high bandwidth links between remotes sites.
A low-cost solution to deliver high bandwidth services over wide geographical areas via the use of broadcast satellite networks has been proposed by [ASBD].
However, this solution is based on low cost receivers with zero bandwidth return. Connection over the satellite link is therefore unidirectional. The integration of these satellite networks with the Internet requires changes in common routing protocols.
A satellite network comprises two types of stations: feeds, which can both send and receive packets, and receivers, which can only receive packets.
Every receiver is composed of a satellite dish oriented toward a geostationary satellite, connected via an interface either to a user station (in this case the access method is referred to as basic access) or to a router (in this case the access method is referred to as subnetwork access). The user station has another interface, and the router has one or more extra interfaces, connected to the Internet. Note that the cost of the hardware is made up of the cost of the satellite dish and of the reception card.
Information is sent from feeds to satellites and then broadcast to all the receivers that belong to the satellite coverage.
Installing feeds in strategic positions over the Internet will create shorter paths and packets will be routed via the satellite network that offers a higher bandwidth.
___ ___ \__\OO\__\ Satellite ^^ vv Network / \ uplink / \ / \ / \ Feed / \ ---- / SAT.x V ---- User's ---======>|R1| |H1| station ---- ---- /\ /\ INT.y || || Server \/ || (PPP connection) ---- ------------------------- || |S1|<==>| regular |<==/ ---- | connections | ------------------------- Figure 1: Basic access
All requests to a remote server are sent via the phone line and responses from the server should be routed by a feed on the satellite network.
___ ___ \__\OO\__\ Satellite R1: Feed ^^ vv Network R2: Receiver / \ / \ uplink / \ / \ / \ ---- / V ---- ------------- ---======>|R1| |R2|<===>| Subnetwork|<===--- ---- ---- ------------- /\ /\ || || Server \/ || ---- ------------------------- || |S1|<==>| regular |<==/ ---- | connections | ------------------------- Figure 2: Subnetwork accessIn that configuration only one satellite dish is required in order to serve a whole subnetwork. The management is also located in only one place, namely in the router.
That 'expandable topology' due to the potential increasing number of receivers (simple host or routers) leads us to consider dynamic routing solutions.
Some modifications should be applied to protocols in order to handle unidirectional links. For example, the protocol ARP [rfc826] assumes that links are bidirectional, and it expects a communication between directly connected host. In the same way, routing protocols assume that communication between neighbor routers is bidirectional to exchange routing information. The configuration in Figure 2 is therefore not supported.
Routing for that type of user's station is different from classical routing. Indeed, the station has two IP addresses : SAT.x (belongs to the satellite network) and INT.y (e.g. PPP connection to an Internet service provider), as depicted in Figure 1.
Users send packets via the interface INT.y, incoming packets should be routed to the default address SAT.x.
Our work is mainly based on the study of the most common routing protocols that will be used by feeds and receivers such as RIP [rfc1723] and OSPF [rfc1583] and DVMRP [rfc1075] for multicast routing.
Unlike receivers, feeds can broadcast routing messages via the satellite network. A feed will expect to receive messages (e.g. a response to a request on a specific interface) from all its interfaces. Since a feed cannot receive messages from the satellite network, routing protocols will consider that there is no reachable networks beyond it.
In order to announce routes to feeds by receivers routing messages must be sent to the unicast address of each feed. This assumes that receivers can communicate with feeds via regular connections (See Figure 3).
___ ___ \__\OO\__\ Satellite R1: Feed ^^ vv Network R2: Receiver ~/ \ / \ uplink / \ / \ / \ ---- / V ---- ---======>|R1| |R2|<=======--- ---- ---- /\ /\ || ----------------- || ====| regular |==== | connections | ----------------- Figure 3Moreover, both the feed's and receiver's interfaces connected to the Internet (regular connection) hardly ever belong to the same subnetwork (due to long distances between feeds and receivers). Routing protocol daemons check, in order to ensure security, that the sender's address of a message belongs to the same subnetwork as the interface which received it. Therefore routing information will not be taken into account since the packet will be rejected.
We have just described some problems that occur when trying to handle unidirectional links by common routing protocols. Specific problems related to RIP [1], OSPF [2] and DVMRP [3] are described in other documents. They are available at ftp://ftp-sop.inria.fr/rodeo/udlr/
However handling unidirectional links by standard routing protocols
(RIP, OSPF, DVMRP) is not trivial and currently not supported. It
requires changes in the current protocol specifications. Fortunately
these changes should not lead to new versions of routing protocols (RIP
and DVMRP) and should be transparent for routers not connected to
satellite networks.
Walid Dabbous
INRIA Sophia Antipolis
2004, Route des Lucioles BP 93
06902 Sophia Antipolis CEDEX France
Email : Walid.Dabbous@sophia.inria.fr
Phone : +33 93 65 77 18