<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 嵌入式系統 > 設計應用 > 10Gbps線(xiàn)速轉發(fā)引擎的并行流水線(xiàn)設計與實(shí)現

10Gbps線(xiàn)速轉發(fā)引擎的并行流水線(xiàn)設計與實(shí)現

作者: 時(shí)間:2017-06-05 來(lái)源:網(wǎng)絡(luò ) 收藏

當前,線(xiàn)路傳輸技術(shù)發(fā)展迅速,光傳輸技術(shù)更是進(jìn)步飛速,無(wú)論是單波長(cháng)載荷速率還是單纖可用波長(cháng)數量,都以驚人的速度增長(cháng)。目前,已出現各種10Gbps的接口類(lèi)型,如POS、LAN、WAN等。作為T(mén)比特路由器的核心部分,轉發(fā)引擎的線(xiàn)速報文轉發(fā)能力決定了路由器所能夠支持的最高端口速率。T比特路由器中線(xiàn)速轉發(fā)引擎必須支持10Gbps接口,而傳統的報文處理結構由于單包處理時(shí)間過(guò)長(cháng),已無(wú)法滿(mǎn)足線(xiàn)速轉發(fā)的性能需求。

1 線(xiàn)速轉發(fā)引擎的結構設計

轉發(fā)引擎是高性能T比特路由器的關(guān)鍵部分之一,其設計的合理性、性能的優(yōu)劣直接影響路由器的整體性能。當前,業(yè)界的硬件轉發(fā)引擎主要有兩種方案:一種是基于網(wǎng)絡(luò )處理器的轉發(fā)引擎,一種是基于平臺的轉發(fā)引擎。本設計采用作為設計平臺,如此選擇主要是出于以下兩點(diǎn)考慮:

(1)目前支持端口速率為10Gbps的線(xiàn)速處理的商用網(wǎng)絡(luò )處理器還不成熟,尤其是沒(méi)有自主知識產(chǎn)權、安全性弱、受芯片提供商的制約,所以網(wǎng)絡(luò )處理器并不是最佳選擇;

(2)采用是為設計單片轉發(fā)系統(SOC)奠定基礎,最終目的是要實(shí)現我國自主的高性能網(wǎng)絡(luò )處理器。

數據包的10Gbps線(xiàn)速轉發(fā),報文轉發(fā)率達到31.25Mpps以上,支持IPv4、IPv6和MPLS三種類(lèi)型報文的處理,支持IPv4、IPv6優(yōu)先級分類(lèi),支持組播以及1M路由表項等,都是T比特路由器必須實(shí)現的關(guān)鍵技術(shù)指標。為此,10Gbps線(xiàn)速轉發(fā)引擎采用基于大規模FPGA、TCAM和SRAM的全硬件流水并行結構,利用硬件的高速特性和高可靠性,實(shí)時(shí)處理路由分組的各項信息并對路由分組進(jìn)行硬件線(xiàn)速轉發(fā)。

下面給出一種基于FPGA的轉發(fā)引擎結構,該引擎采用并行處理方式和流水線(xiàn)結構,有效地降低了報文的處理時(shí)間,實(shí)現了對多協(xié)議報文的支持,達到了10Gbps線(xiàn)速轉發(fā)的性能需求。

2 并行處理結構的設計

并行機制就是對同一段時(shí)間內需要處理的每個(gè)任務(wù)各采用一個(gè)處理通道的并行方式進(jìn)行操作,從而使多個(gè)任務(wù)所需的處理時(shí)間降至最少。轉發(fā)引擎要進(jìn)行報頭分析、QoS實(shí)現、安全檢測、直連檢查、單播查表、組播查表等處理。并行處理方式就是按照各個(gè)功能模塊之間在處理順序上的關(guān)聯(lián)性,將以上的功能模塊進(jìn)行并行處理;并盡可能對并行技術(shù)進(jìn)行進(jìn)一步挖掘。以報頭分析模塊為例,可進(jìn)一步分為版本號檢查、TTL檢查、地址范圍檢查、有效負載長(cháng)度檢查等四個(gè)小模塊,進(jìn)而進(jìn)行小模塊的并行處理。并行處理結構如圖1所示。

采用并行處理技術(shù)之后的總處理時(shí)間只是其中關(guān)鍵并行模塊的處理時(shí)間,關(guān)鍵并行模塊是指所有并行處理模塊中處理時(shí)間最長(cháng)的模塊。

本文引用地址:http://dyxdggzs.com/article/201706/349258.htm


3 流水線(xiàn)機制的設計

若要在數據速率高達10Gbps的條件下實(shí)現IPv6最短包(長(cháng)度為40字節)的線(xiàn)速轉發(fā),則轉發(fā)引擎處理一個(gè)數據包的最長(cháng)時(shí)間為:IP報文長(cháng)度(字節)×8(比特)/端口速率(Gbps)=40×8/10=32ns。即使采用100MHz的時(shí)鐘,處理時(shí)間也只有3.2個(gè)周期,要在如此短的時(shí)間里完成復雜的IP報文處理,必須采用流水線(xiàn)設計。

3.1 系統級流水線(xiàn)

基于FPGA的轉發(fā)引擎內部各大模塊間的流水線(xiàn),本文稱(chēng)為系統級流水線(xiàn)。轉發(fā)引擎的系統級流水線(xiàn)結構如圖2所示。

該流水線(xiàn)結構將轉發(fā)處理分為接口轉換、報頭提取、路由查表、報頭處理與修改、輸出控制等五個(gè)流水操作子進(jìn)程。它們都是在時(shí)間上先后執行的串行任務(wù)單元,且前后子進(jìn)程之間的操作相互獨立。轉發(fā)引擎采用流水線(xiàn)操作以后,只要各子進(jìn)程能滿(mǎn)足給定接口速率下最短報文的處理時(shí)間要求,則整個(gè)轉發(fā)引擎就支持該接口速率。

3.2 流水線(xiàn)查表設計

在該流水線(xiàn)各段中,需要時(shí)間最長(cháng)的功能段為路由查表。在查表模塊進(jìn)一步引入流水線(xiàn)設計,可以減少整個(gè)轉發(fā)處理的流水時(shí)間,使之能夠滿(mǎn)足路由器性能要求。

硬件查表通常由TCAM完成,傳統的TCAM查表流程如圖3所示。

傳統查表由TCAM搜索和TCAM讀表項兩個(gè)操作串行進(jìn)行,無(wú)流水線(xiàn)操作,整個(gè)過(guò)程需要十幾個(gè)時(shí)鐘周期。
在本文提出的由TCAM和SRAM共同完成路由查表的流水線(xiàn)結構中,查表分兩級進(jìn)行:由TCAM完成搜索過(guò)程,再由SRAM讀出查表結果。這樣可將查表時(shí)間縮短為4個(gè)周期。

在本流水查表方案中,TCAM表項僅存儲查表關(guān)鍵字,查表結果則存儲在SRAM的相應地址空間中。對于單播查表,目的IP地址作為查表關(guān)鍵字保存在TCAM的某個(gè)地址中,目的接口號作為查表結果則保存在SRAM中的相應地址空間中,這樣就構成一條完整的單播表項。其流程如圖4所示。

圖4給出了兩種流水線(xiàn)設計方案,它們的區別主要在于是否將TCAM的RBUS直接連接到SRAM的地址總線(xiàn)上。

(1) 方案(a)是將TCAM的RBUS直接作為SRAM的讀取地址,優(yōu)點(diǎn)是PCB制作略為簡(jiǎn)單,減少FPGA中User I/O資源緊張的問(wèn)題,缺點(diǎn)是寫(xiě)表項的時(shí)間較長(cháng)。因為寫(xiě)SRAM表項必須通過(guò)相應的TCAM操作才能進(jìn)行,即寫(xiě)TCAM表項和寫(xiě)SRAM表項均通過(guò)TCAM來(lái)完成,所以寫(xiě)一條完整表項的時(shí)間為二者處理時(shí)間之和。

(2)方案(b)是將TCAM的結果總線(xiàn)RBUS與SRAM的地址總線(xiàn)通過(guò)FPGA連接起來(lái),雖然增加了PCB制作的難度,但由于寫(xiě)表項時(shí)TCAM和SRAM的寫(xiě)操作可同時(shí)進(jìn)行,因而寫(xiě)一條完整表項的時(shí)間為這二者處理時(shí)間的較大值。通常TCAM的讀寫(xiě)時(shí)間遠大于SRAM的讀寫(xiě)時(shí)間。

通過(guò)TCAM寫(xiě)SRAM表項的時(shí)間往往與單獨寫(xiě)TCAM表項的時(shí)間相當,即方案(a)寫(xiě)表項的時(shí)間大大超過(guò)方案(b),因而方案(b)具有更好的線(xiàn)速轉發(fā)性能。

4 工程實(shí)現

通過(guò)采用并行處理技術(shù)和流水線(xiàn)技術(shù)設計的轉發(fā)引擎在實(shí)際工程中得到了很好的應用,工程中采用的FPGA為VIRTEX PRO系列的XC2VP70芯片。借助思博倫通信公司(Spirent Communications)的Adtech AX/4000網(wǎng)絡(luò )測試儀構造的測試環(huán)境如圖5所示。

圖5中,測試儀與10GPOS線(xiàn)卡相連,雙向發(fā)送與接收數據,線(xiàn)卡將10Gbps數據輸入轉發(fā)引擎,再由轉發(fā)引擎送往高速交換網(wǎng)絡(luò )。在測試過(guò)程中,選擇40、64、128、256、512、1024、1280和1500字節的定長(cháng)包進(jìn)行分組轉發(fā)率和丟包率測試。測試表明,在10G VAN和10G LAN接口下,轉發(fā)引擎不丟包,即丟包率為0。在10GPOS接口下,轉發(fā)引擎的吞吐率和丟包率如圖6所示。

圖中表明,在單一包長(cháng)測試條件下,在負荷為100%、包長(cháng)大于等于109.5字節時(shí)的丟包率低于1.07×10-6%,吞吐率接近于1%,該轉發(fā)引擎可以實(shí)現40字節IPv6報文的10Gbps線(xiàn)速轉發(fā)。

在測試過(guò)程中,還做了模擬實(shí)際應用的混合包傳輸(40字節包占25%,172字節包占20%,360字節包占15%,552字節包占20%,1500字節包占20%)測試。圖7表示在模擬實(shí)際包長(cháng)分布條件下,不同負荷時(shí)的轉發(fā)引擎丟包率。

圖中所示的測試結果表明,端口負荷低于90%時(shí),丟包率低于3.0×10-4%。以上結果表明,該轉發(fā)引擎能實(shí)現100%報文通過(guò)率的10Gbps線(xiàn)速轉發(fā)。

10Gbps線(xiàn)路接口的出現,對轉發(fā)引擎的設計是個(gè)極大的挑戰:在不到4個(gè)時(shí)鐘周期的時(shí)間內,需要實(shí)現各種協(xié)議類(lèi)型的報文的線(xiàn)速轉發(fā)。本文提出的一種基于FPGA的轉發(fā)引擎結構,很好地解決了10Gbps線(xiàn)速轉發(fā)的問(wèn)題。該引擎結構已經(jīng)應用在863重大課題“可擴展到T比特的IPv4/v6 路由器基礎平臺及實(shí)驗系統”中,并通過(guò)了測試。

隨著(zhù)線(xiàn)路傳輸技術(shù)的發(fā)展,鏈路接口速率即將突破40Gbps,這對轉發(fā)引擎的結構設計又將是進(jìn)一步的挑戰,研究支持40Gbps的線(xiàn)速轉發(fā)引擎將是我們下一步的研究方向。



評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>