[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Source addresses and multicast (was Re: Fwd: Minutes / Notes)



Erik Nordmark wrote:

I have to admit my ignorance here.  Any pointers that would allow
me to better understand what you say above?  Especially, I don't
understand if the "source" address you talk about is the source
address in a packet, or the addresses (locators) of the members
of a multicast group.

Steve Deerings PhD thesis explains it all :-)
Google finds some easier things at:
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=reverse+path+forwarding+multicast
but no good summary as far as I could tell.
(I think there was an mboned intro to multicast I-D somewhere but I can't find it).

In summary there is a source-rooted distribution tree which is independent
of the multicast group (which is carried in the destination address field).
The source rooted tree conceptually exists all the time and there is
a separate tree for every source address, but the actual tree is built
on demand - details depending on the multicast routing protocol which is
used.

The tree is then pruned based on the precence of members in the multicast group
to try to avoid to deliver packets down braches where there are no members
i.e. no interested receivers. The details of the tree pruning are different
for different multicast routing protocols.

The resulting issue for multihoming appears if a site wants
to forward packets towards the rest of the internet from more than
one attachment point.
If the same packet ends up with different source addresses/locators when exiting through N different border routers (e.g. due to source
locator rewriting by the routers) then the RPF checks will
operate on two different trees and as a result each receiver will receive
N copies of every packet.
Well, some of this depends on the multicast routing protocol in use
and the implementation.  Your description is much closer to what
dense mode protocols do for multicast forwarding (DVMRP and PIM-DM).
PIM-SM will build the distribution tree prior to data flowing.
When PIM-SM builds source-rooted trees, the RPF check will be built
on the Locator value, not the ID since the RPF is a topological
check.

The issue of multiple trees due to multi-homing can be modeled in
much the same way that multicast is implemented over load-balancing
links.  That is, a single forwarding entry is instantiated and
"locked" to a path.  Of course, you would probably lose forwarding
state during an outage.

With SSM, the forwarding entry will be tied to specific source
address.  In SSM and multi-homing this may have to be the ID
rather than the Locator, even though the Locator is needed for
the RPF check.

Regards,
Brian