summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5186.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5186.txt')
-rw-r--r--doc/rfc/rfc5186.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc5186.txt b/doc/rfc/rfc5186.txt
new file mode 100644
index 0000000..e6b610e
--- /dev/null
+++ b/doc/rfc/rfc5186.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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
+ tree pruning and multicast distribution tree grafting. The following
+ sections will describe the behavior needed in PIM-DM to interoperate
+ with IGMPv3 and MLDv2.
+
+5.1. PIM-DM Prunes
+
+ PIM-DM prune messages are initiated when a PIM-DM router determines
+ that there are no entities interested in the data flowing on the
+ (S,G) forwarding state. If the multicast router is running IGMPv3 or
+ MLDv2, this is determined by the source S being in EXCLUDE state in
+ the source filter for the destination G, or all interest in G being
+ terminated for an existing (S,G) forwarding entry.
+
+5.2. PIM-DM Grafts
+
+ PIM-DM graft messages are sent in order to override an existing PIM-
+ DM prune. In the case of IGMPv3 or MLDv2, this occurs when prune
+ state exists for (S,G) and a state change occurs in which the source
+ filter state for S changes to INCLUDE for the specified G.
+
+6. PIM-SM Interaction
+
+ A PIM-SM interaction takes place when a PM-SM [PIMSM] router receives
+ an IGMP or MLD message regarding a group address that is in the Any
+ Source Multicast (ASM) range. This range is defined as the entire
+ multicast address space excluding the global SSM range [SSM] and any
+ locally defined Source Specific space.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Martin Informational [Page 3]
+
+RFC 5186 IGMPv3/MLDv2 and Multicast Protocols May 2008
+
+
+6.1. PIM-SM Joins (ASM Behavior)
+
+ PIM-SM join messages are initiated when a PIM-SM router determines
+ that there are entities interested in a specific group or a specific
+ source sending to the group. If this is due to an IGMPv3 or MLDv2
+ report with a zero-length EXCLUDE list, then the join is sent as a
+ (*,G) join towards the RP.
+
+ If the join is triggered by an IGMPv3 or MLDv2 state change that
+ affects source information, the PIM-SM join is sent as a (S,G) join
+ towards the specific source. This behavior optimizes the join
+ process, as well as facilitates the adoption of the SSM model. The
+ generation of this (S,G) join can cause failures in architectures
+ where leaf routers do not have global reachability, and thus, can be
+ overridden by local policy. If this is the case, then all triggered
+ joins are sent towards the RP as (*,G) joins. The router sending the
+ (*,G) join is responsible for filtering the data as per the IGMPv3
+ database before forwarding.
+
+6.2. PIM-SM Prunes (ASM Behavior)
+
+ PIM-SM prune messages are initiated when a PIM-SM router determines
+ that there are no entities interested in a specific group, or a
+ specific source sending to the group. If this is triggered by either
+ receiving a report with an EXCLUDE or if a specific Source/Group
+ times out, then an (S,G) prune is sent towards the upstream router.
+ If all of the IGMPv3 or MLDv2 derived requests for a group time out,
+ then (S,G) and (*,G) prunes are sent upstream as needed to stop all
+ flow of traffic for that group.
+
+7. PIM-SSM Interaction
+
+ A PIM-SSM interaction takes place when a PIM-SM router receives an
+ IGMPv3 or MLDv2 message regarding a group address that is in the
+ Source Specific Multicast range. This behavior is not defined in
+ this document, but rather in [PIMSM].
+
+8. Security Considerations
+
+ This document does not introduce any additional security issues above
+ and beyond those already discussed in [PIMDM], [PIMSM], [IGMP3], and
+ [MLDv2].
+
+9. Acknowledgements
+
+ The authors would like to thank Murali Brahmadesam, Leonard Giuliano,
+ and Hal Sandick for their feedback and suggestions.
+
+
+
+
+Haberman & Martin Informational [Page 4]
+
+RFC 5186 IGMPv3/MLDv2 and Multicast Protocols May 2008
+
+
+10. Normative References
+
+ [IGMP3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version 3",
+ RFC 3376, October 2002.
+
+ [MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
+ Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+ [DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
+ Multicast Routing Protocol", RFC 1075, November 1988.
+
+ [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
+ 1994.
+
+ [PIMDM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent
+ Multicast - Dense Mode (PIM-DM): Protocol Specification
+ (Revised)", RFC 3973, January 2005.
+
+ [PIMSM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601, August 2006.
+
+ [SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
+ RFC 4607, August 2006.
+
+Authors' Addresses
+
+ Brian Haberman
+ The Johns Hopkins University Applied Physics Laboratory
+ 11100 Johns Hopkins Road
+ Laurel, MD 20723-6099
+ US
+
+ Phone: +1 443 778 1319
+ EMail: brian@innovationslab.net
+
+ Jim Martin
+ Woven Systems
+ 2455 Augustine Drive, Suite 211
+ Santa Clara, CA 95054
+ US
+
+ Phone: +1 408 654-8143
+ EMail: jim@wovensystems.com
+
+
+
+
+
+
+Haberman & Martin Informational [Page 5]
+
+RFC 5186 IGMPv3/MLDv2 and Multicast Protocols May 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Martin Informational [Page 6]
+