Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction
draft-ietf-magma-igmpv3-and-routing-05

MAGMA Working Group                                         B. Haberman 
   Internet Draft                                         Caspian Networks 
   draft-ietf-magma-igmpv3-and-routing-05.txt                    J. Martin 
   October 2003                                                Netzwert AG 
   Expires April 2004                                                      
 
 
        IGMPv3/MLDv2 and Multicast Routing Protocol Interaction 
 
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [RFC 2026].  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents at any time. It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."  
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt.  
     
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
     
     
Abstract 
    
   The definitions of IGMPv3 and MLDv2 require new behavior within the 
   multicast routing protocols.  The additional source information 
   contained in IGMPv3 and MLDv2 messages necessitates multicast 
   routing protocols to 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 multicast routing protocols to 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 
    
  
Haberman, Martin                                                     1 
 

 
Internet Draft   IGMPv3/MLDv2 and Multicast Protocols     October 2003 
    
   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. 
    
   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 the group management database to 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 
        only 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 DVMRP protocol[DVMRP] 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 DVMRP to 
   interoperate with IGMPv3 and MLDv2. 
 
 
  3.1  DVMRP Prunes 
    

  
Haberman, Martin                                                     2 
    

 
Internet Draft   IGMPv3/MLDv2 and Multicast Protocols     October 2003 
    
   DVMRP prune messages are initiated when a DVMRP 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. 
    
  3.2  DVMRP Grafts 
    
   DVMRP graft messages are sent in order to override an existing DVMRP 
   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. 
    
    
4. MOSPF Interaction 
    
   In 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 
    
   Like DVMRP, PIM-DM[PIMDM] must utilize the source filter information 
   when generating Prune and Graft messages.  The following sections 
   describe the creation of these message types. 
    
    
  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 
  
Haberman, Martin                                                     3 
    

 
Internet Draft   IGMPv3/MLDv2 and Multicast Protocols     October 2003 
    
   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.  
    
    
  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 a 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 [PIMSM], [IGMP3], and 
   [MLDv2]. 
    
    
  
Haberman, Martin                                                     4 
    

 
Internet Draft   IGMPv3/MLDv2 and Multicast Protocols     October 2003 
    
9. Acknowledgements 
    
   The authors would like to thank Murali Brahmadesam, Leonard 
   Giuliano, and Hal Sandick for their feedback and suggestions. 
    
    
10. Authors' Addresses 
    
   Brian Haberman 
   Caspian Networks 
   753 Bridgewater Drive 
   Sykesville, MD  21784 
    
   brian@innovationslab.net 
   +1-410-552-1421 
    
    
   Jim Martin 
   Netzwert AG 
   An den Treptowers 1 
   D-12435 Berlin 
    
   jim@Netzwert.AG 
   +49.30/5 900 800-180 
    
    
11. References 
  11.1 Normative References 
   [IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version 
           3", RFC 3376, October 2002. 
    
   [MLDv2] R. Vida, et al., “Multicast Listener Discovery Version 2 
           (MLDv2) for IPv6”, work in progress. 
    
   [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", 
           work in progress. 
    
   [MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 
           1994. 
    
   [PIMDM] A. Adams, et al, "Protocol Independent Multicast - Dense 
           Mode: Protocol Specification (Revised)", work in progress. 
    
   [PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse 
           Mode (PIM-SM): Protocol Specification (Revised)", work in 
           progress. 
    
   [SSM]   H. Holbrook, et al, "Source-Specific Multicast for IP", work 
           in progress. 
 
      
    
  
Haberman, Martin                                                     5 
    

 
Internet Draft   IGMPv3/MLDv2 and Multicast Protocols     October 2003 
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2003).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS 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. 
    
    
 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
   This document expires in April, 2004. 

  
Haberman, Martin                                                     6