Subject: RE: [mobile-ip] Issue 63: Multicast

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 16 Jul 2002 02:41:10 -0400

Firstly..apologies for the long mail...

I discussed this briefly with Jari after the wg last night to raise concerns
about the stated resolution for this issue in the meeting. Jari suggested I
post a little more text to the wg on this issue so that the problem with the
stated direction is clearer.

The suggested resolution was that the use of the home multicast system via a
bi-directional tunnel be included in the spec (fine) but that a MN can
optionally use, for the foreign multicast system, its CCoA as a source
address (not fine) to originate traffic to a multicast group, and that the
detailed mechanisms for this would be detailed in draft-oneill-multicast
etc..

The problem with the latter (CCoA based origination into the foreign
multicast system) is that a MN multicast originator never knows about the
location or number of the receivers on a multicast group, and multicast
groups can use different types of tree building mechanisms (multicast
protocols) in different operator domains. For global multicast groups there
is also an inter-domain tree building protocol which interconnects the trees
in different domains.

Now some of these tree building protocols, including the current
inter-domain protocol (MSDP), build source specific multicast trees where
the source address is installed into the multicast routing entry in each
router on the source specific branch of the multicast tree. These source
trees can specifically be end to end between the MN sender and all group
receivers. Note that the other extreme is that the tree can also have no
sender specific branches with minimal source specific entries limited to the
edge routers only (multicast Designated Routers). The MN nevers knows where
its tree is between these two extremes except possibly for groups scoped to
the foreign domains only (via policy / profile)..

Clearly then, if the MN uses its CCoA as a multicast source address, and
that CCoA is evolving rapidly as the MN moves, then all the source specific
multicast router entries on all source specific branches for all receivers,
need to be updated from the old to the new CCoA at hand-over speed. The
clear danger here is huge thrashing of the multicast routing system with big
groups and/or large numbers of MNs. Therefore, I don't think it is
reasonable to have the base spec enable a MN to use its CCoA as a source
address. It is as dangerous and unscalable (possibly more so) as supporting
MN movement in the unicast routing system by using host routes rather than
MIP edge tunnel redirection. I hope that is clear but am aware there are
differences of opinion so lets thrash that out.

Assuming the above is a fair statement, then it is next clear that the only
stable parts of a MNs address as it moves, which could be safely installed
into the foreign multicast routing state, is either its HoA or the
InterfaceID part of a universal CCoA. There are potential slowly moving
changes to multicast routing protocols (that need significant investigation)
that might enable the MN to scalably originate packets into the foreign
multicast system. Therefore, draft 18 should refer to this future
possibility. However, this work can only progress with significant buy-in,
support and work from the multicast community and I have therefore started
some effort in stimulating awareness of the issue with the relevant ADs and
chairs.

In parallel with this, there are some potential shorter term work arounds
which might be possible which involve modifying the MIP/multicast interface
rather than the multicast protocols themselves. These protocol specific
solutions are not appropriate for standardisation but might be useful within
specific domains here the operator knows what they are doing.. The protocol
specific fixes might however be useful to put in an Informational RFC. One
of these interim workarounds however seems to be reasonably general (and yes
hacky and maybe long-lived) which we could put into the base spec as the
sole option for foreign multicast origination, but this does come with some
future costs.

The interim solution is hybrid multicast whereby the MN joins group G as a
receiver into the foreign multicast system via MLD and normal multicast
mechanisms will build the tree for that group G receiver branch towards the
sender(s) on that group. In addition, the MN originates multicast to the
group using its HoA by reverse tunnelling it to the home network, where it
is injected into the home multicast system as a non-member sender on group
G. No MLD signalling is therefore sent to the HA so the HA must be prepared
to forward such multicast onto the home subnet where multicast mechansims
will need to inject it into the group G tree. The packets must be sent to
the Home subnet so that they will pass the multicast RPF check on the HoA
multicast source address. These HoA originated packets will come down the
multicast tree and arrive back at the MNs access router where there is MLD
state for group G. The HoA sourced packets needs to be delivered to other
members of group G on that multicast router, but should ideally not be
delivered to the MN that owns the HoA in the source address of the multicast
packet. This can only be achieved through the MN sending an MLD join to the
access router for which it specifically excludes itself from receiving
packets with HoA as a source address (source pruning..via exclude). This
should work although it needs to be closely reviewed. The cost though is
that the MN needs to know to do this which means an assumption is being made
about the nature of multicast protocol support in the foreign domain. If
that support changes, then we need a way to upgrade MNs with a replacement
mechanism so that they can completely exploit the foreign multicast system.
In addition, given that all domains will not upgrade their intra-domain
multicast protocols at the same time, we need to ensure that incremental
deployment is possible so that once a MN originates into the foreign
multicast system, subsequent instabilities are not introduced into
downstream domains...

So I would suggest that in base MIPv6 we bar the use of the CCoA as a MN
multicast source address for now (and possibly for ever to be repalced by
the HoA). We can allow home multicast and potentially allow hybrid multicast
with the latter requiring some discussion. What is not in base spec should
go into future revisions of draft-oneill -mip-multicast.. and evolved into a
wg draft. We can get a few interested parties to explore the issues and work
with the multicast community on this. This will no doubt be a long term
effort but we should be able to state the immediate problem and the ideal
requirements, and then pass to the multicast folks. We then need to stick
around and help them build some appropriate longer term solutions...

Finally, also note that the multicast text and mechanisms in RFC3220 needs
to be updated to restrict MN origination into the foreign multicast system
using a CCoA, with similar reasons and options. The hybrid model is again
applicable but this case has the advantage though that the FA can redirect
the non-member sender multicast to the HA and hence hide the type of
multcast support from the MN..

I hope that clarifies the problem to all and lays done a useful way forward
for the base spec and for MIP/multicast. I'll also put up some basic slides
to illustrate this a bit better on the Flarion site and repost feedback from
the multicast community on their view of these issues.

Alan.

****************************************************************************
************************************
This email may contain confidential and privileged material for the sole use
of the
intended recipient. Any review or distribution by others is strictly
prohibited.
If you are not the intended recipient please contact the sender and delete
all copies.
****************************************************************************
*************************************

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Jul 2002 16:09:56 +0200 (CEST)

> detailed mechanisms for this would be detailed in draft-oneill-multicast

The way I see this both approaches have performance issues of different
flavors. Reverse tunneling packets through the HA adds delay for packets
(and is subject to additional potentially congested devices in the network).
Using the CoA as the source causes multicast routing related overhead 
as you point out.
Thus I don't think we can say that one is strictly better than the other;
the performance issues aren't comparable.
Hence I don't see a need to prohibit sending packets with the CoA
as the source.

> It is as dangerous and unscalable (possibly more so) as supporting
> MIP edge tunnel redirection.

I suspect there are cases when reverse tunneling is equally "dangerous and 
unscalable" - it all depends on the assumptions.
So either we allow both ways (and provide future documentation with guidance
on the issues and tradeoffs between them) or we forbit both.

There are similar issues for the joining of multicast groups.
If it is done using the local interface (the "CoA") then the multicast
tree will change as the MN moves, which is bad. 
If it is done over the reverse tunnel (the "HoA") then the multicast
packets will be tunneled from the HA even though copies of the same
multicast packets might already be present on the visited link.

Also in that case I think both approaches make sense under different
cicumstances.

   Erik