依賴源匯聚點的組播協議

Source Rendezvous Points Dependent Multicast Protocol

摘要：域間組播一直是大范圍內部署組播時需要考慮的主要因素。依賴源匯聚點組播是一種基于Chord查找協議的簡單有效的域間組播方案，方案中接收者的指定路由器(DR)使用Chord協議獲得源RP地址，并加入源RP樹。依賴源匯聚點的組播方案是一種域間ASM解決方案；能提供很好的容錯性和可擴展性；支持主機移動組播，但不會造成三角路由問題。

關鍵詞：依賴源匯聚點的組播；稀疏模式獨立組播協議；域間組播；IP組播

Abstract: The key factor in wide-scale multicast deployments is the inter-domain multicast. Source rendezvous point dependent multicast is a simple but effective inter-domain multicast scheme based on the Chord lookup protocol. In this scheme the receiver’s designated router (DR) will discover the address of the rendezvous point (RP) in the source register by using the Chord protocol， and is thus joined to the multicast tree passing through this rendezvous point. The source rendezvous point dependent multicast scheme is an inter-domain multicast solution using Any Source Multicast (ASM)， which has good fault tolerance and expandability， and provides multicast support for mobile hosts without incurring triangular routing.

Key words:source rendezvous point dependent multicast; PIM-SM; inter-domain multicast; IP multicast

基金項目：國家發改委CNGI示范工程項目(CNGI-04-13-2T)

稀疏模式獨立組播協議(PIM-SM)^[1]是一個輕便的，性能良好的域內組播協議，整個組播域內有一個被稱為匯聚點(RP)的組播路由器作為源與接收者的會合地點。但是由于每個因特網業務提供商(ISP)都有自己的RP，且RP只知道本域內的組播源和接收者信息，不具備域間交互的能力。為使PIM-SM支持域間組播，通常可以采用兩種方法：一種是讓接收者RP知道組播源的位置，另一種是讓接收域的路由器知道源RP的位置，其中源RP是源所在域的RP，接收者RP是接收者所在域的RP。本文用第二種方法構建一種域間組播方案。接收者的指定路由器(DR)使用Chord^[2]協議獲得源RP地址，并加入源RP樹。為了敘述方便，本文將該方案稱為依賴源RP組播，因為所有的接收者都必須加入源RP樹。

1 相關工作

1.1 多播源發現協議

多播源發現協議(MSDP)^[3]使用的是第一種方法。在MSDP中，每個源RP把它了解的源活動(SA)信息通過傳輸控制協議(TCP)轉發給其他域里的所有接收者RP。該協議的主要缺點是不易擴展，因為每個域的RP都需要掌握其他RP的信息，在組播域較多時，配置和維護會非常困難；所有SA消息在整個Internet上擴散，給拒絕服務(DoS)攻擊帶來了便利。因此，MSDP一直被看作一種權宜方案，在IPv6中也沒有相應的實現。

1.2 特定源組播

特定源組播(SSM)^[4]并不需要RP，因為它假定接收者知道源的信息。接收者通過指定被稱為信道的(S，G)組，直接加入組播源的最短路徑樹(SPT)，其中S是源地址，G是組地址。SSM的主要缺點是：

(1)對多源組播應用支持不好，尤其在發送者的數量和位置不斷變化時，而這類應用非常普遍又很重要。

(2)需要修改現有的組播應用軟件，使其支持RFC3678中描述的組播源過濾應用編程接口(API)，代價太高。

(3)對源移動組播支持不佳。

因為要使組播信道保持不變，源移動后必須將數據包單播給家鄉代理，讓家鄉代理將數據包組播出去，這會造成路由三角問題，處理大量的移動源信息也會使家鄉代理不堪重負。

1.3 嵌入式匯聚點

有人根據IPv6地址的特點提出了一種被稱為“在組播地址中嵌入RP地址”^[5]的解決方案，簡稱為嵌入式RP。它采用的是第二種方法，其做法是將源RP地址嵌入到組播地址中，組播路由器直接從組播地址中提取源RP地址，并加入源RP樹。其主要缺點是：

(1)這種組播地址對源RP地址的依賴性比較高，源RP一旦出現故障，組播就會出現問題。雖然可以通過泛播(Anycast)RP^[6]技術讓多個RP共享一個地址，但配置和維護工作比較復雜。

(2)可以從組播地址提取源RP地址，并反推出與該RP相關的其他組播會話，不太安全。

(3)在多源組播應用中，如果組播源處在不同域，RP的選擇將成為問題。

(4)多源組播應用會產生路由三角問題。

Chord協議是一種分布式資源查找協議，具有良好的健壯性和可擴展性。它利用一致性散列算法將關鍵信息隨機分散到一組被組織成Chord環的主機中，并能從環中的任何一臺主機上查找存儲的信息。Chord協議的查找速度很快，在n臺主機的環中，平均只需查找log2n次。

2 依賴源匯聚點組播

依賴源匯聚點的組播用Chord協議查找源RP信息，要求與組播源對應的DR首先將源RP信息三元組(S，G，RP)存儲到Chord環中，其中S是源地址，G是組地址，RP是源RP地址。每個組播域至少需要配置一臺Chord主機，所有Chord主機構成一個Chord環，如圖1所示。

Chord主機要加入Chord環需要知道環中某臺主機的IP地址，第一臺主機構建一個指向自己的自旋環。為了方便環的形成，需要配置幾臺永久的Chord主機，類似于域名服務器(DNS)中的根節點。

組播源或接收主機的DR需要知道本地Chord主機的地址，以便于向Chord環存儲或查詢源RP信息。

2.1 地址分類

為方便組播的控制和管理，通常將組播地址分為兩類：全局地址和局部地址。

Chord環上只存儲與全局地址對應的源RP信息，也就是說只能使用全局地址進行域間組播通信。可以使用以下方法區分這兩種地址：

(1)配置組播源和接收主機的DR。譬如，只配置局部地址，非局部地址便是全局地址。

(2)利用IPv6組播地址的范圍管理特性。

2.2 組播的發送

在依賴源匯聚點的組播中，組播源的發送過程如下：

(1)組播源將組播信息發送到它的DR。

(2)DR檢測組播地址，判斷該組播是否已注冊，如果是則轉到過程(6)，否繼續到過程(3)。

(3)建立一個(S，G)項，如果組播地址是局部的，則繼續到(4)，否則轉到過程(5)。

(4)用組地址G匹配并獲得接收者RP的地址，向該RP注冊，然后轉到過程(6)。

(5)將源RP信息發送給本地Chord主機，讓它把源RP信息存放到Chord環上。

(6)過程結束。

組播源的整個發送過程如圖2所示。另外，為保證Chord中源RP信息的正確性，Chord主機需要定時刪除源RP信息，DR也需定時注冊源RP信息，這一過程被稱為刷新。

2.3 組播的接收

在依賴源匯聚點的組播中，接收主機加入RP樹的過程如下：

(1)接收主機向DR發送互聯網組管理協議/組播監聽協議(IGMP/MLD)報告。

(2)接到報告后DR判斷該組播組是否已存在，若是轉到過程(7)，否則繼續到過程(3)。

(3)建立組播轉發項，如果是局部地址，則繼續到過程(4)，否則轉到過程(5)。

(4)加入接收者RP樹，然后轉到過程(7)。

(5)以G為參數查詢本地Chord主機，獲得源RP信息，DR從中提取源RP地址。

(6)加入源RP樹。

(7)過程結束。

整個過程如圖3所示。

DR應定時地查詢Chord，以防止G所對應的S的改變。

2.4 DR的改變

依賴源匯聚點的組播方案無需改變PIM-SM協議和客戶端程序，但需要為DR增加一些功能，主要包括以下3個模塊：注冊模塊、刷新模塊和查詢模塊。

注冊模塊的主要功能為向Chord注冊源RP信息。如果是全局組播地址，注冊模塊會向本地Chord主機發送源RP信息。本地Chord主機上的守護進程監聽進程接收到注冊信息后會將源RP信息存儲在Chord環上。

查詢模塊的主要功能為從Chord查詢源RP信息。如果是全局組播地址，查詢模塊會向本地Chord主機發送查詢消息，本地Chord主機上的守護進程接到查詢消息后會查找源RP信息并返回給查詢模塊。

如前所述，為保證源RP信息的正確性，Chord主機定期刪除源RP信息，因此組播源的DR應定期地向Chord注冊。Chord主機在接到源DR的注冊后，需匹配(S，G，RP)信息，如果匹配成功，則將(S，G，RP)的定時器重置為注冊消息中的保持時間；如果只有(S，G)匹配成功，則更新(S，G，RP)項的RP信息，同時重置定時器；否則，新建(S，G，RP)項。因為DR會為每個源創建一個(S，G)項，因此可以用該信息控制DR向Chord主機的刷新，譬如，用(S，G)項的定時器值初始化注冊消息的保持時間。

接收者DR也應定期地向Chord查詢，獲得消息的保持時間由查詢返回消息中的保持時間決定。

2.5 路由器的其他配置

與MSDP和SSM協議一樣，依賴源匯聚點的組播需要用多協議邊界網關協議(MBGP)配置自治域間的邊界路由器，也需要配置與其他ISP交界的路由器，以允許Chord協議存儲和查找源RP信息。

3 特點分析

相對于其他的域間組播協議，依賴源匯聚點的組播方案除了簡單之外還有可擴展、播范圍可控制、負載平衡、穩定等特點。

3.1 可擴展

依賴源匯聚點的組播不像MSDP那樣將SA信息發送給所有的RP，只需將源RP信息發送給本地Chord主機，由后者將該信息存放到Chord環中適當的主機上。因此源RP信息流動量不會太大，有利于依賴源匯聚點的組播的擴展。

Chord主機加入或退出時Chord環中絕大多數主機的存儲信息無需變動，也利于依賴源匯聚點的組播的擴展。

3.2 組播范圍可控制

因組播地址被分成了全局地址和局部地址，只有全局組播地址可用于域間組播通信，保證了組播范圍的可控制性。

3.3 負載平衡

在多源組播應用中，依賴源匯聚點的組播方案能夠做到負載平衡。因為接收主機的DR會從Chord主機上獲取多條源RP信息，并分別加入多棵SRP樹。多棵SRP樹不僅可以使負載平衡，也避免了三角路由問題。

3.4 穩定

在一臺Chord主機出現故障后，其他主機可以迅速恢復成一個Chord環。只要一個組播域內配置多臺Chord主機，在其中部分主機出現故障時不會中斷現有的組播通信，因為DR可以從沒出故障的Chord主機上查詢SA信息，這類似于一個域內有多臺DNS代理服務器。另外，在Chord主機出現故障后，組播源DR將源RP信息發送給另一臺正常的Chord主機，以保證組播通信的正常進行。

3.5 支持ASM

依賴源匯聚點的組播從邏輯上拋棄了組播域的概念，使源RP為其他組播域所見。

依賴源匯聚點的組播不要求組播源地址和組播地址綁定在一起，因此依賴源匯聚點的組播就是一種域間ASM方案，無需修改現有的組播軟件。

3.6 支持主機移動

由于源RP信息的存放位置與發送該信息的DR的位置無關，因而組播源可以很自由地更換DR。組播源可以讓其外地DR向Chord注冊，避免了三角路由問題。

因為可以從任何一臺Chord主機上查詢源RP信息，所以接收主機在外地域也能通過遠程訂閱機制加入組播組。

4 安全因素

依賴源匯聚點的組播安全方面的措施：

(1)DoS攻擊。人們可以將自己的主機的IP地址偽裝成DR的IP地址向Chord發送一些無用的組播組信息，從而造成Chord性能的下降。可以通過限制單位時間內每臺DR向Chord發送信息的數量來解決。

(2)為快速查詢，每臺Chord主機自身都有一個查找表，通過改變自身的查找表，節點本身可以破壞Chord環的完整性。為此可以采用認證機制，禁止非法的主機加入Chord環。

5 結束語

本文提出了一種基于Chord的域間組播方案——依賴源匯聚點的組播。該方案利用可以從任意Chord主機上查詢Chord上存儲的信息的特點，將源RP信息存儲到Chord上，供各組播域使用，以便不同的域進行組播通信。該方案是一種域間ASM解決方案，能提供很好的容錯性和可擴展性，支持主機移動組播，但不會造成三角路由問題。

6 參考文獻

[1] ESTRIN D， FARINACCI D， HELMY A， et al. Protocol independent multicast - sparse mode (PIM-SM): protocol specification (revised) [S]. RFC 2362. 1998.

[2] STOICA I， MORRIS R， LIBEN-NOWELL D， et al. Chord: a scalable peer-to-peer lookup protocol for Internet applications [J]. IEEE/ACM Transactions on Networking， 2003， 11(1):17-32.

[3] FENNER B， MEYER D. Multicast source discovery protocol[S]. RFC 3618. 2003.

[4] HOLBROOK H， CAIN B. Source-specific multicast for IP [R]. Internet Draft， work in progress. 2005.

[5] SAVOLA P， HABERMAN B. Embedding the rendezvous point (RP) address in an IPv6 multicast address [S]. RFC 3956. 2004.

[6] FARINACCI D， CAI Y. Anycast-RP using PIM [R]. Internet Draft， work in progress. 2005.

收稿日期：2006-05-29

作者簡介

程龍，東南大學計算機科學與工程系在讀碩士研究生，研究方向為計算機網絡體系結構與網絡應用。

曹爭，東南大學計算機科學與工程系副教授，研究方向為計算機網絡體系結構、計算機網絡管理等。

許春嶸，東南大學計算機科學與工程系在讀碩士研究生，研究方向為計算機網絡體系結構與網絡應用。