王 飛,黃盼盼
(1. 海軍裝備部駐南京地區(qū)第二軍事代表室,南京 211153;2. 杭州江南人才服務(wù)有限公司,杭州 310014)
隨著信息時(shí)代的來臨,網(wǎng)絡(luò)技術(shù)飛速發(fā)展,數(shù)據(jù)量呈現(xiàn)爆炸式增長(zhǎng),對(duì)數(shù)據(jù)進(jìn)行快速傳輸與存儲(chǔ)已成為當(dāng)今日益緊迫的需求。目前業(yè)界普遍使用專門的存儲(chǔ)區(qū)域網(wǎng)(Storage Area Network,SAN)存儲(chǔ)網(wǎng)絡(luò)來支持服務(wù)器與存儲(chǔ)設(shè)備之間數(shù)據(jù)的快速傳輸[1-2]。針對(duì)大型復(fù)雜電子裝備的通信網(wǎng)絡(luò),選擇光纖通道作為主干網(wǎng)絡(luò),構(gòu)建包含F(xiàn)C、以太網(wǎng)、RapidIO等多種協(xié)議的融合網(wǎng)絡(luò)系統(tǒng),實(shí)現(xiàn)了不同協(xié)議之間的實(shí)時(shí)、高效轉(zhuǎn)換,有效降低了多種網(wǎng)絡(luò)協(xié)議設(shè)備互聯(lián)的成本和技術(shù)風(fēng)險(xiǎn)[3]。
光纖通道是一種用來傳輸高速數(shù)據(jù)的通信協(xié)議,滿足系統(tǒng)結(jié)構(gòu)的標(biāo)準(zhǔn)化,適合對(duì)大量、高速的信息進(jìn)行可靠的傳輸和處理[4]。以太網(wǎng)從最初的十兆銅軸電纜到百兆以太網(wǎng)再到千兆以太網(wǎng),其發(fā)展從未間斷[5]。運(yùn)行在以太網(wǎng)上層的TCP/IP協(xié)議可以用于數(shù)據(jù)傳輸,其中ICMP作為控制報(bào)文協(xié)議,可用來傳遞差錯(cuò)報(bào)文和其他需要注意的信息,如Ping程序就是使用的ICMP協(xié)議;TCP提供一種可靠的、面向連接的字節(jié)流服務(wù),如FTP文件傳輸協(xié)議;UDP協(xié)議缺乏可靠性,優(yōu)點(diǎn)是使用更少的開銷,與TCP相比,UDP協(xié)議增加了對(duì)多播和廣播的支持[6]。
文獻(xiàn)[7]設(shè)計(jì)了一種基于FPGA的光纖通道協(xié)議處理方案,實(shí)現(xiàn)了FC-2層的數(shù)據(jù)收發(fā)和流量控制、FC-1層的8 B/10 B編解碼和FC-0層的串并轉(zhuǎn)換等功能;文獻(xiàn)[8]提出了一種基于FPGA的高性能光纖通道引擎設(shè)計(jì)方法,實(shí)現(xiàn)了以序列為交互中介的高效軟硬件協(xié)同解決方案;文獻(xiàn)[9]設(shè)計(jì)了一種光纖數(shù)據(jù)傳輸方案,詳細(xì)介紹了收發(fā)控制邏輯的設(shè)計(jì)以及高速收發(fā)器的配置,并根據(jù)AXI4-Stream總線實(shí)現(xiàn)了光纖通道和PCI Express通道之間的數(shù)據(jù)交互;文獻(xiàn)[10]設(shè)計(jì)了FC協(xié)議與萬兆以太網(wǎng)橋接方案,但僅支持FC-AE-ASM與UDP協(xié)議之間的協(xié)議轉(zhuǎn)換,而不支持FC與ICMP、TCP協(xié)議之間的轉(zhuǎn)換,且缺少對(duì)ARP協(xié)議的處理,需要人工獲取MAC地址并進(jìn)行手動(dòng)配置。
本文在上述文獻(xiàn)的基礎(chǔ)上進(jìn)行了改進(jìn):添加ARP處理模塊,實(shí)現(xiàn)了IP地址到MAC地址的動(dòng)態(tài)映射;增加了FC協(xié)議和ICMP、TCP協(xié)議橋接模塊的設(shè)計(jì);針對(duì)FC協(xié)議和ICMP、TCP 、UDP協(xié)議的雙向轉(zhuǎn)換進(jìn)行了一系列測(cè)試,解決了多網(wǎng)融合系統(tǒng)中以太網(wǎng)設(shè)備跨FC網(wǎng)絡(luò)進(jìn)行FTP文件傳輸與ping網(wǎng)絡(luò)應(yīng)答診斷的問題。系統(tǒng)的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖1所示。
圖1 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖
FC數(shù)據(jù)幀格式中有一套專用的字符集作為數(shù)據(jù)的控制字符,如圖2所示,其中SOF是FC幀的起始符,Header包含類型TYPE、尋址等信息,Payload的長(zhǎng)度范圍是0~2 112字節(jié),CRC校驗(yàn)碼確保數(shù)據(jù)傳輸?shù)恼_性,結(jié)束符EOF表示FC幀的結(jié)束[11]。
圖2 FC幀格式
在本設(shè)計(jì)中,由ICMP和TCP數(shù)據(jù)轉(zhuǎn)換后的FC幀首部類型TYPE為0×05,代表IPv4 over Fibre Channel;由UDP數(shù)據(jù)轉(zhuǎn)換后的FC幀首部類型TYPE為0×49,代表FC-AE-ASM 數(shù)據(jù)。
ICMP、TCP和UDP數(shù)據(jù)包可以概括為圖3所示的序列圖,分別由MAC首部、IP首部和IP數(shù)據(jù)組成,其中IP首部和IP數(shù)據(jù)又組成了IPv4數(shù)據(jù)。
圖3 ICMP、TCP和UDP數(shù)據(jù)包序列圖
ICMP/TCP-FC的橋接過程是將FC的載荷數(shù)據(jù)和以太網(wǎng)包的整個(gè)IPv4數(shù)據(jù)相互填充,以太網(wǎng)的MAC、IP信息和FC的TYPE、ID信息都需要映射得到。轉(zhuǎn)換后的數(shù)據(jù)包IP地址會(huì)隨著橋接表的變化而變化,所以需要重新計(jì)算IP首部檢驗(yàn)和。如果是TCP數(shù)據(jù),TCP檢驗(yàn)和也要重新計(jì)算。
UDP-FC的橋接過程是將UDP和FC的首部信息相互映射,載荷數(shù)據(jù)直接相互填充,所以在UDP轉(zhuǎn)FC時(shí),需要將UDP首部中的服務(wù)類型和端口號(hào)分別映射到FC首部的對(duì)應(yīng)位置;當(dāng)FC數(shù)據(jù)需要轉(zhuǎn)換回UDP數(shù)據(jù)時(shí),再將以上信息填入U(xiǎn)DP首部對(duì)應(yīng)位置。當(dāng)FC轉(zhuǎn)換成UDP后,數(shù)據(jù)包的總長(zhǎng)度、IP首部校驗(yàn)和、UDP長(zhǎng)度及UDP校驗(yàn)和都需要進(jìn)行重新計(jì)算。
本文網(wǎng)絡(luò)協(xié)議轉(zhuǎn)換方案的總體框架結(jié)構(gòu)如圖4所示,系統(tǒng)共有兩條數(shù)據(jù)鏈路:以太網(wǎng)轉(zhuǎn)FC數(shù)據(jù)鏈路和FC轉(zhuǎn)以太網(wǎng)數(shù)據(jù)鏈路。兩者都由過濾模塊、ARP模塊、橋接模塊以及合并模塊組成,其中除了ARP模塊是共用的,其他模塊都不相同。FC接口采用上文提到的FC數(shù)據(jù)幀格式,千兆以太網(wǎng)接口采用AXI4-Stream總線協(xié)議[12]。圖中ARP請(qǐng)求信號(hào)包括請(qǐng)求使能信號(hào)和IP地址,ARP應(yīng)答信號(hào)包括應(yīng)答使能信號(hào)、MAC地址和匹配失敗信號(hào)。
圖4 系統(tǒng)總體框架結(jié)構(gòu)
本設(shè)計(jì)采用的以太網(wǎng)協(xié)議為千兆以太網(wǎng)接口,數(shù)據(jù)速率為1 Gbps,而FC數(shù)據(jù)速率為4 Gbps,兩者的速率并不相等,導(dǎo)致整個(gè)網(wǎng)絡(luò)的傳輸帶寬受限于千兆以太網(wǎng)。因此,在協(xié)議轉(zhuǎn)換設(shè)計(jì)時(shí)需要考慮兩者的速度匹配,以便對(duì)較快的FC數(shù)據(jù)流量進(jìn)行控制,防止在協(xié)議轉(zhuǎn)換過程中出現(xiàn)丟包現(xiàn)象。
3.1.1 以太網(wǎng)過濾模塊
以太網(wǎng)轉(zhuǎn)FC鏈路上的以太網(wǎng)過濾模塊共分為兩層:第1層需要篩選出ARP數(shù)據(jù)包;第2層需要篩選出ICMP、TCP和UDP數(shù)據(jù)包。
第1層過濾先判斷圖3中序列2的報(bào)文類型,若值為0×0 806,則該包的類型為ARP,將其壓入ARP FIFO中;若值為0×0 800,則代表該包為IP協(xié)議,將其壓入第2層過濾FIFO中,其余包都丟棄。
第2層再提取首部序列3中的總長(zhǎng)度,根據(jù)總長(zhǎng)度可以判斷該包是否不大于1 500字節(jié)(1幀以太網(wǎng)數(shù)據(jù)的最大長(zhǎng)度一般是1 500字節(jié))。之后從序列4、5中提取IP地址,發(fā)送給IP-ID橋接表,若存在匹配的橋接信息,則將返回匹配成功的信號(hào)和對(duì)應(yīng)的ID值。如果以上條件全部滿足,再從序列3中提取協(xié)議號(hào),若值為0×01,則該包為ICMP數(shù)據(jù)包;若值為0×06,則為TCP數(shù)據(jù)包;若值為0×11,則為UDP數(shù)據(jù)包。最后將篩選所得數(shù)據(jù)分別壓入對(duì)應(yīng)的 FIFO中,不滿足任何一個(gè)條件的都丟棄。
3.1.2 ARP模塊
ARP實(shí)現(xiàn)了從IP地址到MAC地址的轉(zhuǎn)換,屬于TCP/IP協(xié)議族的一員。在網(wǎng)絡(luò)通信中,網(wǎng)絡(luò)層使用IP地址進(jìn)行尋址,但在實(shí)際的網(wǎng)絡(luò)鏈路上,傳輸數(shù)據(jù)尋址時(shí)使用的是MAC地址[13]。每當(dāng)IP協(xié)議需要將一個(gè)IP數(shù)據(jù)包傳遞給下層的鏈路層時(shí),都要通過ARP協(xié)議獲得目的MAC地址。在以太網(wǎng)轉(zhuǎn)FC鏈路中,ARP模塊只接收由以太網(wǎng)過濾模塊第1層篩選出的ARP數(shù)據(jù)包。
如圖5所示,根據(jù)幀格式中的操作碼可以判斷ARP的類型:ARP請(qǐng)求(值為1)、ARP應(yīng)答(值為2)、RARP請(qǐng)求(值為3)或RARP應(yīng)答(值為4)[6]。若接收到ARP請(qǐng)求,先查看請(qǐng)求IP是否為本機(jī)IP:若是,則構(gòu)建一個(gè)ARP的應(yīng)答包,包的源IP地址和SMAC地址即為本機(jī)地址,目的IP地址和DMAC地址為ARP請(qǐng)求方對(duì)應(yīng)的地址;若不是,丟棄該ARP包并且不做其他任何處理。如果接收到的是ARP應(yīng)答,則將發(fā)送方的IP地址和MAC地址寫入cache表,供FC轉(zhuǎn)以太網(wǎng)模塊進(jìn)行查詢,具體寫入流程后面單獨(dú)介紹。
圖5 IPv4地址映射到MAC地址的ARP幀格式
3.1.3 以太網(wǎng)轉(zhuǎn)FC橋接模塊
以太網(wǎng)轉(zhuǎn)FC模塊是網(wǎng)絡(luò)協(xié)議轉(zhuǎn)換中的關(guān)鍵設(shè)計(jì)之一。由前面分析可知,ICMP、TCP轉(zhuǎn)FC和UDP轉(zhuǎn)FC的過程是不一樣的,首先獲取以太網(wǎng)數(shù)據(jù)IP地址映射所得的ID信息,再根據(jù)不同F(xiàn)IFO中讀取的數(shù)據(jù)進(jìn)行轉(zhuǎn)換。如果是ICMP/TCP FIFO,則只須將ID信息填入FC首部對(duì)應(yīng)位置、類型TYPE修改為0×05,其余首部信息都為定值,再將IPv4 數(shù)據(jù)填充為FC Payload,最后補(bǔ)充發(fā)送FC的幀結(jié)束符。如果檢測(cè)到UDP FIFO為非空,首先提取UDP數(shù)據(jù)的MAC首部、IP首部和UDP首部,映射得到FC首部的對(duì)應(yīng)信息,例如UDP首部中的服務(wù)類型和端口號(hào),分別映射到FC首部中的CS_CTL和OX_ID、RX_ID,再結(jié)合前級(jí)所給的ID地址重組出FC首部,然后將不包含3層首部信息的UDP Payload填充到FC Payload,最后同樣補(bǔ)充發(fā)送FC的幀結(jié)束符。
由于FC數(shù)據(jù)的位寬是4字節(jié),當(dāng)ICMP、TCP的IPv4數(shù)據(jù)長(zhǎng)度或者UDP的Payload長(zhǎng)度不是4字節(jié)整數(shù)倍時(shí),那么FC首部信息中F_CTL的0到1位要進(jìn)行相應(yīng)的修改:00表示Payload無填充,01表示填充1字節(jié),10表示填充2字節(jié),11表示填充3字節(jié)。具體流程如圖6所示,這里選用公平輪詢的仲裁方式來判斷兩個(gè)FIFO是否非空。
圖6 ICMP、TCP和UDP到FC的協(xié)議轉(zhuǎn)換流程
3.1.4 FC合并模塊
經(jīng)過以太網(wǎng)轉(zhuǎn)FC模塊之后,ICMP、TCP數(shù)據(jù)轉(zhuǎn)換成了IPv4 over Fibre Channel的FC數(shù)據(jù);UDP數(shù)據(jù)轉(zhuǎn)換成了FC-AE-ASM數(shù)據(jù),合并模塊需要對(duì)這兩路數(shù)據(jù)的發(fā)送做一個(gè)仲裁。由于沒有特定的優(yōu)先級(jí)要求,本設(shè)計(jì)選用公平輪詢的仲裁方式。
3.2.1 FC過濾模塊
FC轉(zhuǎn)以太網(wǎng)鏈路的FC過濾模塊和以太網(wǎng)過濾模塊相似,但不分層。過濾條件如下所述:
(1) FC幀的總長(zhǎng)度小于等于1 524字節(jié);
(2) SOF為SOFi3;
(3) EOF為EOFt(條件(2)、(3)表明1個(gè)FC序列只有1個(gè)FC幀);
(4) ID通過查找ID-IP橋接表能夠成功匹配到對(duì)應(yīng)的IP信息。
若以上4個(gè)條件都滿足,則將FC數(shù)據(jù)包壓入FC FIFO;反之則丟棄。
3.2.2 ARP模塊
FC轉(zhuǎn)以太網(wǎng)在進(jìn)行協(xié)議轉(zhuǎn)換時(shí),每個(gè)FC數(shù)據(jù)包都會(huì)向ARP模塊發(fā)送1個(gè)ARP請(qǐng)求信號(hào),查詢cache表中的DMAC地址,如圖4所示。接收到該請(qǐng)求后,ARP模塊先查看cache表中是否存在請(qǐng)求IP的有效表項(xiàng):若存在,則返回對(duì)應(yīng)的DMAC值;反之,則將匹配失敗信號(hào)置高,并且構(gòu)建1個(gè)ARP請(qǐng)求包,包的源IP地址和SMAC地址為本機(jī)地址,目的IP地址即為所查IP地址,DMAC地址為廣播0×FFFFFFFFFFFF,該包交由合并模塊進(jìn)行發(fā)送(后面將單獨(dú)介紹)。在1 ms內(nèi)如果有ARP應(yīng)答,則將應(yīng)答方的IP和DMAC地址寫入cache表,并返回給FC轉(zhuǎn)以太網(wǎng)模塊;若超時(shí),則丟棄該FC包。
如果在整個(gè)網(wǎng)絡(luò)中都不存在上述IP,那么每個(gè)需要轉(zhuǎn)換成以太網(wǎng)格式的FC包都會(huì)使ARP模塊產(chǎn)生1個(gè)ARP請(qǐng)求,會(huì)導(dǎo)致數(shù)據(jù)鏈路堵塞。為此,在ARP模塊中加入記憶計(jì)時(shí)功能:當(dāng)某個(gè)IP第1次發(fā)起查詢時(shí),如果沒有對(duì)應(yīng)的MAC地址,則發(fā)送ARP請(qǐng)求,然后存下該IP并開始計(jì)時(shí)1 s,在1 s內(nèi)若該IP再次發(fā)起查詢,則直接置高匹配失敗信號(hào)且不發(fā)送ARP請(qǐng)求,橋接模塊也會(huì)直接丟棄對(duì)應(yīng)的FC包,即對(duì)于同1個(gè)IP來說,在1 s內(nèi)只發(fā)送1個(gè)ARP請(qǐng)求,防止數(shù)據(jù)鏈路因此而產(chǎn)生擁堵。
3.2.3 FC轉(zhuǎn)以太網(wǎng)橋接模塊
在FC轉(zhuǎn)成以太網(wǎng)數(shù)據(jù)的過程中,SMAC通過對(duì)應(yīng)寄存器來獲取,默認(rèn)48位都是0,也可以通過串口手動(dòng)輸入進(jìn)行配置。DMAC則通過查詢ARP模塊獲得,若查詢失敗則丟棄該FC包;反之將查詢所得DMAC填入首部,再根據(jù)類型TYPE值判斷將其轉(zhuǎn)換為ICMP、TCP數(shù)據(jù)還是UDP數(shù)據(jù)。
如果TYPE類型是0×05,須判斷協(xié)議號(hào),若為0×01,只需將FC Payload直接填充為以太網(wǎng)的IPv4數(shù)據(jù),再將映射所得IP地址和重計(jì)算的IP首部檢驗(yàn)和填入對(duì)應(yīng)位置;若協(xié)議號(hào)為0×06,還須重新計(jì)算TCP檢驗(yàn)和。如果TYPE類型是0×49,則根據(jù)FC首部信息和查表所得IP地址重組以太網(wǎng)數(shù)據(jù)包各層首部,再把FC Payload填充為UDP Payload,直至EOF到來。對(duì)于ICMP和TCP數(shù)據(jù)來說,MAC首部為14字節(jié),以太網(wǎng)數(shù)據(jù)AXI4-Stream接口的位寬為8字節(jié),所以在8字節(jié)MAC地址填充完成后,圖3中序列2的前6字節(jié)將會(huì)和IPv4數(shù)據(jù)一起發(fā)送。而對(duì)于UDP數(shù)據(jù)來說,MAC首部加上IP首部再加上UDP首部共有42字節(jié),重計(jì)算后的2字節(jié)UDP校驗(yàn)和將會(huì)與Payload一起發(fā)送,轉(zhuǎn)換流程如圖7所示。
圖7 FC到ICMP、TCP和UDP的協(xié)議轉(zhuǎn)換流程
3.2.4 以太網(wǎng)合并模塊
經(jīng)過FC轉(zhuǎn)以太網(wǎng)模塊之后,轉(zhuǎn)換后的ICMP、TCP和UDP數(shù)據(jù)加上ARP模塊產(chǎn)生的ARP數(shù)據(jù),合并模塊需要對(duì)這4路以太網(wǎng)數(shù)據(jù)的發(fā)送做一個(gè)仲裁。由于4路數(shù)據(jù)沒有特定的優(yōu)先級(jí)要求,這里選用和FC合并模塊相同的公平輪詢仲裁方式。
3.3.1 橋接表寫入及查詢方式
整個(gè)系統(tǒng)要對(duì)不止一條數(shù)據(jù)鏈路進(jìn)行轉(zhuǎn)換,所以橋接表中需要存儲(chǔ)大量的地址信息。在高速網(wǎng)絡(luò)下,為了實(shí)現(xiàn)實(shí)時(shí)存儲(chǔ)和查找,橋接表模塊使用了哈希函數(shù)。把函數(shù)運(yùn)算所得數(shù)值儲(chǔ)存到哈希表中的對(duì)應(yīng)位置,根據(jù)數(shù)據(jù)包首部的ID或IP信息可查詢匹配信息的存儲(chǔ)位置,極大地提高了查表效率[14]。具體寫入和查詢流程如圖8所示。
圖8 橋接表模塊寫入及查詢流程
3.3.2 cache表寫入及查詢方式
ARP模塊中的cache表通過讀取ARP包的對(duì)應(yīng)數(shù)據(jù)進(jìn)行寫入,cache表的寫入和查詢與橋接表相似。本設(shè)計(jì)選擇CRC32算法作為哈希函數(shù)[15],方案如下:限制查詢次數(shù)為兩次,若在寫入操作過程中查詢了兩次后依舊未找到匹配的表項(xiàng),則寫入該新表項(xiàng);若在查詢過程中進(jìn)行了兩次操作后依舊未找到,則輸出匹配失敗標(biāo)志。CRC32算法將32位的IP地址映射到32位的Hash[31:0], 將Hash[15:0]作為第1次查詢的地址,將Hash[31:16]+Hash[15:0]的值作為第2次查詢的地址。除此之外,還要考慮MAC地址更新問題,因?yàn)樗谝欢螘r(shí)間內(nèi)可能會(huì)發(fā)生變化。因此cache中的每個(gè)表項(xiàng)都需要一個(gè)更新時(shí)間,一旦超出這個(gè)時(shí)間限制,該表項(xiàng)將被置為無效。對(duì)于MAC地址的更新處理如下:每個(gè)表項(xiàng)在寫入時(shí)都會(huì)設(shè)置一個(gè)屬于自身的TTL初始值,如果一個(gè)表項(xiàng)在一個(gè)計(jì)時(shí)單位內(nèi)非空且有效,其TTL自動(dòng)減1,當(dāng)減到0時(shí),則將此表項(xiàng)的valid置為0,表明該表項(xiàng)已無效,可以被新的寫入數(shù)據(jù)覆蓋。
4.1.1 ICMP、TCP系統(tǒng)測(cè)試平臺(tái)搭建
為了測(cè)試ICMP/TCP-FC橋接系統(tǒng)的性能,設(shè)計(jì)了如圖9所示的測(cè)試平臺(tái),圖中虛線代表千兆以太網(wǎng)數(shù)據(jù)鏈路,粗實(shí)線代表4G FC數(shù)據(jù)鏈路,點(diǎn)虛線代表測(cè)試板中的協(xié)議轉(zhuǎn)換鏈路。
圖9 ICMP/TCP-FC系統(tǒng)測(cè)試平臺(tái)
4.1.2 主機(jī)Ping從機(jī)測(cè)試
首先在RS232串口中配置測(cè)試板1的橋接表信息和SMAC地址信息,如表1和表2所示,其中IP-ID代表將IP地址映射為ID地址,ID-IP代表將ID地址映射為IP地址,且IP地址的輸入格式為十六進(jìn)制,即0×c0換算為十進(jìn)制等于192,以此類推。然后再配置測(cè)試板2的橋接表和SMAC地址,因?yàn)榕c測(cè)試板1數(shù)據(jù)轉(zhuǎn)換的方向相反,所以表1就是其ID-IP橋接表,表2就是其IP-ID橋接表。
表1 IP-ID橋接表配置信息
表2 ID-IP橋接表配置信息
在主機(jī)上Ping從機(jī),并在從機(jī)上使用軟件wireshark抓取以太網(wǎng)數(shù)據(jù),圖10的前兩個(gè)包為ARP請(qǐng)求和回復(fù)包,之后都是ICMP請(qǐng)求和回復(fù)包。
圖10 主機(jī)Ping從機(jī)的以太網(wǎng)數(shù)據(jù)
當(dāng)ICMP數(shù)據(jù)在FC網(wǎng)絡(luò)上傳輸時(shí),通過分析儀抓取FC數(shù)據(jù),其速率示意如圖11所示,兩路數(shù)據(jù)對(duì)應(yīng)的分別是ICMP請(qǐng)求和ICMP回復(fù),已知ICMP數(shù)據(jù)包每秒發(fā)送1個(gè),因此速率示意圖為鋸齒狀。
圖11 ICMP轉(zhuǎn)成FC的速率示意圖
4.1.3 FC與TCP協(xié)議轉(zhuǎn)換測(cè)試
FTP是廣泛使用的基于TCP的文件傳輸協(xié)議,具有可靠、高效、通用等特點(diǎn),因此本文采用FTP來測(cè)試FC與TCP之間的協(xié)議轉(zhuǎn)換。使用軟件wftpd32在從機(jī)上建立FTP賬號(hào),指向目錄為E:TCP_TEST,該文件夾下有一個(gè)測(cè)試文件test_file1.iso,大小為3.18 GB。在主機(jī)端使用軟件FlashFXP下載該文件,從機(jī)到主機(jī)的FTP文件傳輸過程如圖12所示。
圖12 FTP文件傳輸過程
當(dāng)TCP數(shù)據(jù)在FC網(wǎng)絡(luò)上傳輸時(shí),通過分析儀抓取對(duì)應(yīng)的FC數(shù)據(jù)。圖13中的上下兩個(gè)速率分別代表主機(jī)發(fā)往從機(jī)的ACK數(shù)據(jù)所轉(zhuǎn)換成的FC數(shù)據(jù)速率以及從機(jī)發(fā)往主機(jī)的FTP數(shù)據(jù)所轉(zhuǎn)換成的FC數(shù)據(jù)速率。
圖13 TCP轉(zhuǎn)成FC的速率示意圖
4.2.1 UDP系統(tǒng)測(cè)試平臺(tái)搭建
為了測(cè)試UDP-FC橋接系統(tǒng)中新增的ARP模塊的功能和轉(zhuǎn)換性能,設(shè)計(jì)了如圖14所示的測(cè)試平臺(tái)。
圖14 UDP-FC系統(tǒng)測(cè)試平臺(tái)
4.2.2 UDP轉(zhuǎn)FC鏈路測(cè)試
首先通過串口上傳IP-ID和ID-IP橋接表(為了與前文測(cè)試區(qū)分,修改了橋接表中的IP和ID地址),然后在電腦端配置軟件Fbench發(fā)送長(zhǎng)度一定的UDP數(shù)據(jù),圖15中的數(shù)據(jù)為UDP轉(zhuǎn)換后的FC數(shù)據(jù)。
圖15 UDP轉(zhuǎn)換成的FC數(shù)據(jù)
4.2.3 FC轉(zhuǎn)UDP鏈路測(cè)試
操作測(cè)試儀的測(cè)試口發(fā)送包長(zhǎng)隨機(jī)的4G FC數(shù)據(jù),并將源ID和目的ID分別設(shè)置成與橋接表相對(duì)應(yīng)的地址,類型TYPE設(shè)置為0×49,通過分析口抓取的FC數(shù)據(jù)如圖16所示。
圖16 轉(zhuǎn)成UDP前的FC數(shù)據(jù)
橋接系統(tǒng)接收到FC數(shù)據(jù)后,在轉(zhuǎn)換之前需要先發(fā)送ARP包來獲取DMAC,待首部信息獲取完整后再發(fā)送UDP數(shù)據(jù),轉(zhuǎn)換成的以太網(wǎng)數(shù)據(jù)在電腦端通過軟件wireshark進(jìn)行抓取。圖17中的前兩個(gè)數(shù)據(jù)分別為ARP請(qǐng)求和ARP應(yīng)答,之后的UDP數(shù)據(jù)由圖16中的FC數(shù)據(jù)轉(zhuǎn)換而來,兩者是一一對(duì)應(yīng)的。
圖17 FC轉(zhuǎn)成的UDP數(shù)據(jù)
4.2.4 FC與UDP轉(zhuǎn)換速率測(cè)試
如圖18所示,F(xiàn)C Port(1.2.3)是測(cè)試儀發(fā)給分析儀的FC數(shù)據(jù)速率,即FC轉(zhuǎn)UDP鏈路的轉(zhuǎn)換速率; FC Port(1.2.4)是測(cè)試板發(fā)給分析儀的FC數(shù)據(jù)速率,即UDP轉(zhuǎn)FC鏈路的轉(zhuǎn)換速率。兩個(gè)協(xié)議相互轉(zhuǎn)換的速率都能穩(wěn)定在114 MB/s以上,達(dá)到了千兆以太網(wǎng)傳輸帶寬的要求,符合設(shè)計(jì)預(yù)期。
圖18 UDP協(xié)議轉(zhuǎn)換速率
本文提出了一種基于FPGA的FC和千兆以太網(wǎng)橋接系統(tǒng)。首先設(shè)置特定的條件,篩選出需要轉(zhuǎn)換的FC數(shù)據(jù)包和ICMP、TCP以及UDP數(shù)據(jù)包;然后運(yùn)用哈希查表映射出對(duì)應(yīng)的尋址信息,其余首部信息相互填充;最后對(duì)數(shù)據(jù)包的格式進(jìn)行重組并發(fā)送。實(shí)驗(yàn)結(jié)果表明,F(xiàn)C協(xié)議和ICMP、TCP、UDP協(xié)議能夠?qū)崿F(xiàn)相互之間的正確轉(zhuǎn)換,其轉(zhuǎn)換速率滿足千兆以太網(wǎng)傳輸帶寬要求,沒有出現(xiàn)丟包或者錯(cuò)包的情況。下一步工作是對(duì)UDP報(bào)文切分/重組的支持以及對(duì)萬兆網(wǎng)/16G FC的支持。