基于組播代理的移動(dòng)組播實(shí)現(xiàn)機(jī)制研究

2007/10/09

圖1 單播、廣播和組播的傳輸方式

　　目前此類業(yè)務(wù)在IP網(wǎng)上幾乎都是采用IP組播的方式來(lái)實(shí)現(xiàn)的。IP網(wǎng)通信包括三種通信方式（如圖1所示）：?jiǎn)尾ィ║nicast）、廣播（Broadcast）和組播（Multicast）。單播是指源主機(jī)向指定單個(gè)目標(biāo)主機(jī)發(fā)送數(shù)據(jù)信息，單播連接是一一對(duì)應(yīng)的，即一個(gè)發(fā)送者只能對(duì)應(yīng)一個(gè)接收者；廣播指源主機(jī)向一個(gè)網(wǎng)絡(luò)段中的所有主機(jī)發(fā)送數(shù)據(jù)信息，即該網(wǎng)段所有主機(jī)都可以接收這個(gè)數(shù)據(jù)信息；組播介于單播、廣播之間，源主機(jī)向網(wǎng)絡(luò)中特定的一組主機(jī)發(fā)送數(shù)據(jù)信息，這些主機(jī)是靠組播地址來(lái)指定的。

　　相對(duì)于單播，組播技術(shù)可以實(shí)現(xiàn)一對(duì)多，或者是多對(duì)多的數(shù)據(jù)傳輸，極大地減輕了網(wǎng)絡(luò)和源主機(jī)的負(fù)載，提高了傳輸效率；相對(duì)于廣播來(lái)說(shuō)，組播技術(shù)能靈活地將信息發(fā)給指定的組成員，而不是網(wǎng)段中所有的主機(jī)，同時(shí)通常廣播僅限制在本網(wǎng)段內(nèi)，不能通過(guò)路由器進(jìn)行轉(zhuǎn)發(fā)。

二、移動(dòng)組播的研究現(xiàn)狀

　　2.1 移動(dòng)組播面臨的問(wèn)題

　　在IP網(wǎng)絡(luò)中，每個(gè)組播成員的IP地址在一個(gè)組播會(huì)話中是固定不變的，因此，IP網(wǎng)絡(luò)組播對(duì)組播組成員的管理、建立和維護(hù)組播樹(shù)相對(duì)比較簡(jiǎn)單；在移動(dòng)網(wǎng)絡(luò)中，即使在會(huì)話過(guò)程中組播組成員沒(méi)有增減，但是由于每個(gè)成員的地址在不斷變化，也會(huì)導(dǎo)致整個(gè)組播樹(shù)的不穩(wěn)定。這將使移動(dòng)網(wǎng)絡(luò)組播組的維護(hù)和管理變得較為復(fù)雜。

　　由于組成員的移動(dòng)性，移動(dòng)組播在實(shí)現(xiàn)過(guò)程中主要存在以下幾個(gè)問(wèn)題：

　　(1) 組播樹(shù)的維護(hù)管理

　　現(xiàn)有組播路由協(xié)議，如DVMRP（距離矢量組播路由選擇協(xié)議）、MOSPF（Multicast-Open Shortest Path First）、CBT（核心樹(shù)）等都是基于組成員地址是固定的這樣一個(gè)前提，如果組成員發(fā)生移動(dòng)，這些協(xié)議處理機(jī)制采用對(duì)原有組成員進(jìn)行“剪枝”，而后新增一個(gè)組成員的方式進(jìn)行管理。這種方式對(duì)于IP網(wǎng)絡(luò)組成員幾乎不移動(dòng)的情況是實(shí)用的，但是對(duì)于移動(dòng)網(wǎng)絡(luò)，由于組成員頻繁移動(dòng)，會(huì)導(dǎo)致組播樹(shù)頻繁地進(jìn)行“剪枝”和新增組成員。因此，移動(dòng)網(wǎng)絡(luò)中組播樹(shù)非常不穩(wěn)定，同時(shí)組播樹(shù)的管理和維護(hù)會(huì)產(chǎn)生大量開(kāi)銷。

　　(2) 組成員的切換延時(shí)

　　IETF的移動(dòng)IP協(xié)議定義了家鄉(xiāng)代理(home Agent，簡(jiǎn)稱HA)、外地鏈路、外地代理(foreign Agent，簡(jiǎn)稱FA)、通信對(duì)端等概念，一個(gè)移動(dòng)節(jié)點(diǎn)擁有兩個(gè)IP地址：家鄉(xiāng)地址和轉(zhuǎn)交地址。節(jié)點(diǎn)在移動(dòng)過(guò)程中，家鄉(xiāng)地址不改變，發(fā)送到該節(jié)點(diǎn)的數(shù)據(jù)都通過(guò)家鄉(xiāng)地址與轉(zhuǎn)交地址之間的隧道轉(zhuǎn)發(fā)給移動(dòng)節(jié)點(diǎn)。當(dāng)組成員切換時(shí)，包括網(wǎng)絡(luò)鏈路間切換的固有時(shí)延，以及重新加入組播組以及建立組播轉(zhuǎn)發(fā)樹(shù)的時(shí)延，都將導(dǎo)致組播成員丟包。

　　這是移動(dòng)組播相對(duì)于IP組播最突出的兩個(gè)問(wèn)題，在設(shè)計(jì)移動(dòng)組播協(xié)議過(guò)程中需要重點(diǎn)加以考慮。

　　2.2 現(xiàn)有的移動(dòng)組播協(xié)議

　　移動(dòng)IP協(xié)議中提出了兩種組播方案：“雙向隧道”和“遠(yuǎn)程加入”，以下對(duì)這兩種協(xié)議進(jìn)行說(shuō)明和簡(jiǎn)單比較。

　　2.2.1 雙向隧道

　　雙向隧道(bi-directional tunnel，簡(jiǎn)稱MIP-BT)是指在移動(dòng)節(jié)點(diǎn)與家鄉(xiāng)代理之間建立雙向隧道，移動(dòng)節(jié)點(diǎn)通過(guò)雙向隧道加入/退出組播組，并且通過(guò)該隧道發(fā)送和接收組播包。移動(dòng)節(jié)點(diǎn)通過(guò)隧道向家鄉(xiāng)代理發(fā)送IGMP（組管理協(xié)議）報(bào)文，請(qǐng)求加入組播組。而后家鄉(xiāng)代理加入組播樹(shù)中，并將組播包通過(guò)隧道以單播的方式發(fā)送給移動(dòng)節(jié)點(diǎn)；移動(dòng)節(jié)點(diǎn)向組播組發(fā)送數(shù)據(jù)時(shí)，也是首先通過(guò)隧道將組播包發(fā)送給家鄉(xiāng)代理，然后由家鄉(xiāng)代理以組播的形式發(fā)送該組播包。

　　雙向隧道方式有效地解決了因組成員切換給組播樹(shù)造成頻繁調(diào)整的問(wèn)題，減少了計(jì)算量和通信負(fù)擔(dān)。但是，雙向隧道也存在三角路由以及“隧道聚集”問(wèn)題。三角路由不是最佳路由，會(huì)給鏈路帶來(lái)很大的開(kāi)銷；外地代理有可能通過(guò)隧道從不同的家鄉(xiāng)代理收到多個(gè)重復(fù)的組播數(shù)據(jù)包從而產(chǎn)生“隧道聚集”問(wèn)題，導(dǎo)致鏈路帶寬資源的嚴(yán)重浪費(fèi)。

　　2.2.2 遠(yuǎn)程加入

　　遠(yuǎn)程加入(remote subscription,簡(jiǎn)稱MIP-RS)是指移動(dòng)節(jié)點(diǎn)改變地址后重新加入到組播組中，并由組播協(xié)議重新計(jì)算組播樹(shù)。遠(yuǎn)程加入方式最大的優(yōu)點(diǎn)在于無(wú)須建立外地代理和家鄉(xiāng)代理之間的隧道，因此也就不存在隧道聚集問(wèn)題。同時(shí)，組播數(shù)據(jù)包能夠沿著最優(yōu)路徑進(jìn)行轉(zhuǎn)發(fā)，避免了三角路由問(wèn)題。

　　遠(yuǎn)程加入存在的問(wèn)題是：首先，節(jié)點(diǎn)每次移動(dòng)都需要重新計(jì)算并建立整個(gè)組播樹(shù)，這會(huì)影響組播樹(shù)的穩(wěn)定性，給組播樹(shù)的管理和維護(hù)帶來(lái)較大的開(kāi)銷；其次，在頻繁切換過(guò)程中，退出和重新加入組播組都會(huì)產(chǎn)生較大的切換時(shí)延，從而導(dǎo)致播包丟失，影響組播應(yīng)用的可靠性，尤其是在節(jié)點(diǎn)快速移動(dòng)、頻繁切換的情況下這個(gè)問(wèn)題尤為突出。

三、基于代理的移動(dòng)組播協(xié)議ABMoM

　　針對(duì)雙向隧道和遠(yuǎn)程加入存在的問(wèn)題，本文提出了一個(gè)基于區(qū)域代理的移動(dòng)組播的實(shí)現(xiàn)機(jī)制——ABMoM（Agent-based mobile multicast ）。

　　3.1 ABMoM的基本原理

　　ABMoM中引入了組播代理（multicast agent，簡(jiǎn)稱MA）的概念，MA可以代替移動(dòng)節(jié)點(diǎn)加入某個(gè)組播組，接收該組播組的數(shù)據(jù)。移動(dòng)節(jié)點(diǎn)（mobile host，簡(jiǎn)稱MH）在一個(gè)子網(wǎng)中，如果要加入某個(gè)組播組，就向當(dāng)?shù)刈泳W(wǎng)的MA發(fā)送一個(gè)加入請(qǐng)求，在MA向組播路由器發(fā)送加入組播組的請(qǐng)求后，通過(guò)組播路由協(xié)議建立到該MA的組播樹(shù)。

　　MA接收到組播組的數(shù)據(jù)包后，通過(guò)單播的方式發(fā)送給MH，而MH發(fā)往組播組的數(shù)據(jù)也通過(guò)MA來(lái)轉(zhuǎn)發(fā)。整個(gè)ABMoM的原理如圖2所示。

圖2 ABMoM網(wǎng)絡(luò)結(jié)構(gòu)

　　3.2 ABMoM組播組加入機(jī)制

　　在ABMoM協(xié)議中，子網(wǎng)的組播代理MA擔(dān)任了重要角色，MA負(fù)責(zé)子網(wǎng)中所有組播組成員管理。

　　移動(dòng)節(jié)點(diǎn)MH加入某個(gè)組播組，首先向MA發(fā)送一個(gè)組播組加入請(qǐng)求，該請(qǐng)求包含該組的組播地址以及MH的地址。MA將首先查閱本地維護(hù)的活躍組播組列表，如果發(fā)現(xiàn)MH要加入的組播組在本地活躍的組播組列表中，就將MH的地址添加入該組播組成員列表中，一旦接收到該組播組的數(shù)據(jù)即可通過(guò)單播的方式轉(zhuǎn)發(fā)給MH。

　　如果MA查閱到MH請(qǐng)求加入的組播地址并不在本地活躍的組播組中，將向上游的組播路由器發(fā)送IGMP報(bào)文，請(qǐng)求加入該組播組。加入成功后，MA在本地的活躍組播組列表中添加該組播地址，并將MH加為該組播組的成員。當(dāng)后續(xù)還有MH要加入該組播組時(shí)，MA無(wú)須再向上游路由器發(fā)送報(bào)文，而是直接將該MH加入到該組播組的成員列表中，進(jìn)行單播數(shù)據(jù)轉(zhuǎn)發(fā)即可。

　　在ABMoM機(jī)制中，MA不僅擔(dān)當(dāng)了部分組播路由器的角色，同時(shí)負(fù)責(zé)組播子樹(shù)的管理。而在區(qū)域內(nèi)發(fā)生組播成員的加入和退出時(shí)，一般情況下都不會(huì)影響整個(gè)組播樹(shù)，只有當(dāng)該區(qū)域第一個(gè)組播組成員加入和最后一個(gè)組播組成員離開(kāi)時(shí)，才需要重建整個(gè)組播樹(shù)，因此ABMoM可以保證組播樹(shù)的相對(duì)穩(wěn)定。

　　3.3 ABMoM組播組退出機(jī)制

　　在IGMP協(xié)議中，IGMPv1通過(guò)組播路由器發(fā)送查詢報(bào)文來(lái)查詢某一個(gè)端口下是否還有組播組成員；IGMPv2則由組播組成員主動(dòng)向組播路由器發(fā)送退出組的消息。當(dāng)一個(gè)MH要退出某個(gè)組播組時(shí)，ABMoM也有兩種機(jī)制進(jìn)行處理： MH主動(dòng)向MA發(fā)送退出組播組的請(qǐng)求；MA主動(dòng)發(fā)現(xiàn)MH已經(jīng)退出組播組。

　　如圖3所示，當(dāng)MH要退出某個(gè)組播組時(shí)，主動(dòng)向MA發(fā)送退出請(qǐng)求，MA接收到該請(qǐng)求，查詢?cè)摻M播組的成員列表并將該成員從列表中刪除。如果該MH非該組播組的最后一個(gè)成員，MA只是簡(jiǎn)單地停止向該MH轉(zhuǎn)發(fā)數(shù)據(jù)包；如果該MH是該組播組的最后一個(gè)成員，則當(dāng)它退出后，該區(qū)域中無(wú)該組的其他成員，為了節(jié)省帶寬資源，MA需要向上游路由器發(fā)送退出請(qǐng)求，或者是由上游路由器進(jìn)行自動(dòng)“剪枝”。MA并非在該組最后一個(gè)成員離開(kāi)后就立即發(fā)送退出請(qǐng)求，而是要滯后一段時(shí)間查看該區(qū)域是否有新的MH加入。這種機(jī)制對(duì)于移動(dòng)組播是非常必要的，可避免MA因MH的移動(dòng)而頻繁加入退出組播組，導(dǎo)致組播樹(shù)的不穩(wěn)定。

　　在另一種機(jī)制中，MH不向MA發(fā)送退出請(qǐng)求而直接拒收自MA轉(zhuǎn)發(fā)的組播數(shù)據(jù)包，因此MA必須有主動(dòng)發(fā)現(xiàn)MH退出組的機(jī)制。在ABMoM機(jī)制種，MA定期向組播組成員發(fā)送查詢報(bào)文，MH如果仍然在組播組活躍，則在接收查詢報(bào)文后立刻響應(yīng)一個(gè)活躍報(bào)文告知MA，否則MH對(duì)MA發(fā)送過(guò)來(lái)的查詢報(bào)文不做任何響應(yīng)。MA在發(fā)送完查詢報(bào)文后，在本地啟動(dòng)一個(gè)計(jì)時(shí)器，如果計(jì)時(shí)器超時(shí)還沒(méi)收到響應(yīng)的活躍報(bào)文，MA將向該MH再次發(fā)送查詢報(bào)文，如果連續(xù)三次都未收到MH的活躍報(bào)文，則MA認(rèn)為該MH已經(jīng)退組，將把MH從組播組成員列表中刪除。

圖3 ABMoM中MH退出組播組

　　3.4 ABMoM的切換機(jī)制

　　移動(dòng)組播協(xié)議關(guān)鍵是在節(jié)點(diǎn)移動(dòng)狀態(tài)下要保證組播數(shù)據(jù)能及時(shí)地傳送到節(jié)點(diǎn)。

　　當(dāng)一個(gè)組播組成員改變網(wǎng)絡(luò)中位置的時(shí)候，ABMoM協(xié)議的處理機(jī)制是：該節(jié)點(diǎn)在原有的網(wǎng)絡(luò)中退出該組播組，然后在新的網(wǎng)絡(luò)中又加入組播組。

　　如圖4所示，B為一個(gè)移動(dòng)節(jié)點(diǎn)，在網(wǎng)絡(luò)A中加入了組播組224.2.0.1，并通過(guò)C（C為網(wǎng)絡(luò)A中的MA）進(jìn)行組播代理。當(dāng)B移動(dòng)到網(wǎng)絡(luò)A′后，B向網(wǎng)絡(luò)A′中的組播代理C′發(fā)送加入組播組224.2.0.1的請(qǐng)求。

　　在極端的情況下，網(wǎng)絡(luò)A中組播組224.2.0.1只有C一個(gè)組播成員且網(wǎng)絡(luò)A中后來(lái)也無(wú)其他MH加入組播組224.2.0.1，C將通知上游路由器退出組播組224.2.0.1，這時(shí)候需要重新構(gòu)建組播樹(shù)；而在網(wǎng)絡(luò)A′中，原來(lái)也沒(méi)有組播組224.2.0.1的組成員，當(dāng)B要求加入組播組224.2.0.1時(shí)，網(wǎng)絡(luò)A′中的組播代理C′需要向上游網(wǎng)絡(luò)路由器發(fā)送加入組播組224.2.0.1的請(qǐng)求，然后向B轉(zhuǎn)發(fā)該組的組播數(shù)據(jù)包，這時(shí)的切換有可能因?yàn)榍袚Q時(shí)延而導(dǎo)致組播數(shù)據(jù)包丟失。

　　在組播組成員相對(duì)集中的情況下，ABMoM性能將會(huì)好很多。B不是網(wǎng)絡(luò)A中組播組224.2.0.1中最后一個(gè)成員，在離開(kāi)網(wǎng)絡(luò)A時(shí)僅需要組播代理C將B從組播組成員列表中刪除，而對(duì)整個(gè)組播樹(shù)沒(méi)有任何影響；而B(niǎo)在移動(dòng)到網(wǎng)絡(luò)A′中后，如果A′中已經(jīng)有組播組224.2.0.1的組成員，B向C′申請(qǐng)加入該組播組，那么C′只需將B加入本地的組播成員列表中即可，這樣B在網(wǎng)絡(luò)中移動(dòng)時(shí)可不影響組播樹(shù)而退出、進(jìn)入組播組。同時(shí)，ABMoM要求區(qū)域組播代理MA具有一定的數(shù)據(jù)包緩沖能力，可以在一定程度上處理因移動(dòng)切換時(shí)延帶來(lái)的丟包問(wèn)題。

圖4 ABMoM中MH在網(wǎng)絡(luò)中移動(dòng)

四、 結(jié)論

　　ABMoM引入了組播代理MA的概念，在組播組成員相對(duì)集中的環(huán)境中，可以很好地解決移動(dòng)網(wǎng)絡(luò)中組播面臨的問(wèn)題。

　　與雙向隧道的移動(dòng)組播機(jī)制相比，ABMoM不需要在家鄉(xiāng)代理和外地代理之間建立雙向隧道，可以較好地避免“隧道聚集”和三角路由問(wèn)題；與遠(yuǎn)程加入方式相比，ABMOM無(wú)須為移動(dòng)節(jié)點(diǎn)每次加入和退出重新計(jì)算組播樹(shù)，避免了組播樹(shù)的頻繁重建，減少了網(wǎng)絡(luò)資源消耗，同時(shí)ABMoM中MA采用了數(shù)據(jù)包緩沖機(jī)制，在一定程度上可以解決因網(wǎng)絡(luò)切換造成的丟包問(wèn)題。

參考文獻(xiàn)

　　[1] “Internet Protocol (IP) Multicast Technology Overview”, Cisco Systems,2000
　　[2] Beau Williamson, “Developing IP Multicast Networks, Volume1,” Cisco Press, Jan.2000.
　　[3] Perkins C. IP mobility support for IPv4. RFC 3344, Internet Engineering Task Force, 2002.
　　[4] Johnson D, Perkins C, Arkko J. Mobility support in IPv6. Internet Draft, draft ietf mobileip ipv6 21.txt, Internet Engineering Task Force, 2003.
　　[5] 吳茜,吳建平,徐恪,劉瑩, 移動(dòng)Internet中的IP組播研究綜述,軟件學(xué)報(bào)，/2003/14(07)
　　[6] Johnson D, Perkins C, Arkko J. Mobility support in IPv6. RFC 3775, 2004.
　　[7] Chikarmane V, Williamson C, Bunt R, Mackrell W. Multicast support for mobile hosts using mobile IP: Design issues and proposed architecture. Mobile Networks and Applications, ACM/Baltzer Mobile Networks and Applications, 1998,3(4):365~379.

中國(guó)聯(lián)通網(wǎng)站