Network Working Group Emmanuel Duros Internet-Draft Walid Dabbous INRIA Sophia-Antipolis November 1997 Handling of unidirectional links with DVMRP 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.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines the modifications which can be applied to DVMRP [rfc1075] which make the communication over asymmetric links feasible. 1. Introduction DVMRP is a distance-vector-style routing protocol for routing multicast datagrams through the internet. It was designed to work on networks where adjacent gateways routing multicast datagrams communicate using the same link in both directions. In case links are unidirectional, DVMRP can not be used without modifications. 2. Overcoming DVMRP restrictions Duros & Dabbous [Page 1] Internet Draft Unidirectional links and DVMRP March 1996 A satellite network comprises two sets of stations, feeds that can both send and receive multicast packets, and receivers that can only receive packets. Feeds must be allowed to forward over the satellite links the multicast packets which are bound to subnets accessible through other feeds or through receivers. Receivers will never send any packet via the satellite link. They must however send routing messages to the feeds to supply routing information, recently changed routes or responses to requests. If the network included only feeds, DVMRP could be used unchanged. Usage by a mix of receivers and feeds requires some extensions. 3. Proposed solution In our example we assume that G1 and G2 (Gateways) are connected to symmetric and asymmetric networks (See Figure 1) and support multicast routing. G3 and G4 also support multicast routing and are connected to symmetric networks. route N1 ---- N2 ---- ----<==========>|G3|<==--- ---======>|G1| ===================> |G2| ---- ---- ---- update msg ----<===>|G4|<==-- /\ /\ ---- || ------------------ || ====| regular |==== N3 | connections | N4 ------------------ Figure 1 G1 will send routing messages to G2 multicast to address 224.0.0.4.. G1 will never receive messages from G2 via route N1, DVMRP must be modified to take into account that asymmetry. 3.1. Adding information to DVMRP datagrams DVMRP datagrams are composed of two portions: a small, fixed length IGMP header, and a stream of tagged data. The stream is composed of commands. We suggest to modify a command in order to provide a way to authenticate a route taken by a datagram as part of the satellite Duros & Dabbous [Page 2] Internet Draft Unidirectional links and DVMRP March 1996 network. The Flag0 command provides a way to set a number of flags. Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 5 | | value | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Meaning of bits in value: Bit 7: Destination is unreachable. Bit 6: Split Horizon concealed route. Default: All bits zero. Bits 0 to 5 are unused, for our needs we propose to set the bit 5, this specifying that the link is unidirectional. By default bit 5 would be unset. Any DVMRP datagram sent by multicast feeds over the satellite network will be authenticated. Any multicast router connected to the satellite network (feeds and receivers) have to support that functionality when they process routing datagrams. Other multicast routers will simply ignore this extra flag and the process of DVMRP datagram will not be affected. 3.2. Handling by receivers Upon reception of a DVMRP packet, receivers examine the flag0 command and note that this packet was sent by a satellite feed (bit 5 set). They add the packet address [IP source] to a list of "potential feeds". Receivers behave "as if" their virtual interface connected to the satellite network can transmit packets. This way, the shortest reverse path tree can be computed by the receivers with the metric associated to the satellite link. At pseudo-regular intervals, receivers will send to the feeds a DVMRP packet. This packet, however, will not be sent to the multicast address of the feed. A copy of this packet will be sent to the unicast address of each feed found in the list of "potential feeds" through regular connections. Duros & Dabbous [Page 3] Internet Draft Unidirectional links and DVMRP March 1996 Every FULL_UPDATE_RATE seconds routers normally send out DVMRP messages to all of their virtual interfaces with all of their routing information. Receivers will propagate routing information about the destination addresses "reachable" via the virtual interfaces connected to the satellite network. Thus, routers (i.e. G3 and G4, see Figure 1) can compute the shortest reverse path tree to the source address of a multicast packet even if there is no real path. This procedure assumes that there is another route, beside the satellite link, by which the receiver can send packets to the feed (See Figure 1). 3.3. Processing by feeds Any routing message sent over the multicast link (satellite network) is authenticated adding the Flag0 command and setting the bit 5. All incoming unicast packets are processed even if they were not tunneled or sent to a multicast address. References [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 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 93 65 77 18 Duros & Dabbous [Page 4]