Operation of the Distance Vector Multicast Routing Protocol (DVMRP)

DVMRP uses the broadcast-and-prune method to build a separate source-based tree for every multicast source. It uses a variant of RIP to discover the shortest path to the source ”hence the name Distance Vector Multicast Routing Protocol. Each multicast tree is maintained dynamically by pruning and grafting branches as group members leave and join the group.

DVMRP uses seven packet types:

• DVMRP Probe

• DVMRP Report

• DVMRP Prune

• DVMRP Graft

• DVMRP Graft Acknowledgement

• DVMRP Ask Neighbors2

• DVMRP Neighbors2

All the packets have a destination address of 224.0.0.4, the reserved All DVMRP Routers address (see Table 5-1). The uses of the various packet types are described in the following sections, and the section "DVMRP Packet Formats" gives a detailed description of the packet formats.

There are several versions of DVMRP. Version 1 is described in RFC 1075,[8] and version 3, the most recent version, is described in an Internet draft.[9] This chapter describes version 3 of the protocol. You should be aware that earlier versions of DVMRP vary significantly both in functionality and in packet formats. While an effort is made in this section to note differences between DVMRPv3 and some earlier versions, coverage of all the differences would make the section unacceptably long and complex. In this section, "DVMRP" is understood to mean DVMRPv3 unless otherwise noted. If you are working with an earlier version or have an interest in the differences, you should read RFC 1075, the relevant mgated documentation, or the software documentation of the router supporting the earlier version.

NOTE

Most routers running DVMRP are found on the MBone, and most of those run a version of mrouted or mgated.

Cisco IOS Software does not support a full implementation of DVMRP; however, it does support connectivity to a DVMRP network such as the MBone.

Neighbor Discovery and Maintenance

The first task when a DVMRP router comes online is to discover its neighbors using Probe packets. Each Probe packet contains the following information:

• A set of flags describing the originating router's DVMRP capabilities. These flags are used to determine backward compatibility with earlier versions of the protocol.

• A generation ID, which is used to detect a change in a neighbor state.

• A list the addresses of neighbors from which the originating router has received probes.

Out of all this information, the most fundamental is the list of neighbor addresses. When a DVMRP router receives a Probe packet, it records the address of the originating router and the interface on which the probe was received. Recall that the receiving router never forwards any packet with a destination address from the 224.0.0.0/24 range. Both because the Probe packet has a destination address of 224.0.0.4, and because it is originated with a TTL of 1, the receiving DVMRP router knows that the originator is a directly connected neighbor. When the router sends its own probes, it lists all the neighbor addresses it has learned on the subnet on which the probe is sent. When a router sees its own IP interface address in a neighbor's probe, it knows that two-way communication is established with the neighbor.

After a neighbor has been discovered , probes also are used as keepalives . Probes are sent at 10-second intervals, and a neighbor is declared dead if a probe is not received from it within 35 seconds.

Earlier versions of DVMRP do not use Probe packets. Instead, they discover neighbors upon reception of route advertisement messages from their neighbors.

During the neighbor discovery process, earlier versions of DVMRP would, when discovering more than one router on a subnet with group members, select a designated router. The designated router, which is the only router that sends multicast session packets and IGMP queries onto the subnet, is the router with the lowest IP address on that subnet. DVMRPv3 determines a designated router through the IGMPv2 querier election process rather than by reading the source IP addresses of received route advertisement messages.

As you learned previously, a broadcast-and-prune multicast routing protocol must store prune states. If the router is restarted, however, it cannot know what prunes have been sent or received. It may also be slow to reestablish multicast forwarding if it has to wait for the next regularly scheduled route update. The generation ID, a nondecreasing 32-bit number derived from some changing reference such as a time-of-day clock, is designed to alleviate these problems. When a DVMRP router restarts, its generation ID changes. When neighbors detect this changed number in the router's Probe messages, they flush all prune information previously received from the router. They also immediately send a copy of their routing table to the neighbor. Multicast data will again flow to the restarted router due to the cleared prune information, and the router must again prune itself or remain a part of the tree.

The DVMRP Routing Table

The primary purpose of the DVMRP routing table is to determine, for each multicast source, the upstream interface for that source. As explained earlier in the chapter, this process is important for loop avoidance ; if a packet is received from a source on any interface other than the upstream interface ”the interface closest to the source ”the packet must be discarded.

DVMRP uses a variant of RIP to advertise the complete routing table plus all directly connected multicast-enabled subnets. The routes are advertised in DVMRP Report messages, sent to every neighbor using the All DVMRP Routers address 224.0.0.4. Route updates are sent every 60 seconds, known as the Route Report Interval. The exception to this rule occurs when a new neighbor is discovered by the probe process. In this case, the routing table is immediately unicast to the new neighbor. Flash updates also can be used to shorten reconvergence times.

If a route is not updated within 140 seconds, the route expiration time, the route is put into holddown for two report intervals (120 seconds). During this time, the route is advertised with a metric of infinity; when the holddown time expires , the route is removed from the routing table.

The metric associated with each route is hop count, with infinity defined as 32 hops. However, a route may have a metric in the range of 1 through 63. The metric values 1 through 31 indicate reachable sources; the values 33 through 63 are used to indicate route dependencies.

For pruning to work correctly, a DVMRP router must be aware of the downstream neighbors that depend on it to forward packets from particular multicast sources. For each source network, a downstream router signals a route dependency to an upstream router by sending a poison reverse route to the upstream router. The poison reverse route contains a metric that is the advertised metric plus infinity. Suppose, for example, that router A advertises network 172.16.1.0/24 to router B, with a hop count of 3. Router B determines that router A is the upstream router toward this subnet. Router B must signal to router A that it is dependent on router A for multicast traffic from sources on this subnet. Therefore, router B advertises 172.16.1.0/24 to router A with a metric of 35 (3 + 32). Router A recognizes this advertisement as a route dependency.

Yet another function of the DVMRP routing table is the selection of a designated forwarder. When multiple upstream routers are connected to a multiaccess network, as in Figure 5-24, only the designated forwarder forwards multicast packets downstream. This prevents multiple copies of the same packets from being forwarded onto the multiaccess network. When two or more routers on a multiaccess network exchange routes, they can tell which of the routers is closest to the source. That router is the designated forwarder for that source network. In Figure 5-24, upstream router B would be the designated forwarder for the source shown, because it is only one router hop from the source; upstream router A is two hops away. If the routers are an equal distance from the source, the router with the numerically lower IP address on the shared network becomes the designated forwarder.

Figure 5-24. When Multiple Upstream Routers to a Source Are Connected to the Same Data Link, a Designated Forwarder Is Elected

DVMRP Packet Forwarding

When a router first receives a multicast packet from a particular source, an RPF check is performed, using the routing table, to verify that the packet arrived on the upstream interface for the packet's source. If the packet arrived on any other interface, it is dropped. If the packet did arrive on the upstream interface, the (S, G) pair is recorded in a forwarding table, and a copy of the packet is forwarded to all downstream dependent neighbors. The router also uses IGMP to query for group members on each of its leaf networks ”that is, networks with no neighbors. A copy is forwarded to any leaf networks that contain group members.

If there are no downstream dependent neighbors, and no leaf networks with group members, the router sends a prune message to the upstream router. If the upstream router also has no local group members, and if it has received a prune message from all of its downstream dependent neighbors, it sends a prune message of its own to its upstream neighbor. In this way, the multicast tree is dynamically pruned until only branches leading to active group members remain.

A prune message contains a prune lifetime, which indicates how long an upstream router should hold a prune state before resuming the forwarding of packets from the source in question to the pruned router. The default prune lifetime is 2 hours. If the router receiving a prune is itself sending a prune upstream, the prune lifetime is set to the minimum of either 2 hours or the remaining lifetimes of any downstream prunes received for the same (S, G) pair.

As discussed previously, a host can signal its desire to join a multicast group at any time by sending an IGMP membership report message to its local router. If that router has previously pruned itself from the tree delivering packets from that group, it must now graft itself back onto the tree. The router does this by sending a DVMRP Graft message upstream. Grafts are sent hop by hop upstream until an active branch of the multicast tree is found.

If a router sends a graft message and does not begin receiving traffic for the requested group, it must have a mechanism by which it knows whether the source has stopped transmitting, or the graft has been lost. Therefore, at each hop, an upstream router acknowledges the receipt of a Graft message by sending a Graft Ack message to its downstream neighbor. The originator of the graft also sets a Graft Retransmission timer; if a Graft Ack is not received before the timer expires, another Graft message is sent, and the timer is reset. The initial period of the Graft Retransmission timer is 5 seconds, and subsequent periods are calculated using a binary exponential backoff algorithm.

DVMRP Message Formats

The IP header of a DVMRP packet specifies protocol number 2. Note that this is the same protocol number used by IGMP, a legacy of DVMRP's beginnings as a subset of that protocol. This section describes DVMRPv3 formats; for a description of earlier formats, see RFC 1075 or other appropriate documentation.

DVMRP Message Header

Figure 5-25 shows the format of the DVMRP header, which begins every DVMRP message.

Figure 5-25. The DVMRP Message Header

The fields for the DVMRP message are described as follows :

• Type is the IGMP type number, which is set to 0x13 for all DVMRP messages. RFC 1075 specifies a separate 4-bit Version field and 4-bit Type field in this position, in which the version is 0x1 and the type is 0x3. Note that the resulting 8 bits of the version 1 header is 0x13, the same as version 3, making version 3 backward-compatible . The actual DVMRPv3 version is specified in the Major Version field.

• Checksum is a standard IP-style checksum, using a 16-bit one's complement of the one's complement of the DVMRP message.

• Minor Version and Major Version are set to 0xFF and 0x03, respectively, for all DVMRPv3 messages.

• Code specifies the DVMRPv3 message type. Table 5-7 shows the possible values of the code field and the corresponding message types.

Table 5-7. DVMRP Message Types by Code Value

Code	DVMRP Message Types
1	Probe
2	Report
3	Ask Neighbors
4	Neighbors
5	Ask Neighbors 2
6	Neighbors 2
7	Prune
8	Graft
9	Graft Ack

The Ask Neighbors (code 3) and Neighbors (code 4) messages are obsoleted by the Ask Neighbors 2 (code 5) and Neighbors 2 (code 6) messages. None of these messages have yet been discussed; they are used by such diagnostic commands as mrinfo and mstat. They are discussed in this context in the troubleshooting section of Chapter 6, "Configuring and Troubleshooting IP Multicast Routing."

DVMRP Probe Message Format

DVMRP Probe messages serve four functions:

• They allow routers to locate each other by listing all DVMRP-speaking routers detected by the originating router on the originating interface.

• They provide a means for DVMRP routers to communicate their capabilities to each other.

• They enable the selection of a designated forwarder when there are multiple paths to a downstream group member.

• They provide a keepalive function by being transmitted every 10 seconds. If a probe is not heard from a neighbor within 35 seconds, the neighbor is declared dead.

Figure 5-26 shows the format of the probe message.

Figure 5-26. The DVMRP Probe Message

The fields for the DVMRP Probe message are described as follows:

• Capabilities uses eight of the reserved bits in the header for capability flags. The Probe message is the only DVMRP message to modify the header fields. Table 5-8 lists the capabilities flags and their meanings. If the flag is set to 1, the corresponding capability is supported by the originating router.

Table 5-8. DVMRP Capabilities Flags

Bit	Flag	Capability
	L	This router is a leaf router.
1	P	This router understands pruning.
2	G	This router sends Generation IDs.
3	M	This router handles Mtrace requests .
4	S	This router supports the DVMRP MIB.
5	N	This router understands netmasks appended to Prune, Graft, and Graft Ack messages.
6, 7	U	Unused.

• Generation ID is a nondecreasing 32-bit number used for detecting when a router has restarted, without having to wait for an entire report interval to pass. When a change in the generation ID is detected, any prune information from the originating router is declared invalid and is flushed. If the prune information has been sent upstream, a Graft message is sent. The result of this process is that the restarted router is treated as a new router on multicast trees, and the broadcast-and-prune process is begun anew.

• Neighbor Address lists the neighbors from whom the originating router has received Probe messages on the originating interface.

DVMRP Route Report Message Format

Route Report messages, depicted in Figure 5-27, are sent every 60 seconds. The Route Report consists of a list of one or more netmasks, and for each netmask, a list of one or more source network addresses and associated metrics corresponding to the netmask . Although the lengths of the source networks in Figure 5-27 are all 3 octets, in reality the lengths may vary, as described in this section.

Figure 5-27. DVMRP Route Report Message Format

The fields for the DVMRP Route Report Message are defined as follows:

• Mask is a netmask. The first octet of the netmask is always assumed to be 255, so only the last 3 octets are included in the Mask field. Note that this assumption means that DVMRP routes can never be aggregated into addresses with a prefix length less than 8.

• Source Net is a source network address whose prefix length corresponds to the netmask preceding it. The length of the Source Net field varies according to the netmask. For example, if the netmask field is 255.0.0, the field is describing a mask of 255.255.0.0 (remembering that the first octet is assumed to be 255). The Source Net fields following such a netmask are all 2 octets, corresponding to the prefix length specified.

  A default route is specified with a netmask of 0.0.0 and a 1-octet source net of 0. DVMRP routers always interpret this as 0.0.0.0/0, not 0.0.0.0/8.

• Metric is the sum of the interface metrics between the router originating the report and the source network. The metric is a hop count, with 32 signifying infinity. However, the full range of the metric value is 1 “63. As described in the section "The DVMRP Routing Table," a router signals a dependency to an upstream router by advertising a poison reverse route in which the metric is the received metric plus infinity (32). Therefore, metric values between 33 and 63 indicate a downstream dependency.

DVMRP Prune Message Format

Figure 5-28 shows the format of the Prune message.

Figure 5-28. The DVMRP Prune Message Format

The fields for the DVMRP Prune message are defined as follows:

• Source Host Address is the IP address of the originating host.

• Group Address is the IP address of the group to be pruned.

• Prune Lifetime is the time, in seconds, that the upstream neighbor is to keep the prune. This value is either the minimum remaining lifetime of all downstream prunes received for the group address or, if there are no downstream prunes, the default prune lifetime of 2 hours.

• Source Network Mask is the netmask of the source network of the group to be pruned. This field is optional, and it is included only if the upstream neighbor has indicated in its Probe messages that it understands netmasks.

DVMRP Graft Message Format

Figure 5-29 shows the format of the Graft message.

Figure 5-29. The DVMRP Graft Message Format

The fields for the DVMRP Graft message are defined as follows:

• Source Host Address is the IP address of the originating host.

• Group Address is the IP address of the group to be grafted.

• Source Network Mask is the netmask of the source network of the group to be grafted. This field is optional, and it is included only if the upstream neighbor has indicated in its Probe messages that it understands netmasks.

DVMRP Graft Acknowledgement Message Format

Figure 5-30 shows the format of the Graft Acknowledgement message. With the exception of the Code field in the header, the format is identical to that of the Graft message that it is acknowledging.

Figure 5-30. The DVMRP Graft Acknowledgement Message Format

DVMRP Ask Neighbors 2 Message Format

The DVMRP Ask Neighbors 2 message is one of two messages (along with the Neighbors 2 message, discussed in the following section) that are used for troubleshooting. The "2" distinguishes the message from the obsolete Ask Neighbors message. The Ask Neighbors 2 message, shown in Figure 5-31, is unicast to a specified destination. When a router receives an Ask Neighbors 2 message, it should respond by unicasting a Neighbors 2 message to the originator. As the figure shows, the message is merely the DVMRP header with the code set to 0x5.

Figure 5-31. The DVMRP Ask Neighbors 2 Message Format

DVMRP Neighbors 2 Message Format

A DVMRP router in response to an Ask Neighbors 2 message sends the Neighbors 2 message, shown in Figure 5-32. The message is unicast to the originator of the Ask Neighbors 2 message. The message indicates the sender's DVMRP capabilities and lists the addresses of the sender's logical interfaces. For each interface listed, the DVMRP parameters for the interface are specified, and the DVMRP neighbors known on that interface are listed.

Figure 5-32. The DVMRP Neighbors 2 Message Format

The fields for the DVMRP Neighbors 2 message are defined as follows:

• Capabilities specifies the DVMRP capabilities of the originating router. The field is the same as the Capabilities field of the Prune message, and its values are shown in Table 5-8.

• Local Address is the address of an interface on the router. If the interface is down or disabled, a single neighbor entry is associated with the interface, and the neighbor entry has an address of 0.0.0.0.

• Metric specifies the DVMRP metric of the interface.

• Threshold specifies the administrative scoping threshold of the interface.

• Neighbor Count specifies the number of neighbors listed for this interface.

• Neighbor is the IP address of a DVMRP neighbor known on this interface.

• Flags is a series of bits describing operational parameters of the interface. Table 5-9 lists the bits of this field and what flag each bit represents.

Table 5-9. Interface Flags in the Neighbor 2 Message

Bit	Flag	Description
	Tunnel	Neighbor reached via tunnel
1	Source Route	Tunnel uses IP source routing
2	Reserved	No longer used
3	Reserved	No longer used
4	Down	Operational status down
5	Disabled	Administrative status down
6	Querier	Querier for interface
7	Leaf	No downstream neighbors on this interface