Subject: [mobile-ip] Joining to SSM sources that are IPv6 mobile nodes

From: "Dave Thaler" <[email-masked]>
Date: Wed, 26 Sep 2001 19:05:04 -0700

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Sep 2001 12:23:31 +0200

=> IMHO only the method 2 (i.e. to use a bidirectional tunnel between
the MN and the HA, and of course the home address as the source) is
reasonnable. But I wait for folks who have worked with (traditional)
multicast for mobile nodes.

Regards

[email-masked]

PS: method 2 is not always inefficient, but this is always simple
(apply KISS principle? :-)

---

From: "Brian Haberman" <[email-masked]>
Date: Thu, 27 Sep 2001 09:26:28 -0400

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

---

From: Rolland Vida <[email-masked]>
Date: Thu, 27 Sep 2001 18:08:21 +0200

Dave et al.,

Solution 2 is obviously the simplest one. However, solution 1 might prove
to be not as bad as it looks like. Brian said "Let the
group members think the MN is always at home sourcing the multicast data."
In fact, you could use your proposed solution 1 without the receivers being
aware of the MN's address change. The MN should advertise its new CoA to
the edge routers, and not to the receivers. Edge routers then will send a
PIM-SSM join message to the CoA, and a second SSM tree is built. This will
be done transparently for the receivers.
There's of course the problem that even if data will arrive on the new CoA
SSM tree, receivers will drop the packets as the source address is not OK
for them. A possible solution for that is to do NAT in the edge routers,
and change back the source address to the home address, before forwarding
the data to their receivers. I agree however that this solution is a lot
more complicated than a simple tunneling.

> Either option (1) would never be used for any multicast traffic, or else
> the host would
> with MLDv2 and tunnel to the home agent if so.

You can make the difference between an SSM and an SM connection by the
group's address. There's a specific SSM address range, and it is supposed
that you do not do PIM-SM  in the SSM range.

More generally, I think that the problem has a lot in common with the
problem of reliability in an SSM environment. Imagine that you have an SSM
source, and a potential repair server somewhere downstream. If data gets
lost, only the source can send repair data. If you want to use the repair
server, you should probably create a second SSM tree, rooted at the repair
server. In addition, repair servers could move, or in fact could be
activated or deactivated in certain conditions. There are some papers on
this issue by people from UMASS. The point is that you will have to
constantly join and leave different SSM repair trees, like the different
CoA trees. Somehow similar, isn't it?

Ok, I'm a bit far from the strating point. But it's an interesting issue I
think

Regards,
Rolland Vida.

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 27 Sep 2001 09:56:25 -0700

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:[email-masked]]
Sent: Wednesday, September 26, 2001 7:05 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Joining to SSM sources that are IPv6 mobile nodes

-Dave Thaler

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 27 Sep 2001 09:56:25 -0700

Dave,

Mike

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 7:05 PM
To: [email-masked]; [email-masked];

-Dave Thaler