Interoperability Rules for Multicast Routing Protocols
RFC 2715
|
Document |
Type |
|
RFC - Informational
(October 1999; No errata)
|
|
Author |
|
Dave Thaler
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
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.
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,
Show full document text