All things related to multicast

[Alan Crosswell <>]

Show them the business model in which content providers finally are able 
to afford providing content, which leads them to provide more content 
rather than the current model of having to provide more copies of the 
same content.  This results in more bandwidth overall as the number of 
channels expands.

Did I get that right Marshall? ;-)
/a

McCallum, Robert wrote:
> Decent list Alan.  I totally agree with the ISP being more multicast
> centric.  I shall keep trying to hammer home the benefits to my companys
> ISP faction and hopefully one day they actually might just listen :-).
>
> -----Original Message-----
> From: Alan Crosswell [mailto:] 
> Sent: 10 October 2005 21:54
> To: wg-multicast
> Subject: This coming year's multicast working group goals
>
>
> Please comment on the following proposed goals for the Internet2
> Multicast 
> Working Group.  I would like to hear your opinions of things that you
> think 
> should be dropped from or added to the list, and whether you have any
> interest 
> in volunteering your time to help meet the goals.
>
> Some of this work is done by volunteers.  Some is done by Abilene
> engineering 
> staff.  Some is done by Internet2 staff.
>
> Mission
>
> See http://multicast.internet2.edu/wg-multicast-charter.shtml for the
> current 
> mission statement.  I'm no good at mission statements.  Someone want to
> take a 
> crack at revising this or is it good enough?
>
> Goals
>
> 1. Encourage Source-Specific Multicast SSM
>     - Why? Because MSDP won't scale and doesn't exist in IPv6.
>     - How: Work with commercial I2 members, other vendors, and freeware
>       producers to make their products SSM-capable.  This primarly means
>       IGMPv3 support in
>       a. end systems OSes (XP, Linux done.  MacOS X, other BSDs not
> done)
>       b. black boxes (e.g. Vbrick)
>       c. client software (e.g. Real Player, Windows Media Player,
>          StreamPlayerII, etc.)
>          (Note that VLC already does SSM)
>       d. switches
>
> 2. Collect and disseminate multicast testing and debugging tools.  Much
> of this
>     has been done already but the tool list needs to be cleaned up and
> extended.
>
> 3. Continue to deliver training through Hands-on Workshops.
>
> 4. IPv6 Multicast
>     a. Work with v6 working group to bridge v6 and multicast workshop
> content.
>     b. Encourage use of embedded RP in Abilene and other R&E networks.
>     c. Make sure the toolset for v4 also works for v6.
>     d. Work with switch vendors to encourage/evaluate MLDv2 support.
>
> 5. Liaison with related working groups
>     a. IETF MAGMA
>     b. Internet2 bigvideo, v6, measurement, routing, etc.
>     c. Security group(s)
>     d. International R&E groups
>
> 6. Push commodity ISP adoption of multicast routing
>     a. Talk to the ISPs and try to convince them of the value.
>     b. Work through the Quilt and gigapops to make multicast routing a
>        requirement for ISP contracts.  Highlight those ISPs that already
>        offer multicast peering.
>     c. Talk to home access provider ISPs to try and encourage multicast
> support
>        so our residential broadband users see the same benefit as our
> on-campus
>        users.
>
> 7. Clean up the http://multicast.internet2.edu web site.
>
> 8. Invent the multicast killer app:-)
>
>
> Thanks.
> /a