Server based Multimedia Multicasting Framework for APAN
Wan Tat Chee (tcwan@cs.usm.my)
Sureswaran Ramadass (sures@cs.usm.my)
Network Research Group
School of Computer Science
University of Science Malaysia
11800 Penang
Tel: (04) 860-3004
Fax: (04) 657-3335
¡¡
The use of multicasting in interactive multimedia applications provide a bandwidth efficient scheme to transmit the necessary data to and from multiple participants. Examples include multimedia broadcasting over the Internet and multimedia conferencing among multiple parties. Experimental multicast-capable networks have been proposed and implemented, the most prominent being MBONE.
Currently, MBONE uses a dynamic topology discovery algorithm (DVMRP) for determining the membership of a particular multicasting event (termed multicast group). Although the algorithm enables multiple users to enter and leave the group as desired easily, the algorithm induces periodic update packet flooding over the Internet in order to perform its dynamic topology updates. As the number of concurrent multicast streams increases, this periodic flooding of the network would impact the service quality offered to ongoing multicast streams, since the updates results in ¡®spikes¡¯ in network bandwidth utilization.
As the Internet evolves towards providing Quality of Service (QoS) guarantees for multimedia streams, this periodic spikes complicates network bandwidth utilization planning as additional buffer capacity must be provided to support the periodic flooding requirement. Instead of performing the periodic flooding as required by DVMRP, we propose a Server based Multimedia Multicasting Framework which retains the advantages of the current MBONE architecture, while reducing the impact of adding and deleting members from multicast groups.
Servers are already a common part of the Internet landscape. Domain Name Servers (DNS) act as directories to resolve requests for translating site names, such as ¡®www.yahoo.com¡¯ into its corresponding IP address. With the deployment of directory services and Object Request Brokers (ORB) to support various collaborative systems, the issue of requiring an additional Multicast Group Resolution Server (MGRS) for supporting multicasting over the Internet becomes less of a critical factor.
MGRS differs from Multicast Address Resolution Servers (MARS) defined for ATM networks [2] in that while MARS is a LAN service, MGRS is an Internet service to interconnect various LANs. Each LAN is termed a site in this paper.
In any multicast session, there is always an initiating node or site that coordinates the given session. For example, Internet broadcasts originate from the broadcasting site, while multimedia conferences are initiated by one site that acts as the chairperson for that conference.
The proposed framework therefore requires that each initiating site for a given multicast stream registers itself with a well-known MGRS, preferably one per domain. MRS are hierarchical such as is the case for DNS.
The registration creates a logical name for the multicast stream that can be uniquely identified, similar to host/domain names for DNS. The logical multicast group name can then be mapped to specific IP multicast address that is unique for that domain. A multicast session can possibly use different IP multicast address in different domains, managed by the MGRS.
Once a multicast stream is registered, then other sites wishing to join or receive that given stream would perform a Multicast Group Address Resolution (MGAR) via its domain MGRS in order to determine that particular multicast group¡¯s IP multicast address.
Multicast-aware routers, or IP multicast tunnelers such as Multiple LAN Internet Converter (MLICs) [1] handle the task of routing the necessary multicast packets to the new site. MLICs utilize a technique called IP-tunneling to perform its function. IP-tunneling provides a fast and robust manner of interconnecting various multicast islands. IP-tunneling also provides a means of encapsulating the multicast address information such that a common multicast address could be used for a given multicast group in various LANs.
The MGRS and MLICs work closely together. MLICs understands the concept of a multicast routing hierarchy that parallels the MGRS hierarchy (MLICs and MGRS could be implemented in the same network device). Once the MGRS receives a MGAR to join a given multicast group, it would propagate the request up the MGRS hierarchy to the point where the given multicast stream is active. The MGRS for that level of the hierarchy would then perform a topology update to reconfigure the links between the MLIC at that level and any downstream MLICs, to accommodate the new site.
Sites that decide to leave a given multicast group would also inform its MGRS of the change, which would then propagate it up the hierarchy to the point where no other downstream sites are active. At that point, the topology is pruned to remove that site from the group. MGRS could also have a keep-alive timeout to prevent unnecessary multicast transmission due to errant sites that did not perform a proper leave operation. The duration of this keep-alive timeout would be much longer than that used in DVMRP since joins are explicit actions.
Since all site additions and removals are well-defined events, there is no need to perform periodic flooding of the Internet to determine group memberships. Instead, multicasting topologies are modified only upon the explicit addition or removal of sites through the MGRS.
The operation of the MGRS can be divided into five phases:
In each case, the algorithm used to perform each step is provided below.
On initiation of a multimedia stream, the initiating site would register the group with its MGRS. The MGRS would propagate the group registration information up its hierarchy till it reaches the highest level domain designated by the given group properties. At the same time, any participating sites in other part of the hierarchy (for the example of a multimedia conference) would inform their MGRS of the desire to establish the multicast group (invited by the initiating site via normal unicast transmission channels). These MGRS would propagate the group establishment request up to the level needed to identify the source of the multicast group registration. Using this information, a network topology is derived indicating the topology and interconnections between the various MLICs associated with the given group. The naive solution is to have a well-connected mesh network among all participating MLICs in that group.
Once each MLIC has successfully configured its tunneling table with the information pertaining to the new group, the establishment of the new group is complete.
The algorithm for the Group Establishment phase is summarized as follows:
The task of the MLIC during the group¡¯s lifetime is straightforward. Once the group has been established, the interconnections will be active until the initiating site terminates the group or if participating site wishes to leave a given group.
Each MLIC performs the following tasks while operating in Group Data Transfer mode:
Group Membership Deletion occurs when a particular site leaves the group unilaterally after all the participants within that site exit from the given group. However, the group continues among the other participating sites.
A Group Membership Deletion is initiated a MGRS when it has determined that all participants at that given site has left the group. This occurs when each participant in that site leaves the group and informs the MGRS of its intention. The MGRS then propagates the change up its hierarchy.
Alternatively, the MGRS received a directive from the initiating site to remove that particular site from the multicast group. Once the group membership deletion is confirmed, the MGRS propagates the change up its hierarchy until a stable hierarchy is detected. The MGRS at that level performs a topology update to derive the new interconnection topology (N¡¯group). This interconnection topology is then propagated to the participating MLICs to update their tunneling tables.
The Group Membership Deletion algorithm is given as follows:
Group Membership Addition occurs when a site wishes to join the group, or if the initiating site invites a new site to join the group.
Once the group membership addition is confirmed, the MGRS for the site wishing to join the group propagates the change up its hierarchy until a stable level is reached. The MGRS at that level then performs a topology update to derive the new interconnection topology (N¡¯group), which is then propagated to the participating MLICs to update their tunneling tables.
The Group Membership Addition algorithm is given as follows:
Group termination occurs when the initiating site terminates the current group, affecting every site.
It could be seen that a group termination is a special case of group membership deletion, which can be modeled as n sequential group membership deletions. However, it is more efficient in terms of network utilization to perform the group termination using an atomic Group Termination command, since all relevant interconnection topology for the given group could be released simultaneously.
The algorithm for the Group Termination is summarized as follows:
The definition of a server based Multimedia Multicasting Framework would enable the establishment of an orderly hierarchical structure for inter-APAN multicast traffic transmission. While this framework is derived from the MBONE topology, it differs from MBONE in that group memberships are determined explicitly. This reduces the need for periodic flooding of the network which occurs.
MGRS performs two major functions: maintain the logical mapping between a multicast session and the actual IP multicast address, as well as manage group memberships and multicast routing topology for other sites which are part of the multicast session.
Further research needs to be performed to determine how to minimize the disruption to existing multimedia streams due to changes in the topology due to group membership deletions and additions.