Re: multicast-transition

[Radia Perlman - Boston Center for Networking <radia@bcn.East.Sun.COM>]

Re Dino's note:

Not sure I understand your note, or maybe you misunderstood mine.

	>> The first multicast aware router along the path notices the message
	>> and creates a tunnel to the source address in the IP header.
	
	    In most cases, a router doesn't know it is the first multicast 
router.
	    With topology changes, you need the Join to be sent periodically so
	    it can time out the tunnel state in the multicast router.


The router doesn't have to decide whether it's the first multicast router.
if it sees the join, then it's the first one that saw it. The only
issue is on LANs, and maybe that's what you're talking about...the
routers on a LAN have to decide which of them will forward packets off
that LAN towards the set of IP addresses that include the root node.
So for instance if the first endnode sends to the "wrong" router, that
router has to forward it to the "right" router. But PIM does all
this sort of stuff anyway. None of those mechanisms need to change.

As for the paths changing...yes, you need periodic joins (keepalives),
and old unused paths should atrophy. Again, doesn't PIM do all that
anyway? I don't think there's anything different.
	
	    Also this is not trivial to do in existing hardware from the 
multicast
	    router's point of view. When a router is in it's replication loop, 
there
	    are no changes to the IP header, just changes to the layer-2 header.
		    This solution requires the destination IP address to be 
rewritten and
	    an entire IP header checksum recalculation (partial checksum will be
	    hard in this case). You effectively put NAT in the fast-path.
	
Again, not sure what you're saying here. A tunnel is IP in IP. There's
an outer IP header that specifies as the destination the tunnel endpoint.
Routers on the "inside" of the tunnel just forward it like an ordinary
IP packet. Routers on the end have to take off the IP header just
as if the IP header is a layer 2 header. Any tunneling solution will
have this problem. And once all the routers get upgraded to be multicast
routers, multicast just gets forwarded like ordinary layer 3 multicast.
THe IP header checksum doesn't need to be recalculated. The outer
header just gets stripped off. If you have to forward across a tunnel
rather than to a neighbor, then you have to add an IP header, including
an IP checksum. But again, that's what tunnels do.

One of the early encodings suggest for Simple Multicast spec tried to
create a tunnel without an extra IP header by rewriting the dest address
to be the tunnel endpoint, but after comments from router
implementers, that cleverness turned out to be too much trouble (not
sure I remember all the reasons why, perhaps it involved what you're
talking about with recalculating the IP checksum),
and merely putting on a complete extra IP header specifying the destination
to be the tunnel endpoint was simpler. So maybe that's what you were
referring to.

Radia