INTERNET-DRAFT                                    Supratik Bhattacharyya
Expires 18 November 2001 February 2002                                 Christophe Diot
                                                              Sprint ATL
                                                        Leonard Giuliano
                                                        Juniper Networks
                                                             Rob Rockell
                                                      Sprint E|Solutions
                                                             John Meylor
                                                              Dave Meyer
                                                           Cisco Systems
                                                             David Meyer
                                                      Sprint E|Solutions
                                                           Greg Shepherd
                                                        Juniper Networks
                                                          Brian Haberman
                                                         Nortel Networks
                                                          18 May August 2001

        An Overview of Source-Specific Multicast(SSM) Deployment

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC 2119].


   This document provides an overview of the Source-Specific Multicast
   (SSM) service and its deployment using the PIM-SM and IGMP/MLD
   protocols.  The network layer service provided by SSM is a "channel",
   identified by an SSM destination IP address (G) and a source IP
   address S.  The IP IPv4 address range 232/8 has been designated as SSM
   addresses reserved by IANA for IPv4. fo
   use by the SSM service. An SSM destination address range already
   exists for IPv6.  A source S transmits IP datagrams to an SSM
   destination address G. A receiver can receive these datagrams by
   subscribing to the channel (S,G). Channel subscription is supported
   by version 3 of the IGMP protocol for IPv4 and version2 of the MLD
   protocol for IPv6. The interdomain tree for forwarding UDP IP multicast
   datagrams is rooted at the source S. Although a number of protocols
   exists for constructing source-
   rooted source-rooted forwarding trees, this document
   discusses one of the most widely implemented one - PIM Sparse Mode

   This document is intended as a starting point for deploying SSM
   services.  It provides an architectural overview of SSM and describes
   how it solves a number of problems faced in the deployment of inter-
   domain multicast.  It outlines changes to protocols and applications
   both at end-hosts and routers for supporting SSM, with pointers to
   more detailed documents where appropriate. Issues of interoperability
   with the existing multicast service model (as defined by RFC 1112) 1112 are also

1. Terminology

This section defines some terms that are used in the rest of this
document :

  Any-Source Multicast (ASM) : This is the IP multicast service model
  defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a
  "host group", a set of zero or more hosts end-hosts identified by a single
  IP destination address ( through for IPv4).
  This model supports one-to-many and and many-to-many multicast groups.
  End-hosts may join and leave the group any time. There time, and there is no
  restriction on the their location or number of receivers, and number. Moreover, any end-host may
  transmit to a source need host group, even if it is not be a member of the host group it transmits to. that group.

  Source-Specific Multicast (SSM) : This is the multicast service model
  defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to
  an SSM destination address G, and receivers can receive this datagram
  by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS]
  and supports one-to-many multicast.The address range 232/8 has been
  assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the
  range FF2::/11 through FF3x::/11 FF3x::/12 is defined for SSM services [SSM-
  IPV6]. [SSM-IPV6].

  Source-Filtered Multicast (SFM) : This is a variant of the multicast
  service model defined in RFC 1112. A source transmits IP datagrams to
  a host group address in the range of to
  However, each "upper layer protocol module" can now request data sent
  to a host group G by only a specific set of sources, or can request
  data sent to host group G from all BUT a specific set of sources.
  Such support for source filtering is provided by version 3 of the
  Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and
  version 2 of the Multicast Listener Discovery (or MLD) protocol for
  IPv6 [MLDv2]. We shall henceforth refer to these two protocols as "SFM-
  "SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and
  MLDv1 - do not provide support for source-filtering, and are referred
  to as "non-SFM-capable".

2. Current Interdomain Multicast Architecture The current interdomain multicast architecture is based on IGMP/PIM-SM/MSDP/MBGP Architecture for ASM

   All multicast-capable networks of today support the ASM service
   model.  One of the most common multicast protocol architectures for
   supporting ASM in wide-area backbones consists of IGMP version 2
   protocols.  To become a member of a particular host group end-
   hosts register end-hosts
   report multicast group membership with querier routers handling
   multicast group membership function using the IGMP version 2 (IGMPv2)
   protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1) protocol
   [RFC2710] for IPv6.  These protocols are non-SFM-capable,
   hence source-filtering capabilities are unavailable to receivers.

   Multicast-capable routers  Routers then exchange messages with each other
   according to a routing protocol to construct a distribution tree
   connecting all the end-hosts. A number of different protocols exist
   for building multicast forwarding trees, which differ mainly in the
   type of delivery tree constructed [IPMULTICAST,PIM-ARCH, RFC2362,
   SM-NEW, PIM-DM]. Of these, the Protocol Independent Multicast
   Sparse-Mode (PIM-SM) protocol [PIM-SM-NEW] is the For scalability reasons, sparse-mode protocols
   (e.g., PIM-SM) are preferred over dense-mode protocols (e.g., DVMRP,
   PIM-DM)  for deployment in large backbone networks (though many
   smaller networks deploy dense-mode protocols). PIM-SM,  most widely
   deployed in today's public networks. PIM-SM, by default, constructs sparse-mode protocol, builds a
   single spanning multicast tree
   rooted at a core rendezvous point or RP for all group members within
   a single administrative domain. Local Multicast sources then within this domain
   send their data to this RP which forwards the data down the shared
   tree to interested local receivers. A receiver joining receivers within the domain. As of this writing,
   multicast end-hosts with SFM capabilities are not widely available.
   Hence a host group client can only specify interest in the an entire host group and therefore will receive
   receives data
   for sent from any source to this group forwarded on 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 (e.g., Internet broadcast type
   streams) where forwarding from a source to a receiver is most
   efficient via the shortest path. group. PIM-SM also allows a designated
   router serving a particular subnet
   receivers to switch to a source-based shortest path tree for tree.

   An RP uses the MSDP [MSDP] protocol to announce multicast sources to
   RPs in other domains. When an RP discovers a given source once the source's address is
   learned from data arriving on the shared tree.  This capability
   provides for distribution of in a different
   domain transmitting data from local sources to local
   receivers both sharing a common RP inside a given PIM domain.

   It is also possible multicast group for RP's to learn about sources which there are
   interested receivers in other PIM
   domains by using its own domain, it joins the Multicast Source Discovery Protocol (MSDP)
   [MSDP]. Once an active remote shortest-path
   source is identified, an RP can join
   the shortest path based tree to rooted at that source and obtain source. It then redistributes the
   data received to forward down all interested receivers via the local intra-domain shared
   tree on behalf of interested local receivers.
   Designated routers for particular subnets can again switch rooted at itself.

   The MBGP protocol [MBGP] defines extensions to a
   source-based shortest path tree for a given remote source once the
   source's address is learned from data arriving on BGP protocol [BGP]
   to support the shared tree.

   The IGMPv2/PIM-SM/MSDP-based interdomain advertisement of reachability information for
   multicast architecture is
   widely deployed in IPv4 networks routes. This allows an autonomous system (AS) to support
   incongruent unicast and can be particularly effective
   for groups where sources are not known in advance by hosts joining a
   group, or when sources come multicast routing topologies, and go dynamically, or when forwarding on
   a common shared tree is found to be operationally beneficial. thus
   implement separate routing policies for each.

3. Problems with Current Architecture

   There are several deployment problems associated with current
   multicast architecture:

   A) Inefficient handling of well-known sources :

       In cases where the address of the source is well known in advance
      of the receiver joining the group, and when the shortest
      forwarding path is the preferred forwarding mode, then shared tree
      mechanisms and MSDP only are not necessary.

      B) Lack of access control :

       In the ASM 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 data sent to a host group by
      any source.

      C) Address Allocation :

      Address allocation is one of core deployment challenges posed by
      the ASM service model. The current multicast architecture does not
      provide an adequate a deployable solution to prevent address collisions among
      multiple applications. The problem is more serious for IPv4 than
      IPv6 since the total number of multicast addresses is smaller. A
      static address allocation scheme, GLOP [GLOP00] has been proposed
      as an interim solution for IPv4; 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) [MAAA] are generally perceived as
      being too complex (with respect to the dynamic nature of multicast
      address allocation) for widespread deployment. However, the
      unicast-prefix-based multicast architecture of IPv6 [HABE1]
      expands on the GLOP approach, simplifies the multicast address
      allocation solution and incorporates support for source-specific
      multicast addresses.

4. Source Specific Multicast (SSM) : Benefits and Requirements

   As mentioned before, the Source Specific Multicast (SSM) defines a service
   model for defines a "channel" identified by an (S,G) pair, where S is a
   source address and G is an SSM destination address. This model can be realized
   by a protocol architecture, where packet forwarding is restricted to
   shortest path trees rooted at specific sources, and channel Channel
   subscriptions are described using an SFM-capable group management
   protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees
   are needed to implement this model.

   The SSM service model alleviates all of the deployment problems
   described earlier :

      4.1 SSM lends itself to an elegant solution to the access control
      problem. Only When a single receiver subscribes to an (S,G) channel, it
      receives data sent by a only the source S S. In contrast, any host
      can transmit to a channel (S,G)
      where G is an SSM address. This makes ASM host group. Hence, it significantly is more difficult to
      spam an SSM channel than an ASM host group.  In
      addition, data from unrequested sources need not be forwarded by
      the network, which prevents unnecessary consumption of network

      4.2 SSM defines channels on a per-source basis; hence SSM
      addresses basis, i.e., the channel
      (S1,G) is distinct from the channel (S2,G), where S1 and S2 are "local" to each source.
      source addresses, and G is an SSM destination address. This averts
      the problem of global allocation of SSM destination addresses, and
      makes each source independently 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 requires only source-based forwarding trees; this
      eliminates the source S. Thus there is no need for a shared tree infrastructure. In terms of
      the IGMPv2/PIM-SM/MSDP architecture, IGMP/PIM-SM/MSDP/MBGP protocol suite, this implies that
      neither the RP-based shared tree infrastructure of PIM-SM nor the
      MSDP protocol is required. 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. deployment.

      4.4 It is widely held that point-to-multipoint applications such
      as Internet TV will dominate the Internet multicast application
      space in the near future. The SSM model is ideally suited for such

   A protocol architecture for SSM requires the following :

      A) Source specific host membership reports : A SFM-capable
      protocol is needed to allow a host to describe specific sources
      from which it would like to receive data.

      B) Shortest path forwarding.  DR's must be capable of recognizing
      receiver-initiated, source specific host reports and initiating
      (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 (i.e., prevent shared tree
      forwarding) for SSM addresses.  The address range 232/8 has been
      allocated by IANA for deploying source-specific IPv4 multicast
      (SSM) services. In this range, SSM is the sole service model. For
      IPv6, a source-specific multicast address range has been defined
      in [HABE1], as a special case of unicast prefix-based multicast

5. SSM Framework

Figure 1 illustrates the elements in an end-to-end implementation
framework for SSM framework. :

    IANA assigned 232/8 for IPv4             ADDRESS ALLOCATION
    SSM range exists
         FF3x::/12 for IPv6
       +--------------+ session directory/web page
       | source,group |                      SESSION DESCRIPTION
              ^ |
        Query | | s,g (S,G)
              | v
     +-----------------+ host
     |   SSM-aware app |                     CHANNEL DISCOVERY
     |   SSM-aware app |                   SSM-AWARE APPLICATION
     |   IGMPv3/MLDv2  |              IGMPv3/MLDv2 HOST REPORTING
               |(source specific host report)
     +-----------------+  Querier Router
     |   IGMPv3/MLDv2  |                         QUERIER
       |   PIM-SSM  |                        PIM-SSM ROUTING
       +------------+     Designated Router
               | (S,G) Join only
         +-----------+  Core  Backbone Router
         |  PIM-SSM  |
               | (S,G) Join only

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

   We now discuss the framework elements in detail :

   5.1 Address Allocation

   For IPv4, the address range of 232/8 has been assigned by IANA for
   SSM.  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 non-SFM-capable protocols, operational
   policies are being proposed [SSM-BCP] which prevent data sent to
   232/8 from being delivered via shared trees.

   Note that it is possible to achieve the benefit parts of direct and
   immediate the network that do not have
   channel subscribers.

   Note that IGMPv3/MLDv2 does not limit (S,G) joins in response to IGMPv3 reports in other ranges
   than 232/8.However, non-SSM address ranges allow for concurrent use
   of both only the ASM and 232/8
   range. However, SSM service models. Therefore, while we can
   achieve the PIM join efficiency service, as defined in the non-SSM [SSM-ARCH], is available
   only in this address range with
   IGMPv3, it is not possible to prevent the 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 the SSM address range. IPv4.

   In case of IPv6, [HABE1] has defined an extension to the addressing
   architecture to allow for unicast prefix-based multicast addresses.
   In this case, bytes 0-3 (starting from the least significant byte) of
   the IP address is used to specify a multicast group id, bytes 4-11 is
   be used to specify a unicast address prefix (of up to 64 bits) that
   owns this multicast group id, and byte 12 is used to specify the
   length of the prefix. A source-specific multicast address can be
   specified by setting both the prefix length field and the prefix
   field to zero.  Thus IPv6 allows for 2^32 SSM addresses per scope for
   every source, while IPv4 allows 2^24 addresses per source.

   5.2 Session Description and Channel Discovery

      In case of ASM, receivers need to know only the group address for
      a specific session. In the IGMPv2/PIM-SM/MSDP architecture,
      designated routers discover an active source via PIM-SM and MSDP,
      and then graft themselves to the multicast forwarding tree rooted
      at that source.

      In case of the SSM, an

      An SSM receiver application on an end-host must know both the SSM destination
      address G and the source address S before subscribing to a
      channel. Thus the function of channel discovery becomes the
      responsibility of applications.  This information can be made
      available in a number of ways, including via web pages, sessions
      announcement applications, etc.  The exact mechanisms for doing
      this is outside the scope of this framework document.

   5.3. SSM-Aware Applications

      -- For applications sourcing content expected to be available to
      receivers via SSM channels, the session
      must be advertised including a source address as well as an SSM

      -- Applications expecting to subscribe to an SSM channel must be
      capable of specifying a source address in addition to an SSM
      destination address. In other words, the application must be "SSM-aware". "SSM-

      Specific API requirements are identified in [THAL00].

   5.4. IGMPv3 for SSM

      The currently deployed version of IGMPv3/MLDv2 Host Reporting and Querier

      IGMP (IGMPv2) version 2 [IGMPv2] allows end-hosts to register report their interest
      in a multicast group by specifying a class-D IP address for IPv4.
      However in order to implement the SSM service model, an end-host
      must specify a source's unicast address as well as an SSM
      destination address. This capability is provided by the
      recently proposed IGMP version 3 (IGMPv3).
      [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 service model. Hence
      an upgrade from IGMPv2 to IGMPv3 is an essential change for
      implementing SSM.

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

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

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

      There are a number of backward compatibility issues between IGMP
      versions 2 and 3 which have to be addressed. There are also some
      additional requirements for using IGMPv3 for the SSM address
      range. A detailed discussion
      of these issues the use of IGMPv3 in the SSM destination address range is
      provided in [SSM-

5.5  MLDv2 for SSM [SSM-IGMPv3].

      The Multicast Listener Discovery (MLD) protocol used by an IPv6
      router to discover the presence of multicast listeners on its
      directly attached links, and to discover the multicast addresses
      that are of interest to those neighboring nodes.  Version 1 of MLD
      [DEER99] is  derived from IGMPv2 and allows a multicast listener
      to specify the multicast group(s) that it is interested in.
      Version 2 of MLD [VIDA01] is derived from, and provides the same
      support for source-filtering as, IGMPv3.

5.6. PIM-SM Modifications for SSM

5.5. PIM-SSM Routing

   PIM-SM [PIM-SM-NEW] 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, trees. The original
    PIM-SM is [PIM-SM] did not
   designed to allow a router to choose between a shared
   tree and a source-based tree. In fact, a receiver always joins joined a PIM
   shared tree to start with, and may later be switched to a per-source
   tree by its adjacent edge router.

   A key to implementing SSM is eliminate However, the need more recent PIM-SM
   specification [PIM-SM-NEW] has support for starting with a
   shared tree and then switching to a source-specific tree. This join.

   Supporting SSM with PIM-SM involves several changes to PIM-SM as
   described in [PIM-SM-NEW]. The resulting PIM functionality is
   described as PIM-SSM. The specific architectural issues associated
   with PIM-SSM and IGMPv3/MLDv2 are detailed in [SSM-ARCH]. The most
   important changes to PIM-SM with respect to SSM are as follows:

      -- When a DR receives an (S,G) join request with the address G in
      the SSM address range, it must initiate a (S,G) join and NEVER a
      (*,G) join.


      --Backbone routers (i.e. routers that do not have directly
      attached hosts) must not propagate (*,G) joins for group addresses
      in the SSM address range.

      --Rendezvous Points (RPs) must not accept PIM Register messages or
      (*,G) Join messages in the SSM address range.

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

6. Interoperability with Existing Multicast Service Models

   Interoperability with ASM is one of the most important issues in
   moving to SSM deployment. ASM and SSM will always coexist; hence
   there will be two service models for Internet multicast. SSM is the
   ONLY service model for the SSM address range (232/8 for IPv4 and
   FF::/8 for IPv6) - the correct protocol
   behaviour for this range is specified in [SSM-ARCH]. The ASM service
   model will be offered for the non-SSM adddress range, where receivers
   can issue (*,G) join requests to receive multicast data. A receiver
   is also allowed to issue an (S,G) join request in the non-SSM address
   range; however, in that case there is no guarantee that it will
   receive service according to the SSM model.

   Another backward compatibility issue concerns the MSDP protocol,
   which is used between PIM-SM rendezvous points (RPs) to discover
   multicast sources across multiple domains. SSM obviates the needs for
   MSDP, but MSDP is still required to support ASM for non-SSM class-D
   IPv4 addresses. In order to ensure that SSM is the sole forwarding
   model in 232/8, RPs must not accept, originate or forward MSDP SA
   messages for the SSM address range [SSM-BCP].

7. Security Considerations

   SSM does not introduce new security considerations for IP multicast.
   It can help in preventing denial-of-service attacks resulting from
   unwanted sources transmitting data to a multicast channel (S, G).
   However no guarantee is provided.

8. Acknowledgments

   We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon
   and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas,
   Tony Speakman and 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 Cereva Networks and Hugh LaMaster at NASA for their
   valuable insights and continuing support.

9. References:

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

   [IANA-ALLOCATION] Internet Assigned Numbers Authority.

   [RFC2236] W. Fenner. Internet Group Management Protocol, Version 2.
   Request For Comments 2236.

   [IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan.
   Internet Group Management Protocol, Version 3. Work in Progress.

   [SSM-IGMPv3] H. Holbrook and B. Cain.  IGMPv3 for SSM. Work in

   [SSM-ARCH] H. Holbrook and B. Cain.  Source-Specific Multicast for
   IP. Work in Progress.

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

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


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

   [PIM-SM] Bill

   [PIM-SM-NEW] B. Fenner, et al. M. Handley, H. Holbrook, I. Kouvelas.
   Protocol Independent Multicast - Sparse Mode (PIM-SM) : (PIM-SM): Protocol Specifications (Revised).
   Specification (Revised)", Work in Progress. In Progress, 2000.  <draft-ietf-pim-

   [PIM-DM] S. Deering et al.  Protocol Independent Multicast Version 2
   Dense Mode Specification.  Work in Progress.

   [MSDP] Farinacci et al.  Multicast Source Discovery Protocol. Work in

   [MAAA] M. Handley, D. Thaler and D. Estrin.  The Internet Multicast
   Address Allocation Architecture.  Work in Progress (draft-ietf-
   malloc-arch-**.txt) June 2000.

   [MCAST-DEPLOY] 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.

   [SSM-RULES] H. Sandick and B. Cain.  PIM-SM Rules for Support of
   Single-Source Multicast. Work in Progress.

   [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn.  Socket Interface
   Extensions for Multicast Source Filters. Work in Progress.

   [RFC2770] GLOP Addressing in 233/8. Request For Comments 2770.

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

   [SSM-BCP]   G. Shepherd et al.  Source-Specific Protocol Independent
   Multicast in 232/8.  Work in Progress.

   [RFC2710] S. Deering, W. Fenner and B. Haberman.  Multicast Listener
   Discovery for IPv6. Request for Comments 2710.

   [MLDv2] R. Vida, et. al.
            Multicast Listener Discovery Version 2 (MLDv2) for IPv6.
            Work in progress.

   [SSM-IPv6] B. Haberman and D. Thaler.
            Unicast-Prefix-Based IPv6 Multicast Addresses. Work in

   [IPSEC] S. Kent, R. Atkinson.
            Security Architecture for the Internet Protocol. Request for
            Comments 2401.

   [IPv6-ALLOC] B. Haberman.
            Dynamic Allocation Guidelines for IPv6 Multicast Addresses.
            Work in Progress.

12. Authors' Address:

   Supratik Bhattacharyya
   Christophe Diot
   Sprint Advanced Technology Labs
   One Adrian Court
   Burlingame CA 94010 USA
   Leonard Giuliano
   Greg Shepherd
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA

   Robert Rockell
   David Mayer
   Sprint E|Solutions
   Reston Virginia USA

   John Meylor
   Dave Meyer
   Cisco Systems
   San Jose CA USA

   Brian Haberman
   Nortel Networks