[AG-TECH] Multicast service model
Lucy E. Lynch
llynch at darkwing.uoregon.edu
Tue Jan 22 18:34:21 CST 2002
Bill,
You've been reading my mind again - I did a quick cross check on
membership on ag-tech & mboned and found only the following points of
intersection:
almeroth at cs.ucsb.edu
esj at cs.fiu.edu
llynch at darkwing.uoregon.edu
nickless at mcs.anl.gov
tony at ncsa.uiuc.edu
ag-tech w/305 members & mboned w/425 members
Since the access grid community are currently some of the most active
users of Any Source Multicast service it might be useful for
1] more folks to follow the mboned discussions
http://www.ietf.cnri.reston.va.us/html.charters/mboned-charter.html
2] those of us in two places at once to cross post (judiciously)
when issues of interest arise
thanks for getting this rolling -
Lucy E. Lynch Academic User Services
Computing Center University of Oregon
llynch at darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998
On Tue, 22 Jan 2002, Bill Nickless wrote:
> With the current discussion about multicast bridges, I think it might be
> about the right time to show people this Internet Draft on the IP multicast
> service model.
>
> The closest thing we have in the Internet for a multicast service model
> is RFC 1112 by Steve Deering (1989). It defines three things simultaneously:
>
> - The multicast service model
>
> - The system call extensions needed on hosts to support those apps
> that want to take advantage of the multicast service model
>
> - (In Appendix A) the wire protocol to control multicast on
> the local subnet: IGMP
>
> For the Access Grid, the service model is the most valuable of the
> above. The system call extension expectations are buried in the vic and
> rat applications, so some programming effort would be required to move
> beyond that. The Access Grid applications have no particular need for an
> IGMP-based local wire protocol; in fact, the existing MSB doesn't use IGMP
> at all.
>
> Caveats: the reference for the multicast service model on page 1 should
> be RFC 1112.
>
> David Helder suggested that we also look at the UDP Multicast
> Tunneling Protocol (UMTP) and Castgate.
>
> Comments and criticism welcome.
>
>
> Internet Draft B. Nickless
> Document: draft-nickless-mcast-svc-model-00.txt Argonne National
> Laboratory
> Expires: July 2002 January 2002
>
>
> Towards a Multicast Service Model
>
>
> 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.
>
>
> Abstract
>
> This document outlines a framework for IP Multicast applications.
> It intends to describe the services that an application host and
> associated networks should provide, and provide a framework for
> evaluating ways to implement those services for applications.
>
>
> Table of Contents
>
> Status of this Memo................................................1
> Abstract...........................................................1
> Conventions used in this document..................................2
> Introduction and Motivation........................................2
> Core Application Operations........................................3
> Desirable Application Operations...................................4
> Evaluation Framework...............................................4
> Native Multicast (IGMP) Implementation of Core Operations..........4
> SSM With Group Leader Implementation of Core Operations............5
> PIM-speaking Host Implementation of Core Operations................6
> Hypothetical TCP-based Tunnel Implementation of Core Operations....6
>
> Nickless Informational - Expires July 2002 1
> Towards A Multicast Service Model January 2002
>
> Emcast Multicast Library...........................................7
> Security Considerations............................................8
> Acknowledgements...................................................8
> References.........................................................8
> Author's Address...................................................8
>
>
> Overview
>
> The traditional IP Multicast 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. The traditionally
> unreliable nature of IP Multicast datagram delivery requires
> applications to implement their own reliable delivery schemes.
>
> This Draft intends to describe an application framework that
> provides a unified multicast application service model. Such a
> model could lead to a common Application Programming Interface for
> multicast applications. It could also provide a framework for
> evaluating protocols and implementations.
>
> Criteria for evaluating implementations to support the application
> framework are supplied, along with a brief survey of some existing
> possible implementations.
>
>
> 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].
>
>
> Introduction and Motivation
>
> IP Multicast [MCAST] is an internetwork service that allows IP
> datagrams sent from a source to be delivered to one or more
> interested receiver(s). That is, a host system sends a packet to
> the internetwork with a multicast group destination address. The
> internetwork transports this packet to all receivers (replicated
> where necessary) that have registered interest in receiving these
> packets.
>
> This multicast service model (XXX – needs reference) was derived
> from how an operating system interacts with an Ethernet network
> interface. To send, the operating system builds Ethernet frames in
>
> Nickless Informational - Expires July 2002 2
> Towards A Multicast Service Model January 2002
>
> a buffer and hands that buffer off to the Ethernet interface for
> transmission. To receive, an operating system programs the Ethernet
> interface to accept frames that match a certain Media Access Control
> (MAC) address.
>
> Several classes of multicast applications have evolved. The first
> and perhaps best-known application is the multiparty multimedia
> conference. Following close behind is the use of IP multicast for
> service discovery, such as how the Open Shortest Path First (OSPF)
> routing protocol discovers adjacent routers. Distributing media
> content (for example, Internet Radio) is a natural fit for IP
> multicast. Time-sensitive distribution of financial market
> information can also be done through IP multicast. Parallel
> computations often require collective operations (barriers,
> broadcasts, multicasts) that could be implemented using IP multicast
> technology. The distribution of files across clusters of computers
> is a natural use of reliable multicast protocols.
>
> Core Application Operations
>
> Application developers and users have come to expect certain
> facilities to be available from an IP Multicast-enabled network.
> Often, when a local host or network does not support native IP
> Multicast, the application developer and/or end-user will implement
> these facilities independent of the network.
>
> Host Interface Discovery (INTERFACE DISCOVERY): The application
> queries the host to discover which, if any, of the host interfaces
> support IP Multicast services, and the IP address assigned to each
> interface.
>
> Multicast Packet Transmission (TRANSMIT): An application constructs
> an IP datagram including the IP Source Address determined through
> the INTERFACE DISCOVERY step and the IP Destination Address
> determined through the GROUP SELECT step. A pointer to this
> datagram is conveyed to the host, which is then responsible for
> transmitting this datagram to the network for transport to
> interested receivers.
>
> Join Multicast Group (JOIN): An application notifies the host that
> it wishes to receive IP datagrams addressed to a given IP
> Destination/Group address. Optionally, in the case of Source
> Specific Multicast, the application also notifies the host that it
> wishes to receive IP datagrams originated by a certain set of hosts
> identified by IP Source Addresses. The host notifies the network to
> deliver such packets, and returns an opaque identifier to the
> application for later use.
>
> Multicast Packet Receipt (RECEIVE): An application provides a memory
> pointer to the host, along with an opaque identifier provided by the
> host in the JOIN operation. The host waits until a datagram is
> received from the network that has an appropriate IP Destination
> Group address (and optionally an appropriate IP Source Address).
>
> Nickless Informational - Expires July 2002 3
> Towards A Multicast Service Model January 2002
>
> When received, the data is copied into memory associated with the
> pointer.
>
> Leave Multicast Group (LEAVE): An application notifies the host that
> it no longer wishes to receive IP datagrams addressed to a given IP
> Destination and/or Group address. The host in turn notifies the
> network to stop delivering such packets.
>
> Desirable Application Operations
>
> In addition to the Core Application Operations listed above,
> application developers and users are requesting certain additional
> services. At present these are not widely available or in use.
>
> Measure Group Size (GROUP SIZE): An application queries the host to
> determine whether there are any interested Receivers to which
> multicast datagrams might be delivered. If the returned estimate is
> zero, the application might choose not to construct IP datagrams for
> transmission.
>
> Authenticated Join Multicast Group (SECURE JOIN): An application
> must provide an authentication token as part of the JOIN operation.
>
> Authenticated Transmit To Multicast Group (SECURE TRANSMIT): An
> application must be "approved" in some way in order for its data to
> be received by cooperating receivers.
>
> 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?
> - 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.
>
>
> Native Multicast (IGMP) Implementation of Core Operations
>
> The traditional IGMPv2 service model implements the core application
> services in the following way:
>
> INTERFACE DISCOVERY is done 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
> reachability information and uses the IP address associated with the
> appropriate host interface.
>
> Nickless Informational - Expires July 2002 4
> Towards A Multicast Service Model January 2002
>
>
> TRANSMIT is done by the host executing the equivalent of a UNIX
> sendto() call, with the source address set by the INTERFACE
> DISCOVERY step above, and the destination address set to the
> intended Group address.
>
> JOIN is done 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.
>
> RECEIVE is done by the host executing the equivalent of a UNIX
> recvfrom() call, with the from address set to the Group address.
>
> LEAVE is done through the operation of the IGMP protocol. The
> application instructs the host to stop issuing IGMP Group Membership
> reports indicating interest in that Group.
>
> An extension of IGMP might support the SECURE JOIN 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 routing Best Current
> Practices. Only one copy of a multicast packet is sent or received
> by the local Designated Router. Multicast transmission and
> reception is supported.
>
>
> SSM With Group Leader Implementation of Core Operations
>
> Single Source Multicast 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, INTERFACE DISCOVERY, TRANSMIT, JOIN, RECEIVE,
> and LEAVE operate the same way as described in the Native Multicast
> section.
>
> Some applications may wish to use SSM to provide many-to-many
> communications. It is possible to bootstrap many-to-many by
> designating an application group leader that redistributes the (S,G)
> information about active sources down a multicast distribution tree.
> Each interested receiver then executes a source-specific JOIN
> towards the newly discovered source.
>
> SECURE TRANSMIT can be implemented by controlling what (S,G)
> information is propagated down the source-information multicast
> distribution tree.
>
> SECURE JOIN can be implemented by encrypting the information
> propagated down the source-information multicast distribution tree.
>
>
> Nickless Informational - Expires July 2002 5
> Towards A Multicast Service Model January 2002
>
> 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 routing Best
> Current Practice. Only one copy of a multicast packet is sent or
> received by the local Designated Router. Multicast transmission and
> reception is supported.
>
> PIM-speaking Host Implementation of Core Operations
>
> The design and implementations of IGMP predate the PIM routing
> protocol. However, one could imagine a host that ignores IGMP and
> speaks PIM directly with routers on the local subnetwork.
>
> INTERFACE DISCOVERY 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.
>
> TRANSMIT 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.
>
> JOIN would be accomplished by sending a PIM Join towards the local
> PIM Designated Router, refreshed appropriately.
>
> RECEIVE 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 GROUP SIZE is accomplished as a side effect. Until the
> 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 routing Best Current Practice. Only one copy
> of a multicast packet is sent or received by the local Designated
> Router. Multicast transmission and reception is supported.
> Hypothetical 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.
>
> INTERFACE DISCOVERY requires configuration on both the tunnel host
> and the application host. (This configuration might be automated.)
>
> Nickless Informational - Expires July 2002 6
> Towards A Multicast Service Model January 2002
>
> 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.
>
> TRANSMIT 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.
>
> JOIN and LEAVE 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.)
>
> RECEIVE 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.
>
> Emcast Multicast Library
>
> Emcast [EMCAST] is a user-level implementation of several of the
> Core Operations. It implements the TRANSMIT, JOIN, LEAVE, and
> RECEIVE operations with library calls, and has hooks for handlers of
> various types. Currently supported handlers include the traditional
> Internet Multicast, Banana Tree Protocol, and Internet Relay Chat.
>
> 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 INTERFACE DISCOVERY 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
>
> Nickless Informational - Expires July 2002 7
> Towards A Multicast Service Model January 2002
>
> function between a Banana Tree Protocol or Internet Relay Chat
> domain and the IPv4 multicast core.
>
> Multicast transmission and reception is supported.
>
> 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
> services are delivered IP multicast packets without first executing
> a JOIN operation.
>
> 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.
>
>
> References
>
> [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate
> Requirement Levels. S. Bradner. March 1997.
>
> [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering.
> Aug-01-1989.
>
> [EMCAST] http://www.junglemonkey.net/emcast by David A. Helder
>
>
> Author's Address
>
> Bill Nickless
> Argonne National Laboratory
> 9700 South Cass Avenue #221 Phone: +1 630 252 7390
> Argonne, IL 60439 Email: nickless at mcs.anl.gov
>
> Nickless Informational - Expires July 2002 8
>
> ===
> Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless at mcs.anl.gov
>
More information about the ag-tech
mailing list