All things related to multicast

["Kevin C. Almeroth" <>]

This email is a quick status of the I2 Multicast Working Group.
It consists of an update of tasks/projects/objectives that the
WG is doing as well as informal minutes about the last couple
of meetings.

The next working group meeting will be in Columbus at the next
Joint Techs workshop.

-----------------------

1.  Bob Riddle is working on an I2 Channel Guide.  Like previous
web-based channel guides, it will be a list of active multicast
channels.  Unlike previous guides, we want to provide a list
of available SSM channels, we want to provide a list of the
bandwidth for each group, and for non-continuous channels (e.g.
a radio station), we want to list whether the source is actively
transmitting.  Some related points:
   +  Some of these additional-information items create some
      interesting challenges.  A good solution would require an
      agent to periodically join the group, measure whether the
      source is transmitting, and then update the web page.

   +  Until recently, there has not been much in the way of I2
      staff support to manage/coordinate/direct these kinds of
      projects.  At this point however, Bob (who is always leading
      the I2 Detective effort) is able to dedicate cycles to
      multicast-related projects.

   +  The work is ongoing but the current URL is:  
      http://people.internet2.edu/~bdr/tvguide.html

2.  Continued work on a "wall of fame" and/or a "wall of shame".
    To encourage I2 members to deploy and use multicast, we are
    working on a web page listing status for several criteria for 
    each member institution.  For example, criteria include whether 
    they have     multicast to the border (most do), whether they 
    have deployment WITHIN the org, whether they are sourcing 
    content, etc.  The goal is to encourage additional 
    schools/gigapops to deploy multicast.

3.  Continued work to provide compelling multicast-based content
    to the community.  There are a number of projects scheduled
    and a number in the works.  This is something of a unique
    WG item since there are many events being organized by groups
    other than the mcast WG.  This is a good thing.  However, where
    possible, the WG is providing input to help those with the
    content understand what can be done and what could be done.
    For example, we are in talks with the MovieLink folks about
    providing content within I2.  A second effort is that Bob is
    polling most I2 universities to see if they have content that
    that can be transmitted I2-wide via multicast.

4.  There are also a number of smaller projects underway:
    +  Support for IPv6.  Currently the plan is to offer IPv6 SSM.
       Also under discussion in the Abilene NOC is whether to
       provide an Embedded RP.

    +  Participation in IMDOCS.  Since there is a significant
       overlap between this list and the IETF MBONED WG, many of
       us will be participating in contributing content for
       IMDOCS.  One doc of particular use to the I2 community will
       be the updated version of the guidelines for multicast 
       application writers.

    +  Robust join work.  I personally have a project that looks
       at developing an I2 Detective-like tool to determine if
       a group join was (or is likely to be) successful.  It
       involves being clever about seeing what IGMP traffic is
       flowing (for first hop correct operation), doing some 
       basic error checking (no (*,G) joins to the SSM range), etc.

    +  Work to develop and use tunneling technology.  There are
       a number of solutions here.  Markus Buchhorn has been
       working on the rcbridge technology and the IETF has been
       working on the AMT protocol.  In the past, the multicast
       community has largely advocated native-multicast-only.
       It now seems reasonable to believe that a better working
       model is to use tunneling technology to actually get 
       content to users and then to encourage network operators
       to turn multicast on.  The URL for rcbridge is:
       http://if.anu.edu.au/SW/rcbridge.html

    +  Another issue that is re-surfacing is Ken Lindahl's old
       proposal that we need a way to manage groups and traffic
       based on the transmission rate.  HDTV traffic sent via
       multicast needs to be kept from flooding onto links that
       cannot handle the bandwidth (i.e. clueless users who join
       high bandwidth groups and create an inadvertent DoS 
       attack).  
       
5.  A last item that the WG is trying to focus on is finding
    someone interesting in actively managing the WG web pages.
    The web site could be a much better source of information.
    But to keep the pages updated, we need someone with a 
    reasonable amount of available time in their schedule.