T. PusateriINTERNET DRAFT Juniper NetworksObsoletes: RFC 1075 October 22, 2003draft-ietf-idmr-dvmrp-v3-11 Expires: April 22, 2004 Distance Vector Multicast Routing ProtocolStatus of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.Abstract DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88].Pusateri [Page 1]draft-ietf-idmr-dvmrp-v3-11 - Distance Vector Multicast Routing Protocol https://tools.ietf.org/html/draft-ietf-idmr-dvmrp-v3-111 of 51 03-12-2014 21:22INTERNET-DRAFT DVMRP Version 3 August 20001. Introduction DVMRP uses a distance vector distributed routing algorithm in order to build per-source-group multicast delivery trees. A good introduction to distance vector routing can be found in [Perl92]. The application of distance vector routing to multicast tree formulation is described in [Deer91].1.1. Requirements Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC-2119].1.2. Reverse Path Multicasting Datagrams follow multicast delivery trees from a source to all members of a multicast group [Deer89], replicating the packet only at necessary branches in the delivery tree. 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 DVMRP routing table of known source networks. If the datagram arrives on an interface that would be used to transmit 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 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.1.3. Tunnel Encapsulation Because not all IP routers support native multicast routing, DVMRP includes direct support for tunneling IP Multicast datagrams through routers. The IP Multicast datagrams are encapsulated in unicast IP packets and addressed to the routers that do support native multicastPusateri [Page 2]draft-ietf-idmr-dvmrp-v3-11 - Distance Vector Multicast Routing Protocol https://tools.ietf.org/html/draft-ietf-idmr-dvmrp-v3-112 of 51 03-12-2014 21:22INTERNET-DRAFT DVMRP Version 3 August 2000 routing. DVMRP treats tunnel interfaces in an identical manner to physical network interfaces. In previous implementations, DVMRP protocol messages were sent un- encapsulated to the unicast tunnel endpoint address. While this was more direct, it increased the complexity of firewall configuration. The most noticeable change in this specification regarding tunnels is that all DVMRP protocol messages should be sent encapsulated across the tunnel. Previously, protocol messages were sent un-encapsulated directly to the tunnel endpoint. See Appendix C for backward compatibility issues. Note: All protocol messages sent on point-to-point links (including tunnels) should use a destination address of All-DVMRP-Routers. This change will allow the protocol messages to be forwarded across multicast-only tunnels without making encapsulation and decapsulation difficult. In practice, tunnels typically use either IP-IP [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b], although, other encapsulation methods are acceptable.1.4. Document Overview Section 2 provides an overview of the protocol and the different message types exchanged by DVMRP routers. 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 inter-operable implementations. Included in Appendix A, is a summary of the DVMRP parameters. A section on DVMRP support for tracing and troubleshooting is the topic of Appendix B. Finally, a short DVMRP version compatibility section is provided in Appendix C to assist with backward compatibility issues.2. Protocol Overview DVMRP can be summarized as a "broadcast & prune" multicast routing protocol. It builds per-source broadcast trees based upon routing exchanges, then dynamically creates per-source-group multicast delivery trees by pruning (removing branches from) the source's truncated broadcast tree. It performs Reverse Path Forwarding checks to determine when multicast traffic should be forwarded to downstreamPusateri [Page 3]draft-ietf-idmr-dvmrp-v3-11 - Distance Vector Multicast Routing Protocol https://tools.ietf.org/html/draft-ietf-idmr-dvmrp-v3-113 of 51 03-12-2014 21:22INTERNET-DRAFT DVMRP Version 3 August 2000 interfaces. In this way, source-rooted shortest path trees
View Full Document
Unlocking...