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

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

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

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

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

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

　　目前，在FPGA和TCAM、SRAM器件允許的條件下，該查表流水線結構可以支持OC－192接口40字節組播包線速查表。該流水線已經在T比特路由器上得到應用，其具體設計方案不是本文討論的問題，只用來說明采用TCAM+FPGA方式能夠實現10G接口線速轉發，這一點將由實際測試得到證明。
　　關于硬件轉發性能的測試，RFC建議以最短報文來測試路由器的吞吐量。在同樣端口速率下轉發小包是對路由器包轉發能力最大的考驗。筆者進行了測試，測試端口包括10G WAN/LAN和10G POS，利用Spirent通信公司的AX/4000測試儀對該路由器依照RFC2544規定進行轉發性能測試。結果10G WAN/LAN接口40字節以上組播數據包均可達到線速轉發，10G POS接口70字節以上可達到線速轉發。只要FPGA程序進一步優化可以實現任意包長的線速轉發。本次測試的丟包率為0。64字節的包延遲僅為12.35μs。證明組播數據包能夠實現10G線速轉發，延遲很小，適合組播應用。
　　本文結合國家863項目“可擴展到T比特的高性能IPv4/v6路由器基礎平臺及實驗系統”的要求，提出了一種可應用于T比特路由器平臺的分布式PIM-SM組播實現方案，采用TCAM+FPGA方式實現了高速數據轉發，并研究設計了轉發表格式和查表轉發算法，分析了該方式下線速轉發的可行性，并最終得到實際性能的驗證。總之，本文提出了一種實現相對簡單、高效可行的PIM-SM組播實現方案。它具有較強的創新性，該方案的設計思想不僅可以應用于T比特路由器，同樣也適用于其他具有分布式結構的高端路由器。
參考文獻
1 Estrin D，Farinacci 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