IP組播技術(shù)綜述

近年來，隨著Internet的迅速普及和爆炸性發(fā)展，在Internet上產(chǎn)生了許多新的應(yīng)用，其中不少是高帶寬的多媒體應(yīng)用，譬如 網(wǎng)絡(luò)視頻會議、網(wǎng)絡(luò)音頻/視頻廣播、AOD/VOD、股市行情發(fā)布、多媒體遠程教育、CSCW協(xié)同計算、遠程會診。這就帶來了帶寬的急劇消耗和網(wǎng)絡(luò)擁擠問 題。為了緩解網(wǎng)絡(luò)瓶頸，人們提出各種方案，歸納起來，主要包括以下四種：
●增加互連帶寬；
●服務(wù)器的分散與集群，以改變網(wǎng)絡(luò)流量結(jié)構(gòu)，減輕主干網(wǎng)的瓶頸；
●應(yīng)用QoS機制，把帶寬分配給一部分應(yīng)用；
●采用IP Multicast(譯為組播、多播或多路廣播，下文不加區(qū)分)技術(shù)。
比較而言，IP組播技術(shù)有其獨特的優(yōu)越性——在組播網(wǎng)絡(luò)中，即使用戶數(shù)量成倍增長，主干帶寬不需要隨之增加。這個優(yōu)點使它成為當(dāng)前網(wǎng)絡(luò)技術(shù)中的研究熱點之一。
本文簡單介紹了組播的發(fā)展、分析了組播網(wǎng)絡(luò)的體系結(jié)構(gòu)、算法和協(xié)議，討論了組播技術(shù)的應(yīng)用，總結(jié)了組播技術(shù)的難點，希望通過本文能使讀者對組播技術(shù)有總體的了解。
一、IP組播發(fā)展簡史
20世紀(jì)80年代中期，斯坦福大學(xué)的博士生S. E. Deering發(fā)表Host group: A multicast extension to the Internet Protocol (RFC0966) 和Host extensions for IP Multicasting (RFC0988) 兩篇論文。他總結(jié)出：“OSPF的鏈路狀態(tài)機制完全能被擴展用來支持組播……，RIP的基本機制能被用來作為一種新的距離向量的組播路由協(xié)議的基礎(chǔ)。”這 些論斷提出了IP組播的可能性。
1988年，D. Waltzman, C. Portridge, S. E. Deering發(fā)表題為《距離向量組播路由協(xié)議》的文章（RFC1075），它是組播路由協(xié)議的首次實踐；
1991年12月，S. E. Deering發(fā)表了他的博士論文《數(shù)據(jù)報互連網(wǎng)絡(luò)中的組播路由》（RFC1112）。它奠定了組播網(wǎng)絡(luò)體系結(jié)構(gòu)和路由協(xié)議的基礎(chǔ)。該文也成為Internet組管理協(xié)議（IGMP）的原型；
1994年3月，形成了對OSPF協(xié)議的擴展協(xié)議MOSPF（RFC1584）；
1996年11月，出現(xiàn)了對于基于UNI3.0/3.1的ATM組播網(wǎng)絡(luò)支持協(xié)議（RFC2022）；
1997年9月，有核樹（CBTv2）組播路由體系結(jié)構(gòu)形成（RFC2189）；
1997年11月，組管理協(xié)議IGMPv2得到IETF的批準(zhǔn)，成為標(biāo)準(zhǔn)（RFC2336）；
1998年6月，評估可靠組播傳輸協(xié)議RMTP的IETF標(biāo)準(zhǔn)出臺（RFC2357）；
1998年7月，在制定IPv6地址體系標(biāo)準(zhǔn)時，確定IPv6組播地址分配方案（RFC2373），這為組播技術(shù)在下一代Internet上的應(yīng)用做出了必要的準(zhǔn)備；
1999年10月，Cisco、AT&T、Microsoft制定組播地址動態(tài)客戶分配協(xié)議MADCAP（RFC2730）；
2000年底2001年初，人們著手制定各種組播MIB庫，這標(biāo)志組播技術(shù)正向可管理、可控制方向發(fā)展。
二、組播網(wǎng)絡(luò)的體系結(jié)構(gòu)
組播網(wǎng)絡(luò)體系結(jié)構(gòu)包括：組播的基本工作原理、實現(xiàn)組播的條件、組播的地址分配方案及與MAC地址映射、Internet組管理協(xié)議。
2.1組播的工作原理
組播是一種允許一個或多個發(fā)送者（組播源）發(fā)送單一的數(shù)據(jù)包到多個接收者（一次的，同時的）的網(wǎng)絡(luò)技術(shù)。組播源把數(shù)據(jù)包發(fā)送到特定組播組，而只有屬于該組 播組的地址才能接收到數(shù)據(jù)包。組播可以大大的節(jié)省網(wǎng)絡(luò)帶寬，因為無論有多少個目標(biāo)地址，在整個網(wǎng)絡(luò)的任何一條鏈路上只傳送單一的數(shù)據(jù)包。圖1 為基于三種通訊方式的網(wǎng)絡(luò)結(jié)構(gòu)和數(shù)據(jù)傳遞過程。

A: 單播方式實現(xiàn)組播功能B: 組播方式 C: 廣播實現(xiàn)組播功能圖1 三種通訊方式數(shù)據(jù)傳遞過程比較
從圖1的工作方式可以看出：
單播（Unicast）傳輸：在發(fā)送者和每一接收者之間需要單獨的數(shù)據(jù)信道。如果一臺主機同時給很少量的接收者傳輸數(shù)據(jù)，一般沒有什么問題。但如果有大量 主機希望獲得數(shù)據(jù)包的同一份拷貝時卻很難實現(xiàn)。這將導(dǎo)致發(fā)送者負擔(dān)沉重、延遲長、網(wǎng)絡(luò)擁塞；為保證一定的服務(wù)質(zhì)量需增加硬件和帶寬。
組播（Multicast）傳輸：它提高了數(shù)據(jù)傳送效率。減少了主干網(wǎng)出現(xiàn)擁塞的可能性。組播組中的主機可以是在同一個物理網(wǎng)絡(luò)，也可以來自不同的物理網(wǎng)絡(luò)（如果有組播路由器的支持）。
廣播（Broadcast）傳輸：是指在IP子網(wǎng)內(nèi)廣播數(shù)據(jù)包，所有在子網(wǎng)內(nèi)部的主機都將收到這些數(shù)據(jù)包。廣播意味著網(wǎng)絡(luò)向子網(wǎng)主機都投遞一份數(shù)據(jù)包，不 論這些主機是否樂于接收該數(shù)據(jù)包。然而廣播的使用范圍非常小，只在本地子網(wǎng)內(nèi)有效，因為路由器會封鎖廣播通信。廣播傳輸增加非接收者的開銷。
2.2 實現(xiàn)IP組播的前提條件
實現(xiàn)IP組播傳輸，則組播源和接收者以及兩者之間的下層網(wǎng)絡(luò)都必須支持組播。這包括以下幾方面：
●主機的TCP/IP實現(xiàn)支持發(fā)送和接收IP組播；
●主機的網(wǎng)絡(luò)接口支持組播；
●有一套用于加入、離開、查詢的組管理協(xié)議，即IGMP（v1,v2）；
●有一套IP地址分配策略，并能將第三層IP組播地址映射到第二層MAC地址；
●支持IP組播的應(yīng)用軟件；
●所有介于組播源和接收者之間的路由器、集線器、交換機、TCP/IP棧、防火墻均需支持組播；
目前，IP組播技術(shù)得到硬件、軟件廠商的廣泛支持，比如，新生產(chǎn)的以太網(wǎng)卡幾乎都支持組播；Cisco的路由器不僅支持DVMRP、PIM路由協(xié)議、 IGMP組管理協(xié)議，而且支持Cisco專有Cisco組管理協(xié)議CGMP，再如微軟的Windows 95支持IP組播和IGMPv1，而Windows 98還支持IGMPv2。對于不支持IP組播傳輸?shù)闹虚g路由器采用IP隧道（Tunneling）技術(shù)作為過渡方案。這些說明IP組播技術(shù)的應(yīng)用環(huán)境已基 本具備。
2.3 組播地址分配與MAC地址
在組播通信中，我們需要兩種地址：一個IP組播地址和一個Ethernet組播地址。其中，IP組播地址標(biāo)識一個組播組。由于所有IP數(shù)據(jù)包都封裝在 Ethernet幀中，所以還需要一個組播Ethernet地址。為使組播正常工作，主機應(yīng)能同時接收單播和組播數(shù)據(jù)，這意味著主機需要多個IP和 Ethernet地址。
IP地址方案專門為組播劃出一個地址范圍，在IPv4中為D類地址，范圍是224.0.0.0到239.255.255.255，并將D類地址劃分為局部 鏈接組播地址、預(yù)留組播地址、管理權(quán)限組播地址；在IPv6中為組播地址提供了許多新的標(biāo)識功能，圖2為IPv4和IPv6的組播地址格式，其中IPv6 中特殊域的定義見表1。
圖2IPv4和IPv6的組播地址格式 表1 IPv6中特殊域的定義
局部鏈接地址：224.0.0.0～224.0.0.255，用于局域網(wǎng)，路由器不轉(zhuǎn)發(fā)屬于此范圍的IP包；
預(yù)留組播地址：224.0.1.0～238.255.255.255，用于全球范圍或網(wǎng)絡(luò)協(xié)議；
管理權(quán)限地址：239.0.0.0～239.255.255.255，組織內(nèi)部使用，用于限制組播范圍；
2.3.1 以太網(wǎng)與FDDI組播MAC地址映射
IP組播幀都使用以0X0100.5EXX.XXXX的24位前綴開始的MAC層地址，但只有其中的一半MAC地址可以被IP組播使用，剩下的MAC地址 空間的23位作為第三層IP組播地址進入第二層MAC地址的映射使用。由于第三層IP組播的28位地址不能映射到只有23位的可用MAC地址空間，造成有 32:1的地址不明確，所以主機CPU必須對收到的每一個組播數(shù)據(jù)包做出判斷。這增加了主機CPU的開銷。此外，還產(chǎn)生抑制第二層局域網(wǎng)交換的組播擴散問 題。
2.3.2 令牌環(huán)網(wǎng)組播MAC地址映射
令牌環(huán)網(wǎng)MAC地址格式與標(biāo)準(zhǔn)以太網(wǎng)MAC地址格式位序相反。令牌環(huán)網(wǎng)的缺點是其功能地址位使得它對組播地址映射的不明確性高達228:1，這意味著令牌 環(huán)網(wǎng)上的組播數(shù)據(jù)流將導(dǎo)致令牌環(huán)網(wǎng)點的CPU被環(huán)路上的每一個組播數(shù)據(jù)包中斷，從這個角度來說，令牌環(huán)網(wǎng)不適合于組播。
2.4 組播樹
在單播模型中，數(shù)據(jù)包通過網(wǎng)絡(luò)沿著單一路徑從源主機向目標(biāo)主機傳遞，但在組播模型中，組播源向某一組地址傳遞數(shù)據(jù)包，而這一地址卻代表一個主機組。為了向所有接收者傳遞數(shù)據(jù)，一般采用組播分布樹描述IP組播在網(wǎng)絡(luò)里經(jīng)過的路徑。
組播分布樹有四種基本類型：泛洪法、有源樹、有核樹和Steiner樹。
2.4.1 洪泛法（Flooding）
這是最簡單的向前傳送組播路由算法，并不構(gòu)造所謂的分布樹。其基本原理如下：當(dāng)組播路由器收到發(fā)往某個組播地址的數(shù)據(jù)包后，首先判斷是否是首次收到該數(shù)據(jù)包，如果是首次收到，那么將其轉(zhuǎn)發(fā)到所有接口上，以確保其最終能到達所有接收者；如果不是首次收到，則拋棄該數(shù)據(jù)包。
洪泛法的實現(xiàn)關(guān)鍵是“首次收到”的檢測。這需要維護一個最近通過的數(shù)據(jù)包列表，但無需維護路由表。它適合于對組播需求比較高的場合，并且能做到即使傳輸出 現(xiàn)錯誤，只要還存在一條到接收者的鏈路，則所有接收者都能接收到組播數(shù)據(jù)包。然而，洪泛法不適合用于Internet，因為它不考慮鏈路狀態(tài)，并產(chǎn)生大量 的拷貝數(shù)據(jù)包。此外，對于高速網(wǎng)絡(luò)而言，“首次收到”列表將會很長，占用相當(dāng)大的內(nèi)存；盡管它能保證不對相同的數(shù)據(jù)包進行二次轉(zhuǎn)發(fā)，但不能保證對相同數(shù)據(jù) 包只接收一次。
2.4.2 有源樹
有源樹也稱為基于信源的樹或最短路徑樹（Shortest Path Tree：SPT）。它是以組播源為根構(gòu)造的從根到所有接收者路徑都最短的分布樹。如果組中有多個組播源，則必須為每個組播源構(gòu)造一棵組播樹。由于不同組 播源發(fā)出的數(shù)據(jù)包被分散到各自分離的組播樹上，因此采用SPT有利于網(wǎng)絡(luò)中數(shù)據(jù)流量的均衡。同時，因為從組播源到每個接收者的路徑最短，所以端到端 （end-to-end）的時延性能較好，有利于流量大、時延性能要求較高的實時媒體應(yīng)用。SPT的缺點是：要為每個組播源構(gòu)造各自的分布樹，當(dāng)數(shù)據(jù)流量 不大時，構(gòu)造SPT的開銷相對較大。
2.4.3 共享樹
共享樹也稱RP樹（RPT），是指為每個組播組選定一個共用根（匯合點RP或核心），以RP為根建立的組播樹。同一組播組的組播源將所要組播的數(shù)據(jù)單播到RP，再由RP向其它成員轉(zhuǎn)發(fā)。目前，討論最多同時也是最具代表性的兩種共享樹是Steiner樹和有核樹（CBT）。
Steiner樹是總代價最小的分布樹，它使連接特定圖（graph）中的特定組成員所需的鏈路數(shù)最少。若考慮資源總量被大量的組使用的情況，那么使用資 源較少最終就會減少產(chǎn)生擁塞的風(fēng)險。Steiner樹相當(dāng)不穩(wěn)定，樹的形狀隨組中成員關(guān)系的改變而改變，且對大型網(wǎng)絡(luò)缺少通用的解決方案。所以 Steiner樹只是一種理論模型，而非實用工具。目前，出現(xiàn)了許多Steiner樹的次優(yōu)啟發(fā)式生成算法。
有核樹是由根到所有組成員的最短路徑合并而成的樹。A. Ballardie在1997年9月的《基于核的組播路由體系結(jié)構(gòu)》（Core Based Trees (CBT) Multicast Routing Architecture）(RFC2189和RFC2201)中介紹了有核樹。關(guān)于它的進一步討論見下文。
共享樹在路由器所需存儲的狀態(tài)信息的數(shù)量和路由樹的總代價兩個方面具有較好的性能。當(dāng)組的規(guī)模較大，而每個成員的數(shù)據(jù)發(fā)送率較低時，使用共享樹比較適合。但當(dāng)通信量大時，使用共享樹將導(dǎo)致流量集中及根（RP）附近的瓶頸。
2.5 組管理協(xié)議IGMP
主機使用IGMP通知子網(wǎng)組播路由器，希望加入組播組；路由器使用IGMP查詢本地子網(wǎng)中是否有屬于某個組播組的主機。
●加入組播組
當(dāng)某個主機加入某一個組播組時，它通過“成員資格報告”消息通知它所在的IP子網(wǎng)的組播路由器，同時將自己的IP模塊做相應(yīng)的準(zhǔn)備，以便開始接收來自該組 播組傳來的數(shù)據(jù)。如果這臺主機是它所在的IP子網(wǎng)中第一臺加入該組播組的主機，通過路由信息的交換，組播路由器加入組播分布樹。
●退出組播組
在IGMP v1中，當(dāng)主機離開某一個組播組時，它將自行退出。組播路由器定時(如120秒) 使用“成員資格查詢” 消息向IP子網(wǎng)中的所有主機的組地址（224.0.0.1）查詢，如果某一組播組在IP子網(wǎng)中已經(jīng)沒有任何成員，那么組播路由器在確認(rèn)這一事件后，將不再 在子網(wǎng)中轉(zhuǎn)發(fā)該組播組的數(shù)據(jù)。與此同時，通過路由信息交換，從特定的組播組分布樹中刪除相應(yīng)的組播路由器。這種不通知任何人而悄悄離開的方法，使得組播路 由器知道IP子網(wǎng)中已經(jīng)沒有任何成員的事件延時了一段時間，所以在IGMP v2.0中，當(dāng)每一個主機離開某一個組播組時，需要通知子網(wǎng)組播路由器，組播路由器立即向IP子網(wǎng)中的所有組播組詢問，從而減少了系統(tǒng)處理停止組播的延 時。
三、組播轉(zhuǎn)發(fā)
由于組播源是向組播組發(fā)送數(shù)據(jù)包而非單播模型中的具體目標(biāo)主機，所以組播路由器不能依靠IP包中的目標(biāo)地址來決定如何轉(zhuǎn)發(fā)數(shù)據(jù)包，而必須將組播數(shù)據(jù)包轉(zhuǎn)發(fā) 到多個外部接口上，以便同一組播組的成員都能接收到數(shù)據(jù)包。這使組播轉(zhuǎn)發(fā)比單播轉(zhuǎn)發(fā)更加復(fù)雜。大多數(shù)現(xiàn)有組播路由協(xié)議使用逆向路徑轉(zhuǎn)發(fā)（RPF）機制作為 組播轉(zhuǎn)發(fā)的基礎(chǔ)。
3.1 逆向路徑轉(zhuǎn)發(fā)(Reverse Path Forward: RPF)
當(dāng)組播數(shù)據(jù)包到達路由器時，路由器作RPF檢查，以決定是否轉(zhuǎn)發(fā)或拋棄該數(shù)據(jù)包，若成功則轉(zhuǎn)發(fā)，否則拋棄。
RPF檢查過程如下：
●檢查數(shù)據(jù)包的源地址，以確定該數(shù)據(jù)包經(jīng)過的接口，是否在從源到此的路徑上；
●若數(shù)據(jù)包是從可返回源主機的接口上到達，則RPF檢查成功，轉(zhuǎn)發(fā)該數(shù)據(jù)包到輸出接口表上的所有接口，否則RPF檢查失敗，拋棄該數(shù)據(jù)包。
3.2 組播轉(zhuǎn)發(fā)緩存
對于每一個輸入組播數(shù)據(jù)包進行RPF檢查會導(dǎo)致較大的路由器性能損失。因此，建立組播轉(zhuǎn)發(fā)緩存時，通常由組播路由確定RPF接口。然后將RPF接口變成組播轉(zhuǎn)發(fā)緩存項的輸入接口。一旦RPF檢查程序使用的路由表發(fā)生變化，必須重新計算RPF接口；并更新組播轉(zhuǎn)發(fā)緩存項。
3.3 TTL閾值
每當(dāng)路由器轉(zhuǎn)發(fā)組播數(shù)據(jù)包，IP包中的TTL（Time To Live）值都減1。若數(shù)據(jù)包的TTL減少到0，則路由器將拋棄該數(shù)據(jù)包。TTL閾值可用于組播路由器的各個接口，以防止在該接口上轉(zhuǎn)發(fā)低于TTL閾值的 組播數(shù)據(jù)包。這樣可對組播的范圍加以控制。表2給出典型的初始TTL值和作為不同TTL邊界的路由器接口TTL閾值。
表2 典型的TTL邊界值
范 圍 初始TTL值 TTL閾值
本地網(wǎng) 1 N/A
區(qū)域 15 16
地區(qū) 63 64
全球 127 128

3.4 管理權(quán)限邊界
除TTL閾值外，組播提供另一種稱為管理權(quán)限的地址機制作為邊界，以限制組播信息轉(zhuǎn)發(fā)到域外。管理權(quán)限的組播地址是從239.0.0.0到 239.255.255.255，這段地址被認(rèn)為是本地分配(類似于單播中的192.168.xx.xx)，不能用于Internet。這種機制使得在 Intranet內(nèi)部可重復(fù)使用組播地址，提高組播地址空間的利用率。
四、組播路由協(xié)議
要想在一個實際網(wǎng)絡(luò)中實現(xiàn)組播數(shù)據(jù)包的轉(zhuǎn)發(fā)，必須在各個互連設(shè)備上運行可互操作的組播路由協(xié)議。組播路由協(xié)議可分為三類：密集模式協(xié)議（如DVMRP， PIM-DM）、稀疏模式協(xié)議（如PIM-SM，CBT）和鏈路狀態(tài)協(xié)議（MOSPF），下面分別介紹各個協(xié)議的工作原理。
4.1 距離向量組播路由協(xié)議（Distance Vector Multicast Routing Protocol：DVMRP）
DVMRP由單播路由協(xié)議RIP擴展而來，兩者都使用距離向量算法得到網(wǎng)絡(luò)的拓撲信息，不同之處在于RIP根據(jù)路由表前向轉(zhuǎn)發(fā)數(shù)據(jù)，而DVMRP則是基于 RPF。為了使新加入的組播成員能及時收到組播數(shù)據(jù)，DVMPR采用定時發(fā)送數(shù)據(jù)包給所有的LAN的方法，然而這種方法導(dǎo)致大量路由控制數(shù)據(jù)包的擴散，這 部分開銷限制了網(wǎng)絡(luò)規(guī)模的擴大。另一方面，DVMRP使用跳數(shù)作為計量尺度，其上限為32跳，這對網(wǎng)絡(luò)規(guī)模也是一個限制。目前提出了分層DVMRP，即對 組播網(wǎng)絡(luò)劃分區(qū)域，在區(qū)域內(nèi)的組播可以按照任何協(xié)議進行，而對于跨區(qū)域的組播則由邊界路由器在DVMRP協(xié)議下進行，這樣可大大減少路由開銷。
4.2 開放式組播最短路徑優(yōu)先協(xié)議（Multicast Open Shortest Path First：MOSPF）
MOSPF是一種基于鏈路狀態(tài)的路由協(xié)議，是對單播OSPF協(xié)議的擴展。
同OSPF類似，MOSPF定義了三種級別的路由：
●MOSPF區(qū)域內(nèi)組播路由：用于了解各網(wǎng)段中的組播成員，構(gòu)造（源網(wǎng)絡(luò)S，組G）對的SPT；
●MOSPF區(qū)域間組播路由：用于匯總區(qū)域內(nèi)成員關(guān)系，并在自治系統(tǒng)（AS）主干網(wǎng)（區(qū)域0）上發(fā)布組成員關(guān)系記錄通告，實現(xiàn)區(qū)域間組播包的轉(zhuǎn)發(fā)。
●MOSPF AS 間組播路由：用于跨AS的組播包轉(zhuǎn)發(fā)。
區(qū)域內(nèi)MOSPF利用了鏈路狀態(tài)數(shù)據(jù)庫，對單播OSPF數(shù)據(jù)格式進行擴充，定義了新的鏈路狀態(tài)通告（Link State Advertisement：LSA），使得MOSPF路由器了解哪些組播組在哪些網(wǎng)絡(luò)上。路由器使用Dijkstra算法構(gòu)造（源網(wǎng)絡(luò)S，組G）對的 SPT。MOSPF與DVMRP相比，路由開銷較小，鏈路利用率高，然而Dijkstra算法計算量很大，為了減少路由器的計算量，MOSPF執(zhí)行一種按 需計算方案，即只有當(dāng)路由器收到組播源的第一個組播數(shù)據(jù)包后，才對（S，G）SPT計算，否則利用轉(zhuǎn)發(fā)緩存（cache）中的（S，G）SPT。
MOSPF繼承了OSPF對網(wǎng)絡(luò)拓撲的變化響應(yīng)速度快的優(yōu)點，但拓撲變動使所有路由器的緩存失效重新計算SPT，因而消耗大量路由器CPU資源。這就決定 了MOSPF不適合高動態(tài)性網(wǎng)絡(luò)（組成員關(guān)系變化大、鏈路不穩(wěn)定），而適用于網(wǎng)絡(luò)連接狀態(tài)比較穩(wěn)定的環(huán)境。另外，對于有大量組播源子網(wǎng)絡(luò)的網(wǎng)絡(luò)而言， MOSPF的擴展性問題引起了人們的關(guān)注，有待于進一步研究。
4.3 協(xié)議無關(guān)組播（Protocol Independent Multicast：PIM）
PIM由IDMR（域間組播路由）工作組設(shè)計，顧名思義，PIM不依賴于某一特定單播路由協(xié)議，它可利用各種單播路由協(xié)議建立的單播路由表完成RPF檢查 功能，而不是維護一個分離的組播路由表實現(xiàn)組播轉(zhuǎn)發(fā)。由于PIM無需收發(fā)組播路由更新，所以與其它組播協(xié)議相比，PIM開銷降低了許多。PIM的設(shè)計出發(fā) 點是在Internet范圍內(nèi)同時支持SPT和共享樹，并使兩者之間靈活轉(zhuǎn)換，因而集中了它們的優(yōu)點提高了組播效率。PIM定義了兩種模式：密集模式 (Dense-Mode)和稀疏模式（Sparse-Mode）
4.3.1 PIM-DM
PIM-DM與DVMRP很相似，都屬于密集模式協(xié)議，都采用了“擴散/剪枝”機制。同時，假定帶寬不受限制，每個路由器都想接收組播數(shù)據(jù)包。主要不同之處在于DVMRP使用內(nèi)建的組播路由協(xié)議，而PIM-DM采用RPF動態(tài)建立SPT。
圖3：PIM-DM工作示意圖
該模式適合于下述幾種情況：高速網(wǎng)絡(luò)；組播源和接收者比較靠近，發(fā)送者少，接收者多；組播數(shù)據(jù)流比較大且比較穩(wěn)定。
4.3.2 PIM-SM
PIM-SM與基于“擴散/剪枝”模型的根本差別在于PIM-SM是基于顯式加入模型，即接收者向RP發(fā)送加入消息，而路由器只在已加入某個組播組輸出接口上轉(zhuǎn)發(fā)那個組播組的數(shù)據(jù)包。
PIM-SM采用共享樹進行組播數(shù)據(jù)包轉(zhuǎn)發(fā)。每一個組有一個匯合點（Rendezvous Point: RP），組播源沿最短路徑向RP發(fā)送數(shù)據(jù)，再由RP 沿最短路徑將數(shù)據(jù)發(fā)送到各個接收端。這一點類似于CBT，但PIM-SM不使用核的概念。PIM-SM主要優(yōu)勢之一是它不局限于通過共享樹接收組播信息， 還提供從共享樹向SPT轉(zhuǎn)換的機制。
盡管從共享樹向SPT轉(zhuǎn)換減少了網(wǎng)絡(luò)延遲以及在RP上可能出現(xiàn)的阻塞，但這種轉(zhuǎn)換耗費了相當(dāng)?shù)穆酚善髻Y源，所以它適用于有多對組播數(shù)據(jù)源和網(wǎng)絡(luò)組數(shù)目較少的環(huán)境。
圖4：PIM-SM工作示意圖
4.4 有核樹組播路由協(xié)議（Core-Based Trees: CBT）
CBT的基本目標(biāo)是減少網(wǎng)絡(luò)中路由器組播狀態(tài)，以提供組播的可擴展性。為此，CBT被設(shè)計成稀疏模式（與PIM-SM相似）。CBT使用雙向共享樹，雙向 共享樹以某個核心路由器為根，允許組播信息在兩個方向流動。這一點與PIM-SM不同（PIM-SM中共享樹是單向的，在RP與組播源之間使用SPT將組 播數(shù)據(jù)轉(zhuǎn)發(fā)到RP），所以CBT不能使用RPF檢查，而使用IP包頭的目標(biāo)組地址作檢查轉(zhuǎn)發(fā)緩存。這就要求對CBT共享樹的維護就需非常小心，以確保不會 產(chǎn)生組播路由循環(huán)。
從路由器創(chuàng)建的組播狀態(tài)的數(shù)量來看， CBT比支持SPT的協(xié)議效率高，在具有大量組播源和組的網(wǎng)絡(luò)中，CBT能把組播狀態(tài)優(yōu)化到組的數(shù)量級。
CBT為每個組播組建立一個生成樹，所有組播源使用同一棵組播樹。CBT工作過程大體如下：
●首先選擇一個核，即網(wǎng)絡(luò)中組播組的固定中心，來構(gòu)造一棵CBT；
●主機向這個核發(fā)送join命令；
●所有中間路由器都接收到該命令，并把接收該命令的接口標(biāo)記為屬于這個組的樹；
●如果接收到命令的路由器已是樹中一個成員，那么只要再標(biāo)記一次該接口屬于該組；如果路由器第一次收到j(luò)oin命令，那么它就向核的方向進一步轉(zhuǎn)發(fā)該命令，路由器就需要為每個組保留一份狀態(tài)信息；
●當(dāng)組播數(shù)據(jù)到達一個在CBT樹上的組播路由器時，路由器組播數(shù)據(jù)到樹的核。以保證數(shù)據(jù)能夠發(fā)送到組的所有成員。
CBT將組播擴張限制在接收者范圍內(nèi)，即使第一個數(shù)據(jù)包也無需在全網(wǎng)擴散，但CBT導(dǎo)致核周圍的流量集中，網(wǎng)絡(luò)性能下降。所以某些版本的CBT支持多個核心以平衡負載。
目前CBTv3草案已公布。該方案通過使用CBT邊界路由器（BR）更好地處理域間組播的轉(zhuǎn)發(fā)。CBTv3還引入新的狀態(tài)及單向分支CBT概念。盡管CBT很有代表性，但至今卻幾乎沒有已實現(xiàn)的CBT網(wǎng)絡(luò)。
五、組播應(yīng)用與編程
組播技術(shù)被認(rèn)為是WWW技術(shù)推廣之后出現(xiàn)的最激動人心的網(wǎng)絡(luò)技術(shù)之一。1992年出現(xiàn)支持IP組播的Mbone(組播主干網(wǎng))和Mbone桌面工具； 1993-1996年IP Multicast成為業(yè)界關(guān)注的焦點，然而因發(fā)展條件不成熟使得IP組播只為業(yè)界所關(guān)注；進入1999年以來，IP組播具備了發(fā)展的三個關(guān)鍵條件：支持 組播的路由協(xié)議；基于開放標(biāo)準(zhǔn)的可測試管理協(xié)議；因商業(yè)發(fā)展機遇而進入高速發(fā)展階段。又一次掀起了組播實踐的高潮，下面將有關(guān)組播應(yīng)用作簡單討論：
5.1 組播主干網(wǎng)(Multicast Backbone：Mbone)
Mbone是一個由IETF開發(fā)的運行在Internet上的虛擬重疊網(wǎng)絡(luò)。Mbone的初衷是創(chuàng)建一個半永久的IP組播測試床而不需要等到整個Internet都采用支持組播的路由器。
Mbone跨越幾個洲，用戶數(shù)大約在10000-30000之間。在IETF會議期間，大約有1000個不同的接收主機接入。它成為Internet上傳送聲音和視頻信息的一個重要組成部分。
1992年，組播技術(shù)還處于實驗階段。當(dāng)時提出以IP遂道（Tunneling）聯(lián)結(jié)組播島，組播島是支持組播服務(wù)的區(qū)域，最小的組播島是一個支持組播的LAN。
Mbone使用DVMRP協(xié)議，而DVMRP在UNIX下是由標(biāo)準(zhǔn)守護進程mrouted得以實現(xiàn)，所以許多用戶使用UNIX主機接入Mbone。由于 UNIX主機上的I/O處理能力、對IP遂道的處理能力、網(wǎng)絡(luò)接口數(shù)量等方面都不及商用路由器，這都無形制約了Mbone的發(fā)展。
Mbone自從出現(xiàn)就不斷發(fā)展。今天，從基于mrouted的UNIX主機到商用路由器的遷移已超過了50%；Mbone也采用剪枝、封裝等技術(shù)。新的域間組播路由協(xié)議和轉(zhuǎn)發(fā)算法、流量控制與管理、可靠組播也將對Mbone產(chǎn)生影響。
5.2 組播應(yīng)用程序接口與編程
RFC1112推薦了一些支持組播的應(yīng)用程序接口：
●加入一個組播組；
●離開一個組播組；
●為調(diào)整范圍對一個組播數(shù)據(jù)的IP TTL值進行設(shè)定；
●為組播傳輸和接收設(shè)定本地的接口；
●禁止輸出的組播數(shù)據(jù)回送。
現(xiàn)在，許多TCP/IP實現(xiàn)都支持RFC1112所提到的要求，下面簡要介紹UNIX(Berkeley Socket)和Windows(Winsock) API。
5.2.1 Berkeley Socket組播API
所有Berkeley Socket API都采用setsockopt()的“套接字選項”功能來設(shè)置（對于某些選項，getsockopt()功能可用來獲得當(dāng)前的設(shè)置）。表3描述了 Berkeley BSD的set sockopt()/getsockopt()組播命令。
表3 BSD setsockopt()/getsockopt()組播命令的說明
setsockopt()/getsockopt()組播命令 命令說明
IP_MULTICAST_TTL 設(shè)置輸出組播數(shù)據(jù)的TTL值
IP_ADD_MEMBERSHIP 在指定接口上加入組播組
IP_DROP_MEMBERSHIP 退出組播組（在IGMPv2中實現(xiàn)）
IP_MULTICAST_IF 獲取默認(rèn)接口或設(shè)置接口
IP_MULTICAST_LOOP 禁止組播數(shù)據(jù)回送

對于套接字編程，首先要使用函數(shù)socket()建立一個數(shù)據(jù)包套接字，然后用bind()函數(shù)將套接字與一個地址和端口號連接起來。
為了發(fā)送一個組播數(shù)據(jù)包，需要在sendto()調(diào)用中指定一個組播地址作為目的地址（所有IP地址都使用網(wǎng)絡(luò)字節(jié)順序）。
為了接收一個組播數(shù)據(jù)包，需要在recvfrom()調(diào)用中指定所要接收的組播地址。
IP_MULTICAST_TTL允許將隨后的組播數(shù)據(jù)的TTL設(shè)定成從0到255之間的任何值，例如：
u_char ttl;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_TTL,&ttl,sizeof(ttl));
關(guān)于TTL的討論見上文。
通過IP_MULTICAST_IF,系統(tǒng)管理員可在安裝的時候為組播創(chuàng)建默認(rèn)的接口（為從一個給定的網(wǎng)絡(luò)接口并發(fā)傳送，一個網(wǎng)絡(luò)接口會忽略這個默認(rèn)值）。例如：
struct in_addr addr;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_IF,&addr,sizeof(addr));
在這里，addr是希望輸出接口的本地IP地址，可使用一個INADDR_ANY地址來回送到默認(rèn)的接口。
當(dāng)組播組中的一臺主機發(fā)送組播數(shù)據(jù)到輸出接口時，默認(rèn)的IP層將為本地回送數(shù)據(jù)的拷貝。
IP_MULTICAST_LOOP網(wǎng)絡(luò)參數(shù)控制IP層是否回送所送的數(shù)據(jù)。例如：
u_char loop;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_LOOP,&loop,sizeof(loop));
將loop設(shè)置為0則禁止回送，設(shè)置為1則允許回送。
為了能夠接收IP組播數(shù)據(jù)，主機必須加入某個或多個組播組，程序通過使用IP_ADD_MEMBERSHIP網(wǎng)絡(luò)接口參數(shù)向主機提出加入組播組的申請。例如：
struct ip_mreq
{struct in_addr imn_multiaddr; /* multicast group to join */
struct in_addr imr_interface; /* interface to join on */
}mreq;
setsockopt(sock,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq));
一個組的成員是與一個單一的網(wǎng)絡(luò)接口相聯(lián)系；主機可在不止一個網(wǎng)絡(luò)接口上加入相同的組。若選擇默認(rèn)組播接口，要將imr_interface設(shè)置為INADDR_ANY;若選擇主機其中一個本地地址，要將imr_interface設(shè)置為特定的組播接口。
若撤消一個成員資格，使用IP_DROP_MEMBERSHIP
struct ip_mreq mreq;
setsockopt(sock,IPPROTP_IP,IP_DROP_MEMBERSHIP,&mreq,sizeof(sreq));
其中mreq包含了在IP_ADD_MEMBERSHIP命令中相同的值。
5.2.2 Windows Socket組播API
基于Winsock1.1的組播編程與Berkeley Socket類似，這里不再贅述。Winsock2是Winsock1.1的擴展，除兼容Berkeley Sockets組播API外，它還定義了一套支持IP組播的協(xié)議獨立API，如表4所示：
表4 WinSock 2的協(xié)議獨立組播API說明
WSAEnum Protocol() 獲得協(xié)議信息結(jié)構(gòu)(WASPROTOCOL_INFO)
WSASocket() 設(shè)置組播類型
WSAJoinLeaf 加入組播組并指定角色(發(fā)送者/接收者)
WSAIoctl(…SIO_MULTICAST_SCOPE…) 設(shè)置IP TTL
WSAIoctl(…SIO_MULTICAST_LOOPBACK…) 禁止組播數(shù)據(jù)回送

在Winsock2中，定義了“數(shù)據(jù)平面”（Data Plane）和“控制平面”(Control Plane)的概念，其中，數(shù)據(jù)平面決定在不同的網(wǎng)絡(luò)成員之間數(shù)據(jù)如何傳送；控制平面定義網(wǎng)絡(luò)成員的組織方式； 這兩方面的特征既可以是“有根的”（Rooted）,也可以是“無根的”（Nonrooted）。在“有根的”控制平面內(nèi)，存在一個特殊的組播組成員，稱 作C_root（根節(jié)點），其余的組成員稱作C_leaf(葉節(jié)點)。對“無根的”控制平面而言，只存在葉節(jié)點。
在“有根的”平面中，根節(jié)點負責(zé)組播的建立，以及同任意數(shù)量葉節(jié)點的連接。葉節(jié)點可申請加入一個特定的組播組。數(shù)據(jù)傳送只能在根節(jié)點和葉節(jié)點之間進行，根節(jié)點將數(shù)據(jù)組播到每個葉節(jié)點。
在“無根的”平面中，只存在葉節(jié)點，它們可以任意加入一個組播組。從葉節(jié)點發(fā)送的數(shù)據(jù)會組播到每一個葉節(jié)點。
由于篇幅所限，有關(guān)Winsock API的進一步討論，請參閱參考文獻[3]、[5]和MSDN。
六、IP組播中存在的問題與發(fā)展
6.1 組播的可靠性
IP組播數(shù)據(jù)包典型使用用戶數(shù)據(jù)報協(xié)議（UDP），而UDP是一種“盡力而為”（Best-effort）協(xié)議。因此，IP組播應(yīng)用必定會遇到數(shù)據(jù)包丟失和亂序問題。
從端到端傳輸延遲和可靠性方面考慮，組播應(yīng)用可大致分為三類：
1）實時交互應(yīng)用，如視頻會議系統(tǒng)，這類應(yīng)用對可靠性要求相對較低，但對端到端傳輸延遲和網(wǎng)絡(luò)抖動的要求很高。
2）實時非交互型應(yīng)用，如數(shù)據(jù)廣播，這類應(yīng)用傳輸延遲要求相對前一類應(yīng)用較低，但在一定延遲范圍內(nèi)，卻對可靠性提出更高要求。
3）非實時應(yīng)用，如軟件分發(fā)，這類應(yīng)用中，可靠性是最基本的要求，在滿足可靠性要求的前提下，必須保證傳輸延遲在可接受的范圍之內(nèi)。
對于不同類型的應(yīng)用必須在確認(rèn)方式（肯定確認(rèn)ACK和否定確認(rèn)NACK），集中確認(rèn)與分布確認(rèn)、重傳機制、重傳范圍、流量控制、擁塞控制、end-to-end延遲和廣播延遲、網(wǎng)絡(luò)抖動、可伸縮性與網(wǎng)絡(luò)的異構(gòu)性等方面做出綜合考慮，提出相應(yīng)的解決辦法。
迄今為止，盡管在廣域網(wǎng)環(huán)境中已經(jīng)存在許多可靠組播協(xié)議，包括可靠組播協(xié)議RMP（Reliable Multicast Protocol）、可擴展可靠組播SRM(Scalable Reliable Multicast)、基于日志的可靠組播LBRM（Log-Based Reliable Multicast）和可靠組播傳輸協(xié)議RMTP(Reliable Multicast Transport Protocol)，但組播的可靠性研究仍然是國際上的重點研究課題之一。
6.2 組播的安全性
安全組播就是只有注冊的發(fā)送者才可以向組發(fā)送數(shù)據(jù)；只有注冊的接收者才可以接收組播數(shù)據(jù)。然而IP組播很難保證這一點。
首先，IP組播使用UDP，任何主機都可以向某個組播地址發(fā)送UDP包，并且低層組播機構(gòu)將傳送這些UDP包到所有組成員。其次，Internet缺少對于網(wǎng)絡(luò)層的訪問控制。第三，組成員可以隨時加入/退出組播組。這幾點使組播安全性問題同組播的可靠性問題一樣難以解決。
總的來說，安全組播可分為集中式和分布（分層）式密鑰管理體系。目前，對于組播安全性問題已有Naïve密鑰管理、Iolus、Nortel框架和SRM （Secure Reliable Multicast）等解決方案。Matthew J. Mayer等人在[29]中提出了安全組播評估標(biāo)準(zhǔn)，回顧并討論了安全組播體系結(jié)構(gòu)、組密鑰管理和信源認(rèn)證等問題。然而現(xiàn)有的解決方案都不同程度的存在不 足，安全組播仍然是一個技術(shù)難點。
6.3 網(wǎng)絡(luò)的異構(gòu)性導(dǎo)致組播的復(fù)雜性
Internet是一個異構(gòu)網(wǎng)絡(luò)，這種異構(gòu)性表現(xiàn)在很多方面。第一，Internet的低層硬件平臺千差萬別，可以是Ethernet、ATM、 FDDI、令牌環(huán)網(wǎng)、幀中繼、串行鏈路（PSTN、xDSL）、無線網(wǎng)絡(luò)、衛(wèi)星網(wǎng)絡(luò)、移動網(wǎng)絡(luò)等等。這些低層網(wǎng)絡(luò)具有不同的帶寬、硬件存取控制方式、時延 特征。在多鏈路情況下，各鏈路的帶寬與代價也可能不同。另外，某些網(wǎng)絡(luò)平臺的數(shù)據(jù)鏈路具有非對稱性，比如xDSL和衛(wèi)星網(wǎng)絡(luò)。第二，主機的硬件處理能力和 操作系統(tǒng)各不相同。就操作系統(tǒng)而言，主要的操作系統(tǒng)，如UNIX、Windows、MacOS、OS2有不同的變種和版本，對IP組播的支持程度、進程的 調(diào)度與管理、TCP/IP的實現(xiàn)方式和API都有差異。第三，互連設(shè)備的差異。路由器、交換機、網(wǎng)絡(luò)服務(wù)器在背板能力、包轉(zhuǎn)發(fā)率、支持的路由協(xié)議的互操作 性。這些異構(gòu)性都導(dǎo)致在實現(xiàn)IP組播網(wǎng)絡(luò)中的復(fù)雜性。
比如：網(wǎng)絡(luò)中不同部分的帶寬不同、接收者的處理要求和處理能力不同，而所有接收者都要與同一組播源交互，這就要求采取某些方法使得每一個接收者接收到與其 接收能力和從組播源到接收者之間帶寬相適合的數(shù)據(jù)流（即公平性）。再比如：ATM面向連接的特點在IP組播傳輸中帶來了新的問題，這使IP組播與ATM組 播具有不同特點。
所以，在設(shè)計IP組播網(wǎng)絡(luò)時，必須充分考慮到網(wǎng)絡(luò)的異構(gòu)性。
七、結(jié)束語
本文從組播的產(chǎn)生和發(fā)展出發(fā)，介紹了組播網(wǎng)絡(luò)的體系結(jié)構(gòu)、算法和協(xié)議，討論了組播技術(shù)的應(yīng)用，總結(jié)了組播技術(shù)的難點。隨著高寬帶多媒體應(yīng)用的迫切需求、ISP、ICP對IP組播網(wǎng)絡(luò)的支持、設(shè)備提供商的投入、各種專業(yè)組織的介入，IP組播技術(shù)必然有著廣闊的發(fā)展前景。