《電子技術應用》
您所在的位置:首頁 > 可編程邏輯 > 業(yè)界動態(tài) > 一種支持多協(xié)議的超高速轉(zhuǎn)發(fā)引擎的設計與實現(xiàn)

一種支持多協(xié)議的超高速轉(zhuǎn)發(fā)引擎的設計與實現(xiàn)

2008-07-17
作者:趙崢嶸, 蘭巨龍,, 曲 晶,, 姜

  摘 要: 從節(jié)約FPGA資源的角度出發(fā),,分析了超高速條件下多協(xié)議" title="多協(xié)議">多協(xié)議支持策略的實現(xiàn)難點,,設計了一種可支持10Gbps" title="10Gbps">10Gbps速率下多協(xié)議報文線速轉(zhuǎn)發(fā)的引擎結構,,解決了FPGA“資源與速度互換”的矛盾,。
  關鍵詞: 路由器 轉(zhuǎn)發(fā)引擎" title="轉(zhuǎn)發(fā)引擎">轉(zhuǎn)發(fā)引擎 協(xié)議


  光纖傳輸技術發(fā)展迅速,,網(wǎng)絡鏈路層的接口速率目前已達到10Gbps,,出現(xiàn)了諸如10G的LAN,、WAN,、POS等接口類型。高端路由器作為骨干網(wǎng)的核心交換結點,,必須支持10Gbps接口,,轉(zhuǎn)發(fā)引擎的單包處理時間將急劇縮短。
  另一方面,,隨著IPv6,、組播" title="組播">組播、MPLS協(xié)議的成熟及廣泛應用,,高端路由器也要求提供對以上協(xié)議的支持,。而不同類型的報文處理流程不盡相同,很難實現(xiàn)通用模塊的處理,。這無疑增加了超高速轉(zhuǎn)發(fā)引擎的設計難度,。
  傳統(tǒng)的報文處理流程已不能滿足超高速轉(zhuǎn)發(fā)和多協(xié)議支持的要求。作為轉(zhuǎn)發(fā)處理的代表方向之一,,網(wǎng)絡處理器(NP)目前的商用化水平還不支持10Gbps接口,,大多不具備多協(xié)議支持的能力。
  同時,,從自主知識產(chǎn)權的角度出發(fā),,也必須在高端路由器上開發(fā)自己的轉(zhuǎn)發(fā)“芯”。
  本文在深入分析了轉(zhuǎn)發(fā)引擎的實現(xiàn)難點后,,從提高報文處理速度和節(jié)省FPGA資源的角度出發(fā),,設計了一種可支持多協(xié)議的超高速轉(zhuǎn)發(fā)引擎結構,并經(jīng)國家“863”課題(“大規(guī)模接入?yún)R聚路由器ACR”)工程驗證,,可支持10Gbps接口下多種類型報文的線速轉(zhuǎn)發(fā),。
1 10Gbps接口下的線速轉(zhuǎn)發(fā)
  表1給出了不同接口下,40字節(jié)超短包的線速轉(zhuǎn)發(fā)時間,。


  對于40字節(jié)的超短包,,10Gbps接口下的處理時間只有32ns,即使在100MHz時鐘下,,也只有不到4個周期的時間,。而轉(zhuǎn)發(fā)引擎的報文處理流程包括報頭有效性檢查、直連檢查,、組播RPF檢查,、查表" title="查表">查表(單、組播,、MPLS查表),、報頭修改等復雜操作。傳統(tǒng)的串行處理流程顯然無法滿足線速轉(zhuǎn)發(fā)的時間要求,。
1.1 并行流水線方案
  按照處理流程各步驟之間的時間關系,,筆者在對整個處理流程進行了功能劃分后,,采用流水線設計,縮短了處理時間,,如圖1,。


  引進該方案的最大好處是:整個轉(zhuǎn)發(fā)引擎可以處于流水線狀態(tài),不必等待單個任務的完成,,省去了串行處理中的等待時間,。整個流水線的周期等于最長流水段的周期(路由查表),而不是簡單的各段周期之和,。
  按照這個思路,,在實際工程應用時,采用了如下并行流水線引擎結構:
  對某些流水段,,可以通過段內(nèi)的并行設計,,進一步縮短處理時間。例如,,對圖2中的有效性檢查模塊,,可以進一步細化為版本號檢查、TTL檢查,、地址范圍檢查,、Payload Length檢查四個子模塊,作并行處理,,如圖3,。


1.2 方案分析
  采用并行流水線的設計,其關鍵在于整個流水線的不斷流,、不溢出,。這要求對各流水段進行精細劃分,使各段的周期盡量接近,,即實現(xiàn)同步流水線,減少段間的緩存容量,。
2 多協(xié)議支持策略
  本方案考慮支持的協(xié)議為IPv4,、IPv6、MPLS,,均含單播,、組播、二次查表,。要支持如此多的協(xié)議類型,,而不同類型報文的處理流程不盡相同,在時序上很難對齊,,難以用通用模塊實現(xiàn),,必然需要大量的緩存FIFO,。圖4給出了其分析。


  可以看出,,報頭處理的設計非常復雜,,資源占用較多。為了合理利用FPGA的內(nèi)部資源,,必須對報頭處理單元精心設計,。
  報頭處理單元要處理的報文包括以下類型:IPv4(單、組播),、IPv6(單,、組播)、MPLS(單,、組播)6種,加上二次查表,,共有12種類型的報文。對此,,有如下分析:
  (1)對以上的12種情況各用一個單元進行實現(xiàn),,這就意味著報頭處理中任何一處的緩存FIFO都必須生成12個。
  (2)粗略劃分成IPv4,、IPv6和MPLS三種實現(xiàn)單元,,每一個單元又采用單組播獨立實現(xiàn)的方式,也就是將二次查表和非二次查表的報頭處理做成通用處理方式,。這樣也需要6套FIFO緩存報文,。
  (3) 只分成IPv4、IPv6和MPLS三種情況,,對單播和組播,、二次查表以及非二次查表做成通用的處理模塊,這樣內(nèi)部需要3套緩存FIFO,。
  (4) 與(3)的區(qū)別在于,,通過精細設計報頭處理單元的各種讀寫信號(上報、轉(zhuǎn)發(fā),、二次查表),,使得報頭處理單元內(nèi)部不需要緩存報文,報頭處理主要完成生成內(nèi)部報頭(轉(zhuǎn)發(fā),、上報和二次查表),,將緩存FIFO合并為一個,不管是IPv4,、IPv6還是MPLS共用一個轉(zhuǎn)發(fā)FIFO和上報FIFO,。
  為節(jié)省FPGA資源,提高設計可靠性,,筆者在實際工程中采用了方案(4)的設計方法,。其實現(xiàn)結構如圖5,。


  方案分析:顯然,該設計方案在節(jié)省資源的同時,,復雜了內(nèi)部邏輯的設計,,因為任何一個報頭處理都需要同時完成單播和組播、非二次查表和二次查表的統(tǒng)一處理,,而且各種報文都統(tǒng)一存放于一個緩存FIFO,,因此還需要IPv4、IPv6和MPLS報頭處理單元中的轉(zhuǎn)發(fā)設計和上報設計進行時序?qū)R,,即從緩存FIFO讀出報文的同時送往轉(zhuǎn)發(fā)和上報,,供兩路同時使用(在轉(zhuǎn)發(fā)和上報都有效時),需要二者的時序進行配合,。
3 工程應用
  該方案已應用在“大規(guī)模接入?yún)R聚路由器ACR”的10G轉(zhuǎn)發(fā)引擎上,,采用的FPGA為VIRTEX PRO系列的XC2VP70芯片。圖6給出了測試數(shù)據(jù),。


  分析:
  (1) 單一包長測試條件下,,在負荷為100%時,當包長大于等于109.5字節(jié)時的丟包率低于1.07E×10-6,,吞吐率接近于1,。
  (2) 混合包傳輸條件下,在端口負荷低于90%時,,丟包率低于3.0E×10-4,。
  本文著重結合項目需要,解決了10Gbps線速轉(zhuǎn)發(fā)和多協(xié)議支持兩個問題,。通過并行流水線設計,,縮短了報文處理時間。而通過報頭處理內(nèi)部各模塊的時序配合,,減少了FPGA內(nèi)部緩存FIFO的使用,,節(jié)省了FPGA資源,保證了該設計的工程實用性,。方案的難點在于報頭綜合處理單元的時序邏輯設計,。
  可以預見,鏈路接口速率即將突破40Gbps,,可以考慮采用多條類似流水線并行處理的引擎結構,但將面臨流量均衡及轉(zhuǎn)發(fā)表效率的問題,,這是下一步的研究方向之一,。
參考文獻
1 Xilinx Corporation.RocketIO transceiver user guide[Z].UG024 (v2.3.2)June 24,2004
2 Xilinx Corporation.Virtex pro platform FPGA handbook.2003
3 Mohammad J.Akhbarizadeh and mehrdad nourani. An IP packet forwarding technique based on partitioned lookup table
4 Newman P, Minshall G, Huston L. IP switching and gigabitrouters.

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,,并不代表本網(wǎng)站贊同其觀點,。轉(zhuǎn)載的所有的文章,、圖片、音/視頻文件等資料的版權歸版權所有權人所有,。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認版權者,。如涉及作品內(nèi)容、版權和其它問題,,請及時通過電子郵件或電話通知我們,,以便迅速采取適當措施,避免給雙方造成不必要的經(jīng)濟損失,。聯(lián)系電話:010-82306118,;郵箱:[email protected]