RE: Joining to SSM sources that are IPv6 mobile nodes

["Michael Luby" <luby@digitalfountain.com>]

Dave,

I think that neither of these options is necessarily the right answer all
the time, as this seems to me to be more of an application service issue
rather than a networking service issue.

For example, an application could implement the solution to 1 that you
propose below at the application level in pretty much the same manner
(without additional explicit network support).  The idea would be for the
roaming source to always send its current address to its permanent home
address (at the application level), and then the home server would always
send out the current address of the source through an application level SSM
announcement channel.  In this solution, the roaming source would send its
data multicast packets using its local source address.

As another example, at the application level, solution 2 could also be used,
where the roaming source always tunnels its multicast packets back to its
permanent home address, and then these are sent out using SSM from the home
address.

There are other ways of doing this as well, but I believe that they should
be done at the application level specific to each application, and not at
the network services level.  I like the philosophy of building a simple but
robust common denominator network service (like SSM), rather than trying to
build too much of the complexity into this level (like MSDP) that could be
done more efficiently and simply at the application level (because one
doesn't have to provide a general implementation at the application level,
only a much simpler implementation particular to the application).  The
problem with doing this at the network level is that it will either be too
general (and thus hard to implement and scale) or else too restrictive.

Mike

-----Original Message-----
From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
Sent: Wednesday, September 26, 2001 7:05 PM
To: mobile-ip@sunroof.eng.sun.com; magma@innovationslab.net;
ssm-interest@external.cisco.com
Subject: Joining to SSM sources that are IPv6 mobile nodes


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