INTERNET-DRAFT                                    Supratik Bhattacharyya
Expires 13 January 2001                                  Christophe Diot
                                                              Sprint ATL
                                                        Leonard Giuliano
                                                             Rob Rockell
                                                              SprintLink
                                                             John Meylor
                                                              Dave Meyer
                                                           Greg Shepherd
                                                           Cisco Systems
                                                            13 July 2000


        A Framework for Source-Specific IP Multicast Deployment
                     <draft-bhattach-pim-ssm-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].










Bhattacharyya et. al.                                   FORMFEED[Page 1]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


Abstract

   This document provides an overview of the Source-Specific Multicast
   (SSM) service model which supports source-based multicast trees
   across multiple domains in the Internet.  SSM realizes components of
   the EXPRESS [HOLB99] multicast service model in which there is a
   single source for every multicast channel, and channel membership is
   based on the unique combination of multicast group address (G) as
   well as the source's unicast address (S). End-hosts use version 3 of
   the IGMP protocol (IGMPv3) to register their interest in a particular
   source-group (S,G) pair. The PIM-SM protocol is then used to
   construct the multicast forwarding tree rooted at the source S.

   This document is intended as a starting point for implementing and
   deploying SSM services. It provides a brief architectural overview of
   SSM described in more detail in [HOLBOO] and describes associated
   deployment challenges.  It summarizes changes to protocols and
   applications both at end-hosts and routers, with pointers to more
   detailed documents, wherever appropriate.  Issues of interoperability
   with the current multicast architecture are also discussed.


1. Classic Multicast Service Model using IGMPv2/PIM-SM

   The current IP multicast service model is an open model where a set
   of hosts can be aggregated into a group with a single class-D IP
   address in the range of 224.0.0.0 to 239.255.255.255. Any end-host
   can send data to a multicast group (even without joining the group),
   and any end-host can receive data sent to a group by becoming a
   member of it.  To become a member of a particular group, an end-host
   registers multicast group membership with a querier routers that
   handles the multicast group membership function using the IGMP
   [FENN97,CAIN99] protocol.  Initial IGMPv1 or IGMPv2 protocols only
   provide for the ability to specify the group to which a host will
   join, there is no mechanism available to allow hosts to describe
   their desire to include (or exclude) particular sources sending to a
   given group.

     Multicast-capable routers then exchange messages with each other
   according to some routing protocol to construct a distribution tree
   connecting all the end-hosts. A number of different protocols exist
   for multicast routing. They differ mainly in the type of delivery
   tree constructed [DEER90,DEER96,PIMSM,PIMDM]. Of these, the Protocol
   Independent Multicast Sparse-Mode (PIM-SM) protocol is the most
   widely deployed in today's public networks. PIM-SM constructs a
   single spanning multicast tree rooted at a core rendezvous point or
   RP for all group members within a domain.




Bhattacharyya et. al.                                   FORMFEED[Page 2]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   In the following paragraph, the term 'local' when applied to a source
   and relative to some router, refers to a source that is in the same
   PIM-SM domain.  Local sources then send their data to this RP which
   forwards the data down the shared tree to interested local receivers.
   Again, a receiver joining via IGMPv1 or IGMPv2 can only specify
   interest in the entire group and therefore will receive data sent by
   any source to this group forwarded via the shared tree.  Distribution
   via a shared tree can be effective for certain types of traffic,
   e.g., where the number of sources is large since forwarding on the
   shared tree is performed via a single multicast forwarding entry.
   However, there are many cases (eg, Internet broadcast type streams)
   where forwarding from a source to a receiver is most efficient via
   the shortest path.  PIM-SM also allows a designated router serving a
   particular subnet to switch to a source-based shortest path tree for
   a given source once the source's address is learned from data
   arriving on the shared tree.  This behavior provides for distribution
   of data from local sources to local receivers both sharing a common
   RP inside a given PIM domain.

   Interdomain PIM-SM Multicast Using MSDP

    It is also possible for RP's to learn about sources in other PIM
   domains by using the Multicast Source Discovery Protocol (MSDP). Once
   an active remote source is identified, an RP can join the shortest
   path tree to that source and obtain data to forward down the local
   shared tree on behalf of interested local receivers. Designated
   routers for particular subnets can again switch to a source-based
   shortest path tree for a given remote source once the source's
   address is learned from data arriving on the shared tree.
    Current implementations of the classic IP multicast service that use
   IGMPv2 and PIM-SM, and MSDP for interdomain multicast are widely
   deployed and can be particularly effective for groups where sources
   are not known in advance by hosts joining a group, or when sources
   come and go dynamically, or when forwarding on a common shared tree
   is found operationally beneficial.

   2. Limitations of IGMPv2/PIM-SM Service Model

   There exist several service model limitations associated with use of
   IGMPv2, PIM-SM, and MSDP:

   A) Handling Well Known Sources via Shortest Path Forwarding

       In cases where the address of the source is well known before the
      receiver joining the group, and when the shortest forwarding path
      is the preferred forwarding mode, then PIM-SM's shared tree
      mechanisms and MSDP only represent unnecessary interim mechanisms,
      contributing to join latency and operational overhead until the



Bhattacharyya et. al.                                   FORMFEED[Page 3]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


      final shortest path tree is constructed.

      B) Access Control
       In the Classic IP Multicast service model, a receiver can not
      specify which specific sources it would like to receive when it
      joins a given group. A receiver will be forwarded all sources to
      that group.

      C) Address Allocation : This is one of the biggest challenges in
      deploying inter-domain multicast. Currently there is nothing to
      prevent an application from sending data to any multicast address.
      More importantly, there is a serious risk of address collisions
      among multiple applications. A static address allocation scheme,
      GLOP [GLOP00] has been proposed as an interim solution, however,
      GLOP addresses are allocated per registered AS, which is
      inadequate in cases where the number of sources exceeds the AS
      numbers available for mapping. Proposed longer-term solutions such
      as the Multicast Address Allocation Architecture (MAAA) provide
      for additional address allocation but do not guarantee address
      availability of any particular address range.

   The previously proposed Explicitly-Requested Single-Source(EXPRESS)
   Multicast service model decribed, among other things, methods for
   addressing the above limitations [HOLB99]. In the EXPRESS model, a
   multicast "channel" is determined by specifying a source address S as
   well a group address G. Data distribution from source to receiver is
   restricted to this shortest path forwarding tree, data is precluded
   from being forwared on shared trees. Therefore two channels (S1,G)
   and (S2,G) are routed independently, even though they have the same
   multicast group address.

   The IGMPv3 protocol allows a host to specify a list of sources (S)
   which it would like to include (or exclude) if the host can identify
   these sources in advance of joining a group.  A designated router
   serving such hosts is no longer dependent on data coming down the
   shared tree to identify local sources nor is it dependent on MSDP for
   remote sources, it can initiate a PIM join to specific source
   directly and immediately.  However, at the same time, IGMPv3 alone
   does not preclude the DR from joining the shared tree for a given
   group.  Thus, while immediate PIM (S,G) joins made possible by IGMPv3
   source specific host reports do reduce the amount of mechanism
   invoked when sources are well-known in advance, IGMPv3 alone does not
   address the issues of access control or address allocation.  To
   resolve these issues, there must also be an agreed upon range of
   globally routable class D address over which PIM (S,G) joins MUST be
   used, and over which (*,G) joins MUST NOT be used.  For this purpose
   IANA has allocated 232/8.




Bhattacharyya et. al.                                   FORMFEED[Page 4]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   3. Source Specific Multicast (SSM)
    Source Specific Multicast defines a method of multicast forwarding
   restricted to shortest path trees to specific sources described by
   hosts using IGMPv3. The allocation of 232/8 for SSM ensures a range
   in which SSM is the sole forwarding model.  Source-Specific
   Multicast, as implemented by PIM-SM and IGMPv3requires the following:

   A) source specific host membership reports. As previously described,
   IGMPv3 allows a host to describe specific sources from which it would
   like to receive data.

   B) PIM shortest path forwarding.  DR's must be capable of recognizing
   receiver-initiated, source specific host reports and initiating PIM
   (S,G) joins directly and immediately as result.

   C) elimination of shared tree forwarding.  In order to achieve global
   effectiveness of SSM, all networks must agree to restrict data
   forwarding to source trees (ie prevent shared tree forwarding) for
   some recognized group range.  The address range 232/8 has been
   allocated by IANA for use by source-specific multicast (SSM)
   services. Henceforth, we refer to 232/8 as the SSM address range.

4. Benefits of using SSM

   4.1 SSM provides a basis for access control mechanisms.  Only a
   single source S can transmit to a channel (S,G) where G is an SSM
   address. Each receiver is capable of specifying the specific sources
   from which it would like to receive content.  In addition, the
   elimination of shared tree forwarding prevents unrequested sources
   from consuming network resources based on (*,G) forwarding.

   4.2 SSM defines multicast channels on a per-source basis such that
   SSM  addresses are "local" to each source. This averts the problem of
   global allocation of SSM addresses for multicast groups. Each source
   is now responsible for resolving address collisions for the various
   channels that it creates.

   4.3 The distribution tree for an SSM channel (S, G) is always rooted
   at the source S. Thus there is no need for an RP-based shared tree
   infrastructure or for MSDP for source discovery. Thus the complexity
   of the multicast routing infrastructure for SSM is low, making it
   viable for immediate deployment and more efficient for well-known
   sources.

   4.4 It is widely held that point-to-multipoint applications such as
   Internet TV comprise a large portion of the Internet multicast
   application space. The SSM model is designed to efficiently handle
   such cases where sources are known in well known.



Bhattacharyya et. al.                                   FORMFEED[Page 5]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


5. SSM Framework

This section describes changes to hosts, applications, and routers that
must be realized in order to deploy and use the SSM service model.
These changes assume that IGMPv3 will be used to provide application-
level interfaces to the SSM service model and that a slightly modified
version of PIM-SM (which we call PIM-SSM) can be deployed on routers


5.1  Address Allocation
  SSM addresses should be selected from IANA assigned block 232/8 in
order to ensure source specific functionality.

5.2 Source Discovery
 Applications must learn about SSM sources directly before they attempt
to join to the sources content, since they must pass the source address
and group address to the IGMPv3 stack.

5.3 Source-aware Applications
 Applications must be capable of parsing source specific information
from sessions descriptions or announcements and be capable of providing
this information to the IGMPv3 stack.

5.4 IGMPv3 Host Stack
 Hosts must run IGMPv3 stacks which can receive source specific join
information from applications and convert this into IGMPv3 include mode
source_list information sent to the querier router.

5.5 IGMPv3 Querier
 Querier routers must run IGMPv3 and be capable of receiving IGMPv3 host
reports from hosts.  5.6 PIM-SSM Designated Router
 The Designated Router must be capable of recognizing source specific
join requests as provided by the IGMPv3 host reports.  The DR must be
capable of initiating a direct and immediate PIM (S,G) Join toward the
source.  In addition, in the SSM range specified which must include
232/8, the DR must not send an (*,G) join toward the RP in order to
create a shared tree.

5.7 PIM-SSM Core Router Core routers for purposes of this document can
be described as routers which do not have directly connected IGMPv3
speaking hosts.
 Core routers must be capable of receiving and propogating PIM (S,G)
joins based on correct RPF information.  In addition, they must not
propogate joins for addresses in the SSM range.







Bhattacharyya et. al.                                   FORMFEED[Page 6]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


Figure 1 describes the SSM Framework.

   --------------------------------------------------------------
          IANA assigned 232/8              ADDRESS ALLOCATION
   --------------------------------------------------------------
                |
                v
       +--------------+ session directory/web page
       | source,group |                    SESSION DISCRIPTION
   --------------------------------------------------------------
              ^ |
        Query | | s,g
              | v
         +-----------+  host
         | IGMPv3 app|                     SOURCE DISCOVERY
   --------------------------------------------------------------
         | IGMPv3 app|                     IGMPv3 APPLICATION
   --------------------------------------------------------------
         |  IGMPv3   |                     IGMPv3 HOST REPORTING
         +-----------+
               |(source specific host report)
               |
   --------------------------------------------------------------
               v
         +-----------+  Querier Router
         |  IGMPv3   |                     IGMPv3 QUERIER
   --------------------------------------------------------------
         |  PIM-SSM  |                     PIM-SSM ROUTING
         +-----------+  Designated Router
               |
               | (PIM S,G Join only)
               v
         +-----------+  Core Router
         |  PIM-SSM  |
         +-----------+
               |
               | (PIM S,G Join only)
               V


           Figure 1  : SSM Framework: elements in end-to-end model










Bhattacharyya et. al.                                   FORMFEED[Page 7]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


6. Framework Elements

   In the following sections, we provide a more detailed description of
   the SSM framework elements, outline changes to existing protocols,
   discuss interoperability issues and tradeoffs of having a SSM based
   single source multicast service.


   6.1 Address Allocation

   The address range of 232/8 has been assigned by IANA for explicit
   source join multicast applications.  Sessions expecting SSM
   functionality must allocate addresses from the 232/8 range.  To
   ensure global SSM functionality in 232/8, including in networks where
   routers run traditional IGMPv2/PIM-SM/MSDP protocols, operational
   policies [SHEP] should prevent data sent to 232/8 from being
   delivered via shared trees.

   NOTE:  IGMPv3 and PIM-SM allow for direct creation of the shortest-
   path tree for multicast addresses not in the SSM address range,
   however, non-232/8 ranges allow for concurrent use of traditional
   PIM-SM and shared trees for forwarding data. Therefore, while you can
   achieve the PIM join efficiency in non-232/8 with IGMPv3, you can't
   prevent creation of shared trees or shared tree data delivery, and
   thus cannot provide for certain types of access control or assume
   per-source unrestricted address use as with 232/8.

   6.2 Source Discovery

    With SSM the application must know the the source address before it
   can join to an (S,G) pair, so the function of source discovery
   becomes the responsibility of the application.  Source information
   can be provided in a number of ways, including via a web page, a
   session announcement application.  The exact mechanisms for doing
   this is outside the scope of this framework document, but we provide
   two examples of how this might be done.
     An advertising tool such as SDR or a content provider URL can be
   used to announce multicast services using an abstract naming scheme
   (a discussion of an appropriate naming scheme is beyond the scope of
   this document). Then it uses the (S,G) address to join the source-
   based multicast tree for that service.  A session advertisement tool
   like SDR can also be used to advertise the source and destination
   address of an SSM session.








Bhattacharyya et. al.                                   FORMFEED[Page 8]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   6.3. Requirements for Multicast SSM Applications

   -- For applications sourcing content on an SSM address the session
   must be advertised including a source address as well as a group
   address.

   -- An application expecting to join an SSM channel, must be capable
   of specifing a source address in addition to a group address.  In
   other words, the application must be "IGMPv3-aware".

   Specific API requirements are identified in [THAL00].  More detailed
   discussion of application requirements for SSM are in [QUINN].




   6.4. IGMPv3


   IGMPv2 allows end-hosts to register their interest in a multicast
   group by specifying a class-D IP address. However in order to
   implement the single-source multicast model, an end-host must specify
   a source's unicast address as well as a group address. This
   capability is provided by the recently proposed IGMP version 3
   (IGMPv3). IGMPv3 supports "source filtering", i.e., the ability of an
   end-system to express interest in receiving data packets sent only by
   SPECIFIC sources, or from ALL BUT some specific sources. Thus, IGMPv3
   provides a superset of the capabilities required to realize the SSM
   model. Hence an upgrade from IGMPv2 to IGMPv3 is an essential change
   for implementing single-source multicast. We believe that this is the
   MOST EXTENSIVE CHANGE FOR SSM DEPLOYMENT as it involves changes to
   the Application Programming Interface (API) on ALL END-HOSTS that
   want to participate in SSM sessions.

   IGMPv3 requires the API to provide the following operation (or its
   logical equivalent) [CAIN99]:


   IPMulticastListen (Socket, IF, G, filter-mode, source-list)

   "Socket" is an implementation-specific parameter used to distinguish
   among different requesting entities. IF is a local identifier of the
   network interface on which the specified multicast address is to be
   enabled or disabled and G is the multicast group address to which the
   request pertains. filter-mode may be INCLUDE or EXCLUDE. In INCLUDE
   mode, reception of packets sent to the specified multicast address is
   requested only from the IP addresses listed in the source-list
   parameter.



Bhattacharyya et. al.                                   FORMFEED[Page 9]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   As explained in the IGMPv3 specifications [CAIN99], the above
   IPMulticastListen() operation subsumes the group-specific join and
   leave operations of IGMPv2. Performing (S,G)-specific joins and
   leaves is also trivial. A join operation is equivalent to :

    IPMulticastListen (Socket,IF,G,INCLUDE,{S})

   and a leave operation is equivalent to

    IPMulticastListen (Socket,IF,G,EXCLUDE,{S})


   If a system (end-host or edge-router) supports both IGMPv2 and
   IGMPv3, it must ignore any IGMPv2 message for a SSM address.

   A more detailed review of changes to the Internet Group Management
   Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific
   multicast detailed can be found in [HOLB00-1].


6.5. PIM-SM Modifications


   PIM-SM itself supports two types of trees, a shared tree rooted at a
   core (RP), and a source-based shortest path tree. THUS PIM-SM ALREADY
   SUPPORTS SOURCE-BASED TREES; however, PIM-SM is not designed to allow
   a router to immediately select a source-based tree.  In fact, with
   PIM-SM a DR will always joins a PIM shared tree to start with, and
   then may later be switched to a per-source tree.

   A key to implementing SSM is eliminate the need for starting with a
   shared tree and then switching to a source-specific tree. This
   involves several changes to PIM-SM as described in [BHAS00].  The
   resulting PIM functionality is described as PIM-SSM.  The most
   fundemental functional change wrt SSM is as follows:

   -- When a DR identifies request to join a specific source in a group
   with a SSM group address (232/8), it ALWAYS initiate a (S,G) join and
   NEVER a (*,G) join. Moreover, unlike PIM-SM, it need not send a (S,G)
   prune towards the RP.

   The specific architectural issues associated with PIM-SSM and IGMPv3
   are detailed in [HOLB00].








Bhattacharyya et. al.                                  FORMFEED[Page 10]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


7. Interoperability with Existing Multicast Service Models

   Moving to SSM will create several deployment issues:

   7.1 Addressing:  There are two kinds of problems in term of
   addressing. PIM-SSM and PIM-SM need to co-exist. There will
   consequently be two types of multicast applications on the Internet:
   shared groups applications and SSM applications. From an addressing
   standpoint, it is important that SSM applications use the 232/8
   address range and that PIM-SM groups DO NOT use 232/8 addresses.
   Depending on whether a host is PIM-SSM and/or PIM-SM enabled, it will
   need to have the following capabilities:

   - a PIM-SM sender must use a class D address outside the 232/8 range.

   - a PIM-SM receiver can issue a (*, G) join to PIM-SM group.

   - a PIM-SSM sender must use a class D address within the 232/8 range.

   - a PIM-SSM receiver can issue a (S, G) join to any multicast group,
   irrespective of whether it is a PIM-SSM address or not.

   These requirements are very important for addressing backward
   compatibility issues between PIM-SSM and PIM-SM/MSDP.


7. Acknowledments

   We would like to thank a number of people at Sprint Labs -- Gene
   Bowen, Ed Kress, Bryan Lyles, Sue Moon, Timothy Roscoe and JayCee
   Straley -- and Hugh Holbrook, Isidor Kouvelas, Tony Speakman, Nidhi
   Bhaskar at Cisco Systems -- for participating in lengthy discussions
   and design work on SSM, and providing feedback on this document.
   Thanks are also due to Mujahid Khan and Ted Seely at SprintLink, Tom
   Pusateri at Juniper Networks, Bill Fenner at AT&T Research, Kevin
   Almeroth at the University of California Santa Barbara, Brian Levine
   at the University of  Massachusetts Amherst, Brad Cain at Nortel
   Networks and Hugh LaMaster at NASA for their valuable insight and
   continuing support.


11. References:

   [HOLB99] H. Holbrook and D.R. Cheriton.
            IP Multicast Channels : EXPRESS Support for Large-scale
            Single-Source Applications. In Proceedings of SIGCOMM 1999.





Bhattacharyya et. al.                                  FORMFEED[Page 11]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   [FENN97] W. Fenner.
            2236, November 1997.

   [CAIN99] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan.
            Internet Group Management Protocol, Version 3. Internet
            Draft draft-ietf-idmr-igmp-v3-03.txt, March 2000.

   [HOLB00] H. Holbrook and B. Cain.
            Source-Specific Multicast for IP. Internet Draft draft-
            holbrook-ssm-arch-00.txt.

   [HOLB00-1] H. Holbrook and B. Cain.
            Using IGMPv3 For Source-Specific Multicast. Internet Draft
            draft-holbrook-idmr-ssmigmpv3-00.txt

   [DEER90] S. Deering and D. Cheriton.
            Multicast Routing in Datagram Networks and Extended LANs.
            ACM Transactions on Computer Systems, 8(2):85-110, May 1990.

   [DEER96] S. Deering et al.
            PIM Architecture for Wide-Area Multicast Routing. IEEE/ACM
            Transaction on Networking, pages 153-162, April 1996.

   [ESTR98] D. Estrin et al.
            Protocol Independent Multicast - Sparse Mode (PIM-SM) :
            Protocol Specification.  Request for Comments, 2362, 1998.

   [DEER99] S. Deering et al.
            Protocol Independent Multicast Version 2 Dense Mode
            Specification. Internet Draft draft-ietf-pim-v2-dm-03.txt,
            June 1999.

   [FARI00] Farinacci et al.
            Multicast Source Discovery Protocol. Internet Draft draft-
            ietf-msdp-spec-02.txt, January 2000.

   [DIOT00] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen.
            Deployment Issues for the IP Multicast Service and
            Architecture.  In IEEE Networks Magazine's Special Issue on
            Multicast, January, 2000.

   [SAND00] Hal Sandick and Brad Cain.
            PIM-SM Rules for Support of Single-Source Multicast.
            Internet Draft draft-sandick-pimsm-ssmrules-00.txt.

   [THAL00] Dave Thaler, Bill Fenner and Bob Quinn.
            Socket Interface Extensions for Multicast Source Filters.
            Internet Draft draft-ietf-idmr-msf-api-00.txt



Bhattacharyya et. al.                                  FORMFEED[Page 12]





INTERNET-DRAFT     A Framework for PIM-SSM Deployment      10 March 2000


   [BHAS00] N. Bhaskar and I. Kouvelas.
            Source-Specific Protocol Independent Multicast. Internet
            Draft draft-bhaskar-pim-ss-00.txt

   [GLOP97] GLOP Addressing in 233/8. Request For Comments 2770, 1997.

   [SDR]    Session directory (sdr).
            http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr.

   [LEVI00] B. Levine et al.
            Consideration of Receiver Interest for IP Multicast
            Delivery.  In Proceedings of IEEE Infocom, March 2000.

   [SHEP] G. Shepherd et al.
            Source-Specific Protocol Independent Multicast in 232/8.
            Internet Draft draft-shepherd-ssm232/8-00.txt

   [QUINN]
            IP Multicast Applications: Challenges and Solutions.
            Internet Draft draft-ietf-mboned-mcast-apps-02.txt



12. Authors'  Address:

   Supratik Bhattacharyya
   Christophe Diot
   Sprint Advanced Technology Labs
   One Adrian Court
   Burlingame CA 94010
   {supratik,cdiot}@sprintlabs.com
   http://www.sprintlabs.com

   Leonard Giuliano
   Robert Rockell
   Sprint Internet Service Center
   Reston, Virginia
   {giuliano,rrockell}@sprintlink.net


   John Meylor
   Dave Meyer
   Greg Shepherd
   Cisco Systems
   {jmeylor,dmm,shep@cisco.com}






Bhattacharyya et. al.                                  FORMFEED[Page 13]