If the distance-vector algorithm is used :

Transcription

1 An Experimental tudy of Asymmetric Routing Manish Karir y karir@isr.umd.edu University of Maryland College Park, MD Yongguang Zhang ygz@hrl.com HRL Laboratories Malibu, CA Abstract Traditionally, most routing protocol designs and their implementations assume that every link is bidirectional. This assumption is no longer true with direct broadcast satellite and other one-way communication link technology. In this research, we study the problems of dynamic asymmetric routing in an experimental approach. We have developed and implemented a method to adapt existing routing protocols and routing software to support networks with unidirectional links. 1 Introduction Recent advances in communication technologies has allowed the use of direct broadcast satellites (D) as a new networking media for the Internet. D has many unique benets: large geography coverage, high bandwidth, broadcast in nature, and low cost per terminal. It is especially suitable for applications that require rapid deployable infrastructure and/or oneto-many communications [8, 9]. everal commercial oerings have already been using D to provide internet connectivity, such as in the notable example of Hughes DirecPC network 1. Nevertheless, D brings unconventional networking characteristics to the Internet. Traditionally, communication links in the Internet are duplex and bidirectional. However, D is a one-way unidirectional media: communication can take place only from a small subset of nodes (called feeds) to rest of the nodes (called receivers). Feeds are equipped with large ground terminals that have adequate power to transmit data to the satellite for broadcast. Receivers only have small receive-only antenna; they can receive broadcast signal from the satellite but do not have the physical means to send signals back to the feeds. uch communication network is unidirectional in nature. We call such network link a UniDirectional Link (UDL). esides D, certain cable modem systems are also UDLs. y This work was performed under an Internship program at Hughes Research Labs (now HRL Labs), ummer UDL can be integrated into the Internet as a subnet technology, if there already exist other paths in the Internet from the receivers to the feeds. Internet routers can be congured to use the UDL to deliver IP datagrams in one direction and use the alternative path for the other direction. End-to-end Internet applications will not be aected because they need not know how the IP datagrams are delivered and what paths are used. We called such routing scenario asymmetric routing. As described in literatures [3, 8], asymmetric routing is not compatible with the current dynamic routing infrastructure in the Internet. In this paper, we will describe our experience in supporting dynamic routing in an asymmetric routing environment. We will demonstrate that a small x in the current routing software may be sucient to support asymmetric routing. 2 Problems with Dynamic Asymmetric Routing Most dynamic routing protocol implementations make the assumption that links are bidirectional. If a node receives a routing information packet on one interface, the routing software often assumes the source (sender of the packet) is automatically reachable via that same interface. This assumption breaks down in a network with UDLs. In a network with UDLs, a packet containing the routing information might be received via one link but it might not be possible to transmit packets on that link. 2.1 Unicast Many unicast routing protocols in the Internet use a distance-vector algorithm to compute dynamic routes [6]. efore this algorithm can be applied to a network with UDLs, special care must be taken to propagate the routing information. Figure 1 illustrates this implication using a simple 3-node network with a UDL. Router A receives routing information from both and C, however, router only receives routing messages from node C. As shown in 1

2 A 2 1 C If the distance-vector algorithm is used : A s route table : interface 1: dist=1 C: interface 2: dist=1 s route table A: interface 5: dist=2 C: interface 5: dist=1 C s route table A: interface 3: dist=1 : interface 4: dist=1 wrong sub-optimal Figure 1: Applying distance-vector to UDL the gure, the route tables computed by the distancevector algorithm are either incorrect or sub-optimal. The route table at A contains an incorrect entry for destination as no packets can be sent out of interface 1 (the receive-only interface of the UDL receiver). Moreover, the route table at contains a sub-optimal entry for destination A, via the regular bidirectional network which makes A two hops away, while the actual shortest path to A from is via interface 6 (the send-only interface of the UDL feed). Therefore the rst problem involving unicast routing in a network with UDLs is that of sending packets out of the UDL send-only interface at the UDL sender. As that interface does not receive any routing packets, it will conclude that no networks can be reached via that interface. This is incorrect as all networks on the UDL receiver side of the network are in fact reachable via that interface and the link. The second problem arises for packets sent from the UDL receiver to networks on the UDL sender side of the network. The UDL receiver receives routing information via the UDL. Therefore, it concludes that the shortest path back to the UDL sender, or any other network beyond the UDL sender is only one hop away and can be reached via the UDL receive-only interface. However, it is not possible to transmit packets from that interface as it is receive only. Therefore, all networks on the UDL sender side of the network become unreachable from all networks on the UDL receiver side of the network. The correct route table in the context of the unidirectional link would be one that causes packets sent from the UDL receiver to the UDL sender to go via the bi-directional network and packets sent from the UDL sender to the UDL receiver to go via the UDL. 2.2 Multicast everal multicast routing protocols in the Internet use reverse path forwarding [1] to derive their multicast forwarding tables. Their reliance on unicast routing to aid multicast forwarding makes the multicast routing protocols vulnerable to the same problems as unicast routing protocols. Figure 2 illustrates the problems with incorrect multicast routing in a network with UDLs. In the rst scenario, the multicast source is either at the UDL receiver, or on a network downstream to the UDL receiver. The shortest reverse path from the multicast receiver at the UDL sender or on a network upstream to the UDL feed, is via the UDL link. However, as the multicast data cannot be forwarded from the source to the receiver C via the UDL, therefore, the multicast receiver, will not be able to receive any multicast packets from the the multicast source. imilarly, in the second scenario where the multicast source is at the UDL sender or on a network upstream to the UDL sender, and the multicast receiver is downstream on the UDL receiver side, the shortest reverse path from the multicast receiver to the multicast sender will be via the bi-directional network, although the most ecient forwarding path for the multicast trac from the source to the receiver is via the UDL. Therefore in both cases, using the shortest reverse path scheme results in incorrect multicast forwarding tables. The correct multicast route table in the context of the unidirectional would forward multicast packets via the bidirectional network in the rst scenario and via the UDL in the second scenario. 3 Approach Over the past two years, several methods have been proposed to x the problems. For example, INRIA proposed a change to the routing protocols RIP and DVMRP to remove the protocol dependency on the bidirectionality of a link [3]. This however may require changes to all routers. Our approach to the problems is to hide the asymmetry by creating a virtual symmetric network. Figure 3 gives a high-level concept illustration. We use tunnels to create an illusion of a virtual bi-directional network for routing purposes. Therefore each UDL receiver, establishes a tunnel to the UDL feed via the existing bi-directional network. This tunnel carries encapsulated routing information directly from 2

3 Example network: The correct multicast tree from source should be: Receiver routing daemon virtual symmetric network UDL tunnel Internet (bi-directional) Feed routing daemon Figure 3: Approaching the UDL problem with a tunneling mechanism ut, the actual tree built by reverse path forwarding: A C (ecause the shortest path from C to is through, RPF stops C from accepting multicast from A) cenario 1: source at downstream UDL Example network: The optimal multicast tree from source should be: ut, the actual tree built by reverse path forwarding: A (ecause the shortest path from A to is actually through, RPF stops A from accepting multicast from ) cenario 2: source at upstream UDL Figure 2: Applying reverse path forwarding to UDL the UDL receiver back to the UDL feed. In this way the UDL sender and the UDL feed now have a virtual symmetric link between them through which they can exchange routing information. The data packets themselves do not ow through the tunnel, only the packets containing routing information go through the tunnel. 4 Experiments and Results We have implemented our approach towards asymmetric routing in Linux operating system. We have developed a set of procedures to adapt existing routing software to support networks with UDLs. We use a routing software system called GateD [4] to test out unicast routing with RIP protocol [5]. We use another routing software system called Mrouted [1] to test out multicast routing with DVMRP protocol [7]. The solution requires additional network setup at UDL feeds and receivers, new congurations for the GateD and Mrouted, and a minor modication of the Mrouted software. The procedures have been tested successfully using an experimental UDL network at HRL Labs. 4.1 The UDL Network Testbed Figure 4 describes the base network topology of our experimental network for dynamic asymmetric routing. It consists of many PCs acting as routers/hosts and several Ethernet segments to connect them. The base network setup consists of a UDL subnet among three routers (A,, C). Router C on the UDL has send-only capability and it is referred to as the UDL feed, Router A and router are on the receiveonly side of the UDL and they are referred to as the UDL receivers. Router C is on the send-only side of UDL and it is referred to as the UDL feed. In the example network setup, Router A's receive-only 3

4 the UDL network tunnels E (u).2 (u).3 (v) C A H Ethernet hub F (b).1 (b).4 (u).5 (v).2 G D.3 (b) Higher metrics emulates multi-hop Host/Router Figure 4: Testbed network conguration interface is denoted as A.u ( ), router 's receive-only interface is.u ( ), and router C's send-only interface is C.u ( ). As the UDL subnet is implemented by a bidirectional ethernet segment, we emulate the UDL feature by running rewall utility on each UDL receiver (A and ). The rewalls are congured to prevent any packets from being sent out of the the UDL receive-only interfaces (A.u and.u), which in eect provides us with a UDL where packets can only be sent from a UDL feed to a UDL receiver. In addition, router A,, C all have other bidirectional interfaces, denoted as A.b ( ),.b ( ), and C.b ( ) respectively. Router D acts as our emulated multihop bidirectional network. Router/host E, F, G, H are nodes that communicate with one other over this internetwork. All PCs run Linux They also run GateD (gated, version 3.5) and Mrouted (mrouted, version 3.8) software for dynamic routing purpose. In addition to the base topology shown in the gure, we can add and remove hosts and routers as required to demonstrate the various network topologies that we are interested in. We also supply articial routes in the edge routers (E, F, G, H) to observe their propagation in a network with UDLs. 4.2 The IP-Tunnel Device The cornerstone of our approach is the IP tunnel from a UDL receiver to a UDL feed. The routing software (such as GateD and Mrouted) will use this tunnel to pass routing information. The goal is to make the tunnel as transparent as possible, so that we make little change to the routing software operation. Fortunately, many Unix operating systems include some type of virtual network devices call IP tunnels. They behave like normal network device (such as Ethernet) but deliver IP datagrams by IP-in-IP encapsulation with congurable destination address in the outer packet. In Linux, we use the tunl0 device. In the example of our UDL test network (Figure 4), we need to create a virtual tunnel interface from router A to router C, and another one from router to router C. For example, the following Linux commands in router A establish the tunnel: A> ifconfig tunl0 inet A.v -pointopoint \ allmulti up A> route add -host C.u gw C.b dev tunl0 where A.v denotes the IP address assigned to the tunnel device ( ). The rst line sets up the network interface, the second line instructs that the route to UDL feed (C.u) is via the tunnel (tunl0) to UDL feed's bidirectional interface (C.b). oth lines create a one-way tunnel from the UDL receiver to the feed. The IP address assigned to the tunnel device should be from the same subnet as the UDL receiver interface, so that logically they can be treated as the same by the UDL feed. For example, when the routing software (at router A) sends out a message to the UDL feed (router C), it will carry the tunnel device IP address (A.v) as the source address. If the feed's routing software uses this address (A.v) to reply, the reply messages will go out the UDL send-only interface (C.u) because both are from the same subnet. However, the reply address (A.v) has no MAC entry 4

5 because the virtual tunnel interface is not a physical device (unlike the receive-only interface A.u). To amend this, we set up an articial ARP entry at the UDL feed so that the tunnel IP address (A.v) has the same MAC address as its physical counterpart (A.u). Any messages from the UDL feed to the UDL receiver using the tunnel IP address (A.v) will be received by the physical receive-only interface (A.u). This task can be easily accomplished via a simple script at router C: C> arp -s A.v `arp A.u` C> arp -s.v `arp.u` During the implementation, we did run into a minor problem with the TTL semantics in IPIP encapsulation. In Linux, TTL of an outer IPIP datagram is copied from the inner IP packet. This may not be desirable in all cases. Many routing software communicates with their immediate neighbors only; they sends out routing information messages with TTL value 1. When these messages are sent using the tunnel device, the outer encapsulation datagrams also have a TTL value of 1. They will always get dropped at the next hop router, never making to the tunnel endpoint (because the tunnel from UDL receiver to UDL feed through the bidirectional path is always longer than one hop). To overcome this deciency, we modied the Linux tunnel driver to implement a dierent semantics: when TTL of the inner datagram is 1, the outer TTL is set to MAXTTL (256). This ensures that the routing messages will get to the other end of the tunnel irrespective of the number of intermediate routers that the tunneled packet has to go through. 4.3 Experiments with RIP (GateD) The RIP implementation in GateD works as follows. GateD periodically sends routing update messages on all interfaces. The routing update is in form of \distance-vector" { the number of hops to reach each stub network in the Internet. Mrouted maintains a unicast route table detailing the next hop address for each such stub network. When GateD receives a routing update message from another GateD, it adds the cost metric of the receiving interface (usually 1) to the distance-vector and merges it into the its unicast route table. GateD then updates the kernel route table Unicast from feed to receiver In order to create the illusion of a virtual bidirectional network around the UDL, we have to use the tunnel to carry RIP routing updates from the UDL receiver to the UDL feed so that they arrive with unmodied route metrics. With a tunnel set up as described above, GateD can recognize the tunnel interface and send out RIP protocol messages on the interface. The following line is added to gated.conf at router A so that the RIP messages are addressed from A.v to C.u: sourcegateways C.u These messages will be automately encapsulated by the tunnel interface in IPIP packets from A.b to C.b. They will appear at the UDL feed with unmodied metrics as desired. Upon receiving the RIP messages, the UDL feed (router C) will recognize that the shortest path to hosts downstream the UDL receiver side of the network is via the RIP message sender (i.e. A.v). The UDL feed (Router C) will then start forwarding IP datagrams downstream UDL, using A.v as the next hop. Using the ARP entry as described previously, we map these packets to the correct actual interface (A.u) that these packets must arrive. With the setup above the route table obtained at the UDL feed will be correct in the UDL context, and packet from the UDL feed to the UDL receiver will be forwarded via the UDL Unicast from receiver to feed Normally, when a UDL receiver receives RIP routing update messages with a small metrics via the UDL interface, it concludes that the UDL receive-only interface would be used to reach back to the UDL feed and some upstream networks. To prevent this wrongful setting, the GateD at the UDL feed must use a large metrics when it send RIP update messages to the UDL subnet. This metrics should be larger than the sum along the bidirectional path from the UDL feed to the UDL receiver, so that the UDL receiver can logically conclude that the best path to the UDL feed or upstream networks is through the bidirectional network interface. This can be implemented easily by changing the metrics value in UDL feed's GateD conguration le, for example, the following line at router C's gated.conf: interface C.u... metricout 15 In practice, one can also instruct UDL feed's GateD not to send out RIP information for the UDL subnet. With this minor conguration setup, the GateD were able to generate correct route tabls at all routers, and we were able to receive packets at 5

6 the UDL feed, from the UDL receiver, via the bidirectional network. 4.4 Experiments with DVMRP (Mrouted) Multicast routing in Mrouted works as follows. First, Mrouted relies on the exchange of periodic DVMRP probe messages to discover neighboring multicast enabled routers. Once it receives probes from such neighbors on one of its interface, it will send them periodic routing update messages. The routing update is in form of \distance-vector" { the number of hops to reach each stub network in the Internet. Mrouted maintains a unicast route table (independent from other unicast routing software such as GateD, or the Unix kernel unicast route table). When it receives a distance-vector from one interface, it adds the cost metric of this interface (usually 1) to the distancevector and merges it into the unicast route table. To forward a multicast datagram of a given source, Mrouted rst performs the \reverse path forwarding" algorithm { consulting its unicast route table to identify the interface leading to the shortest path to the source. Mrouted then inserts the interface into the kernel multicast forwarding table { from now on the kernel will accept multicast datagrams of that source from that particular interface and from that interface only. However, this multicast forwarding procedure and the above neighbor discovery procedure have a few problems in the UDL network Neighbor discovery in a UDL network For a UDL feed to recognize a UDL receiver as a neighboring multicast router, the UDL feed must receive DVMRP probes from the UDL receiver via the UDL interface. For this purpose we use the same virtual tunnel device (tunl0) as described previously. Mrouted at the UDL receiver will recognize this device as a separate interface and it will start generating probe messages on the interface. These messages will be automatically tunneled by the interface to the UDL feed. Upon receiving the DVMRP messages, Mrouted at the UDL feed will conclude that it has a peer on the UDL receiver at the UDL subnet. It will start generating DVMRP routing update messages on the UDL send-only interface. On the other direction, the UDL feed sends probe messages on its send-only interface. Upon receiving the probe and recognizing the UDL feed as a peer, a UDL receiver will send DVMRP routing update messages to the UDL feed. These messages will also be automatically tunneled to the feed by the same tunnel interface Multicast from feed to receiver When a source upstream the UDL subnet sends multicast to a host downstream the UDL subnet, multicast datagrams may be forwarded by the UDL feed on to the UDL subnet and accepted by the UDL receivers for further routing downstream. However, a glitch in the current Mrouted implementation prevents such multicast datagrams to be accepted by the UDL receivers. In a UDL receiver, Mrouted considers the tunnel interface a separate interface from the UDL receiveonly interface. When Mrouted determines that the shortest path to the source is through the UDL feed, it wrongfully determines that the virtual tunnel interface is the one that leads to the feed, according to the unicast route table and our tunneling set up. Therefore, Mrouted will set a wrong entry in kernell's multicast forwarding table, causing it to reject the multicast datagram from the UDL receive-only interface. To correct this problem, Mrouted must instruct the kernel to accept multicast from the receive-only interface when the reverse path points to the tunnel interface. To accomplish this we introduce a new construct called udlints in Mrouted's conguration le (mrouted.conf). It associates the tunnel interface with the receive-only interface. For example, the following line is added to mrouted.conf at router A: udlints A.u A.v A minor modication to the Mrouted source code allows it to add the proper setting in the kernel multicast forwarding table. Multicast datagrams on the UDL subnet sent by the UDL feed are now accepted at the UDL receive-only interface for further routing by the UDL receiver Multicast from receiver to feed When a source downstream the UDL subnet sends multicast to a host upstream the UDL subnet, multicast datagrams may pass both a UDL receiver and the feed, through a path over the bidirectional internetwork. Great care must be taken in both the UDL receiver and the UDL feed so that the virtual tunnel interface will not be used for actual multicast trac. 6

7 In the UDL feed, DVMRP routing updates are received at both interfaces: from the UDL send-only subnet (through tunneling), and from the normal bidirectional network. However, if DVMRP routes received from the tunnel carries a smaller metric, the UDL feed may consider that the shortest path to a source downstream the UDL subnet is at the UDL send-only interface. In this case, the UDL feed will wrongfully reject the multicast datagrams coming from the bidirectional network. To correct this problem, we need to set a large metric at UDL feed's UDL send-only interface. This metrics should be larger than the sum along the bidirectional path from the UDL receiver to the UDL feed. For example, we use the following denition in the mrouted.conf le in UDL feed (router C): phyint C.u metric Conclusion We have implemented our tunneling approach towards asymmetric routing in Linux operating system, and tested it in an experimental UDL network. The results show that, with the help of a virtual IPtunneling interface, existing routing protocols and routing software can be easily adapted to support a network with unidirectional links. This tunneling approach has been adopted by IETF (Internet Engineering Task Force) UDLR (Unidirectional Link Routing) working group as the short term solution towards the asymmetric routing problem in the Internet [2]. [4] Gate Daemon, [5] C. L. Hedrick. Routing information protocol, June RFC 1058, the Internet Engineering Task Force. [6] Christian Huitema. Routing in the Internet. Prentice Hall, [7] D. Waitzman, C. Partridge, and. Deering. Distance vector multicast routing protocol, November RFC 1075, the Internet Engineering Task Force. [8] Yongguang Zhang and on Dao. Integrating direct broadcast satellite with wireless local access. In Proceedings of the First International Workshop on atellite-based Information ervices, pages 24{29, November [9] Yongguang Zhang, Dante DeLucia, o Ryu, and on Dao. atellite communications in the global Internet: Issues, pitfalls, and potential. In INET'97, June References [1]. Deering and D. Cheriton. Multicast routing in datagram internetworks and extended LANs. ACM Transactions on Computer ystems, 8(2):85{110, May [2] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, and Y. Zhang. A link layer tunneling mechanism for unidirectional links, IETF internet-draft, [3] Emmanuel Duros and Walid Dabbous. upporting unidirectional links in the Internet. In Proceedings of the First International Workshop on atellite-based Information ervices, November