Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction
RFC 5186
| Document | Type | RFC - Informational (May 2008; No errata) | |
|---|---|---|---|
| Authors | Jim Martin , Brian Haberman | ||
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5186 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Margaret Cullen | ||
| Send notices to | (None) | ||
Network Working Group B. Haberman
Request for Comments: 5186 Johns Hopkins University
Category: Informational J. Martin
Woven Systems
May 2008
Internet Group Management Protocol Version 3 (IGMPv3) /
Multicast Listener Discovery Version 2 (MLDv2) and
Multicast Routing Protocol Interaction
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.
Abstract
The definitions of the Internet Group Management Protocol Version 3
(IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require
new behavior within the multicast routing protocols. The additional
source information contained in IGMPv3 and MLDv2 messages
necessitates that multicast routing protocols manage and utilize the
information. This document describes how multicast routing protocols
will interact with these source-filtering group management protocols.
1. Introduction
The definitions of IGMPv3 [IGMP3] and MLDv2 [MLDv2] require new
behavior within the multicast routing protocols. The additional
source information contained in IGMPv3 and MLDv2 messages
necessitates that multicast routing protocols manage and utilize the
information. This document will describe how multicast routing
protocols will interpret information learned from these source-
filtering group management protocols.
2. Multicast Forwarding State
Existing multicast routing protocols utilize the group management
database in determining if local members exist for a particular
multicast group. With previous group management protocols, this
database had one type of record indicating the group for which there
was interest and the associated local interfaces.
Haberman & Martin Informational [Page 1]
RFC 5186 IGMPv3/MLDv2 and Multicast Protocols May 2008
In the case of IGMPv3 and MLDv2, these routing protocols may now
build multicast forwarding state based on the source filter
information available for each multicast group that has local
membership. This requires that the group management database have
four record types. Only one record may exist for a given interface
and a given multicast group.
1. EXCLUDE <>
The EXCLUDE <> record indicates interest in all sources
destined to this group address for a set of local interfaces.
It is equivalent to the single record type existing in previous
versions of the group management protocols.
2. INCLUDE <>
The INCLUDE <> record indicates that there is no interest in
any sources destined to this group address for a set of local
interfaces.
3. EXCLUDE <list>
The EXCLUDE <list> record indicates that there is interest in
all sources other than the specifically listed sources for a
set of local interfaces.
4. INCLUDE <list>
The INCLUDE <list> record indicates that there is interest in
only the specifically listed sources for a set of local
interfaces.
The records in the group management database should be utilized when
generating forwarding state for a multicast group. If the source
address in the multicast packet exists in the database for the
specified multicast group and is in an INCLUDE list or is not listed
in an EXCLUDE list, the multicast routing protocol should add the
interface to the list of downstream interfaces; otherwise, it should
not be added based on local group membership.
3. DVMRP Interaction
The Distance Vector Multicast Routing Protocol (DVMRP) [DVMRP] does
not incorporate any knowledge of the multicast group's senders.
Therefore, DVMRP will act only on the multicast group address
contained in an IGMPv3 or MLDv2 report.
Future standardized versions of DVMRP may incorporate pruning and
grafting messages similar to PIM-DM (discussed in Section 5). The
rules defined in Section 5 can be applied in this situation.
Haberman & Martin Informational [Page 2]
RFC 5186 IGMPv3/MLDv2 and Multicast Protocols May 2008
4. MOSPF Interaction
In Multicast Extensions to OSPF (MOSPF) [MOSPF], the consideration of
source filter information in the group management database is limited
to the building of forwarding state (discussed above). This is due
to the flooding of group-membership-LSAs within MOSPF.
5. PIM-DM Interaction
The PIM-DM protocol [PIMDM] interaction with a source-filtering group
management protocol is important in two areas: multicast distribution
Show full document text