[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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).


   This document defines the modifications which can be applied to DVMRP
   [rfc1075] which make the communication over asymmetric links

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

   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


   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


   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.


   [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]