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 distributionShow full document text