All things related to multicast

[Leonard Giuliano <>]

On Fri, 4 Mar 2011, Zenon Mousmoulas wrote:

-) Dear all,
-) 
-) It's encouraging to see that AMT is gaining momentum, bringing renewed 
interest to IP multicast. However, in the interest of moving forward, and 
especially if we are to consider AMT deployment, I think there are some 
practical questions that beg for (public) answers:
-) 
-) a) AMT implementations:
-) - Juniper supports AMT relay (only) from 10.3 (maybe 10.2?). However 
-) the implementation doesn't seem complete, e.g. it doesn't support ipv6 
-) or mcast sources on AMT gateways (I'm not sure there would be much use 
-) for the latter). JUNOSe support perhaps would make sense for pushing 
-) AMT relays closer to broadband users (in existing/legacy deployments).

Mcast sourcing behind a GW is theoretically possible, and is mentioned in 
the spec.  But it was never given a ton of thought as it was always found 
to be very difficult to figure out how exactly it would work and 
eventually folks just gave up and decided it wasn't worth the effort.  To 
my knowledge, there are no implementations that support sourcing, and I 
doubt that will change soon.  On a practical level, I think it's fair to 
consider AMT to be a receiver-only solution.

Personally, AMT in v6 never made sense to me.  If someone if going through 
the effort to enable their network for v6, it only makes sense to enable 
mcast since you are already under the hood touching all your network 
devices.  Seems like this was a bad assumption- to my surprise, mcast is 
frequently not even on the radar for many when enabling v6.  I wish it 
could be made a strong recommendation to turn on mcast when turning on 
v6.  In any event, again, I don't think there are any AMT implementions 
for v6 out there, but as v6 adoption increases, I suspect that would 
change.

-) - I remember Cisco being mentioned for supporting (funding) the UTDallas 
implementation, but I have yet to see any products featuring AMT. Are we 
missing something?
-) - Other vendors?
-) - What about AMT (gateway) implementations on residential gateways?
-) - How about native OS support? I remember reading[1] about possible 
conflicts between AMT and host IGMP/MLD stacks, e.g. where there was native 
multicast connectivity and AMT should back off, or where an IGMP v2 downgrade 
affected AMT functionality. A natively integrated stack would supposedly be 
able to better handle such cases.
-) - The UTDallas implementation seems frozen around 2008. The web site and 
documentation are somewhat terse; it would be nice to know at least whether 
it is still functional and how far it is from the current AMT draft.
-) - Are there any other (public) host-based implementations?
-) - Regarding Octoshape: Is there any public technical information (perhaps 
a paper) about if/when and how they use AMT?
-) 
-) b) AMT specs and deployment:
-) - What is the status of AMT anycast address space? I remember something 
-) about ISC and 154.17.0.0/16, but that seems long gone now. So the 
-) question is: Is there a well known AMT anycast relay address and 
-) prefix?
-) - Would anyone care to update us on the status of the AMT I-D (sorry, I 
-) haven't been following MBONED)? Version 10 of the draft has expired, I 
-) think. It would be nice to know what we can look forward to.

Version 10 was close to being ready to submit to IESG with only a few 
fairly minor issues to hash out- new verbage on sourcing, a proposed new 
teardown msg and verbage on null checksum support in v6 were the issues 
left.  None of these issues seem too difficult resolve, and new editors 
were just selected to finalize the doc.  I am hopeful the spec can be done 
and ready for submission to IESG in the next few months.

-) - There is a parallel between AMT and 6to4, both being anycast-nased 
-) services. In theory, with 6to4 being a transition mechanism, one 
-) expects to be able to reach (potentially) the global ipv6 internet or 
-) the dual stack ipv4/ipv6 internet. Should there be similar expectations 
-) if AMT was deployed like 6to4? Would large providers deploying AMT 
-) actually connect you to what we have come to consider the multicast 
-) internet? Maybe not a technical requirement, yet it is a valid concern, 
-) I think.

Actually, the concepts behind AMT were largely stolen from 6to4.  AMT was 
originally envisioned to be a way for mcast-enabled ISPs to deliver 
Internet mcast content to unicast-only hosts.  That's still the most 
likely application, however, recently SPs are looking at using AMT to 
deliver walled-garden video content to their own customers where the last 
mile (eg, mobile, DSL, etc) may have trouble supporting mcast.

-) 
-) Best regards,
-) Zenon Mousmoulas
-) GRNET
-) 
-) [1] http://tools.ietf.org/agenda/76/slides/mboned-0.ppt
-) 
-)