All things related to multicast

["Curtis, Bruce" <>]

On Mar 9, 2011, at 3:25 AM, Zenon Mousmoulas wrote:

> Hi Richard,
> 
> thanks for relaying this information. In the tech note mentioned below, the 
> last figure shows that Octoshape relies on AMT-enabled routers, while the 
> following text implies that Octoshape client itself performs the AMT 
> gateway function:

  The AMT-enabled router in the diagram is on the network that doesn't have 
multicast enabled on the last mile (to the customer computer).  So AMT on the 
customer computer talks to an AMT relay (which in the diagram is the router 
providing the AMT relay function) and the router talks native multicast to 
the world.

http://www.juniper.net/techpubs/en_US/junos10.3/topics/concept/amt-operation.html

> 
> [...] The Octoshape client in the background attempts to tune into this SSM 
> address and immediately finds it unavailable since it is not connected to 
> the native multicast domain. The Octoshape client then sends an Anycast 
> request out to find the closest AMT relay, if available. The closest relay 
> responds to the request, and tunnels to the native multicast domain to pull 
> one copy of the stream into the AMT relay.
> 
> I tried to test this by looking for AMT (2268/udp) traffic while playing a 
> stream on the multicast showcase web page. Dissecting this traffic verified 
> the latter scenario:
> 
> No.     Time        Source                Destination           Protocol 
> Info
>      1 0.000000    83.212.9.91           12.54.128.89          AMT      
> Relay Discovery Message
>      2 0.205031    12.54.128.89          83.212.9.91           AMT      
> Relay Advertisement Message
>      3 0.205714    83.212.9.91           12.91.38.34           AMT      
> Request Message
>      4 0.405267    12.91.38.34           224.0.0.1             IGMP     V3 
> Membership Query, general
>      5 0.406059    127.0.0.1             127.0.0.1             IGMP     V3 
> Membership Report / Join group 232.27.106.225 for sources in 
> {12.236.227.105, 32.97.116.119}
>      6 0.753810    12.236.227.105        232.27.106.225        UDP      
> Source port: 8247  Destination port: 8250
>      7 0.788894    12.236.227.105        232.27.106.225        UDP      
> Source port: 8247  Destination port: 8250
>      8 0.930350    12.236.227.105        232.27.106.225        UDP      
> Source port: 8247  Destination port: 8250
>      9 0.962414    32.97.116.119         232.27.106.225        UDP      
> Source port: 8247  Destination port: 8250
>     10 1.007251    32.97.116.119         232.27.106.225        UDP      
> Source port: 8247  Destination port: 8250
> 
> 
> While searching for an AMT dissector, I stumbled across another lightweight 
> AMT gateway implementation in Java:
> 
> http://sites.google.com/site/amtproxy/
> 
> Quite interesting, although it didn't work for me (something went wrong for 
> the sdp parser library, perhaps it didn't understand source-filter 
> attributes).
> 
> Best regards,
> Z.
> 
> -----Αρχικό μήνυμα-----
> Από: 
> 
>  εκ μέρους Richard Machida
> Αποστολή: Τρι 8/3/2011 4:03 πμ
> Προς: wg-multicast
> Θέμα: RE: AMT questions
> 
> I was asked to forward this message to the list.
> 
> Richard
> 
> Zenon,
> 
> You can download a technote on the Octoshape implementations with Multicast 
> here. 
> http://www.octoshape.com/?page=services/multicastpaper
> 
> You can read a little about some press releases with ATT here:
> http://www.octoshape.com/index.php?page=services/multicast
> 
> You can play with some streams coming from AMT relays ATT has deployed here:
> http://www.octoshape.com/?page=showcase/multicast
> 
> Please let me know if you have any other questions.
> 
> Best,
> Scott
> ---------- Forwarded message ----------
> Date: Fri, 4 Mar 2011 09:10:42 +0200
> From: Zenon Mousmoulas 
> <>
> To: 
> 
> Subject: RE: AMT questions
> 
> 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).
> - 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.
> - 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.
> 
> Best regards,
> Zenon Mousmoulas
> GRNET
> 
> [1] http://tools.ietf.org/agenda/76/slides/mboned-0.ppt
> 
> 
> From: Mailin1 Warning 
> <>
> Date: March 7, 2011 4:59:26 PM AKST
> To: 
> ""
>  
> <>
> Subject: RE: AMT questions
> 
> 
> Zenon,
> 
> You can download a technote on the Octoshape implementations with Multicast 
> here. 
> http://www.octoshape.com/?page=services/multicastpaper
> 
> You can read a little about some press releases with ATT here:
> http://www.octoshape.com/index.php?page=services/multicast
> 
> You can play with some streams coming from AMT relays ATT has deployed here:
> http://www.octoshape.com/?page=showcase/multicast
> 
> Please let me know if you have any other questions.
> 
> Best,
> Scott
> ---------- Forwarded message ----------
> Date: Fri, 4 Mar 2011 09:10:42 +0200
> From: Zenon Mousmoulas 
> <>
> To: 
> 
> Subject: RE: AMT questions
> 
> 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).
> - 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.
> - 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.
> 
> Best regards,
> Zenon Mousmoulas
> GRNET
> 
> [1] http://tools.ietf.org/agenda/76/slides/mboned-0.ppt
> 
> 
> 

---
Bruce Curtis                         

Certified NetAnalyst II                701-231-8527
North Dakota State University