Internet DRAFT - draft-ietf-idmr-igmpv3-and-routing

draft-ietf-idmr-igmpv3-and-routing




   IDMR Working Group                                          B. Haberman 
   Internet Draft                                                J. Martin 
   draft-ietf-idmr-igmpv3-and-routing-01.txt               Nortel Networks 
   July 2001                                                               
   Expires January 2002                                                    
 
 
           IGMPv3 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 definition of IGMPv3 requires new behavior within the multicast 
   routing protocols.  The additional source information contained in 
   IGMPv3 messages necessitates multicast routing protocols to manage 
   and utilize the information.  This document will describe how IGMPv3 
   and multicast routing protocols interact. 
    
    
1. Introduction 
    
   The definition of IGMPv3[IGMP3] requires new behavior within the 
   multicast routing protocols.  The additional source information 
   contained in IGMPv3 messages necessitates multicast routing 
   protocols to manage and utilize the information.  This document will 
   describe how IGMPv3 and multicast routing protocols interact. 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119. 
    
    
2. Multicast Forwarding State 
  
Haberman, Martin                                                     1 
 

 
Internet Draft      IGMPv3 and Multicast Protocols           July 2001 
    
   Existing multicast routing protocols utilize the IGMP database in 
   determining if local members exist for a particular group.  In the 
   case of IGMPv3, these routing protocols must now build multicast 
   forwarding state based on the source filter information available 
   for each multicast group that has local membership. 
    
   The source filter state available in the IGMPv3 database should be 
   utilized when generating forwarding state for a multicast group.  If 
   the source address in the multicast packet is included in the IGMPv3 
   database for the specified multicast group, 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. IGMP Version Transitions and Routing Protocol Interaction 
    
   IGMP version 3 specifies that if at any point a router receives an 
   older version query message on an interface that it must immediately 
   switch into a compatibility mode with that earlier version. Since 
   none of the previous versions of IGMP are source aware, should this 
   occur and the interface switch to Version 1 or 2 compatibility mode, 
   any previously learned group memberships with specific sources 
   (learned via the INCLUDE or EXCLUDE mechanisms) MUST be converted to 
   non-source specific group memberships. The routing protocol will 
   then treat this as it would the receipt of an IGMPv3 report message 
   with a zero-length EXCLUDE list. 
    
4. DVMRP/IGMPv3 Interaction 
    
   The DVMRP protocol[DVMRP] interaction with IGMPv3 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. 
 
  4.1  DVMRP Prunes 
    
   DVMRP prune messages are generated when a router determines that 
   there are no longer any interested downstream listeners.  The DVMRP 
   protocol builds prune information that contains both destination 
   group address and source network information. 
    
   When DVMRP routers implement IGMPv3, the source filter information 
   in the IGMPv3 database must be used in the creation of DVMRP prune 
   messages.  When IGMPv3 state changes (e.g. Report message received 
   with EXCLUDE state) and forwarding state exists for a particular 
   (S,G), DVMRP will create a prune containing the specified group and 
   source information. 
    
  4.2  DVMRP Grafts 
    
   DVMRP graft messages are generated when local group membership state 
   changes and a DVMRP prune is in place for the requested group 
  
Haberman, Martin                                                     2 
    

 
Internet Draft      IGMPv3 and Multicast Protocols           July 2001 
    
   address.  The graft message overrides the prune state and should 
   result in the resumption of multicast flow for the requested group. 
    
   When DVMRP routers implement IGMPv3, the source filter information 
   in the IGMPv3 database must be used in the creation of DVMRP graft 
   messages.  State changes in the IGMPv3 database that renders 
   existing prune state obsolete must result in the creation of a DVMRP 
   graft message.  
    
5. MOSPF/IGMPv3 Interaction 
    
   In MOSPF[MOSPF], the consideration of IGMPv3 source filter 
   information is limited to the building of forwarding state 
   (discussed above).  This is due to the flooding of group-membership-
   LSAs within MOSPF. 
    
    
6. PIM-DM/IGMPv3 Interaction 
    
   Like DVMRP, PIM-DM[PIMDM] must utilize the IGMPv3 source filter 
   information when generating Prune and Graft messages.  The following 
   sections describe the creation of these message types. 
    
  6.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, 
   this is determined by the source S being EXCLUDED in the source 
   filter for the destination G or all interest in G being terminated 
   by a Leave message for an existing (S,G) forwarding entry. 
    
  6.2  PIM-DM Grafts 
    
   PIM-DM graft messages are sent in order to override an existing PIM-
   DM prune.  In the case of IGMPv3, this occurs when prune state 
   exists for (S,G) and an IGMPv3 state change occurs in which the 
   source filter state for S changes to INCLUDE for the specified G. 
    
7. PIM-SM/IGMPv3 Interaction 
    
   A PIM-SM/IGMPv3 interaction takes place when a PM-SM [PIMSM] router 
   receives an IGMP message regarding a group address that is in the 
   Any Source Multicast (ASM) range. This range is defined as the 
   entire Class D Multicast space excluding the global SSM range [SSM] 
   and any locally defined Source Specific space.  
    
  7.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 report with 
  
Haberman, Martin                                                     3 
    

 
Internet Draft      IGMPv3 and Multicast Protocols           July 2001 
    
   a zero-length EXCLUDE list, then the join is sent as a (*,G) join 
   towards the RP. 
    
   If the join is triggered by the reception of an IGMPv3 report that 
   contains source specific information, the 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. It 
   also can cause failures in some specific network architectures, and 
   thus, can be overridden by local policy. If this is the case, then 
   all IGMPv3 triggered joins are sent towards the RP as (*,G) joins. 
   The initiating router is responsible for filtering the data before 
   forwarding to the requesting network.  
    
  7.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 an IGMP report with an EXCLUDE or if a specific IGMP 
   derived Source/Group times out, then an (S,G) prune is sent towards 
   the upstream router. If all of the IGMP 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.  
    
8. PIM-SSM/IGMPv3 Interaction 
    
   A PIM-SSM/IGMPv3 interaction takes place when a PIM-SM router 
   receives an IGMP message regarding a group address that is in the 
   Source Specific Multicast range. This range is defined as the global 
   SSM range and any locally defined Source Specific space. 
    
  8.1  PIM-SM Joins (SSM Behavior) 
    
   PIM-SM join messages are initiated when a PIM-SM router determines 
   that there are entities interested in specific sources sending to 
   the group. If this is due to an IGMPv3 report with source specific 
   information, then a (S,G) join is sent towards the specific sources.  
   If an IGMPv3 report with a zero-length EXCLUDE list is received, it 
   MUST be ignored. 
    
  8.2  PIM-SM Prunes (SSM Behavior) 
    
   PIM-SM prune messages are initiated when a PIM-SM router determines 
   that there are no entities interested in specific sources sending to 
   the group. If this is triggered by either receiving an IGMP report 
   with an EXCLUDE or by an IGMP timeout, then a (S,G) prune is sent in 
   the direction of the source.  
    
9. Outstanding Issues 
    
   The following is a list of open issues that need to be addressed: 
           - More detailed protocol descriptions 
  
Haberman, Martin                                                     4 
    

 
Internet Draft      IGMPv3 and Multicast Protocols           July 2001 
    
           - SSM behavior in DVMRP, MOSPF, and PIM-DM? 
           - Security issues 
    
    
10. Security Considerations 
   TBD. 
    
11. Acknowledgements 
    
   The authors would like to thank Murali Brahmadesam, Leonard 
   Giuliano, and Hal Sandick for their feedback and suggestions.  
    
12. Authors' Addresses 
    
   Brian Haberman 
   Nortel Networks 
   300 Perimeter Park 
   Morrisville, NC  27560 
   1-919-905-7484 
   haberman@nortelnetworks.com 
    
   Jim Martin 
   Nortel Networks 
   4401 Great America Parkway 
   Santa Clara, CA  95054 
   1-408-495-3792 
   jrm@nortelnetworks.com 
    
13. References 
 
   [IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version 
           3", work in progress, March 2001. 
    
   [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", 
           work in progress, August 2000. 
    
   [MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 
           1994. 
    
   [PIMDM] S. Deering, et al, "Protocol Independent Multicast - Dense 
           Mode Specification", work in progress, ???. 
    
   [PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse 
           Mode (PIM-SM): Protocol Specification (Revised)", work in 
           progress, March 2001. 
    
   [SSM]   G. Shepard, et al, "Source-Specific Protocol Independent 
           Multicast in 232/8", work in progress, April 2001. 
    



  
Haberman, Martin                                                     5