IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1754

INVITED PAPER

Special Issue on Content Delivery Networks

Multicast Communications—Present and Future Miki YAMAMOTO†a) , Regular Member

SUMMARY Multicast communications have been expected as an effective way to disseminate information to potentially large number of receivers. IP multicast is a well- known multicast protocol for the Internet. However, IP multicast has several technical problems to be resolved until it is widely deployed in the Internet. These includes service-model of multicast group, reliable transport protocol, congestion control and security. A lot of researches trying to resolve these technical problems make multicast communications a hot research area in these couple of decades. This paper overviews the present style of IP multicast and clearlify technical issues of the present multicast communications. The paper also surveys important approaches to these problems and discuss about future directions of multicast communications. key words: multicast, IP multicast, deployment

1.

Introduction

Deployment and development of the Internet is proceeded rapidly with appearance of killer applications, e.g. electric mail and WWW (World Wide Web). Almost applications used presently in the Internet are implemented on a point-to-point communication model. Communication protocols based on a point-to-point model include FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol) and HTTP (HyperText Transfer Protocol), which are widely used in the Internet. These protocols use, in general, TCP for a transport layer protocol. Now, a different communication model other than point-to-point model, point-tomultipoint or multipoint-to-multipoint is very promising because dissemination of the same data to potentially large number of receivers is now becoming an attractive application. These applications include teleconference, real-time information (voice or image, or both) distribution and file distribution. This type of communication model is called multicast. There can be several ways to implement point-tomultipoint communication model∗ in a network layer. The easiest way is to use multiple point-to-point communications (Fig. 1(a)). In this case, the same data is transmitted multiple times redundantly on a link. Especially, on a link attached to or close to the source, the same data is transmitted lots of times (the same Manuscript received September 29, 2002. Manuscript revised January 22, 2003. † The author is with the Department of Communications Engineering, Graduate School of Engineering, Osaka University, Suita-shi, 565-0871 Japan. a) E-mail: [email protected]

Fig. 1

Point-to-multipoint communications.

number of receivers). The most cost-effective way is multicast (Fig. 1(b)). In multicast, only one packet is transmitted on each link. A data packet is replicated at an adequate router and forwarded to an interface below which there are receivers. Multicast is scalable in the following two points. One is reducing packet-transmission overhead at the source because only one data packet is necessary to be sent by the source. The other is reducing redundant bandwidth wasted by transmission of the multiple same packets on a link. IP multicast [1], [2] is the first communication protocol supporting network layer multicast. In IP multicast, the concept of multicast group is introduced for supporting multicast service. One multicast address chosen from a class D block of IP address is assigned to a multicast group. When a source would like to send a datagram to multiple receivers in a multicast group, the only thing the source should do is to send a datagram to this assigned multicast address. Group membership is managed by routers inside a network and this datagram sent by the source is forwarded to one or more interfaces of a router below which there are receivers by making a replication at an adequate router (a router located at a branching point). IP multicast is, at first, experimentally implemented on MBone (Multicast Backbone) [3]. MBone has been served as a testbed for deployment of IP multicast. To enable running IP multicast on condition that not all routers are multicast-capable, MBone uses overlay model, i.e. multicast-incapable region is skipped over by using a tunneling technique. In MBone, many multicast protocols have been devel∗ A multipoint-to-multipoint model can be implemented as superposition of multiple point-to-multipoint ones. So, we focus on a point-to-multipoint model here.

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1755

oped and tested. These include DVMRP (Distance Vector Multicast Routing Protocol) [4], PIM (Protocol Independent Multicasting) [5], MOSPF (Multicast Open Shortest Path) [6] and RTP (Real-time Transfer Protocol) [7]. Almost routers available today have capability of handling IP multicast. However, only few ISPs (Internet Service Providers) support IP multicast and almost ISPs inactivate IP multicast intentionally [8]. In the paper, we first explain about current status of IP multicast in detail. And in the consecutive sections, we discuss about technical issues for current IP multicast. These issues include a service model, reliable multicast, congestion control and security in multicast. In the paper, we would like to survey important research activities to these problems and also discuss about future directions of multicast communications. The paper is structured as follows. Section 2 presents current status of IP multicast and discusses about deployment issues of it. The following sections discuss each topic of these deployment issues and survey important research directions. Section 3 deals with a service model and shows interesting new service models for multicast communications. In Sect. 4, reliable multicast is highlighted and retransmission control is picked up as a focused issue. In Sect. 5, congestion control is treated and coexistence of multicast traffic and unicast traffic is important discussion here. Section 6 deals with secure multicast which brings secure communications to multicast. In Sect. 7, new approaches to multicast communications, application-level multicasting is discussed. Section 8 concludes the paper. 2.

IP Multicast—Present Technology

In IP multicast, the concept of multicast group is introduced to represent receivers having interest of receiving multicast datagram. The source has no necessity to manage membership information of a corresponding multicast group. This fact shifts the burden of handling information of receivers from the source to routers on the path to receivers, which leads to scalability of IP multicast. In this section, we would like to explain about the current technology of IP multicast in detail. 2.1 Service Model There are two ways to manage receivers, a senderinitiated way and a router-assisted way. In the former way, a sender-initiated way, the sender keeps information of all receivers. The sender should receive some signaling information from all receivers and manage everything in its multicast data transmission. In the latter way, a router-assisted way, routers inside a network manage receivers of multicast communications. IP multicast applies a router-assisted approach. In IP multicast, a concept of multicast group is

used for managing receivers. A receiver having an interest of receiving multicast datagram informs its interest to an edge router (see Sect. 2.3 for details of this operation). In IP multicast, a receiver announces its interest in a multicast group (not a sender of multicast datagram). When an edge router has one or more interested receivers of a multicast group, it establishes path to a multicast distributed tree of a corresponding multicast group by a multicast routing protocol (for details, please see Sect. 2.4). After a distributed tree is established, a datagram of a corresponding multicast group arrives at an edge router and this edge router transmits a datagram to all interested receivers below it by using multicast in LAN. The sender has no necessity to manage receivers. It only has to send a datagram to an aiming multicast group. In IP multicast, membership model is frat, i.e. no identification of the sender and receivers. All members of a multicast group can send a datagram to other members. This means all members can be a sender of a multicast datagram. Even a host of non-member of a multicast group can send a datagram to a multicast group, i.e. all members of a multicast group. 2.2 Multicast Address For multicast communications, a class D address block from 224.0.0.0 to 239.255.255.255, can be used. One multicast address is assigned to a multicast group. This address is an identifier of a multicast group, not a host. When a multicast address is assigned to a multicast group, this address should not be assigned to another group, i.e. a multicast address should be unique to a multicast group. If this restriction is not satisfied, two or more multicast groups have the same multicast address. In this case, a datagram sent to a multicast group from the source arrives at members in another multicast group. Thus, multicast address assignment is one of the most important issues in IP multicast. There have been proposed several protocols for multicast address allocation. In the first stage, fixed assignment of multicast address was investigated, but with this method multicast address may be exhausted. So, dynamic allocation is now discussed in IETF. In dynamic allocation, a multicast address which was used but is not used now is reassigned to an active multicast group. For example, MADCAP (Multicast Address Dynamic Client Allocation Protocol) [9] is used for assignment of a multicast address to a client. A client sends a request to an address allocation server, and a server responds with an allocated multicast address. Multicast addresses are location independent. On the contrary, unicast addresses are well known to be location-oriented. In unicast, address blocks are hierarchically assigned to a domain and CIDR (Classless Inter-Domain Routing) makes use of this location information in an address space to aggregate contents in

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1756

Fig. 3

Fig. 2

Hierarchical structure of multicast routing.

a forwarding table of a router. Multicast address is assigned to a multicast group and this assignment is independent of location of receivers or a source. This location-independent nature of multicast address gives difficulties to address aggregation at a router. 2.3 IGMP Multicast routing has three-tier structure, client-toedge router, intra-domain routing and inter-domain routing, as shown in Fig. 2. For intra-domain and interdomain routing, we would like to discuss in detail in the following section. For client-to-edge router, IGMP (Internet Group Management Protocol) [10] is used. When there are one or more hosts having an interest of receiving datagrams of a multicast group in a local network, an edge router attached to this local network forwards a datagram of a corresponding multicast group to a local network in a style of local multicast. Thus, an edge router has no necessity of having information of all interested hosts, but has to know about whether there is at least one host in a physically attached local network. An edge router running IGMP sends a query named “a membership query” to its attached local networks periodically. When there is a host having an interest of receiving a multicast datagram, it responds to this query by sending a response named “a membership report.” As described above, an edge router should keep records of existence of interested hosts to each multicast group. When there are lots of interested hosts in a local network and these hosts respond at the same time, an edge router may receive lots of membership reports. To avoid this situation of concentration of membership reports, when a host receives a query, it sets random delay timer for each multicast group. When a timer expires without receiving another report for a corresponding multicast group, a host sends a membership report to an edge router. This report is multicast to a local network, so other members of a multicast group reveive it. When a host receives a membership report of a corresponding multicast group

Multicast routing protocols.

before its timer expiration, this host quits sending a membership report. This operation reduces the number of generated reports for each multicast group, which leads to scalability. When a host would like to leave a multicast group, it only acts as not sending a response when it receives a query. Some modification of IGMP is now discussed in IETF [11]. In IGMP version 3, source filtering is introduced as a new function. Hosts can announce its interest of receiving multicast datagram only from a specific source or from all but a specific source from datagrams sent to a multicast group. 2.4 Routing Routing in the Internet can be divided into two categories, intra-domain routing and inter-domain routing. This is also the case for multicast routing. In this section, we would like to explain about current status of IP multicast routing in these two categories. [Intra-domain routing] In multicast communications, routing protocols generally make a tree-shaped path. Multicast routing protocols can be categorized into two categories by the shape of generated distribution tree. One is a protocol using a source-based tree and the other is a protocol using a shared tree (Fig. 3). A source-based tree is constructed by making the source as a root of the tree and interested hosts as leaves. In a source-based tree protocol, a multicast distribution tree is made for each source when a multicast group has multiple sources. In a shared-tree approach, a shared-tree is constructed and multicast groups share this tree to distribute their data. There are two approaches for a source-based tree protocol, a flood-and-prune approach and a link-state approach. In a flood-and-prune protocol, when an edge router receives the first datagram to a multicast group, it distributes this datagram to all routers in a domain (flooding). In a flooding phase, when a router receives a multicast datagram, it forwards this datagram to all interfaces other than an interface from which this datagram arrives. By using this operation, a datagram sent by the sender is broadcast to all routers in a domain. A router sends a prune message in the following two situations. When a link from which a flooding datagram is arrived is not on the shortest path to the source, a

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1757

Fig. 4

Flood and prune protocol.

router sends a prune message to an interface attached to this link (prune message of category 1 in Fig. 4). When an edge router has no hosts interested in a corresponding multicast group below it, it sends a prune message to all nodes from which a flooding datagram arrives (prune message of category 2 in Fig. 4). DVMRP [4] and PIM-DM (Protocol Independent Multicasting Dense Mode) [12], [13] are examples of flood-and-prune approach. In a flood-and-prune approach, a datagram is first distributed to all routers in a domain, which restricts its applicable area only to intra-domain routing. OSPF [14] is a unicast routing protocol using link states. In OSPF, routing information named LSA (Link State Advertisement) is distributed from each router to all other routers in a domain. Each router computes a path based on the same information of network topology which all routers have. This LSA flooding nature makes OSPF only applicable to intra-domain routing. MOSPF (Multicast OSPF) [6] is an extension of OSPF, allowing IP multicast routing in an OSPF domain. In MOSPF, a new type of LSA, the groupmembership-LSA is used for routing information distributed from each router. Each router which has one or more hosts having an interest to receive multicast datagrams announces group membership information to all other routers in a MOSPF domain by sending (flooding) the group-membership-LSA. By flooding groupmembership-LSA, every router in a domain can obtain multicast membership information in a corresponding domain and calculate the shortest path by using obtained information. This shortest path is calculated as the shortest path from each source. On the contrary, in unicast routing of OSPF, the shortest path from the source to the destination is calculated at a router by calculating the shortest path to the destination from this router. This is a difference between path calculation in OSPF and MOSPF. PIM-SM (PIM Sparse Mode) [15] and CBT [16]– [18] are categorized to a protocol of a shared-tree approach. In a shared-tree protocol, a shared tree is constructed for each multicast group. A shred tree has a core (or a RP: randezvous point) which is predefined and known to all edge routers of a domain where a

shared-tree protocol is applied. When a receiver has interest to some multicast group, it announces its interest to an edge router through IGMP. An edge router having an interested host, sends a join message to a core of a shared tree on a unicast communication. This join message constructs a branch from a shared tree to an edge router initiating a join message. These are operations for making a multicast distribution tree in PIM-SM and CBT. In PIM-SM, a shared-tree-based distribution tree can be switched to a source-based tree when traffic volume from a source is higher than a threshold. [Inter-domain Routing] Protocols described above, e.g. DVMRP, MOSPF, PIM-SM and CBT are not suitable for inter-domain routing. This is because, for example for DVMRP, when DVMRP is applied for inter-domain, data is flooded to all routers in the Internet-wide area. There have been several proposals for inter-domain routing, which include BGMP [19], [20]. However, Inter-domain routing in IP multicast is remained research issues. 2.5 Measurement of Multicast Communications MBone (Multicast Backbone) has been served as a testbed for deployment of IP multicast. Since its first operation in early 1992, not only multicast routing protocol but also several applications have been experimentally tried on MBbone. Some applications can be used for measurement of Mbone. These include RTCP (Real-time Control Protocol) [7], mtrace [21], mlisten [23] and MHealth [22]. Almeroth [23] proceeds a longterm analysis of group membership in Mbone. They use sdr(session directory tool) to collect join and leave data. And they monitor RTCP packets in RTP protocol to obtain membership information. In this paper, they show that growth of MBone is very slow, which means deployment of IP multicast is progressed little since first MBone operation in 1992. They enumerate the reasons of slow growth of MBone as follows. Serious problems of MBone are operational costs for initiating a connection to MBone, i.e. seeking an ISP providing IP multicast or connecting to a multicast-capable region by using tunneling technique, low communication quality and no attractive contents.

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1758

Yajnik et al. [24] analyzes packet loss behavior in MBone. They collected packet loss data simultaneously at several hosts geographically distributed in the world by hearing the same session on MBone. They analyze spatial and temporal correlation in packet loss among hosts at different locations. Measured results in [24] show that packet loss at LAN is negligible and packet loss in a backbone network is very low. There is reported to be a major bottleneck close to the source which causes high packet loss rate, about 5%. Handley [25] also analyzes packet loss in MBone. This paper shows that packet loss rate in MBone is quite high and communication quality of MBone is very low. Multicast communication is said to be effective compared with superposition of multiple unicast connections. From this viewpoint, Chalmers et al. [26] measure shapes of multicast trees by using measured data in MBone and analyze effectiveness of multicast communications. Two ways are used for measurement on MBone. One is that MHealth [22] is used for obtaining membership information and a path from each receiver to the source is analyzed by mtrace [21]. In the other way, mlisten [23] is used for obtaining membership information. Chuang and Sirbu examined effectiveness of multicast tree for generated topology in their paper [27]. According to their analysis, multicast tree cost Lm /Lu can be expressed by the following power law form, Lm /Lu = N k

(1)

where Lm - total length of multicast distribution tree, Lu - average length of unicast routing path, N - multicast group size, k - multicast scaling factor. The paper shows k is approximately 0.8. Measurement in MBone in [26] also gives this power law form expression but k is about 0.7. The fact that multicast tree cost is expressed in a power law form and k has a value ranging from 0.7 to 0.8, means that multicast communication can reduces total bandwidth significantly compared with superposition of unicast connections. Phillips et al. [28] try to explain this scaling law from mathematical analysis. Adams et al. [29] show a different use of multicast measurement. They propose a way to measure internal loss or delay behavior in the entire Internet by making use of end-to-end multicast measurement. Multicast traffic is used for just as artificially generated traffic for measurement. C´ aceres et al. [30] also propose the way to infer internal network characteristics by measuring end-to-end multicast traffic. This approach is one of the possible ways to make use of multicast measurement to network design or dimensioning. 2.6 Streaming Service Streaming service is one of the most promising services

provided by multicast communications. In Mbone, several streaming programs have been supported. For multicasting of streaming data, QoS (quality of service) is an important technical issue. For QoS control, a sender should know about receiving status of receivers in a corresponding multicast group. RTP (Real-Time Protocol) [7] and RTCP (RTP Control Protocol) [7] provide a framework for controlling multimedia streams over IP networks. RTP is used for transmission of multimedia streaming data. For multimedia traffic, synchronization of arrival data is necessary at a receiver because packets are delayed independently and delay jitter in a network disturbs arrival timing of packets. To maintain synchronous timing of streaming data, delay jitter should be absorbed by a playout mechanism at a receiver. In RTP, multimedia data is transmitted in an RTP packet and a packet header includes timestamp and sequence number. These information in a header is used for synchronous playout at a receiver. RTCP is a companion protocol of RTP. In RTCP, a sender and all receivers send their statistic information as a control packet periodically. When a transmission rate of these control packets is fixed, bandwidth consumed by control packets for a large multicast group may exceed bandwidth used for multimedia streaming data. To improve this scalability problem, RTCP adjusts transmission rate of control packet according to the number of receivers in a multicast group. As described in Sect. 2.1, a sender (and also receivers) has no information about members in a corresponding multicast group. However, in RTCP, all members, i.e. a sender and all receivers, send control packets to a multicast group. These control packets arrive at all members of a multicast group and with reception of these packets each member can estimate total number of members. With this estimated number of members, each member calculates an adequate transmission rate of its control packet. RTCP attempts to regulate total bandwidth for control packets to 5% of all bandwidth used for a streaming session. For QoS control for streaming data, there is another approach, QoS routing [31], [32]. QoS routing is a routing where a path satisfying QoS requirements is tried to be found. It can provide another aspect than rate control in QoS control, but it still includes many technical problems, e.g. cooperation with multicast routing and definition of cost function. 2.7 Deployment Issues Multicast communication is well-known to be a very effective way to disseminate the same information to potentially large number of receivers [26] and IP multicast is the first protocol for realizing network-layer multicasting. And almost commercial routers implement IP multicast and multicast routing protocols. However,

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1759

few ISPs are willing to support IP multicast in their network. Several papers are discussing this deployment issues of IP multicast [8], [23]. They list the following issues for deployment of IP multicast. • Motivation to Deployment of IP Multicast For the source of multicast data and receivers of them, there cannot be seen any advantages for deployment of IP multicast. For them, the fact that the same data is arrived to expected receivers is very important and they do not care about how data is transmitted inside a network. From this viewpoint a network provider should have motivation to deployment of IP multicast. However, they cannot implement IP multicast because of lack of a good service model as described below. • Poor Contents In MBone, no attractive contents have been served. Popular applications in MBone are realtime broadcast service of IETF meeting, NASA events and some audio distribution. • Service Model The concept of multicast group gives scalability to network-layer multicasting but is not suitable for business model of multicasting. For example, the source cannot identify receivers of its providing contents. This prevents the source to collect fee for providing contents. For another example, there is no way to prevent malicious users to send meaningless data to a multicast group. This is because any hosts can send data to multicast group in IP multicast. In the paper, we would like to survey attractive research results for future multicast communications, in the following sections. These researches are trying to address these issues. 3.

Service Model

IP multicast applies multicast group concept to enable a network (a router) managing membership. This service model of multicast group has the following two problems from the viewpoint of communication service. First, it has no explicit way for a source to learn how large multicast group size is. Second, it cannot make an authorized source to send data packets to multicast members. Other hosts, unauthorized sources including malicious users, can send packets to a multicast group. Multicast group concept has also scalability problem from the viewpoint of address allocation. For a single multicast group, a multicast address assigned exclusively to a group from a class D address block is used for multicast data transmission. When two or more multicast groups use the same multicast address simultaneously, multicast data packets sent by different sources arrive at receives and multicast application cannot reconstruct application-layer data.

Recently, some researches investigating new service model for multicast are emerging. Holbrook and Cheriton [33] propose a new service model named EXPRESS (EXPlicitly Requested Single-Source) multicast. In EXPRESS, a source sends a multicast datagram to a channel expressed as a tuple (source address, channel address). Only a host with a source address identified in a tuple (source address, channel address) may send datagram to this channel. A host interested in reception of data sent to a channel specifies an interested channel to a network. Two channels (S1 , C) and (S2 , C) are unrelated even though they have the common destination channel address C. A host subscribing data sent to (S1 , C) does not automatically receive data to (S2 , C). In EXPRESS, a counting protocol, ECMP (EXPRESS Count Management Protocol) is proposed. ECMP is a protocol counting some information related to receivers (e.g. the number of receivers). In ECMP, information sent from receivers are aggregated at each intermediate router on a multicast distribution tree. ECMP provides a way for the source to count the number of receivers in a channel. By using EXPRESS, a receiver can receive multicast data packet only from an authorized source. A channel address can be managed on per-source basis, which resolve address allocation problem of IP multicast. Perlman et al. [34] propose a similar new service model, named Simple Multicast. In Simple Multicast, a group is expressed as a tuple (Core address, Multicast address). A core can be a source or a node close to members of a group, which is slightly different from EXPRESS. Levine et al. [35] evaluate several approaches to new service model of IP multicast. They compare three approaches, filtering, addressing and hybrid approaches. In filtering approach, all data is broadcast to all members and arrived information is filtered by a middleware at an end host of each member according to its interest. In addressing approach, applications are partitioned to multicast addresses of their own, i.e. each application has its own address, and a member only receives data sent to a corresponding multicast address. In hybrid approach, data of several applications is mapped to a common multicast address based on some policy, e.g. receivers’ interests, and filtered at an end host. Simulation results in [35] show that addressing approach is a good one on condition that address space is wide enough to accommodate all applications. When multicast address are a scare resource, hybrid approach is an advantage. Wong et al. [36] propose grouping (clustering) method applicable to hybrid approach. A proposed scheme groups approximately similar sources and receivers from the viewpoint of preference into a common multicast group. Performance evaluation in [36] shows that clustering brings better goodput than when it is not used.

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1760

4.

Reliable Multicast

IP multicast is based on best-effort communication and in IP multicast UDP is generally used for a transport protocol. So, no function for supporting reliability, such as retransmission control and congestion control, is implemented in IP multicast. This feature regulates applications of IP multicast to real-time one. When reliability is supported on IP multicast, new type of applications can emerge and encourage deployment of IP multicast. These promising applications include software distribution, file distribution and distribution of stock quote. In IETF, discussion of reliable multicast communication protocols which support reliability on IP multicast, started in early 1990’s. Main functions necessary for reliability support are retransmission control and congestion control. We devote the next section for discussion about congestion control including not only reliable multicast but also real-time multicast. In this section, we focus on retransmission control issues. There are two approaches for retransmission control, using feedback information and without it (Fig. 5). For a feedback approach, retransmission control can be categorized into the following three, ACK-based, NAKbased and FEC+feedback. In the early stage of reliable multicast research, applicability of an ACK-based protocol and a NAK-based protocol was discussed. In point-to-point communications, burden for the source and the receiver is almost the same. However, in multicast communications, the burden for the sender is high because all feedback information concentrates to the sender. This concentration of feedback at the sender may cause performance degradation, which is called feedback implosion. For an ACK-based approach, all receivers send an ACK to the source, so ACK implosion is a serious problem. Paul et al. [37] propose a hierarchical approach, RMTP (Reliable Multicast Transport Protocol), to resolve ACK implosion problem. In RMTP, some special nodes called DR (Designated Receiver) are located on the path of a multicast distribution tree. This DR manages some receivers in its downstream direction. A DR aggregates ACKs from these receivers and forwards only one ACK to the source (or to neighboring DR in its upward direction). Aggregation mechanism decreases the number of arrived ACKs to the source,

Fig. 5

Retransmission control for reliable multicast.

which brings scalability to RMTP. For a NAK-based approach, only receivers suffering packet loss send a NAK to the source, so the number of feedback packets should be smaller than an ACKbased approach. Both approaches are mathematically analyzed and evaluated from the viewpoint throughput performance in [38] and from the viewpoint of delay performance in [39]. Performance evaluation results in these papers show that a NAK-based approach has better scalability than an ACK-based one. Simulation results in [40] show that an ACK-based approach has worse scalability even though a hierarchical structure is applied. Even though a NAK-based protocol has better scalability than an ACK-based one, NAK implosion may cause performance degradation when multicast group size is large. To resolve this implosion problem, several approaches have been proposed. SRM (Scalable Reliable Multicast) [41] applies a timer-based approach. Whenever a receiver detects a packet loss, it schedules a pending NAK transmission at a randomly chosen point of time in the future. If the receiver receives a NAK generated by another receiver, it cancels its NAK transmission. This mechanism is called NAK suppression. When a timer expires without receiving a NAK from other receivers, the receiver multicast a NAK. With this NAK suppression mechanism, the number of generated NAKs is significantly reduced [39], which brings good scalability. For this timer approach, several papers have discussed about how to decide a timer length [42], [43]. Another approach for resolving NAK implosion is local recovery. In local recovery approach, a receiver receiving a packet correctly initiates retransmission. Nonnenmacher et al. [44] compare sender-based error recovery (they call centralized error recovery in the paper) and local recovery (distributed error recovery) and show that local recovery outperforms senderbased error recovery from the viewpoint of average delay and bandwidth consumption. Performance comparison also shows that local recovery with parity retransmission (see description of FEC below) gives better performance than local recovery with ARQ. Kasera et al. [45] compare two approaches of local recovery, serverbased and receiver-based, and shows server-based approach where designated servers initiating retransmission are located in the network has better performance. In local recovery, configuration of groups among whose members local recovery is tried, is very important. This group configuration issues are discussed in [46]. The third approach for retransmission using feedback information is FEC+feedback. Conventionally, FEC technology is applied for recovery caused bit error in telecommunication field. Rizzo [47] shows FEC technology can be applied to recovery of erasure, missing packets in a stream, in reliable multicast. He also shows a coding method using Vandermonde matrix whose computation time for coding is short enough for

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1761

practical use. FEC technology introduces redundant packets for error recovery to be distributed to members, which may lead to bandwidth consumption. So, location where FEC is applied is very important problem. Nonnenmacher et al. [48] discuss where to use FEC technology. Noguchi et al. [49] claim FEC to be applied at links close to the source. Packet loss probability on links close to the source is reported to be high [24] and a packet loss here means almost members are suffered by this shared loss. So, they show that FEC applied locally to these links brings significant performance improvement. Nonnenmacher et al. [50] propose an interesting way to recovery a lost packet in multicast communications. When packet loss pattern at each receiver is different, each receiver sends back the number of lost packets in a predefined block and the sender multicast this number of recovery packets, called parity packets. Each receiver can recover a block of packets when these parity packets arrives correctly. The other way than using feedback information is FEC where only FEC is used and no feedback information is sent back to the sender. Digital Fountain [51] and Fcast [52] are examples of this approach. Both of them make use of Tornado Codes with which a large file can be coded. The source repeats transmission of file and redundant packets. A receiver joins a multicast group whenever it likes and leaves when it receives enough packets necessary to recover a transmitted file. Recently, a new approach for resolving feedback implosion problem, a network support approach is widely discussed in a multicast research field. Technical background for enabling network support is active network technology [53], [54]. Network support for reliable multicast includes NAK aggregation and caching. In NAK aggregation, a router on the path of feedback information (NAKs) only forwards a first-arrived NAK to the source and discards NAKs arrived later. A router marks links from which a NAK arrives. When a retransmitted packet arrives at a router, it replicates and forwards a retransmitted packet only to marked links. With this operation, the number of NAKs arrived at a source is significantly reduced and bandwidth wasted for redundant retransmission is also reduced. Another way for network support is caching. When a router receives a retransmitted packet, a router stores it in its local cache. When a retransmitted packet is also lost at a receiver, retransmission of a packet is initiated from this cache. PGM (Pragmatic General Multicast) [55] and ARM (Active Reliable Multicast) [56] are examples of network support approach. In a network support approach, it is very important to investigate how much percentile of routers which can provide a network support function are necessary for obtaining good performance. Performance evaluation in [57] shows that a network support approach outperforms end-to-end approaches when 20% of routers are equipped with a network support function.

5.

Congestion Control

Congestion control is an essential element of communication protocols in the Internet because the Internet is a world-wide network shared with large number of users. IP multicast does not implement congestion control because it uses UDP in the transport layer. In this section, future direction of multicast congestion control is discussed by introducing remarkable research results in this field. Multicast congestion control can be categorized into a source-based approach and a receiver-based approach. In a source-based approach, the source regulates its transmission rate by feedback information sent back from receivers. In a receiver-based approach, the source divides information into several layers and sends them in different multicast groups. A receiver-based approach, in general, uses this layered transmission. The first receiver-based approach, RLM (Receiverdriven Layered Multicast) is proposed by McCanne et al. [58]. In RLM, the source has no active operation, just transmitting layered data to each multicast group. The receiver searches its optimal rate of data subscription by joining and leaving groups. When a receiver detects packet loss and quality degradation, it can learn that its subscription is too high and leaves the highest subscription group. A receiver adds groups when it experiences no congestion. Recently, co-existence of multicast session with unicast sessions is widely discussed. In the Internet, TCP is widely used, e.g. HTTP, SMTP and FTP uses TCP as a congestion control. In order to prevent a multicast session from exploiting network resources, multicast congestion control should share congested resources fairly with TCP sessions. This kind of fairness issue is called TCP friendly. As a TCP friendly congestion control in a receiver-based approach, Vicisano et al. [59] propose a layered multicast congestion control. Transmission rate of each layer increases exponentially, for example twice. When a receiver leaves from a goup, receiving data rate decreases exponentially. This follows multiplicative decrease behavior of TCP. However, additive increase nature cannot be followed by this operation. Byers et al. [60] propose Fine-grained Layered Multicast, where transmission rate of each layer is divided into finer grain. This enables additive increase of transmission rate by joining a one-level higher layer. For a source-based approach, loss path multiplicity problem is reported to be a serious problem [61]. When loss of the same packet is suffered at multiple receivers and transmission rate of the source is regulated by loss indications, e.g. NAKs, sent from these receivers, transmission rate of the source is too much regulated. This leads to serious degradation of throughput performance of a multicast session. To avoid loss path multiplicity problem, a nominee approach is generally applied to

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1762

a source-based approach. In a source-based approach, transmission rate of the source is regulated by the receiver of the worst throughput, i.e. the receiver suffered by congestion in the network. From this observation, a nominee is selected as the receiver of the worst throughput. Rizzo [62] proposes pgmcc based on these ideas. In pgmcc, a nominee (called an acker in [62]) sends a NAK when it detects a loss of packet. In this NAK, receiver’s RTT (Round Trip Time) and packet loss rate, p, is included as a feedback information. When a source receives these NAKs sent by receivers suffered by a packet loss, it elects the receiver of the worst TCP throughput as a nominee. TCP throughput (T ) is reported to be simply expressed in the following form [63], [64], T ∝

1 √ . RT T p

(2)

From this equation, the worst throughput receivers can be elected as the receiver which has the lowest value √ of RT T p. After selecting a nominee, an ACK-based window flow control is applied between the source and the selected receiver. Feedback implosion problem is prevented because only the selected receiver sends an ACK to the source. Kasera et al. [65] propose a similar congestion control. They applies active service for gathering throughput information. In their proposal, all receivers send their measured RTT and packet loss rate to the source. A server attached to a router inside a network is introduced. When this server on the path to the source receives these measured information, it only forwards information with the highest value of the product of RTT and packet loss rate, i.e. information of the worst throughput node. It has better scalability than pgmcc because only one feedback information is sent back to the source. These two proposals above apply window-based congestion control with an ACK sent back from the elected receiver, a nominee. Thus, they have TCP-friendly nature. For multicast congestion control, fairness issues are very important. This is because one of the most important purposes of congestion control is fair-share of congested resources. There have been proposed several fairness concepts, thus far. These can be categorized into inter-session fairness and intra-session fairness. Inter-session fairness is fairness between sessions. For multicast communications, two types of inter-session fairness can be defined, fairness between multicast and unicast and between multicast and multicast. Intrasession fairness is fairness between receivers inside the same multicast session. Intra-session fairness can be defined only for a multicast session. TCP friendly discussed above is one of inter-session fairness between a unicast session and a multicast one. Yamamoto et al. [66] propose a new multicast congestion control for reliable multicast which improves intra-session fairness. To improve intra-session fairness, packet reception rate should differ for each receiver, so a router at a branch-

ing point of multicast tree may forward packets at different rates to its downstream links. For real-time application, a router just discards packets. However, for reliable multicast, packet discarding at a router may cause overhead of retransmission. So, they introduce a new function at a router, storing data, and propose a new congestion control also achieving TCP friendliness. TCP friendly is a microscopic fairness because it only focuses on fair share of link bandwidth with unicast and multicast traffic. From the macroscopic viewpoint, multicast traffic brings great benefits to the network because it can effectively distribute the same amount of information to multiple receivers with consumpting less network resources. From this viewpoint, another idea of fairness, giving slightly prioritized resource to multicast users, is now emerging. Wang and Schwartz [67] introduce bounded fairness concept. In bounded fairness concept, a multicast session sharing a bottleneck link with TCP sessions is said to fairly use bandwidth of bottleneck when throughput of a multicast session satisfies the following equation: a × ThroughputT CP < Throughputmulticast < b×ThroughputT CP . When b is larger than 1, preferable resource can be assigned to a multicast session in this concept. Legout et al. [68] discuss larger bandwidth allocation to a multicast session and propose bandwidth allocation based on logarithmic function of the number of receivers downstream of the bottleneck. Yamamoto et al. [69] propose an active queue management policy which adjusts packet loss probability of multicast sessions according to the number of receivers downstream of the bottleneck. Shapiro et al. [70] also discuss prioritized resource assignment to a multicast session from the viewpoint of assigning optimization-based congestion control concept to multicast. To give an incentive to use multicast, multicast sessions should be given priority to unicast sessions. This seems to bring unfair resource sharing to unicast users, but more efficient usage of network resource brought by multicast sessions will also satisfy requirement of unicast users [69]. From this viewpoint, fairness issues between unicast and multicast should be an interesting research field in future. 6.

Secure Multicast

Security is one of the most important technical issues in the current Internet. Especially, for multicast communication, security is very important because disseminated information on IP multicast session can be easily received by any host. Multicast communication supporting security is called secure multicast. In secure multicast, key management is one of the most important technical problems. Information to be disseminated is encrypted by a traffic encryption key called a group key. A group key is shared by all receives. This group key should be encrypted and distributed to all receivers. Each receiver should have a

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1763

Fig. 6

Key graph (d = 3).

different key of encryption for distributing a group key because receivers may dynamically join or leave a multicast group independently. Wong et al. [71] propose a hierarchical key management method, called key graph. In a key graph approach, a special server, called a key server, is introduced. This key server manages a group key and keys for encryption of a group key by using a key graph. Figure 6 shows an example of a key graph for a multicast group of 9 receivers. One individual key at a leaf of a key graph is assigned to each receiver. Intermediate nodes in a key graph are related to auxiliary keys which are used for encryption of a group key. Each receiver knows all keys on a path from the root to a corresponding leaf. For example, a receiver related to an individual key k1 knows keys k1 , k123 and k1−9 . Data packets are encrypted by a group key k1−9 and disseminated to all 9 members. When a receiver corresponding to a key k3 leaves from a multicast group, all keys known to this receiver, i.e. keys k123 and k1−9 , should be changed. When a group key k1−9 and an aux  and k123 , respectively, iliary key k123 is changed to k1−9 a key server informs this change of keys to all receivers related to this change. It informs a new auxiliary key  to receivers corresponding to k1 and k2 with enk123  with a key k1 and k2 , respectively. A new crypting k123  is distributed to receivers k1 and k2 with group key k1−9  . For receivers encrypting by a new auxiliary key k123 k4 - k6 and k7 - k9 , a group key k1−9 is encrypted by an auxiliary key k456 and k789 . Hierarchical key structure reduces total number of encryption at a key server, for example only one encryption is needed for 3 receivers corresponding to k4 -k6 . Wong et al. show key graph approach incurs o(log n) overhead, where n is the number of group members. Chang et al. [72]also propose a similar hierarchical structure of key management. A main difference from a key graph approach is making use of Boolean function minimization techniques. This process of changing keys initiated by a multicast member’s leaving or joining is called rekeying. Rekeying is necessary for keeping both of forwardsecrecy membership policy and backward-secrecy membership policy. Forward-secrecy membership policy needs a condition that a receiver leaving a multicast group cannot receive data correctly after its leaving.

Backward-secrecy membership policy requires that a receiver joining a multicast group cannot decrypt data packets sent before its joining. Even though a hierarchical structure is applied, a key server will be a performance bottleneck of a secure multicast because key management load increases with the number of members in a multicast group. To resolve this scalability problem, several approaches have been proposed. These approaches can be categorized into two approaches, distributing load in time axis and in spatial axis. Batch Rekeying [73] is one of researches in the former category. In Batch Rekeying, keys are not changed whenever a multicast group member joins or leaves. Keys are changed periodically and rekeying necessary for several members’ leaving and joining are processed in a batch style. Batch processing of rekeying reduces key management load of the key server. Yang et al. [74] evaluate batch rekeying with reliable multicast transmission of rekeying information. Time interval of periodical batch rekeying is an important parameter for batch rekeying and is evaluated in detail. For the latter approach, distributing load in spatial axis, Mittra [75] proposes a framework for scalable secure multicast, called Iolus. In Iolus, special servers, called GSI (Group Security Intermediaries) are located inside a network. At GSI, encrypted data packet is once decrypted. This decrypted data is once more encrypted and transmitted to another domain. This decryption and encryption at a GSI means key management domain is divided and joining or leaving of a member in one domain does not affect anything to key management in another domain, which reduces key management load in each domain. Banerjee and Bhattacharjee [76] propose another scheme of the latter approach, a clustering method. In their clustering method, each receiver is mapped to a leaf of a hierarchical clustering structure. In each cluster, a representative, called a cluster leader, is selected and manages keys inside a cluster. Joining and leaving of a member affects only to other nodes inside a cluster, which leads to localization of rekeying. Secure multicast in wireless communications is one of the most interesting future research fields because security is more important for wireless communications. DeCleene et al. [77] treat a handoff problem for secure multicast in wireless communications. They compare several approaches for rekeying which is applied when a member moves to another area. Performance evaluation results in [77] show delayed rekeying where a member moving to another area holds an old key managed in a previous area for some time period, shows good performance. 7.

Application-Level Multicast

One of the technical difficulties for deployment of IP

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1764

Fig. 7

Application-level multicast.

multicast is requirement of replacement of all routers to multicast-capable ones. Application-level multicast is an approach resolving this problem by shifting networklayer function to application-layer, i.e. application layer operates routing and making a replication at a branching point. IP datagrams are sent to a neighboring host in a virtual addressing space determined by application level routing. This transmission of IP datagram uses unicast transmission, which means there is no necessity for multicast-capable routers in a network. Figure 7 illustrates disadvantage of applicationlevel multicast. In IP multicast (Fig. 7(a)), the source (S) sends a multicast datagram destined to a multicast address. When this datagram arrives at a router, a router at a branching point of a multicast tree makes a replica of this datagram and forwards them. In application-level multicast depicted in Fig. 7(b), the source first transmits a unicast datagram to a host A. A host A sends to a host C on a unicast channel and a host C sends a unicast datagram to a host B. By these operations in an application layer, all receivers, A, B and C, can receive the same information. In this case, on a link between two routers, the same datagrams appear multiple-times, which never occurs in networklayer multicast. This is a well-known disadvantage of application-level multicast. Link stress which is defined as the number of identical copies of a packet carried by a link and relative delay penalty defined as the ratio of the delay between two members along the overlay to the unicast delay, are used as performance metric for evaluating this disadvantage of application-level multicast. End System Multicast [78] is the first proposal for application-level multicast. They develop a protocol for End System Multicast, called Narada. In End System Multicast, each member in a multicast group keeps member information of all other members. Narada constructs a mesh at first and the shortest spanning tree on this mesh. Data packets are transmitted on the constructed tree where each intermediate node (host) receives them up to an application layer and forwards them to a neighboring node (nodes) by making replica of them when necessary. Scattercast [79] is a similar approach for application-level multicast. The only difference from End System Multicast is that Scattercast introduces network agents named SCX (ScatterCast proXies). At first, a mesh is constructed among

SCXs and routing on a mesh is DVMRP. In these approaches, each member should keep information of all other members in order to make a mesh. This leads to significant overhead for managing group membership. Thus, these two approaches are suitable for small size multicast, e.g. teleconferencing, and are not applicable to multicast with large number of receivers. Improvement for scalability is tried in several approaches. Bayeux [80] proposes a scalable routing technique for application-level multicast. Bayeux is an expansion of an application layer routing technique for unicast, called Tapestry [81], to multicast communications. In Bayeux, each member has its name independent of its location, in the form of random fixed-length bit-sequences. Neighbors of a node in this virtual address space are defined in multiple levels according to its assigned virtual address. When a new node joins in a multicast group, neighbor information is transmitted from this joined node to the source by relaying to a neighboring node on the path to the source. This transmission of neighbor information makes a routing state in every intermediate hosts on the path. Routing tables in Bayuex have size logarithmically proportionally to the network size, so Bayeux has better scalability than End System Multicast and Scattercast. Ratnasamy et al. [82] propose more scalable routing technique for application-level multicast. Routing in their approach makes use of virtual address space, named CAN (Content-Addressable Network) [83]. CAN uses Cartesian space for its routing. Each node in a group should keep neighbor information in an address space of CAN. Routing tables in CAN have size of dimension of CAN address space independent of the network size and the group size, which leads to higher scalability. Research activities on application-level multicast described above try a distributed management approach, i.e. there is assumed to be no centralized control cite. ALMI (Application Level Multicast Infrastructure) [84] is categorized in a centralized approach. In ALMI, a centralized controller named SC (Session Controller) manages all members and constructs multicast tree. When a receiver joins or leaves, it informs its joining or leaving to SC and the SC re-constructs a multicast tree (minimum spanning tree). This approach has poor scalability due to significant overhead for group management. Stoica et al. [85] propose Internet Indirection Infrastructure (i3), a general P2P model including application multicast as a subset of its service composition. A service model of i3 is a randezvous-based communication, in which a network is defined as a platform connecting a sender’s interest and a receiver’s interest. i3 can support not only multicast but also anycast and mobility. Application-level multicast seems to be an easy way to implement multicast communication in the current Internet. However, it is hard to be used widely

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1765

in the Internet due to the following problems. First, each data packet is received at intermediate end-hosts, so application-level multicast has security problem. In IP multicast, each data packet is received, forwarded and replicated at a trusted network element, a router. Second, robustness for failure of elements in a multicast tree is also a serious problem. In IP multicast, when a network element, e.g. a router, fails, a routing algorithm will recover a multicast tree. Third problem, and the last one, is performance penalty, e.g. link stress and delay penalty. Almost research activities in applicationlevel multicast try to reduce these performance penalties. However, it is difficult to make it as small as IP multicast. Thus, this approach should be treated as a tentative solution for multicast deployment. 8.

Conclusions

Multicast communication is an effective way to disseminate the same information to large number of receivers. IP multicast is the first internet protocol which achieves network-layer multicasting. IP multicast has not widely deployed in a commercial-based network because IP multicast has some difficulties for supporting business model for multicast. These difficulties include congestion control, reliability support and security. Even though IP multicast itself has these technical difficulties, network-layer multicast should be necessary in the Internet because dissemination of the same data to multiple receivers, such as real-time multicast, file distribution and software distribution, will be the most promising application in the Internet and network-layer multicast is the most effective way to support this kind of application. A lot of research activities have been trying to resolve these technical problems of IP multicast in the last decade. The paper selects and surveys interesting research activities and discusses future directions of multicast communications. We believe that it is very important to make IP multicast attractive not only to network providers but also end-users. For network providers, multicast itself is very attractive because it enables dissemination of data to large number of receivers with effective usage of network resources. For end-users, they only care about whether data transmitted from the source reaches to all members and does not care about how they are transmitted in a network. So, it is more important to make IP multicast attractive to end-users. From this viewpoint, research activities in the direction of giving slight priority to multicast to unicast is the most promising way to accelerate deployment of IP multicast. Further research for resolving technical problems of IP multicast including one described above are desirable and now being progressed around the world.

References [1] S. Deering, “Host extensions for IP multicasting,” IETF RFC 1112, Aug. 1989. [2] S. Deering and D. Cheriton, “Multicast routing in datagram inter-networks and extended LANs,” ACM Trans. Comput. Syst., vol.8, no.2, pp.85–110, May 1990. [3] S. Casner and S. Deering, “First IETF Internet audiocast,” ACM Computer Communication Review, vol.22, no.3, pp.92–97, July 1992. [4] D. Waitzmann, C. Partridge, and S. Deering, “Distance vector multicast routing protocol,” IETF RFC 1075, Nov. 1997. [5] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, G. Liu, and L. Wei, “PIM architecture for wide-area multicast routing,” IEEE/ACM Trans. Netw., vol.4, no.2, pp.153–162, April 1996. [6] J. Moy, “Multicast extensions to OSPF,” IETF RFC 1584, March 1994. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A transport protocol for real-time applications,” IETF RFC 1889, Jan. 1996. [8] C. Diot, B. Levine, B. Lyles. H. Kassem, and D. Balensiefen, “Deployment issues for the IP multicast service and architecture,” IEEE Netw., vol.14, no.1, pp.78–88, Jan. 2000. [9] S. Hanna, B. Patel, and M. Shah, “Multicast address dynamic client allocation protocol (MADCAP),” IETF RFC 2730, Dec. 1999. [10] W. Fenner, “Internet group management protocol, Version 2,” IETF RFC 2236, Nov. 1997. [11] B. Cain, S. Deering, B. Fenner, I. Kouvelas, and A. Thyagarajan, “Internet group management protocol, Version 3,” IETF Internet Draft, draft-ietf-idmr-igmp-v311.txt, May 2002. [12] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, and L. Wei, “Protocol independent multicast version 2 dense mode specification,” IETF Internet Draft, draft-ietf-pim-v2-dm-03.txt, June 1999. [13] A. Adams, J. Nicholas, and W. Siadak, “Protocol independent multicast—Dense mode (PIM-DM): Protocol specification (revised),” IETF Internet Draft, draft-ietf-pim-dmnew-v2-01.txt, Feb. 2002. [14] J. Moy, “OSPF version 2,” IETF RFC 1583, March 1994. [15] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, “Protocol independent multicast—Sparse mode (PIM-SM): Protocol specification (revised),” IETF Internet Draft, draftietf-pim-sm-v2-new-05.txt, March 2002. [16] A. Ballardie, P. Francis, and J. Crowcroft, “Core based trees (CBT): An architecture for scalable multicast routing,” Proc. ACM SIGCOMM’95, pp.85–95, Cambridge, MA, U.S.A., Aug. 1995. [17] A. Ballardie, “Core based trees (CBT) multicast routing architecture,” IETF RFC 2201, Sept. 1997. [18] A. Ballardie, “Core based trees (CBT Version 2) multicast routing—Protocol specification,” IETF RFC 2189, Sept. 1997. [19] S. Kumar, P. Radoslavov, D. Thaler, C. Alaettinoglu, D. Estrin, and M. Handley, “The MASC/BGMP architecture for inter-domain multicast routing,” Proc. ACM SIGCOMM’98, pp.93–104, Vancouver, Canada, Sept. 1998. [20] D. Thaler, “Border gateway multicast protocol (BGMP): Protocol specification,” IETF Internet Draft, draft-ietfbgmp-spec-03.txt, June 2002. [21] W. Fenner and S. Casner, “A ‘traceroute’ facility for IP multicast,” IETF Internet Draft, draft-ietf-idmrtraceroute-ipm-04.txt, March 1999.

IEICE TRANS. COMMUN., VOL.E86–B, NO.6 JUNE 2003

1766

[22] D. Makofske and K. Almeroth, “MHealth: A real-time graphical multicast monitoring tool,” Proc. Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV’99), Basking Ridge, U.S.A., June 1999. [23] K. Almeroth, “A long-term analysis of growth and usage patterns in the multicast backbone (MBone),” Proc. IEEE INFOCOM 2000, pp.824–833, Tel Aviv, Israel, March 2000. [24] M. Yajnik, J. Kurose, and D. Towsley, “Packet loss correlation in the MBone multicast network,” Proc. IEEE Global Internet’96, pp.94–99, London, UK, Nov. 1996. [25] M. Handley, “An examination of MBone performance,” USC/ISI Research Report, ISI/RR-97-450, Jan. 1997. [26] R. Chalmers and K. Almeroth, “Modeling the branching characteristics and efficiency gains in global multicast trees,” Proc. IEEE INFOCOM 2001, pp.449–458, Anchorage, U.S.A., April 2001. [27] J. Chuang and M. Sirbu, “Pricing multicast communications: A cost-based approach,” Telecommunication Systems, vol.17, no.3, pp.281–297, July 2001. [28] G. Phillips, S. Shenker, and H. Tangmunarunkit, “Scaling of multicast trees: Comments on the Chuang-Sirbu scaling law,” Proc. ACM SIGCOMM’99, pp.41–52, Cambridge, U.S.A., Aug. 1999. [29] A. Adams, T. Bu, T. Friedman, J. Horowitz, D. Towsley, R. Caceres, N. Duffield, F. Lo Presti, S. Moon, and V. Paxson, “The use of end-to-end multicast measurement for charactrerizing internal network behavior,” IEEE Commun., vol.38, no.5, pp.152–158, May 2000. [30] R. C´ aceres, N. Duffield, J. Horowitz, and D. Towsley, “Multicast-based inference of network-internal loss characteristics,” IEEE Trans. Inf. Theory, vol.45, no.7, pp.2462– 2480, Nov. 1999. [31] B. Wang and J. Hou, “Multicast routing and its QoS extension: Problems, algorithms, and protocols,” IEEE Netw., vol.14, no.1, pp.22–36, Jan. 2000. [32] A. Striegel and G. Manimaran, “A survey of QoS multicasting issues,” IEEE Commun., vol.40, no.6, pp.82–87, June 2002. [33] H. Holbrook and D. Cheriton, “IP multicast channel: EXPRESS support fro large-scale single-source applications,” Proc. ACM SIGCOMM’99, pp.65–78, Cambridge, U.S.A., Aug. 1999. [34] R. Perlman, C. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, J. Thoo, and M. Green, “Simple multicast: A design for simple, low-overhead multicast,” IETF Internet Draft, draft-perlman-simle-multicast-03.txt, Oct. 1999. [35] B. Levine, J. Crowcroft, C. Diot, J. Garcia-Luna-Acceves, and J. Kurose, “Consideration of receiver interest for IP multicast delivery,” Proc. IEEE INFOCOM 2000, pp.470– 479, Tel-Aviv, Israel, March 2000. [36] T. Wong, R. Katz, and S. McCanne, “An evaluation of preference clustering in large-scale multicast applications,” Proc. IEEE INFOCOM 2000, pp.451–460, Tel-Aviv, Israel, March 2000. [37] S. Paul, K. Sabnani, J. Lin, and S. Bhattacharyya, “Reliable multicast transport protocol (RMTP),” IEEE J. Sel. Areas Commun., vol.15, no.3, pp.407–421, April 1997. [38] S. Pingali, J. Kurose, and D. Towsley, “A comparison of sender-initiated and receiver-initiated reliable multicast protocols,” Proc. 1994 ACM International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS’94), pp.221–230, May 1994. [39] M. Yamamoto, J. Kurose, D. Towsley, and H. Ikeda, “A delay analysis of sender-initiated and receiver-initiated reliable multicast protocols,” Proc. IEEE INFOCOM’97,

pp.480–488, Kobe, April 1997. [40] K. Yamamoto, M. Yamamoto, and H. Ikeda, “Performance evaluation of ACK-based and NAK-based flow control mechanisms for reliable multicast communications,” IEICE Trans. Commun., vol.E84-B, no.8, pp.2313–2316, Aug. 2001. [41] S. Floyd, V. Jacobson, C. Liu, S. McCanne, and L. Zhang, “A reliable multicast framework for light-weight sessions and application level framing,” IEEE/ACM Trans. Netw., vol.5, no.6, pp.784–803, Dec. 1997. [42] M. Grossglauser, “Optimal deterministic timeouts for reliable scalable multicast,” Proc. IEEE INFOCOM’96, pp.1425–1432, San Francisco, U.S.A., March 1996. [43] J. Nonnenmacher and E. Biersack, “Optimal multicast feedback,” Proc. IEEE INFOCOM’98, pp.964–971, San Francisco, U.S.A., March 1998. [44] J. Nonnenmacher, M. Lacher, M. Jung, E. Biersack, and G. Carle, “How bad is reliable multicast without local recovery?” Proc. IEEE INFOCOM’98, pp.972–979, San Francisco, U.S.A., March 1998. [45] S. Kasera, J. Kurose, and D. Towsley, “A comparison of server-based and receiver-based local recovery approaches for scalable reliable multicast,” Proc. IEEE INFOCOM’98, pp.988–995, San Francisco, U.S.A., March 1998. [46] M. Yamamoto, T. Hashimoto, and H. Ikeda, “Performance evaluation of local recovery group configuration in reliable multicast,” IEICE Trans. Commun., vol.E83-B, no.12, pp.2675–2684, Dec. 2000. [47] L. Rizzo, “Effective erasure codes for reliable computer communication protocols,” ACM Computer Communication Review, vol.27, no.2, pp.24–36, April 1997. [48] J. Nonnenmacher and E. Biersack, “Reliable multicast: Where to use FEC,” Proc. IFIP 5th International Workshop on Protocols For High-Speed Networks, pp.134–148, Sophia Antipolis, France, Oct. 1996. [49] T. Noguchi, M. Yamamoto, and H. Ikeda, “Reliable multicast protocol applied local FEC,” Proc. IEEE ICC 2001, pp.2348–2353, Helsinki, Finland, June 2001. [50] J. Nonnenmacher, E. Biersack, and D. Towsley, “Paritybased loss rocovery for reliable multicast transmission,” Proc. ACM SIGCOMM’97, pp.289–299, Canne, France, Sept. 1998. [51] J. Byers, M. Luby, M. Mitzenmacher, and A. Rege, “A digital fountain approach to reliable distribution of bulk data,” Proc. ACM SIGCOMM’98, pp.56–67, Vancouver, Canada, Sept. 1998. [52] J. Gemmel, J. Gray, and E. Schooler, “Fcast multicast file distribution,” IEEE Netw., vol.14, no.1, pp.58–68, Jan. 2000. [53] D. Tennenhouse and D. Wetherall, “Towards an active network architecture,” ACM Computer Communication Review, vol.26, no.2, pp.5–18, April 1996. [54] M. Yamamoto, “A survey of active network technology,” IEICE Trans. Commun. (Japanese Edition), vol.J84-B, no.8, pp.1401–1412, Aug. 2001. [55] T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, and L. Vicisano, “PGM reliable transport protocol specification,” IETF RFC 3208, Dec. 2001. [56] L. Lehman, S. Garland, and D. Tennenhouse, “Active reliable multicast,” Proc. IEEE INFOCOM’98, pp.581–589, San Francisco, U.S.A., March 1998. [57] M. Yamamoto, M. Yamaguchi, T. Hashimoto, and H. Ikeda, “Performance evaluation of reliable multicast communication protocol with network support,” Proc. IEEE GLOBECOM 2000, pp.1736–1741, San Francisco, U.S.A., Nov.

YAMAMOTO: MULTICAST COMMUNICATIONS—PRESENT AND FUTURE

1767

2000. [58] S. McCanne, V. Jacobson, and M. Vetterli, “Receiverdriven layered multicast,” Proc. ACM SIGCOMM’96, pp.117–130, Stanford, U.S.A., Aug. 1996. [59] L. Vicisano, J. Crowcroft, and L. Rizzo, “TCP-like congestion control for layered multicast data transfer,” Proc. IEEE INFOCOM’98, pp.996–1003, San Francisco, U.S.A. March 1998. [60] J. Byers, M. Luby, and M. Mitzenmacher, “Fine-grained layered multicast,” Proc. IEEE INFOCOM 2001, pp.1143– 1151, Anchorage, U.S.A., April 2001. [61] S. Bhattacharyya, D. Towsley, and J. Kurose, “The loss path multiplicity problem in multicast congestion control,” Proc. IEEE INFOCOM’99, pp.856–863, New York, U.S.A., March 1999. [62] L. Rizzo, “pgmcc: A TCP-friendly single-rate multicast congestion control scheme,” Proc. ACM SIGCOMM 2000, pp.17–28, Stockholm, Sweden, Aug. 2000. [63] M. Mathis, J. Semke, K. Mahdavi, and T. Ott, “Macroscopic behavior of the TCP congestion avoidance algorithm,” ACM Computer Communication Review, vol.27, no.3, pp.67–82, July 1997. [64] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, “Modeling TCP throughput: A simple model and its empirical validation,” Proc. ACM SIGCOMM’98, pp.303–314, Vancouver, Canada, Sept. 1998. [65] S. Kasera, S. Bhattacharyya, M. Keaton, D. Kiwior, J. Kurose, D. Towsley, and S. Zabele, “Scalable fair reliable multicast using active services,” IEEE Netw., vol.14, no.1, pp.48–57, Jan. 2000. [66] M. Yamamoto and M. Yamaguchi, “Congestion control scheme for reliable multicast improving intra-session fairness with network support,” SPIE ITCom 2002 (Quality of Service over Next-Generation Internet), pp.98–105, Boston, U.S.A., Aug. 2002. [67] H. Wang and M. Schwartz, “Achieving bounded fairness for multicast and TCP traffic in the Internet,” Proc. ACM SIGCOMM’98, pp.81–92, Vancouver, Canada, Aug. 1998. [68] A. Legout, J. Nonnenmacher, and E. Biersack, “Bandwidth allocation policies for unicast and multicast flows,” Proc. IEEE INFOCOM’99, pp.254–261, New York, U.S.A., March 1999. [69] K. Yamamoto and M. Yamamoto, “Packet discarding method considering the number of downstream multicast receivers,” IEICE Technical Report, NS2002-137, Oct. 2002. [70] J. Shapiro, D. Towsley, and J. Kurose, “Optimization-based congestion control for multicast communications,” IEEE Commun., vol.40, no.9, pp.90–95, Sept. 2002. [71] C. Wong, M. Gouda, and S. Lam, “Secure group communications using key graphs,” Proc. ACM SIGCOMM’98, pp.68–79, Vancouver, Canada, Aug. 1998. [72] I. Chang, R. Engel, D. Kandlur, D. Pendarakis, and D. Saha, “Key management for secure Internet multicast using Boolean function minimization techniques,” Proc. IEEE INFOCOM’99, pp.689–698, New York, U.S.A., March 1999. [73] S. Setia, S. Koussih, S. Jajodia, and E. Harder, “Kronos: A scalable group re-keying approach for secure multicast,” Proc. IEEE Symposium on Security and Privacy 2000, pp.215–228, Berkley, U.S.A., May 2000. [74] Y. Yang, X. Li, X. Zhang, and S. Lam, “Reliable group rekeying: A performance analysis,” Proc. ACM SIGCOMM 2001, pp.27–38, San Diego, U.S.A., Aug. 2001. [75] S. Mittra, “Iolus: A framework for scalable secure multicasting,” Proc. ACM SIGCOMM’97, pp.277–288, Cannes, France, Sept. 1997. [76] S. Banerjee and B. Bhattacharjee, “Scalable secure group

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

communication over IP multicast,” Proc. IEEE ICNP 2001 (International Conference on Network Protocols), pp.261– 269, Riversice, U.S.A., Nov. 2001. B. DeCleene, L. Dondeti, S. Griffin, T. Hardjono, D. Kiwior, J. Kurose, D. Towsley, S. Vasudevan, and C. Zhang, “Secure group communications for wireless networks,” IEEE MILCOM 2001, pp.113–117, Virginia, U.S.A., Oct. 2001. Y. Chu, S. Rao, and H. Zhang, “A case for end system multicast,” Proc. ACM SIGMETRICS 2000, pp.1–12, Santa Clara, U.S.A., June 2000. Y. Chawathe, Scattercast: An Adaptable Broadcast Distribution Framework, Ph.D. Thesis, University of California at Berkeley, Dec. 2000. S. Zhuang, B. Zhao, A. Joseph, R. Katz, and J. Kubiatowicz, “Bayeux: An architecture for scalable and faulttolerant wide-area data dissemination,” Proc. 11th ACM International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001), pp.11–20, New York, U.S.A., Jan. 2001. B. Zhao, J. Kubiatowicz, and A. Joseph, “Tapestry: An infrustructure for fault-tolerant wide-area location and routing,” Technical Report UCB/CSD-01-1141, University of California at Berkley, April 2001. S. Ratnasamy, M. Handley, R. Karp, and S. Schenker, “Application-level multicast using content-addressable networks,” Proc. 3rd International Workshop on Networked Group Communication (NGC 2001), pp.14–25, London, UK, Nov. 2001. S. Ratnasamy, P. Francis, M. Handely, R. Karp, and S. Schenker, “A scalabel content-addressable network,” Proc. ACM SIGCOMM 2001, pp.161–172, San Diego, U.S.A., Aug. 2001. D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel, “ALMI: An application level multicast infrastructure,” Proc. 3rd USENIX Symposium on Internet Technologies and Systems (USITS’01), pp.49–60, San Francisco, U.S.A., March 2001. I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana, “Internet indirection infrastructure,” ACM SIGCOMM 2002, pp.73–86, Pittsburgh, U.S.A., Aug. 2002.

Miki Yamamoto received the B.E., M.E. and Ph.D. degrees in communications engineering from Osaka University in 1983, 1985 and 1988, respectively. In 1988, he joined Department of Communications Engineering, Osaka University, where he is now an Associate Professor. During 1995 and 1996, he visited University of Massachusetts at Amherst. His research interests include multicast communications, active networks, high speed networks and performance evaluation of these systems. He is the recipient of IEICE Network System Research Awards in 2002. He is a member of IEEE, ACM and IPSJ.