All things related to multicast

["Lucy E. Lynch" <>]

SSM Progress Report:

During the August 2000 Internet2 Joint Techs meeting in Toronto, the first
end-to-end Source Specific Multicast (SSM) session was sourced across the
Internet2/Abilene backbone. Greg Shepherd of Cisco Systems worked directly
with Mark Fullmer (Ohio State University), Matt Davy (Indiana
University/Abilene NOC) and Hans Kuhn (University of Oregon). Oregon
sourced an H261 encoded session using IP/TV and the session was also
announced at: http://videolab.uoregon.edu/cgi-bin/urd.cgi. Matt Davy
worked to ensure that all the Abilene routers were fielding a standard PIM
configuration and successfully passing traffic (see:
http://palpatine.ucs.indiana.edu/mrview-abilene/). Mark Fullmer acted as
the content receiver. Ohio State University installed an SSM capable EFT
image in their edge router and Fullmer also modified the standard MBone
tools (VIC & VAT) to operate with SSM under FreeBSD 4.0 (available at:
ftp://ftp.net.ohio-state.edu/users/maf/mcast). Wilbert de Graaf updated
the FreeBSD TCP/IP stack to be IGMPv3-aware so SSM source and group (s,g)
pairs could be recognized (see: 
http://home.hetnet.nl/~wilbertdg/igmpv3.html). 
The test session was completely successful and both source and receiver
stayed up for several days.

This demonstration was repeated in September for the 37th RIPE Meeting in
Amsterdam. The University of Oregon again provided an H261 source and
traffic traveled via Abilene to the Ten-155 pan-European research network
via the DANTE POP in New York. Multicast connectivity was tunneled from
the RIPE conference to Ten-155 and a live demonstration was provided by
Arjen Boers of Cisco Systems as part of the Multicast Routing Workshop
(see: http://www.ripe.net/ripe/meetings/current/ripe-37/#multicast).

Internet2 Institutions with an interest in multicast or real time video
broadcasting are invited to join the SSM beta testing project. You will
need install the current SSM capable image on at least one router on your
campus. The last hop router before the intended receiver must run the EFT
image which supports SSM and you can contact Greg Shepherd
()
 to obtain the current image for your router. Receivers
behind an SSM capable router can view sources using either an IGMPv3 aware
OS/client setup or URD. Questions about URD (this is a solution that
allows existing IP multicast receiver applications to be used with SSM
without modifying the application and without changing or adding any
software on the receiver host running the application) or the URD wrapper
scripts, IGMPv3 aware linux patches (kernel and standard tools) and
sourcing SSM broadcast content should be directed to: 


Background:
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtssm.htm)

Source-specific multicast (SSM) is an extension to the IP multicast
service available in Cisco IOS Software since version 10.2. It provides a
super-scalable, performance-optimized, thin network solution primarily for
one-to-many applications such as Internet broadcast. Currently, a receiver
joins a multicast group but has no ability to specify a source. Multiple
sources can exist and all data from them will be received. SSM enables the
selection of a particular source for multicast data. This prevents traffic
from other sources for the same group from being forwarded to the host.
SSM requires well-known sources and is most useful for static
applications.

SSM requires the host to learn about a specific source independently of
the Multicast Routing Protocol used in the network. This is usually
accomplished by posting the source/group information on a web page but any
other method is acceptable. The web page usually consists of a cgi script
which will start a particular multicast application on the receiving host.
The host then must communicate the source/group information to the
last-hop router. IGMPv3 is the standard protocol for setting up an SSM
data path, but it requires modification of both the host OS and the
application. However, there are two Cisco-specific, interim methods that
can be used if your host does not support IGMPv3.

Both IGMPv3-lite and URD (URL Rendezvous Directory) enable a user to
easily join a multicast group and receive content transmitted to that
group, while providing the network administrator with enhanced
capabilities to manage multicast streams.

URD does not require any changes in the host operating system or in the
multicast application. An HTTP redirect, generated by the cgi script on
the web page, is intercepted by the last hop router which then sets up the
SSM data path.

IGMPv3-lite uses a daemon (available from Whitebarn at
http://www.talarian.com/products/multicastlite/index.shtml) to allow an
IGMPv3 aware application to be used on a host OS that has not yet
implemented IGMPv3. This daemon will send a subset of IGMPv3 reports to
the last-hop router, which also listens for IGMPv2 reports before setting
up the SSM data path.

- 30 -

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon

                (541) 346-1774