A Highly Dynamic SSM Source Discovery Protocol Mickaël Hoerdt
Jean-Jacques Pansiot
Université Louis Pasteur – LSIIT Boulevard Sébastien Brant 67400 Illkirch, France Email:
[email protected]
Université Louis Pasteur – LSIIT Boulevard Sébastien Brant 67400 Illkirch, France Email:
[email protected]
Abstract— Steven Deering’s multicast communication model offers a powerful and flexible service for group communicating processes. Sending a multidestination datagram with only one local source operation, implicit source discovery for an open group, and logical binding. All theses features without limits on group size and dynamics. This proposition, later called Any Source Multicast (ASM) has not been deployed at large scale on Internet partially because of the unscalability of multicast routing protocols. A new service model but potentially scalable to the whole Internet has been proposed : Source Specific Multicast (SSM). It is less powerful because it needs an explicit source discovery mechanism for receivers. In this paper, we propose and evaluate such a session layer mechanism. This protocol offers the source discovery service missing from source specific multicast routing. We have implemented this protocol, which permits us to evaluate its feasability and scalability.
I. I NTRODUCTION Today, the IP protocol, either in it’s version 4 or in it’s version 6 is mostly static and point to point. Each datagram sent and forwarded on the network by routers is sent toward a unique destination, with a fixed geographical position in the network. Deering, during his work [1] proposed a natural extension to IP for group communications. This powerful extension allows to send a multi-destination datagram with one local operation on the source, an implicit in-band multicast source discovery mechanism and the logical naming of a host group by using IP multicast addresses. All of this, without limit on the group size or dynamics inside an open group. This proposition has later be called Any Source Multicast (ASM), enabling logical binding and diffusion applications independent of the source/receiver location. A few applications example which may heavily depend on these services are television, radio or databases replication, distributed computation or games. Despite the power and the utility of such services for the applications and the network, IP multicast is still not widely deployed on the inter-domain Internet. Multicasting at the layer 2 was already well established since Metcalfe work [2]. Deering’s work was in the continuity of Ethernet and it was reasonable to think that it would be a success. Actually, a large scale deployment tentative effectively happened with the Mbone [3] and the protocol suite IGMPv2 [4], PIM-SM [5] and MSDP [6], but it did not produce the awaited results. A lots of operational and research experience came
out from this tentative but the scalability of the multicast routing and addressing protocols suite was not satisfying for the academic and for the industry communities. In parallel of this, Holbrook [7] decided to study the viability of a group service model without an in-band multicast source discovery mechanism. This model has later been called Source Specific Multicast (SSM) and is implemented by the protocol suite IGMPv3 [8] or MLDv2 [9] for IPv6 and PIM-SSM [10]. A receiver registers explicitly to a channel where only one IP source is allowed to send data. In the case of multi-source applications, a receiver has to learn the list of all channels used by the sources by out-of-band means. This list can be dynamic. We propose a new simple session protocol, Source Specific Multicast Source Discovery Protocol (SSMSDP). It is only based on the SSM service model proposition from Holbrook [10], today standardised and implemented. This session protocol only needs to be executed on the end hosts, and reestablish the dynamic in-session multicast source discovery function for the application, without breaking the simplicity of the Holbrook’s model [11]. We implemented our protocol, which permits us to evaluate it’s feasibility and it’s extensibility by using a local test-bed. This test-bed is potentially extensible at the inter-domain Internet. In this paper, we show that out-of-band multicast source discovery is a viable solution for most of the multicast applications. Section II summarises the related work in the field, sections III and IV describe the protocol in details and it’s evaluation in a real environment with an implementation freely available for the research community [12], [13]. II. R ELATED WORK In his seminal work of the SSM model service definition, Holbrook considered two multicast cases to be able to use multi-sources applications over SSM only IP environments. He defined two schemes plus a hybrid one.
IP multicast router
IP multicast router
terminal
terminal signalisation
Fig. 1.
Session relaying
Fig. 2.
Session advertisement
The first scheme, illustrated on figure 1 use a relay node for all the data transiting in a session. This is basically a shared tree but at the application layer. The second one, on which our proposition is based is illustrated on figure 2. Here, only the control messages of the session are relayed in an applicative shared tree. This permits to link logically the members of a same session. Holbrook evaluated these two propositions by simulation without really defining a detailed architecture. We propose here an evaluation of this architecture by defining in details a protocol based on the signal relay and by implementing it. In [14], Chesterfield and Schooler propose to modify RTP/RTCP [15] to cope with SSM environments. This solution is aimed at real time contents distribution and do not consider the general case of distributed group process. Indeed, their solution only works for the RTP/RTCP specific applications such as vic [16] and rat [17] by relaying the RTCP information. We consider that their solution is too application specific and that a general session layer should be defined. In this paper we define a session level protocol as independent as possible from the applications. The SSMSDP service is designed to discover dynamically and automatically the multicast sources from a process group connected by a SSM network. An architecture based on session relaying is proposed in [18]. Their study consist in placing a variable number of proxies on the Internet to help SSM deployment. We do not consider incremental deployment problem here and consider an Internet environment where SSM is ubiquitous and where a sender advertisement based architecture can be deployed. In [19] the authors propose to modify directly the forwarding tables of SSM multicast routers. They say that their proposition would only need a little modification in the SSM architecture and would extend the SSM multicast forwarding state scalability. They also say that this solution would solve the failure problem of SSM tree root. We think that their solution would need to change all the SSM architecture and that it is not coherent with the original SSM service model. We presented our solution in an internet draft [20] and in [21]. Recently Lethonen [22] proposed a very similar solution , with the difference that it uses messages based on MSDP [6] and a TCP connection toward the relay to enhance the security of the proposition. Also we propose to use UDP to reduce the connection delay for a new source announcement in a SSMSDP session. We implemented both UDP and TCP mode and we quantify in section IV its impact on the announcement of a new channel. III. S OURCE S PECIFIC M ULTICAST S OURCE D ISCOVERY P ROTOCOL As seen in section II, two solutions exist to gather senders and receivers of the same group over a SSM only network. The first one is based on a unique shared data tree, supporting all the traffic of the sources present in the session. The second is based on a unique shared signaling tree, this adding a new problem : how to link the different sources to the receivers with
a session and to conserve the same properties as Deering’s host group model ? Three entities play a role in the SSMSDP protocol: controllers, receivers and sources. A controller is the root of a SSMSDP control tree and sends the necessary signaling to establish a session between the sources and the receivers. It has a rendezvous and relay function for the SSMSDP signaling. A receiver is the leaf of a SSMSDP control tree and registers to the multicast channels announced. A source sends announcements to the controller. The controller forwards these announcements to all receivers through the shared signalling tree. Signalisation transport is achieved by UDP datagrams. A. Source-controller Interaction A SSMSDP session is dynamic, as an ASM host group. Multicast sources may appear and disappear from a session without constraints. To maintain such a session, one needs to constantly keep up to date the information about a source activity at a given time. This information travels from the sources toward the controller and is soft-state maintained by two messages. The first one that we name ONSSM SDP is transmitted periodically (In the current specification every 5 seconds) from the source toward the controller in unicast to maintain a temporised cache. The second message OF FSSM SDP is sent from the source toward the controller to notify the source departure from a SSMSDP session, which is the same as reinitializing the cache timer to zero.
C
S
SSM IP router SSMSDP process SSMSDP cache SSMSDP timer
Fig. 3.
SSMSDP source-controller interaction
OF FSSM SDP are not mandatory for a correct behaviour of the protocol as each source is temporised at the controller. If a source timer expires a OF FSSM SDP message is sent in the control tree toward the receivers. This means the implicit deletion of the source for the receivers. The figure 3 illustrates the mechanism. A SSMSDP controller is an intra-process entity. This entity waits for source announcements, when it receives one, it puts the source information in its cache and starts a timer for it. The controller propagates the first source announcement in the SSMSDP control tree corresponding to the session that it maintains. Further source announcements are sent periodically by the controller as long as the corresponding timer in its cache is active.
B. Controller-receiver interaction Source state information present in a SSMSDP session must be duplicated on each receiver. For this, the controller sends (presently every 5 secs) in multicast the state of its cache in the SSMSDP control tree. ONSSM SDP messages notify to the receivers that a source is still active. OF FSSM SDP messages notify the departure of a source from the session.
C
S
SSM IP router
ASM a source may start to send toward a group at any moment, its packets will be routed toward the registered receiver as "sender just send" [25]. With SSMSDP, a source should wait until the receivers have received the source announcement and have finished to register to the corresponding channel. We wish to evaluate the delay induced by SSMSDP with our implementation. With simulation it is easy to centralise time measurements. We do not have such a global timer with a real implementation and the timing measurements have to be the more precise as possible. Our tests scenarios are designed to centralise the delay measurements but in a real environment. The section IVA gives the topology that we used to measure delays, and the section IV-B details the different kinds of delay induced by SSMSDP, with the associated delay measurement scenarios.
SSMSDP process R
SSMSDP cache SSMSDP timer Toward a new channel
Fig. 4.
SSMSDP controller-receiver interaction
It is possible for the controller to aggregate in a single message the notifications from a set of sources thanks to its cache. A controller transmits every 5 seconds a message ALIV ESSM SDP to notify its own presence to the receivers. Receiver behaviour is very similar to the controller one. They maintains a temporised cache for the announcements received on the control tree. The controller cache is temporised by unicast announcements. A source with an active timer is potentially registrable by SSM. To obtain a SSMSDP session with the same behaviour than ASM, a receiver joins immediately a new multicast channel announced during a SSMSDP session. This session will be represented by a control tree in addition to all the source trees corresponding to the sources registered in the session. This session mechanism allows to logically connect a process group with the same properties as the host group from Deering but offers additional advantages. A receiver can learn that a source is active in the session but do not have the obligation to register it. Source announcements may be filtered at the controller. Also, because our proposition is implemented in the end hosts, the policy used to manage the set of announced source can be application specific. C. Implementation We implemented SSMSDP in a library named libssmsdp [12]. This library can be potentially used by all applications needing a dynamic multi-source support. During an European IPv6 deployment project [23], we tested our library with several applications needing an in-session source discovery like vic [16] or the multicast beacon [24]. We evaluate now our protocol by using our implementation. IV. E VALUATION One key difference between the native ASM service and the use of a SSMSDP session layer is the delay. For example, in
A. Topology We built a local triangle-shaped test-bed illustrated on figure 5. It is composed of three routers and three hosts, each host being connected to a distinct router. The routers R1, R2 and R3 are simple PC based on i386. They run the protocols PIM-SSM [5] and MLDv2 [9] router part that we implemented [13]. The hosts H1,H2 and H3 are i386 PC under Linux and run the protocol SSMSDP and MLDv2 host part. The link bandwidth capacity is given on the figure.
Fig. 5.
Delay evaluation test-bed of SSMSDP protocol
As mentioned in section III, three kinds of entities are present in the SSMSDP protocol : controllers, sources and receivers. We can put them freely on H1, H2 or H3 and run several instances and type per host depending on the desired session number or application needs. Here our application is a test designed to obtain delay measurements and to evaluate the robustness of our implementation to show the feasibility of our protocol proposition. We now detail the scenarios allowing to measure the delay when a source comes and leaves during a SSMSDP session. B. Delays induced by SSMSDP There is no implicit source discovery mechanism in PIMSSM. Networks components who want to register or unregister to a multicast source must tell it to the network explicitly. In SSMSDP, the source sends an announcement toward the controller, which must sent the announcement in the control
tree. The receivers have to register or unregister, therefore creating or destructing a branch toward the source. These operations take time and we would like to quantify it. Our measures are mainly focused at the node treatment, as the test-bed is local. Table I describes in more details the different steps creating a delay in our solution.
Announcement of a new source
Announcement of the departure of a source
MLDv2 + PIM-SSM + SSMSDP 1a.packet processing by the source. (sending of a message ON in unicast toward the controller) 2a.Network travelling from the source toward the controller. 3a.packet processing by the controller. (unicast reception and multicast sending in the control tree toward the receivers R ) 4a.Network travelling from the controller toward the receivers. 5a.packet processing by the receiver. (MLD processing and sending a MLD (S,G) report message) 6a.Contruction of the branch between the first receiver and the source (PIM processing). 1d.Same as 1a. but sending a message OFF in unicast toward the controller 2d.Same as 2a. 3d.Same as 3a. 4d.Same as 4a. 5d.packet processing by a receiver. (MLD processing and sending of a MLD leave (S,G) message) 6d.destruction delay of the branch between the last receiver and the source (PIM processing).
TABLE I T HE DIFFERENT DELAY STEPS IN SSMSDP
The steps numbered from 1a to 6a follow the normal order of SSMSDP execution following the announcement of a new source. As long as all theses steps are not accomplished, all packets send by this new source will be lost. The steps numbered from 1d to 6d do the same, but following the departure of a source. As long as all these steps are not terminated, the multicast diffusion tree will be maintained uselessly by the network. We can notice that when a new source is announced, the step 6a corresponds to the building of the first multicast branch toward this source. On the other side when a source leaves the session, the step 6d corresponds to the destruction of the last branch toward the source. In the currently used IP multicast architecture, a source is not informed of the existence of receivers. The MSNIP protocol, presently being normalised [26] will allow routers to give this information to SSM sources. As this protocol is not implemented, we run an instance of PIM in the source. In this way the first PIM-join after a source announcement means that step 6a has been completed. Similarly, the first PIM-leave after an OF FSSM SDP means that the step 6d has been completed. 1) New source appearing: Based on the figure 5, we instanciate a SSMSDP session composed of one source s1 and one receiver r1 on H1, one controller c1 on H2 and one receiver r2 on H3. We want to quantify the announcement delay of a new source and the branch building delay toward this source by varying SSMSDP scalability parameters but by centralising delay measurements on H1 too. More specifically, we want to measure the delay passed between the moment when a SSMSDP source is created on H1 and the time when it receives the first PIM-Join from R1
given multiple evaluation criteria. The first criteria is based on the number of sources available simultaneously inside the same session. The second one is based on the number of simultaneous sessions available on H2 and where R3 and H1 have registered.
Fig. 6. Delay triangle coming from SSMSDP protocol during the announce of a new source
As illustrated on figure 6, three kinds of delay appear. Let ∆ = t1 + t2 + t3. ∆ measurement is obtained by using the timer of H1 associated with s1 and by waiting for an PIM-Join message arriving. This measure includes all the applicative processing associated with the libssmsdp [12] library, because all time measurements are done inside a same probe process containing s1 and r1. Γ = t1 + t2 is obtained by the same way, apart than we probe for ONSSM SDP messages on the control channel. We can then deduce t3 with the difference of these two values and quantify the ratio beetwen t3 and t1+t2. Two experiences allow us to evaluate our implementation and to measure these delay given the previous criteria : • The first one variate the number of channels announced to c1, this means instantiate a variable number s1 ...sn of source entities in the SSMSDP session. In consequence we will have a variable number of SSM branches starting from r2 and reaching s1 ...sn . On one hand this implies an applicative processing time in the controllers, source and receivers entities and on the other hand a processing and propagation time of PIM control message on the branch between r2 and s1 ...sn . These delays should increase with the number of announced channel and we would like to quantify them. We execute a sequential scenario which increments the number of announced channels like this : When we receive the first control message on H1, indicating that the nth branch is active, we announce the nth + 1st channel after 100ms and we still keep the previous last announcements active in the session. Everything happens as if a new source appeared in the session every 100 + ∆ms. We waited 100ms to suppress the congestion risks if ∆ is too small. • The second experiment is based on the number of simultaneous SSMSDP sessions running on H1. By varying the number of SSMSDP controllers c1 ...cn on H1, we will consequently have a variable session number connecting the c1 ...cn controllers to the r1 ...rn receivers. As in the first experiment, the applicative and network processing time should increase the delay ∆. We execute a sequential scenario which increments the number of sessions on our test-bed : after having created and joined the n − th
1e+07
1e+07 t1+t2+t3 t1+t2
1e+07
1e+07 t3
100000
100000
10000
10000
1000 50
100
150
200 250 300 Number of sessions
350
400
450
Delay (µ seconds)
Delay (µ seconds)
1e+07 t3
1e+06
1000 500
1e+06
1e+06
100000
100000
10000
10000
1000 50
Fig. 9. t1 + t2 + t3 and t1 + t2 delay in function of the number of simultaneous sessions
100
150
200 250 300 Number of sessions
350
400
450
1000 500
Fig. 10. t3 delay in function of the number of simultaneous sessions
500 per process, which means that we maintain 500 SSMSDP controllers per process. We are currently working toward a solution which let us bypass this limit, even if we think that 500 SSMSDP sessions per process is already a satisfying limit for the existing applications. The high delay comes again, and is visible for the t3 computation, which well confirms that it is coming from the MLDv2 or PIM-SM. 1e+07
1e+07
1e+07
t1+t2+t3 t1+t2
1e+07 t3
1e+06
1e+06
100000
100000
1e+06
1e+06
100000
100000
10000
10000
10000
1000
1000
1e+06
100000
100000
10000
10000
Delay (µ seconds)
Delay (µ seconds)
1e+06
1e+07
1e+06
Delay (µ seconds)
1e+07
1e+07 t1+t2+t3 t1+t2
Delay (µ seconds)
session on H2, H1 and H3, we announce a channel i in this session. When we receive the first control message on H1 that indicates that the channel corresponding branch is active, we announce the departure of i from this session and we create the nth+1st session and keep the previous created sessions active. After the creation of a session ci on H1 and a receiver ri on H1, we wait 100ms before announcing the channel i in this session to be sure that the control tree is active. In this experimentation the number of sessions increases, but not the number of announced channels. 2) Results: Delay measurements based on the number of announced channels per session are drawn in 7 and 8. Measurements depending on the number of simultaneous session are traced on 9 and 10. The delay is varying between 6ms and 30ms for a number of announced channels varying from 1 to 1500 and 6ms to 17ms for a number of sessions varying from 1 to 500. For comparison, with 500 simultaneous channels, the measured delay was 13ms, maintaining a high number of concurrent sessions per host is more costly than maintaining the same number of channels.
1e+06
1e+06
10000
100000
100000
1000
10000
1000 0
200
400
600
800
1000
1200
1400
Number of channels
200
400
600
800
1000
1200
1400
Number of channels
10000
1000
0
1000
1000 0
200
400
600
800
1000
1200
Fig. 11. ∆ and Γ delay in function of the number of simultaneous announced channels with TCP
1000 0
200
400
600
800
1000
1200
1400
Number of channels
Fig. 12. t3 delay in function of the number of simultaneaous announced channels with TCP
1400
Number of channels
Fig. 7. t1 + t2 + t3 and t1 + t2 delay depending of the number of simultaneous channels
Fig. 8. t3 delay in function of the number of simultaneous channels
We can notice high delays having greater than one second appearing more frequently as the number of simultaneous channels increase. These high delays are certainly coming from an implementation artefacts from MLDv2 [9] or PIMSSM [5] because they reappear in t3 computation on the figure 8. They cannot come from a ONSSM SDP message loss otherwise the additional delay would be over the 5 seconds periodical announcement of these and t1 + t2 measurement would show an high delay artefact too. On figure 7 we also plot Γ value, that is the delay between the call asking for the connection of a new channel to a SSMSDP session and the reception of the first ONSSM SDP message on the control channel. This delay varies from 2ms to 11ms for a number of channels varying from 1 to 1500, which represents the third of ∆. The two other third are used by MLDv2 and PIM-SSM : announcement delay of a new source depends mostly on the implementation quality of MLDv2 and PIM-SM. This delay may have a high value as each PIM-SM message is sent hop by hop toward the new source and that a MLDv2 message is sent from the host toward its multicast access router. On figure 9 we trace the delay ∆ in function of the number of simultaneous sessions. For implementation reasons, we were not able to handle a number of sessions superior to
We extended our implementation to support TCP announcement and repeated the experience on the number of channels inside the same SSMSDP session without changing anything else. The figure 11 and 12 give the results on the obtained delays. We can see that the high delay artefact do not disappear and that TCP cannot cope with congestion when the number of concurrent flows is important. Delay ∆ is as we could expect higher than UDP as it is ranging from 8ms to 60ms for a number of connection varying from 1 to 1500 : the mean increase of the delay is about twice higher than with a UDP announcement. Maintaining 1500 TCP simultaneous connections is certainly more costly than a single UDP entry point on a host. Γ value ranges from 3ms to 40ms. These values would certainly heavily increase if we extended the testbed at the international scale as establishing a TCP connection requires a handshake not present in UDP. We measured the tearing down delay of the SSM branch between the time when a source announces that it is leaving and the time when we receive the first PIM control message indicating that the branch is effectively destroyed. This delay is varying between 1s and 3s and do not depend on the number of channels already present in the channel. This high delay value comes from the IGMPv3/MLDv2 [9] design. Indeed, when a multicast receiver signals its departure on the network, the MLDv2 protocol says that the link has to be asked about the presence of others receivers and to initialise a timer before
propagating the information to PIM-SM. Without an explicit receiver tracking system, this timer can vary between 1 and 3s which explains our results. Similar delays are obtained with ASM, so this is not a limitation of SSMSDP. V. C ONCLUSION
AND FUTURE WORK
In this paper we have proposed, implemented and evaluated SSMSDP, a session level protocol which is freely available [12]. We showed that the source announcement delay is realistic by using measurements from a real test-bed consisting of simple PC-routers running freely available implementations [13]. We showed that our protocol is robust and feasible in real environments by maintaining more than 1500 simultaneously announced sources inside a same session and process, and more than 500 simultaneous SSMSDP sessions for a same process coping with the receiver, controller and source entity. This shows that SSMSDP can be applied to hosts groups with an important number of channel sources. The limitation on the number of SSMSDP sessions has no impact on the current and future applications, as we are not aware of any application needing an important number of sessions per process which participates in group applications. The delay obtained with the source departure experiment are mainly due to the PIM and MLD protocols and would not be different with ASM. All theses measurements make us think that SSMSDP is a realistic solution permitting applications needing a highly dynamic source discovery mechanism to function without difficulties on a multicast network which only supports SSM. We are currently working on extending the SSMSDP protocol to have a different behaviour if the source announcements are made via TCP or UDP as the periodical ONSSM SDP announce are not really useful on a reliable connection. We are also working on an extension of SSMSDP with several controllers, allowing a better robustness in case of controller failure and also load sharing. We will extend our experimentation at the national and european scale to show that SSMSDP is viable for group process communications at the inter-domain level where SSM could be rapidly deployed. R EFERENCES [1] D. R. Cheriton and S. E. Deering, “Host groups: a multicast extension for datagram internetworks,” 9th Data Communication Symposium, IEEE Computer Society and ACM SIGCOMM, published as Computer Communication Review, vol. 15, no. 4, pp. 172–179, Sept. 1985. [2] R. M. Metcalfe and D. R. Boggs, “Ethernet: Distributed packet switching for local computer networks,” Communications of the ACM, vol. 19, no. 5, pp. 395–404, July 1976. [3] K. C. Almeroth, “The evolution of multicast: From the mbone to interdomain multicast to internet2 deployment,” IEEE Network, vol. 14, no. 1, pp. 10–20, Feb. 2000. [4] W. Fenner, “Internet group management protocol version 2,” Internet Engineering Task Force, Request For Comments 2236, Nov. 1997. [5] D. E. et al, “Protocol independent multicast-sparse mode (pim-sm) : Protocol specification,” Internet Engineering Task Force, Request For Comments 2362, June 1998. [6] B. Fenner and D. Meyer, “Multicast source discovery protocol (msdp),” Internet Engineering Task Force, Request For Comments 3618, Oct. 2003. [7] H. Holbrook, “A channel model for multicast,” Ph.D. dissertation, Standford University, Aug. 2001.
[8] Cain, Deering, Fenner, and K. ans Thyagarajan, “Internet group management protocol, version 3,” Internet Engineering Task Force, Request For Comments 3376, Oct. 2002. [9] R. Vida and L. Costa, “Multicast listener discovery version 2 (mldv2) for ipv6,” Internet Engineering Task Force, Request For Comments 3810, June 2004. [10] S. Bhattacharyya, “An overview of source-specific multicast (ssm),” Internet Engineering Task Force, Request For Comments 3569, July 2003. [11] H. W. Holbrook and D. R. Cheriton, “Ip multicast channels: Express support for large-scale single-source applications,” in Proceedings of the ACM SIGCOMM symposium on Communications architectures and protocols. Cambridge, Massachusetts: ACM, Sept. 1999, pp. 65–78. [12] M. Hoerdt, libssmsdp 0.3, Université Louis Pasteur, http://clarinet.ustrasbg.fr/ hoerdt/libssmsdp/. [13] ——, pim6sd, a free PIM-SMv6 implementation, Université Louis Pasteur, http://clarinet.u-strasbg.fr/ hoerdt/pim6sd_linux/. [14] J. Chesterfield and E. M. Schooler, “An extensible rtcp control framework for large multimedia distributions,” IEEE Symposium on Network Computers and Applications (NCA-03), Apr. 2003. [15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “Rtp : A transport protocol for real-time applications,” Internet Engineering Task Force, Request For Comments 1889, Jan. 1996. [16] S. McCanne and V. Jacobson, “vic: a flexible framework for packet video,” in MULTIMEDIA 1995: Proceedings of the third ACM international conference on Multimedia. ACM Press, Nov. 1995, pp. 511–522. [17] V. Hardman, M. A. Sasse, and I. Kouvelas, “Successful multiparty audio communication over the internet,” Communication of the ACM, vol. 41, no. 5, pp. 74–80, May 1998. [18] D. Zappala and A. Fabbri, “Using ssm proxies to provide efficient multiple-source multicast delivery,” in IEEE Globecom, Sixth Global Internet Symposium, Nov. 2001, pp. 1590–1594. [19] K. Sarac, P. Namburi, and K. C. Almeroth, “Ssm extensions: Network layer support for multiple senders in ssm,” in 12th International Conference on Computer Communications and Networks, Dallas, Oct. 2003, pp. 74–80. [20] F. Beck, M. Hoerdt, and J.-J. Pansiot, “Source discovery protocol in ssm networks,” Internet Draft draft-beck-mboned-ssm-source-discoveryprotocol, June 2003. [21] M. Hoerdt, F. Beck, D. Magoni, and J.-J. Pansiot, “Source discovery protocol for asm applications in ssm networks,” in Proceedings of the 3rd International Conference on Networking, Pointe-à-Pitre, Guadeloupe, French Caribbean, March 2004. [22] R. Lehtonen, “Dynamic multi-source discovery for ssm using msdp,” Internet Engineering Task Force, Internet Draft draft-lehtonen-mbonedmultissm, July 2004. [23] The 6net IST project, http://www.6net.org. [24] M. Kutzko, T. Rimovsky, J. Estabrook, and J. Dugan, The NLANR/DAST Multicast Beacon, National Laboratory for Applied Network Research, http://dast.nlanr.net/Projects/Beacon/. [25] S. Deering, “Host extensions for ip multicasting,” Internet Engineering Task Force, Request For Comments 1112, Aug. 1989. [26] B. Fenner, B. Haberman, H. Holbrook, and I. Kouvelas, “Multicast source notification of interest,” Internet Engineering Task Force, Internet Draft draft-ietf-idmr-msnip, June 2003.
