Multiple LAN Internet Protocol Converter (MLIC) for Multimedia Conferencing Tat Chee Wan (
[email protected]) R. Sureswaran (
[email protected]) K. Saravanan (
[email protected]) Network Research Group School of Computer Science University of Science Malaysia 11800 Penang Tel: (04) 860-3004 Fax: (04) 657-3335
Keywords: Multicast, Multimedia conferencing, Tunneling, Wide Area Multimedia Conferencing.
IP 1.
MULTIMEDIA CONFERENCING USING MULTICAST
ABSTRACT Traditional multimedia conferencing architectures required dedicated equipment for both multimedia capture and display, as well as dedicated high bandwidth links between participating sites in order to deliver the necessary bandwidth and performance requirements for the users. Such multimedia conferencing systems are beyond the reach of many users. However, with the widespread adoption of Internet Protocol (IP)-based networks around the world, an open network for multimedia conferencing is now feasible. If the user is willing to put up with the lack of service guarantee inherent in IP-based networks, the use of IP-based protocols for wide-area communications is a much more cost-effective solution.
Multimedia conferencing over multiple Local Area Networks (LAN), or across a Wide Area Network requires the use of efficient multicast servers in order to function correctly. This paper presents a proposed Multiple LAN Internet Protocol Converter (MLIC) algorithm currently being implemented by the Network Research Group and Multimedia Research Labs Sdn. Bhd. for use with multimedia conferencing, to interconnect multiple wide area LANs using IP protocols. This proposed multimedia multicast router will allow multicast based multimedia traffic over ATM Networks like TEMAN (Testbed Environment for Malaysia Multimedia Applications and Networking) and APAN (Asia Pacific Advanced Networks).
Nonetheless, the network bandwidth requirements of multimedia conferencing would be overwhelming if each participant in the multimedia conference is expected to establish a link with every other participant. This leads to the N*(N-1) combinatorial explosion of network links needed to keep each participant in a conference in synchronization with the other participants. In addition, the timing jitter between different participants would have a high degree of variation since each participant node has to transmit the same data to all other participating nodes. The architecture would break down over a large number of distributed participants, such as in the case of widearea multimedia conferencing.
Existing wide-area multimedia conferencing architectures are designed using proprietary systems and routers for wide area multicasting. With MLIC, a distributed approach using off the shelf hardware is proposed. MLICs maintains the full duplex interaction between active multimedia conferencing clients via multicasting via IP tunneling to provide a seamless ‘virtual multicast network.’ In addition, multimedia streams may be compressed in order to accommodate the lower bandwidths available on wide area links. An algorithm for configuring the MLICs during conference initiation and termination is presented in this paper. In addition, the network bandwidth requirement of full duplex multimedia conferencing is analyzed.
Fortunately, the shared-medium nature of current Local Area Networks (LAN) can be exploited to minimize the impact of multimedia conferencing. If the multimedia conference were confined to a single LAN, then each participant node would only need to transmit one copy of the information via multicasting, which is
*This research project is funded by IRPA and MLabs Sdn. Bhd. and is supported by TEMAN and APAN.
1
then received by all other participants without any additional processing on the part of the sending node. However, this multicasting capability is not available to wide-area multimedia conferences, since wide-area links are seldom (if ever) multicast-capable. This paper therefore introduces a Multiple LAN Internet Protocol Converter (MLIC) for addressing this issue of conducting multimedia conferences across a wide-area network, involving participants in different sites. 2.
In addition, MLICs will inter-operate with existing non-multicast aware routers in order to provide multimedia conferencing capabilities in current network environments. Therefore, deploying a multimedia conferencing system would not require a total overhaul of the networking infrastructure for a given site. 3. • • • • •
SYSTEM ARCHITECTURE DEFINITION
In a multimedia conferencing system such as MCS [1], developed at the University of Science Malaysia School of Computer Science Network Research Group, participants are grouped into ‘sites’ that are defined on different LANs. A Server object in each site coordinates various sessions of ongoing multimedia conferences, and arbitrates between different clients wishing to obtain the right to speak using well-defined control criteria [2].
3.1.
MLIC OPERATION
MLIC operation can be divided into five phases: Session Establishment (start of conference) Session Data Transfer (during conference) Session Connection Deletion (during conference) Session Connection Addition (during conference) Session Termination (end of conference) MLIC SESSION ESTABLISHMENT
On initiation of an inter-site conference, the server object would first determine the number of participating sites. The initiating server object then establishes communications with each of the other participating server objects to determine the respective site’s MLIC object’s IP address. Using this information, a network topology is derived indicating the topology and interconnections between the various MLICs associated with the given session. The naïve solution is to have a well-connected mesh network among all sites.
Clients are individual participants equipped with PCs configured with suitable video capture and playback equipment involved in a given multimedia conference. Each server object knows about the existence of other site server objects, in order to initiate and coordinate inter-site multimedia conferences. In addition, each server object knows about the MLIC objects attached to its site. Each site acts as an island of multicast activity, which is then interconnected to other islands using MLICs to bridge the multicast information for a given multimedia conference to provide a seamless multicasting environment for the wide-area multimedia conference.
After the interconnection topology is known, the tunneling tables of each participating MLIC is then updated to register the inter-site multimedia conference session that is being established, with the corresponding multicast address used for the given session determined by the initiating server.
MLICs utilize a technique called IP-tunneling to perform its function. In itself, IP-tunneling is not specific to multicasting or even multimedia conferencing, but IPtunneling provides a fast and robust manner of interconnecting the various multicast islands. IP-tunneling also encapsulates the multicast address information such that a common multicast address can be used for a given multimedia conference across multiple LANs.
Once MLICs have successfully configured their tunneling table with the new session information, the establishment of the new inter-site session is complete. • •
In addition, the bandwidth of wide-area links is often much more limited and more expensive than that available for LAN. There is also a need to minimize the overhead associated with session maintenance, such that it is reduced to a minimum. Fortunately, since multimedia conferences have to be initiated and exited explicitly under the control and coordination of the Server object, the issue of session maintenance is limited to the beginning and ending of the multimedia conference itself.
•
•
Thus, the MLICs are configured to their desired interLAN topology at the beginning of a session, while the configuration is terminated at the end of the session. This contrasts with the Internet MBONE [3], which requires periodic IGMP status updates in order to maintain the topology of the inter-LAN links.
3.2.
Session Establishment is performed as follows: Initiating Server (S0) determines number (n) of participating sites in new session Initiating Server (S0) contacts each site server (Si) to determine the given site’s MLIC IP address (Mi) Interconnection topology (Nsession) for new session is derived using a specified topology derivation technique, given MLIC link information, such as delay, bandwidth, etc. Naïve solution of n*(n-1) links for a well-connected mesh topology can be used for a small number of sites. Multicast configuration and topology information (Nsession) for given session is propagated to each MLIC in turn. The session is established upon successful completion of topology propagation phase. MLIC SESSION DATA TRANSFER
The task of the MLIC during the multimedia conferencing session is straightforward. Once the session
2
has been established, the interconnections will be active until the conference chairman terminates the session or if an entire site wishes to leave a given session.
•
Each MLIC performs the following tasks while operating in Session Data Transfer mode: • For a given session with specified multicast address, local multicast packets for the given session with source address from the local LAN is encapsulated in a unicast IP header and IP-tunneled to other MLICs based on the interconnection topology (Nsession) configured previously. • For incoming IP-tunneled packets from other MLICs, the IP header is stripped and the resultant multicast packet with source address from other LANs is transmitted onto the local LAN. • IP source address checking is necessary to prevent repeated forwarding of incoming packets, which creates multicast loops. 3.3.
3.4.
Once the session connection addition is confirmed, the initiating server performs a topology update to derive the new interconnection topology (N’session), which is then propagated to the participating MLICs to update their tunneling tables. Session Connection Addition is performed as follows: • Site server (Si) receives a request by one or more clients in the site to rejoin the conference in progress. • Site server informs initiating server (S0) of session connection addition status. • OR Conference Chairman invites a new site (Si) to join the conference. • Initiating server updates interconnection topology (N’session) • New topology (N’session) is propagated to each MLIC in turn. The MLIC from the session connection addition site is directed to add the specified session from its tunneling table. • Multimedia conferencing session continues with the new site included in the conference.
MLIC SESSION CONNECTION DELETION
A Session Connection Deletion is initiated by the site server (Si) when it has determined that all clients at that given site has left the conference. This occurs when each client in that site leaves the conference in progress and informs the site server (Si) of its intention. The site server then informs the initiating server of the session connection deletion.
3.5.
Alternatively, the initiating site received instruction from the chairman to remove a given site from the conference. Once the session connection deletion is confirmed, the initiating server determines the number of sites remaining in the conference, and performs a topology update to derive the new interconnection topology (N’session). This interconnection topology is then propagated to the participating MLICs to update their tunneling tables.
• • • •
MLIC SESSION CONNECTION ADDITION
Session Connection Addition occurs when a site wishes to rejoin the conference in progress (after a session connection deletion), or if the conference chairman invites a new site to join the conference.
Session Connection Deletion occurs when a particular site leaves the conference unilaterally after all the clients within that site exit from the given session; or the chairman decides to remove the site from the conference. However, the multimedia conferencing session continues among the other participating sites.
•
connection deletion site is directed to remove the specified session from its tunneling table. Multimedia conferencing session continues without further involvement of the site that has left the conference session.
MLIC SESSION TERMINATION
Session termination affects every site when the conference chairman terminates the current session. It could be seen that a session termination is a special case of session connection deletion, which can be modeled as n sequential session connection deletions. However, it is more efficient in terms of network utilization to perform the session termination using an atomic Session Termination command, since all relevant interconnection topology for the given session could be released simultaneously.
Session Connection Deletion is performed as follows: Site server (Si) determines that all clients in the site has left the conference in progress. Site server informs initiating server (S0) of session connection deletion status. OR Conference Chairman removes a given site (Si) from the conference. Initiating server updates interconnection topology (N’session) New topology (N’session) is propagated to each remaining MLIC in turn. The MLIC from the session
• • •
3
Session Termination is performed as follows: Conference Chairman initiates Session Termination. Initiating Server (S0) informs all other participating servers (Si) of the termination command Each server (Si) informs its MLIC (Mi) to terminate the specified session. MLICs (Mi) removes interconnection links to other sites (parallel).
4.
Whereas for the other (passive) sites, the traffic remains as 2[AVm + AVu]in.
BANDWIDTH UTILIZATION
The network bandwidth utilization for full duplex multimedia conferencing is given here for the case of MCS, a multimedia conferencing system developed at University of Science Malaysia in collaboration with MLabs Sdn. Bhd. MLICs are assumed to be connected in a mesh-topology for a worst-case analysis.
5.
The algorithm described here in this paper is deterministic, as compared to the DVMRP protocol used in MBONE, since the conference session initiation and termination events are well defined and under the control of the Conference Servers. As such, topology discovery and configuration needs to be performed once at the start of the conference, and as needed as sites leave and join the conference or when the conference is terminated by the chairman. In every case, the MLICs only need to be informed of changes by the site servers, thus simplifying its design. MLIC performance is therefore not hampered by periodic network topology updates or group membership discovery process.
Let the multicast video stream bandwidth for a given MCS client be Vm, and the multicast audio stream bandwidth for any MCS client be Am, assuming identical bandwidth requirements for all clients. The unicast tunneled equivalent of the multicast streams are Vu and Au, where Vu = kVm and Au = kAm. k ≥ 1 represents the overhead due to the unicast header. For simplicity, we can assume k=1 if the overhead is negligible. Therefore, the multimedia stream bandwidth AVm = (Am + Vm) for a given MCS client. The respective clients perform compression, so AVm represents the net bandwidth utilization per multimedia stream. Since MCS defines a full duplex transmission from two simultaneously active clients (a chairman and an active client) to every client (active and passive) of the conference at any given time, therefore the multicast network bandwidth utilization within a single LAN multimedia conference is 2AVm.
6.
Nonetheless, the algorithm still holds, as it is able to adapt to any interconnection topology that can be supported by MLICs. Optimization of the interconnection topology remains a topic of active research. 7.
For the first case, the total bandwidth consumed by the local multicast traffic and MLIC unicast tunnels for the site containing the chairman and the active client is: (1)
[2] R. Sureswaran, Using the RSW Control Criteria to Create a Distributed Environment for Multimedia Conferencing, REDECs '97, Malaysia. Nov 1997. [3] S. Deering, Host Extension for IP Multicasting, RFC1112, IETF, http://www.ietf.org, Aug 1989.
(2)
For the second case, there is one stream originating from the chairman site, and another coming from the active site. For both the chairman as well as the active site, the total traffic due to the conference is:
8.
ACKNOWLEDGEMENTS
The authors wish to acknowledge the valuable contributions of Wai Beng Lam, as well as the following students who have contributed to the project: Pei Hwa Wong, Chye Hong Loo, May Nee Khor, Chin Wei Khor and Su Lin Tan.
[AVm + (Y-1) * AVu]out + [AVm + AVu]in = [2AVm + (Y * AVu)]total
REFERENCES
[1] R. Sureswaran, T.C. Wan and O. Aboudallah, A Multimedia Conferencing System to Support the APAN Network (Asia Pacific Advanced Network), to appear.
The network utilization for all other (passive) sites consisting of the unicast tunnel traffic from the chairman/active site, and the multicast retransmission is: 2[AVm + AVu]in
CONCLUSION
MLICs represent a means of implementing wide-area multimedia conferencing using off-the-shelf components and equipment, which incurs lower control traffic bandwidth compared to MBONE. It can be seen from the network bandwidth utilization that MLIC, which operates on the basis of unicast tunneling, would not scale well using a mesh-topology. Topology optimization is necessary in order to minimize the number of unicast tunnels that operate between active sites in a given conference. Better yet, true multicast routers which does not perform tunneling but instead connect between different LANs directly would become necessary for the wide scale deployment of such multi-LAN conferences.
The MLIC is a network entity that operates on the LAN to tunnel the multicast packets to another LAN via a router. Since the MLIC transmits its tunneled information via the same LAN to the router, therefore a Multi-LAN conference would of necessity consume additional bandwidth. Given Y sites, each MLIC in a mesh topology will need to tunnel an active stream to (Y-1) other MLICs. There are two cases: the first where both the chairman and active client is on the same LAN, and the second, where the chairman and the active client is on different LANs.
2[AVm + (Y-1) * AVu]out
DISCUSSION
(3)
4
