Supporting unidirectional links in the Internet Emmanuel Duros eduros@sophia.inria.fr I.N.R.I.A. Sophia Antipolis http://www.inria.fr/rodeo/personnel/eduros/ Walid Dabbous dabbous@sophia.inria.fr I.N.R.I.A. Sophia Antipolis 1 Introduction Many distributed applications may benet from a high bandwidth connection to the Internet. However, this requires high bandwidth links between remote sites. A low-cost solution to deliver such high bandwidth links over wide geographical areas is to use broadcast satellite networks as proposed in [ASBD]. However, this solution is based on low cost receivers with zero bandwidth return. The connection over the satellite link is therefore unidirectional. Current routing protocols in the Internet do not support unidirectional links. The goal of this paper is to describe changes in these protocols to support such links. 2 The satellite-based architecture A satellite network provides 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. A 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 oers a higher bandwidth. 2.1 Basic access Basic access corresponds to the case when each receiver has a satellite dish. The user station is also connected to the Internet via a telephone/modem (e.g. PPP connection). The station therefore has two IP addresses, one belonging to the satellite subnet (SAT.x) and the other to the regular connection subnet (INT.y). See Figure 1. SATELLITE NETWORK UPLINK R1: FEED H1: USER S STATION SAT.x R1 REGULAR CONNECTIONS H1 INT.y (PPP CONNECTION) S1 SERVER 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 local or a campus subnetwork. Thus, in this case, 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 Proposed solutions We next describe solutions to handle unidirectional links for both the basic access and the subnetwork access. First, note that satellite networks are able to cover large geographical areas and therefore to address very large sets of receivers. This makes a solution based on static routing, with routes manually set up and hardwired in feeds, inadequate as the number 2
SATELLITE NETWORK UPLINK R1: FEED R2, R3: ROUTERS R1 R2 SUBNET REGULAR CONNECTIONS R3 S1 SERVER Figure 2: Subnet access of receivers might be huge. Thus, we consider dynamic routing solutions. Furthermore, note that satellite transmissions can fade away and thus create black holes if routes are dened statically. However, dynamic routing solutions still need some work and some modications must be applied to routing protocols in order to handle unidirectional links for both basic and subnetwork access, as we illustrate next. 3.1 Basic Access The main problem with basic access is related to the ARP protocol [rfc826] because ARP assumes that links are bidirectional, and it expects a communication between directly connected hosts. Thus, it cannot work properly in Figure 1, since an ARP request sent by a feed to a host that belongs to the satellite network cannot expect a response from receivers. Another problem is related to routing protocols since a station (such as H1 in Figure 1) has two IP addresses : SAT.x (belongs to the satellite network) and INT.y (e.g. PPP connection to an Internet service provider). H1 send packets via the interface INT.y, but incoming packets should be routed to the default address SAT.x. 3.2 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 cannot 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], OSPF [rfc1583], and DVMRP [rfc1075] for multicast routing. 3
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 specic 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). UPLINK SATELLITE NETWORK R1: FEED R2: RECEIVER R1 R2 REGULAR CONNECTIONS Figure 3: Subnet access Moreover, both the feed's and receiver's interfaces connected to the Internet (using regular connections) 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. Specic problems related to RIP [1], OSPF[2] and DVMRP[3] are described in other documents. 3.3 An example: RIP RIP is one of the rst dynamic routing protocols used in the Internet. It was designed to work in networks where adjacent gateways communicate using the same link in both directions. Links may be asymmetric, e.g., have dierent delays and throughputs in dierent directions, but they have to be bidirectional. RIP is based on the exchange of routing information known as distance vectors between directly-connected routers. A router broadcasts routing messages on all its interfaces with a TTL of 1 (a routing message is never forwarded). Thus, receivers are unable to inform feeds of destinations they can reach. They must however send reports to the feeds to indicate the subnets for which they are ready to receive packets. RIP v2 allows the use of an authentication eld. We propose to associate a specic authentication code with the satellite network. All RIP packets sent over the satellite 4
network are authenticated. receivers. The handling of this code will be dierent by feeds and 3.3.1 Handling by receivers Upon reception of a RIP packet, receivers examine the authentication code. They note that this packet was sent by a satellite feed. They ignore all subnet-distance announces contained in this packet, but they add the source address of the packet [IP source] to the list of "potential feeds". At pseudo-regular intervals, the receivers send to the potential feeds a RIP packet that will be authenticated as a "satellite packet". This packet, however, is not sent to the regular multicast address of all the RIP routers. Instead, a copy of this packet is sent to the unicast address of each feed. Normally, sending a packet to the unicast address of each feed sets the IP source address of this packet to the IP address of the outgoing interface. In RIP specications, this latter is then used by feeds in their routing table to specify the next router along a path to a destination. But this address is not relevant because it does not belong to the subnets connected to the feeds. Therefore, when a receiver sends a RIP packet, the IP source address must be changed to the IP address of the interface which is connected to the unidirectional link. 3.3.2 Processing by feeds Processing of RIP packets by feeds is almost unchanged, except for the following : all packets sent over the multicast link are authenticated. all packets authenticated as satellite packets are processed even if they are routed by another interface. 4 Conclusion Improving user connectivity to the Internet at low cost seems possible, for both basic access or subnetwork access. However handling unidirectional links by standard routing protocols (RIP, OSPF, DVMRP) is not trivial and currently not supported, and it requires changes in the current protocol specications. 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. Note: This work has been presented at the udlr (unidirectional link routing) BoF session during the IETF meeting in Montreal (June 96). It is also possible to subscribe to the udlr mailing list sending a mail to udlr-request@sophia.inria.fr asking for subscription. 5
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/doc/draft-ietf-rip-unidirectional-link- 00.txt, March 96 [2] E. Duros, ftp://zenon.inria.fr/rodeo/udlr/doc/draft-ietf-ospf-unidirectional-link-00.txt, March 96 [3] W. Dabbous, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/doc/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. 6