Re: Joining to SSM sources that are IPv6 mobile nodes

["Brian Haberman" <haberman@nortelnetworks.com>]

Dave,
     I prefer method 2.  Trying to get BUs to all group members
in order to make SSM work seems overly complicated.  Let the
group members think the MN is always at home sourcing the
multicast data.

Brian

Dave Thaler wrote:
> 
> Sorry for the cross-post, but this issue really does concern
> interactions between drafts in three different WGs:
> MobileIP: draft-ietf-mobileip-ipv6-14.txt, section 10.19
> MAGMA: draft-vida-mld-v2-01.txt
> SSM: draft-ietf-ssm-overview-01.txt
> (Please trim the recipients when responding, if appropriate.)
> 
> Starting from the Mobile IPv6 spec:
> > A mobile node that wishes to send packets to a multicast group
> > also has two options:  (1) send directly on the foreign link being
> > visited; or (2) send via a tunnel to its home agent.  Because
> > multicast routing in general depends upon the Source Address used in
> > the IPv6 header of the multicast packet, a mobile node that tunnels a
> > multicast packet to its home agent MUST use its home address as the
> > IPv6 Source Address of the inner multicast packet.
> 
> The issue is how to continue getting data to receivers after a mobile
> node moves.
> Method (2) works fine for SSM, but has the obvious inefficiency.
> Method (1) does not work as is for SSM.
> 
> I'll assume the sender has advertised (HA,G) in whatever method (e.g. a
> web page) he uses to announce the session, just like the session would
> advertise HA in any method used to get unicast clients to connect to
> him.  (The sender could just as well use (COA,G) but the same issues
> arise if it subsequently moves, from my understanding.)
> 
> In the SSM model, when receivers join (HA,G) via MLDv2, join state is
> constructed along the path to HA (i.e. hitting the home agent).  Any
> data sent directly on the foreign link being visited will go nowhere,
> since there is no join state there.
> 
> A bad answer would be "do nothing, we don't care if sourcing SSM is
> broken".
> 
> A simple answer would be "an SSM source MUST use option (2), i.e.
> tunnel packets to the home agent".  In this case, either option (1)
> would never be used for any multicast traffic, or else the host would
> have to know whether a receiver might want to use an include-mode list
> with MLDv2 and tunnel to the home agent if so.  Personally, I don't
> like this answer, but if this is what the consensus turns out to be,
> then it should be documented in the Mobile IPv6 spec (no effect on the
> SSM or MAGMA WGs), and apis to inform the mobile node stack that it
> MUST tunnel to the home agent may be required.
> 
> Another answer, which would require adding rules to both the Mobile
> IPv6 and MLDv2 specs (and probably mentioning it in the SSM overview
> doc), would be to make method (1) work for SSM sources.  A potential
> solution here is twofold:
> 
> 1) If an MLDv2 host is sending an include-mode report for a source X,
> and a binding cache entry exists for X with a care-of-address COA, then
> put both X and COA in the membership report.  (This means that if you
> can somehow get a Binding Update to all the group members, then they'll
> be able to receive packets sourced from COA, since routers will
> construct join state back to the foreign link.)  It needs to join to
> both addresses so that if the node moves again, it won't be stuck
> waiting for data from the old COA.
> 
> 2) A mobile node sourcing traffic when away from home needs to get a
> Binding Update to all the group members.  I believe this can be done by
> tunneling a packet via the home agent (and hence must have a source
> address of its home address) which contains a Binding Update with
> an Alternate Care-of Address of its current COA.  This would need to be
> done periodically, so that new receivers get it.
> 
> Comments?  Am I missing anything?
> 
> -Dave Thaler