Multicast Papers Appeared in 1998

Where to Provide Support For Efficient Multicasting In Irregular Networks: Network Interface of Switch?, Rajeev Sivaram, Ram kesavan, Dhabaleswar K. Panda, Craig B. Stunkel, IBM Rep. 1998

Agent-based Multicast Routing, S.G. Hild and J.H. Bischof, IBM Rep. 1998

Agent systems are elegant, but it is difficult to find application of practical importance that gain from being implemented with agent technology as opposed to conventional means: the prevailing opinion is that agents are a solution in search of a problem. In this short paper we state our definition of agents, briefly describe the Aglet agent system, and give details of an application that we believe is of practical importance and is more easily implemented with agent technology than other techniques: we introduce an agent that roams a network of arbitrary topology and configures a multicast network equivalent to the minimum spanning tree between the sender and the receivers.

Centralized Multicast. Srinivasan Keshav and Sanjoy Paul. (TR98-1688)

Search Party: Using Randomcast for Reliable Multicast with Local Recovery. Adam M. Costello and Steven McCanne. (CSD-98-1011)

Scalable Multimedia Communication with Internet Multicast, Light-weight Sessions, and the MBone. Steven R McCanne. (CSD-98-1002)

Improving Reliable Multicast Using Active Parity Encoding Services (APES). D. Rubenstein, S. Kasera, D. Towsley and J. Kurose. (UM-CS-1998-079)

The Loss Path Multiplicity Problem for Multicast Congestion Control. S. Bhattacharyya, D. Towsley and J. Kurose. (UM-CS-1998-076)

Real-Time Reliable Multicast Using Proactive Forward Error Correction TITLE2:. D. Rubenstein, J. Kurose and D. Towsley. (UM-CS-1998-019)

Location-Based Multicast in Mobile Ad Hoc Networks. Young-Bae Ko and Nitin H. Vaidya. (TR98-018)

K. C. Almeroth, M. Ammar, and Z. Fei, "Scalable delivery of web pages using cyclic best-effort multicast," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1214, March/April 1998.

Abstract: The World Wide Web (WWW) has gained tremendously in popularity over the last several years. In this work we explore the use of UDP, best-effort multicast as a delivery option. Reliability is achieved through repetitive, cyclic transmission of a requested page. This solution is expected to be most efficient when used for highly requested pages. We view this cyclic multicast technique as a delivery option that can be integrated with the traditional reliable unicast and recently proposed reliable multicast options. We first describe the architecture of an integrated web server employing all three delivery options. We then describe the cyclic multicast technique and consider the various procedures needed for its successful operation. We characterize the gains in performance achieved by our proposal through an extensive performance analysis and simulation of our technique by itself, and when integrated with the other delivery options. We also describe our experience with an implementation of a prototype cyclic multicast server and its performance over the Multicast Backbone (MBone).

T. Anker, D. Breitgand, D. Dolev, and Z. Levy, "IMSS: IP multicast shortcut service," Internet Draft, Internet Engineering Task Force, Jan. 1998. Work in progress.

Abstract: This memo describes an IP Multicast Shortcut Service (IMSS) over a large ATM cloud. The service enables cut-through routing between routers serving different Logical IP Subnets (LISs). The presented solution is complementary to MARS [2], adopted as the IETF standard solution for IP multicast over ATM. IMSS consists of two orthogonal components: CONnection-oriented Group address RESolution Service (CONGRESS) and IP multicast SErvice for Non-broadcast Access Networking TEchnology (IP-SENATE). An IP class D address is resolved into a set of addresses of multicast routers that should receive the multicast traffic targeted to this class D address. This task is accomplished using CONGRESS. The cut-through routing decisions and actual data transmission are performed by IP- SENATE. IMSS preserves the classical LIS model [8]. The scope of IMSS is to facilitate inter-LIS cut-through routing, while MARS provides tools for the intra-LIS IP multicast.

P. Bagnall, B. Briscoe, and A. Poppitt, "Taxonomy of communication requirements for large-scale multicast applications," Internet Draft, Internet Engineering Task Force, May 1998. Work in progress.

Abstract: The intention of this draft is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimise the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardising the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardisation.

T. Ballardie, B. Cain, and Z. Zhang, "Core based tree (CBT) multicast border router specification," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This draft specifies the behaviour of a CBT multicast border router (BR). This specification assumes the use of CBTv3 - the latest CBT protocol version [3]. CBTv3 has capabilities which make CBT equally well suited for use in stub- or transit- domains; this draft describes mechanisms which enable a CBT distribution tree to span only those routers and links leading to interested receivers or receiver-domains.

T. Ballardie, B. Cain, and Z. Zhang, "Core based trees (CBT version 3) multicast routing - protocol specification," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This document describes the Core Based Tree (CBT version 3) network layer multicast routing protocol. CBT builds a shared multicast dis- tribution tree per group, and is suited to inter- and intra-domain multicast routing. CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1]. This specification supercedes and obsoletes RFC 2189. Changes from RFC 2189 include support for source specific joining and pruning to provide better CBT transit domain capability, new packet formats, and new robustness features. Section 1 documents the primary changes to RFC 2189. This document is progressing through the IDMR working group of the IETF. CBT related documents include [1, 2, 3, 5, 8]. For all IDMR- related documents, see http://www.cs.ucl.ac.uk/ietf/idmr.

M. P. Barcellos and P. D. Ezhilchelvan, "An End-to-End Reliable Multicast Protocol Using Polling for Scaleability," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1180, March/April 1998.

Abstract: Reliable sender-based one-to-many protocols do not scale well due mainly to implosion caused by excessive rate of feedback packets arriving from receivers. We show that this problem can be circumvented by making the sender poll the receivers at carefully planned timing instants, so that the arrival rate of feedback packets is not large enough to cause implosion. We describe a generic end-to-end protocol which incorporates this polling scheme together with error and flow control mechanisms. We analyze the behavior of our protocol using simulations which indicate that our scheme can be effective in minimizing losses due to implosion, achieving high throughput with low network cost.

Keywords: Feedback Implosion; Reliable Multicast; Transport Protocols

A. Banerjea, M. Faloutsos, and R. Pankaj, "Designing QoSMIC: a quality of service sensitive multicast internet protocol," Internet Draft, Internet Engineering Task Force, May 1998. Work in progress.

Abstract: We present, QoSMIC, a multicast protocol for the Internet that supports QoS-sensitive routing, and minimizes the importance of a priori configuration decisions (such as core selection). The protocol is resource-efficient, robust, flexible, and scalable. In addition, our protocol is provably loop-free. Our protocol starts with a resources-saving tree (Shared Tree) and individual receivers switch to a QoS-competitive tree (Source-Based Tree) when necessary. In both trees, the new destination is able to choose the most promising among several paths. An innovation is that we use dynamic routing information without relying on a link state exchange protocol to provide it. Our protocol limits the effect of pre- configuration decisions drastically, by separating the management from the data transfer functions; administrative routers are not necessarily part of the tree. This separation increases the robustness, and flexibility of the protocol. Furthermore, QoSMIC is able to adapt dynamically to the conditions of the network. The QoSMIC protocol introduces several new ideas that make it more flexible than other protocols proposed to date. In fact, many of the other protocols, (such as YAM, PIM-SM, BGMP, CBT) can be seen as special cases of QoSMIC. The goal of this document is to present the motivation behind, and the design of QoSMIC, and to provide both analytical and experimental results to support our claims. NOTE: The text version of the draft is missing several figures, that facilitate the understanding of the work. For this, the authors suggest the postscript version.

S. Bhattacharyya, J. F. Kurose, D. Towsley, and R. Nagarajan, "Efficient rate-controlled bulk data transfer using multiple multicast groups," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1172, March/April 1998.

Abstract: Controlling the rate of bulk data multicast to a large number of receivers is difficult due to the heterogeneity among the end-systems’ capabilities and their available network bandwidth. If the data transfer rate is too high, some receivers will lose data, and retransmission will be required. If the data transfer rate is too low, an inordinate amount of time will be required to transfer the data. In this paper, we examine an approach towards rate-controlled multicast of bulk data in which the sender uses multiple multicast groups to transmit data at different rates to different sub-groups of receivers. We present simple algorithms for determining the transmission rate associated with each multicast channel, based on static resource constraints, e.g., network bandwidth bottlenecks. Transmission rates are chosen so as to minimize the average time needed to transfer data to all receivers. Analysis and simulation are used to show that our policies for rate selection perform well for large and diverse receiver groups and make efficient use of network bandwidth. Moreover, we find that only a small number of multicast groups are needed to reap most of the possible performance benefits.

S. Bradner, A. Mankin, V. Paxson, and A. Romanow, "IETF criteria for evaluating reliable multicast transport and application protocols," Request for Comments (Informational) 2357, Internet Engineering Task Force, June 1998.

Abstract: This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF.

S. Bradner, A. Mankin, A. Romanow, and V. Paxson, "IETF criteria for evaluating reliable multicast transport and application protocols," Internet Draft, Internet Engineering Task Force, May 1998. Work in progress.

Abstract: This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes 1997]. A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications. [Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet? The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols.

B. Cain and S. Biswas, "IGMP multicast router discovery," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: Companies have been proposing ''IGMP snooping'' type schemes for layer-2 bridging devices. A method for discovery multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discoverying multicast routers as one querier is elected. In order to ''discover'' multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers.

J. Crowcroft, H. Fuchs, T. Turletti, A. Ghosh, Z. Wang, L. Vicisano, and C. Diot, "RMFP: a reliable multicast framing protocol," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: There has been considerable interest in reliable multicast, and a number of reliable multicast transport applications and systems have been built in the past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A survey of most of current reliable multicast protocols is available in [Diot97].

J. Crowcroft and M. Ohta, "Static multicast," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: The current IP Multicast model appears to achieve a level of simplicity by extending the IP unicast addressing model (historically the classful A,B, and C net numbers) from the mask and longest match schemes of CIDR, with a new classful address space, class D. The routing systems have been also built in a deceptively simple way in one of three manners - either broadcast and prune (DVMRP, Dense Mode PIM), destination list based tree computation (MOSPF) or single centered trees (current sparse mode PIM and CBT). The multicast service creates the illusion of a spectrum that one can ''tune in to'', as an application writer. Due to this view, many have seen the multicast pilot service, the Mbone, as a worldwide Ethernet, where simple distributed algorithms can be used to allocate ''wavelengths'' and advertise them through ''broadcast'' on a channel (the session directory), associated with a spectrum.

S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei, "Protocol independent multicast-sparse mode (PIM-SM): protocol specification," Request for Comments (Experimental) 2362, Internet Engineering Task Force, June 1998. (Obsoletes RFC2117).

Abstract: This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast-Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups.

S. Deering, B. Fenner, and B. Haberman, "Multicast listener discovery (MLD) for IPv6," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol [IGMPv2]. One important difference to note is that MLD uses ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. This document is a product of the IP Next Generation working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipng@sunroof.Eng.Sun.COM and/or the author(s).

S. Deering and B. Hinden, "IPv6 multicast address assignments," Request for Comments (Informational) 2375, Internet Engineering Task Force, July 1998.

Abstract: This document defines the initial assignment of IPv6 multicast addresses. It is based on the "IP Version 6 Addressing Architecture" [ADDARCH] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments.

K. Dubray, "Terminology for IP multicast benchmarking," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: The purpose of this draft is to add terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 1944, and other IETF Benchmarking Methodology Working Group (BMWG) effort and extends them to the multicast paradigm.

D. Estrin, D. Meyer, and D. Thaler, "Border gateway multicast protocol (BGMP): protocol specification," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This document describes BGMP, a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and allows receiver domains to build source-specific, inter-domain, distribution branches where needed. Building upon concepts from CBT and PIM-SM, BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). BGMP assumes that at any point in time, different ranges of the class D space are associated (e.g., with MASC [MASC]) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.

R. Finlayson, "An abstract API for multicast address allocation," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This document describes the ''abstract service interface'' for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.

R. Finlayson, "IP multicast and firewalls," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal 'intranet'. In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast.

R. Finlayson, "The multicast attribute framing protocol," Internet Draft, Internet Engineering Task Force, Jan. 1998. Work in progress.

Abstract: The Internet has recently seen the emergence of applications that involve the ongoing transmission, or ''pushing'', of structured data from a server to one or more client nodes. Most current applications send this data using unicast communications - usually over TCP connections. However, similar applications can also be implemented using multicast-based protocols. Multicast not only improves the scalability of this particular class of application, but also makes possible an additional class of application in which the participants can act as peers - sending data as well as receiving. This Internet Draft describes the ''Multicast Attribute Framing Protocol'' (MAFP) - a generic, attribute-based data representation, intended for a wide variety of multicast-based applications. It is currently being used to implement the ''multikit'' generic multicast session browser (http://www.lvn.com/multikit). This draft describes an early version of MAFP that is likely to undergo changes in the future. However, it is being described now, in the hope that it will promote open discussion of this and similar protocols - ideally leading to the adoption of an open, interoperable standard for this class of application.

R. Finlayson, "The UDP multicast tunneling protocol," Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress.

Abstract: Many Internet hosts - such as PCs - while capable of running multicast applications, cannot access the MBone because (i) the router(s) that connect them to the Internet do not yet support IP multicast routing, and (ii) their operating systems cannot support a tunneled implementation of IP multicast routing. The ''UDP Multicast Tunneling Protocol'' (UMTP) enables such a host to establish an 'ad hoc' connection to the MBone by tunneling multicast UDP datagrams inside unicast UDP datagrams. By using UDP, this tunneling can be implemented as a 'user level' application, without requiring changes to the host's operating system. It is important to note, however, that this tunneling mechanism is *not* a substitute for proper multicast routing, and should be used *only* in environments where multicast routing cannot be used instead. This document describes this protocol, as is currently implemented by the liveGate multicast tunneling server (http://www.lvn.com/liveGate).

D. Farinacci, A. Lin, T. Speakman, and A. Tweedly, "Pretty good multicast (PGM) transport protocol specification," Internet Draft, Internet Engineering Task Force, Jan. 1998. Work in progress.

Abstract: Pretty Good Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and retransmissions, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for sca- lability and network efficiency.

D. Farinacci, D. Meyer, and Y. Rekhter, "Intra-LIS IP multicast among routers over ATM using sparse mode PIM," Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress.

Abstract: This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs.

D. Farinacci, D. Meyer, and Y. Rekhter, "Intra-LIS IP multicast among routers over ATM using sparse mode PIM," Request for Comments (Experimental) 2337, Internet Engineering Task Force, May 1998.

Abstract: This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs.

D. Farinacci, L. Wei, and J. Meylor, "Use of anycast clusters for inter-domain multicast routing," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: Anycast Clusters is a proposal to connect multiple ISP sparse-mode PIM domains together. The environment we anticipate is multiple interconnection points among a set of ISPs when they are unable to colocate their respective RPs at the same dense-mode interconnect point. This is an alternative to the Multi-Level RP design and requires less new code in routers. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment and is upward compatible with the IDMR protocols being proposed for subsequent phases.

M. Greene and C. Chung, "Definitions of managed objects for multicast over UNI 3.0/3.1 based ATM networks," Internet Draft, Internet Engineering Task Force, Apr. 1998. Work in progress.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community.

S. Hanna, "Multicast address request protocol (MARP)," Internet Draft, Internet Engineering Task Force, Jan. 1998. Work in progress.

Abstract: The Multicast Address Request Protocol (MARP) serves as a front end to the Multicast Address Allocation Architecture. Any host that wishes to allocate a multicast address may contact a Multicast Address Allocation Server and use MARP to request an address allocation for a specific interval, scope, etc. Later, the host may request an extension of the address allocation or deallocate the address if it is no longer needed.

M. Hashemi and A. Leon-Garcia, "A Multicast Single-Queue Switch with a Novel Copy Mechanism," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 800, March/April 1998.

Abstract: A new multicasting mechanism for RAM-based shared-buffer ATM switches is introduced. Multiple logical output queues, including a new queue for multicast and broadcast cells, are all interleaved into a single physical buffer as in the single-queue switch architecture [Hashemi and Garcia 97]. Queues are hardware-independent and full buffer-sharing is achieved. Cells are scheduled in the multicast queue based on their priority level and service type as in the unicast queues. A single copy of a multicast cell is kept in the queue. The cell is sent to all of its designations upon its service time. A unicast cell in a given output queue can still be sent if it has higher priority than a multicast cell. In this case a unicast copy of the multicast cell for that output port is placed in the output queue. This copying scheme requires neither extra hardware nor extra memory space for duplicated cells. A new grouping algorithm is presented which supports the incorporation of the multicast queue and the unicast queues into a single overall queue.

Keywords: ATM Switch Architecture; Multicasting; Scheduling; RAM-Based Shared-Buffer Switch; Quality of Service; Single-Queue Switch

S. P. Hong, H. Lee, and B. H. Park, "An Efficient Multicast Routing Algorithm for Delay-Sensitive Applications with Dynamic Membership," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1433, March/April 1998.

Abstract: We propose an algorithm for finding a multicast tree in packet-switched networks. The objective is to minimize total cost incurred at the multicast path. The routing model is based on the minimum cost Steiner tree problem. The Steiner problem is extended, in our paper to incorporate two additional requirements. First, the delay experienced along the path from the source to each destination is bounded. Second, the destinations are allowed to join and leave multicasting anytime during a session. To minimize the disruption to on-going multicasting the algorithm adopts the idea of connecting a new destination to the correct multicasting by a minimum cost path satisfying the delay bound. To find such a path is an NP-hard problem and an enumerative method relying on generation of delay bounded paths between node pairs is not likely to find good routing path in acceptable computation time when network size is large. To cope with such difficulty, the proposed algorithm utilizes an optimization technique called Lagrangian relaxation method. A computational experiment is done on relatively dense and large Waxman's networks. The results seem to be promising. For sparse networks, the algorithm can find near-optimal multicast trees. Also the quality of multicast trees does not seem to deteriorate even when the network size grows. Furthermore, the experimental results shows that the computational efforts for each addition of node to the call are fairly moderate, namely the same as to solve a few shortest path problems.

P. Johansson, "Multicast channel allocation protocol (MCAP) for IEEE 1394," Internet Draft, Internet Engineering Task Force, Apr. 1998. Work in progress.

Abstract: This docuent specifies how IP-capable Serial Bus devices may allocate IEEE 1394 channel nuber(s) for use in the multicast transmission of IP datagras. It defines the necessary methods, data structures and codes for that purpose. See also the ost recent revision of draft-ietf-ip1394-ipv4 for a specification of the transport of IPv4 datagras over IEEE 1394. CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe parts reflect rough consensus achieved at the 41st IETF eeting in Los Angeles, other parts reflect the editor's distillation of coments on the reflector since then and still other parts are new contributions to the evolution of MCAP. Until subsequent revisions of this docuent are posted that ore clearly identify agreed areas, the reader should consider this a work in progress very uch subject to revision. This docuent is not yet adopted by the IP/1394 working group.

S. K. Kasera, J. Kurose, and D. Towsley, "A comparison of server-based and receiver-based local recovery approaches for scalable reliable multicast," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 988, March/April 1998.

Abstract: Local recovery approaches for reliable multicast have the potential to provide significant performance gains in terms of reduced bandwidth and delay, and higher system throughput. In this paper we examine two local recovery approaches: one server-based, and the other receiver-based, and compare their performance. The server-based approach makes use of specially designated hosts, called repair servers, co-located with routers inside the network. In the receiver-based approach, only the end hosts (sender and receivers) are involved in error recovery. Using analytical models, we first show that the two local recovery approaches yield significantly higher protocol throughput and lower bandwidth usage than an approach that does not use local recovery. Next, we demonstrate that server-based local! recovery yields higher protocol throughput and lower bandwidth usage than receiver-based local recovery when the repair servers have processing power slightly higher than that of a receiver and several hundred kilobytes of buffer per multicast session.

Jean Francois Labourdette, "Traffic Optimization and Reconfiguration Management of Multiwavelength Multihop Broadcast Lightwave Networks," Computer Networks and ISDN Systems, vol. 30, pp. 981-998, May 1998.

Abstract: Lightwave network architectures have emerged that aim to go far beyond simply exploiting the huge point-to-point transmission capabilities of fiber optics. One of the most powerful and promising feature of optical networks is their ability to be dynamically reconfigured by retuning the optical transmitters/receivers. This ability to realize a logical connectivity among network nodes independently of the physical infrastructure allows to (1) increase network utilization while providing better network performance by adapting the bandwidth allocation to changing traffic loads and (2) react to failure by bypassing those elements that failed (fault-tolerant/self-healing capabilities). In this paper, we study and review the literature on the two main research problems raised by dynamic reconfiguration of multiwavelength multihop broadcast lightwave networks. The two problems are (1) traffic optimization to find the ``best'' configuration for a given traffic pattern, and (2) reconfiguration management to go from one configuration to another. We present mathematical formulations for the problems, reference NP-completeness results, and describe and compare heuristic algorithms. We also discuss open research problems. This work is limited to broadcast optical networks, and does not directly apply to wavelength-routed optical networks, where the wavelengths making up the logical connectivity among nodes have to be allocated and routed.

Keywords: optical network; traffic optimization; reconfiguration; multihop

L. W. Lehman, S. Garland, and D. L. Tennenhouse, "Active Reliable Multicast," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 581, March/April 1998.

Abstract: This paper presents a novel loss recovery scheme, Active Reliable Multicast (ARM), for large-scale reliable multicast. ARM is active in that routers in the multicnst tree play an active role in loss recovery. Additionally, ARM utilizes soft-state storage within the network to improve performance and scalability. In the upstream direction, routers suppress dupticate NACKS from multiple receivers to control the implosion problem. By suppressing dupticate NACKS, ARM also lessens the traffic that propagates back through the network. ln the downstream direction, routers limit the delivery of repair packets to receivers experiencing loss, thereby reducing network bandwidth consumption. Finally, to reduce wide-area recovery latency and to distribute the retransmission load, routers cache multicast data on a best-effort basis. ARM is flexible and robust in that it does not require all nodes to be active, nor does it require any specific router or receiver to perform loss recovery. Analysis and simulation results show that ARM yields significant benefits even when less than half the routers within the multicast tree can perform ARM processing.

Keywords: Reliable multicaat; active networks; soft state; distributed network algorithms; protocol design and analysis; NACK implosion

H. C. Lin and S. C. Lai, "VTDM - A Dynamic Multicast Routing Algorithm," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1426, March/April 1998.

Abstract: In this paper, the dynamic multicast routing problem is studied. The multicast routing problem has been shown to be NP-complete. Many heuristics have been proposed to find the multicast trees for multicast connections. In computer networks, application services may allow nodes to join or leave the multicast connection dynamically. The mrdticast routing problem in which nodes are allowed to join or leave the multicast connection is caned the dynamic multicast routing problem. A new dynamic multicast routing algorithm called Virtual Trunk Dynamic Multicast (VTDM) routing algorithm is proposed for this problem, A Virtual Trunk (VT) is a tree of the underlying graph. It is used as a template for constructing multicast trees. The VTDM routing algorithm constructs multicast trees based on the virtual trunk. Simulations are performed to study the performance of the VTDM routing algorithm. Simulation results show that the performance of the VTDM algorithm is close to that of the KMB algorithm [Kou et at, 81] (a near optimal heuristic for the static multicast routing problem).

Keywords: ATM networks; Dynamic multicast routing algorithm

X. Li, S. Paul, and M. Ammar, "Layered video multicast with retransmissions (LVMR): evaluation of hierarchical rate control," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1062, March/April 1998.

Abstract: Layered Video Multicast with Retransmissions (LVMR) is a system for distributing video using layered coding over the Internet, The two key contributions of the system are: (1) improving the quality of reception within each layer by retransmitting lost packets given an upper bound on recovery time and applying an adaptive playback point scheme to help achieve more successful retransmission, and (2) adapting to network congestion and heterogeneity using hierarchical rate control mechanism. This paper concentrates on the rate control aspects of LVMR. In contrast to the existing sender-based and receiver-based rate control in which the entire information about network congestion is either available at the sender (in sender-based approach) or replicated at the receivers (in receiver-based approach), the hierarchical rate control mechanism distributes the information between the sender, receivers, and some agents in the network in such a way that each entity maintains only the information relevant to itself. In addition to that, the hierarchical approach enables intelligent decisions to be made in terms of conducting concurrent experiments and choosing one of several possible experiments at any instant of time based on minimal state information at the agents in the network. Protocol details are presented in the paper together with experimental and simulation results to back our claims.

J. Liebeherr and B. S. Sethi, "A Scalable Control Topology for Multicast Communications," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1197, March/April 1998.

Abstract: Large-scale multicast applications for the Internet require the availability of multicast protocols that enhance the basic connectionless IP Multicast service. A critical requirement of such protocols is their ability to support a large group of simultaneous users. In this paper, we present a new approach for distributing control information within a multicast group. The goal of our approach is to scale to very large group sizes (in excess of lOO,OOO users). Multicast group members are organized as a logical n-dimensional hypercube, and all control information is transmitted along the edges of the hypercube. We analyze the scalability of the hypercube control topology and show that the hypercube balances the load per member for processing control information better than existing topologies.

D. Meyer, "Administratively scoped IP multicast," BC 2365, Internet Engineering Task Force, July 1998.

Abstract: This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes.

J. Nonnenmacher and E. W. Biersack, "Optimal multicast feedback," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 964, March/April 1998.

Abstract: We investigate the scalability of feedback in multicast communication and propose a new method of probabilistic feedback based on exponentially distributed timers. By analysis and simulation for up to 106 receivers we show that feedback implosion is avoided while feedback latency is low. The mechanism is robust against the loss of feedback messages and robust against homogeneous and heterogeneous delays. We apply the feedback mechanism to reliable multicast and compare it to existing timer-based feedback schemes. Our mechanism achieves lower NAK latency for the same performance in terms of NAK suppression. It is scalable, the amount of state at every group member is independent of the number of receivers. No topological information of the network is used and data delivery is the only support required from the network. It adapts to the number of receivers and leads therefore to a constant performance for implosion avoidance and feedback latency.

Keywords: Feedback; Multicast; Reliable Multicast; Performance Evaluation; Extreme Value Theory

J. Nonnenmacher, M. Lacher, M. Jung, E. Biersack, and G. Carle, "How bad is reliable multicast without local recovery?," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 972, March/April 1998.

Abstract: We examine the impact of the loss recovery mechanisms on the performance of a reliable multicast protocol. Approaches to reliable multicast can be divided into two major classes: source-based recovery, and distributed recovery. For both classes we consider the state of the art: For source-based recovery, a type 2 hybrid ARQ scheme with parity retransmission. For distributed recovery, a scheme with local multicast retransmission and local feedback processing. We further show the benefits of combining the two approaches and consider a type 2 hybrid ARQ scheme with local retransmission. The schemes are compared for up to 106 receivers under different loss scenarios with respect to network bandwidth usage and completion time of a reliable transfer We show that the protocol based on local retransmissions via type 2 hybrid ARQ performs best for bandwidth and latency. For networks, where local retransmission is not possible, we show that a protocol based on type 2 hybrid ARQ comes close to the performance of a protocol with local retransmission.

Keywords: Reliable Multicast Protocol; Error Control; ARQ; FEC; Performance Evaluation

J. J. Pansiot and D. Grad, "On routes and multicast trees in the internet," ACM Computer Communication Review, vol. 28, pp. 41-50, Jan. 1998.

Abstract: Multicasting has an increasing importance for network applications such as groupware or videoconferencing. Several multicast routing protocols have been defined. However they cannot be used directly in the Internet since most inter-domain routers do no implement multicasting. Thus these protocols are mainly tested either on a small scale inside a domain, or through the Mbone, whose topology is not really the same as Internet topology. The purpose of this paper is to construct a graph using actual routes of the Internet, and then to use this graph to compare some parameters - delays, scaling in term of state or traffic concentration - of multicast routing trees constructed by different algorithms - source shortest path trees and shared trees.

Keywords: Routing; routes; Internet; multicast; shortest path trees; centered trees

M. Pullen, M. Myjak, and C. Bouwens, "Limitations of internet protocol suite for distributed simulation in the large multicast environment," Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress.

Abstract: The Large-Scale Multicast Applications (LSMA) working group was chartered to produce Internet-Drafts aimed at a consensus-based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This draft defines aspects of the Internet protocols that LSMA has found to need further development in order to meet that goal.

C. Papadopoulos, G. Parulkar, and G. Varghese, "An error control scheme for large-scale multicast applications," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1188, March/April 1998.

Abstract: Retransmission based error control for large scale multicast applications is difficult because of implosion and exposure. Existing schemes (SRM, RMTP, TMTP, LBRRM) have good solutions to implosion, but only approximate solutions to exposure. We present a scheme that achieves finer grain fault recovery by exploiting new forwarding services that allow us to create a dynamic hierarchy of receivers. We extend the IP Multicast service model so that routers provide a more refined form of multicasting (which may be useful to other applications), that enables local recovery. The new services are simple to implement and do not require routers to examine or store application packets; hence, they do not violate layering. Besides providing better implosion control and less exposure than other schemes, our scheme integrates well with the current IP model, has small recovery latencies (it requires no back-off delays), and completely isolates group members from topology. Our scheme can be used with a variety of multicast routing protocols, including DVMRP and PIM. We have implemented our scheme in NetBSD Unix, using about 250 lines of new C-code. The implementation requires two new IP options, 4 additional bytes in each routing entry and a slight modification to IGMP reports. The forwarding overhead incurred by the new services is actually lower than forwarding normal multicast traffic.

Keywords: reliable multicast; error control

T. Pusateri, "Distance vector multicast routing protocol," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88].

Dan Rubenstein, S. Kasera, Don Towsley, and James F. Kurose, "Improving reliable multicast using active parity encoding services (APES)," Tech. Rep. 98-79, Department of Computer Science, University of Massachusetts, Amherst, Massachusetts, July 1998.

Abstract: Traditional reliable multicast protocols for the Internet require large amounts of bandwidth to support reliable delivery of data to numerous receivers. In this paper, we propose and evaluate novel protocols that combine active repair service (a.k.a. local recovery) and parity encoding (a.k.a. forward error correction or FEC) techniques. We show that compared to other repair service protocols, our protocols require less buffer inside the network, and maintain the low bandwidth requirements of previously proposed repair service / FEC combination protocols. Our protocols also reduce the amount of FEC processing at repair servers, moving more of this processing to the end-hosts. Last, we examine repair service / FEC combination protocols in an environment where loss rates are different across domains within the network. We find that in such environments, repair services are more effective than FEC at reducing bandwidth utilization. Furthermore, adding FEC to a repair services protocol not only reduces buffer requirements at repair servers, but also reduces bandwidth utilization in domains with high loss, or in domains with large populations of receivers.

Keywords: FEC; reliable multicast; active networks

K. Robertson, K. Miller, M. White, and A. Tweedly, "StarBurst multicast file transfer protocol (MFTP) specification," Internet Draft, Internet Engineering Task Force, Apr. 1998. Work in progress.

Abstract: The Multicast File Transfer Protocol (MFTP) is a protocol that operates above UDP in the application layer to provide a reliable means for transferring files from a sender to up to thousands (potentially millions with network ''aggregators'' or relays) of multiple receivers simultaneously over a multicast group in a multicast IP enabled network. The protocol consists of two parts; an administrative protocol to set up and tear down groups and sessions, and a data transfer protocol used to send the actual file reliably and simultaneously to the multiple recipients residing in the group .

H. Rupp, "A protocol for the transmission of net news articles over IP multicast," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: Mcntp (Multicast News Transfer Protocol) provides a way to use the IP multicast infrastructure to transmit NetNews articles between news servers. Doing so will reduce the bandwidth that is actually needed for transmission of articles which is mostly done via NNTP. This does not affect how news reading clients communicate with servers.

Henning Schulzrinne and Jonathan Rosenberg, "Signaling for internet telephony," Technical Report CUCS-005-98, Columbia University, New York, New York, Feb. 1998.

Abstract: Internet telephony must offer the standard telephony services. However, the transition to Internet-based telephony services also provides an opportunity to create new services more rapidly and with lower complexity than in the existing public switched telephone network (PSTN). The Session Initiation Protocol (SIP) is a signaling protocol that creates, modifies and terminates associations between Internet end systems, including conferences and point-to-point calls. SIP supports unicast, mesh and multicast conferences, as well as combinations of these modes. SIP implements services such as call forwarding and transfer, placing calls on hold, camp-on and call queueing by a small set of call handling primitives. SIP implementations can re-use parts of other Internet service protocols such as HTTP and the Real-Time Stream Protocol (RTSP). In this paper, we describe SIP, and show how its basic primitives can be used to construct a wide range of telephony services.

Keywords: Internet telephony; signaling; SIP; RTSP; intelligent network; ISDN

D. Thaler, "Distance-vector multicast routing protocol MIB," Internet Draft, Internet Engineering Task Force, May 1998. Work in progress.

Abstract: This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Distance-Vector Multicast Routing Protocol (DVMRP) protocol [5,6]. This MIB module is applicable to IP multicast routers which implement DVMRP.

D. Thaler, "Interoperability rules for multicast routing protocols," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, and PIM-SM multicast routing protocols, as well as for IGMP-only links.

J. Tian and G. Neufeld, "Forwarding state reduction for sparse mode multicast communication," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 711, March/April 1998.

Abstract: Reducing forwarding state overhead of multicast routing protocols is an important issue towards a scalable global multicast solution. In this paper, we propose a new approach, Dynamic Tunnel Multicast, which utilizes dynamically established tunnels on unbranched links of a multicast distribution tree to eliminate unnecessary multicast forwarding states. Analysis and simulation results show promising reduction in the state overhead of sparse mode multicast routing protocols.

Keywords: Multicast; Routing; State reduction; Dynamic tunnel

B. Vickers, C. Albuquerque, and T. Suda, "Adaptive multicast of multi-layered video: Rate-based and credit-based approaches," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 1073, March/April 1998.

Abstract: Network architectures that can efficiently transport high quality, multicast video are rapidly becoming a basic requirement of emerging multimedia applications. The main problem complicating multicast video transport is variation in network bandwidth constraints. An attractive solution to this problem is to use an adaptive, multi-layered video encoding mechanism. In this paper, we consider two such mechanisms for the support of video multicast; one is a rate-based mechanism that relies on explicit rate congestion feedback from the network, and the other is a credit-based mechanism that relies on hop-by-hop congestion feedback. The responsiveness, bandwidth utilization, scalability and fairness of the two mechanisms are evaluated through simulations. Results suggest that while the two mechanisms exhibit performance trade-offs, both are capable of providing a high quality video service in the presence of varying bandwidth constraints.

L. Vicisano, L. Rizzo, and J. Crowcroft, "TCP-Like congestion control for layered multicast data transfer," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 996, March/April 1998.

Abstract: We present a novel congestion control algorithm suitable for use with cumulative, layered data streams in the MBone. Our algorithm behaves similarly to TCP congestion control algorithms, and shares bandwidth fairly with other instances of the protocol and with TCP flows. It is entirely receiver driven and requires no per-receiver status at the sender, in order to scale to large numbers of receivers. It relies on standard functionalities of multicast routers, and is suitable for continuous stream and reliable bulk data transfer. In the paper we illustrate the algorithm, characterize its response to losses both analytically and by simulations, and analyze its behavior using simulations and experiments in real networks. We also show how error recovery can be dealt with independently from congestion control by using FEC techniques, so as to provide reliable bulk data transfer.

Keywords: congestion control; multicast

N. Yamanouchi, O. Takahashi, and N. Ishikawa, "RADIUS extension for multicast router authentication," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress.

Abstract: This memo describes an extension of RADIUS authentication protocol (RFC2138) and RADIUS accounting protocol (RFC2139) to provide authentication service about multicast receivers and senders to the ingress and egress routers, and to keep track of the receiving and sending clients for multicast data feed service management. New services and attributes are added to the RADIUS definitions while the authentication transaction mechanisms are preserved. The authentication server authenticates the multicast receiver/sender by using the CHAP-based mechanism. The account server logs the start and stop points of multicast route usage. This extension is intended to be used in conjunction with the IGMP extension for multicast receiver and sender authentication.

W. Yung, "TFTP multicast option," Internet Draft, Internet Engineering Task Force, May 1998. Work in progress.

Abstract: The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a new TFTP option. This new option will allow the multiple client to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2]. Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency. This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].

Y. Zheng and H. Imai, "Compact and unforgetable key establishment over an ATM network," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), p. 411, March/April 1998.

Abstract: Authenticated session key establishment is a central issue in network security. This paper addresses a question on whether we can design a compact, efficient and authenticated key establishment protocol that has the following two properties: (1) each message exchanged between two participants can be transferred in a short packet such as an ATM cell whose payload has only 384 bits, and (2) messages that carry key materials are Unforgetable and non-repudiatable without the involvement of a trusted key distribution center. We discuss why the answer to this question is negative if one follows the currently standard approach to key establishment, namely employing secret/public key encryption and, possibly, digital signature. We then present a number of protocols that represent a positive answer to the question. Our protocols are all based on a recently introduced cryptographic primitive called ''signcryption'' that fulfills both the functions of digital signature and public key encryption with a cost far smaller than that required by ''digital signature followed by encryption''.

Keywords: ATM Networks; cryptography; key establishment; multicast; network security; signcryption