Distance Vector Multicast Routing Protocol
RFC 1075

Document Type RFC - Experimental (November 1988; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1075 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        D. Waitzman
Request For Comments: 1075                                  C. Partridge
                                                                 BBN STC
                                                              S. Deering
                                                     Stanford University
                                                           November 1988

               Distance Vector Multicast Routing Protocol

1. Status of this Memo

   This RFC describes a distance-vector-style routing protocol for
   routing multicast datagrams through an internet.  It is derived from
   the Routing Information Protocol (RIP) [1], and implements
   multicasting as described in RFC-1054.  This is an experimental
   protocol, and its implementation is not recommended at this time.
   Distribution of this memo is unlimited.

2. Introduction

   A draft standard for multicasting over IP networks now exists [2],
   but no routing protocols to support internetwork multicasting are
   available.  This memo describes an experimental routing protocol,
   named DVMRP, that implements internetwork multicasting.  DVMRP
   combines many of the features of RIP [1] with the Truncated Reverse
   Path Broadcasting (TRPB) algorithm described by Deering [3].

   DVMRP is an "interior gateway protocol"; suitable for use within an
   autonomous system, but not between different autonomous systems.
   DVMRP is not currently developed for use in routing non-multicast
   datagrams, so a router that routes both multicast and unicast
   datagrams must run two separate routing processes.  DVMRP is designed
   to be easily extensible and could be extended to route unicast
   datagrams.

   DVMRP was developed to experiment with the algorithms in [3].  RIP
   was used as the starting point for the development because an
   implementation was available and distance vector algorithms are
   simple, as compared to link-state algorithms [4].  In addition, to
   allow experiments to traverse networks that do not support
   multicasting, a mechanism called "tunneling" was developed.

   The multicast forwarding algorithm requires the building of trees
   based on routing information.  This tree building needs more state
   information than RIP is designed to provide, so DVMRP is much more
   complicated in some places than RIP.  A link-state algorithm, which
   already maintains much of the state needed, might prove a better
   basis for Internet multicasting routing and forwarding.

Waitzman, Partridge & Deering                                   [Page 1]
RFC 1075       Distance Vector Multicast Routing Protocol  November 1988

   DVMRP differs from RIP in one very important way.  RIP thinks in
   terms of routing and forwarding datagrams to a particular
   destination.  The purpose of DVMRP is to keep track of the return
   paths to the source of multicast datagrams.  To make explanation of
   DVMRP more consistent with RIP, the word "destination" is used
   instead of the more proper "source", but the reader must remember
   that datagrams are not forwarded to these destinations, but originate
   from them.

   This memo is organized into the following sections:
           - A description of DVMRP is presented.
           - Tunnels are explained.
           - The routing algorithm is shown.
           - The forwarding algorithm is shown.
           - The various time values are listed.
           - Configuration information is specified.

   This memo does not analyze distance-vector routing, nor fully explain
   the distance-vector algorithm; see [1] for more information on these
   topics.  The process or processes that perform the routing and
   forwarding functions are called "routers" in this memo.

3. Protocol Description

   DVMRP uses the Internet Group Management Protocol (IGMP) to exchange
   routing datagrams [2].

   DVMRP datagrams are composed of two portions: a small, fixed length
   IGMP header, and a stream of tagged data.

   The fixed length IGMP header of DVMRP messages is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Type  |  Subtype      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The version is 1.

   The type for DVMRP is 3.

   The subtype is one of:

   1 = Response; the message provides routes to some destination(s).
   2 = Request; the message requests routes to some destination(s).
   3 = Non-membership report; the message provides non-membership
       report(s).

Waitzman, Partridge & Deering                                   [Page 2]
RFC 1075       Distance Vector Multicast Routing Protocol  November 1988

   4 = Non-membership cancellation; the message cancels previous
       non-membership report(s).
Show full document text