行政院國家科學委員會專題研究計畫成果報告
無線數據網路下之以 IP 為基礎的行動群播
IP-Based Mobile Multicast for Wir eless Data Networ ks
計畫編號：NSC 90-2213-E-110-042
執行期限：90 年 8 月 1 日至 91 年 7 月 31 日
主持人：林俊宏 國立中山大學資訊工程學系
一、中文摘要
我們提出此計劃的主要目的是針對現行網 際網路上的行動工作站，設計一個嶄新的、高效率 的可靠行動群播協定，此協定將經過測試及模擬， 最後再發展成雛形系統。我們希望這個協定必須具 備簡單、可擴充、相容性高的條件，且儘量不需要 更改底層群播路由協定。我們的計劃是以目前網際 網路中的標準群播協定為基礎(如 DVMRP, CBT, MOSPF, PIM 等等)，而對於行動訂閱者的處理，則 是在原來網際網路標準群播協定之上，架設 IETF Mobile IP 中所建議的兩種解決方案之一，亦即遠 端訂閱(remote subscription)及雙向轉傳 bi-directional tunneling)，或者是我們所提出 的 RBMoM (Range based Mobile Multicast) [15] 的解決方法。遠端訂閱主要的優點是提供最短距離 的資料傳輸給行動訂閱者；但是卻因此需付出維護 群播樹的高成本。而雙向轉傳是希望對系統隱藏起 行動工作站，如此不需要花費額外維護群播樹的成 本，但卻犧牲了最短路徑的資料傳輸。也就是，在 短距離的資料傳輸與維護群播樹的成本間無法兩 全其美，但 RBMoM 整合兩者之優點，使得不論行動 工作站在任何的移動速度及數量之下，均能使維護 群播樹的成本低且具有短距離的資料傳輸路徑。 我們的計劃是要更進一步提供上述行動群播 的可靠性(reliability)服務。在行動網路中的資 料遺失，除了有線網路的擁塞外，無線網路的通訊 品質及行動工作站的 handoff 更尤勝於前者，是資 料遺失的主因。為有效地支援可靠服務，我們的機 制必須解決可靠群播的一些重要議題，如：request implosion, duplicate replies, recovery latency, recovery isolation (or exposure), 和 adaptability to dynamic membership and location change。我們的協定將包含 handoff 機 制、回應機制、抑止重覆的重傳要求及回應等等。 最後，我們將先對此新協定做模擬及測試。並且進 一步將其實作成一個雛形系統，再整合於我們目前 已完成的行動群播測試系統平臺中。 關鍵詞：群播，群播樹，群播網、可靠群播、Mobile IP，行動計算， 雙向隧道法，遠端訂閱法。 Abstr actThe major focus of the proposed research is the design, testing and prototyping of a novel,
high-performance reliable mobile multicast protocol for Internet. Mobility support (i.e., mobile participants) complicates the reliable multicast problem. The main challenges of mobile multicast are that the multicast protocol must deal not only with dynamic group membership but also with dynamic member location. Also, the established routes are themselves transient in nature. Therefore, new pacing and retransmission mechanisms should be designed to improve the performance for mobility support. The IETF Mobile IP (IPv4) [22] only focuses on unicast delivery to mobile hosts; new protocol for multicast support has to be developed over or within the Mobile IP. Every reliable protocol assumes the existence of multicast routing tree in IP networks provided by underlying multicast routing protocols, such as DVMRP, CBT, MOSPF or PIM. Mobile participants roam around the internetworks and can cause some static multicast routers to join or leave the multicast tree. The operations of joining and leaving can exploit the protocols of remote subscription [22], bi-directional tunneling [22], or RBMoM [15].
In our proposed research, we will develop the reliability service over the mobile multicast in IP networks. In mobile networks, the data loss is not only because of the congestion in wired networks, but also because of the wireless channel quality and mobile host handoff. In our solution, we need to solve the following important issues (which are absent from unicast error control): request implosion, duplicate replies, recovery latency, recovery isolation (or
exposure), and adaptability to dynamic membership and location change. So our solution contains the handoff scheme, ACK mechanism, and suppressing the duplicate requests and replies. Taking advantage of our previous works on mobile multicast [15], we believe our protocol will be efficient. Finally, we will simulate and make testing our protocol, and then integrate it with our developed mobile multicast service.
Keywor ds: Mobile IP, multicast, reliable multicast,
multicast tree, bi-directional tunneling, remote subscription
1. INTRODUCTION
The mobile multicast protocol must deal not only with dynamic group membership but also with
dynamic member location. Reconstructing the delivery tree every time a multicast member and/or source moves is not always a good solution. This will involve the overhead, yet leaving the tree unchanged can result in inefficient, incorrect, or even failure of multicast datagram delivery. Thus they are not suitable for the mobile environment.
In this report, our protocol is using the concept of the service rangeand the multicast home agent. Thus, our protocol has the advantages of both bi-directional tunneled multicast and remote subscription: hiding the host mobility from all other members of the group (i.e., no overheads in multicast tree maintenance due to host mobility) and the near shortest delivery paths. We evaluate our protocol through simulation, focusing primarily on its system performance with respect to scalability, implosion, load of MHAs, mobile
population density, and saving cost. However, the most important of our simulation is find out the balance of the routing path and tree maintenance overhead with suitableservice range.
The remainder of this report is organized as follows. Section 2 provides a brief background on IETF Mobile IP protocol, and how its functionality can be leveraged to support mobile multicast. In addition, we address the design of range-base mobile multicast protocol (RBMoM). Section 3 discusses the details of RBMoM. In addition, we address the concept of virtual branch. Section 4 presents and discusses the simulation results to assess the performance of our protocol. Finally, Section 5 concludes our work.
2. RELATED WORKS
A. Mobile Multicast Protocol
Mobile IP [9] supports (unicast) IP routing for mobile hosts in an IP internetwork. The current version of Mobile IP proposes two approaches to support mobile multicast, which are remote subscription andbi-directional tunneling [3].
In remote subscription, each MH (Mobile Host) always re-subscribes to its desired multicast group when it enters a foreign network. Therefore its multicast router (MR) must be added to the multicast distribution tree. The update frequency of the multicast distribution tree will depend on how often the mobile handoff occurs. The main advantage of this approach is that the multicast datagrams are always delivered on the shortest paths. However, the overhead is the cost of reconstructing the delivery tree while a handoff occurs.
Figure 1: Tunnel Convergence Problem
In bi-directional tunneling, the mobile host receives multicast datagrams by way of its home agent (HA) using the unicast Mobile IP tunnels. This approach hides host mobility from all other members of the multicast group. In addition, the multicast distribution tree will not be updated for the sake of member location change. The main drawback of this approach is the routing path for multicast delivery can be far from optimal. Besides, the HA must replicate and deliver tunneled multicast datagrams to all its away MHs, regardless of at which foreign networks they resides. Therefore, the network resource will be wasted. The scheme is complicated by a phenomenon called tunnel convergence problem resulting from the fact that multiple Mobile IP tunnels (from different HAs) can terminate at a particular FA (Foreign Agent). This problem is illustrated in Figure 1, where multiple HAs all happen to have mobile hosts that are members of the same multicast group at the same foreign network, managed by the foreign agent FA. Therefore more than one copy of every multicast package would be forwarded to the FA by every HA (i.e., HAa, HAb, and HAc) that is serving itsmobile hosts.
B. Range-Based Mobile Multicast (RBMoM)
RBMoM [6] intends to trade off between the shortest delivery path and the frequency of the multicast tree reconfiguration. Multicast datagrams are delivered on the near-shortest paths without paying the high cost of reconstructing the multicast tree (the main drawback of remote subscription).
.
Like the home agent in Mobile IP, RBMoM has a router, called multicast home agent (MHA), that is responsible for tunneling multicast datagrams to the foreign agent to which the mobile host (MH) is currently attached. Therefore, each MHA must always be one of the multicast group members (this is like bi-directional tunneling in which every home agent must join the multicast group). Every MH can only have one MHA. The home agent (HA) of a MH is
never changed. However, the MHA of a MH is changeable according to the MH location. The initial MHA of a mobile host is set to be its HA.
Figure 2: An illustration of service range = 1
RBMoM addresses a concept of “range” for each MHA. The range of a MHA means the service range to its MHs. That is, a MHA can only serve the mobile hosts which are roaming around the foreign networks which are within its service range, or the network to which the MHA is attached. If a mobile host is out of its MHA service range, then the MHA handoff will occur. That is, another MHA will take over the multicast service to the mobile host. From the point of view of the range concept, we will find both bi-directional tunneling and remote subscription are the extremes of RBMoM. Let R be the service range of a multicast home agent. Thus,
(1) If we let R = inf, then RBMoM is the same as bi-directional tunneling. In this case, the MHA is always the home agent and is never changed. (2) If we let R = 0, then RBMoM is the same as
remote subscription. That is, when a MH enters a foreign network (i.e., handoff), its MHA must be changed because of out of the service range. (3) RBMoM is a generalization of the above cases and
a unifying mobile multicast approach. According to the value of R, a MHA can determine whether the datagrams should be tunneled to each of them. Observe that the service range restricts the maximal length of the tunnel between a mobile host and its MHA.
3. MOBILE MULTICAST DETAILS
A. Range-Based Mobile Multicast Forwarding Mechanism
Consider the example of an autonomous system shown in Figure 2. All routers in figure 4 are assumed running RBMoM. If Router RT1 has been elected to be MHA for Campus Network, then it could service RT2 and RT3 with range=1. For simplicity, we assume mobile hosts MH1...MH5 join the same multicast group and there is only one source. The base stations in SubnetA and SubnetB join this multicast group via the IGMP (Internet Group Management Protocol). Similarly, using IGMP the routers and base stations in the Campus Network would join this multicast group. We assume RT2 and RT3 are served by the RT1 in this figure (i.e., RT1 is the MHA of RT2 and RT3). Note that RT2 and RT3 can be served by the other MHAs if
they are also in these MHAs’ service range. But each multicast router must elect only one MHA. That is, each router can have only one MHA even though there is more than one in its neighborhood.
To illustrate the delivery of a multicast datagram, suppose that Multicast Source (attached to the Internet) sends a multicast datagram to the “multicast group X”. This datagram will be through the Internet get to the MHA (Router RT1) by using some multicast routing protocol (e.g., CBT, DVMRP or PIM, etc.), and then RT1 forwards the datagram to the members of multicast group X locate d at SubnetA and SubnetB. This is accomplished by sending a single copy of the datagram onto Campus Network as a data-link layer multicast. Upon receiving the multicast datagram from RT1, RT2 and RT3 will then multicast the datagram on their connected networks (SubnetA and SubnetB, respectively). Note that, if MH2 moves from the area of BS3 to the area of BS4, it still can receive the multicast datagrams since it is within the service range of the same MHA (RT1). There will be the similar result when it migrates to the area of BS1, because the BS1 is still still served by RT1. Thus, there is almost no datagram lost because of mobile host handoff only if the mobility is within the service range of the MHA (i.e., the host mobility is hidden within the service range of the MHA).
B. Multicast Home Agent Election
The multicast home agent (MHA) election is performed per handoff by a mobile host using a combination of distance tiebreakers (i.e., the closest node to the multicast source should be the MHA) and loading tiebreakers in the case of equal distances. Random tiebreakers will be used when both distance and loading are equal [6]. For simplicity, we can let all mobile hosts staying in a subnet have the same MHA, and this MHA must be a multicast router. Then the tunnel convergence problem can be solved. Given a service range R, RBMoM, thus, elects the MHA among the group of multicast routers which have the hop distance less than or equal to R to the subnet. Those mobile hosts roaming at a common LAN have the same MHA.
Consider the example depicted in Figure 3 (service range = 1). Figure 3(a) is the network topology. Every node in this figure represents a LAN (or subnet). We assume that each LAN has a multicast router (MR). The MR in a “squared” LAN (e.g., LAN 2, 5 and 9, etc.) in Figure 3(a) means the qualified router to be able to act as a MHA. Once a qualified router is elected as a MHA, it must be on the multicast tree. Figure 3(b) shows the multicast tree in which the source is assumed at LAN 14. If the MR at LAN 2, denoted MR2, acts as the MHA of LAN 1, 3 and 7, it must be on the multicast tree to receive the multicast datagrams from the source and then to tunnel these received multicast datagrams to MR1, MR3 and MR7. These MRs then further broadcast the datagrams to
their local mobile participants. Consider the LAN 18. There are two possible candidates within the service range to be its MHA (i.e., MR13 and MR19). We choose one which service less MRs to be the MHA (loading tiebreakers). If the loading is equal, we can use the random tiebreakers to choose one. If we increase the service range, obviously the number of MHAs is decreased.
How can we get the qualified MRs in the example mentioned above to be the candidates of MHAs for a given service range and a network topology? We need to develop an algorithm to elect a set of MRs (i.e., the MRs in these “squared” LANs in Figure 3) such that every LAN can decide its MHA from this set with the constraint of the service range (i.e., the MHA must be within the service range). Here we assume there is only one MR in each LAN. The size of the set which is obtained from the algorithm must be as small as possible to reduce the multicast traffic delivered on the tree. Additionally, the delivery paths must be as short as possible. We will use a distributed greedy algorithm to solve this problem to get an acceptable and quick answer rather than an optimal one.
We model a network topology to be a graph in which each node represents a LAN and an edge between two nodes means that both LANs are adjacent. It is specially notable that the term “neighbors” used in our algorithm is the set of nodes within the scope of the radius of the service range (called the locality). There is a variable, status, at each node which is used to record whether this node is a member of the set of the candidate MHAs. Its initial value is assigned null. During the run time, the value of the status can benull,
holding, non-member and member. When the
algorithm ends, the status must be either “member” or “non-member”. The MRs at the “member” nodes (LANs) are the possible MHA candidates. Each LAN can randomly choose one to be the MHA, but must meet the constraint of the service range. Once the MHA is decided, it cannot be changed during the multicast session.
1: At the start each node broadcasts its degree (i.e., the number of adjacent nodes) to the neighbors of its locality. The TTL (Time-To-Live) field in the IP header can be used to limit the scope of this broadcast message.
2: For a node, excluding the non-member nodes and holding nodes in its locality, if status=null and it has the highest degree in its locality, it must becomes the member node. Thus, status = member and it broadcasts the MEMBER message to the neighbors. Lowest-ID tiebreakers are used here.
3: When receiving the MEMBER message, a node whose status is not ready (i.e., neither “member” nor “non-member”) sets its status to be
“non-member” and broadcasts aNON-MEMBER
message to the neighbors.
4: If a node's status is not ready and there exits a non-member adjacent node, its status is set to be “holding” (temporary status) and it sends “HOLDING” message to the neighbors. 5: For a node, status=holding and all other nodes'
statuses in its locality are either non-member or holding. The status can be changed tomember if it has the highest degree among all holding nodes in its locality. Lowest-ID tiebreakers are also used here. Like the above rules, status update needs to inform all nodes in its locality.
6: When all nodes decide their statuses, the algorithm ends.
Figure 3: Multicast home agent election (service range = 1)
In this algorithm, every node needs to record the status and degree information of all other nodes in its locality. Take Figure 3(a) as an example. At beginning {2, 11} are to be “member” nodes independently (Rule 2). They make {1, 3, 6, 7, 12, 16} be “non-member” nodes (Rule 3), and then {4, 8, 17, 21} become “holding” nodes (Rule 4). Then according to Rule 2, {5, 13, 22} become “member” nodes. Thus, {4, 8, 10, 14, 17, 18, 21, 23} are “non-member” (Rule 3) and {9, 15, 19} become “holding”. Then according to Rule 5, {9, 19} are updated to be “member”. Thus, node 24 becomes a “non-member” and node 25 becomes a “holding”. Finally, node 20 is updated to be “member” (Rule2), {15, 25} therefore become “non-member” (Rule 3) and the algorithm ends. The “member” nodes are {2, 5, 9, 11, 13, 19, 20, 22}. This the set of MRs to be elected to act as the MHA. Thus, each LAN can decide its MHA among the MRs of these eight LANs. It is worth noting that all MHAs must be on the multicast tree and would not leave the tree during the multicast session. Since these MHAs is many enough to be able to serve the whole internetwork, mobile participant handoff will not cause any overhead in the multicast tree maintenance. Therefore, the host mobility is hidden from all other members of the group.
4. CONCLUSIONS
RBMoM has distinct performance advantage over two other approaches proposed for the mobile multicast problem, namely remote subscription and
bi-directional tunneling. Actually, remote subscription and bi-directional tunneling are the extremes of RBMoM. Our protocol not only hides host mobility from all other members of the group, but also avoids the long delivery path. The delivery path is near shortest, and mobility does not cause any overhead in the multicast tree maintenance. In the multicast home agent (MHA) election is using a combination of distance tiebreakers and loading tiebreakers in case of equal distances. These tiebreakers will choose the shortest path to the MHA and balance the traffic loading of the MHA. Furthermore, the virtual branch scheme can avoid the bouncing of performing the join and leave operations because of handoffs. This is especially useful when the topology size (n x n) is large and the mobile population density is low (i.e., in sparse mode).
