王 飛，黃盼盼

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

0 引 言

隨著信息時代的來臨，網(wǎng)絡(luò)技術(shù)飛速發(fā)展，數(shù)據(jù)量呈現(xiàn)爆炸式增長，對數(shù)據(jù)進行快速傳輸與存儲已成為當今日益緊迫的需求。目前業(yè)界普遍使用專門的存儲區(qū)域網(wǎng)(Storage Area Network，SAN)存儲網(wǎng)絡(luò)來支持服務(wù)器與存儲設(shè)備之間數(shù)據(jù)的快速傳輸[1-2]。針對大型復(fù)雜電子裝備的通信網(wǎng)絡(luò)，選擇光纖通道作為主干網(wǎng)絡(luò)，構(gòu)建包含F(xiàn)C、以太網(wǎng)、RapidIO等多種協(xié)議的融合網(wǎng)絡(luò)系統(tǒng)，實現(xiàn)了不同協(xié)議之間的實時、高效轉(zhuǎn)換，有效降低了多種網(wǎng)絡(luò)協(xié)議設(shè)備互聯(lián)的成本和技術(shù)風險[3]。

光纖通道是一種用來傳輸高速數(shù)據(jù)的通信協(xié)議，滿足系統(tǒng)結(jié)構(gòu)的標準化，適合對大量、高速的信息進行可靠的傳輸和處理[4]。以太網(wǎng)從最初的十兆銅軸電纜到百兆以太網(wǎng)再到千兆以太網(wǎng)，其發(fā)展從未間斷[5]。運行在以太網(wǎng)上層的TCP/IP協(xié)議可以用于數(shù)據(jù)傳輸，其中ICMP作為控制報文協(xié)議，可用來傳遞差錯報文和其他需要注意的信息，如Ping程序就是使用的ICMP協(xié)議；TCP提供一種可靠的、面向連接的字節(jié)流服務(wù)，如FTP文件傳輸協(xié)議；UDP協(xié)議缺乏可靠性，優(yōu)點是使用更少的開銷，與TCP相比，UDP協(xié)議增加了對多播和廣播的支持[6]。

文獻[7]設(shè)計了一種基于FPGA的光纖通道協(xié)議處理方案，實現(xiàn)了FC-2層的數(shù)據(jù)收發(fā)和流量控制、FC-1層的8 B/10 B編解碼和FC-0層的串并轉(zhuǎn)換等功能；文獻[8]提出了一種基于FPGA的高性能光纖通道引擎設(shè)計方法，實現(xiàn)了以序列為交互中介的高效軟硬件協(xié)同解決方案；文獻[9]設(shè)計了一種光纖數(shù)據(jù)傳輸方案，詳細介紹了收發(fā)控制邏輯的設(shè)計以及高速收發(fā)器的配置，并根據(jù)AXI4-Stream總線實現(xiàn)了光纖通道和PCI Express通道之間的數(shù)據(jù)交互；文獻[10]設(shè)計了FC協(xié)議與萬兆以太網(wǎng)橋接方案，但僅支持FC-AE-ASM與UDP協(xié)議之間的協(xié)議轉(zhuǎn)換，而不支持FC與ICMP、TCP協(xié)議之間的轉(zhuǎn)換，且缺少對ARP協(xié)議的處理，需要人工獲取MAC地址并進行手動配置。

本文在上述文獻的基礎(chǔ)上進行了改進：添加ARP處理模塊，實現(xiàn)了IP地址到MAC地址的動態(tài)映射；增加了FC協(xié)議和ICMP、TCP協(xié)議橋接模塊的設(shè)計；針對FC協(xié)議和ICMP、TCP 、UDP協(xié)議的雙向轉(zhuǎn)換進行了一系列測試，解決了多網(wǎng)融合系統(tǒng)中以太網(wǎng)設(shè)備跨FC網(wǎng)絡(luò)進行FTP文件傳輸與ping網(wǎng)絡(luò)應(yīng)答診斷的問題。系統(tǒng)的網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖1所示。

圖1 網(wǎng)絡(luò)拓撲結(jié)構(gòu)圖

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

FC數(shù)據(jù)幀格式中有一套專用的字符集作為數(shù)據(jù)的控制字符，如圖2所示，其中SOF是FC幀的起始符，Header包含類型TYPE、尋址等信息，Payload的長度范圍是0～2 112字節(jié)，CRC校驗碼確保數(shù)據(jù)傳輸?shù)恼_性，結(jié)束符EOF表示FC幀的結(jié)束[11]。

圖2 FC幀格式

在本設(shè)計中，由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)包的整個IPv4數(shù)據(jù)相互填充，以太網(wǎng)的MAC、IP信息和FC的TYPE、ID信息都需要映射得到。轉(zhuǎn)換后的數(shù)據(jù)包IP地址會隨著橋接表的變化而變化，所以需要重新計算IP首部檢驗和。如果是TCP數(shù)據(jù)，TCP檢驗和也要重新計算。

UDP-FC的橋接過程是將UDP和FC的首部信息相互映射，載荷數(shù)據(jù)直接相互填充，所以在UDP轉(zhuǎn)FC時，需要將UDP首部中的服務(wù)類型和端口號分別映射到FC首部的對應(yīng)位置；當FC數(shù)據(jù)需要轉(zhuǎn)換回UDP數(shù)據(jù)時，再將以上信息填入UDP首部對應(yīng)位置。當FC轉(zhuǎn)換成UDP后，數(shù)據(jù)包的總長度、IP首部校驗和、UDP長度及UDP校驗和都需要進行重新計算。

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請求信號包括請求使能信號和IP地址，ARP應(yīng)答信號包括應(yīng)答使能信號、MAC地址和匹配失敗信號。

圖4 系統(tǒng)總體框架結(jié)構(gòu)

本設(shè)計采用的以太網(wǎng)協(xié)議為千兆以太網(wǎng)接口，數(shù)據(jù)速率為1 Gbps，而FC數(shù)據(jù)速率為4 Gbps，兩者的速率并不相等，導(dǎo)致整個網(wǎng)絡(luò)的傳輸帶寬受限于千兆以太網(wǎng)。因此，在協(xié)議轉(zhuǎn)換設(shè)計時需要考慮兩者的速度匹配，以便對較快的FC數(shù)據(jù)流量進行控制，防止在協(xié)議轉(zhuǎn)換過程中出現(xiàn)丟包現(xiàn)象。

3 硬件邏輯設(shè)計

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

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的報文類型，若值為0×0 806，則該包的類型為ARP，將其壓入ARP FIFO中；若值為0×0 800，則代表該包為IP協(xié)議，將其壓入第2層過濾FIFO中，其余包都丟棄。

第2層再提取首部序列3中的總長度，根據(jù)總長度可以判斷該包是否不大于1 500字節(jié)(1幀以太網(wǎng)數(shù)據(jù)的最大長度一般是1 500字節(jié))。之后從序列4、5中提取IP地址，發(fā)送給IP-ID橋接表，若存在匹配的橋接信息，則將返回匹配成功的信號和對應(yīng)的ID值。如果以上條件全部滿足，再從序列3中提取協(xié)議號，若值為0×01，則該包為ICMP數(shù)據(jù)包；若值為0×06，則為TCP數(shù)據(jù)包；若值為0×11，則為UDP數(shù)據(jù)包。最后將篩選所得數(shù)據(jù)分別壓入對應(yīng)的 FIFO中，不滿足任何一個條件的都丟棄。

3.1.2 ARP模塊

ARP實現(xiàn)了從IP地址到MAC地址的轉(zhuǎn)換，屬于TCP/IP協(xié)議族的一員。在網(wǎng)絡(luò)通信中，網(wǎng)絡(luò)層使用IP地址進行尋址，但在實際的網(wǎng)絡(luò)鏈路上，傳輸數(shù)據(jù)尋址時使用的是MAC地址[13]。每當IP協(xié)議需要將一個IP數(shù)據(jù)包傳遞給下層的鏈路層時，都要通過ARP協(xié)議獲得目的MAC地址。在以太網(wǎng)轉(zhuǎn)FC鏈路中，ARP模塊只接收由以太網(wǎng)過濾模塊第1層篩選出的ARP數(shù)據(jù)包。

如圖5所示，根據(jù)幀格式中的操作碼可以判斷ARP的類型：ARP請求(值為1)、ARP應(yīng)答(值為2)、RARP請求(值為3)或RARP應(yīng)答(值為4)[6]。若接收到ARP請求，先查看請求IP是否為本機IP：若是，則構(gòu)建一個ARP的應(yīng)答包，包的源IP地址和SMAC地址即為本機地址，目的IP地址和DMAC地址為ARP請求方對應(yīng)的地址；若不是，丟棄該ARP包并且不做其他任何處理。如果接收到的是ARP應(yīng)答，則將發(fā)送方的IP地址和MAC地址寫入cache表，供FC轉(zhuǎn)以太網(wǎng)模塊進行查詢，具體寫入流程后面單獨介紹。

圖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è)計之一。由前面分析可知，ICMP、TCP轉(zhuǎn)FC和UDP轉(zhuǎn)FC的過程是不一樣的，首先獲取以太網(wǎng)數(shù)據(jù)IP地址映射所得的ID信息，再根據(jù)不同F(xiàn)IFO中讀取的數(shù)據(jù)進行轉(zhuǎn)換。如果是ICMP/TCP FIFO，則只須將ID信息填入FC首部對應(yīng)位置、類型TYPE修改為0×05，其余首部信息都為定值，再將IPv4 數(shù)據(jù)填充為FC Payload，最后補充發(fā)送FC的幀結(jié)束符。如果檢測到UDP FIFO為非空，首先提取UDP數(shù)據(jù)的MAC首部、IP首部和UDP首部，映射得到FC首部的對應(yīng)信息，例如UDP首部中的服務(wù)類型和端口號，分別映射到FC首部中的CS_CTL和OX_ID、RX_ID，再結(jié)合前級所給的ID地址重組出FC首部，然后將不包含3層首部信息的UDP Payload填充到FC Payload，最后同樣補充發(fā)送FC的幀結(jié)束符。

由于FC數(shù)據(jù)的位寬是4字節(jié)，當ICMP、TCP的IPv4數(shù)據(jù)長度或者UDP的Payload長度不是4字節(jié)整數(shù)倍時，那么FC首部信息中F_CTL的0到1位要進行相應(yīng)的修改：00表示Payload無填充，01表示填充1字節(jié)，10表示填充2字節(jié)，11表示填充3字節(jié)。具體流程如圖6所示，這里選用公平輪詢的仲裁方式來判斷兩個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ù)，合并模塊需要對這兩路數(shù)據(jù)的發(fā)送做一個仲裁。由于沒有特定的優(yōu)先級要求，本設(shè)計選用公平輪詢的仲裁方式。

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

3.2.1 FC過濾模塊

FC轉(zhuǎn)以太網(wǎng)鏈路的FC過濾模塊和以太網(wǎng)過濾模塊相似，但不分層。過濾條件如下所述：

(1) FC幀的總長度小于等于1 524字節(jié)；

(2) SOF為SOFi3；

(3) EOF為EOFt(條件(2)、(3)表明1個FC序列只有1個FC幀)；

(4) ID通過查找ID-IP橋接表能夠成功匹配到對應(yīng)的IP信息。

若以上4個條件都滿足，則將FC數(shù)據(jù)包壓入FC FIFO；反之則丟棄。

3.2.2 ARP模塊

FC轉(zhuǎn)以太網(wǎng)在進行協(xié)議轉(zhuǎn)換時，每個FC數(shù)據(jù)包都會向ARP模塊發(fā)送1個ARP請求信號，查詢cache表中的DMAC地址，如圖4所示。接收到該請求后，ARP模塊先查看cache表中是否存在請求IP的有效表項：若存在，則返回對應(yīng)的DMAC值；反之，則將匹配失敗信號置高，并且構(gòu)建1個ARP請求包，包的源IP地址和SMAC地址為本機地址，目的IP地址即為所查IP地址，DMAC地址為廣播0×FFFFFFFFFFFF，該包交由合并模塊進行發(fā)送(后面將單獨介紹)。在1 ms內(nèi)如果有ARP應(yīng)答，則將應(yīng)答方的IP和DMAC地址寫入cache表，并返回給FC轉(zhuǎn)以太網(wǎng)模塊；若超時，則丟棄該FC包。

如果在整個網(wǎng)絡(luò)中都不存在上述IP，那么每個需要轉(zhuǎn)換成以太網(wǎng)格式的FC包都會使ARP模塊產(chǎn)生1個ARP請求，會導(dǎo)致數(shù)據(jù)鏈路堵塞。為此，在ARP模塊中加入記憶計時功能：當某個IP第1次發(fā)起查詢時，如果沒有對應(yīng)的MAC地址，則發(fā)送ARP請求，然后存下該IP并開始計時1 s，在1 s內(nèi)若該IP再次發(fā)起查詢，則直接置高匹配失敗信號且不發(fā)送ARP請求，橋接模塊也會直接丟棄對應(yīng)的FC包，即對于同1個IP來說，在1 s內(nèi)只發(fā)送1個ARP請求，防止數(shù)據(jù)鏈路因此而產(chǎn)生擁堵。

3.2.3 FC轉(zhuǎn)以太網(wǎng)橋接模塊

在FC轉(zhuǎn)成以太網(wǎng)數(shù)據(jù)的過程中，SMAC通過對應(yīng)寄存器來獲取，默認48位都是0，也可以通過串口手動輸入進行配置。DMAC則通過查詢ARP模塊獲得，若查詢失敗則丟棄該FC包；反之將查詢所得DMAC填入首部，再根據(jù)類型TYPE值判斷將其轉(zhuǎn)換為ICMP、TCP數(shù)據(jù)還是UDP數(shù)據(jù)。

如果TYPE類型是0×05，須判斷協(xié)議號，若為0×01，只需將FC Payload直接填充為以太網(wǎng)的IPv4數(shù)據(jù)，再將映射所得IP地址和重計算的IP首部檢驗和填入對應(yīng)位置；若協(xié)議號為0×06，還須重新計算TCP檢驗和。如果TYPE類型是0×49，則根據(jù)FC首部信息和查表所得IP地址重組以太網(wǎng)數(shù)據(jù)包各層首部，再把FC Payload填充為UDP Payload，直至EOF到來。對于ICMP和TCP數(shù)據(jù)來說，MAC首部為14字節(jié)，以太網(wǎng)數(shù)據(jù)AXI4-Stream接口的位寬為8字節(jié)，所以在8字節(jié)MAC地址填充完成后，圖3中序列2的前6字節(jié)將會和IPv4數(shù)據(jù)一起發(fā)送。而對于UDP數(shù)據(jù)來說，MAC首部加上IP首部再加上UDP首部共有42字節(jié)，重計算后的2字節(jié)UDP校驗和將會與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ù)，合并模塊需要對這4路以太網(wǎng)數(shù)據(jù)的發(fā)送做一個仲裁。由于4路數(shù)據(jù)沒有特定的優(yōu)先級要求，這里選用和FC合并模塊相同的公平輪詢仲裁方式。

3.3 查表設(shè)計

3.3.1 橋接表寫入及查詢方式

整個系統(tǒng)要對不止一條數(shù)據(jù)鏈路進行轉(zhuǎn)換，所以橋接表中需要存儲大量的地址信息。在高速網(wǎng)絡(luò)下，為了實現(xiàn)實時存儲和查找，橋接表模塊使用了哈希函數(shù)。把函數(shù)運算所得數(shù)值儲存到哈希表中的對應(yīng)位置，根據(jù)數(shù)據(jù)包首部的ID或IP信息可查詢匹配信息的存儲位置，極大地提高了查表效率[14]。具體寫入和查詢流程如圖8所示。

圖8 橋接表模塊寫入及查詢流程

3.3.2 cache表寫入及查詢方式

ARP模塊中的cache表通過讀取ARP包的對應(yīng)數(shù)據(jù)進行寫入，cache表的寫入和查詢與橋接表相似。本設(shè)計選擇CRC32算法作為哈希函數(shù)[15]，方案如下：限制查詢次數(shù)為兩次，若在寫入操作過程中查詢了兩次后依舊未找到匹配的表項，則寫入該新表項；若在查詢過程中進行了兩次操作后依舊未找到，則輸出匹配失敗標志。CRC32算法將32位的IP地址映射到32位的Hash[31：0]， 將Hash[15：0]作為第1次查詢的地址，將Hash[31：16]+Hash[15：0]的值作為第2次查詢的地址。除此之外，還要考慮MAC地址更新問題，因為它在一段時間內(nèi)可能會發(fā)生變化。因此cache中的每個表項都需要一個更新時間，一旦超出這個時間限制，該表項將被置為無效。對于MAC地址的更新處理如下：每個表項在寫入時都會設(shè)置一個屬于自身的TTL初始值，如果一個表項在一個計時單位內(nèi)非空且有效，其TTL自動減1，當減到0時，則將此表項的valid置為0，表明該表項已無效，可以被新的寫入數(shù)據(jù)覆蓋。

4 系統(tǒng)測試

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

4.1.1 ICMP、TCP系統(tǒng)測試平臺搭建

為了測試ICMP/TCP-FC橋接系統(tǒng)的性能，設(shè)計了如圖9所示的測試平臺，圖中虛線代表千兆以太網(wǎng)數(shù)據(jù)鏈路，粗實線代表4G FC數(shù)據(jù)鏈路，點虛線代表測試板中的協(xié)議轉(zhuǎn)換鏈路。

圖9 ICMP/TCP-FC系統(tǒng)測試平臺

4.1.2 主機Ping從機測試

首先在RS232串口中配置測試板1的橋接表信息和SMAC地址信息，如表1和表2所示，其中IP-ID代表將IP地址映射為ID地址，ID-IP代表將ID地址映射為IP地址，且IP地址的輸入格式為十六進制，即0×c0換算為十進制等于192，以此類推。然后再配置測試板2的橋接表和SMAC地址，因為與測試板1數(shù)據(jù)轉(zhuǎn)換的方向相反，所以表1就是其ID-IP橋接表，表2就是其IP-ID橋接表。

表1 IP-ID橋接表配置信息

表2 ID-IP橋接表配置信息

在主機上Ping從機，并在從機上使用軟件wireshark抓取以太網(wǎng)數(shù)據(jù)，圖10的前兩個包為ARP請求和回復(fù)包，之后都是ICMP請求和回復(fù)包。

圖10 主機Ping從機的以太網(wǎng)數(shù)據(jù)

當ICMP數(shù)據(jù)在FC網(wǎng)絡(luò)上傳輸時，通過分析儀抓取FC數(shù)據(jù)，其速率示意如圖11所示，兩路數(shù)據(jù)對應(yīng)的分別是ICMP請求和ICMP回復(fù)，已知ICMP數(shù)據(jù)包每秒發(fā)送1個，因此速率示意圖為鋸齒狀。

圖11 ICMP轉(zhuǎn)成FC的速率示意圖

4.1.3 FC與TCP協(xié)議轉(zhuǎn)換測試

FTP是廣泛使用的基于TCP的文件傳輸協(xié)議，具有可靠、高效、通用等特點，因此本文采用FTP來測試FC與TCP之間的協(xié)議轉(zhuǎn)換。使用軟件wftpd32在從機上建立FTP賬號，指向目錄為E：TCP_TEST，該文件夾下有一個測試文件test_file1.iso，大小為3.18 GB。在主機端使用軟件FlashFXP下載該文件，從機到主機的FTP文件傳輸過程如圖12所示。

圖12 FTP文件傳輸過程

當TCP數(shù)據(jù)在FC網(wǎng)絡(luò)上傳輸時，通過分析儀抓取對應(yīng)的FC數(shù)據(jù)。圖13中的上下兩個速率分別代表主機發(fā)往從機的ACK數(shù)據(jù)所轉(zhuǎn)換成的FC數(shù)據(jù)速率以及從機發(fā)往主機的FTP數(shù)據(jù)所轉(zhuǎn)換成的FC數(shù)據(jù)速率。

圖13 TCP轉(zhuǎn)成FC的速率示意圖

4.2 FC與UDP協(xié)議轉(zhuǎn)換測試

4.2.1 UDP系統(tǒng)測試平臺搭建

為了測試UDP-FC橋接系統(tǒng)中新增的ARP模塊的功能和轉(zhuǎn)換性能，設(shè)計了如圖14所示的測試平臺。

圖14 UDP-FC系統(tǒng)測試平臺

4.2.2 UDP轉(zhuǎn)FC鏈路測試

首先通過串口上傳IP-ID和ID-IP橋接表(為了與前文測試區(qū)分，修改了橋接表中的IP和ID地址)，然后在電腦端配置軟件Fbench發(fā)送長度一定的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鏈路測試

操作測試儀的測試口發(fā)送包長隨機的4G FC數(shù)據(jù)，并將源ID和目的ID分別設(shè)置成與橋接表相對應(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進行抓取。圖17中的前兩個數(shù)據(jù)分別為ARP請求和ARP應(yīng)答，之后的UDP數(shù)據(jù)由圖16中的FC數(shù)據(jù)轉(zhuǎn)換而來，兩者是一一對應(yīng)的。

圖17 FC轉(zhuǎn)成的UDP數(shù)據(jù)

4.2.4 FC與UDP轉(zhuǎn)換速率測試

如圖18所示，F(xiàn)C Port(1.2.3)是測試儀發(fā)給分析儀的FC數(shù)據(jù)速率，即FC轉(zhuǎn)UDP鏈路的轉(zhuǎn)換速率； FC Port(1.2.4)是測試板發(fā)給分析儀的FC數(shù)據(jù)速率，即UDP轉(zhuǎn)FC鏈路的轉(zhuǎn)換速率。兩個協(xié)議相互轉(zhuǎn)換的速率都能穩(wěn)定在114 MB/s以上，達到了千兆以太網(wǎng)傳輸帶寬的要求，符合設(shè)計預(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īng)的尋址信息，其余首部信息相互填充；最后對數(shù)據(jù)包的格式進行重組并發(fā)送。實驗結(jié)果表明，F(xiàn)C協(xié)議和ICMP、TCP、UDP協(xié)議能夠?qū)崿F(xiàn)相互之間的正確轉(zhuǎn)換，其轉(zhuǎn)換速率滿足千兆以太網(wǎng)傳輸帶寬要求，沒有出現(xiàn)丟包或者錯包的情況。下一步工作是對UDP報文切分/重組的支持以及對萬兆網(wǎng)/16G FC的支持。