[AG-TECH] Updated multicast service model draft
Bill Nickless
nickless at mcs.anl.gov
Thu Jan 31 23:46:05 CST 2002
As promised, enclosed is a rewrite of the Multicast Service Model draft
that you received earlier. The purpose of this Draft is to update the
service model defined in RFC 1112, but in an implementation-independent way.
This Draft is also available at
http://www-fp.mcs.anl.gov/~nickless/draft-nickless-mcast-svc-model-00.txt
Internet Draft B. Nickless
Document: draft-nickless-mcast-svc-model-00.txt Argonne National
Laboratory
Expires: August 2002 February 2002
The IP 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.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................2
Introduction and Motivation........................................2
Addressing.........................................................2
Internetwork Multicast Routing.....................................3
Core Application Operations........................................3
Desirable Application Operations...................................4
Security Considerations............................................5
Acknowledgements...................................................5
References.........................................................5
Author's Address...................................................5
Nickless Informational - Expires August 2002 1
Towards A Multicast Service Model February 2002
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.
The multicast service model described in [MCAST] was derived from
how an operating system interacts with an Ethernet network
interface. To send, the operating system builds Ethernet frames in
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.
As these applications have been implemented and deployed, the
operations needed to support them have become clearer. This
document intends to describe those operations in an implementation-
neutral way. Such a description will provide a basis for evaluating
various implementations, and may lead to a general Application
Programming Interface (API) for multicast applications.
Multicast Addressing
Internet Protocol datagrams have a source and destination address.
There are special destination addresses used to refer to the set of
interested receivers. These addresses are referred to as Group
Nickless Informational - Expires July 2002 2
Towards A Multicast Service Model February 2002
addresses, because multiple applications and hosts may be interested
in the datagrams addressed to a given Group address.
IPv4 Group addresses are chosen from the so-called Class D address
space 224.0.0.0/4. IPv6 Group addresses start with the octet 0xFF
(See [ADDARCH] for details of the IPv6 Group Address assignments.)
Hosts are not assigned the Group addresses in advance; instead, they
dynamically register their interest in datagrams with Group
destination addresses.
Internetwork Multicast Routing
An internetwork delivers IP datagrams with Group destination
addresses from active sources to interested receivers. Generally, a
distribution tree is created, rooted at the active source with
leaves at each interested receiver. Each node on this tree is one
of the following: the source, a multicast router, or an interested
receiver. The distribution tree must be loop-free to avoid so-
called "multicast amplifiers." Each multicast router checks the
incoming multicast datagram's source address to verify that the
datagram arrived on the appropriate interface. In general, the
datagram should arrive on the same interface used to forward unicast
datagrams towards the source address of the datagram. This
operation is often referred to as the Reverse Path Forward (RPF)
check.
There are three known general ways to create and maintain this
forwarding tree.
So-called "dense mode" multicast routing protocols forward datagrams
along the largest possible distribution tree, but prune back the
tree as multicast routers register their lack of interest in
specific datagrams. If there are no interested receivers, the
pruning process eventually reaches back to the active source.
So-called "sparse mode" multicast routing protocols take the
opposite approach: interested receivers first register their
interest in receiving datagrams addressed to a particular Group
addressed. The internetwork explicitly builds the distribution tree
towards the active sources.
So-called "tunneling" multicast routing protocols operate when parts
of the internetwork are not capable of participating in a forwarding
tree. Tunnels can form the edges of dense-mode or sparse-mode
distribution trees.
Core Application Operations
Application developers and users have come to expect certain
facilities to be available from an IP Multicast-enabled
internetwork. Often, when a local host or network does not support
native IP multicast services, the application developer and/or end-
user will implement these facilities independent of the network.
Nickless Informational - Expires July 2002 3
Towards A Multicast Service Model February 2002
Host Interface Discovery (GroupInterfaceDiscovery): 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. The IP address returned is used by the application as
the IP source address for any multicast datagrams transmitted.
Multicast Packet Transmission (GroupTransmit): 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 (GroupJoinAny and GroupJoinOnly): An
application notifies the host that it wishes to receive IP datagrams
addressed to a given IP Destination/Group address. The application
executes the GroupJoinAny operation to receive IP datagrams
originated by any source addressed to the Destination/Group address.
(This is often referred to as an "Any Source Multicast" Join.) The
application executes the GroupJoinOnly operation to receive IP
datagrams originated by a certain set of hosts identified by IP
Source Addresses. (This is often referred to as a "Source Specific
Multicast" Join.) The host notifies the network to deliver such
packets, and returns an opaque identifier to the application for
later use.
Multicast Packet Receipt (GroupReceive): An application provides a
memory pointer to the host, along with an opaque identifier provided
by the host in the GroupJoinAny or GroupJoinAll operations. 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). When received, the data is copied
into memory associated with the pointer.
Leave Multicast Group (GroupLeave): 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 (GroupSize): 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.
Nickless Informational - Expires July 2002 4
Towards A Multicast Service Model February 2002
Authenticated Join Multicast Group (SecureGroupJoinAny and
SecureGroupJoinOnly): An application must provide an authentication
token as part of the GroupJoinAny or GroupJoinOnly operation.
Authenticated Transmit To Multicast Group (SecureGroupTransmit): An
application must be "approved" in some way in order for its data to
be received by cooperating receivers.
Security Considerations
Multicast implementations can be 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 to applications that
have not executed a GroupJoinAny or GroupJoinOnly 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.
Steve Deering developed the original IPv4 Multicast Service Model.
Much of the information in this document is derived from his work.
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. Deering.
August 1989.
[ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
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 5
===
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