Interoperability Rules for Multicast Routing Protocols
RFC 2715

Document Type RFC - Informational (October 1999; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2715 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           D. Thaler
Request for Comments: 2715                                      Microsoft
Category: Informational                                      October 1999

         Interoperability Rules for Multicast Routing Protocols

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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


   The rules described in this document will allow efficient
   interoperation among multiple independent multicast routing domains.
   Specific instantiations of these rules are given for the DVMRP,
   MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well
   as for IGMP-only links.  Future versions of these protocols, and any
   other multicast routing protocols, may describe their
   interoperability procedure by stating how the rules described herein
   apply to them.

1.  Introduction

   To allow sources and receivers inside multiple autonomous multicast
   routing domains (or "regions") to communicate, the domains must be
   connected by multicast border routers (MBRs).  To prevent black holes
   or routing loops among domains, we assume that these domains are
   organized into one of the following topologies:

   o  A tree (or star) topology (figure 1) with a backbone domain at the
      root, stub domains at the leaves, and possibly "transit" domains
      as branches between the root and the leaves.  Each pair of
      adjacent domains is connected by one or more MBRs.  The root of
      each subtree of domains receives all globally-scoped traffic
      originated anywhere within the subtree, and forwards traffic to
      its parent and children where needed.  Each parent domain's MBR
      injects a default route into its child domains, while child
      domains' MBRs inject actual (but potentially aggregated) routes
      into parent domains.  Thus, the arrows in the figure indicate both
      the direction in which the default route points, as well as the
      direction in which all globally-scoped traffic is sent.

Thaler                       Informational                      [Page 1]
RFC 2715                     Interop Rules                  October 1999

                          +----|        |----+
          +---+    +---+  |  ===>      <===  |
          |   |    |   |  +----|   #    |----+
          |   |    | # |     +-----#------+
          | # |  +---#-------|     v      |-----------+
         +--#----|   v       |            |           |-----+
         |  v  ===>        ===> Backbone <===        <===   |
         +-------|   ^       |            |     ^     |-----+
                 +---#-------|     ^      |-----#-----+
                   | # |     +-----#------+ |   #    |-----+
                   |   |       |   #    |   |       <===   |
                   +---+   +---|        |   |        |-----+
                           | ===>       |   +--------+

                 Figure 1: Tree Topology of Domains

   o  An arbitrary topology, in which a higher level (inter-domain)
      routing protocol, such as HDVMRP [1] or BGMP [9], is used to
      calculate paths among domains.  Each pair of adjacent domains is
      connected by one or more MBRs.

   Section 2 describes rules allowing interoperability between existing
   multicast routing protocols [2,3,4,5,6], and reduces the
   interoperability problem from O(N^2) potential protocol interactions,
   to just N (1 per protocol) instantiations of the same set of
   invariant rules.  This document specifically applies to Multicast
   Border Routers (MBRs) which meet the following assumptions:

   o  The MBR consists of two or more active multicast routing
      components, each running an instance of some multicast routing
      protocol.  No assumption is made about the type of multicast
      routing protocol (e.g., broadcast-and-prune vs. explicit-join) any
      component runs, or the nature of a "component".  Multiple
      components running the same protocol are allowed.

   o  The router is configured to forward packets between two or more
      independent domains.  The router has one or more active interfaces
      in each domain, and one component per domain.  The router also has
      an inter-component "alert dispatcher", which we cover in Section

Thaler                       Informational                      [Page 2]
RFC 2715                     Interop Rules                  October 1999
Show full document text