Opened 13 years ago

Closed 12 years ago

#91 closed enhancement (fixed)

Re-establishing MN multicast listener state at new AR

Reported by: julien.ietf@… Owned by: julien.ietf@…
Priority: major Milestone:
Component: draft-ietf-netlmm-mn-ar-if Severity:
Keywords: Cc:


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.

Change History (3)

comment:1 Changed 13 years ago by julien.ietf@…

  • Status changed from new to assigned

comment:2 Changed 13 years ago by julien.ietf@…

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.

comment:3 Changed 12 years ago by julien.ietf@…

  • Cc netlmm@… removed
  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.