王 飛，黃盼盼

(1. 海軍裝備部駐南京地區(qū)第二軍事代表室，南京 211153；2. 杭州江南人才服務(wù)有限公司，杭州 310014)

0 引 言

隨著信息時(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)圖

1 協(xié)議轉(zhuǎn)換分析

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ì)算。

2 系統(tǒng)總體框架

本文網(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 硬件邏輯設(shè)計(jì)

3.1 以太網(wǎng)轉(zhuǎn)FC設(shè)計(jì)

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 FC轉(zhuǎn)以太網(wǎng)設(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 查表設(shè)計(jì)

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 系統(tǒng)測(cè)試

4.1 FC與ICMP、TCP協(xié)議轉(zhuǎn)換測(cè)試

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 FC與UDP協(xié)議轉(zhuǎn)換測(cè)試

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)換速率

5 結(jié)束語

本文提出了一種基于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的支持。