CN111131159A - 一种报文解析器及其设计方法 - Google Patents
一种报文解析器及其设计方法 Download PDFInfo
- Publication number
- CN111131159A CN111131159A CN201911155986.9A CN201911155986A CN111131159A CN 111131159 A CN111131159 A CN 111131159A CN 201911155986 A CN201911155986 A CN 201911155986A CN 111131159 A CN111131159 A CN 111131159A
- Authority
- CN
- China
- Prior art keywords
- message
- protocol
- stage
- message header
- transmission channel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明公开了一种报文解析器及其设计方法,报文解析器基于FPGA实现且包括多级流水线,每一级流水线包括至少一个协议处理模块,并且协议处理模块具有相同的硬件结构且可通过改变参数配置而处理不同的协议,相邻流水线之间的通信通道包括报文头切片传输通道、协议类型向量传输通道、报文头向量传输通道和状态传输通道。本发明的报文解析器可实现对任意协议首部组成的报文头解析并做到时序最优化和资源占有最小化,流水线模块化的结构便于灵活配置和调度,本发明调度方法可调度报文解析器的协议处理模块流水级以避免冲突和停顿,使得报文解析器解析过程完全流水化。
Description
技术领域
本发明涉及网络报文解析技术,具体涉及一种报文解析器及其设计方法。
背景技术
现有网络处理器均需要对进入的报文进行报文头解析,然后才能进行下一步的操作。集成电路芯片(ASIC)往往使用资源换时间的做法,通过复制不同的协议首部处理模块至不同的流水级,从而保证报文解析操作的流水化来提供高性能的报文解析。网络处理器(NP)采用多核或者单核通用处理器,通过执行指令的方式解析报文。但是对于资源有限和运行速度受限的FPGA平台,上述方法均不适用,其所实现的报文解析器必须具有资源占用少,运行速度快,并行化处理速度高等特点,才能满足高性能报文解析的实际应用要求。
发明内容
本发明要解决的技术问题:针对现有技术的上述问题,提供一种基于FPGA平台的报文解析器及其设计方法,本发明的报文解析器可实现对任意协议首部组成的报文头解析,并做到资源占用少,运行速度快,而且采用流水线模块化的结构便于灵活配置和调度,以满足快速设计针对不同报文解析的需求。本发明的报文解析器设计方法是一种对协议处理模块的硬件优化方法,以此设计出一个能够完全流水化处理报文解析的报文解析器,该解析器对报文的处理没有冲突和停顿,并且每个时钟周期处理一个数据报文。
为了解决上述技术问题,本发明采用的技术方案为:
一种报文解析器,基于FPGA实现且包括多级流水线,每一级流水线包括至少一个协议处理模块,第一级流水线的输入端包括报文头切片输入端口,最末级流水线的输出端包括报文头向量输出端口、状态输出端口和协议类型端口,相邻流水线之间的通信通道包括报文头切片传输通道、协议类型向量传输通道、报文头向量传输通道和状态传输通道,所述多级流水线中的每一级流水线针对输入的报文头切片按照对应的协议类型进行解析后传输至下级流水线直至最末级流水线的输出端输出解析后的报文头向量和状态信号。
所述相邻流水线之间的通信通道还包括错误信号传输通道和握手信号传输通道,所述错误信号传输通道用于传输流水线发生的错误信息,所述握手信号传输通道用于传输各流水级之间握手信号,且当前流水级标识当前输出端口数据有效,则后一级流水级即接收当前输入的数据。
所述协议处理模块包括:
协议类型识别器,用于在当输入的数据有效时,比较检查输入的协议类型向量的指定比特位以确认当前协议处理模块所配置的协议类型是否与前一级协议首部解析出来的协议匹配,如果匹配则通过控制信号EN控制后续的报文头切片移位器、字段提取器、协议类型生成器三个功能模块对输入的数据进行选择处理还是仅传递输入的数据;
报文头切片移位器,用于针对报文头切片传输通道输入的报文头切片,计算或标识移位量并执行移位操作,将下一个待处理协议首部移动到报文头切片的头部,然后在使能信号控制下选择移位操作后的数据或者移位操作前的原始数据通过寄存器组存储作为待输出的报文头切片;
字段提取器,用于将报文头切片中的指定字段提取并更新至报文头向量中;
协议类型生成器,用于编码下一级待处理的网络协议类型,并在协议类型向量中标记最终输出至下一级流水线。
所述协议类型识别器包括一个比较器实现和一个位指示器,所述位指示器为指向类型向量中某一位的常数项,所述类型向量中被位指示器指向的位、常数“1”一起作为比较器的输入,所述比较器的输出端输出的控制信号EN则分别与报文头切片移位器、字段提取器以及协议类型生成器的控制信号EN的输出端相连。
所述报文头切片移位器包括:
计算单元,用于针对报文头切片计算或者标识移位量;
移位单元,用于针对报文头切片根据移位量执行移位操作;
第一选择器,用于在控制信号EN控制下选择输入移位后的数据还是输入的原始数据;
第一寄存器组,用于存储待输出的报文头切片;
所述计算单元的输入端和本级流水线的报文头切片传输通道的输入端口相连,所述计算单元的输出端和移位单元的输入端相连,所述第一选择器的一个输入端和本级流水线的报文头切片传输通道的输入端口相连、另一路输入端和移位单元的输出端相连,所述第一选择器的输出端和第一寄存器组的输入端相连,所述第一寄存器组的输出端和本级流水线的报文头切片传输通道的输出端口相连。
所述字段提取器包括:
字段指示符,用于存储四组预定义的地址数组,这些地址包括协议首部中各指定字段的起始偏移地址和结束偏移地址,以及在报文头向量的起始偏移地址和结束偏移地址,每组地址数组的元素个数根据提取字段的个数确定;
提取执行器,用于实际执行从报文头切片中复制字段至报文头向量指定位置的功能;
第二选择器,用于在控制信号EN控制下选择提取执行器输出的报文头向量或者输入的原始报文头向量;
第二寄存器组,用于存储待输出的报文头向量;
所述提取执行器的输入端分别与本级流水线的报文头切片传输通道的输入端口、报文头向量传输通道的输入端口相连,所述第二选择器的一个输入端和本级流水线的报文头向量传输通道的输入端口相连、另一路输入端和提取执行器的输出端相连,所述第二选择器的输出端和第二寄存器组的输入端相连,所述第二寄存器组的输出端和本级流水线的报文头向量传输通道的输出端口相连。
所述协议类型生成器包括:
类型指示符,用于指示下一级流水线所需处理的协议类型的匹配字段和方式;
类型生成器,用于生成下一级流水线所需处理的网络协议类型,并在协议类型向量中标记;
第三选择器,用于在控制信号EN控制下选择生成的协议类型或者输入的原始协议类型;
第三寄存器组,用于存储待输出的协议类型;
所述类型指示符的输入端分别与本级流水线的报文头切片传输通道的输入端口、协议类型向量传输通道的输入端口相连,所述第三选择器的一个输入端和本级流水线的协议类型向量传输通道的输入端口相连、另一路输入端和类型生成器的输出端相连,所述第三选择器的输出端和第三寄存器组的输入端相连,所述第三寄存器组的输出端和本级流水线的协议类型向量传输通道的输出端口相连。
所述报文头切片传输通道的端口位宽等于本报文解析器待支持的所有报文类型中最长报文头的长度。
所述报文头向量传输通道的端口位宽等于流水线中各级提取字段总和最长的协议处理模块所提取字段长度之和。
本发明还提供一种前述报文解析器的设计方法,实施步骤包括:
1)确定报文解析器所需支持的网络协议,将报文解析器所需支持所有网络协议生成有向无环图作为协议解析图;
2)在协议解析图中找出一条最长的路径作为主干路径,将主干路径的节点个数作为报文解析器的流水级数,从而确定报文解析器的流水级数;
3)在所有未选入主干中的节点遍历选取一个节点作为操作对象;针对每一个操作对象,找出主干路径中的所有前驱节点,从这些前驱节点中选取一个处在主干路径最底层的并保留该前驱节点与当前操作对象的依赖关系,并将处于兄弟关系的两个节点合并为一个虚拟节点并将这两个节点的与其前驱和后继节点的关系调整为与这个虚拟节点的关系,从而使得协议解析图中的每一个节点都归属到报文解析器的每一级流水中获得优化后的协议解析图,从而确定报文解析器的每一级流水线中所包含的协议处理模块;
4)根据报文解析器所支持的最长报文头计算报文头切片的长度,然后根据每个协议需要提取的字段以及所在流水级的位置,计算总的报文头向量宽度,并分配地址给各个提取的字段;
5)根据优化后的协议解析图配置各级流水线中所包含的协议处理模块的参数,使得各个流水线中所包含的协议处理模块用于处理对应的网络协议;
6)将各级流水线中所包含的协议处理模块按照优化后的协议解析图中的顺序进行拼接,从而得到完成设计的报文解析器。
和现有技术相比,本发明的报文解析器具有下述优点;
1、本发明的报文解析器基于FPGA实现,本发明的报文解析器可实现对任意协议首部组成的报文头解析并做到时序最优化,而且采用流水线模块化的结构便于灵活调度和设计,能够在最小资源占有的情况下(FPGA平台有限的资源),满足解析的流水化,提高运行频率,不产生冲突和停顿的,使得报文解析器每个周期处理一个数据包。
2、本发明的报文解析器采用模块化的结构,只需要一个公共的协议处理模块,通过配置不同参数即可实现解析不同协议首部的功能,而且这个公共处理模块的硬件结构能够做到资源占用少,运行速度快,性能高。
和现有技术相比,本发明的报文解析器的设计方法具有下述优点:本发明报文解析器的设计方法对前述报文解析器的协议处理模块的进行优化方法,以此实现设计出一个能够完全流水化处理报文解析的报文解析器,可以调度报文解析器的协议处理模块流水级以避免冲突和停顿,使得报文解析器解析过程完全流水化,并且每个时钟周期处理一个数据包,使得本发明的报文解析器采用模块化的结构,只需要一个公共的硬件处理模块,通过配置不同参数即可实现不同的功能,进一步简化了整个解析器的硬件结构。
附图说明
图1为本发明实施例的协议转换功能解析图示例。
图2为本发明实施例的报文解析器的结构示意图。
图3为本发明实施例中协议处理模块的微体系结构。
图4为本发明实施例中协议类型识别器的结构示意图。
图5为本发明实施例中报文头切片移位器的结构示意图。
图6为本发明实施例中字段提取器的结构示意图。
图7为本发明实施例中协议类型生成器的结构示意图。
图8为本发明实施例中报文头组成结构示意图。
图9为本发明实施例中五元组在报文头向量中的排列结果示意图。
图10为本发明实施例中类型向量的排列示意图。
图11为本发明实施例调度方法的基本流程示意图。
图12为本发明实施例中流水线的调度过程示意图。
具体实施方式
下文将以执行图1所示协议转换功能为例的,对本发明的报文解析器及其调度方法进行进一步的详细说明。
如图2所示,本实施例的报文解析器基于FPGA实现且包括多级流水线,每一级流水线包括至少一个协议处理模块,第一级流水线的输入端包括报文头切片(Header Slice)输入端口,最末级流水线的输出端包括报文头向量输出端(Header Vector’)和状态(Status)输出端和协议类型向量输出端,相邻流水线之间的通信通道包括报文头切片(HeaderSlice’)传输通道、协议类型向量传输通道、报文头向量(Header Vector)传输通道和状态传输通道,多级流水线中的每一级流水线针对输入的报文头切片按照对应的协议类型进行解码后传输至下级流水线直至最末级流水线的输出端输出解码后的报文头向量和状态信号。
本实施例中报文头解析器由多级流水线构成,其级数由解析器所计划支持的网络协议决定,结合图1可知,本实施例中包括5级流水线,依次包括Ethernet→VLAN→VLAN→IPv6+IPv4→TCP+UDP。流水线中的每一级具有相似的硬件结构和功能:从当前输入的网络协议首部中提取指定的字段并保存到头向量中、解析更高一级的协议类型,记录处理状态信息和可能出现的解析错误,以及将输入的报文头进行移位操作。参见图2,各个箭头表示各种数据流,比如报文头切片,下一个协议代码等等。途中虚线框代表各级流水线,而虚线框内被标记为A、B、C和D的实线框代表协议处理模块。协议处理模块被定义专门处理某种协议首部的功能模块,比如A可以配置为针对“Ethernet Type”的功能模块,而B可以配置为针对“IPv4”或者“IPv6”的功能模块。这些模块将根据所支持的协议集合,分配至流水线的不同流水级中。每一级流水线可包含一个协议处理模块,比如第一级和第二级流水线。流水级也可以包含更多的协议处理模块,比如图1中的最后一级即存在C和D两个协议处理模块。在这一级流水线中,所有的输入数据被同时传输至C和D两个协议处理模块中,这两个模块会根据输入的数据做出相应的处理,并输出处理结果,但两个结果将只有一个被选择输出。当输入的协议首部与协议处理模块不匹配而不需要处理时,协议处理模块将所有输入保存一个周期之后,在下一个时钟沿到来时将其输出。在每级流水线中,除了协议处理模块之外,流水线中还存在其他的辅助电路,比如最后一级流水线,需要产生对于C和D进行选择输出的控制信号EN。此外,错误和处理状态将最终输出至解析器的下一级流水线。
本实施例中,相邻流水线之间的通信通道还包括错误信号传输通道和握手信号传输通道,错误信号传输通道用于传输流水线发生的错误信息,握手信号传输通道用于传输各流水级之间握手信号,且当前流水级标识当前输出端口数据有效,则后一级流水级即接收当前输入的数据。诸多的向量和数据通过各个端口逐级在解析器中传输,为了保持这些数据同步传输,各流水级之间以及解析器与其他模块均需要握手信号来确认。本实施例的报文头解析器采用标准二线握手信号,此外也可以根据需要采用其他类型的握手信号,同样可以实现各流水级之间的状态和数据的传递。
本实施例中,所有流水线中的协议处理模块具有相同的硬件结构且可通过改变参数配置而处理不同的协议。如图3所示,协议处理模块包括:
协议类型识别器,用于在当输入的数据有效时,比较检查输入的协议类型向量的指定位以确认当前协议处理模块所配置的协议类型是否与前一级协议首部解析出来的协议匹配,如果匹配则通过控制信号EN控制后续的报文头切片移位器、字段提取器、协议类型生成器三个功能模块对输入的数据进行选择处理还是仅传递输入的数据;
报文头切片移位器,用于针对报文头切片传输通道输入的报文头切片,计算或标识移位量并执行移位操作,将下一个待处理协议首部移动到报文头切片的头部,然后在使能信号控制下选择移位操作后的数据或者移位操作前的原始数据通过寄存器组存储作为待输出的报文头切片;
字段提取器,用于将报文头切片中的指定字段提取并更新至报文头向量中;
协议类型生成器,用于编码下一级待处理的网络协议类型,并在协议类型向量中标记最终输出至下一级流水线。
协议处理模块内部设计一级寄存器用于保存所有模块内部的逻辑计算结果,即处理逻辑在一个周期内处理完成,然后在下一个周期时输出结果。协议处理模块的主要输入端口包括“报文头切片”,“类型向量”,“错误向量”,“报文头向量”,以及“握手信号”,而输出端口同样为这五个类别的端口,只是对应端口输出的数据存在被该模块处理更新。
当输入的数据有效时,“类型向量”首先被“协议类型识别器”进行比较检查,以此确认当前协议处理模块所配置的协议类型,是否与前一级协议首部解析出来的协议匹配,如果匹配即控制后续的三个功能模块对输入的数据进行处理,否则仅保存当前输入的数据。以图1所示的报文解析器为例,假设当前协议模块为处于第四级的“IPv4”协议处理模块,那么其前一级协议首部解析出的下一个协议类型可能为“IPv4”或者“IPv6”,并会将其记录在“类型向量”中。因此,当输入数据有效,“协议类型识别器”即检查“IPv4”的标志位是否为“1”,如果是,即控制“报文头切片移位器”对输入的“报文头切片”做移位操作,“字段提取器”从“IPv4”协议首部中提取IP地址等指定字段并更新至“报文头向量”中,以及控制“协议类型生成器”从“IPv4”协议首部中解析出下一个协议的内容,并更新至“类型向量”中,以备下一级流水线使用。
如图4所示,协议类型识别器包括一个比较器实现和一个位指示器,位指示器为指向类型向量中某一位的常数项,类型向量中被位指示器指向的位、常数“1”一起作为比较器的输入,比较器的输出端输出的控制信号EN则分别与报文头切片移位器、字段提取器以及协议类型生成器的控制信号EN的输出端相连。类型向量是一个寄存器向量,其存储当前报文头中已被解析出的协议,并被逐级更新传输。协议类型识别器即检查其对应的标志位是否被流水线中的前一级标记为“1”,这表示当前输入的有效数据需要在该协议处理模块中得到处理。协议类型识别器的功能由一个比较器实现。位指示为一个常数,表示直接提取类型向量中的某一位,将其与常数“1”进行比较,并将比较结果作为控制信号EN控制其他模块。
由于报文头由不同长度的多种协议首部组合而成,在解析前一个协议首部之前,很难知道每个协议首部的偏移量。除了最外层协议外,所有内层协议首部在不同报文头中的偏移地址可能均不相同,即内层协议首部在报文头内部的偏移具有随机性。实际的电路设计中,在一个比特向量中随机定位任意子向量的电路将变得非常复杂,其不仅消耗大量的资源,而且还降低时钟速率,从而降低处理性能。对于本实施例中的解析器结构,除第一级流水线外,其他流水线中的协议处理模块均将面临此问题。报文头切片移位器能够将已经处理完成的协议首部通过位移的方式从报文头切片中移出,从而实现其后继协议被移动到报文头切片的起始位置,实现地址偏移量为0,从而降低电路的复杂性,减少大量的资源开销以及提高电路运行的频率。
如图5所示,报文头切片移位器包括:
计算单元,用于针对报文头切片计算或者标识移位量;
移位单元,用于针对报文头切片根据移位量执行移位操作;
第一选择器,用于在控制信号EN控制下选择输入移位后的数据还是输入的原始数据;
第一寄存器组,用于存储待输出的报文头切片;
计算单元的输入端和本级流水线的报文头切片传输通道的输入端口相连,计算单元的输出端和移位单元的输入端相连,第一选择器的一个输入端和本级流水线的报文头切片传输通道的输入端口相连、另一路输入端和移位单元的输出端相连,第一选择器的输出端和第一寄存器组的输入端相连,第一寄存器组的输出端和本级流水线的报文头切片传输通道的输出端口相连。
对于具有固定长度的协议首部,比如“IPv6”和“Ethernet”,计算单元可直接指定移位量;而对于具有可变长度的协议首部,比如带选项的“IPv4”和“TCP”,其协议首部会根据当前报文所携带选项大小而有所不同,对于这种协议首部,计算单元可移位量需要通过分析获取。对于可编程的协议首部,需要使用到动态移位器,即所需移位数动态确定。但是实现这种动态移位器的电路同样非常复杂,其将大量资源以及产生长的关键路径,从而运行频率。通过研究协议报文头格式,本实施例发现可变报文头的长度以32比特为单位增长,并且在一定的范围内增加。例如,IPv4报文头中的选项部分,增加的长度在32比特的0-10倍数范围内。通过实现这类限定范围的动态移位器,能够显著减少资源的占用量,并且运行在较高的频率。
作为报文解析器的核心功能之一,字段提取器将报文头切片中的指定字段提取并更新至报文头向量中,而协议处理模块执行将对应协议首部的指定字段复制到报文头向量中的指定区域。如图6所示,字段提取器包括:
字段指示符(Field Indicator),用于存储四组预定义的地址数组,这些地址包括协议首部中各指定字段的起始偏移地址和结束偏移地址,以及在报文头向量的起始偏移地址和结束偏移地址,每组地址数组的元素个数根据提取字段的个数确定。例如对应协议中需要提取1个字段就是1,如果是两个就是2,如果没有就是0;
提取执行器(Extrator),用于实际执行从报文头切片中复制字段至报文头向量指定位置的功能;
第二选择器,用于在控制信号EN控制下选择提取执行器输出的报文头向量或者输入的原始报文头向量;
第二寄存器组,用于存储待输出的报文头向量;
提取执行器的输入端分别与本级流水线的报文头切片传输通道的输入端口、报文头向量传输通道的输入端口相连,第二选择器的一个输入端和本级流水线的报文头向量传输通道的输入端口相连、另一路输入端和提取执行器的输出端相连,第二选择器的输出端和第二寄存器组的输入端相连,第二寄存器组的输出端和本级流水线的报文头向量传输通道的输出端口相连。
字段指示符存储四组预定义的地址,这些地址包括协议首部中指定字段的起始偏移地址和结束偏移地址,以及在报文头向量的起始偏移地址和结束偏移地址。这些预定义的地址,在编译器解析程序时即可获知,而且报文头向量的偏移量只是协议首部内的相对位置,而不需要考虑报文头协议的构成类型。提取执行器实际执行从报文头切片中复制字段至报文头向量指定位置的功能。由于报文切片和报文向量中操作对象均在VHDL代码综合前即确定,因此实际的电路相对较简单。后续的数据选择器和寄存器组功能与其他模块一致。
如图7所示,协议类型生成器包括:
类型指示符,用于指示下一级流水线所需处理报文类型的匹配字段以及匹配方式;
类型生成器,用于生成下一级流水线所需处理的网络协议类型,并在协议类型向量中标记;
第三选择器,用于在控制信号EN控制下选择生成的协议类型或者输入的原始协议类型;
第三寄存器组,用于存储待输出的协议类型;
类型指示符的输入端分别与本级流水线的报文头切片传输通道的输入端口、协议类型向量传输通道的输入端口相连,第三选择器的一个输入端和本级流水线的协议类型向量传输通道的输入端口相连、另一路输入端和类型生成器的输出端相连,第三选择器的输出端和第三寄存器组的输入端相连,第三寄存器组的输出端和本级流水线的协议类型向量传输通道的输出端口相连。
协议类型的代码或标志往往存储在其前驱协议首部的某个特定字段中,通过提取这个字段便可知其后继协议的类型。但也存在部分协议首部并不存储其后继协议类型,比如MPLS协议,此类协议需要匹配其后继节点的某些字段,并在类型向量中标记。参见图7,类型指示符存储协议类型代码或者标志位在协议首部的起始地址和结束地址,或者需要匹配字段的起始地址和匹配方式,这些地址或者匹配方式在解析器设计时针对协议分析获取。继续以“MPLS”协议首部为例,在其标志位“S”位“1”时,需要匹配其后继协议的头4个比特,即相对于其起始地址为“35downto 32”,如果其为“0100”即后继协议为“IPv4”协议,如果为“0110”即后继协议为“IPv6”,否则为无法识别的协议首部。类型向量由类型生成器根据操作结果进行更新。后续的第三选择器和第三寄存器组和其他模块的功能一致。
对于报文头解析器而言,除了需要解析报文头内各协议外,还需要额外执行一些功能函数。比如计算“IPv4”和“TCP”协议首部内的校验值,这些函数可根据需要选择加入到协议处理模块中,其结果作为错误向量的一个分量。
参见图2和图3,相邻流水线之间的通信通道包括报文头切片(Header Slice’)传输通道、协议类型(Protocol Type)传输通道、报文头向量(Header Vector)传输通道、错误信号(Errors)传输通道和握手信号(Handshake)传输通道,对应的每一级中间流水线都具有对应的输入和输出端口,第一级和最末级则具有输出或者输入端口。将网络数据报文输入报文头解析器,然后输出从报文头解析并提取的各字段内容及状态和错误,这些数据通过不同的端口与报文头解析器的前端和后端连接,接收前端发送的数据并将处理结果输出至后续的处理单元,除此之外,报文解析器与前后端通过握手信号实现数据的同步。报文头解析器的各个端口位宽根据支持的协议不同而有所区别,具体的方法由以下各小结中进行描述。
本实施例中,多级流水线中的协议处理模块包括但不限于处理Ethernet、VLAN、VLAN、IPv6、IPv4、TCP、UDP等网络协议的协议处理模块,报文头切片传输通道的端口位宽等于本报文解析器待支持的所有网络协议类型中最长报文头的长度。如图8所示,报文头切片传输通道的端口位宽为1072个比特。需要说明的是,这个位宽不是固定数,而是等于所支持报文中具有最长报文头的那个长度。比如我们增加支持一个协议,其协议首部为1072,那么这个端口位宽就可能大于1072。
报文通过解析器的输入端口进入,为了实现解析器的处理效率达到最好性能,其需要一个时钟周期处理一个报文头。那么必须每个周期输入一个报文,但显然解析器的输入端口不可能满足动辄成百上千个字节的位宽,如果缩小输入端口的位宽,那么报文将受到带宽限制而被拆分成若干个片段分时输入。而且报文中的载荷部分(Payload)从解析器传输,将会消耗大量的周期用于传输载荷,造成解析器的性能损失。因此,将一个报文拆分为报文头和载荷两部分,并且只将报文头输入解析器是解决方案之一。首先,本实施例需要确定报文头在输入报文中的长度。报文头由各种长度不一的协议首部组成,而且协议类型也各不相同,在解析完所有协议首部之前无法确定报文头的长度。因此,本实施例提出一种从报文中截取报文头的方案,确保任一报文的头比特位能一次全部输入解析器,而这个截取的报头称之为报头切片。为了演示本方案,本实施例假设报文头解析器支持“EthernetType”,“带选项的IPv4”,“IPv6”,“带选项的TCP”,“UDP”五种协议。这些协议之间至少存在4种组合方式构成一个报文头,图7描述了报文头的组合类型及长度。图8描述了各种组合下可能的最大长度。其中轴的上方表示两种可能的组合:“Ethernet类型”+“带选项的IPv4”+“UDP”或者“Ethernet类型”+“带选项的IPv4”+“带选项的TCP”。前者具有最长的后者具有1072比特,但是实际使用过程中,由于选项的不确定性,报文头的长度会更小一些。轴的下方表示另外两种可能的组合:“Ethernet类型”+“IPv6”+“UDP”或者“Ethernet类型”+“IPv6”+“带选项的TCP”,其中前者长度不会变化,固定为496比特,而后者最长为912比特,但根据TCP选项长度的变化而变的更小。综上,所有可能支持的报文头的长度范围在336比特至1072比特之间。因此,如果本实施例选取最长的报文头作为报文截取的长度,那么所有可能的协议首部组合的长度均在这个范围内。每一个进入网络处理器的报文,首先被从头部开始,按照1072个比特的位宽切成报文切片,然后输入报文头解析器中,而无需考虑当前报文的实际长度。对于整个报文长度小于1072个比特的报文,比如只有512比特的最小报文,其空缺部分采用全零进行填充。通过上述的计算方法,首先找到所支持协议组成的最长数据包并计算其长度,然后将这个最长的长度作为报文头的输入端口,从而保证任一支持的报文,其报文头均能在一个时钟周期内进入解析器,然后每一个时钟输出一个处理完成的报文头。
本实施例中,多级流水线中的协议处理模块包括但不限于处理Ethernet、VLAN、VLAN、IPv6、IPv4、TCP、UDP等网络协议的协议处理模块,报文头向量传输通道的端口位宽等于流水线中各级提取字段总和最长的协议处理模块所提取字段长度之和。如图9所示,报文头向量传输通道的端口位宽为296个比特。这个位宽同样不是常数,而是根据在各级流水线中提取字段长度的一个和。比如第一级有两个协议处理模块,其中一个提取54比特,另外一个提取60比特,第二级流水线只有一个协议处理模块,提取的所有字段加起来40比特,那么这个向量为60+40。即每一级里面选取提取字段最长的那个协议处理模块,并计算其提取字段的长度和作为该级的向量位宽,最后报文头向量的位宽为所有流水级位宽之和。
报文头向量为一个具有特定宽度的寄存器组,其在流水线中逐级传递,而每一级流水线将其从对应协议首部中提取出来的指定字段复制并保存到该报文头向量中。通过逐级处理,各类协议中所有提取的字段将最终从报文头向量端口输出至报文头解析器的后续处理模块中。因此,本章节需要解决该向量的位宽即端口的位宽,以及指定字段在该向量中的存放位置。报文头解析器根据要求,从各种支持的协议首部中提取不同位宽的字段,并将其保存至报文头向量中。如果将所有提取字段保存至固定的位置,这将造成向量位宽的浪费。比如在一个同时支持“IPv4”和“IPv6”的报文头解析器中需要提取源IP地址和目的IP地址,如果将他们设计为保存到固定的地址,那么“IPv4”和“IPv6”两者的地址将占用320个比特的位宽。但很显然,“IPv4”和“IPv6”两类IP地址永远不会同时出现在该向量中,两者可以实现存储空间的共享。本实施例以流水线的分级为基础,计算每一级各个处理模块所提取字段的总长,并将该流水级中提取字段总长最长位宽作为该级流水线存储空间的长度,而同一级流水线的各模块之间将共享这一段存储空间。最后,将各个流水级的存储空间顺序拼接,构成最终的报文头向量空间。以提取IP报文中的五元组为例,说明IP地址,协议号和端口号在报文头向量中的排列。图9展示了五元组在报文头向量中的最终排列结果。图9中的虚线将分属于不同层级的协议分开,IP地址和协议号从三层协议如“IPv4”和“IPv6”中获取,而端口号从四层协议如“TCP”和“UDP”中获取,而支持IP报文的解析器往往将“IPv4”和“IPv6”以及“TCP”和“UDP”两者调度到同一个流水级中。按照上述的设计方法,在三层协议所在的流水级最长的提取字段为“IPv6源IP地址”+“IPv6目的IP地址”+“协议号”,如此“IPv4”提取到的IP地址将于更长的“IPv6”IP地址实现共享。在四层网络协议中,从“TCP”和“UDP”获取的端口号完全相同,因此两者可以实现存储字段的完全共享。通过将两级流水线结合,因此标头向量的长度应为“IPv6”IP地址+协议号+端口号的总长度,为296比特位宽。
由于报文头由多种不同的协议首部组合而成,在报文头解析过程当中,不仅需要从各种协议首部中提取指定的字段,而且还需要将各种协议的类型记录,并应用到后续处理模块中,比如逆解析器可以按照这个记录重新组装更新后的报文头。本实施例采用一个向量用于记录报文头中相应的协议类型,以图1所示的解析图为例,图10表示这样的一个向量。上述向量中每一个比特对应唯一的一个协议,当对应位标记为“1”时,表示该协议在当前报文中存在,否则标记为“0”。这个向量通过相应的端口,逐级在流水线中传输。在解析报文头的过程中,可能会发生各种错误,比如报文中包含解析器不支持的协议种类,亦或出现校验值错误等。这些错误必须被记录并传递至后续的处理单元进行相应的处理。例如将无法识别的协议上传进行处理,或者将出现错误的报文直接丢弃。这些错误信息同样使用具有特定位宽的向量来保存,其结构与类型向量类似,并通过错误传输端口逐级传递。
如图11所示,本实施例还提供一种前述报文解析器的设计方法,实施步骤包括:
1)确定报文解析器所需支持的网络协议,将报文解析器所需支持所有网络协议生成有向无环图作为协议解析图;
2)在协议解析图中找出一条最长的路径作为主干路径,将主干路径的节点个数作为报文解析器的流水级数,从而确定报文解析器的流水级数;
3)在所有未选入主干中的节点遍历选取一个节点作为操作对象;针对每一个操作对象,找出主干路径中的所有前驱节点,从这些前驱节点中选取一个处在主干路径最底层的并保留该前驱节点与当前操作对象的依赖关系,并将处于兄弟关系的两个节点合并为一个虚拟节点并将这两个节点的与其前驱和后继节点的关系调整为与这个虚拟节点的关系,从而使得协议解析图中的每一个节点都归属到报文解析器的每一级流水中获得优化后的协议解析图,从而确定报文解析器的每一级流水线中所包含的协议处理模块;
4)根据报文解析器所支持的最长报文头计算报文头切片的长度,然后根据每个协议需要提取的字段以及所在流水级的位置,计算总的报文头向量宽度,并分配地址给各个提取的字段;
5)根据优化后的协议解析图配置各级流水线中所包含的协议处理模块的参数(协议处理模块的参数包括但不限于端口的位宽、提取字段的个数、对应字段的地址等信息),使得各个流水线中所包含的协议处理模块用于处理对应的网络协议;
6)将各级流水线中所包含的协议处理模块按照优化后的协议解析图中的顺序进行拼接,从而得到完成设计的报文解析器。
计算机网络在开放式系统互联(Open System Interconnect,OSI)模型中被分成七层结构,而各种网络协议也分别对应于其中的一层,比如“Ethernet类型”对应于OSI底层的数据链路层,而“IPv4”对应于OSI模型的网络层。网络报文在发送至网络之前,其报文头也将按照这种层次关系进行封装,最高层协议将封装在最内层,然后才是低层次的协议,而解包过程刚好相反。由于协议之间的这种层次关系,在报文头的解析过程中,除了最外层的协议首部外,任何一个内层协议首部在解析其前一个协议之前均是未知的,只有其前一个协议首部解析完成后才能得到确认。这种依赖关系在报文头解析器设计时,根据其设计支持的所有网络协议便可获知,并使用有向无环图(DAG)将这种关系清晰的表示,本实施例称之为协议解析图。基于本实施例的方法,这种依赖关系是通过解析程序得到并以此建立相应的协议解析图。图12即是这种典型的解析图。其中图中的各个节点分别表示对应的网络协议类型,而节点之间的箭头表示协议之间的转换顺序和依赖关系。以图12为例,包含了“Ethernet”,“VLAN”,“IPv4”,“IPv6”等各种协议。报文解析器所能支持的报文中,第一个协议一定是“Ethernet”这个二层协议,紧接其后的却有可能是“IPv4”,“IPv6”或者“VLAN”协议,具体只能在解析“Ethernet”之后才能确定。可以根据这个解析图,设计解析对应协议的处理模块,并建立各个处理模块之间的数据通路,完全实现图示的功能。但是这种实现方式可能带来新的问题。假设本实施例中按照图12所示的协议依赖关系实现了对应的报文解析器,那么这个解析器在解析输入的各种报文头时,可能带来资源冲突,从而造成流水线的停顿,造成解析性能降低。
下文以表I中第一列按照先后顺序输入解析器的三个报文为例讲述这种冲突。
表1:报文头分析过程中的冲突停顿。
上表中,Packer Header表示报文包的报文头,Clock number表示时钟排数。假设第一个时钟输入解析器的报文头为“Ethernet→MPLS→IPv4”,第二个时钟周期输入的报文头为“Ethernet→IPv4”,而在第三个时钟周期输入的报文头为“Ethernet→IPv6”。因此,当第一个报文输入解析器时,报文将直接送到“Ethernet”协议的处理模块,并且解析出下一个协议首部为“MPLS”。第二个时钟周期到来后,第一个数据包被送到“MPLS”协议的处理模块,“Ethernet”处理模块将变得空闲,而第二个报文被直接送到已经空闲的“Ethernet”处理模块中。此时,“MPLS”处理模块解析出第一个报文的下一个协议为“IPv4”协议,第三个时钟周期到来时这个报文将被送到“IPv4”处理模块。与此同时,处理第二个报文的“Ethernet”处理模块解析出第二个报文的下一个协议同样为“IPv4”,在第三个时钟周期到来时第二个报文也将送往“IPv4”处理模块。当第三个时钟周期到来时,第一个报文和第二个报文需要使用同一个“IPv4”的处理资源,由此将产生资源冲突。此时第二个报文不得不停顿等待资源的释放,而且将继续占用“Ethernet”处理模块,因此也直接造成了第三个报文的停顿。这种资源冲突导致的停顿,直接导致解析器处理性能的下降,而流水级(处理模块)的调度是解决这种冲突的方法之一。本实施例中通过对流水线的调度,将多个不同的协议处理模块按照特定的顺序分配至不同的流水级中,从而使输入的报文能够被按照其协议分装的顺序逐层解析,而不产生任何的冲突和停顿,实现输入报文的完全流水化。
同样以图1所示功能的报文解析器为例,来说明本实施例所提出的流水线调度方法。其调度过程如图12所示;图12中,(a)至(c)演示了调度某一个节点的操作过程,其中(c)和(d)之间的虚线箭头表示省略针对其他节点相同操作的步骤,而(d)表示最终的调度结果。详细地调度过程如下步骤所述。
主干选择:本实施例中需要在图1的解析图中找出一条最长的路径。而图1中存在四条具有五个节点的路径,比如“Ethernet→VLAN→VLAN→IPv4→TCP”或者“Ethernet→VLAN→VLAN→IPv6→TCP”。如果解析图存在多条最长路径,调度程序将选取其中任意一条路径作为后续操作的基准。为了演示的方便,本实施例选择“Ethernet→VLAN→VLAN→IPv4→TCP”作为基准并用主干图表示,其结果如图12(a)所示。
定位层级:在所有未选入主干中的节点选取一个节点作为操作对象,比如选取节点“IPv6”。然后,找出节点“IPv6”在主干中的所有前驱节点,这些节点分别为“Ethernet”,外层“VLAN”和内层“VLAN”。此后,从这些前驱节点中选取一个处在主干最底层的,并保留该前驱节点与当前操作对象的依赖关系。图12(b)即保留内层“VLAN”与“IPv6”之间的关系,采用实线箭头标明,而与其他两个前驱节点之间的关系被删除,采用虚线箭头表示。
合并兄弟节点:此时,节点“IPv6”与节点“IPv4”均为内层“VLAN”的后继节点,两者之间为兄弟关系。将处于兄弟关系的两个节点合并为一个虚拟节点,并将这两个节点的与其前驱和后继节点的关系调整为与这个虚拟节点的关系。结果如图12(c)所示。
重复上述步骤2和步骤3,直至所有其他节点全部进入主干中。图12(d)显示将图1中的解析图调度之后的最终结果。
通过步骤1),解析图中主干的选取即完成了解析器流水级数的确定,主干的节点个数即解析器的流水级数。通过步骤2),能够将解析图中的所有节点在流水线中应处的位置确定。而步骤3)即将所有节点与自己处于同一级流水线的节点合并,实现流水级的设计。流水线调度完成之后,每个输入的报文均能在该流水线中逐级解析。该报文解析器具有固定的流水级数,所有报文的解析具有恒定的延迟。本实施例前述报文解析器中的多级流水线由不同的协议处理模块构成,这些模块具有一个通用的硬件体系结构。通过配置此结构中的各种功能参数,从而实现针对不同协议首部的处理功能。根据上述对流水线调度的结果,可将这些处理不同协议首部的处理模块分配到不同的流水级中,最终形成一个完整功能的报文解析器。
为了验证本实施例设计的解析器的性能,本实施例针对硬件结构中的动态移位器及移位器进行评估,包括资源占有,运行速度和吞吐率等方面。评估基于Virtex-7,-3速度等级芯片,使用赛灵思(Xilinx)的综合工具Vivado 2015.4进行综合,最终得到相关数据。
一、动态移位器评估
动态移位器移位具有可变数位的向量,并且它可能在FPGA中使用大量资源。根据网络协议,带有选项的标头长度总是随着32位限制时间的步长而增加。此实验评估此类动态移位器是否节省资源并以高时钟速率运行。使用1024位向量宽度实现三个移位器,以移位480位的IPv4报头。比较结果如表2所示。
表2:变换器比较。
Type | LUTs | FFs | Clock Rate(MHz) |
固定 | 0 | 545 | 714.3 |
本实施例提出 | 1639 | 865 | 533.6 |
完全动态 | 5068 | 1025 | 306.6 |
从表2中可以看出,固定移位器为向量移动固定量位,它使用最少的资源并以非常高的时钟速率运行。全动态移位器具有最大的灵活性,它可以为向量移位任意数量的位,但它使用最大的资源并以最低的时钟速率运行。而本实施例提出的解决方案使用平均资源和时钟速率,这符合本实施例提出的解决方案的理论期望。
二、报文解析器性能评估
为了演示和评估本实施例中提出的解决方案,本实施例分别实现了两类解析器:简单解析器支持以太网,IPv4/IPv6(带2个扩展),UDP,TCP和ICMP/ICMPv6。复杂解析器:与简单解析器相同,但是使用MPLS(带有两个嵌套头)和VLAN(内部和外部)本实施例中提出的解决方案在吞吐量、延迟和资源使用方面的评估结果如表3所示。
表3:在吞吐量、延迟和资源使用方面的评估结果。
由于硬件架构,本实施例中提出的报文解析器的总线宽度为1072和1136,对应于简单解析器中的报文头“Ethernet→IPv4 with option→TCP with option”,以及“Ethernet→VLAN(MPLS)”)→VLAN(MPLS)→带选项的IPv4→带选项的TCP”。所有提取字段包含IPv4和TCP协议首部中的选项部分。根据表3可知:I)时序:本实施例中解析器能够运行在300MHz左右。表中的总延迟表明,报文通过本实施例中提出的解析器仅需要14.55ns。II)吞吐量:本实施例中提出的解析器吞吐量达到300Gbps以上。此外本实施例中的解析器吞吐量仅计算了报文头的数据,考虑报文中的载荷,吞吐量应高于表中的吞吐量。III)资源使用:实现复杂的报文解析器使用少于5%的LUT和2%的FF。
综上所述,本实施例提供的报文解析器基于流水线的硬件基础结构,其中协议处理模块硬件结构可配置为针对不同的协议首部,并组合成各种性能不同的解析器。通过对协议处理模块的调度,以避免冲突和停顿,从而实现完全流水化,且每个周期处理一个数据报文。实验表明,生成的报文解析器可以高效地使用FPGA资源,并且可以实现大约320Gbps的线速率。
以上所述仅是本发明的优选实施方式,本发明的保护范围并不仅局限于上述实施例,凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理前提下的若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (10)
1.一种报文解析器,其特征在于,基于FPGA实现且包括多级流水线,每一级流水线包括至少一个协议处理模块,第一级流水线的输入端包括报文头切片输入端口,最末级流水线的输出端包括报文头向量输出端口、状态输出端口和协议类型端口,相邻流水线之间的通信通道包括报文头切片传输通道、协议类型向量传输通道、报文头向量传输通道和状态传输通道,所述多级流水线中的每一级流水线针对输入的报文头切片按照对应的协议类型进行解析后传输至下级流水线直至最末级流水线的输出端输出解析后的报文头向量和状态信号。
2.根据权利要求1所述的报文解析器,其特征在于,所述状态传输通道包括错误信号传输通道和握手信号传输通道,所述错误信号传输通道用于传输流水线发生的错误信息,所述握手信号传输通道用于传输各流水级之间握手信号,用于标识当前输出端口数据有效,则后一级流水级即接收当前输入的数据。
3.根据权利要求1或2所述的报文解析器,其特征在于,所述协议处理模块包括:
协议类型识别器,用于在当输入的数据有效时,比较检查输入的协议类型向量的指定位以确认当前协议处理模块所配置的协议类型是否与前一级协议首部解析出来的协议匹配,如果匹配则通过控制信号EN控制后续的报文头切片移位器、字段提取器、协议类型生成器三个功能模块对输入的数据进行处理还是仅传递输入的数据;
报文头切片移位器,用于针对报文头切片传输通道输入的报文头切片,计算或标识移位量并执行移位操作,将下一个待处理协议首部移动到报文头切片的头部,然后在控制信号EN控制下选择移位操作后的数据或者移位操作前的原始数据,通过寄存器组存储作为待输出的报文头切片;
字段提取器,用于将报文头切片中的指定字段提取并更新至报文头向量中;
协议类型生成器,用于编码下一级待处理的网络协议类型,并在协议类型向量中标记最终输出至下一级流水线。
4.根据权利要求3所述的报文解析器,其特征在于,所述协议类型识别器包括一个比较器实现和一个位指示器,所述位指示器为指向类型向量中某一位的常数项,所述类型向量中被位指示器指向的位、常数“1”一起作为比较器的输入,所述比较器的输出端输出的控制信号EN则分别与报文头切片移位器、字段提取器以及协议类型生成器的使能控制端相连。
5.根据权利要求3所述的报文解析器,其特征在于,所述报文头切片移位器包括:
计算单元,用于针对报文头切片计算或者标识移位量;
移位单元,用于针对报文头切片根据移位量执行移位操作;
第一选择器,用于在控制信号EN控制下选择输入移位后的数据还是输入的原始数据;
第一寄存器组,用于存储待输出的报文头切片;
所述计算单元的输入端和本级流水线的报文头切片传输通道的输入端口相连,所述计算单元的输出端和移位单元的输入端相连,所述第一选择器的一个输入端和本级流水线的报文头切片传输通道的输入端口相连、另一路输入端和移位单元的输出端相连,所述第一选择器的输出端和第一寄存器组的输入端相连,所述第一寄存器组的输出端和本级流水线的报文头切片传输通道的输出端口相连。
6.根据权利要求3所述的报文解析器,其特征在于,所述字段提取器包括:
字段指示符,用于存储四组预定义的地址数组,这些地址包括协议首部中各指定字段的起始偏移地址和结束偏移地址,以及在报文头向量的起始偏移地址和结束偏移地址,每组地址数组的元素个数根据提取字段的个数确定;
提取执行器,用于实际执行从报文头切片中复制字段至报文头向量指定位置的功能;
第二选择器,用于在控制信号EN控制下选择提取执行器输出的报文头向量或者输入的原始报文头向量;
第二寄存器组,用于存储待输出的报文头向量;
所述提取执行器的输入端分别与本级流水线的报文头切片传输通道的输入端口、报文头向量传输通道的输入端口相连,所述第二选择器的一个输入端和本级流水线的报文头向量传输通道的输入端口相连、另一路输入端和提取执行器的输出端相连,所述第二选择器的输出端和第二寄存器组的输入端相连,所述第二寄存器组的输出端和本级流水线的报文头向量传输通道的输出端口相连。
7.根据权利要求3所述的报文解析器,其特征在于,所述协议类型生成器包括:
类型指示符,用于指示下一级流水线所需处理的协议类型的匹配字段和方式;
类型生成器,用于生成下一级流水线所需处理的网络协议类型,并在协议类型向量中标记;
第三选择器,用于在控制信号EN控制下选择生成的协议类型或者输入的原始协议类型;
第三寄存器组,用于存储待输出的协议类型;
所述类型指示符的输入端分别与本级流水线的报文头切片传输通道的输入端口、协议类型向量传输通道的输入端口相连,所述第三选择器的一个输入端和本级流水线的协议类型向量传输通道的输入端口相连、另一路输入端和类型生成器的输出端相连,所述第三选择器的输出端和第三寄存器组的输入端相连,所述第三寄存器组的输出端和本级流水线的协议类型向量传输通道的输出端口相连。
8.根据权利要求1所述的报文解析器,其特征在于,所述报文头切片传输通道的端口位宽等于本报文解析器待支持的所有报文类型中最长报文头的长度。
9.根据权利要求1所述的报文解析器,其特征在于,所述报文头向量传输通道的端口位宽等于流水线中各级提取字段总和最长的协议处理模块所提取字段长度之和。
10.一种权利要求1~9中任意一项所述的报文解析器的设计方法,其特征在于实施步骤包括:
1)确定报文解析器所需支持的网络协议,将报文解析器所需支持所有网络协议生成有向无环图作为协议解析图;
2)在协议解析图中找出一条最长的路径作为主干路径,将主干路径的节点个数作为报文解析器的流水级数,从而确定报文解析器的流水级数;
3)在所有未选入主干中的节点遍历选取一个节点作为操作对象;针对每一个操作对象,找出主干路径中的所有前驱节点,从这些前驱节点中选取一个处在主干路径最底层的并保留该前驱节点与当前操作对象的依赖关系,并将处于兄弟关系的两个节点合并为一个虚拟节点并将这两个节点的与其前驱和后继节点的关系调整为与这个虚拟节点的关系,从而使得协议解析图中的每一个节点都归属到报文解析器的每一级流水中获得优化后的协议解析图,从而确定报文解析器的每一级流水线中所包含的协议处理模块;
4)根据报文解析器所支持的最长报文头计算报文头切片的长度,然后根据每个协议需要提取的字段以及所在流水级的位置,计算总的报文头向量宽度,并分配地址给各个提取的字段;
5)根据优化后的协议解析图配置各级流水线中所包含的协议处理模块的参数,使得各个流水线中所包含的协议处理模块用于处理对应的网络协议;
6)将各级流水线中所包含的协议处理模块按照优化后的协议解析图中的顺序进行拼接,从而得到完成设计的报文解析器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911155986.9A CN111131159A (zh) | 2019-11-22 | 2019-11-22 | 一种报文解析器及其设计方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911155986.9A CN111131159A (zh) | 2019-11-22 | 2019-11-22 | 一种报文解析器及其设计方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111131159A true CN111131159A (zh) | 2020-05-08 |
Family
ID=70496441
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911155986.9A Pending CN111131159A (zh) | 2019-11-22 | 2019-11-22 | 一种报文解析器及其设计方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111131159A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111818098A (zh) * | 2020-09-01 | 2020-10-23 | 广东省新一代通信与网络创新研究院 | 一种报文编辑方法、装置及计算机可读存储介质 |
CN112202670A (zh) * | 2020-09-04 | 2021-01-08 | 烽火通信科技股份有限公司 | 一种SRv6段路由转发方法及装置 |
CN112732241A (zh) * | 2021-01-08 | 2021-04-30 | 烽火通信科技股份有限公司 | 一种多级并行高速处理下的可编程解析器及其解析方法 |
CN113824706A (zh) * | 2021-09-10 | 2021-12-21 | 杭州迪普信息技术有限公司 | 报文解析方法及网络设备 |
CN115314446A (zh) * | 2022-07-22 | 2022-11-08 | 武汉烽火技术服务有限公司 | 一种报文带宽补偿方法、装置及设备 |
CN117278661A (zh) * | 2023-11-23 | 2023-12-22 | 中汽数据(天津)有限公司 | 一种工业物联网多协议解析方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080212611A1 (en) * | 2001-03-29 | 2008-09-04 | International Business Machines Corporation | Parsing messages with multiple data formats |
CN102685008A (zh) * | 2012-05-07 | 2012-09-19 | 西安电子科技大学 | 基于流水线的快速流识别方法及设备 |
CN106961445A (zh) * | 2017-04-28 | 2017-07-18 | 中国人民解放军信息工程大学 | 基于fpga硬件并行流水线的报文解析方法及其装置 |
CN107707548A (zh) * | 2017-09-30 | 2018-02-16 | 北京东土军悦科技有限公司 | Tlv报文解析方法、装置、电子设备及存储介质 |
CN110381051A (zh) * | 2019-07-12 | 2019-10-25 | 苏州浪潮智能科技有限公司 | 一种报文解析的方法、系统、设备及计算机可读存储介质 |
-
2019
- 2019-11-22 CN CN201911155986.9A patent/CN111131159A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080212611A1 (en) * | 2001-03-29 | 2008-09-04 | International Business Machines Corporation | Parsing messages with multiple data formats |
CN102685008A (zh) * | 2012-05-07 | 2012-09-19 | 西安电子科技大学 | 基于流水线的快速流识别方法及设备 |
CN106961445A (zh) * | 2017-04-28 | 2017-07-18 | 中国人民解放军信息工程大学 | 基于fpga硬件并行流水线的报文解析方法及其装置 |
CN107707548A (zh) * | 2017-09-30 | 2018-02-16 | 北京东土军悦科技有限公司 | Tlv报文解析方法、装置、电子设备及存储介质 |
CN110381051A (zh) * | 2019-07-12 | 2019-10-25 | 苏州浪潮智能科技有限公司 | 一种报文解析的方法、系统、设备及计算机可读存储介质 |
Non-Patent Citations (1)
Title |
---|
ZHUANG CAO等: ""A Fast Approach for Generating Efficient Parsers on FPGAs"", 《SYMMETRY》 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111818098A (zh) * | 2020-09-01 | 2020-10-23 | 广东省新一代通信与网络创新研究院 | 一种报文编辑方法、装置及计算机可读存储介质 |
CN112202670A (zh) * | 2020-09-04 | 2021-01-08 | 烽火通信科技股份有限公司 | 一种SRv6段路由转发方法及装置 |
CN112732241A (zh) * | 2021-01-08 | 2021-04-30 | 烽火通信科技股份有限公司 | 一种多级并行高速处理下的可编程解析器及其解析方法 |
CN112732241B (zh) * | 2021-01-08 | 2022-04-01 | 烽火通信科技股份有限公司 | 一种多级并行高速处理下的可编程解析器及其解析方法 |
CN113824706A (zh) * | 2021-09-10 | 2021-12-21 | 杭州迪普信息技术有限公司 | 报文解析方法及网络设备 |
CN113824706B (zh) * | 2021-09-10 | 2023-07-25 | 杭州迪普信息技术有限公司 | 报文解析方法及网络设备 |
CN115314446A (zh) * | 2022-07-22 | 2022-11-08 | 武汉烽火技术服务有限公司 | 一种报文带宽补偿方法、装置及设备 |
CN115314446B (zh) * | 2022-07-22 | 2024-05-28 | 烽火通信科技股份有限公司 | 一种报文带宽补偿方法、装置及设备 |
CN117278661A (zh) * | 2023-11-23 | 2023-12-22 | 中汽数据(天津)有限公司 | 一种工业物联网多协议解析方法及系统 |
CN117278661B (zh) * | 2023-11-23 | 2024-04-09 | 中汽数据(天津)有限公司 | 一种工业物联网多协议解析方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111131159A (zh) | 一种报文解析器及其设计方法 | |
KR102402176B1 (ko) | 소프트웨어-규정된 네트워크 엔진에서 패킷 수정 및 포워딩을 위해서 룩업들을 생성하고 결정들을 수행하기 위한 장치 및 방법 | |
US20060117126A1 (en) | Processing unit for efficiently determining a packet's destination in a packet-switched network | |
WO2012080170A1 (en) | Network processor and method for accelerating data packet parsing | |
US20070192572A1 (en) | Minimum processor instruction for implementing weighted fair queuing and other priority queuing | |
US8943085B2 (en) | Start pointer tracking in NFAs | |
US8824468B2 (en) | System and method for parsing frames | |
CN112136108A (zh) | 一种报头解析装置及方法 | |
CN113411380A (zh) | 基于fpga可编程会话表的处理方法、逻辑电路和设备 | |
CN107707548B (zh) | Tlv报文解析方法、装置、电子设备及存储介质 | |
Zazo et al. | Automated synthesis of FPGA-based packet filters for 100 Gbps network monitoring applications | |
US11095760B1 (en) | Implementing configurable packet parsers for field-programmable gate arrays using hardened resources | |
US20150023356A1 (en) | Alignment circuit and receiving apparatus | |
CN113835712B (zh) | 一种按照给定字段值进行判断的快速数据包分组路由方法 | |
EP4203395A1 (en) | Packet forwarding method and apparatus, and computer-readable storage medium | |
EP1360602B1 (en) | Apparatus and method for processing pipelined data | |
US11425036B1 (en) | Pipelined match-action circuitry | |
CN114143195A (zh) | 一种数据包处理装置及方法 | |
JPH11317783A (ja) | ヘッダ処理装置とそのヘッダ処理方法 | |
CN110933001A (zh) | 一种可扩展的可重构交换机包解析器基本处理单元结构 | |
US8661162B2 (en) | Address handling | |
CN116847005B (zh) | 报文解析方法、解析器件及网络设备 | |
US11831743B1 (en) | Streaming architecture for packet parsing | |
US11657203B2 (en) | Multi-phase topology synthesis of a network-on-chip (NoC) | |
US20240195742A1 (en) | Deadlock prevention of switch memory overflow |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200508 |