Appendix B. Acronyms Introduction Multicast point-to-multipoint is a communication pattern in which a source host sends a message to a group of destination hosts. Although, this can be done by sending different unicast point-to-point messages to each of the destination hosts, there are many reasons which make having the multicasting capability desirable. The first major advantage of using multicasting is the decrease of the network load. There are many applications like stock ticker applications which are required to transmit packets to hundreds of stations. The packets sent to these stations share a group of links on their paths to their destinations.

Author:Mezibei Vozilkree
Language:English (Spanish)
Published (Last):27 September 2019
PDF File Size:19.70 Mb
ePub File Size:3.44 Mb
Price:Free* [*Free Regsitration Required]

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.

The trees are calculated and updated dynamically to track the membership of individual groups. When a datagram arrives on an interface, the reverse path to the source of the datagram is determined by examining a unicast routing table of known source networks.

If the datagram arrives on an interface that would be used to transmit unicast datagrams back to the source, then it is forwarded to the appropriate list of downstream interfaces.

Otherwise, it is not on the optimal delivery tree and should be discarded. In this way duplicate packets can be filtered when loops exist in the network topology. The source specific delivery trees are automatically pruned back as group membership changes or leaf routers determine that no group members are present. This keeps the delivery trees to the minimum branches necessary to reach all of the group members.

New sections of the tree can also be added dynamically as new members join the multicast group by grafting the new sections onto the delivery trees. The IP Multicast datagrams are encapsulated in unicast IP packets and addressed to the routers that do support native multicast routing. DVMRP treats tunnel interfaces in an identical manner to physical network interfaces. Those who wish to gain a general understanding of the protocol but are not interested in the more precise details may wish to only read this section.

Section 3 explains the detailed operation of the protocol to accommodate developers needing to provide interoperable implementations. Table of Contents 1. Protocol Overview 2. This address falls into the range of IP Multicast addresses that are to remain on the locally attached IP network and therefore are not forwarded by multicast routers. Care must be taken to interoperate with older implementations of DVMRP that do not include this list of neighbors.

Therefore, it is not necessary to send both old and new types of Neighbor Probes. In addition to the list of known neighbors, the Probe message should contain a set of flags describing the attributes of the DVMRP router. There are currently four attributes defined. LEAF - This router considers itself a leaf router. This interface is called the upstream interface. If the datagram arrived on the correct upstream interface, then it is a candidate for forwarding to one or more downstream interfaces.

If the datagram did not arrive on the anticipated upstream interface, it is discarded. In order to ensure that all DVMRP routers have a consistent view of the unicast path back to a source, a unicast routing table is propagated to all DVMRP routers as an integral part of the protocol. Each router advertises the network number and mask of the interfaces it is directly connected to as well as relaying the routes received from neighbor routers.

DVMRP allows for an interface metric to be configured on all physical and tunnel interfaces. When a route is received, the metric of the upstream interface over which the datagram was received must be added to the metric of the route being propagated. This adjusted metric should be computed before the route is compared to the metric of the current next hop gateway. Although there is certainly additional overhead associated with propagating a separate unicast routing table, it does provide two nice features.

First, since all DVMRP routers are using the same unicast routing protocol, there are no inconsistencies between routers when determining the upstream interface aside from normal convergence issues related to distance vector routing protocols. By placing the burden of synchronization on the protocol as opposed to the network manager, DVMRP reduces the risk of creating routing loops or blackholes due to disagreement between neighbor routers on the upstream interface. Second, by propagating its own unicast routing table, DVMRP makes it convenient to have separate paths for unicast vs.

Although, ideally, many network managers would prefer to keep their unicast and multicast traffic aligned, tunneled multicast topologies may prevent this causing the unicast and multicast paths to diverge.

Additionally, service providers may prefer to keep the unicast and multicast traffic separate for routing policy reasons as they experiment with IP multicast routing and begin to offer it as a service. For these benefits, DVMRP has chosen to accept the additional overhead of propagating unicast routes. DVMRP uses the unicast route exchange as a mechanism for upstream routers to determine if any downstream routers depend on them for forwarding from particular source networks.

If a downstream router selects a particular upstream router as the best next hop to a particular source network, then it signifies this to the upstream router by echoing back the route to the upstream router with a metric equal to the original metric plus infinity.

If the upstream interface is correct, then a DVMRP router will forward the datagram to a list of downstream interfaces. If the downstream interface under consideration is a leaf network has no other IP multicast routers on it , then the IGMP local group database must be consulted.

Obviously, it is necessary to refresh this list and age out entries received from routers that are no longer being refreshed. The IGMP local group database is maintained by an elected IP multicast router on each physical, multicast capable network. The details of the election procedure are discussed in section 3. If the destination group address is listed in the local group database, then the interface should be included in the list of downstream interfaces.

If there are no group members on the interface, then the interface can be pruned from the candidate list. This allows all downstream routers to be aware of traffic destined for a particular source, group pair. The downstream routers will then have the option to prune and graft this source, group pair to and from the multicast delivery tree as requirements change from their downstream routers and local group members.

If a router prunes all of its downstream interfaces, it can notify the upstream router that it no longer wants traffic destined for a particular source, group pair. This is accomplished by sending a DVMRP Prune message upstream to the router it expects to forward datagrams from a particular source. This method allows the upstream router to build a list of downstream routers on each interface that are dependent upon it for datagrams from a particular source network.

If the upstream router receives prune messages from each one of the dependent downstream routers on an interface, then the upstream router can in turn prune this interface from its downstream interface list.

If the upstream router is able to prune all of its downstream interfaces in this way, it can then send a DVMRP Prune message to its upstream router. This continues until the minimum tree necessary to reach all of the receivers remains. Since IP multicast routers may be restarted at any time and lose state information about existing prunes, it is necessary to limit the life of a prune and periodically resume the flooding procedure.

This will reinitiate the prune mechanism and the cycle will continue. When a router decides to prune one of its downstream interfaces, it will set a timer to indicate the lifetime of the prune. There are two different ways for packets from the source, group pair to be forwarded again. First, since IP multicast supports dynamic group membership, new hosts may join the multicast group.

In this case, DVMRP routers will need a mechanism to undo the prunes that are in place from the host back to the first branch that was pruned from the multicast tree. A router will send a Graft message to its upstream neighbor if a group join occurs for a group that currently has pruned sources. Separate Graft messages must be sent to the appropriate upstream neighbor for each source that has been pruned. Since there would be no way to tell if a Graft message sent upstream was lost or the source simply quit sending traffic, it is necessary to acknowledge each Graft message with a DVMRP Graft Ack message.

If an acknowledgment is not received within a Graft Time-out period, the Graft message should be retransmitted. Duplicate Graft Ack messages should simply be ignored. Second, if the prune interval expires, the negative cache entries are removed and the packets will automatically be forwarded again.

This is a necessary feature since routers may be restarted and lose all prune state information or new routers may appear. Since these routers will not have prune state associated with the source, group pair, they will not realize that a DVMRP Graft message is necessary if a new host joins the group.

Therefore, by periodically timing out the prunes and re-flooding the traffic, any new or restarted routers can have their prune state periodically refreshed. Currently, there are codes allocated for DVMRP protocol message types as well as protocol analysis and troubleshooting packets. These codes are discussed in Appendix B. This may be deduced from the major and minor version numbers in the Probe packet or directly from the capability flags. Examples of these capabilities are whether Generation IDs are used, if the neighbor supports pruning, if the neighbor is a leaf router, and whether the neighbor supports the multicast trace route function.

Probes provide a keep-alive function in order to quickly detect neighbor loss. This allows fairly early detection of a lost neighbor yet provides tolerance for busy multicast routers. For instance, for major versions less than 3, it can be assumed that the neighbor does not support pruning. The formal capability flags were first introduced in version 3. A complete version history is summarized in Appendix A to assist with backward compatibility.

Instead, it will spread the updates over an entire routing update interval. In order for the neighbor to detect a router that is restarted, a non-decreasing number is placed in the periodic probe message called the generation ID. If a router detects an increase in the generation ID of a neighbor, it should exchange its entire unicast routing table with the neighbor.

A time of day clock provides a good source for a non-decreasing 32 bit integer. This allows the neighbor router to know that its probes have been received by the sending router. The current Major Version is 3. To maintain compatibility with previous versions, implementations of Version 3 must include pruning and grafting of multicast trees. Based on the list of neighbors from which DVMRP Probe messages were received, a router will pick the router with the lowest IP address as the designated querier.

The router must be sure and include itself in this list of candidates. Because the possible combinations of these is quite large, forwarding cache entries are generated on demand as data arrives at a multicast router. Since the IP forwarding decision is made on a hop by hop basis as with the unicast case , it is imperative that each multicast router has a consistent view of the reverse path back to the source network. If the packet did not arrive on that interface, it should be discarded without further processing.

Each multicast forwarding entry should cache the upstream interface for a particular source host or source network after looking this up in the DVMRP unicast routing table. Any interfaces designated as leaf networks and do not have members of the particular multicast group can be automatically pruned from list of downstream interfaces. These interfaces may be pruned in the future if it is determined that there are no group members anywhere along the entire tree branch.

One effect of using these encapsulated tunnels is that IP multicast traffic may not be aligned with IP unicast traffic. This means that a multicast datagram from a particular source can arrive on a different interface than the upstream interface back to the unicast source of the multicast datagram. Therefore, when determining the reverse path back to a particular source it is not always possible to use the standard unicast routing table.

This routing information is used exclusively for determining the reverse path back to source of multicast traffic. Tunnels are considered to be distinct interfaces and route reports are sent unicast between tunnel endpoints as though they arrived on the tunnel pseudo interface.

The routing information that is propagated by DVMRP contains a list of unicast source networks and an appropriate metric.


Distance Vector Multicast Routing Protocol

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. The trees are calculated and updated dynamically to track the membership of individual groups. When a datagram arrives on an interface, the reverse path to the source of the datagram is determined by examining a unicast routing table of known source networks. If the datagram arrives on an interface that would be used to transmit unicast datagrams back to the source, then it is forwarded to the appropriate list of downstream interfaces. Otherwise, it is not on the optimal delivery tree and should be discarded.


IP Multicasting: Concepts, Algorithms, and Protocols

Google Network Working Group D. Waitzman Request For Comments: C. Status of this Memo This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. This is an experimental protocol, and its implementation is not recommended at this time. Distribution of this memo is unlimited. Introduction A draft standard for multicasting over IP networks now exists [2], but no routing protocols to support internetwork multicasting are available.



Related Articles