Subject: Re: [netlmm] #91: Re-establishing MN multicast listener state at new AR

From: netlmm <[email-masked]>
Date: Mon, 03 Jul 2006 09:26:35 -0000

#91: Re-establishing MN multicast listener state at new AR
-----------------------------------------+----------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  enhancement                 |      Status:  assigned               
  Priority:  major                       |   Milestone:                         
 Component:  draft-ietf-netlmm-mn-ar-if  |     Version:  1.0                    
Resolution:                              |    Keywords:                         
-----------------------------------------+----------------------------------
Changes (by [email-masked]):

  * status:  new => assigned

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/91>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: netlmm <[email-masked]>
Date: Mon, 03 Jul 2006 09:20:45 -0000

#91: Re-establishing MN multicast listener state at new AR
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     Type:  enhancement                 |      Status:  new                    
 Priority:  major                       |   Milestone:                         
Component:  draft-ietf-netlmm-mn-ar-if  |     Version:  1.0                    
 Keywords:                              |  
----------------------------------------+-----------------------------------
 James Kempf wrote:
 >
 > 4) The draft only discusses multicast in the context of address
 > configuration, in Section 4.1. draft-ietf-dna-protocol says that
 > the MN need not send out an MLD REPORT if DNA reports that the MN
 > has not moved to a new link. In a NETLMM domain, that will always
 > be the case, but the new AR won't have the multicast listener state
 > for the MN. I don't have any concrete proposal for solving this
 > problem, though I can think of a few suggestions, some of which
 > might require support from the NETLMM protocol itself.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 4 Jul 2006 14:09:25 +0200

James Kempf wrote:
 > the MN need not send out an MLD REPORT if DNA reports that the
 > MN has not moved to a new link. In a NETLMM domain, that will
 > always be the case, but the new AR won't have the multicast
 > listener state for the MN. I don't have any concrete proposal
 > for solving this problem, though I can think of a few
 > suggestions, some of which might require support from the NETLMM
 > protocol itself.

I think multicast listener state movement is pretty similar to 
movement of global unicast addresses: If DNA reports that the link 
hasn't changed, the MN does not DAD its global addresses, and sources 
RSs with its link-local while performing DNA, hence the new AR is 
unaware of previously configured global unicast. Likewise, the MN 
needs not to send an MLD REPORT, hence the new AR is unaware of 
previously joined multicast addresses.

IMHO this requires support from the NetLMM protocol: When a MN first 
configure a global unicast, its AR of attachment registers with the 
MAP the address. Then when the MN moves to a new AR, the MAP informs 
the new AR about the set of global unicast addresses that the MN has 
precedenly configured, because the new AR cannot figure them out by 
itself (e.g. they're not DADed)

Similarly, an AR could register/deregister the MN with the MAP for any 
multicast address that a MN join/leave. After movement, the MAP would 
inform the new AR of the current multicast listener state for this 
MN.

So I think this issue applies both to the MN-AR interface (needs to 
specify snooping of IGMP/MLD) and to the NetLMM protocol (needs to 
specify how to register/deregister multicast addresses for a MN.)

What do you think?

--julien

---

From: netlmm <[email-masked]>
Date: Mon, 17 Jul 2006 13:03:58 -0000

Comment (by [email-masked]):

 Possible resolutions: The re-establishment of the MN multicast listener
 state at new AR can be achieved by two means:

    1) state transfer from previous AR

    2) reconstruction of the state by new AR.

 1) requires supports from the NetLMM protocol so that ARs can transfer
 state when MNs move.

 2) requires no support from the NetLMM protocol as the state can be
 reconstructed using IGMPv3 or MLDv2.

 Proposed resolution: Specify that the AR MUST re-establish the multicast
 listener state for newly attached MNs. It SHOULD reconstruct this state
 using IGMPv3 or MLDv2 General Membership Query, and MAY use state transfer
 techniques which are out-of-scope of this specification.