基于FPGA的FC和千兆以太网桥接器设计

王 飞，黄盼盼

(1. 海军装备部驻南京地区第二军事代表室，南京 211153；2. 杭州江南人才服务有限公司，杭州 310014)

0 引 言

随着信息时代的来临，网络技术飞速发展，数据量呈现爆炸式增长，对数据进行快速传输与存储已成为当今日益紧迫的需求。目前业界普遍使用专门的存储区域网(Storage Area Network，SAN)存储网络来支持服务器与存储设备之间数据的快速传输[1-2]。针对大型复杂电子装备的通信网络，选择光纤通道作为主干网络，构建包含FC、以太网、RapidIO等多种协议的融合网络系统，实现了不同协议之间的实时、高效转换，有效降低了多种网络协议设备互联的成本和技术风险[3]。

光纤通道是一种用来传输高速数据的通信协议，满足系统结构的标准化，适合对大量、高速的信息进行可靠的传输和处理[4]。以太网从最初的十兆铜轴电缆到百兆以太网再到千兆以太网，其发展从未间断[5]。运行在以太网上层的TCP/IP协议可以用于数据传输，其中ICMP作为控制报文协议，可用来传递差错报文和其他需要注意的信息，如Ping程序就是使用的ICMP协议；TCP提供一种可靠的、面向连接的字节流服务，如FTP文件传输协议；UDP协议缺乏可靠性，优点是使用更少的开销，与TCP相比，UDP协议增加了对多播和广播的支持[6]。

文献[7]设计了一种基于FPGA的光纤通道协议处理方案，实现了FC-2层的数据收发和流量控制、FC-1层的8 B/10 B编解码和FC-0层的串并转换等功能；文献[8]提出了一种基于FPGA的高性能光纤通道引擎设计方法，实现了以序列为交互中介的高效软硬件协同解决方案；文献[9]设计了一种光纤数据传输方案，详细介绍了收发控制逻辑的设计以及高速收发器的配置，并根据AXI4-Stream总线实现了光纤通道和PCI Express通道之间的数据交互；文献[10]设计了FC协议与万兆以太网桥接方案，但仅支持FC-AE-ASM与UDP协议之间的协议转换，而不支持FC与ICMP、TCP协议之间的转换，且缺少对ARP协议的处理，需要人工获取MAC地址并进行手动配置。

本文在上述文献的基础上进行了改进：添加ARP处理模块，实现了IP地址到MAC地址的动态映射；增加了FC协议和ICMP、TCP协议桥接模块的设计；针对FC协议和ICMP、TCP 、UDP协议的双向转换进行了一系列测试，解决了多网融合系统中以太网设备跨FC网络进行FTP文件传输与ping网络应答诊断的问题。系统的网络拓扑结构如图1所示。

图1 网络拓扑结构图

1 协议转换分析

FC数据帧格式中有一套专用的字符集作为数据的控制字符，如图2所示，其中SOF是FC帧的起始符，Header包含类型TYPE、寻址等信息，Payload的长度范围是0～2 112字节，CRC校验码确保数据传输的正确性，结束符EOF表示FC帧的结束[11]。

图2 FC帧格式

在本设计中，由ICMP和TCP数据转换后的FC帧首部类型TYPE为0×05，代表IPv4 over Fibre Channel；由UDP数据转换后的FC帧首部类型TYPE为0×49，代表FC-AE-ASM 数据。

ICMP、TCP和UDP数据包可以概括为图3所示的序列图，分别由MAC首部、IP首部和IP数据组成，其中IP首部和IP数据又组成了IPv4数据。

图3 ICMP、TCP和UDP数据包序列图

ICMP/TCP-FC的桥接过程是将FC的载荷数据和以太网包的整个IPv4数据相互填充，以太网的MAC、IP信息和FC的TYPE、ID信息都需要映射得到。转换后的数据包IP地址会随着桥接表的变化而变化，所以需要重新计算IP首部检验和。如果是TCP数据，TCP检验和也要重新计算。

UDP-FC的桥接过程是将UDP和FC的首部信息相互映射，载荷数据直接相互填充，所以在UDP转FC时，需要将UDP首部中的服务类型和端口号分别映射到FC首部的对应位置；当FC数据需要转换回UDP数据时，再将以上信息填入UDP首部对应位置。当FC转换成UDP后，数据包的总长度、IP首部校验和、UDP长度及UDP校验和都需要进行重新计算。

2 系统总体框架

本文网络协议转换方案的总体框架结构如图4所示，系统共有两条数据链路：以太网转FC数据链路和FC转以太网数据链路。两者都由过滤模块、ARP模块、桥接模块以及合并模块组成，其中除了ARP模块是共用的，其他模块都不相同。FC接口采用上文提到的FC数据帧格式，千兆以太网接口采用AXI4-Stream总线协议[12]。图中ARP请求信号包括请求使能信号和IP地址，ARP应答信号包括应答使能信号、MAC地址和匹配失败信号。

图4 系统总体框架结构

本设计采用的以太网协议为千兆以太网接口，数据速率为1 Gbps，而FC数据速率为4 Gbps，两者的速率并不相等，导致整个网络的传输带宽受限于千兆以太网。因此，在协议转换设计时需要考虑两者的速度匹配，以便对较快的FC数据流量进行控制，防止在协议转换过程中出现丢包现象。

3 硬件逻辑设计

3.1 以太网转FC设计

3.1.1 以太网过滤模块

以太网转FC链路上的以太网过滤模块共分为两层：第1层需要筛选出ARP数据包；第2层需要筛选出ICMP、TCP和UDP数据包。

第1层过滤先判断图3中序列2的报文类型，若值为0×0 806，则该包的类型为ARP，将其压入ARP FIFO中；若值为0×0 800，则代表该包为IP协议，将其压入第2层过滤FIFO中，其余包都丢弃。

第2层再提取首部序列3中的总长度，根据总长度可以判断该包是否不大于1 500字节(1帧以太网数据的最大长度一般是1 500字节)。之后从序列4、5中提取IP地址，发送给IP-ID桥接表，若存在匹配的桥接信息，则将返回匹配成功的信号和对应的ID值。如果以上条件全部满足，再从序列3中提取协议号，若值为0×01，则该包为ICMP数据包；若值为0×06，则为TCP数据包；若值为0×11，则为UDP数据包。最后将筛选所得数据分别压入对应的 FIFO中，不满足任何一个条件的都丢弃。

3.1.2 ARP模块

ARP实现了从IP地址到MAC地址的转换，属于TCP/IP协议族的一员。在网络通信中，网络层使用IP地址进行寻址，但在实际的网络链路上，传输数据寻址时使用的是MAC地址[13]。每当IP协议需要将一个IP数据包传递给下层的链路层时，都要通过ARP协议获得目的MAC地址。在以太网转FC链路中，ARP模块只接收由以太网过滤模块第1层筛选出的ARP数据包。

如图5所示，根据帧格式中的操作码可以判断ARP的类型：ARP请求(值为1)、ARP应答(值为2)、RARP请求(值为3)或RARP应答(值为4)[6]。若接收到ARP请求，先查看请求IP是否为本机IP：若是，则构建一个ARP的应答包，包的源IP地址和SMAC地址即为本机地址，目的IP地址和DMAC地址为ARP请求方对应的地址；若不是，丢弃该ARP包并且不做其他任何处理。如果接收到的是ARP应答，则将发送方的IP地址和MAC地址写入cache表，供FC转以太网模块进行查询，具体写入流程后面单独介绍。

图5 IPv4地址映射到MAC地址的ARP帧格式

3.1.3 以太网转FC桥接模块

以太网转FC模块是网络协议转换中的关键设计之一。由前面分析可知，ICMP、TCP转FC和UDP转FC的过程是不一样的，首先获取以太网数据IP地址映射所得的ID信息，再根据不同FIFO中读取的数据进行转换。如果是ICMP/TCP FIFO，则只须将ID信息填入FC首部对应位置、类型TYPE修改为0×05，其余首部信息都为定值，再将IPv4 数据填充为FC Payload，最后补充发送FC的帧结束符。如果检测到UDP FIFO为非空，首先提取UDP数据的MAC首部、IP首部和UDP首部，映射得到FC首部的对应信息，例如UDP首部中的服务类型和端口号，分别映射到FC首部中的CS_CTL和OX_ID、RX_ID，再结合前级所给的ID地址重组出FC首部，然后将不包含3层首部信息的UDP Payload填充到FC Payload，最后同样补充发送FC的帧结束符。

由于FC数据的位宽是4字节，当ICMP、TCP的IPv4数据长度或者UDP的Payload长度不是4字节整数倍时，那么FC首部信息中F_CTL的0到1位要进行相应的修改：00表示Payload无填充，01表示填充1字节，10表示填充2字节，11表示填充3字节。具体流程如图6所示，这里选用公平轮询的仲裁方式来判断两个FIFO是否非空。

图6 ICMP、TCP和UDP到FC的协议转换流程

3.1.4 FC合并模块

经过以太网转FC模块之后，ICMP、TCP数据转换成了IPv4 over Fibre Channel的FC数据；UDP数据转换成了FC-AE-ASM数据，合并模块需要对这两路数据的发送做一个仲裁。由于没有特定的优先级要求，本设计选用公平轮询的仲裁方式。

3.2 FC转以太网设计

3.2.1 FC过滤模块

FC转以太网链路的FC过滤模块和以太网过滤模块相似，但不分层。过滤条件如下所述：

(1) FC帧的总长度小于等于1 524字节；

(2) SOF为SOFi3；

(3) EOF为EOFt(条件(2)、(3)表明1个FC序列只有1个FC帧)；

(4) ID通过查找ID-IP桥接表能够成功匹配到对应的IP信息。

若以上4个条件都满足，则将FC数据包压入FC FIFO；反之则丢弃。

3.2.2 ARP模块

FC转以太网在进行协议转换时，每个FC数据包都会向ARP模块发送1个ARP请求信号，查询cache表中的DMAC地址，如图4所示。接收到该请求后，ARP模块先查看cache表中是否存在请求IP的有效表项：若存在，则返回对应的DMAC值；反之，则将匹配失败信号置高，并且构建1个ARP请求包，包的源IP地址和SMAC地址为本机地址，目的IP地址即为所查IP地址，DMAC地址为广播0×FFFFFFFFFFFF，该包交由合并模块进行发送(后面将单独介绍)。在1 ms内如果有ARP应答，则将应答方的IP和DMAC地址写入cache表，并返回给FC转以太网模块；若超时，则丢弃该FC包。

如果在整个网络中都不存在上述IP，那么每个需要转换成以太网格式的FC包都会使ARP模块产生1个ARP请求，会导致数据链路堵塞。为此，在ARP模块中加入记忆计时功能：当某个IP第1次发起查询时，如果没有对应的MAC地址，则发送ARP请求，然后存下该IP并开始计时1 s，在1 s内若该IP再次发起查询，则直接置高匹配失败信号且不发送ARP请求，桥接模块也会直接丢弃对应的FC包，即对于同1个IP来说，在1 s内只发送1个ARP请求，防止数据链路因此而产生拥堵。

3.2.3 FC转以太网桥接模块

在FC转成以太网数据的过程中，SMAC通过对应寄存器来获取，默认48位都是0，也可以通过串口手动输入进行配置。DMAC则通过查询ARP模块获得，若查询失败则丢弃该FC包；反之将查询所得DMAC填入首部，再根据类型TYPE值判断将其转换为ICMP、TCP数据还是UDP数据。

如果TYPE类型是0×05，须判断协议号，若为0×01，只需将FC Payload直接填充为以太网的IPv4数据，再将映射所得IP地址和重计算的IP首部检验和填入对应位置；若协议号为0×06，还须重新计算TCP检验和。如果TYPE类型是0×49，则根据FC首部信息和查表所得IP地址重组以太网数据包各层首部，再把FC Payload填充为UDP Payload，直至EOF到来。对于ICMP和TCP数据来说，MAC首部为14字节，以太网数据AXI4-Stream接口的位宽为8字节，所以在8字节MAC地址填充完成后，图3中序列2的前6字节将会和IPv4数据一起发送。而对于UDP数据来说，MAC首部加上IP首部再加上UDP首部共有42字节，重计算后的2字节UDP校验和将会与Payload一起发送，转换流程如图7所示。

图7 FC到ICMP、TCP和UDP的协议转换流程

3.2.4 以太网合并模块

经过FC转以太网模块之后，转换后的ICMP、TCP和UDP数据加上ARP模块产生的ARP数据，合并模块需要对这4路以太网数据的发送做一个仲裁。由于4路数据没有特定的优先级要求，这里选用和FC合并模块相同的公平轮询仲裁方式。

3.3 查表设计

3.3.1 桥接表写入及查询方式

整个系统要对不止一条数据链路进行转换，所以桥接表中需要存储大量的地址信息。在高速网络下，为了实现实时存储和查找，桥接表模块使用了哈希函数。把函数运算所得数值储存到哈希表中的对应位置，根据数据包首部的ID或IP信息可查询匹配信息的存储位置，极大地提高了查表效率[14]。具体写入和查询流程如图8所示。

图8 桥接表模块写入及查询流程

3.3.2 cache表写入及查询方式

ARP模块中的cache表通过读取ARP包的对应数据进行写入，cache表的写入和查询与桥接表相似。本设计选择CRC32算法作为哈希函数[15]，方案如下：限制查询次数为两次，若在写入操作过程中查询了两次后依旧未找到匹配的表项，则写入该新表项；若在查询过程中进行了两次操作后依旧未找到，则输出匹配失败标志。CRC32算法将32位的IP地址映射到32位的Hash[31：0]， 将Hash[15：0]作为第1次查询的地址，将Hash[31：16]+Hash[15：0]的值作为第2次查询的地址。除此之外，还要考虑MAC地址更新问题，因为它在一段时间内可能会发生变化。因此cache中的每个表项都需要一个更新时间，一旦超出这个时间限制，该表项将被置为无效。对于MAC地址的更新处理如下：每个表项在写入时都会设置一个属于自身的TTL初始值，如果一个表项在一个计时单位内非空且有效，其TTL自动减1，当减到0时，则将此表项的valid置为0，表明该表项已无效，可以被新的写入数据覆盖。

4 系统测试

4.1 FC与ICMP、TCP协议转换测试

4.1.1 ICMP、TCP系统测试平台搭建

为了测试ICMP/TCP-FC桥接系统的性能，设计了如图9所示的测试平台，图中虚线代表千兆以太网数据链路，粗实线代表4G FC数据链路，点虚线代表测试板中的协议转换链路。

图9 ICMP/TCP-FC系统测试平台

4.1.2 主机Ping从机测试

首先在RS232串口中配置测试板1的桥接表信息和SMAC地址信息，如表1和表2所示，其中IP-ID代表将IP地址映射为ID地址，ID-IP代表将ID地址映射为IP地址，且IP地址的输入格式为十六进制，即0×c0换算为十进制等于192，以此类推。然后再配置测试板2的桥接表和SMAC地址，因为与测试板1数据转换的方向相反，所以表1就是其ID-IP桥接表，表2就是其IP-ID桥接表。

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

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

在主机上Ping从机，并在从机上使用软件wireshark抓取以太网数据，图10的前两个包为ARP请求和回复包，之后都是ICMP请求和回复包。

图10 主机Ping从机的以太网数据

当ICMP数据在FC网络上传输时，通过分析仪抓取FC数据，其速率示意如图11所示，两路数据对应的分别是ICMP请求和ICMP回复，已知ICMP数据包每秒发送1个，因此速率示意图为锯齿状。

图11 ICMP转成FC的速率示意图

4.1.3 FC与TCP协议转换测试

FTP是广泛使用的基于TCP的文件传输协议，具有可靠、高效、通用等特点，因此本文采用FTP来测试FC与TCP之间的协议转换。使用软件wftpd32在从机上建立FTP账号，指向目录为E：TCP_TEST，该文件夹下有一个测试文件test_file1.iso，大小为3.18 GB。在主机端使用软件FlashFXP下载该文件，从机到主机的FTP文件传输过程如图12所示。

图12 FTP文件传输过程

当TCP数据在FC网络上传输时，通过分析仪抓取对应的FC数据。图13中的上下两个速率分别代表主机发往从机的ACK数据所转换成的FC数据速率以及从机发往主机的FTP数据所转换成的FC数据速率。

图13 TCP转成FC的速率示意图

4.2 FC与UDP协议转换测试

4.2.1 UDP系统测试平台搭建

为了测试UDP-FC桥接系统中新增的ARP模块的功能和转换性能，设计了如图14所示的测试平台。

图14 UDP-FC系统测试平台

4.2.2 UDP转FC链路测试

首先通过串口上传IP-ID和ID-IP桥接表(为了与前文测试区分，修改了桥接表中的IP和ID地址)，然后在电脑端配置软件Fbench发送长度一定的UDP数据，图15中的数据为UDP转换后的FC数据。

图15 UDP转换成的FC数据

4.2.3 FC转UDP链路测试

操作测试仪的测试口发送包长随机的4G FC数据，并将源ID和目的ID分别设置成与桥接表相对应的地址，类型TYPE设置为0×49，通过分析口抓取的FC数据如图16所示。

图16 转成UDP前的FC数据

桥接系统接收到FC数据后，在转换之前需要先发送ARP包来获取DMAC，待首部信息获取完整后再发送UDP数据，转换成的以太网数据在电脑端通过软件wireshark进行抓取。图17中的前两个数据分别为ARP请求和ARP应答，之后的UDP数据由图16中的FC数据转换而来，两者是一一对应的。

图17 FC转成的UDP数据

4.2.4 FC与UDP转换速率测试

如图18所示，FC Port(1.2.3)是测试仪发给分析仪的FC数据速率，即FC转UDP链路的转换速率； FC Port(1.2.4)是测试板发给分析仪的FC数据速率，即UDP转FC链路的转换速率。两个协议相互转换的速率都能稳定在114 MB/s以上，达到了千兆以太网传输带宽的要求，符合设计预期。

图18 UDP协议转换速率

5 结束语

本文提出了一种基于FPGA的FC和千兆以太网桥接系统。首先设置特定的条件，筛选出需要转换的FC数据包和ICMP、TCP以及UDP数据包；然后运用哈希查表映射出对应的寻址信息，其余首部信息相互填充；最后对数据包的格式进行重组并发送。实验结果表明，FC协议和ICMP、TCP、UDP协议能够实现相互之间的正确转换，其转换速率满足千兆以太网传输带宽要求，没有出现丢包或者错包的情况。下一步工作是对UDP报文切分/重组的支持以及对万兆网/16G FC的支持。