[AG-TECH] Multicast service model
Bill Nickless
nickless at mcs.anl.gov
Tue Jan 22 17:45:41 CST 2002
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