行政院國家科學委員會專題研究計畫成果報告
網際網路之可靠行動群播設計
The Design of Reliable Mobile Multicast Suppor t for IP Networ ks
計畫編號：NSC 89-2213-E-110-081
執行期限：89 年 8 月 1 日至 90 年 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 act
The 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.
Keywords: Mobile IP, multicast, reliable
multicast, multicast tree, bi-directional tunneling, remote subscription
1. Introduction
Background, purpose, and importance: The exponential growth of the MBONE and other multicast-capable networks has led to the wide-spread deployment of multicast applications such as video-conferencing, distributed interactive simulation, news distribution, and the reliable dissemination of multimedia information over the Internet. Many of these applications require data
delivery guarantees not provided by IP Multicast [4]. Thus, we require multicast transport protocols that work on top of the network multicast service to provide delivery guarantees. Minimally, an end-to-end
multicast service ensures that all packets from each source are delivered to each receiver in the session within a finite amount of time and free of errors and that packets are safely deleted within a finite time.
Additionally, the service may ensure that each packet is delivered only once and in the order sent by the source. Although reliable multicast protocols have developed for quite some time, viable approaches on the
provision of end-to-end reliable multicasting over the mobile networks are just emerging.
Mobility support (i.e., mobile participants) complicates the reliable multicast problem. The main challenges of mobile multicast are the multicast protocol must deal not only with dynamic group membership but also with dynamic member location. Also, because of host movement, the established routes are themselves transient in nature. The packet loss is no longer only because of the network congestion, but also because of host
movement (e.g., handoff duration). 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. Each reliable protocol assumes the existence of multicast routing trees provided by underlying multicast
routing protocols. In the Internet, the tree will be built using such protocols as DVMRP [25], MOSPF [17], Core-Based Tree (CBT) [2], or Protocol-Independent Multicast (PIM) [6], in which implicitly assume static hosts when maintaining the multicast delivery tree. Thus they are not suitable for the mobile environment. For reliability service, the multicast problem facing the future Internet is compounded by its current size and
continuing growth, which makes the handling of acknowledgements a major challenge
commonly referred to as the
acknowledgement (ACK) implosion problem.
This problem is especially severe in mobile networks because of the dynamic wireless channel quality and receiver movement. ACK implosion with a large number of mobile receivers would burden the sender with the problems of loss detection and retransmissions. In an effort to alleviate these problems, the following evolutionary steps have been proposed thus far [14, 21]: l A shift has been proposed from
sender-based to receiver-sender-based error control schemes. Receiver-based schemes move the responsibility of error detection from the sender to the receivers. However, we can have request implosion when a large number of receivers lose a message and each sends a request.
l To further move processing away from the sender, it has been proposed that the effort of processing requests and sending retransmissions be shared among all members of a group, not just the sender. However, it also necessitates
mechanisms to prevent duplicates from ill-coordinated members.
l The scope of recovery messages be restricted to the region that suffered loss, thus preventing the whole group from being pestered by recovery messages from members in loss regions. Indeed, with these steps multicast can potentially achieve better reliability (since more retransmission points are available), and lower average latency (since lost data can often be recovered from a nearby neighbor) compared with unicast.
The IETF Mobile IP Working Group had defined the Mobile IP to support unicast IP routing for mobile hosts in an IP
internetwork [1, 15, 18, 22]. The current version of Mobile IP proposes two
approaches to support mobile multicast: one is bi-directional tunneling; the other is remote subscription. In the former, the
mobile host (MH) receives multicast
datagrams via his home agent (HA) using the unicast Mobile IP tunnels. If the mobility of MHs is low, then using bi-directional
tunneling is simple and low cost. Otherwise, the HA will replicate and deliver tunneled multicast datagrams to each of its mobile hosts through a “long” tunnel. Thus the network bandwidth is wasted and the efficiency of the delivery is worse.
In remote subscription, each MH always re-subscribes to its desired multicast group when it enters a foreign network. The update frequency of the multicast tree depends on how often the mobile handoff. Obviously, remote subscription has better performance if mobile hosts spend more time within a cell, compared with the join and graft latencies [1]. The main advantage of this protocol is that multicast datagrams are always delivered on the shortest paths. However, the overhead is the cost of reconstructing the delivery tree while handoff occurs. In addition, this protocol implicitly assumes that only subscribers of a multicast group can be mobile hosts. The source is not allowed a mobile host.
Bi-directional tunneling hides host mobility from all other members of the group
(therefore, no any overhead in the multicast tree maintenance); remote subscription provides the shortest routes for delivery of multicast datagrams to mobile hosts. RBMoM (Range-Based Mobile Multicast) [15] intends to trade off between the shortest delivery path and the frequency of the multicast tree reconfiguration by controlling theservice range of the multicast home agent (MHA). We can find that remote subscription
and bi-directional tunneling are the extremes of RBMoM. From the point of view of the MHA and the service range concepts, RBMoM is a generalization of both
approaches and a unifying mobile multicast approach. RBMoM can adapt to the
fluctuation of both host movement and the number of mobile group members, and has much better performance than the current two IP mobile multicast solutions.
2. Range-Based Mobile Multicast (RBMoM) RBMoM intends to trade off between the
shortest delivery path and the frequency of the multicast tree reconfiguration. Regardless of what environment parameters (e.g.,
mobility, the number of mobile goup members, etc.) are, 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 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 HA of a MH is never changed. However, the MHA of a MH is changed according to the MH location. The initial MHA of a mobile host is set to be its HA.
Figure 1: Service range of each base station RBMoM addresses a concept of “range” for each MHA. Therange 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. Consider the example shown in Figure 1. If the service range of each router is one (hop distance), the MHA1 can only forward multicast datagrams to its MHs which are roaming in the foreign networks 2,
3, 6 or its current network. Similarly, the MHA2 can only serve its MHs in the networks 8, 12 or its current network. From the grounds of the range concept, we will find both bi-directional tunneling and remote subscription are the extremes of RBMoM. LetR be the service range of a multicast
home agent. Thus,
(1) If we letR = infinite, then RBMoM is the
same as bi-directional tunneling. In this case, the MHA is always the home agent and is never changed. That is, home agents with multiple mobile host group members away from home must replicate and deliver tunneled multicast datagrams to each of them, regardless of at which foreign networks they reside.
(2) If we letR = 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. The current FA can be the new MHA and will subscribe to the desired multicast group. (3) RBMoM is a generalization of the above
cases and a unifying mobile multicast approach. According to the value ofR, a
MHA with multiple mobile host group members can determine whether the datagrams should be tunneled to each of them. Actually, the service rangere stricts the maximal length of the tunnel between a mobile host and its MHA.
Figure 2:Setup the new MHA The MHA information of a mobile host is recorded at its HA. When a MH reaches a foreign network, it locates the FA and
registers with it according to Mobile IP. Then FA contacts its (permanent) HA to locate the MHA serving the MH. The FA calculates the distance to MHA. If it is greater than the service range, a new MHA must be selected
to take over the work. For simplicity, we select the current FA to be the MHA. The new MHA has to subscribe to the multicast group (i.e., the multicast router of the foreign network has to join the multicast tree). The FA (also the new MHA) has to inform the HA to update the MHA currently serving the MH (HA must always record the last MHA location). If the MH is still within the service range of its MHA, the FA just informs the MHA of the FA currently serving it. In order to get a shorter delivery path, if the current FA has already been in the multicast group, we can update the MHA to be the FA even though the MH is still within the service range. In Figure 2, the service range is assumed 1. When the MH is out of the service range of MHA, new MHA (i.e.,
MHA’) is setup to serve the MH and the MHA’ must join the multicast group. It is
notable that all MHAs must be in the multicast group.
The main difference between the HA and the MHA is that the MHA is dynamically
changed according to the location of the MH, but the HA is unchangeable. The MHA offers the multicast service and the HA offers the unicast service. Both need the FA to
cooperate. The current MHA serving the MH is recorded at the home agent. A MHA has to keep a list of mobile hosts which need to beserved. When the MHA is changed, the new MHA must inform the old MHA to delete the record of the mobile host.
