Network Working Group Emmanuel Duros Internet-Draft Walid Dabbous INRIA Sophia-Antipolis November 1997 Supporting Unidirectional Paths in the Internet Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.nTermet (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction 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. 2. A new architecture The advantage of a satellite network is to provide high bandwidth services independent of the user's location over a large geographical area. 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. 2.1 Basic access Basic access corresponds to the case when each receiver has a satellite dish. The user's station is also connected to the Internet via a telephone/modem (e.g. PPP connection). This station has therefore two IP addresses, one belonging to the satellite subnet (SAT.x) and the other to the regular connection subnet (INT.y). See Figure 1. ___ ___ \__\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. 2.2 Subnetwork access Subnetwork access corresponds to the case when a subnet router has a satellite dish. See Figure 2. This router is then interconnected to the Internet via regular connections and to a subnetwork (such as R2 in Figure 2). ___ ___ \__\OO\__\ Satellite R1: Feed ^^ vv Network R2: Receiver / \ / \ uplink / \ / \ / \ ---- / V ---- ------------- ---======>|R1| |R2|<===>| Subnetwork|<===--- ---- ---- ------------- /\ /\ || || Server \/ || ---- ------------------------- || |S1|<==>| regular |<==/ ---- | connections | ------------------------- Figure 2: Subnetwork access In 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. 3. Solutions For the basic access and the subnetwork access we propose solutions in order to handle unidirectional links. 3.1 A dynamic routing Satellite networks are able to cover nationwide areas and therefore address very important sets of receivers. 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. 3.2 Basic Access The ARP protocol can not work properly, an ARP request sent by a feed to a host that belongs to the satellite network can not expect a response from receivers. 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. 3.3 Subnetwork access We consider here feeds and receivers as IP routers (R1 and R2 in Figure 3). The general problem is : how can a receiver announce routes to feeds since it can not communicate directly with them ? 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 can not 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 3 Moreover, 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://zenon.inria.fr/rodeo/udlr/ 4. Conclusion Improving user connectivity to the Internet at low cost seems possible, e.g. both for basic access or subntework access. 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. References [ASBD] V. Arora, N. Suphasindhu, J.S. Baras, D. Dillon, Asymmetric Internet Access over Satellite-Terrestrial Networks, http://www.isr.umd.edu/CCDS/research/AIA/sld001.htm [1] C. Huitema, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft- ietf-rip-unidirectional-link-00.txt, March 96 [2] E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft-ietf-ospf- unidirectional-link-00.txt, March 96 [3] W. Dabbous, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft- ietf-dvmrp-unidirectional-link-00.txt, March 96 [rfc823] David C. Plummer, "An Ethernet Address Resolution Protocol", Request For Comments (RFC) 826, November 1982. [rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", Request For Comments (RFC) 1723, Xylogics, Inc., November,1994. [rfc1583] J. Moy,"OSPF Version 2", Request For Comments (RFC) 1583, Proteon, Inc., March 1994. [rfc1075] S. Deering, C. Partridge, D. Waitzman, "Distance Vector Multicast Routing Protocol", November 1988. Author's address Emmanuel Duros INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email : Emmanuel.Duros@sophia.inria.fr Phone : +33 4 93 65 78 15 Walid Dabbous INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email : Walid.Dabbous@sophia.inria.fr Phone : +33 4 93 65 77 18