[AG-TECH] Multicast service model
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Wed Jan 23 01:44:09 CST 2002
In message <Pine.GSO.4.44.0201221611110.19264-100000 at darkwing.uoregon.edu>, "Lu
cy E. Lynch" typed:
>>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
actualy, i follow both...
>>2] those of us in two places at once to cross post (judiciously)
>> when issues of interest arise
ok - so note that the UK GRID is trying to run AG stuff over a net
which consists almost completely of MANs running PIM SM, a core
running PIM SM, connected by MSDP
boy oh boy is it hard to debug.
i wih we had bidir pim and bgmp...:-)
>>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 b=
>>e
>>> about the right time to show people this Internet Draft on the IP multi=
>>cast
>>> 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 simultan=
>>eously:
>>>
>>> - 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 an=
>>d
>>> 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 I=
>>GMP
>>> 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. Nickles=
>>s
>>> Document: draft-nickless-mcast-svc-model-00.txt Argonne Nationa=
>>l
>>> Laborator=
>>y
>>> Expires: July 2002 January 200=
>>2
>>>
>>>
>>> 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 document=
>>s
>>> 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 thi=
>>s
>>> 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 =96 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 Etherne=
>>t
>>> interface to accept frames that match a certain Media Access Contro=
>>l
>>> (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 multicas=
>>t
>>> 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 t=
>>o
>>> deliver such packets, and returns an opaque identifier to the
>>> application for later use.
>>>
>>> Multicast Packet Receipt (RECEIVE): An application provides a memor=
>>y
>>> pointer to the host, along with an opaque identifier provided by th=
>>e
>>> 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 tha=
>>t
>>> 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 i=
>>s
>>> zero, the application might choose not to construct IP datagrams fo=
>>r
>>> 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 requir=
>>e
>>> 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 applicatio=
>>n
>>> 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 th=
>>e
>>> 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 Membershi=
>>p
>>> 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 hos=
>>t
>>> 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 o=
>>f
>>> 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 hos=
>>t
>>> 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 an=
>>d
>>> 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 migh=
>>t
>>> 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 dat=
>>a
>>> 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 th=
>>e
>>> 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 transmi=
>>t
>>> 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, t=
>>o
>>> 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 dat=
>>a
>>> into the TCP channel and transmitting it to the tunnel host. If th=
>>e
>>> 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 hos=
>>t
>>> 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, multipl=
>>e
>>> 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 o=
>>f
>>> various types. Currently supported handlers include the traditiona=
>>l
>>> 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 Protoco=
>>l
>>> 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 Bes=
>>t
>>> 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 Advance=
>>d
>>> 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
>>>
>>> =3D=3D=3D
>>> 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.an=
>>l.gov
>>>
>>
cheers
jon
More information about the ag-tech
mailing list