All things related to multicast

["Zenon Mousmoulas" <>]

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 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