All things related to multicast

[Dov Zimring <>]

I was a student of Kevin Almeroth's at UCSB and have the pleasure of 
putting my education to work in the Telecomm world.  Telcos are 
competing with cable head to head, building out infrastructure to 
provide video and other entertainment services along with their 
traditional product portfolio.

Most major telephone companies are in the process of defining their next
generation IP architectures to support multicast to the home for IP
Video delivery.  Many of the architectural discussions I've been exposed
to include the use of SSM to the edge and IGMPv3 in the home.  IPv6 and
MLD are out there on the horizon from my view and while the
architectures do not currently support subscribers as multicast sources,
they provide the majority of the plumbing necessary to allow for that.
There are a growing number of early adopters that have implemented IP
Video networks with PIM, SSM and some flavor of IGMP in the STBs.
That's the first major commercial push of IP Multicast into the home
that I'm aware of, albeit in a "walled garden".

When I look at endeavors like SBCs Project Lightspeed, Verizon's FiOS
and whatever BellSouth ends up calling theirs, I have to believe that
"over the top" content will grow into these walled gardens.  They may be
walled but there's 10s of millions of subscribers inside those walls and
all of them will have infrastructure in place to receive native IP
multicast to their home.  With a growing availability and consumption of
non-traditional video content, I think these networks may evolve to
start multicast peering with external content sources and each other.
It may not happen as fast as we'd like but I do think IP Multicast is
pushing its way into ubiquity.

--
Dov Zimring
Triple Play Architect
Occam Networks
work:   (805) 692-2903
mobile: (805) 705-8813
http://www.occamnetworks.com


Kevin C. Almeroth wrote:

> My personal belief is that if these apps were given more than
> just a binary try-it-and-if-it-doesn't-work-do-something-else,
> it might help...  hence the reason we've been looking at making
> the join process more robust.
>
> Of course, if the current state-of-the-art in protocols isn't
> being deployed, what hope do we have of improvement?
>
> -Kevin
>
> On Tue, 11 Oct 2005, John Kristoff wrote:
>
>  
>
> > > On Tue, 11 Oct 2005 19:40:27 -0400
> > > "Richard Mavrogeanes" 
> > > <>
> > >  wrote:
> > >
> > >      
> > >
> > > > Please don't flame me...I don't offer this as an advertisement but for
> > > > the opinion and thoughts of this august body :)  Rollover thas been
> > > > around for awhile but I don't recall seeing a discussion here...
> > > >        
> > > Halfway down the first page is this:
> > >
> > > As the name implies, unicast rollover first tries to view a video
> > > via multicast, but if multicast fails it will play the same video
> > > via multicast.
> > >
> > > You *will* use multicast!  MMwuahahah!  :-)  I don't think that is
> > > what you meant.
> > >
> > > It seems like a pretty nice approach that an application can take
> > > to me.  It might be nice if the source has a good feature set at
> > > their disposable to be able to do things like "only these netblocks
> > > can get the [unicast|multicast] stream", or only X simultaneous
> > > unicast streams permitted at one time and so on.
> > >
> > > John
> > >
> > >