在寬帶網(wǎng)絡(luò)的建設(shè)和運營中,，業(yè)務(wù)是先導(dǎo)和核心,。其中組播業(yè)務(wù)作為最具潛力的未來業(yè)務(wù)之一，已經(jīng)得到了前所未有的重視,。IP組播技術(shù)具有獨特的優(yōu)越性：在組播網(wǎng)絡(luò)中,，即使用戶數(shù)量成倍增長，主干帶寬也不需要隨之增加,。隨著寬帶技術(shù)的不斷發(fā)展,，F(xiàn)TP、HTTP,、SMTP等傳統(tǒng)的數(shù)據(jù)業(yè)務(wù)已無法滿足人們對信息的需求,，而視頻點播、遠(yuǎn)程教學(xué),、新聞發(fā)布,、網(wǎng)絡(luò)電視等將成為各大運營商爭相發(fā)展的新型業(yè)務(wù)，這些業(yè)務(wù)都可以利用組播實現(xiàn)，使得IP組播技術(shù)成為當(dāng)前網(wǎng)絡(luò)技術(shù)中的研究熱點之一,。為此,，人們開發(fā)了多種組播路由協(xié)議" title="路由協(xié)議">路由協(xié)議來支持組播的應(yīng)用，而PIM-SM是目前應(yīng)用最廣泛,、功能最強大的一種,，適合廣域網(wǎng)環(huán)境下用戶比較分散的組播業(yè)務(wù)的開展。美國UC-Berkeley最早于1990年初開始在MBone上研究基于組播的協(xié)同環(huán)境,，國內(nèi)也于20世紀(jì)90年代后期開始研究和應(yīng)用組播視頻會議,。2004年4月，在CERNET主干網(wǎng)絡(luò)8個城市10個地區(qū)主節(jié)點之間成功配置了全程組播(Native multicast),。2003年SARS之后,，開始向38個省級主節(jié)點擴展，其中主要實現(xiàn)了基于PIM-SM的組播視頻會議業(yè)務(wù),。實現(xiàn)高性能PIM-SM組播將會對未來實現(xiàn)大規(guī)模組播應(yīng)用產(chǎn)生深遠(yuǎn)而重要的影響,。
　　PIM-SM組播通常采用純軟件或者利用ASIC、NP等硬件方式轉(zhuǎn)發(fā),。純軟件方式常用于中低端路由器,，在轉(zhuǎn)發(fā)性能上難以滿足核心路由器的要求；由于PIM-SM協(xié)議還未完全定型,，ASIC轉(zhuǎn)發(fā)方式難以更新升級,，并且開發(fā)周期長不適合在研發(fā)階段采用；而NP方式雖然開發(fā)效率高但技術(shù)成熟度低,。為此,，本文提出了一種PIM-SM分布式實現(xiàn)方案。該方案以筆者研發(fā)的T比特級路由器為平臺,，將PIM-SM控制平面與數(shù)據(jù)平面分離,，控制平面在路由器的主控上利用軟件方式實現(xiàn)，而數(shù)據(jù)平面利用TCAM+FPGA的方式在路由器的轉(zhuǎn)發(fā)子系統(tǒng)上實現(xiàn),?？紤]到路由查表" title="查表">查表的特性，將轉(zhuǎn)發(fā)表存放在商用TCAM芯片中,，可以充分利用TCAM的關(guān)鍵字查找優(yōu)勢,，利用FPGA程序?qū)崿F(xiàn)轉(zhuǎn)發(fā)處理邏輯。這樣的設(shè)計方式開發(fā)簡單,，成本較低,，靈活性強。其實現(xiàn)模型如圖1所示,。

1 實現(xiàn)難點分析
　　考察近幾年的路由器技術(shù)發(fā)展,，單播路由協(xié)議采用硬件轉(zhuǎn)發(fā),、軟件維護已經(jīng)不是新的方案。這是因為單播路由表類型比較單一,，存放的是下一跳,、網(wǎng)絡(luò)度量、出接口等固定長度的信息,，而且協(xié)議控制平面與數(shù)據(jù)平面功能劃分清晰,。數(shù)據(jù)平面只用來轉(zhuǎn)發(fā)而不影響協(xié)議機制的運行，它使用的轉(zhuǎn)發(fā)表只需要簡單的目的地址和出接口信息(只有一個),，其工作就是對到來的數(shù)據(jù)包進行目的地址的匹配,，然后根據(jù)匹配結(jié)果直接轉(zhuǎn)發(fā)即可。因此,，單播協(xié)議的轉(zhuǎn)發(fā)功能采用硬件方式實現(xiàn)較容易,，只需簡單的硬件轉(zhuǎn)發(fā)表和判定邏輯對數(shù)據(jù)進行處理，然后交給調(diào)度模塊直接輸出即可,。
　　PIM-SM實現(xiàn)方案的設(shè)計可以借鑒單播路由協(xié)議的硬件轉(zhuǎn)發(fā)模式,。但是，它實現(xiàn)硬件轉(zhuǎn)發(fā)比單播協(xié)議硬件轉(zhuǎn)發(fā)困難得多,。其主要困難如下：
　　(1)組播轉(zhuǎn)發(fā)過程較為復(fù)雜,，輸入輸出項多且輸出項不定長。PIM-SM組播路由協(xié)議的路由表項類型不單一,，多達四種且有匹配優(yōu)先順序，數(shù)據(jù)包的匹配查找邏輯相當(dāng)復(fù)雜,。
　　(2)組播轉(zhuǎn)發(fā)表容量龐大,，表項寬。受器件水平的限制,，硬件實現(xiàn)方案中可能根據(jù)可用器件的情況設(shè)計多級轉(zhuǎn)發(fā)表,，而多級查表又限制了硬件實現(xiàn)方案速度優(yōu)勢的發(fā)揮。
　　(3)與單播轉(zhuǎn)發(fā)相比,，數(shù)據(jù)包需要硬件復(fù)制和交換轉(zhuǎn)發(fā),。組播轉(zhuǎn)發(fā)不僅大大增加了路由器轉(zhuǎn)發(fā)模塊的復(fù)雜度，而且還增加了調(diào)度模塊和接口模塊的復(fù)雜度,。
　　(4)一些利用軟件容易解決的問題,，可能利用硬件實現(xiàn)就比較困難，例如轉(zhuǎn)發(fā)查表,、RPF檢查,、數(shù)據(jù)驅(qū)動報文處理等。
　　(5)組播路由協(xié)議尚不完善,，組播應(yīng)用還未普及,，可以預(yù)見在未來的幾年中,，隨著組播應(yīng)用的發(fā)展，IPv4組播路由協(xié)議還要不斷改進和完善,。目前IPv6組播路由協(xié)議還未有標(biāo)準(zhǔn),，但是轉(zhuǎn)發(fā)設(shè)計必須考慮基于IPv6的實現(xiàn)方式。
　　這些由協(xié)議特性造成的與單播路由協(xié)議硬件轉(zhuǎn)發(fā)的不同之處,，也是PIM-SM實現(xiàn)硬件轉(zhuǎn)發(fā)的復(fù)雜之處,。這種復(fù)雜性在具體設(shè)計和實現(xiàn)時雖然在一定程度上會增加硬件轉(zhuǎn)發(fā)設(shè)計的復(fù)雜度，但是只要合理設(shè)計,，采用正確的技術(shù)手段和策略,，硬件轉(zhuǎn)發(fā)的性能優(yōu)勢是很明顯的。
2 方案設(shè)計
　　經(jīng)過分析,，不難得出關(guān)于PIM-SM分布式實現(xiàn)方案的大致輪廓,。方案總體上可以分為數(shù)據(jù)平面轉(zhuǎn)發(fā)設(shè)計、控制平面實現(xiàn)方式設(shè)計和平面間通信方式設(shè)計三個部分,。其中,，數(shù)據(jù)平面轉(zhuǎn)發(fā)部分的設(shè)計是整個方案的關(guān)鍵和難點，影響著PIM-SM組播的轉(zhuǎn)發(fā)性能,，其主要難點是轉(zhuǎn)發(fā)表格式和轉(zhuǎn)發(fā)邏輯的設(shè)計,，在T比特路由器的轉(zhuǎn)發(fā)子系統(tǒng)上實現(xiàn)。協(xié)議軟件部分負(fù)責(zé)控制平面的協(xié)議行為,，應(yīng)該在T比特路由器的主控子系統(tǒng)上實現(xiàn),，主要工作是維護協(xié)議狀態(tài)機的運行，與其他模塊進行交互,，以及對路由表項的更新管理,。平面間通信部分包括兩方面的工作：路由表下發(fā)和數(shù)據(jù)驅(qū)動報文上報。這兩部分包括判定,、封裝,、上報和處理等操作，涉及到主控和轉(zhuǎn)發(fā)兩方面的工作,，也是比較復(fù)雜的一部分,，需要通過高速內(nèi)部網(wǎng)絡(luò)進行通信?？紤]到在T比特路由器上的實現(xiàn),，PIM-SM實現(xiàn)方案的總體框圖如圖2所示。

　　圖2中只描繪了一個轉(zhuǎn)發(fā)的框圖,，對于多個轉(zhuǎn)發(fā)的情況可以類推,。
　　協(xié)議控制平面以及路由表管理部分在主控板上以軟件形式實現(xiàn)，數(shù)據(jù)平面部分在T比特路由器的轉(zhuǎn)發(fā)板上利用硬件實現(xiàn),，數(shù)據(jù)報文經(jīng)查表后直接轉(zhuǎn)發(fā),。主控與轉(zhuǎn)發(fā)之間通過高速網(wǎng)絡(luò)互聯(lián),，數(shù)據(jù)驅(qū)動報文在轉(zhuǎn)發(fā)生成后通過該網(wǎng)絡(luò)上報給主控的協(xié)議軟件處理。
　　值得注意的是,，協(xié)議報文必須上交給主控進行處理,。因此，為減少轉(zhuǎn)發(fā)邏輯的復(fù)雜度可以將協(xié)議報文在線路接口部分判斷后直接通過內(nèi)部網(wǎng)絡(luò)上交給主控協(xié)議棧處理,。這樣既可減少了硬件轉(zhuǎn)發(fā)部分的負(fù)擔(dān),，又使協(xié)議報文的處理不會與數(shù)據(jù)報文的處理相混淆。
　　前面已經(jīng)提到過,，影響數(shù)據(jù)高速轉(zhuǎn)發(fā)的關(guān)鍵因素是轉(zhuǎn)發(fā)表格式和查表轉(zhuǎn)發(fā)算法的設(shè)計,。因此，必須從保證協(xié)議一致性的角度出發(fā)考慮哪些功能可以用硬件完成,，哪些需要經(jīng)軟件計算后下發(fā),。這部分設(shè)計的正確與否不僅會影響協(xié)議一致性，而且會對轉(zhuǎn)發(fā)性能產(chǎn)生影響,。經(jīng)過對協(xié)議轉(zhuǎn)發(fā)規(guī)則的細(xì)致分析以及針對本路由器體系結(jié)構(gòu)特點,，提出了以下PIM-SM轉(zhuǎn)發(fā)表格式，如表1所示,。該格式支持PIM-SM三種轉(zhuǎn)發(fā)項,。

　　查表轉(zhuǎn)發(fā)算法包括三部分：查表、結(jié)果判別和轉(zhuǎn)發(fā)上報,。查表部分負(fù)責(zé)數(shù)據(jù)包轉(zhuǎn)發(fā)表項的匹配,，方式是針對數(shù)據(jù)包利用TCAM中存放的轉(zhuǎn)發(fā)表進行關(guān)鍵字匹配，輸出查表結(jié)果,，如果失敗則丟棄數(shù)據(jù)包,；結(jié)果判別部分包括RPF檢查、數(shù)據(jù)驅(qū)動報文判定,、查表成敗判定等邏輯，根據(jù)查表結(jié)果信息進行判定,；轉(zhuǎn)發(fā)上報部分包括正常數(shù)據(jù)包的轉(zhuǎn)發(fā)和數(shù)據(jù)驅(qū)動報文封裝上報等操作,。其中查表部分相對復(fù)雜，時間耗費較多,，利用FPGA程序?qū)崿F(xiàn)時需要考慮如何進行性能優(yōu)化,，否則容易導(dǎo)致數(shù)據(jù)不能及時查表轉(zhuǎn)發(fā)，達不到線速轉(zhuǎn)發(fā)的要求,。數(shù)據(jù)驅(qū)動報文的封裝上報等操作可以采用硬件或者軟件實現(xiàn),。在路由器中硬件對組播的支持包括兩個方面：一是完成硬件查表轉(zhuǎn)發(fā)，二是在硬件上支持組播復(fù)制,。在組播復(fù)制的硬件實現(xiàn)中,，將組播復(fù)制功能放到調(diào)度模塊實現(xiàn),。調(diào)度模塊收到轉(zhuǎn)發(fā)送來的組播報文后，根據(jù)轉(zhuǎn)發(fā)所貼標(biāo)簽標(biāo)識的目的端口號及復(fù)制數(shù)目進行相應(yīng)的復(fù)制,，并直接送到相應(yīng)端口的FIFO,。
3 線速轉(zhuǎn)發(fā)可行性分析
　　該分布式設(shè)計方案的目的是實現(xiàn)高速數(shù)據(jù)轉(zhuǎn)發(fā)，目標(biāo)是達到10G接口的線速轉(zhuǎn)發(fā),。根據(jù)以上設(shè)計需要估算一下能否達到線速轉(zhuǎn)發(fā)能力和主要限制因素,。考慮到查表過程的時間耗費對轉(zhuǎn)發(fā)性能的影響最大,，從這方面展開對線速轉(zhuǎn)發(fā)限制因素的分析,。
3.1 線速轉(zhuǎn)發(fā)條件
　　線速轉(zhuǎn)發(fā)要求數(shù)據(jù)包的吞吐率在達到線路接口的最高值時不會丟包，即必須能及時處理所有的數(shù)據(jù)包,，那么衡量的標(biāo)準(zhǔn)為查表的時間應(yīng)低于單個數(shù)據(jù)包的線速轉(zhuǎn)發(fā)時間,。數(shù)據(jù)包越長，對應(yīng)的查表時間就越長,，因此對短數(shù)據(jù)包的要求更為苛刻,。要在數(shù)據(jù)速率高達10Gbps的條件下，實現(xiàn)常見最短組播數(shù)據(jù)包(長度為40字節(jié))的線速轉(zhuǎn)發(fā),，則轉(zhuǎn)發(fā)處理一個數(shù)據(jù)包的最長時間為：
　　(IP報文長度)40×8bit/(端口速率)10Gbps＝32ns,。
　　表2給出了不同長度數(shù)據(jù)包的轉(zhuǎn)發(fā)最長時間。

　　假定商用TCAM芯片的時鐘為100MHz,，每個時鐘周期長10ns,，也就是說必須在4個時鐘周期內(nèi)完成查表轉(zhuǎn)發(fā)，才能實現(xiàn)最短數(shù)據(jù)包的線速轉(zhuǎn)發(fā),。根據(jù)轉(zhuǎn)發(fā)表格式的設(shè)計,，源地址和目的地址作為查表關(guān)鍵字存放于TCAM中，針對IPv4關(guān)鍵字長64bit,，IPv6關(guān)鍵字長256bit,，使用的TCAM為Netlogic公司的NSE5512，其容量為512k×72bit(即：若表項寬度為72位,，則該容量(包括掩碼)為512k×72bit,，事實上表項為256k條)。該器件的表項寬度可配置為72位,、144位,、288位和576位，表項配置為144位時,，容量為128k條,；配置為288位時，容量即為64k條,。根據(jù)筆者設(shè)計的轉(zhuǎn)發(fā)表格式,，組播表的查表關(guān)鍵字設(shè)為288位寬,。
　　利用TCAM實現(xiàn)查表所需的總時間T可分為兩部分。一部分為查表關(guān)鍵字的輸入時間T1,，例如對數(shù)據(jù)總線為72位的TCAM而言,，288位查表關(guān)鍵字的輸入時間需要4個FPGA時鐘周期；另一部分為查表關(guān)鍵字搜索TCAM內(nèi)部表項從而得出查表結(jié)果所需的時間,，也可以稱之為查表結(jié)果等待時間T2,，目前業(yè)界比較先進的TCAM的等待時間通常為10個FPGA時鐘周期。因此,，有：T＝T₁＋T₂＝14,。這說明，采用通常的查表方案在4個時鐘周期內(nèi)無法處理完最短包,，10G接口的線速轉(zhuǎn)發(fā)無法得到,。
3.2 優(yōu)化查表策略
　　為了實現(xiàn)10G接口的線速轉(zhuǎn)發(fā)，必須設(shè)法使得轉(zhuǎn)發(fā)查表能在4個時鐘周期內(nèi)完成,。而純粹的TCAM查表不能在4個時鐘周期內(nèi)完成,，這就要求必須采用流水查表技術(shù)對查表實現(xiàn)方案進行優(yōu)化。這樣,，一種由TCAM和SRAM共同完成的路由查表流水線方案在此處可以得到應(yīng)用,。該流水查表方案中，TCAM表項僅存儲查表關(guān)鍵字,，查表結(jié)果則存儲在相應(yīng)地址的SRAM中,。組播查表過程被分解成為三級流水級。其中,，一級關(guān)鍵字是組播查表關(guān)鍵字,，該關(guān)鍵字格式應(yīng)為(S，G),，一級關(guān)鍵字的查表利用TCAM實現(xiàn),；二級關(guān)鍵字是TCAM中表項最低匹配地址，二級關(guān)鍵字的查表利用SRAM實現(xiàn),；二級關(guān)鍵字查表結(jié)果為最終結(jié)果,，即出接口等信息。則查表流水線如圖3所示,。

　　流水線的功能段完成該段任務(wù)所需的時間即為功能段延遲時間，表3列出了IPv4/IPv6組播數(shù)據(jù)包查表時各功能段的時間延遲,。由該表可知,，該查表流水線中延遲時間最長的段為“TCAM查表關(guān)鍵字輸入”，需要4個FPGA時鐘周期,。

　　目前,，在FPGA和TCAM,、SRAM器件允許的條件下，該查表流水線結(jié)構(gòu)可以支持OC－192接口40字節(jié)組播包線速查表,。該流水線已經(jīng)在T比特路由器上得到應(yīng)用,，其具體設(shè)計方案不是本文討論的問題，只用來說明采用TCAM+FPGA方式能夠?qū)崿F(xiàn)10G接口線速轉(zhuǎn)發(fā),，這一點將由實際測試得到證明,。
　　關(guān)于硬件轉(zhuǎn)發(fā)性能的測試，RFC建議以最短報文來測試路由器的吞吐量,。在同樣端口速率下轉(zhuǎn)發(fā)小包是對路由器包轉(zhuǎn)發(fā)能力最大的考驗,。筆者進行了測試，測試端口包括10G WAN/LAN和10G POS,，利用Spirent通信公司的AX/4000測試儀對該路由器依照RFC2544規(guī)定進行轉(zhuǎn)發(fā)性能測試,。結(jié)果10G WAN/LAN接口40字節(jié)以上組播數(shù)據(jù)包均可達到線速轉(zhuǎn)發(fā)，10G POS接口70字節(jié)以上可達到線速轉(zhuǎn)發(fā),。只要FPGA程序進一步優(yōu)化可以實現(xiàn)任意包長的線速轉(zhuǎn)發(fā),。本次測試的丟包率為0。64字節(jié)的包延遲僅為12.35μs,。證明組播數(shù)據(jù)包能夠?qū)崿F(xiàn)10G線速轉(zhuǎn)發(fā),，延遲很小，適合組播應(yīng)用,。
　　本文結(jié)合國家863項目“可擴展到T比特的高性能IPv4/v6路由器基礎(chǔ)平臺及實驗系統(tǒng)”的要求,，提出了一種可應(yīng)用于T比特路由器平臺的分布式PIM-SM組播實現(xiàn)方案，采用TCAM+FPGA方式實現(xiàn)了高速數(shù)據(jù)轉(zhuǎn)發(fā),，并研究設(shè)計了轉(zhuǎn)發(fā)表格式和查表轉(zhuǎn)發(fā)算法,，分析了該方式下線速轉(zhuǎn)發(fā)的可行性，并最終得到實際性能的驗證,?？傊疚奶岢隽艘环N實現(xiàn)相對簡單,、高效可行的PIM-SM組播實現(xiàn)方案,。它具有較強的創(chuàng)新性，該方案的設(shè)計思想不僅可以應(yīng)用于T比特路由器,，同樣也適用于其他具有分布式結(jié)構(gòu)的高端路由器,。
參考文獻
1 Estrin D，F(xiàn)arinacci D.Protocol independent multicast-sparse mode(PIM-SM)：Protocol specification.RFC2362,，1998,；(6)
2 Savola P，Sonera T.PIM-SM multicast routing security issues and enhancements.Draft-ietf-mboned-mrou-tesec-00，2004
3 Deering S.Host extensions for IP multicasting.RFC1112,，1989
4 Fenner W.Internet group man-agement protocol Version 2.RFC2236,，1997
5 Fenner B，Handley M.Protocol independent multicastsparse mode(PIM-SM)：Protocol specification (Revised).Draft-ietf- pim-sm-v2-new-05,，2002
6 Stephen E,，Deborah D，Estrin L.The PIM architecture for wide-Area multicast routing.IEEE/ACM Transactions on Networking,，1996,；4(2)
7 Estrin D，Handley M,，Helmy A et al.A dynamic bootstrap mechanism for rendezvous-based multicast routing.In：Proced-dings of IEEE INFOCOM′99,，1999
8 Haberman B，Sandick H.Protocol independent multicast rout-ing in the Internet Protocol Version 6(IPv6).Draft-ietf-pim-ipv6-03,，2000
9 Bradne S,，Mcquaid J.Benchmarking methodology for network interconnect devices.RFC2544，1999
10 Bhattacharyya B,，Giuliano L.An overview of source-specific multicast(SSM).Draft-ietf-ssm-overview-03,，2002
11 Bhattacharyya S.An Overview of source-specific multicast (SSM).RFC3569，2003
12 Kim D,，Meyer D.Anycast rendevous point(RP) mechanism using protocol independent multicast(PIM) and multicast source discovery protocol(MSDP).RFC3446,，2003