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@mcs.anl.gov Nickless Informational - Expires July 2002 5