When a sender initiates a multicast, the adjacent router
or routers assume that all users in the entire routed
network will want to participate. The router adjacent to the
sender sends a multicast to all of its adjacent routers, and
each of those routers sends the message to all of their
adjacent routers. This process continues until all multicast
group members have seen the message.
When a router receives the multicast message, it checks
its unicast routing table to determine that interface which
provides the shortest route back to the source. If that
route is over the interface that the multicast was received,
the router enters information into its internal table about
the multicast group and then forwards the message on to
adjacent routers, and not over the interface the multicast
was received on. This process is called RPF (Reverse Path
Forwarding) and ensures that there are no loops in the tree
and that the shortest paths will be used.
Enhancements to the DMVRP protocol have led to routers
becoming more intelligent when forwarding multicast updates.
For example, if router R4 (see figure) understands (from its
unicast tables) that R5 will probably determine that R4 is
the best path back to the source, R4 will not bother
flooding the routing update to R5.
Routers maintain who (workstations) are members of
multicast groups so that pruning can take place.
Workstations periodically respond to IGMP messages (IGMP is
explained in another white paper) from the routers to
maintain membership. These messages from the workstations
allow the router to determine whether it needs to forward
the multicast out through all interfaces. If a router
determines that it has no participants in a multicast, it
will ask the upstream router not to forward the multicast
down. This is a pruning mechanism that results in a smaller,
more efficient spanning tree.
This pruning method appears to work well for densely
populated participants. DVMRP does not scale well, however,
because every DVMRP router must:
- Maintain a potentially large amount of routing state
information,
- Maintain state information for all multicast groups,
and
- Periodically participate in reinitiating the spanning
tree for each group.
It is because of this that DVMRP does not support
sparsely distributed participants in a large network
infrastructure.
A DVMRP message is in the following format preceded by an
IP header:
The type for DVMRP is 3.
The subtype is one of the following:
- = Response; the message provides routes to some
destination(s)
- = Request; the message requests routes to some
destination(s)
- = Non-membership report; the message provides
non-membership report(s)
- = Non-membership cancellation; the message cancels
previous non-membership report(s)
The following packet formats and descriptions were taken
from RFC 1075.
The length of DVMRP messages is limited to 512 bytes,
excluding the IP header.
The following is a list of possible tagged data:
Null Command:
Description: The Null command can be used to provide
additional alignment or padding to 32 bits.
Address Family Indicator (AFI) Command:
Values:
2 = IP address family, in which address are 32 bits long.
Default: Family = 2
Description: The AFI command provides the address family for
subsequent addresses in the stream (until a different AFI
command is given).
Subnet Mask Command:
Additional Argument, with AFI = IP:
Count is 0 or 1.
Default: Assume that following routes are to networks,
and use a mask of the network mask of each routeÕs
destination.
Description: The Subnet mask command provides the subnet
mask to use for subsequent routes. There are some
requirements on the bits in the subnet mask: bits 0 through
7 must be 1, and all of the other bits must not be 1.
If the count is 0, then no subnet mask applies; assume
that the following routes are to networks, and use a mask of
the network mask of each routeÕs destination. If count is
1, then a subnet mask should be in the data stream, of an
appropriate size given the address family. It is an error
for count not to equal 0 or 1.
Subnet masks should not be sent outside of the appropriate
network.
Metric Command:
Value is the metric, as an unsigned value ranging from 1
to 255.
Default: None.
Description: The metric command provides the metric to
subsequent destinations. The metric is relative to the
router that sent this DVMRP routing update.
It is an error for metric to equal 0.
Flags0 Command:
Meaning of bits in value:
Bit 7: Destination is unreachable.
Bit 6: Split Horizon; concealed route.
Default: All bits zero.
Description: The flags0 command provides a way to set a
number of flags. The only defined flags, bits 6 and 7, can
be used to provide more information about a route with a
metric of infinity. A router that receives a flag that it
does not support should ignore the flag. The command is
called flags0 to permit the definition of additional flag
commands in the future (flags1, etc.).
This is an experimental command, and may be changed in
the future.
Infinity Command:
Value is the infinity, as an unsigned value ranging from
1 to 255.
Default: Value = 16.
Description: The infinity command defines the infinity
for subsequent metrics in the stream.
It is an error for infinity to be zero, or less than the
current metric. Destination Address (DA) Command
Array of "count" additional arguments, with AFI
= IP:
Count is the number of addresses supplied, from 1 to 255.
The length of the addresses depends upon the current address
family. The number of addresses supplied is subject to the
message length limitation of 512 bytes.
Default: None.
Description: The DA command provides a list of
destinations. While this format can express routes to hosts,
the routing algorithm only supports network and subnetwork
routing. The current metric, infinity, flags0 and subnetmask,
when combined with a single destination address, define a
route. The current metric must be less than or equal to the
current infinity.
It is an error for count to equal 0.
Requested Destination Address (RDA) Command:
Array of "count" additional arguments, with AFI
= IP:
Count is the number of addresses supplied, from 0 to 255.
The length of the addresses depends upon the current address
family. The number of addresses supplied is subject to the
message length limitation of 512 bytes.
Default: None.
Description: The RDA command provides a list of
destinations for whom routes are requested. A routing
request for all routes is encoded by using a count = 0.
Non Membership Report (NMR) Command:
Array of "count" additional arguments, with AFI
= IP:
Count is the number of Multicast Address and Hold Down
Time pairs supplied, from 1 to 255. The length of the
addresses depends upon the current address family. The
number of pairs supplied is subject to the message length
limitation of 512 bytes.
Default: None.
Description: The NMR command is experimental, and has not
been tested in an implementation. Each multicast address and
hold down time pair is called a non-membership report. The
non-membership report tells the receiving router that the
sending router has no descendent group members in the given
group. Based on this information the receiving router can
stop forwarding datagrams to the sending router for the
particular multicast address(es) listed. The hold down time
indicates, in seconds, how long the NMR is valid.
It is an error for count to equal 0.
The only other commands in a message that has NMR
commands can be the AFI, flags0, and Null commands. No
relevant flags for the flags0 command are currently defined,
but that may change in the future.
Non Membership Report Cancel (NMR Cancel) Command:
Array of "count" additional arguments, with AFI
= IP:
Count is the number of Multicast Addresses supplied, from
1 to 255. The length of the addresses depends upon the
current address family. The number of addresses supplied is
subject to the message length limitation of 512 bytes.
Default: None.
Description: The NMR Cancel command is experimental, and
has not been tested in an implementation. For each multicast
address listed, any previous corresponding non-membership
reports are canceled. When there is no corresponding
non-membership report for a given multicast address, the
Cancel command should be ignored for that multicast address.
It is an error for Count to equal 0.
The only other commands in a message that has NMR Cancel
commands can be the AFI, flags0, and Null commands. No
relevant flags for the flags0 command are currently defined,
but that may change in the future.
The following illustrations will help tie in the packet
formats and protocol operation: When a source initiates an
IP multicast, IGMP packets are sent out to set up a group.
The router then uses this IGMP to set up a DVMRP spanning
tree as shown:
R1 sends out a packet which would look something like the
following. DVMRP packets use a multicast with a destination
IP of 224.0.0.4. The IP header of the packet below has been
omitted.
In the packet above, the first row lists the version,
type, subtype and checksum of the IGMP header for this DVMRP
packet. The size of this frame is limited to 512 bytes
excluding the IP header. This is the same size limitation
place on RIP (RFC 1058).
In the second row, the first 2 is the AFI and the second
2 is the value. The 4 says the following is a metric value
and the 1 is the metric.
In the third row the 6 is the Infinity command and the 1 is
the value. The following 3 is the subnet mask command and
the value of 1 means there is a subnet mask.
In the fourth row the subnet mask is given.
In the fifth row the 7 is the Destination address command
followed by the value 1 and the actual address follows on
into row 6 (172.16.3.34).
The routers receiving this packet respond as shown:
In the preceding diagram, when R2 receives a route on its
virtual interface from R4, R2 will compare metrics. Since
the metrics are the same, the router with the lowest IP
address will become the dominate router. If R4 had a lower
metric, then R2 will put into its routing table that R4 is
the dominant router for the virtual interface. R2 would then
be considered the subordinate router.
The dominant router for a virtual network is called the
parent and the virtual network it is responsible for is
called a child.
There are a series of Time Values associated with this
multicast routing algorithm listed in RFC (1075) where a
description on how a new router will effect the network is
given in fair detail.
The message continues to propagate the routed network:
The tree continues to resolve:
The tree is now complete as shown below:
When finished, the tree will have computed based on the
shortest reverse path tree back to the source. This process
is referred to as the TRPB (Truncated Reverse Path
Broadcasting) algorithm. Each multicast router must
determine its place in the tree, relative to the particular
source, and then determine which of its virtual interfaces
are in the shortest path tree. The datagram is forwarded
through these virtual interfaces. The process of excluding
virtual interfaces not in the shortest path tree is called
"pruning." A leaf becomes a virtual network which
no router considers uptree to a given source (see following
diagram).
Looking at the following figure,
The packet format of R6 packet sent to R4 would be as
follows:
The first row lists the version, type, subtype and
checksum of the IGMP header for this DVMRP packet, as
described earlier. In the second row, the first 2 is the AFI
and the second 2 is the value. The 9 says that the following
is a Non Membership Report (NMR) command and the 1 says that
only one address is being requested not to be sent. Row 3
displays the multicast D address R6 is asking R4 not to send
down. Row 4 displays the Hold Down Time, as explained
earlier.
DVMRP is considered a dense mode protocol because its
members are traditionally close together geographically.
Other examples of dense mode protocols are MOSPF and PIM
Dense. Sparse mode protocols are used in networks when
members are more distributed or when bandwidth is not as
plentiful. Examples of a sparse mode protocols are
PIM-Sparse and Core-Based Tree (CBT). Another buzz word we
some times hear about is the Mbone, which is basically a
network within the Internet. The Mbone delivers multimedia
data by utilizing tunneling, creating point-to-point links
and encapsulating multicast frames.
E-Mail
Related