INTERNET-DRAFT                                    Supratik Bhattacharyya
Expires 04 June September 2002                                Christophe Diot
                                                              Sprint ATL
                                                        Leonard Giuliano
                                                        Juniper Networks
                                                             Rob Rockell
                                                      Sprint E|Solutions
                                                             John Meylor
                                                           Cisco Systems
                                                             David Meyer
                                                      Sprint E|Solutions
                                                           Greg Shepherd
                                                        Juniper Networks
                                                          Brian Haberman
                                                          No Affiliation
                                                         4 December 2001
                                                          04 March 2002

             An Overview of Source-Specific Multicast(SSM) Deployment
                    <draft-ietf-ssm-overview-02.txt> Multicast (SSM)
                    <draft-ietf-ssm-overview-03.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].

Abstract

   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  An IPv4 address range 232/8 has been reserved by IANA fo for 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 IP multicast datagrams is rooted
   at the source S. Although a number of protocols
   exists for constructing source-rooted forwarding trees, this document
   discusses one of S, and is constructed using the most widely implemented one - PIM Sparse Mode
   [PIM-SM-NEW]. [PIM-
   SM-NEW] protocol.

   This document is not intended as to be a starting point standard for Source-Specific
   Multicast (SSM). Instead, its goal is to serve as an introduction to
   SSM and and its benefits for anyone interested in deploying SSM
   services.  It provides an architectural overview of SSM and describes and how it solves a
   number of problems faced in the deployment of inter-
   domain 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
   multicast service model defined by RFC 1112 are also discussed.

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 end-hosts identified by a single
  IP destination address (224.0.0.0 through 239.255.255.255 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, and there is no
  restriction on their location or number. Moreover, this model supports
  multicast groups with arbitrarily many senders - any end-host may
  transmit to a host group, even if it is not a member of 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 provides host applications with a
  "channel" abstraction, in which each channel has exactly one source
  and any number of receivers. SSM is derived from earlier work in
  EXPRESS [EXPRESS]
  and supports one-to-many multicast.The [EXPRESS].The address range 232/8 has been assigned by IANA
  [IANA-ALLOC] for SSM service in IPv4. For IPv6, the range FF3x::/96 is
  defined for SSM services [SSM-IPv6].

  Source-Filtered Multicast (SFM) : This is a variant of the multicast ASM service model defined in RFC 1112. A source transmits IP datagrams to
  a host group address in
  model, and uses the same address range of 224.0.0.0 to 239.255.255.255.
  However, each as ASM
  (224.0.0.0-239.255.255.255).  It extends the ASM service model as
  follows. 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
  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) MLDv2) [MLDv2] protocol for
  IPv6 [MLDv2].
  IPv6.  We shall henceforth refer to these two protocols as
  "SFM-capable". "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". Note that while SFM is a different model than
  ASM from a receiver standpoint, there is no distinction between the
  two for a sender.

For the purpose of this document, we treat the scoped multicast model of
[RFC2365] to be a variant of ASM since it does not explicitly restrict
the number of sources, but only requires that they be located within the
scope zone of the group.

2. The IGMP/PIM-SM/MSDP/MBGP Architecture Protocol Suite for ASM

   All

   As of this writing, all multicast-capable networks of today support the ASM
   service model. One of the most common multicast protocol architectures suites for
   supporting ASM in wide-area backbones consists of IGMP version 2 [IGMPv2], PIM-SM [PIM-SM,PIM-SM-NEW], [PIM-
   SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP] protocols.  To become a member of a particular host group end-hosts
   report multicast group membership with querier routers handling
   multicast group membership function using the IGMP version 2 (IGMPv2)
   protocol  IGMPv2
   [RFC2236] for IPv4 or is the MLD version 1 (MLDv1) most commonly used protocol
   [RFC2710] for IPv6.  Routers then exchange messages with each other
   according to a routing protocol hosts to construct specify
   membership in a distribution tree
   connecting all the end-hosts. A number of different protocols exist
   for building multicast forwarding trees, which differ mainly in group, and nearly all multicast routers
   support (at least) IGMPv2. In case of IPv6, MLDv1 [RFC2710] is the
   type
   commonly used protocol.

   Although a number of delivery tree constructed [IPMULTICAST,PIM-ARCH, PIM-SM, PIM-
   SM-NEW, PIM-DM]. For scalability reasons, sparse-mode protocols
   (e.g., PIM-SM) are preferred over dense-mode protocols (e.g., DVMRP,
   PIM-DM) such as PIM-DM [PIM-DM], CBT
   [RFC2189,RFC2201], DVMRP [IPMULTICAST], etc. exist for deployment building
   multicast tree among all receivers and sources in large backbone networks (though many
   smaller networks deploy dense-mode protocols). PIM-SM, the same
   administrative domain, PIM-SM [PIM-SM, PIM-SM-NEW] is the most widely
   deployed sparse-mode protocol,
   used protocol.  PIM-SM builds a spanning multicast tree rooted at a
   core rendezvous point or RP for all group members within a single
   administrative domain. Multicast sources within this domain
   send their data  A 'first-hop' router adjacent to this a multicast
   source sends the source's traffic to the RP for its domain. The RP which
   forwards the data down the shared spanning tree to all interested
   receivers within the domain. PIM-SM also allows receivers to switch
   to a source-based shortest path tree.

   As of this writing, multicast end-hosts with SFM capabilities are not
   widely available.  Hence a client can only specify interest in an
   entire host group and receives data sent from any source to this
   group. PIM-SM also allows
   receivers to switch to

   Inter-domain multicast service (i.e., where at least one source for a source-based shortest path tree.
   multicast group is located in a different domain than the receivers)
   requires additional protocols - MSDP [MSDP] and MBGP [MBGP] are the
   most commonly used ones. An RP uses the MSDP [MSDP] protocol to
   announce multicast sources to RPs in other domains. When an RP
   discovers a source in a different domain transmitting data to a
   multicast group for which there are interested receivers in its own
   domain, it joins the shortest-path source based tree rooted at that
   source. It then redistributes the data received to all interested
   receivers via the intra-domain shared tree rooted at itself.

   The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP]
   to support the advertisement of reachability information for
   multicast routes. This allows an autonomous system (AS) to support
   incongruent unicast and multicast routing topologies, and 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 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 a deployable solution to prevent address collisions among
      multiple applications. The problem is more much less serious for IPv4 than IPv6
      than for IPv4 since the total number size of the multicast addresses address space is smaller.
      much larger.  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] are generally perceived as
      being too complex (with respect to the dynamic nature of multicast
      address allocation) for widespread deployment.

4. Source Specific Multicast (SSM)

   B) Lack of Access control : Benefits and Requirements

   As mentioned before,

       In the Source Specific Multicast (SSM) ASM service
   model defines model, a receiver cannot 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.  Moreover, even when a source is allocated a multicast
      group address to transmit on, it has no way of enforcing that no
      other source will use the same address.  This is true even in the
      case of IPv6, where address collisions are less likely due to the
      much larger size of the address space.

   C) 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 are not necessary.

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

   As mentioned before, the Source Specific Multicast (SSM) service
   model defines a "channel" identified by an (S,G) pair, where S is a
   source address and G is an SSM destination address. 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. When a receiver subscribes to an (S,G) channel, it
      receives data sent by a only the source S. In contrast, any host
      can transmit to an ASM host group. Hence, it is more difficult to
      spam an SSM channel than an ASM host group.

      4.2

      A) Address Allocation : SSM defines channels on a per-source
      basis, i.e., the channel (S1,G) is distinct from the channel
      (S2,G), where S1 and S2 are 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

      B) Access Control : SSM lends itself to an elegant solution to the
      access control problem. When a receiver subscribes to an (S,G)
      channel, it receives data sent by a only the source S. In
      contrast, any host can transmit to an ASM host group. At the same
      time, when a sender picks a channel (S,G) to transmit on, it is
      automatically ensured that no other sender will be transmitting on
      the same channel (except in the case of malicious acts such as
      address spoofing). This makes it much harder to "spam" an SSM
      channel than an ASM multicast group.

      C) Handling of well-known sources : SSM requires only source-based
      forwarding trees; this eliminates the need for a shared tree
      infrastructure. In terms of the 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.

      4.4 Note that MBGP is
      still required for distribution of multicast reachability
      information.

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

5. SSM Framework

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

   --------------------------------------------------------------
    IANA assigned 232/8 for IPv4             ADDRESS ALLOCATION
         FF3x::/12 for IPv6
   --------------------------------------------------------------
                |
                v
       +--------------+ session directory/web page
       | source,group |                      SESSION DESCRIPTION
   --------------------------------------------------------------
              ^ |
        Query | | (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)
   --------------------------------------------------------------
               v
     +-----------------+  Querier Router
     |   IGMPv3/MLDv2  |                         QUERIER
   --------------------------------------------------------------
       |   PIM-SSM  |                        PIM-SSM ROUTING
       +------------+     Designated Router
               |
               | (S,G) Join only
               v
         +-----------+  Backbone Router
         |  PIM-SSM  |
         +-----------+
               |
               | (S,G) Join only
               V

     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. 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 recommend that routers
   should not send SSM traffic to parts of the network that do not have
   channel subscribers.

   Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
   range. However, SSM service, as defined in [SSM-ARCH], is guaranteed available
   only in this address range for 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
   Bytes 0-3 (starting from the least significant byte) of the IP
   address is are used to specify a multicast group id, bytes 4-11 is
   be are 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 is specified by setting
   both the prefix length field and the prefix field to zero.

   5.2 Session Description and Channel Discovery

      An SSM receiver application must know both the SSM destination
      address G and the source address S before subscribing to a
      channel. Thus the function of channel Channel discovery becomes is 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
      This is outside the scope of this framework document.

   5.3. SSM-Aware Applications

      -- For similar to what is used for ASM applications sourcing content via SSM channels, the where a
      multicast session
      must needs to be advertised including a announced so that potential
      subscribers can know of the multicast group adddres, encoding
      schemes used, etc.  In fact, the only additional piece of
      information that needs to be announced is the source address as well as an SSM
      address.

      -- for
      the channel being advertised.  However, the exact mechanisms for
      doing this is outside the scope of this framework document.

   5.3. SSM-Aware Applications expecting to subscribe

      -- An application that wants to received an SSM session must first
      discover the channel address in use. Any of the mechanisms
      described in Section 5.2 can be used for this purpose.

      -- A receiving application must be
      capable of specifying able to specify both a source
      address in addition to an SSM and a destination address. address to the network layer protocol
      module on the end-host. In other words, the application must be "SSM-
      aware".
      "SSM-aware".

      Specific API requirements are identified in [THAL00]. [THAL00]
      describes a recommended application programming interface for a
      host operating system to support the SFM service model. Although
      it is intended for SFM, a subset of this interface is sufficient
      for supporting SSM.

   5.4. IGMPv3/MLDv2 Host Reporting and Querier

      IGMP version 2 [IGMPv2] allows end-hosts to report their interest
      in a multicast group by specifying a class-D IP address for IPv4.
      However in

      In order to implement the use SSM service model, service, an end-host must be able to specify a
      channel address, consisting of a source's unicast address as well as and an
      SSM destination address. This capability IGMP version 2 [IGMPv2] and MLD version 1
      [MLDv1] allows an end-host to specify only a destination multicast
      address.  The ability to specify an SSM channel address c is
      provided by IGMP version 3
      [IGMPv3]. IGMPv3 supports [IGMPv3] and MLD version 2 [MLDv2].
      These protocols support "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,
      In fact, IGMPv3 provides a superset of the capabilities required
      to realize the SSM service model.

      There are a number of backward compatibility issues between IGMP
      versions 2 and 3 which have to be addressed.

      A detailed discussion of the use of IGMPv3 in the SSM destination
      address range is provided in [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 does not provide the multicast group(s) that it is interested in. source
      filtering capability required for the SSM service model. Version 2 of MLD [VIDA01] is derived from, and provides the same
      support for source-filtering as, IGMPv3.

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. The original
    PIM-SM [PIM-SM] did not allow a router to choose between a shared
   tree
      of MLD [VIDA01] is derived from, and provides the same support for
      source-filtering as, IGMPv3. THus IGMPv3 (or MLDv2 for IPv6)
      provides a source-based tree. In fact, a receiver always joined a PIM
   shared tree to start with, and may later be switched host with the ability to a per-source
   tree by its adjacent edge router. However, request the more recent PIM-SM
   specification network for an SSM
      channel subscription.

5.5. PIM-SSM Routing

   [PIM-SM-NEW] has support provides guideliness for how a PIM-SM implementation
   should handle source-specific join.

   Supporting host reports as required by SSM.
   Earlier versions of the PIM protocol specifications did not describe
   how to do this.

   The router requirements for operation in the SSM range are detailed
   in [SSM-ARCH]. These rules are primarily concerned with PIM-SM involves preventing
   ASM-style behaviour in the SSM address range. In order to comply with
   [SSM-ARCH] several changes to the PIM-SM protocol are required, 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 [PIM-SM-NEW].The most important changes to in PIM-SM
   required for compliance with respect to SSM [SSM-ARCH] 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.

   Note that only a small subset of the full PIM-SM protocol
   functionality is needed to support the SSM service model. This subset
   is explicitly documented in [PIM-SM-NEW].

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 deployment, since both models for Internet multicast. are expected to be used
   at least in the foreseeable future. SSM is the ONLY service model for
   the SSM address range - 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 interoperability 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 MSDP is not needed for
   MSDP, SSM, but MSDP is still required to support
   needed if ASM for non-SSM class-D
   IPv4 addresses. In order is supported. [SSM-BCP] specifies operational
   recommendations to help ensure that SSM is MSDP does not interfere with the sole forwarding
   model in 232/8,
   ability of a network to support the SSM service model. Specifically,
   [SSM-BCP] states that 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 Lyles 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.
   http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.

   [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
   Progress.

   [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, Comments 2362.

   [PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas.
   Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
   Specification (Revised)", Work In Progress, 2000.  <draft-ietf-pim-
   sm-v2-new-01.txt>.

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

   [RFC2189] A. Ballardie.  Core-Based Trees (CBT Version 2) Multicast
   Routing -- Protocol Specification. Request for Comments 2189.

   [RFC2201] A. Ballardie.  Core-Based Trees (CBT) Multicast Routing
   Architecture. Request for Comments 2201.

   [RFC2365] D. Meyer.  Adminstratively Scoped IP Multicast. Request for
   Comments 2365.

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

   [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
   2000.

   [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
            Progress.

   [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
   {supratik,cdiot}@sprintlabs.com
   http://www.sprintlabs.com

   Leonard Giuliano
   Greg Shepherd
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089 USA
   {lenny,shep}@juniper.net

   Robert Rockell
   David Meyer
   Sprint E|Solutions
   Reston Virginia USA
   {rrockell,dmm}@sprint.net

   John Meylor
   Cisco Systems
   San Jose CA USA
   jmeylor@cisco.com

   Brian Haberman
   No Affiliation
   haberman@innovationslab.net