Skip to Content.
Sympa Menu

wg-multicast - Re: This coming year's multicast working group goals

Subject: All things related to multicast

List archive

Re: This coming year's multicast working group goals


Chronological Thread 
  • From: Tim Chown <>
  • To:
  • Subject: Re: This coming year's multicast working group goals
  • Date: Wed, 12 Oct 2005 09:41:34 +0100

On Wed, Oct 12, 2005 at 12:37:30AM -0400, Tom Pusateri wrote:
>
> Actually, I think we've learned a bit.
>
> MBONEv1 was about connecting islands of multicast in any random way
> to connect interested parties. And the worst part about it was the
> broadcast and prune, not the tunnel part.
>
> AMT is really about tunneling from a multicast core network or
> internetwork through the edge provider where multicast isn't being
> enabled for non-technical reasons. It basically replicates at the
> leaves of the multicast tree because either the switches are not
> multicast enabled or the edge provider doesn't want to allow multicast
> content in from external sources.
>
> In my opinion, this latter problem will never go away, because
> you're not trying to solve a technical problem. So AMT or something
> equivalent (like application level multicast) is here to stay because
> it solves a real problem.

You could take the above mbone text and with minimal edits it could be
written about IPv6. The original 6bone (detectable but not defined by
use of the 3ffe::/16 prefix) was about "connecting islands of <foo> in
any random way" where foo was IPv6. In theory old 6bone prefix usage
should stop on 6/6/6.

Now IPv6 has matured. In the same places as multicast too, if you take
the NREN and acadmic network view.

IPv6 access is now more about 'structured' access from the CPE to the ISP
'edge' in a way that meets the requirements of users and ISPs. The last
(final?!) new IETF WG on IPv6 is 'softwires', which is addressing this
very issue. I wonder how much it has in common?

> In addition, AMT provides the security aspects of a unicast stream
> at the edge while allowing the bandwidth savings at the source and
> across the core required to scale. Its a very practical solution.

And with IPv6 we have mechanisms like TSP that enable some authentication
for tunnels.

> Multicast is most useful when nothing else will work. If you can
> solve the problem with unicast, then use unicast. Don't force the
> use of multicast just because its cool.

s/unicast/IPv4, s/multicast/IPv6.

Now, who's for IPv6 and multicast together? No, wait, that's m6bone!
Well it is, but m6bone is a 'random' but simple (single RP) tunnel
topology... we need to push on to more interesting native topologies, and
embedded-RP.

Can we learn anything from the apparently very common tales of two 'cool'
technologies?

--
Tim/::1





Archive powered by MHonArc 2.6.16.

Top of Page