Subject: DVMRP v3 Applicability Statement

From: Tom Pusateri <[email-masked]>
Date: Sat, 06 Nov 1999 15:57:05 -0800

This is the last piece needed to advance DVMRP up the standards track.
I'll submit as a draft after the meeting. Any comments received before
then would be greatly appreciated.

Thanks,
Tom

------------------------------------------------------------------------

                                                             T. Pusateri
INTERNET DRAFT                                          Juniper Networks
draft-ietf-idmr-dvmrp-v3-as-00                              October 1999
                                                 Expires: April 30, 2000

   Distance Vector Multicast Routing Protocol Applicability Statement

Status 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

   This document provides a framework for the use of Distance Vector
   Multicast Routing Protocol (DVMRP) Version 3 within a multicast
   routing domain. It is an interior gateway protocol designed to be
   used within an autonomous system.

Pusateri                                                        [Page 1]


INTERNET-DRAFT        DVMRP Applicability Statement         October 1999

1.  Intended use

   DVMRP [Pusa99] can be characterized as a broadcast and prune
   multicast routing protocol. This means that IP multicast datagrams
   are forwarded to all possible receivers and then unwanted data
   traffic is pruned back to the minimum tree necessary to reach all of
   the current receivers.

   This provides a data driven mechanism for all last hop routers to
   learn about all active multicast sources. If the last hop routers
   have local group members for the multicast group associated with the
   source, they simply do nothing and the multicast data will continue
   to arrive.

   If the last hop routers do not have corresponding group members for
   the active source, then they send control messages back up the
   multicast delivery tree toward the source to prune their branch from
   the tree.

   As a failsafe mechanism, the prunes sent upstream toward the source
   time out and are periodically refreshed. The periodic broadcast and
   prune nature of the protocol makes it well suited for use within a
   multicast domain or autonomous system where the number of receivers
   are likely to be densely located. It is NOT intended for use as an
   EGP across multicast domains or for interconnecting multicast
   domains.

   DVMRP's advantages compared with other multicast routing protocols
   include:

   a. Pure source specific multicast distribution trees provide a simple
      model to deploy and troubleshoot.

   b. Join latency is minimized since new sources are automatically sent
      to all receivers.

   c. Discovery mechanisms relying on expanding ring searches are fully
      supported.

   Of course, these benefits do not come without a cost. The broadcast
   nature of DVMRP makes it unsuitable for connecting leaf domains via
   low speed links. Additionally, the cost of keeping prune state for
   unwanted data can be high depending on the mix of receivers.

   Additionally, DVMRP operates on the premise that all data will be
   broadcast throughout the domain and unwanted data will be pruned back
   toward the source. If a DVMRP domain is connected downstream from an

Pusateri                                                        [Page 2]


INTERNET-DRAFT        DVMRP Applicability Statement         October 1999

   explicit join multicast domain, then without additional mechanism, no
   data would ever be broadcast into the DVMRP domain from the explicit
   join domain. For this purpose, Domain Wide Reports [Fenn99] were
   invented to inform border routers between explicit join domains and
   broadcast and prune domains about the active group membership within
   the broadcast and prune domain.

2.  Scalability/Applicability

   A routing protocol need only scale within the limits of its intended
   use.  In this case, DVMRP need only scale within the context of
   multicast routing domain or autonomous system.

   There are several factors that limit the scalability of DVMRP.
   Fortunately, these factors are well understood and by making these
   explicit within this applicability statement, it should be possible
   to avoid negative side-effects.

   Convergence time
      Since DVMRP uses to uses a distance vector (also called Bellman-
      Ford after its authors) routing algorithm to distribute source
      information, its scope is limited by the convergence time required
      to propagate updated source information across the routing domain.
      In order to limit the convergence time, DVMRP has imposed a limit
      on the number of hops across a domain by setting the infinity
      metric to 32 hops.

   Count to Infinity
      All distance vector protocols are susceptible to the well known
      "count to infinity" problem [Perl92]. However, by requiring the
      use of split horizon with poison reverse, the chances of
      encountering this are significantly lowered.

3.  State Analysis

   As stated earlier, DVMRP broadcasts new multicast data to all
   receivers and then prunes back the unwanted data based on group
   membership information. To further reduce the amount of broadcasted
   data, DVMRP truncates the broadcast tree by determining the single
   reverse path from a receiver back to the source and pruning duplicate
   paths.

   This truncated broadcast tree is precalculated using poison reverse
   route updates as each router participates in a designated forwarder
   election per source network to determine the upstream router.

Pusateri                                                        [Page 3]


INTERNET-DRAFT        DVMRP Applicability Statement         October 1999

   This mechanism prevents duplicate datagrams from arriving on multi-
   access networks at the expense of more state in the router. DVMRP
   requires designated forwarder election state to be kept per prefix
   per interface and prune state to be kept per neighbor per prefix.

4.  Control Traffic Analysis

   Independent of the amount of multicast data being forwarded, DVMRP
   will always send some control traffic. First, there is a DVMRP probe
   message sent every 10 seconds per interface for neighbor discovery
   and keep-alive functions. Additionally, there are periodic route
   exchanges that advertise source networks and assist in building the
   multicast delivery trees. These route reports are resent every 60
   seconds but are spread out across the report interval to reduce the
   processing load.  The number of route report packets sent is
   dependent on the number of prefixes being reported.

   The amount of prune and graft messages sent is a function of the
   number of active receivers for the data received. Grafts are only
   sent to undo the effects of previous prunes. Prunes are sent in
   response to unwanted multicast data. The lifetime of a prune which is
   specific to a group and source network is approximately 2 hours. This
   alone greatly limits the amount of prune control traffic that is
   sent.

Pusateri                                                        [Page 4]


INTERNET-DRAFT        DVMRP Applicability Statement         October 1999

5.  References

   [Fenn99]  Fenner, W., "Domain Wide Multicast Group Membership
             Reports", Work in Progress, August 1999.

   [Perl92]  Perlman, R., "Interconnections: Bridges and Routers",
             Addison-Wesley, 1992, pp. 210-211.

   [Pusa99]  Pusateri, T., "Distance-Vector Multicast Routing Protocol
             Version 3",  Work In Progress, September 1999.

6.  Author's Address

   Thomas Pusateri
   Juniper Networks, Inc.
   385 Ravendale Dr.
   Mountain View, CA  94043
   Phone:    (650) 526-8046
   EMail:    [email-masked]

7.  Acknowledgments

   The author would like to acknowledge Dave Thaler for his review and
   comments.

Pusateri                                                        [Page 5]


INTERNET-DRAFT        DVMRP Applicability Statement         October 1999

8.  Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Pusateri                                                        [Page 6]


                             Table of Contents

   1. Intended Use . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Scalability/Applicability  . . . . . . . . . . . . . . . . . .   3
   3. State Analysis . . . . . . . . . . . . . . . . . . . . . . . .   3
   4. Control Traffic Analysis . . . . . . . . . . . . . . . . . . .   4
   5. References . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6. Author's Address . . . . . . . . . . . . . . . . . . . . . . .   5
   7. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .   5
   8. Full Copyright Statement . . . . . . . . . . . . . . . . . . .   6

Pusateri                                                        [Page i]