All things related to multicast

[Scott Brown <>]

Bill there are different models.. It is all new and disruptive, and these new 
models are not yet understood by many. The exciting thing is that it is all 
in production, and has global reachability. The two new pieces enabling this 
ecosystem is AMT and Octoshape technologies..

If we take the AT&T model in production today..

There are three components: Octoshape has a streaming server complex much 
like any other content delivery network. AT&T has a Multicast enabled 
backbone, but not always  all the way down to the broadband side of the last 
mile. They deploy AMT (Automatic Multicast Tunneling) relays. These are 
actually publicly accessible.

So as an example:
CNN distributes content for CNN.com Live, that can be delivered with or 
without multicast. Users can always get to that around the globe. However, 
that same video flow gets injected into the Native multicast backbone of 
AT&T, and therefore downstream to their AMT relays. 

The flow goes:
User tunes into CNN.com Live, they get a blast of data from Octoshape and 
starts streaming instantly. The user is good to go from here on out, there 
stream will not get interrupted. However Octoshape learns that there is a 
Native Multicast source available and attempts to make an IGMP join. If 
successful, it migrates to that seamlessly and drops almost all the server 
based data.  If that IGMP join, an anycast request is sent out to an AMT 
relay, and the nearest AMT relay responds joining the native multicast on 
behalf of the client. The multicast is tunneled the rest of the way.  It acts 
as a bridge where native multicast hasn't reached the edge yet. The most 
important thing is the user always gets video data which is the goal. The 
more AMT and Native multicast gets deployed the more efficient the flows get. 

Octoshape provides the transparent movement between the distribution types, 
(unicast, Native Multicast, and AMT Multicast), as well as adaptive bitrate 
support, and taking streaming formats that aren't multicast able (http based 
transports), and making them multicastable.  etc..

IPV6 is coming, we simply haven't had the strong customer push for it yet. 

Regarding Interdomian Multicast,  as Lenny states,  you could called public 
AMT Interdomain Multicast.. but again, we haven't found the need for it yet 
in our applications. It is quite easy for us to drop off a feed of the video 
data into many private Multicast domains, so it alleviates this concern for 
now.

Thanks for the questions.. but I echo Lenny's comments.  There is a body of 
mental knowledge and experience about how to deploy Multicast, and that has 
failed all but a very few applications. We have solved the problems now in 
the hardest places and broken down all the barriers to making it work, so as 
unfortunate and painful as it is to throw everything we have learned and 
experienced about Multicast to date, it is something we must do in order to 
see the new implementation methods that make it successful.

A couple of good presentations from NANOG 52:
http://www.nanog.org/meetings/nanog52/presentations/Monday/nortz-ATTMCast%20NANOG52.pdf
http://www.nanog.org/meetings/nanog52/presentations/Monday/brown-Octoshape%20MCast%20NANOG52-v5.pdf

Hope this was helpful.

-Scott
On Dec 17, 2012, at 3:12 PM, Bill Owens 
<>
 wrote:

> On Mon, Dec 17, 2012 at 03:03:48PM -0500, Scott Brown wrote:
>>   Just a quick comment on what is happening in the Internet at large, that
>>   you may be interested in.
>>   It is about content, but also about technologies coming together at the
>>   same time.
>>   Many Telco's actually have IPTV services running over Native Multicast,
>>   where they have implemented QOS on their last mile to create an
>>   environment for it. As you mention this is private and internal to
>>   footprint. However it is now beginning to take shape over the broadband
>>   side. You can see for instance using a combination of Native and AMT
>>   multicast that AT&T has deployed public Multicast support. Octoshape, the
>>   company I work for facilitates the streaming delivery for things like
>>   CNN.com Live, and NBA League pass over these broadband unmanaged
>>    Multicast enabled infrastructures.
>>   While it is true, it has spent many years in the dark, I believe it is
>>   quickly moving the opposite direction. 
>>   There is a lot of reading material about it here if you are interested:
>>   http://www.octoshape.com/showcase/juniper-openlab-multicast/
> 
> I'd heard about Octoshape a few years ago, and it's an interesting 
> application of a technology that I never thought would have any legs (AMT). 
> But I'm often wrong about predicting the adoption of new technologies - I 
> proselytized native multicast for many years ;) I didn't think that it 
> depended in any way on native multicast, though. Are you saying that these 
> networks are extending native multicast out to the edge equipment, or that 
> they're using it internally and letting Octoshape handle the last part of 
> the path? And are they using multicast intra- or inter-domain? I've heard 
> of streaming providers using it within their own networks, but not allowing 
> it to leave their boundaries. 
> 
> Bill.
> 
> PS - also, does Octoshape have an IPv6 story? I found something on your 
> website, but it was from June 2006. . .
> 
>