The Java™ Reliable Multicast™Service - CiteSeerX

The Java™ Reliable Multicast™Service:A Reliable Multicast Library

Phil Rosenzweig, Miriam Kadansky, and Steve Hanna

M/S MTV29-01901 San Antonio RoadPalo Alto, CA 94303-4900

The Java™ Reliable Multicast™ Service:A Reliable Multicast Library


SMLI TR-98-68 September 1998

Abstract:

The Java™ Reliable Multicast Service™ (JRMS) is a set of libraries and services for building multicast-aware applications. It enables building applications that distribute data from “senders” to “receivers” over“channels” with distributed control over content mix. It includes a dynamic filtering mechanism that usesJava software that is pushed into the network for interpreting the data of the receiver. JRMS supports mul-tiple reliable multicast transport protocols via a common programming interface, which provides isolation toapplications. Supported transport protocols are selectable by applications based on reliability and type ofservice needs.

Emerging multimedia or “push” applications can use JRMS as a better platform for reliable delivery of con-tent to very large constituencies. As compared to unicast (point-to-point) protocols), reliable multicastenables broadcasting to groups of receivers, ensuring bandwidth conservation and timely delivery. TheJRMS reliable multicast transport protocol (TRAM) is designed for high scalability. JRMS also includesrelated services for multicast address allocation, channel advertisement and subscription, authenticationand encryption, and receiver group management. JRMS is designed to be a flexible toolkit to the applica-tion developer for authoring new types of network-centric multimedia applications.

email address:[email protected]@[email protected]

© 1998 Sun Microsystems, Inc. All rights reserved. The SML Technical Report Series is published by Sun Microsystems Laboratories, of SunMicrosystems, Inc. Printed in U.S.A.

Unlimited copying without fee is permitted provided that the copies are not made nor distributed for direct commercial advantage, and credit to thesource is given. Otherwise, no part of this work covered by copyright hereon may be reproduced in any form or by any means graphic, electronic,or mechanical, including photocopying, recording, taping, or storage in an information retrieval system, without the prior written permission of thecopyright owner.

TRADEMARKSSun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. AllSPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other coun-tries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.

For information regarding the SML Technical Report Series, contact Jeanie Treichel, Editor-in-Chief <[email protected]>.

The Java Reliable Multicast Service:

A Reliable Multicast Library


Sun Microsystems LaboratoriesBoston Center For Networking

Chelmsford, Massachusetts

1 Introduction

1.1 What is IP Multicast?IP Multicast is an internet protocol that enablestransmission of data packets to a group ofreceivers. It is described in RFC 1112[MULTICAST]. Datagrams are sent to a sharedclass D IP address to which all group members(or hosts) are listening. Hosts may attach to thegroup by joining or detach from the group byleaving. These actions associate or disassociatethe host from the class D multicast IP address. Inorder for multicast to work, IP routers need torecognize hosts that have joined the multicastgroup and forward datagrams to each of theirdownstream links that have hosts on themulticast group. The IGMP protocol [IGMP]provides a mechanism for hosts to communicatewith their associated routers to join and leavemulticast groups. See [RTNG] for a completedescription of IP Multicast routing.

1.2 Why IP Multicast?Basic TCP/IP network protocols address theneed for communicating between one sender andone receiver. This type of communication isknown as “unicast” or point-to-point. When aWeb browser is pointed at a Web site, TCP/IPprovides a unicast connection to enablecommunications.

There is an emerging class of applicationsdesigned for collaborative computing, streamingmultimedia, and real-time data delivery. Theserequire multi-point communications between oneor more senders and several receivers in order towork well. In this mode of operation, instead of a

receiver explicitly requesting data from a sender,data is sent from a sender to the receiversasynchronously as needed. IP Multicast isdesigned to solve this problem.

For example, when groups of people share datathat changes often, it may be necessary to notifyeveryone when the data changes. Unless it ispossible to broadcast changes to all groupmembers at the same time, notifying eachmember in turn is inefficient. This would requireindividual point-to-point connections in order formembers to receive updates from other members.Obviously, this won’t scale beyond a handful ofmembers.

1.3 IP Multicast IssuesSeveral challenging issues related to IP Multicasthave emerged. The following subsections dis-cuss these issues.

1.3.1 Multicast Routing ProtocolsDVMRP [DVMRP], Sparse-mode PIM [PIM-SM], Dense-mode PIM [PIM-DM], MOSPF[MOSPF], and CBT [CBT] are the most com-mon multicast routing protocols in use today. Onthe MBone, the Internet's experimental multicastbackbone [MBONE], DVMRP is most widelydeployed. Each of these protocols is designed todeliver packets from senders to receivers on aclass D IP Multicast group address.

Shortest path protocols are designed to find theshortest path through the routing infrastructurebetween each sender and each of its receivers.Shared tree protocols attempt to determine acommon path which is shared by all senders on amulticast group. Each approach requires someamount of network traffic and elapsed time inorder to build the initial routes (or tree) between

the sender(s) and receivers, and optimize for bestpath depending on the approach. If groupmembership is fluid because of frequent orcontinuous joins and leaves, or additional newsenders join the group, or the group membershipis very large, routing instability may result.

For example, because DVMRP is a distancevector protocol, it has shown scalability prob-lems in environments such as the MBone whichcontain large numbers (8000+) of subnets. Thislimitation is one of the key driving forces behindthe transition from DVMRP to a more scalablemulticast routing protocol [BGMP] on theMBone.

1.3.2 Product IssuesAlthough multicast routing protocols arereasonably well-defined, product issues remainin various categories of network equipment.This is because there are very few applicationsexercising the current infrastructure. Theseissues will get resolved as more multicast-awareapplications become deployed. Some exampleproduct issues are:

NICs: Network interface cards (NICs) are thehardware and software devices which connectnetwork nodes to multi-access media networkssuch as ethernet. NICs usually provide a level ofsupport in hardware for receiving packets on thenode’s IP address, broadcast address, andmulticast address(es). Multicast address supportcan vary from none to some upward limit. Forexample, SBUS cards for Sun workstations andservers typically support up to 20 multicastaddresses. Beyond this limit requires filteringincoming packets by address in software, whichis expensive from a performance perspective.

Switches: LAN switches sometimes treatmulticast packets in the same manner asbroadcast packets, which results in flooding allports. This is usually considered a bug.

Routers: Significant bugs exist in many of themulticast routing implementations. In particular,experience with DVMRP on the MBoneindicates some unpredictability and instability inits operation, causing some network managers tobe reluctant to enable multicast routing in theirown networks.

TCP/IP Stacks: Most current TCP/IP stackssupport multicast. The key capability is supportfor IGMP, which is the protocol used for joining

and leaving multicast groups. Older implemen-tations often do not support IGMP.

1.3.3 ScalabilityRouter Tables: As multicast is increasinglydeployed, more router table space will beconsumed. Internal data structures that occupyrouter memory are created to indicate where toforward multicast packets. Routers on the treefor a particular multicast group must record statefor that multicast group. In addition, dependingon the multicast routing protocol used, a routermay keep state for multicast groups even if it isnot involved in transmitting data for the group.For backbone routers, if a large number ofconcurrent multicast groups are in use, there isthe potential for exhaustion of table memoryspace or available processor bandwidth, whichcan limit scalability. The MBone routers on theInternet best illustrate this condition.

Congestion Control: The lack of congestioncontrol mechanisms in multicast transports cancause inefficiencies in the bandwidth utilizationof the network. This is especially dangeroussince a single multicast group can affect largeportions of a network. Other traffic, such as well-behaved TCP sessions, may be endangered bypoorly behaved multicast flows.

1.3.4 Address AllocationIP Multicast [IP] identifies a set of IP Multicastaddresses (224.0.0.0 to 239.255.255.255) that areused to identify a group of recipients (a multicastgroup). An IP packet sent to one of theseaddresses is delivered to all members of themulticast group. These groups may span severalIP networks.

Certain multicast addresses, 224.0.0.0 to224.255.255.255, are reserved by the InternetAssigned Numbers Authority (IANA1) forspecial purposes. Other addresses, known asadministratively-scoped addresses [ADMIN](239.0.0.0 to 239.255.255.255), are reserved foruse within a predefined administrative scope,such as site-local or organization-local. The rest,known as globally-scoped addresses, operatewith a global scope.

At the moment, there are several techniques forallocating multicast addresses, but they all haveserious disadvantages and they are not always

1 See http://www.iana.org

used. This can lead to collisions where twomulticast groups are established independentlywith the same multicast address assigned to both,possibly causing data intended for one group tobe received by members of another group. Theideal address allocation scheme should scale upto the size of the Internet and guarantee uniqueaddresses across all networks for a particularsession. Although IPv4 allows 228 multicastaddresses, reuse is required in order not to runout of addresses over time.

1.3.5 Session DirectoriesCurrently, end-users find out about multicastsessions by consulting a session directory [SDR].Directory entries are multicast over a well-known multicast address using the SessionAnnouncement Protocol [SAP] and the SessionDescription Protocol [SDP]. Information associ-ated with particular multicast sessions, such asgroup address, start time or public key, may bemade available by the session directory. Thesedirectories that are responsible for advertisementof available multicast sessions must scale orotherwise become an inhibitor to multicastdeployment. Unless this information is highlyavailable, potential receivers for individualmulticast sessions may not receive timelynotification in which case they would not be ableto participate. Handley [SCALE] describes thescalability considerations with sessiondirectories.

1.3.6 TTL ScopingAnother issue is scoping of multicast groups. Itis often useful to contain transmission ofmulticast traffic to a subset of a network. TheTime To Live (TTL) field in the header of IPpackets is commonly used to limit the number ofrouter hops a packet is to be forwarded. Thisfield is decremented each time a packet isforwarded by a router. At zero, the packet isdiscarded. If the TTL is too small, packets maynot reach every desired part of the network. Ifthe TTL is too large, multicast packets may beforwarded farther than required. In general, theTTL should be large enough to reach allmembers of a multicast group.

Several reliable multicast transport protocolsadjust the TTL field of repair packets to limittheir scope. However, using TTL to containretransmission of packets to a subset of amulticast group does not necessarily confine thedata to the targeted receivers.

1.3.7 SecurityIn a multicast environment, any node can join amulticast group, then send or receive packets.This is a major concern for applications thatrequire security, either to keep data from beingseen by unauthorized observers, to ensure thatdata is sent only by authorized senders, or just toprevent denial-of-service attacks caused bysenders flooding the group with data.

For unicast applications, data can be keptconfidential and senders can be authenticatedusing various encryption and signaturetechniques. While these techniques can also beused for multicast data, it is more difficult todistribute keying information in a multicastenvironment. Key distribution and revocationalgorithms are complex as they need to consideran arbitrary number of senders and receivers, notjust two.

1.4 Reliable Multicast

1.4.1 IntroductionBasic IP Multicast is unreliable. This does notmean that it fails often! It means that if any datais lost during transmission, there is nomechanism for repairing this loss. For video, thisjust causes a momentary glitch. For some otherdata (like a spreadsheet), it renders the datauseless.

Reliable multicast adds a way to repair lost ordamaged multicast data. When a receiver missesone or more data packets, it needs these packetsto be retransmitted. This sounds easy, but it’s not.In fact, it is an area of active research, with newideas and protocols coming out all the time. Thechallenges of supporting reliable multicastinclude:

• Performing repairs for those receivers thatneed them

• Not overloading the sender with messagesfrom receivers

• Managing receivers with different abilities(loss rate, bandwidth, latency, etc.)

• Congestion detection, avoidance and control• Insuring scalability to large receiver groups• Maximizing throughput• Handling different types of applications• Providing data security

1.4.2 JRM Service ObjectivesOne of the basic assumptions of the JRM Serviceis that the problem of applying reliability tomulticast is best addressed as an end-to-endproblem. This means that it is best done fromone end system to another, rather than within therouting infrastructure. The need to save state forthe purpose of repairing packets on a per packet /per group basis puts an inordinate resource loadon routing nodes which typically have limitedmemory and processor resources. Packet repairrequires establishing packet caches at appropriatepoints throughout the network. Scalabilityrequirements require these caches to be withinreasonable proximity of the receivers. Sincerouters are best-effort packet forwarders and willdrop packets if resources become exhausted,higher level protocols must deal with lost packetdetection and retransmission when necessary.This would suggest that reliable multicast is bestdone in higher level protocols and in deviceswhich have sufficient computing resources toprovide adequate services.

As seen in the next section, there are a variety oftypes of applications for reliable multicast. Eachof these imposes different requirements on thenetwork. This implies a corresponding variety ofreliable multicast protocols in order to addressthe needs of applications. For example, anapplication which transfers bulk data or largefiles from one sender to many receivers (such assoftware distribution), is very different from acollaborative application, which has multiplesenders and receivers (such as sharing a virtualwhiteboard). The JRM Service addresses theneeds of different application types by providinga framework for including multiple reliablemulticast protocols. These protocols areaccessible by applications via a common API.Since these protocols are implemented end-to-end, it is straightforward to provide them as theybecome available and define interfaces for othersto plug into. It would be much harder toimplement and deploy this mix of protocols inrouter devices — not only because of the reasonspreviously discussed, but also because routersare homogeneous devices which are notextensible by others. Router code bases comefrom a single vendor and tend to be released andinstalled by customers on long time cycles in aconservative manner. This slow-moving releasemethodology is analogous to operating systemsrelease, except that operating systems allowusers to add drivers and other extensions toprovide new functions, within reasonably well-

defined bounds. So, again, this argues that endsystems are better than routers for timelydeployment of reliable multicast protocoltechnology.

The objectives for the JRM Service are:

• Provide a platform for building multicast-aware applications organized as a set oflibraries and services implemented on endstations

• Provide applications with access to multiplereliable multicast protocols through acommon API which isolates applicationsfrom protocol changes, yet allows selectingappropriate protocols based on applicationneed

• Design a highly scalable bulk data transferprotocol for large numbers of receiverswhich includes support for congestiondetection, avoidance, and control

• Provide services for multicast addressallocation, security (authentication andencryption), and administrative policycontrol

• Flexibility• Implement in Java software for multi-

platform support• Handle simple or complex applications

with scalable overhead for supportingservices

• Add new reliable multicast protocolswith minimal impact to applications

• Provide a mechanism for applyingadministrative policy to data at thereceivers (dynamic filters)

2 Reliable MulticastApplications

There are several distinct types of multicast-aware applications. These are characterized byfactors relating to such things as how theapplication behaves, characteristics of the datatransmitted, demand placed on the network,connectivity characteristics such as stationary ormobile, and available bandwidth. This sectiondescribes multicast-aware application types andcorresponding requirements that characterizethem.

2.1 Application CharacteristicsThe requirements listed below are the keyrequirements of multicast-aware applications for

the reliable multicast protocols used to supportthem. These substantially affect the nature anddesign of the reliable multicast protocols used toaddress the applications. These requirements are:

Number of Senders: Protocols that allow morethan one sender (known as “many senders”) aresubstantially more complicated than those thatallow only one sender (known as “singlesender”), as they have no centralized point ofcontrol.

Late Joins: Different applications have differentrequirements for receiver readiness. Receiversthat join the group after some data has been sentare known as late joins. If all receivers musthave a single start time, protocol design issimplified considerably; late joins are notallowed. If receivers may start at any time andmust receive copies of all data sent, a good dealof effort must go into preserving all data. This isknown as late join with full data recovery. Ifreceivers may start at any time but do not receivecopies of all data sent earlier, less effort isrequired. This is known as late join with limiteddata recovery.

Real-time Performance: Some applicationsrequire that data be delivered within a certainperiod of time. Others simply require that it bedelivered eventually.

Consistency: Requirements in this area differwidely. Some applications require that all data bedelivered to all receivers at exactly the same time(such as stock price delivery). Others requiresimply that all receivers eventually get the data.Some provide application-level checkpoints atwhich consistency must be guaranteed.

Ordering: Most applications require data to bedelivered in order, but some (such as news feeds)do not.

Reliability: Most applications require fullreliability, but some (such as streaming video)can trade off a certain amount of data loss inorder to achieve high throughput and timelydelivery.

2.2 Types of Reliable MulticastApplications

2.2.1 Bulk DataBulk data applications are concerned withtransferring files or other large blocks of data.Examples include distribution of corporate data,updating software, loading Web caches, orupdating data warehouses. Such applicationstypically require: one sender per channel, no latejoins, no real-time requirement, file levelconsistency, ordering, and full reliability.

2.2.2 Live DataLive data applications are concerned withdistributing an ongoing flow of small pieces ofdata. Examples include stock price distribution,news feeds, and event logging. Such applicationstypically require: one sender per channel, no starttime (late joins with limited data recovery),varied real-time requirements (strict for stockprices, loose for some others), varying levels ofconsistency (extremely strict for stock prices,loose for most others), varying levels of ordering(strict for stock prices, none for news feeds), andvarying levels of reliability (strict for stockprices, none for event logging).

2.2.3 Resilient StreamsResilient streams applications (also known assemi-reliable applications) are concerned withdistributing a stream of real-time multimediadata that can handle some losses. Examplesinclude video or audio feeds. While suchapplications may use unreliable multicast,reliable multicast can provide limited data repairand (more important) congestion control. Suchapplications typically require: one sender perchannel, various start times, moderate real-timerequirements, no consistency requirements, noordering requirements, and loose reliabilityrequirements.

2.2.4 CollaborativeCollaborative applications are concerned withsharing data within a group. Examples include ashared whiteboard, collaborative editing, orcontrolling a multimedia conference. Suchapplications typically require: many senders perchannel, late join with full data recovery,moderate real-time requirements, variousconsistency requirements, various orderingrequirements, and full reliability.

2.2.5 HybridHybrid applications are some combination of theabove. Examples include Distributed InteractiveSimulation (DIS) and other shared virtual realityenvironments. These applications often havemany different requirements for different datastreams or at different times. Some of them maybe implemented as a combination of the aboveapplication types. Others may have specialrequirements that require special solutions (suchas rapid joining and leaving of channels).

2.3 Suitability of the JRM Servicefor Various Applications

The JRM Service is designed to support many ofthe application types listed above. As can beseen, the architecture of the JRM Serviceaccommodates multiple reliable multicastprotocol implementa-tions. This enables the JRMService to address varying and perhapsconflicting requirements of multicast-awareapplications. The JRM Service includes atransport protocol (Tree-based Reliable MulticastProtocol) [TRAM] that satisfies many of theneeds of applications such as bulk data.Conversely, collaborative applications such as ashared whiteboard require a protocol thatsupports many senders. The JRM Serviceincludes one such protocol, Lightweight ReliableMulticast Protocol [LRMP], and a simple chatapplication that supports multiple senders. In allcases, applications use a common APIirrespective of the reliable multicast protocol inuse.

The TRAM protocol is most useful with bulkdata applications. These are typically single-sender applications with many receivers. TRAMsupports ordering and reliability. Moderate real-time requirements are addressed in TRAM with

support for maintaining minimum (andmaximum) data rates. This is a best effortmechanism to sustain throughput within a rangeof transmission speeds. More details of theTRAM protocol can be found in section 4.

3 The JRM ServiceArchitecture

3.1 Abstract ModelThe abstract model for the JRM Service is thatone or more senders transmit data on a givenchannel and one or more receivers receive thisdata. In Figure 1, A is a sender on channel E; B,C, and D are receivers. It is possible to havemany senders and for a single node to be both asender and a receiver.

A channel is a multicast transport session thatconveys data from one or more senders tomultiple receivers. This is conceptually similarto an IP Multicast group, but reliable delivery,security, and other features may be added on.

Each channel has one or more channel managersthat are responsible for creating and destroyingthe channel, configuring it, and managingchannel membership (that is, controlling whocan send and receive on it). In Figure 1, M is thechannel manager.

These are the basic components in the JRMService abstract model: channels, senders, re-ceivers, and channel managers.

3.2 SystemsFigure 2 illustrates the major systems that makeup the JRM Service .

Figure 1: JRM Service Abstract Model

A

C

B

D

Channel E

M

3.2.1 TransportThe transport system is responsible for providinga reliable multicast transport. It may be useddirectly by the application or indirectly throughthe channel management system. The transportsystem is composed of two parts, a set ofprotocol-independent transport APIs and one ormore transport protocols.

3.2.1.1 Transport APIsMany different reliable multicast transportprotocols have been developed and many moreare on the way. Currently, application vendorsthat want to use reliable multicast must developcode specifically to support one protocol. Ifanother protocol comes out that meets theirneeds better, they must reintegrate their code.The JRM Service provides a interface that allowsapplication vendors to write their code once andhave it work with any reliable multicast protocol.

The JRM Service is provided with threeprotocols implemented: Tree-Based ReliableMulticast [TRAM], Lightweight ReliableMulticast [LRMP], and an unreliable multicasttransport. Other protocols can easily be addedusing stream or packet interfaces.

3.2.1.2 The JRM Service TransportProtocol

The JRM Service Transport Protocol [TRAM] isa reliable multicast protocol designed to supportbulk data transfer with a single sender andmultiple receivers. TRAM uses dynamic trees toimplement local error recovery that scales to avery large number of receivers without imposinga serious burden on the sender. It also includescongestion control and other techniquesnecessary to operate efficiently and fairly withother protocols across the wide variety of linkand client characteristics that make up theInternet.

Figure 2: The JRM Service

3.2.2 Channel ManagementThe channel management system is responsiblefor creating, configuring, and destroyingchannels upon request. It handles end-to-endmanagement of the multicast session, includingsession advertisement, discovery and joining,receiver authentication, event notification anddistribution of dynamic filters. Operations at thechannel layer are generic to the transportprotocol in use.

A channel may be configured with one or moredynamic filters. A dynamic filter is a piece ofJava software that runs on a receiver, which maybe an end-station or intermediate node, andprocesses the data received on a channel,transforming it in some way. For instance, adynamic filter can block access to entertainmentchannels during working hours. It can alsohighlight stories that match a user’s interestprofile.

Dynamic filters are delivered to receivers whenthey register for a channel. Different receiversmay receive different filters, based on accesscontrol or preferences.

3.2.3 Address AllocationThe address allocation system is responsible formanaging multicast address allocation. It may beused directly by the application or indirectlythrough the channel management system.

One of the first steps in establishing a newchannel is choosing a multicast address. Becausemulticast addresses are shared across multiplenetworks, this is a tricky problem. Severaltechniques are in use today, but no one techniqueaddresses every issue. The address allocationsystem provides a standard API that may be usedto allocate and deallocate addresses. Differentaddress allocators may be installed to implementdifferent allocation techniques.

3.2.4 SAP SupportThe SAP Support system provides animplementation of the Session AnnouncementProtocol [SAP] and Session Description Protocol[SDP]. These protocols are useful both forallocating multicast addresses and for advertisingmulticast sessions. The SAP Support classes areused by both the Address Allocation andChannel Management systems.

3.2.5 SecuritySecurity solutions for reliable multicast are muchmore complex than those for unicast[SECURITY]. The JRM Service supports threeaspects of security:

• data confidentiality• data integrity and message

authentication• sender and receiver authentication

and access control

Data confidentiality is achieved by encryptingdata sent on the channel. Data integrity isachieved by including a message digest. In orderto support a wide variety of implementations ofdata confidentiality and integrity, the JRMService provides generic interfaces for confiden-tiality and authentication. Confidentiality isprovided by a layer just above the transport;message and sender authentication is supportedwithin the transport layer. The JRM Serviceprovides implementations of several solutionsusing these open interfaces. New implementa-tions can be plugged into the system via thesupported open interfaces.

User authentication, access control, and keydistribution are implemented as part of channelmanagement. Senders and receivers identifythemselves to the channel manager, and, afterauthentication, securely receive appropriatekeying information. For instance, receivers aresent decryption and signature verification keys,while senders obtain encryption and signingkeys.

4 TRAM

4.1 OverviewTRAM is designed to support bulk data transferwith a single sender and multiple receivers. Ituses dynamic trees to implement local errorrecovery and to scale to a large number ofreceivers without impacting the sender. It alsoincludes flow control, congestion control, andother adaptive techniques necessary to operateefficiently and fairly with other protocols acrossthe wide variety of link and client characteristicsthat make up the Internet as well as intranets.

TRAM ensures reliability by using a selectiveacknowledgement mechanism, and scalability by

adopting a hierarchical tree-based repairmechanism. The hierarchical tree not onlyovercomes implosion-related problems but alsoenables localized multicast repairs and efficientlyfunnels feedback to the sender.

The receivers and the data source of a multicastsession in TRAM interact with each other todynamically form repair groups. These repairgroups are linked together in a hierarchicalmanner to form a tree with the sender at the rootof the tree. Figure 3 shows a typical TRAMrepair tree. These types of trees have beenshown to be the most scalable way of supportingreliable multicast transmissions [SURVEY].Every repair group has a receiver that functionsas a group head; the rest function as groupmembers. These members are said to beaffiliated with their head. Except for the sender,every repair group head in the system is amember of some other repair group. Allmembers receive data multicast by the sender.The group members report lost and successfullyreceived messages to the group head using aselective acknowledgement mechanism similar

to TCP’s [SACK]. The repair heads cache everymessage sent by the sender and provide repairservice for messages that are reported as lost bythe members. The dynamic nature of the treeallows it to react to changes in the underlyingnetwork infrastructure without sacrificingreliability.

The TRAM tree formation algorithm works inboth bi-directional multicast environments anduni-directional multicast environments (such assatellite links). Repair nodes are elected basedon a wide spectrum of criteria, and the tree iscontinuously optimized based on the receiverpopulation and network topology. Theacknowledgement-reporting mechanism iswindow-based with optimizations to reduceburstiness and processing overhead. The flowcontrol mechanism is rate-based and adapts tonetwork congestion. The sender senses andadjusts to the rate at which the receivers canaccept the data. Receivers that cannot keep upwith the minimum data rate can be dropped fromthe repair tree.

Figure 3: Typical Hierarchical Repair Tree in TRAM

Some of the major features of TRAM are:

Reliability: TRAM guarantees delivery of datato any receiver that joins the tree and is able tokeep up with the minimum transmission speedspecified by the sender. While this level ofguarantee cannot protect applications fromdelivery failure, features of the JRM Service canbe used to closely keep track of individualmember’s status.

Avoiding Acknowledgement Implosion: Point-to-point transports achieve reliability byacknowledging receipt of data directly to thesender. Unfortunately, this does not scale overmulticast. A sender trying to fieldacknowledgements from many receivers willquickly become overloaded. TRAM avoids thisimplosion by dynamically designating a receiverto be a repair head for a group of members. Therepair head fields acknowledgements from eachof its group members and supplies them withrepair packets. To avoid overload, each repairhead is responsible for only a limited number ofmembers.

Local Repair: TRAM builds the tree so thatrepair heads are close to their members. Thisenables repair heads to perform repairs usingsmall time-to-live (TTL) values, which not onlyminimizes network bandwidth consumption butalso avoids unnecessary processing at receiversnot requiring repair.

Automatic Configuration: Different applica-tions, networks, or user groups may performbetter using different types of trees. TRAMprovides for building different types of treesoptimized for these different circumstanceswithout adding complexity to the networkinfrastructure itself. As a receiver groupchanges, TRAM also provides for ongoingoptimization of an existing tree, for instance,enabling a member to find a better repair head.A particular tree’s formation method may also bechanged at any time during the transmission atthe discretion of the sender. TRAM’s treemanagement works in networks providing onlyunidirectional multicast, as well as thosesupporting bi-directional multicast.

Rate-based Flow Control and CongestionAvoidance: TRAM schedules packet trans-mission according to a data rate. This data rate isdynamically adjusted based on congestionfeedback from the receivers. Congestion feed-

back is aggregated by repair heads through thetree. The algorithm used to adjust the rate worksin different network topologies. The rate isbounded by a maximum and minimum rateconfigured at the sender.

Feedback to the Sender: Each member of thetree periodically reports statistics to its repairhead. This includes statistics that assist inbuilding the tree (for instance, the number ofavailable repair heads on the tree) as well asreports on congestion conditions, which allowthe sender to adapt its data rate to networkconditions. This information is aggregated ateach level of the tree in order to reduce controltraffic to the sender.

Controlling Memory Use: Each repair head isresponsible for ensuring that the data is receivedby every member. This means that a repair headmust cache data until it is sure that all of itsmembers have received it. TRAM requirespositive acknowledgements from members whendata is received. This enables repair heads toreclaim cache buffers containing data that hasbeen received by all members.

Repair Group Management: Both membersand repair heads monitor each other to detectunreachability. Non-responsive members can bedropped from the repair group and correspondingcache buffers can be reclaimed. Non-responsiverepair heads can be abandoned by their membersin favor of an active repair head. Repair headsare also responsible for detecting receivers whichcannot keep up with the minimum transmissionrate specified by the sender. While suchmembers cannot be dropped from the multicastgroup, they can be denied repair head supportand receive no repairs.

Scalability: TRAM has been designed to bescalable in many situations, such as largenumbers of receivers and sparsely or denselypopulated receiver groups. TRAM alsoaccommodates wide ranges of receivercapabilities. Control message traffic is designedto be limited in all of these cases.

4.2 Data TransmissionThe TRAM sender transmits data at a rate thatadjusts automatically between a specifiedminimum and maximum. Sequence numbers inthe data packets allow receivers to identify

missing packets. Each member is bound to arepair head that retransmits lost packets whenrequested. Acknowledgements sent by receiverscontain a bitmap indicating received and missingpackets. Missing packets are repaired by therepair head; packets received by all members areremoved from the repair head’s cache.

4.3 LimitationsRealistic TTL Values: Tree formation inTRAM relies on TTLs. Current multicastrouting protocols may not provide accurate TTLvalues for this purpose.

Heterogeneous Receiver Population: AlthoughTRAM adjusts itself to the capabilities of thereceivers as much as possible, a particular slowreceiver may end up without repair service if itcannot keep up with the minimum speedspecified by the sender according toadministrative policy.

5 Channel ManagementThe JRM Service provides an abstraction layerknown as a “channel” for applications to deliverdata to multiple receivers. In the protocol stack,it is layered above the transport. This allowschannel to provide a common set of functions toapplications irrespective of which transportprotocols are in use. For example, one ofchannel’s functions is authentication ofreceivers. This would be available to collabo-rative applications using a many-to-manytransport protocol, such as LRMP, and to newsdistribution applications using a one-to-manytransport protocol, such as TRAM. The choice oftransport protocol can differ without affectingthe functions provided by the channel layer.

Channels provide the following functions:

• Channel discovery• Channel registration and authentication of

channel users• Event notification• Application of policy through dynamic

filtering• Access to security services

A key motivation behind providing the channellayer comes from the requirements ofapplications moving from unicast to multicast. Inunicast, there is a point-to-point connection

between a single pair of nodes in a network. If abanking application distributes updated currencyinformation to each of its remote offices over anetwork at the end of each day, it can make aunicast connection to each office in turn, transferthe data and log the fact that it did so. Inmulticast, senders and receivers can beanonymous to each other, given the way nodesjoin and leave multicast groups. If one were toimprove the banking application by moving it tomulticast, how would it be able to log that ittransferred data to each of the remote offices?One way would be for each of the remote officesto tell the sender by establishing a unicastconnection with the sender when transmission iscomplete. This, of course, would somewhatdefeat the purpose of using multicast. A betterway would be to provide the ability for receiversto be identified and remembered as part of theinitialization process of the session so that thesender would know each of the receivers and beable to log the information. This somewhatrecreates, for reliable multicast, the implicitknowledge that a pair of nodes has of eachother’s identities in a unicast environment.Channel has discovery and registration functionsto provide this capability for applications.

5.1 Channel Discovery,Registration andAuthentication

A useful way to think about the concept of achannel is to visualize it as a shared medium towhich all users of the channel are attached. Datasent on a channel is visible to all that havesubscribed to it. Users (applications running onnetwork nodes) can be senders, receivers or both.The channel itself is an entity that has associatedcharacteristics. Applications discover theexistence of channels, then find out thecharacteristics of the channels in order to usethem. An application can create a channel, use itfor the duration of the application session andthen destroy it. Channels can also persistindefinitely and be reused by more than oneapplication.

5.1.1 DiscoveryPotential users of a channel can discover it inseveral ways: by listening for sessionannouncements, by querying a channel manageror by static configuration. Using a well-knownmulticast address, sessions can be advertised viathe Session Announcement Protocol [SAP].

Session announcements contain informationnecessary for an application to become a user ofthe channel. This information is packaged into astructure called a channel profile. Sinceapplications in a multicast environment aredistributed, this mechanism provides forsynchronization of users. This is often useful forbulk data transfer applications that require allreceivers to be ready and waiting prior to startingdata transmission. Among other things, channeladvertisements contain a channel name and amulticast address and port for the session. Theymay also contain session start time information,security information, and other optional fields.The JRM Service uses the Session DescriptionProtocol [SDP] to format session advertisementmessages. The use of SAP and SDP allowsleveraging existing mechanisms used on theMBone for announcing multicast sessions.

Another way to discover channels is for apotential channel user to contact a channelmanager. Channel managers are processes in thenetwork that provide functions for maintainingchannels. Session details are cached by channelmanagers and are subsequently available torequestors once properly authenticated. Apotential user of a channel could query a channelmanager for information about a channel whosechannel name is known. The channel managerthen provides the information necessary for theapplication to attach to and become a user of thechannel.

Finally, channel information can be staticallyconfigured within applications themselves. Thiswould alleviate the need for SAP announcementsor channel manager queries but it is the leastflexible. However, it may be appropriate forcertain applications.

5.1.2 Registration and Authenticationof Users

Once a potential user of a channel discovers thechannel and its information, the next step isregistration. To do this, it makes a registrationcall to a channel manager. The channel managerperforms authentication to be sure the user hasappropriate permissions to access the channel,records the event that this user has attached and,if configured, downloads any dynamic filters tothe user application which may be necessary foradministrative control over the channel dataitself (see section 5.3). The channel managermay also send security information, such asencryption and authentication keys, to the

registered receiver (see section 7). Registrationmay also trigger events for which others can bewaiting. For instance, the registration mechanismallows senders to wait for all receivers, or certainreceivers, to register before transmitting data.

During the session, it may be required thatreceivers re-register. Re-registration causes usersto contact their channel manager using the sameregistration calls performed the first time. Thisprovides a way to apply new or changedconfiguration data during a session. For example,one way to change data encryption keys during asession is to require each receiver to periodicallyre-register and securely download new keys.

5.2 Event NotificationChannel provides interfaces that may be used toinform applications of various events. Forinstance, events are available to enable anapplication to monitor a particular user; theapplication can be informed when the userregisters for a session, or when it completesreception of some data. Events can also be usedto monitor the session as a whole, for instance,keeping track of how many users are registeredat any particular time.

5.3 Dynamic FiltersDynamic filters are designed to provide theflexibility to apply administrative control overthe content of a channel. One or more dynamicfilters may be installed on a receiver during theprocess of registering for a channel. Dynamicfilters are pre-configured Java software classeswhich are associated with one or more receivers.Typically, they are downloaded to receivers froma service running on a server in the network.This service can be co-located with the channelmanager or not but must be accessible by thechannel manager for retrieving dynamic filters atregistration time. The JRM Service storesdynamic filters in a database. Caching dynamicfilters or otherwise making them persistent at thereceiver is a possible enhancement.

Once dynamic filters are installed, they haveaccess to data packets received from the networkbut not yet presented to the application. In thecurrent implementation, dynamic filters arecalled on a per-packet basis which allow them tofilter, transform or augment the data and returnthe result. Multiple dynamic filters may be

installed at a receiver in which case each iscalled in turn to process the received datapackets. When the last dynamic filter completes,the data is presented to the application.

Some dynamic filter operations may requirecaching packets until a logical block of data ispresent in receiver memory. If, for example, adynamic filter is performing languagetranslation, it may require more than one packetat a time. Other examples may includeencryption/decryption operations, forward errorcorrection or distributed guaranteed deliveryalgorithms for time-sensitive data.

Application designers may choose to usedynamic filters as a way for end-users tocustomize preferences for their data.Additionally, network management personnelmay apply centralized control for groups of end-users using dynamic filters to limit access tocertain content based on local policies. Thedynamic filtering feature is designed to be aflexible mechanism for accommodating manydiverse requirements of multicast-awareapplications.

6 Address AllocationAllocating and managing multicast IP addressesis a tricky problem. Unlike a unicast IP address,data sent to a multicast address may be sent toreceivers on many different networks. In fact, theset of receivers may change over time. If twosenders use the same multicast addressaccidentally, the data they send may be mingled,causing application confusion. Therefore, it isimportant to manage multicast addressescarefully so that this doesn’t happen.

Several multicast address allocation techniquesare currently in use. Administratively scopedmulticast addresses are often allocated withmanual systems such as a list maintained by anetwork administrator. Non-administrativelyscoped addresses are allocated via multicastadvertising with the Session AnnouncementProtocol (SAP). This allows for global dynamicallocation, but it will only scale to about 10,000addresses [HANDLEY].

The Multicast Address Allocation WorkingGroup of the IETF is working on solutions thatwill scale to millions of addresses. Their currentarchitecture calls for a three-tiered model withinterdomain allocation handled by MASC[MASC], intradomain allocation handled byAAP [AAP], and a host request protocol namedMDHCP [MDHCP]. The JRM Service team isplaying an active role in development of the newIETF protocols, and implementations of theseprotocols are being considered.

The JRM Service addresses the multicast addressallocation problem in three ways. First, itprovides a standard API that may be used torequest and manage addresses. This insulatesapplication vendors from any changes in addressallocation techniques. Second, it providessupport for allocating addresses from apredefined pool of administratively scopedaddresses, set aside exclusively for the use of asingle JRM Service channel manager. Third, itprovides an implementation of SAP allocation.

The multicast address allocation APIs providedby the JRM Service are the Multicast AddressManagement API (MAMAPI), whichapplications use to allocate multicast addresses,and the Multicast Address Management ServiceProvider Interface (MAMSPI), which allows anymulticast address allocator to be plugged in.

7 SecurityThe JRM Service security interfaces supportboth data confidentiality and data integrity.These interfaces expand on existing unicastsecurity methods, enabling their use withmulticast. Keys are managed by security servers(see section 7.5), which create, distribute, andupdate keys used by the channel. Senders andreceivers use an encryption layer above thetransport for confidentiality, and authenticationservices at the transport layer for message andsender authentication. Although the JRMService provides a number of security methods,not all may be available for export. Figure 4shows an overview of JRM Service security.

Figure 4: JRM Service Security Architecture

7.1 Data ConfidentialityData confidentiality ensures that channel datacan only be viewed by subscribers of thechannel. At channel registration time, eachregistered sender or receiver is given the currenttext encryption keys. These are usually secretkeys shared by the entire multicast group.Senders use these keys to encrypt data, andreceivers use them to decrypt data.

7.2 Data IntegrityData integrity guarantees the receiver that amessage was not modified in transit. To do this,the sender computes a digest of the message,encrypts the computed digest and includes theencrypted value in the message that is to be sent.Receivers compute the digest of the message andcompare the computed digest against thedecrypted digest extracted from the received

message. Messages that fail the comparison testare considered altered in transit and arediscarded. At channel registration time, eachregistered receiver is given keys to verify digestsfrom each authorized sender. The channel mayrequire a separate key for each sender, or it mayallow all of the senders to use the same key.

These keys can be the public key of each sender,or a new public key generated for the channel’suse. Senders use their private key to generate asignature of the data, and receivers use thecorresponding public key to verify the signature.

Alternatively, shared secret keys may be used,either a separate one for each sender, or one keyused by all senders. In this case, the same key isused to both encrypt and decrypt. However,public/private key pairs are often used, since, asdescribed in the next section, they also providesender authentication.

7.3 Sender AuthenticationSender authentication guarantees the receiverthat a message came from the indicated sender.Usually a public/private key pair is used. Atchannel registration time, each registeredreceiver is given the public key of eachauthorized sender. The channel may require aseparate key pair for each sender, or it may allowall of the senders to use the same key pair.These keys can be the public key of each sender,or a new public key generated for the channel’suse. Senders use the private key to generate asignature of the data, and receivers use thecorresponding public key to verify the signature.In practice, such signature generation can take aconsiderable amount of processing, so, instead ofsigning the entire message, the sender firstgenerates a digest of the message (a muchquicker operation), then encrypts the digest.Receivers decrypt the digest, then validate thedigest by regenerating it from the data.

7.4 RekeyingThe authentication and encryption mechanismsdescribed above are very similar to those in usefor unicast connections. The main issue for thesemechanisms in a multicast environment isrekeying. If a unicast session suspects that a keyhas been compromised, it is not difficult for thetwo parties to confidentially generate a new key.In a multicast environment, it is not so easy. Inaddition, a multicast application may haveseveral additional reasons to redistribute keyinginformation. For instance, the application maybe paid for on a daily basis, requiring that anyencryption keys be changed on a daily basis. Or,an application may require that a new membernot be able to see any data sent before it joined.In this case, since the new member may requestthat old data be repaired, the encryption key mustbe changed any time a new member joins thegroup.

If the group has a small number of members,each one could be made to re-register and thenreceive new keying information, as if it had justjoined the group. However, this may not scalewell enough to larger groups, and could takesome time. Another option is to use one ofseveral innovative proposed algorithms[KEYING] that allow key managers to multicastinformation to the receivers that allows them torecalculate new keys. This information iscleverly encrypted to prevent excluded users

from decrypting it. JRM Service applicationsusing these types of algorithms can use thechannel to reliably send out the rekeyinginformation.

Other algorithms may be used for data confiden-tiality and integrity; the JRM Service interfacesmake the actual method used transparent to theJRM Service code itself. The implementor needonly conform to general interfaces for encryp-tion/decryption, signature generation/verifica-tion, and key management.

7.5 Security ServersSecurity servers are used by channel managers toproduce and distribute keys. Standard Java APIsaccommodate implementations supporting mostsecurity strategies. Security servers withinchannel managers support distribution of keys tonew users, as well as rekeying.

7.6 Authentication ServicesThe JRM Service provides authenticationservices solely within the transport layer. Forreliable multicast, it is essential that authenti-cation be done in the transport itself to avoidfeeding invalid packets to the upper layers. Byintegrating authentication into the transport, thetransport’s reliability features can be used torecover the legitimate version of an alteredpacket. If an altered packet is accepted andpassed to an upper layer for authentication, thereis no possibility of replacing it with a legitimateone.

8 ConclusionsThis paper describes the architecture and majorfeatures of a reliable multicast system designedto support the needs of new types of informationdelivery applications. We believe that amulticast-based system is inherently better thanan HTTP-based system for pushing event-baseddata over a computer network. The results showbetter scalability through more efficientbandwidth utilization of the network and timelydelivery of the data. When reliability is applied,this technology enables dissemination ofmission-critical business data that expands theuse of multicast beyond audio and videoapplications.

The JRM Service can be thought of asinteresting “middleware”. Since the JRM Serviceapproaches the problem of adding reliability tomulticast as an end-to-end problem, it layerssoftware between the IP stack of the end-systemand the application. The design center of theJRM Service is to isolate the application as muchas possible from the details of the networkthrough a cleanly layered set of APIs.Alternative approaches require that applicationsbe intertwined with the network software. Thismakes them more difficult to write, given all ofthe considerations about the network that mustbe taken into account. However, suchintertwined solutions have the potential to bemore intelligent about such things as repairinglost data in collaborative applications, forexample.

The JRM Service uses IP multicast. This raisestwo major problems. The first concerns themulticast routing protocols themselves: how wellthey work and how well they scale to largenetworks. The second is the availability ofmulticast. Many corporate networkadministrators have yet to enable it in theirnetwork routers, and many ISPs are evaluatingthe business case to offer multicast service andthe costs of doing so. These issues will beresolved over time and multicast will beubiquitous on corporate networks in the nextcouple of years and in widespread use on theInternet someday. Ubiquity on the Internet isunclear — perhaps within the realms of ISPs ismost realistic.

One of the key objectives of the JRM Servicewas to develop a reliable multicast protocol[TRAM] that enables large-scale distribution ofdata. Through design, implementation, analysisand experimentation, we have learned how hardthis problem is. In real networks there is alwaysloss occurring somewhere in the network.Throughput bandwidth is variable when there issome level of network load. This requiredconsideration of complex algorithms forcongestion detection, avoidance and control aswell as protocol overhead to construct, maintainand optimize the repair tree. As the number ofreceivers grows, the protocol overhead must beminimized so as not to consume any significantbandwidth on the network. A mechanism to dealwith slow receivers was needed to allowdisconnection of receivers from the repair treewhich were too slow to keep up, thereby causingthe whole transmission to all receivers to lock-

step with the slowest receiver. This mechanismenables applications to decide how best totradeoff completion of the overall transmissionand error recovery. In addition, the TRAMprotocol provides for transmission between aminimum and maximum speed. This issomewhat novel because a majority of IPnetwork applications have been traditionallybuilt to use as much bandwidth as they need andthe network will provide without any regard forother applications or network traffic. SinceTCP/IP networks are “best effort delivery,”applications such as ftp use as much bandwidthas the network will provide. The JRM Servicegoes one step further and tries to hold itselfbetween two bounds, perhaps behaving as abetter network citizen but also attempting to givestreaming applications a minimum quality ofservice. Other applications may be builtsimilarly in the future.

9 Future Work

9.1 TRAMSupport for Live and Resilient Data: With afew adjustments, TRAM could support live datatransmissions. The primary difference betweenbulk data and live data is the requirement to viewlive data in real time. Bulk data can afford todelay repair of a single packet; live data cannot..

Full Data Recovery for Late Joins: CurrentlyTRAM has no guaranteed support for late joinersrequiring full data recovery. If a member comeslate to a session, it may not find a repair headthat has all of the existing session data in itscache.

Congestion Control: Once TRAM is more fullydeployed and there are more results concerningthe performance of TRAM's congestion control,we expect to make more improvements. Inparticular, interaction with other network traffic,for instance, TCP, needs further study.

Repair Tree Management: Some situations callfor more controlled tree formation. Somepossibilities include

• Static assignments of members to repairheads

• Static assignment of standby repair heads

9.2 Channel ManagementCaching Dynamic Filters: The current designcalls for dynamic filters to be automaticallyupdated by requiring receivers to re-register fromtime to time. However, it is likely that dynamicfilters will not change very often. Cachingdynamic filters or otherwise making thempersistent at the receiver is a possibleenhancement.

9.3 Address AllocationEmerging Protocols: Address AllocationProtocol [AAP] and Multicast Dynamic HostConfiguration Protocol [MDHCP] are currentlyInternet Drafts. As they move along the stan-dards process, they may replace or supplementThe JRM Service’s current address allocationtechniques.

9.4 SAP SupportJRMS leverages SAP as a mechanism toadvertise the existence of multicast sessions.Alternatives or enhancements to SAP must beexamined due to the inherent limitations in itsability to scale well once the session countbecomes extremely large.

10 AcknowledgementsThe authors wish to thank Dah Ming Chiu, SteveHurst, Radia Perlman, Seth Proctor and JoeWesley for their contributions to the content ofthis paper.

11 References

[AAP] MALLOC Working Group, M. Handley,Multicast Address Allocation Protocol, draft-ietf-malloc-aap-01.txt, work in progress, July1998

[ADMIN] D. Meyer, Administratively Scoped IPMulticast, RFC 2365, July 1998

[AIM] B. Levine, J. Garcia-Luna-Aceves,Improving Internet Multicast with RoutingLabels, University of California, Santa Cruz,1997

[BGMP] S. Kumar, P. Radoslavov, D. Thaler, C.Alaettinoglu, D. Estrin, M. Handley, TheMASC/BGMP Architecture for Inter-domainMulticast Routing, SIGGCOMM ’98

[CBT] T. Ballardie, Core Based Trees (CBT)Multicast Routing Architecture, RFC 2201,September 1997

[DVMRP] T. Pusateri, Distance VectorMulticast Routing Protocol, draft-ietf-idmr-dvmrp-v3-06, work in progress, March 1998

[HANDLEY] M. Handley, On ScalableMultimedia Conferencing Systems, University ofLondon, November, 1997

[IGMP] W. Fenner, Internet Group ManagementProtocol, Version 2, RFC 2236, November 1997

[IP] D. Comer, Internetworking with TCP/IP,Volume I, Prentice-Hall, ISBN0-13-468505-9, 1991

[KEYING] G. Caronni, M. Waldvogel, D. Sun,B. Plattner, Efficient Security for Large andDynamic Multicast Groups, Proceedings of theSeventh Workshop on Enabling Technologies(WET ICE ’98), IEEE Computer Society Press,1998

[LMS] C. Papadopoulos, G. Parulkar, G.Varghese, An Error Control Scheme for Large-Scale Multicast Applications, WashingtonUniversity St. Louis, 1997

[LRMP] T. Liao, Light-weight ReliableMulticast Protocol as an Extension to RTP,http://monet.inria.fr/lrmp/lrmp-rtp.html

[MASC] D. Estrin, R. Govindan, M. Handley, S.Kumar, P. Radoslavov, D. Thaler, The MulticastAddress-Set Claim (MASC) Protocol, draft-ietf-idmr-masc-01, work in progress, August, 1998

[MBONE] The MBone Information Web,http://www.mbone.com

[MDHCP] S. Hanna, B. Patel, M. Shah,Multicast Address Allocation based on theDynamic Host Configuration Protocol, draft-ietf-malloc-mdhcp-00.txt, work in progress,August, 1998

[MOSPF] J. Moy, Multicast Extensions toOSPF, RFC 1584, March 1994

[MULTICAST] S. Deering, Host Extensions forIP Multicasting, RFC 1112, August 1989

[PIM-DM] D. Estrin, V. Jacobson, D. Farinacci,D. Meyer, L. Wei, S. Deering, A. Helmy,Protocol Independent Multicast Version 2 DenseMode, draft-ietf-pim-v2-dm-00, work inprogress, August 1998

[PIM-SM] D. Estrin, D. Farinacci, A. Helmy, D.Thaler, S. Deering, M. Handley, V. Jacobson, C.Liu, P. Sharma, L. Wei, Protocol IndependentMulticast - Sparse Mode (PIM-SM); ProtocolSpecification, RFC 2117, June 1997

[RANDOM] A. Costello, Search Party: AnApproach to Reliable Multicast with LocalRecovery, University of California, Berkeley,1997

[RTNG] T. Maufer, C. Semeria, Introduction toIP Multicast Routing, draft-ietf-mboned-intro-multicast-03.txt, work in progress, July 1997

[SACK] M. Mathis, J. Mahdavi, S. Floyd, A.Romanow, TCP Selective AcknowledgementOptions, RFC 2018, October 1996

[SAP] M. Handley, SAP: Session AnnouncementProtocol, draft-ietf-mmusic-sap-03.txt, work inprogress, March 1997

[SCALE] M. Handley, Session Directories andInternet Multicast Address Allocation,Computer Communication Review, volume 28,number 4, October 1998

[SDP] M. Handley, V. Jacobson, SDP: SessionDescription Protocol, RFC 2327, April 1998

[SDR] M. Handley, The sdr Session Directory:An Mbone Conference Scheduling and BookingSystem, http://mice.ed.ac.uk/mice/archive/sdr.html,April 1996

[SECURITY] C. Kaufman, R. Perlman, M.Speciner, Network Security: Private Communi-cation in a Public World, Prentice Hall, 1995

[SURVEY] B. Levine, J. Garcia-Luna-Aceves,A Comparison of Known Classes of ReliableMulticast Protocols. University of California,Santa Cruz, 1996

[TRAM] D. Chiu, S. Hurst, M. Kadansky, J.Wesley, TRAM: a Tree-based Reliable MulticastProtocol, Sun Microsystems Laboratories, SMLITR-98-66, July 1998

About the Authors

Phil Rosenzweig is the Director of the BostonCenter for Networking at Sun MicrosystemsLaboratories, Chelmsford, MA. He leads an ad-vanced development group that focuses on newnetwork protocols and services. Current projectsinclude developing enabling technology forreliable IP Multicast and a new public keysecurity infrastructure. For the previous sixyears, he led Sun’s PC Networking Group, wherehe was responsible for the PC-NFS productfamily that provides connectivity between PCsand UNIX systems. Prior to Sun, Rosenzweigwas Director of Software at Xyplex, where hehelped develop one of the first multi-protocolcommunications servers. Rosenzweig received aBachelor’s degree in Computer Science fromRochester Institute of Technology in 1977.

Miriam Kadansky is a Senior Staff Engineer atSun Microsystems Laboratories, Chelmsford,MA. She is the Technical Lead of the JRMService team. Kadansky has a Bachelor’sdegree in Mathematics from Harvard College,and worked for several networking vendorsbefore joining Sun. Her current interests includesecure reliable multicasting and Java software.

Steve Hanna is a Staff Engineer at Sun Micro-systems Laboratories, Chelmsford, MA. He isthe Technical Lead of the Internet Securityresearch team and former Technical Lead of theJRM Service team. Before arriving at Sun,Hanna worked at several software firmsincluding ON Technology and Lotus. Hiscurrent technical interests include Java software,multicast, security, internationalization, andhuman interface issues. Hanna is the co-chair ofthe Multicast Address Allocation (malloc)working group of the Internet Engineering TaskForce. He has a Bachelor’s degree in ComputerScience from Harvard College.

The Java™ Reliable Multicast™Service - CiteSeerX

Documents

Transcript of The Java™ Reliable Multicast™Service - CiteSeerX