Interoperability Rules for Multicast Routing Protocols
RFC 2715

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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.

Abstract

   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
      3.

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

   o  Only one multicast routing protocol is active per interface (we do
      not consider mixed multicast protocol LANs).  Each interface on
      which multicast is enabled is thus "owned" by exactly one of the
      components.

   o  All components share a common forwarding cache of (S,G) entries,