Internet Draft                                           B. Nickless
    Document:                                           Argonne National
    draft-nickless-mcast-ipv4-impl-survey-00.txt              Laboratory
    Expires: July 2002                                      January 2002


             A Survey of IPv4 Multicast Service Implementations


1 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.


2 Abstract

    This document surveys various ways of implementing the IPv4
    Multicast Service Model.  Each mechanism is evaluated against a
    common set of criteria.


3 Table of Contents

    1 Status of this Memo..............................................1
    2 Abstract.........................................................1
    3 Table of Contents................................................1
    4 Introduction.....................................................2
    5 Conventions used in this document................................2
    6 Evaluation Framework.............................................2
    7.1 Native Multicast (IGMPv2)......................................2
    7.2 Native Multicast (IGMPv3)......................................3
    7.3 PIM-speaking Host Implementation of Core Operations............4
    7.4 TCP-based Tunnel Implementation of Core Operations.............5
    7.5 Emcast Multicast Library.......................................5
    7.6 UDP Multicast Tunneling Protocol and CastGate..................6

    Nickless      Informational - Expires August 2002                1
                Survey of IPv4 Multicast Implementations  February 2002

    8 Security Considerations..........................................6
    9 Acknowledgements.................................................7
    10 References......................................................7
    11 Author's Address................................................7

4 Introduction

    The traditional Multicast [MCAST][SVCMODEL] service model is
    conceptually simple: a source application sends datagrams to the
    network, which delivers those datagrams to interested receiver
    applications.  Some applications could benefit from extensions to
    this conceptual model, such as providing the source application with
    knowledge of the existence of receivers.  There remain networks
    where IP Multicast deployment is not complete, requiring
    applications to work around the problem.  An application may wish to
    control which sources and receivers are permitted to participate.

    Criteria for evaluating implementations to support the application
    framework are supplied, along with a brief survey of some existing
    possible implementations.

5 Conventions used in this document

    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 [RFC2119].

6 Evaluation Framework

    As shown in the rest of this Draft, there are several possible ways
    of providing the multicast service to applications.  Criteria for
    evaluating each approach should include:

     - How expensive is the deployment of the approach?  Does it require
       the cooperation of the local network administrator to operate?
     - Is it compatible with the Best Current Practices of routing IP
       multicast in the Internet core?
     - Which of the Multicast Service Model [SVCMODEL] Core and Desired
       operations are supported?
     - Does it ensure that only one copy of a multicast packet need
       traverse a network link?
     - Does it allow for both multicast transmission and reception?

    Each of the following approaches is evaluated by these criteria.

7.1 Native Multicast (IGMPv2)

    IGMPv2 [IGMPv2] is the traditional way for hosts to interact with
    networks to provide the core Multicast Service Model Operations.

    InterfaceDiscovery is supported by putting reachability information
    in the host reachability table, generally with a static route to the
    224.0.0.0/4 logical internet subnet.  The application looks up this

    Nickless      Informational - Expires August 2002                2
                Survey of IPv4 Multicast Implementations  February 2002

    reachability information and uses the IP address associated with the
    appropriate host interface.

    GroupTransmit is supported by the host executing the equivalent of a
    POSIX sendto() system call, with the source address set by the
    InterfaceDiscovery step above, and the destination address set to
    the intended Group address.

    GroupJoinAny is supported through the operation of the IGMP
    protocol.  The application instructs the host to create IGMP Group
    Membership reports, which the network uses to create appropriate
    forwarding trees to the local subnetwork.

    The GroupJoinOnly operation is not supported in IGMPv2.

    GroupReceive is supported by the host executing the equivalent of a
    POSIX recvfrom() call, with the from address set to the Group
    address.

    GroupLeave is supported through the operation of the IGMPv2
    protocol. The application instructs the host to stop issuing IGMPv2
    Group Membership reports indicating interest in that Group.

    An extension of IGMP might support the SecureJoinAny Operation.

    Implementation of this approach requires that the host, and the host
    network, be made IGMP-aware.

    If properly configured by the network administrator, it is
    compatible with IPv4 Multicast Routing Best Current Practices.

    Only one copy of a multicast packet is sent or received from the
    local network by the local IGMPv2 Designated Router.

    Multicast transmission and reception is supported.

7.2 Native Multicast (IGMPv3)

    Single Source Multicast [SSM]is generally implemented by a
    combination of IGMPv3 between the host and the network, and source-
    specific-tree-only PIM operations.  Group addresses are in the
    232.0.0.0/8 range, and any transmission within that range is source-
    specific.

    Within that context, InterfaceDiscovery, GroupTransmit,
    GroupJoinAny, GroupReceive, and GroupLeave operate the same way as
    described in the Native Multicast section.  In addition, IGMPv3
    supports the GroupJoinOnly operation.

    Implementation of this approach requires that the host, and the host
    network, be made IGMPv3-aware.

    If properly configured by the network administrator, it is
    compatible with IPv4 Multicast Routing Best Current Practice.

    Nickless      Informational - Expires August 2002                3
                Survey of IPv4 Multicast Implementations  February 2002


    Only one copy of a multicast packet is sent or received from the
    local IGMPv3 Designated Router.

    Multicast transmission and reception is supported.

7.3 PIM-speaking Host Implementation of Core Operations

    The design and implementations of IGMPv2 predate the PIM routing
    protocol.  However, one could imagine a host that ignores IGMP and
    speaks PIM directly with routers on the local subnetwork.

    InterfaceDiscovery would have to be hard-coded or otherwise
    discovered by the implementation.  The application or host would
    implement the PIM protocol instead of the IGMP protocol.  This might
    mean the host would have to discover or be configured with the
    appropriate upstream PIM speaker (PIM Designated Router) for the
    local subnetwork.

    GroupTransmit would be accomplished by encapsulating the application
    data into a PIM Register message and transmitting that encapsulated
    data via unicast to the PIM Rendezvous Point.  This would happen
    relatively infrequently; most of the data would be discarded until a
    PIM Join was received.  Given a PIM Join, the application would
    transmit directly onto the local subnetwork.

    JoinOnly would be accomplished by sending an (S,G) PIM Join towards
    the local PIM Designated Router, refreshed appropriately.  JoinAll
    would be accomplished by sending a (*,G) PIM Join towards the local
    PIM Designated Router, and then sending (S,G) PIM Joins when
    datagrams arrive with the PIM SPT bit set.

    GroupReceive is done by the host executing the equivalent of a UNIX
    recvfrom() call, with the from address set to the Group address.

    A variant of GroupSize is accomplished as a side effect.  Until a
    PIM Join arrives, the application can assume that no receiver has
    expressed an interest in the data at full rate, so the application
    need not even generate the data for transmission, much less transmit
    it on the local subnetwork.

    Implementation of this approach requires that the host and at least
    one router on the local network speak the PIM protocol.

    It is consistent with IPv4 Multicast Routing Best Current Practice.

    Only one copy of a multicast packet is sent or received between the
    host and its PIM Neighbor, except for the occasional Register packet
    transmitted to the PIM Rendezvous Point.

    Multicast transmission and reception is supported.


    Nickless      Informational - Expires August 2002                4
                Survey of IPv4 Multicast Implementations  February 2002

7.4 TCP-based Tunnel Implementation of Core Operations

    Consider a hypothetical tunneling protocol that bypasses the local
    subnetwork of a host with an interested application.  Multicast
    packets are transmitted from a tunnel host participating in the
    native IP multicast core of the internetwork, over a TCP channel, to
    the application on a host.

    InterfaceDiscovery requires configuration on both the tunnel host
    and the application host.  (This configuration might be automated.)
    The application host needs to know what IP address to use to source
    packets, so that the internetwork core knows to get those packets
    from the tunnel host.

    GroupTransmit would be accomplished by encapsulating the application
    data into the TCP channel and transmitting it to the tunnel host.
    If the TCP transmit buffer is full, the application data would be
    discarded.

    GroupJoinAny, GroupJoinOnly, and GroupLeave would be accomplished by
    a special message through the TCP channel, where the application
    host notifies the tunnel host of its interest (or disinterest) in
    data from various groups (and possibly specific sources.)

    GroupReceive would be accomplished by the tunnel host encapsulating
    data into the TCP channel towards the application host.  If the TCP
    transmit buffer is full, the application data would be discarded.
    The application host would decapsulate the data from the TCP stream
    and deliver it to the application in datagram form.

    TCP is preferred in this scenario because of its ability to sense
    congestion and back off appropriately.

    Implementation of this approach requires that the application host
    implement the TCP-Based Tunnel protocol, and that the application
    host be associated with at least one tunnel host.  It does not
    require that the application host subnetwork be configured for
    multicast in any way.

    Given proper configuration of the tunnel host, it is consistent with
    IPv4 routing Best Current Practice.

    If there are multiple application hosts on a given subnetwork,
    multiple copies of a multicast packet may be carried to that
    subnetwork from the tunnel host (one each per TCP tunnel).

    Multicast transmission and reception is supported.

7.5 Emcast Multicast Library

    Emcast [EMCAST] is a user-level implementation of several of the
    Core Operations.  It implements the GroupTransmit, GroupJoinAny,
    GroupLeave, and GroupReceive operations with library calls, and has
    hooks for handlers of various types.  Currently supported handlers

    Nickless      Informational - Expires August 2002                5
                Survey of IPv4 Multicast Implementations  February 2002

    include the traditional Internet Multicast, Banana Tree Protocol,
    and Internet Relay Chat.

    GroupJoinOnly and InterfaceDiscovery are not supported.

    Use of Emcast requires that the application support the Emcast
    library and at least one handler.  If using the Banana Tree Protocol
    or Internet Relay Chat handlers, it does not require that the local
    subnetwork be configured for multicast in any way.

    If Emcast was extended to support the InterfaceDiscovery operation,
    specifically giving the application an internetwork-unique
    multicast-enabled IP source address, then the non-traditional user-
    level multicast forwarding schemes (e.g. Banana Tree Protocol and
    Internet Relay Chat) could be made consistent with IPv4 routing Best
    Current Practice.  This would of course require some gateway
    function between a Banana Tree Protocol or Internet Relay Chat
    domain and the IPv4 multicast core.

    Multicast transmission and reception is supported.

7.6 UDP Multicast Tunneling Protocol (UMTP) and CastGate

    The UDP Multicast Tunneling Protocol [UMTP] supports IPv4 multicast
    applications across a unicast-only internetwork.  A server bridges
    traffic between the multicast-enabled and unicast-only portions of
    an internetwork.  Only UDP multicast datagrams are supported.

    GroupTransmit, GroupReceive, GroupJoinAny, and GroupLeave are
    supported through the UMTP protocol operation.

    The InterfaceDiscovery and GroupJoinOnly operations are not
    supported.

    Implementation of this approach requires a tunnel server connected
    to a multicast-enabled portion of the internetwork.

    Multicast transmission and reception is supported; however, the
    transmitted UDP datagrams from a tunnel client are rewritten to
    appear as though they were sourced from the tunnel server.

    CastGate [CASTGATE] provides a general mechanism for UMTP tunnel
    clients to automatically discover and initiate connections to UMTP
    tunnel servers.


8 Security Considerations

    Multicast technology is subject to various denial-of-service
    attacks.

    Certain host-based implementation of IP multicast forwarding are
    subject to security vulnerabilities; especially when insecure

    Nickless      Informational - Expires August 2002                6
                Survey of IPv4 Multicast Implementations  February 2002

    services are delivered IP multicast packets without first executing
    a GroupJoinAny or GroupJoinOnly operation.

9 Acknowledgements

    This work was supported by the Mathematical, Information, and
    Computational Sciences Division subprogram of the Office of Advanced
    Scientific Computing Research, U.S. Department of Energy, under
    Contract W-31-109-Eng-38.

    David Helder provided useful comments and suggestions.


10 References

    [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering.
       August 1989.

    [SVCMODEL] draft-nickless-mcast-svc-model-00.txt. B. Nickless.
       February 2002.

    [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate
       Requirement Levels.  S. Bradner.  March 1997.

    [IGMPv2] Internet Group Management Protocol, Version 2.  W. Fenner.
       RFC 2236.

    [SSM] draft-ietf-ssm-overview-02.txt.  S. Bhattacharyya, C. Diot, L.
       Giuliano, R. Rockwell, J. Meylor, D. Meyer, G. Shepherd, B.
       Haberman.  December 2001.

    [EMCAST] http://www.junglemonkey.net/emcast by David A. Helder

    [UMTP] http://www.live.com/umtp.txt by Ross Finlayson

    [CASTGATE] draft-liefooghe-castgate-01.txt.  P. Liefooghe.  November
       2001.


11 Author's Address

    Bill Nickless
    Argonne National Laboratory
    9700 South Cass Avenue #221     Phone:  +1 630 252 7390
    Argonne, IL 60439               Email:  nickless@mcs.anl.gov

    Nickless      Informational - Expires August 2002                7