Interoperability Rules for Multicast Routing Protocols (RFC2715)
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.
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 (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.
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  or BGMP , 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 (...