CN111865804A - 一种通过硬件发包机制提升路由下发效率的方法及系统 - Google Patents

一种通过硬件发包机制提升路由下发效率的方法及系统 Download PDF

Info

Publication number
CN111865804A
CN111865804A CN202010544458.9A CN202010544458A CN111865804A CN 111865804 A CN111865804 A CN 111865804A CN 202010544458 A CN202010544458 A CN 202010544458A CN 111865804 A CN111865804 A CN 111865804A
Authority
CN
China
Prior art keywords
address
level
route
routing
index
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.)
Granted
Application number
CN202010544458.9A
Other languages
English (en)
Other versions
CN111865804B (zh
Inventor
王欢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fiberhome Telecommunication Technologies Co Ltd
Wuhan Fisilink Microelectronics Technology Co Ltd
Original Assignee
Fiberhome Telecommunication Technologies Co Ltd
Wuhan Fisilink Microelectronics Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fiberhome Telecommunication Technologies Co Ltd, Wuhan Fisilink Microelectronics Technology Co Ltd filed Critical Fiberhome Telecommunication Technologies Co Ltd
Priority to CN202010544458.9A priority Critical patent/CN111865804B/zh
Publication of CN111865804A publication Critical patent/CN111865804A/zh
Application granted granted Critical
Publication of CN111865804B publication Critical patent/CN111865804B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/74591—Address table lookup; Address filtering using content-addressable memories [CAM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/748—Address table lookup; Address filtering using longest matching prefix

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种通过硬件发包机制提升路由下发效率的方法及系统，涉及路由技术领域，本发明通过将待配置的低掩码路由映射到硬件发包器的数据包内容中，通过硬件发包器发包实现将低掩码路由下发至DRAM当中。硬件发包器可以一次下发多个报文，用来替代现有技术通过CPU一条一条地下发大量的条目进行下一跳覆盖的方式，不仅可以提高路由的下表速率，且与传统的TCAM方式相比，能够提升低掩码的路由容量。

Description

一种通过硬件发包机制提升路由下发效率的方法及系统
技术领域
本发明涉及路由技术领域，具体涉及一种通过硬件发包机制提升路由下发效率的方法及系统。
背景技术
传统的ASIC(ApplicationSpecificIntegratedCircuit，专用集成电路)芯片采用TCAM(TernaryContentAddressMemory，三态内容寻址存储器)方式进行Ipv4/Ipv6路由下发，在软件下发表项的时候，采用Hash二分法或者平衡二叉树的方式对路由软件同步表缓存，在复杂的软件表项计算和搬移下，调用软件API(Application ProgrammingInterface，应用编程接口)，通过Cpu的Pcie(总线与接口标准)下发消息到指定的TCAM条目位置。由于TCAM成本昂贵，容量小，此方式不能满足大路由容量的需求。
采用传统的DRAM(DynimicRandomAccessMemory，动态随机存取存储器)方式下发Ipv4/Ipv6路由，软件采用M-Tries(多步长单词查找树)树方式进行路由下发分配，利用DRAM的空间的大的特点，采用24-8的Trie(两级查找，第一级长度为24位掩码，第二掩码长度为8的单词查找树)树方式下发，采用以空间换时间的方式，通过CPU下发大量的条目进行下一跳覆盖，极大的占用CPU的利用率，导致路由难以收敛。
综上所述，以上两种技术均存在路由容量小、下发速度慢的缺陷。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种通过硬件发包机制提升路由下发效率的方法及系统，提高路由的下表速率。
为达到以上目的，本发明采取的技术方案是：一种通过硬件发包机制提升路由下发效率的方法，包括以下步骤：
将待配置的低掩码路由映射到硬件发包器的数据包内容中，
通过硬件发包器将所述低掩码路由下发至DRAM中。
在上述技术方案的基础上，所述低掩码路由为长度为1至24位掩码的IPV4路由或长度小于等于64位掩码的IPv6路由。
在上述技术方案的基础上，将待配置的低掩码路由映射到硬件发包器的数据包内容中，具体包括以下步骤：
对于掩码长度小于/等于16位的IPv4路由或掩码长度小于/等于56位的Ipv6路由，根据该路由对应的路由操作修改IP查找树；
遍历软件同步表的第一级的下一跳索引中该条路由覆盖地址段，对上述地址段中的每一个地址，反向计算出地址IP的前16/56位作为KEY，在IP查找树中查找KEY对应的路由项；
比较在IP查找树中找到的路由项与软件同步表中记录的路由项是否存在差异；
若存在差异，根据IP查找树中找到的路由项更新软件同步表中的下一跳索引的路由项值，并将需要更新的下一跳索引、以及对应的软件同步表的第一级的地址，配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
在上述技术方案的基础上，将待配置的低掩码路由映射到硬件发包器的数据包内容中，具体还包括以下步骤：
对于掩码长度大于16位的IPv4路由或掩码长度大于56位的Ipv6路由，以IPv4/Ipv6路由地址的前16/56位进行哈希运算得到一个地址作为软件同步表的第二级的地址索引，保存到软件同步表的第一级中；
若第二级的地址索引无效，建立第一级对应的软件同步表的第二级块，从IP查找树中恢复出当前路由地址的原始第二级块数据填入新建的第二级块；
根据该路由对应的路由操作修改IP查找树；
通过当前路由地址和掩码长度计算出该路由在软件同步表的第二级块中所覆盖的地址段；
遍历上述地址段，对上述地址段中的每一个地址，结合第二级的地址索引反向计算出完整IP，采用该IP作为KEY，在IP查找树中进行最长匹配查找；
比较在IP查找树中找到的路由项与软件同步表的第二级块中记录的路由项是否存在差异；
若存在差异，将第一级中保存的第二级的索引地址、需要更新的下一跳索引配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
在上述技术方案的基础上，通过硬件发包器将所述低掩码路由下发至DRAM中，具体包括以下步骤：
判断IPV4路由掩码长度是否小于等于16或IPV6路由掩码长度是否小于等于56位；
如果为是，提取报文头部中第一级的地址和第一级的下一跳索引，将发包个数控制器的计数值加上第一级的地址，将第一级的下一跳索引更新至各地址对应的DRAM路由表项；
如果为否，将IPV4路由的IP头部的前16位或IPV6路由的IP头部的前56位进行地址查找，获取第一级的下一跳索引和第二级的地址索引；通过低8位地址加上第二级的地址索引进行地址查找，获取第二级的下一跳索引，如果查找到的第二级的下一跳索引有效，采用该第二级的下一跳索引作为需更新的下一跳索引；如果查找到的第二级的下一跳索引无效，采用第一级的下一跳索引作为需更新的下一跳索引；提取报文头部中第二级的基地址，将发包个数控制器的计数值加上第二级的基地址，将需更新的下一跳索引更新至各地址对应的DRAM路由表项。
本发明还提供一种通过硬件发包机制提升路由下发效率的系统，包括：
配置模块，其用于：将待配置的低掩码路由映射到硬件发包器的数据包内容中；
微码模块，其用于：通过硬件发包器将所述低掩码路由下发至DRAM中。
在上述技术方案的基础上，所述低掩码路由为第1至24位掩码的IPV4路由或小于等于64位掩码的IPv6路由。
在上述技术方案的基础上，所述配置模块具体用于：
对于掩码长度小于/等于16位的IPv4路由或掩码长度小于/等于56位的Ipv6路由，根据该路由对应的路由操作修改IP查找树；
遍历软件同步表的第一级的下一跳索引中该条路由覆盖地址段，对上述地址段中的每一个地址，反向计算出地址IP的前16/56位作为KEY，在IP查找树中查找KEY对应的路由项；
比较在IP查找树中找到的路由项与软件同步表中记录的路由项是否存在差异；
若存在差异，根据IP查找树中找到的路由项更新软件同步表中的下一跳索引的路由项值，并将需要更新的下一跳索引、以及对应的软件同步表的第一级的地址，配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
在上述技术方案的基础上，所述配置模块具体还用于：
对于掩码长度大于16位的IPv4路由或掩码长度大于56位的Ipv6路由，以IPv4/Ipv6路由地址的前16/56位进行哈希运算得到一个地址作为软件同步表的第二级的地址索引，保存到软件同步表的第一级中；
若第二级的地址索引无效，建立第一级对应的软件同步表的第二级块，从IP查找树中恢复出当前路由地址的原始第二级块数据填入新建的第二级块；
根据该路由对应的路由操作修改IP查找树；
通过当前路由地址和掩码长度计算出该路由在软件同步表的第二级块中所覆盖的地址段；
遍历上述地址段，对上述地址段中的每一个地址，结合第二级的地址索引反向计算出完整IP，采用该IP作为KEY，在IP查找树中进行最长匹配查找；
比较在IP查找树中找到的路由项与软件同步表的第二级块中记录的路由项是否存在差异；
若存在差异，将第一级中保存的第二级的索引地址、需要更新的下一跳索引配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
在上述技术方案的基础上，所述微码模块具体用于：
判断IPV4路由掩码长度是否小于等于16或IPV6路由掩码长度是否小于等于56位；
如果为是，提取报文头部中第一级的地址和第一级的下一跳索引，将发包个数控制器的计数值加上第一级的地址，将第一级的下一跳索引更新至各地址对应的DRAM路由表项；
如果为否，将IPV4路由的IP头部的前16位或IPV6路由的IP头部的前56位进行地址查找，获取第一级的下一跳索引和第二级的地址索引；通过低8位地址加上第二级的地址索引进行地址查找，获取第二级的下一跳索引，如果查找到的第二级的下一跳索引有效，采用该第二级的下一跳索引作为需更新的下一跳索引；如果查找到的第二级的下一跳索引无效，采用第一级的下一跳索引作为需更新的下一跳索引；提取报文头部中第二级的基地址，将发包个数控制器的计数值加上第二级的基地址，将需更新的下一跳索引更新至各地址对应的DRAM路由表项。
与现有技术相比，本发明的优点在于：
本发明通过将待配置的低掩码路由映射到硬件发包器的数据包内容中，通过硬件发包器发包实现将低掩码路由的下发至DRAM当中。硬件发包器可以一次下发多个报文，用来替代现有技术通过CPU一条一条地下发大量的条目进行下一跳覆盖的方式，不仅可以提高路由的下表速率，且与传统的TCAM方式相比，能够提升低掩码的路由容量。
附图说明
图1为本发明实施例的硬件发包器的数据包格式；
图2为本发明实施例的微码实现硬件写路由条目的操作流程；
图3为本发明实施例的Ipv4路由的硬件发包器的数据包格式；
图4为本发明实施例的Ipv6路由的硬件发包器的数据包格式。
具体实施方式
以下结合附图对本发明的实施例作进一步详细说明。
本发明实施例提供一种通过硬件发包机制提升路由下发效率的方法，包括以下步骤：
将待配置的低掩码路由映射到硬件发包器的数据包内容中，
通过硬件发包器将所述低掩码路由下发至DRAM中。
本发明实施例适用于IPV4路由和IPv6路由。
对于IPV4路由，低掩码路由为长度为1至24位掩码的IPV4路由，高掩码路由长度为25至32位掩码的IPV4路由；
对于IPV6路由，低掩码路由为长度小于等于64位掩码的IPv6路由，高掩码路由为长度大于64位掩码的IPv6路由。
对于IPV4和IPv6的高掩码路由，采用TCAM下发。本发明实施例主要涉及IPV4和IPv6的低掩码路由的下发步骤。
首先需要构建IP查找树。IP查找树包括IPv4查找树和IPv6查找树。IPv4/IPv6查找树是一个标准的PATRICIATRIE(帕式单词查找树)。该树为不饱和二叉树，目前使用的方式不包含逆向父节点索引，叶节点为IPv4/IPv6路由项，挂载下一跳索引。
对于Ipv4的DRAM路由算法下发采用了16-8式的分段方式，即前16位添加到软件同步表的Stride1(第一级)，后8位添加到软件同步表的stride2(第二级)。
对于Ipv6的DRAM路由算法下发采用了56-8式的分段方式，即前56位添加到软件同步表的Stride1(第一级)，后8位添加到软件同步表的stride2(第二级)。
对于Ipv4的掩码长度小于或者等于16位的路由或Ipv6的掩码长度小于或者等于56位的路由，只需要添加到软件同步表的Stride1，不需要添加后面的Stirde2，具体流程如下：对于Stride1的修改，软件层面上需要修改IPv4查找树，同步软件同步表，采用软件同步表同步硬件DRAMStride1(DRAM的第一级查找)。
1、修改IPv4/Ipv6查找树。若为删除操作，删除树的该查找路径，并删除释放叶节点；若为添加操作，添加树的该查找路径，并申请添加新叶节点；若该节点存在，则删除释放原节点并申请添加新叶节点。
2、遍历软件同步表的Stride1表下一跳索引中该条路由覆盖地址段。对于ipv4的路由起始地址为该条路由的前16位，结束地址为其匹配长度能覆盖到的最后一个地址的前16位。例如：2.3.0.0/15的覆盖地址段为0x0202-0x0203，又例如2.48.0.0/12的覆盖地址段为0x0230-0x023F。对于ipv6的路由起始地址为该条路由的前56位，结束地址为其匹配长度能覆盖到的最后一个地址的前56位。
3、对上述IPv4的地址段中的每一个地址，反向计算出一个IP的前16位，然后以此IP作为KEY在IPv4查找树中查找路由项。例如，0x0233计算出IP为2.51.0.0。然后以此IP作为KEY在IPv4查找树中查找路由项。此时IPv4查找树中的内容由于步骤1的修改，同步了最新的修改部分；而软件同步表中的内容则和硬件表项同步，仍是修改之前的状态。对IPv4查找树的查找是一个标准的最长匹配过程，返回的值为其最长匹配时的路由项。比较刚才IPv4查找树的查找到的路由项与软件同步表Stride1表中本条IP的现在记录的路由项，如果有所差异，则表示这条软件同步表Stride1路由项为所修改的路由IP能匹配到的区域，需要更新；如没有差异，则表示虽然这条修改的路由IP在可能被匹配到的范围内，但是由于有其他更长的匹配，这条并没有被最长匹配到，不需要更新。对IPv6路由，同样对IPv6的地址段中的每一个地址，反向计算出一个IP的前56位，然后以此IP作为KEY在IPv6查找树中查找路由项。后续处理步骤与IPv4相同。
4、在软件同步表Stride1结构当中，下一跳索引是一个数组变量，数组的大小为64k，每个下一跳索引的数组下标，就是对应一个ip地址的前16位，对于所有需要更新的软件同步表的下一跳索引项，将软件同步表中的下一跳索引路由项值更新，然后将需要更新的下一跳索引项、以及对应的Stride1的地址，配置到硬件发包器对应的用户自定义寄存器当中，通过启动硬件发包器，通过编写微码流程去更新DRAMStride表项的更新。
例如：s1_next_hop_ref[0x0233]＝100,下一跳索引值为100，对应的地址是10，0x0233所映射的ip地址为2.51.0.0。将这个地址值，以及下一跳索引，配置到硬件发包器固定的位域当中。
对于所有需要更新的软件同步表的下一跳索引项，将软件同步表中的下一跳索引路由项值更新，并同时采用硬件发包机制，通过数据平面下发包，根据发送数据包的内容，去更新Stride1的路由条目范围。
采用硬件发包机制，通过数据平面下发包，根据发送数据包的内容，去更新Stride1的路由条目范围，具体过程包括：
对于Ipv6，前56bits使用Stride1，后8bits和IPv4一样使用Stride2，前56bits首先由Hash引擎计算出一个20bits的Hashkey，使用该Hash值作为Stride2的索引地址。需要说明的是Ipv6的Stride1表与IPv4的Stride1表分别分配在不同的DRAM当中，物理上是分开的。
所有IPv6的软件同步表的路由表项都使用Stride2，并不对56bits情况特别省略Stride2。因此Stride1返回的一定是一个指向Stride2块的指针，Ipv6与IPv4的共用Stride2块表。
由于Hash值并不完全可靠，在Stride2块结构中加入compare项，用以存放添加路由时的原始IP项，在查找到Stride2入口后，还需判断compare值与当前查找目的IP符合才认为查找匹配，否则返回失败。
对于Stride2的修改，需要分两级操作，对于IPV4的前缀长度大于16的掩码修改，先将固定16bit的ip地址保存到软件同步表的Stride1当中。而对于Ipv6的前缀长度大于等于56的掩码修改，先将固定的56bit的路由进行软件CRC32Hash运算，采取掩码屏蔽的方式获取一个20bit的地址，软件同步表的Stride1当中。然后，两者都是将剩下的8bit，采用地址范围的方式修改下一跳索引，具体流程如下：
1、以IPv4/Ipv6路由地址的前16/56位为Ipv4/ipv6Stride1索引地址，通过表Stride1_blocknum(第一级的地址块索引)对应地址内容是否有效，判断该地址的Stride1是否已经申请了Stride2块。如果该Stride2并无对应Stride2地址块索引并且这次操作不是删除操作，则为其申请一块。
2、在函数局部变量空间中建立一个临时Stride2块。从IPv4查找树中遍历恢复出当前待修改路由地址的原始Stride2块数据。
3、修改IPv4/IPv6查找树。若为删除操作，删除树的该查找路径，并删除释放叶节点；若为添加操作，添加树的该查找路径，并申请添加新叶节点；若该节点存在，则删除释放原节点并申请添加新叶节点。
4、通过当前路由地址和掩码长度计算出这条路由在s2块中所覆盖的地址范围。起始地址为路由地址的24/64位。结束地址为该掩码能覆盖到的最后一个24/64位路由地址，遍历上述Stride2地址段，由地址结合Stride2索引地址反向计算出完整IP，对这些IP在查找树中进行最长匹配查找。依次将查找结果与步骤2中生成的临时Stride2块进行比较，如果有所差异，则表示这条Stride2路由项为所修改的路由IP能匹配到的区域，需要更新；如没有差异，则表示虽然这条修改的路由IP在可能被匹配到的范围内，但是由于有其他更长的匹配，这条并没有被最长匹配到，不需要更新。若有条目不为无效路由项，则将该Stride2块标记为有效。
5、对于需要更新的条目，无需更新至临时Stride2块，直接采用Stride1中对应Stride2地址进行硬件发包器进行更新。
6、若新申请了Stride2块或者释放了Stride2块，则发消息给硬件发包器，对DRAMStride2256个地址范围进行覆盖(8bit的地址寻址空间为256)路由下发。
在软件同步硬件的过程中，通过Cpu发送消息给硬件发包器，将要配置的路由表项的内容映射到硬件发包器的数据包内容中去，然后配置硬件发包器的发包个数，来控制下发该掩码长度的Ipv4路由覆盖范围条目数。
硬件发包器可以一次下发多个报文，用来替代现有技术通过CPU一条一条地下发大量的条目进行下一跳覆盖的方式，实现对IPV4/IPV6路由表项的配置。不仅可以提高路由的下表速率，同时也能够提升低掩码的路由容量。
硬件发包器由以下几个部分组成：发包Start(发包开始控制)寄存器、报文长度寄存器、数据包内容寄存器、报文间隔控制寄存器、数据报文个数控制寄存器。
发包Start寄存器：主要控制报文的发送和停止，报文发送完成后，会有控制消息通告Cpu，Cpu关闭硬件发包器，此时硬件发包器就空闲了，可以给下一个路由下发，可以根据需求设计多个硬件发包器，来进行不同模块之间的调度。
报文长度寄存器：可以选择64字节、96字节、128字节等长度的报文，报文长度不一样，那么报文所携带的数据不一样，当前应用选用128字节。
报文数据内容寄存器：配置发送数据包的报文格式，具体如图1所示。
Stride1Addr字段：表示第一级DRAM下发表项的基地址。
MaskLen字段：表示下发路由表项的掩码长度，长度低于16位，只关心Stride1的相关属性字段。掩码长度在17至24，既需要关心Stride1的相关字段，又需关心Stride2的相关属性字段。对于v6的路由，掩码长度在56-64之间的，既需要关心Stride1的相关字段，又需要关心Stride2的相关字段，其他掩码长度的路由采用TCAM下发，不采用硬件发包器下发。
Stride2Addr字段：表示第二级DRAM下发表项的基地址。
Nexthop1Addr字段：表示第一级下一跳索引。
Nexthop2Addr字段：表示第二级下一跳索引。
Valid字段：表示对Ipv路由掩码的选择标志位。0代表操作ipv4掩码长度小于16的路由，1代表操作掩码长度大于16到24的路由。
Type字段：表示路由类型。0代表为Ipv4路由，1代表Ipv6路由。
数据报文个数控制寄存器：由当前路由掩码长度覆盖地址范围来决定发送多少个报文。
报文间隔控制寄存器：控制发包速率，定义两个数据包之间的时间间隔。
当硬件发包器将数据报文发送到流水线中，此时编写微码实现对DRAM路由表修改操作，具体流程如图2所示：
对于进入流水线的数据报文，首先提取数据报文的Type字段，判断Type字段的真假，若为0，代表Ipv4路由，若为1，代表Ipv6路由。
对于IPv4的报文，提取数据保文头部中的Valid(有效)字段，判断其字段是否为真，如果为真，说明掩码长度是小于等于16位，继续提取报文头部中stride1addr(第一级的地址)和nexthopptr1(第一级的下一跳索引)，然后将逐变的Count(发包个数控制器的计数值)值加上Stride1addr，通过微码写操作实现对DRAM路由下发路由，由于Count值是从0开始递增变化，最大值为用户配置参数值减1，这样就实现了一个地址范围域的写入，避免了通过CPU一条一条的下发消息去实现写表项。如果为否，就是对17-24掩码长度的Ipv4地址进行操作，原理同上，继续提取报文头部中Stride2addr(第二级的基地址)和Nexthopptr2(第二级的下一跳索引)，然后将逐变Count值加上Stride2addr，配置DRAMStride2表项。但是软件需要下发一条消息配置Ipv4Stride1里的Stride2索引地址。因为在流水线中进行路由查找操作的时候，先将IP头部的前16bit进行地址查找，获取一个Nexthopptr1和Stride2的地址索引，然后通过低8位地址加上Stride2的地址索引去查找地址，获取Nexthopptr2，如果Nexthopptr1，Nexthopptr2都有效，就采用Nexthopptr2，如果Nexthopptr2无效，就采用Nexthopptr1，如果都无效，表示路由未查到。
对于IPv6的报文，不关心valid字段，由于ipv6的软件同步表查找必须采用二级查找，所以只需要提取报文头部中Stride2addr(第二级的基地址)和Nexthopptr2(第二级的下一跳索引)，然后将逐变Count值加上Stride2addr，配置DRAMStride2表项。但是软件需要下发一条消息配置Ipv6Stride1里的stride2索引地址和此条IPv6路由的掩码长度。原因在于对于ipv6DRAM查找，只是掩码长度为56-64，不一定是最长匹配，需要和TCAM查找的结果，TCAM返回一个掩码长度，比较这两个掩码长度，谁的掩码长度就采用谁的下一跳索引，去查找下一跳表项。
在实际应用中，采取DDR3SDRAM，DRAM容量为2Gbit，分为4虚拟bank，分别为BankA、BankB、BankC、BankD。用户使用的空间4M条目，每条条目的位宽128bit。对于IPv4路由，BankA全部预留给Ipv4Stride1，BankB全部预留给Stride2。对于Ipv6路由，BankC全部预留给IPv6Strid1如果每个Stride1地址下面挂了一个Stride2块，那么就需要256*64K的内存空间。
微码对DRAM路由的最长匹配查找得益于驱动对DRAM路由的精确添加和删除，在路由添加的时候，它是基于不同掩码长度路由的作用域来执行路由添加，掩码长度越低，作用域越大，掩码长度大的覆盖部分掩码长度小的作用域，在路由删除的时候，删除掩码长度更大的路由要回复比它掩码长度小的作用域。如下2描述了Ipv4路由的1.1.1.1/8的下一跳到A和1.1.1.1/9的下一跳到B，两条路由的添加和删除以及作用域的范围变化。
首先分析1.1.1.1/8这条路由，它的掩码长度为8，只关心前面的8bit，那么后面的16bit都不关心。添加1.1.1.1/8路由的时候，只关心block1的内存单元内容填充，block1内存区域的地址作用域为1.0到1.255，那就意味着在这段地址空间域内的内存单元的nexthopPtr1(下一跳索引1)都为A，stride2的索引全部指向默认为0的Stride2块。
此时对于驱动给硬件发包器的配置发包个数256，报文长度128字节，报文发包间隔设置1us，发包速率为1mpps(每秒1兆个数据包)，收到的报文内容为如图3所示。
流水线收到硬件发包器发来的第一个的报文的时候，Couter(发包个数控制器的计数值，从计数值依次递增)值为0，此时根据数据报文中Valid位判断使用Stride的地址和下一跳索引，然后将stride1的地址加上当前的Count值，然后加上DRAM的BankA的基地址，去下发相应的条目，下发完成后，此数据包将会丢掉。下一个数据包到来的时候，Count自动加1，进行下一个条目的写操作，一直等到所有报文都处理完了，这条路由才算下成功。
如果此时要加入一个1.1.1.1/9的路由，它的掩码长度为9，只关心前面的9bit，在block1内存区域内的地址范围为1.0-1.127，要将1.1.1.1/8低一半的地址作用域的block1内存的下一跳覆盖成B。
如下描述Ipv6路由的2222:2222:2222:2222:2200/56的下一跳到A和2222:2222:2222:2222:2280/57的下一跳到B，两条路由的添加和删除以及作用域的范围变化：
首先Ipv6算法，是对掩码长度56-64bit，其他掩码长度全部放在TCAM当中。故分析2222:2222:2222:2222:2200/56，掩码长度为56位，那么后面8bit就是不关心的，先将前56bit进行CRC32的Hash运算，获得一个20bit的地址索引(例如：Hash值为0x12345)，然后通过软件下发一条配置消息，下发到IPv6Stride1的DRAM条目上，填充内容为Stride2地址块索引的基地址以及掩码长度56位，后面8bit采用地址范围方式寻址，寻址空间所覆盖的Ipv6的64位的掩码路由范围为：
2222:2222:2222:2222:2200—2222:2222:2222:2222:22FF，那就意味着在这段地址空间域内的内存单元的nexthopPtr1(下一跳索引1)都为A。
流水线收到硬件发包器发来的第一个的报文的时候，Couter(发包个数控制器的计数值，从计数值依次递增)值为0，Couter最大值为256，提取数据报文的Type字段，判断Type字段是否为1，若为1，说明是Ipv6路由下发，然后获取Stride2的基地址为1，加上逐变的Couter值，依次对1-256这个地址范围内的DRAM内存进行写操作，写入的下一跳索引为A。硬件发包器的数据包报文内容为如图4所示。
如果继续加入一个2222:2222:2222:2222:2280/57的路由，它的掩码长度为57，只关心前面的57bit，先将前57bit进行CRC32的Hash运算，获得一个20bit的地址索引(例如：Hash值为0x12346)，CPU下发一条消息写Ipv6Stride1的内存，内容为掩码长度57和Stride2地址块索引的基地址。
掩码长度57位，后面7bit采用地址范围方式寻址，寻址空间所覆盖的Ipv6的64位的掩码路由范围为2222:2222:2222:2222:2280—2222:2222:2222:2222:22FF，那就意味着在这段地址空间域内的内存单元的nexthopPtr1(下一跳索引1)都为B。
采用此种方式下发路由，相对于采用CPU一条一条去下，速度要快一倍，大大提高了路由下发效率，有利于路由的快速收敛，同时也能够提升低掩码的路由容量。
本发明实施例还提供一种通过硬件发包机制提升路由下发效率的系统，包括：
配置模块，其用于：将待配置的低掩码路由映射到硬件发包器的数据包内容中；
微码模块，其用于：通过硬件发包器将所述低掩码路由下发至DRAM中。
优选的，所述低掩码路由为第1至24位掩码的IPV4路由或小于等于64位掩码的IPv6路由。
作为本发明实施例的其中一种实施方式，所述配置模块具体用于：
对于掩码长度小于/等于16位的IPv4路由或掩码长度小于/等于56位的Ipv6路由，根据该路由对应的路由操作修改IP查找树；
遍历软件同步表的第一级的下一跳索引中该条路由覆盖地址段，对上述地址段中的每一个地址，反向计算出地址IP的前16/56位作为KEY，在IP查找树中查找KEY对应的路由项；
比较在IP查找树中找到的路由项与软件同步表中记录的路由项是否存在差异；
若存在差异，根据IP查找树中找到的路由项更新软件同步表中的下一跳索引的路由项值，并将需要更新的下一跳索引、以及对应的软件同步表的第一级的地址，配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
作为本发明实施例的优选实施方式，所述配置模块具体还用于：
对于掩码长度大于16位的IPv4路由或掩码长度大于56位的Ipv6路由，以IPv4/Ipv6路由地址的前16/56位进行哈希运算得到一个地址作为软件同步表的第二级的地址索引，保存到软件同步表的第一级中；
若第二级的地址索引无效，建立第一级对应的软件同步表的第二级块，从IP查找树中恢复出当前路由地址的原始第二级块数据填入新建的第二级块；
根据该路由对应的路由操作修改IP查找树；
通过当前路由地址和掩码长度计算出该路由在软件同步表的第二级块中所覆盖的地址段；
遍历上述地址段，对上述地址段中的每一个地址，结合第二级的地址索引反向计算出完整IP，采用该IP作为KEY，在IP查找树中进行最长匹配查找；
比较在IP查找树中找到的路由项与软件同步表的第二级块中记录的路由项是否存在差异；
若存在差异，将第一级中保存的第二级的索引地址、需要更新的下一跳索引配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
作为本发明实施例的其中一种实施方式，所述微码模块具体用于：
判断IPV4路由掩码长度是否小于等于16或IPV6路由掩码长度是否小于等于56位；
如果为是，提取报文头部中第一级的地址和第一级的下一跳索引，将发包个数控制器的计数值加上第一级的地址，将第一级的下一跳索引更新至各地址对应的DRAM路由表项；
如果为否，将IPV4路由的IP头部的前16位或IPV6路由的IP头部的前56位进行地址查找，获取第一级的下一跳索引和第二级的地址索引；通过低8位地址加上第二级的地址索引进行地址查找，获取第二级的下一跳索引，如果查找到的第二级的下一跳索引有效，采用该第二级的下一跳索引作为需更新的下一跳索引；如果查找到的第二级的下一跳索引无效，采用第一级的下一跳索引作为需更新的下一跳索引；提取报文头部中第二级的基地址，将发包个数控制器的计数值加上第二级的基地址，将需更新的下一跳索引更新至各地址对应的DRAM路由表项。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种通过硬件发包机制提升路由下发效率的方法，其特征在于，包括以下步骤：
将待配置的低掩码路由映射到硬件发包器的数据包内容中，
通过硬件发包器将所述低掩码路由下发至DRAM中。
2.如权利要求1所述的方法，其特征在于，
所述低掩码路由为长度为1至24位掩码的IPV4路由或长度小于等于64位掩码的IPv6路由。
3.如权利要求2所述的方法，其特征在于，将待配置的低掩码路由映射到硬件发包器的数据包内容中，具体包括以下步骤：
对于掩码长度小于/等于16位的IPv4路由或掩码长度小于/等于56位的Ipv6路由，根据该路由对应的路由操作修改IP查找树；
遍历软件同步表的第一级的下一跳索引中该条路由覆盖地址段，对上述地址段中的每一个地址，反向计算出地址IP的前16/56位作为KEY，在IP查找树中查找KEY对应的路由项；
比较在IP查找树中找到的路由项与软件同步表中记录的路由项是否存在差异；
若存在差异，根据IP查找树中找到的路由项更新软件同步表中的下一跳索引的路由项值，并将需要更新的下一跳索引、以及对应的软件同步表的第一级的地址，配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
4.如权利要求3所述的方法，其特征在于，将待配置的低掩码路由映射到硬件发包器的数据包内容中，具体还包括以下步骤：
对于掩码长度大于16位的IPv4路由或掩码长度大于56位的Ipv6路由，以IPv4/Ipv6路由地址的前16/56位进行哈希运算得到一个地址作为软件同步表的第二级的地址索引，保存到软件同步表的第一级中；
若第二级的地址索引无效，建立第一级对应的软件同步表的第二级块，从IP查找树中恢复出当前路由地址的原始第二级块数据填入新建的第二级块；
根据该路由对应的路由操作修改IP查找树；
通过当前路由地址和掩码长度计算出该路由在软件同步表的第二级块中所覆盖的地址段；
遍历上述地址段，对上述地址段中的每一个地址，结合第二级的地址索引反向计算出完整IP，采用该IP作为KEY，在IP查找树中进行最长匹配查找；
比较在IP查找树中找到的路由项与软件同步表的第二级块中记录的路由项是否存在差异；
若存在差异，将第一级中保存的第二级的索引地址、需要更新的下一跳索引配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
5.如权利要求4所述的方法，其特征在于，通过硬件发包器将所述低掩码路由下发至DRAM中，具体包括以下步骤：
判断IPV4路由掩码长度是否小于等于16或IPV6路由掩码长度是否小于等于56位；
如果为是，提取报文头部中第一级的地址和第一级的下一跳索引，将发包个数控制器的计数值加上第一级的地址，将第一级的下一跳索引更新至各地址对应的DRAM路由表项；
如果为否，将IPV4路由的IP头部的前16位或IPV6路由的IP头部的前56位进行地址查找，获取第一级的下一跳索引和第二级的地址索引；通过低8位地址加上第二级的地址索引进行地址查找，获取第二级的下一跳索引，如果查找到的第二级的下一跳索引有效，采用该第二级的下一跳索引作为需更新的下一跳索引；如果查找到的第二级的下一跳索引无效，采用第一级的下一跳索引作为需更新的下一跳索引；提取报文头部中第二级的基地址，将发包个数控制器的计数值加上第二级的基地址，将需更新的下一跳索引更新至各地址对应的DRAM路由表项。
6.一种通过硬件发包机制提升路由下发效率的系统，其特征在于，包括：
配置模块，其用于：将待配置的低掩码路由映射到硬件发包器的数据包内容中；
微码模块，其用于：通过硬件发包器将所述低掩码路由下发至DRAM中。
7.如权利要求6所述的系统，其特征在于，
所述低掩码路由为第1至24位掩码的IPV4路由或小于等于64位掩码的IPv6路由。
8.如权利要求7所述的系统，其特征在于，所述配置模块具体用于：
对于掩码长度小于/等于16位的IPv4路由或掩码长度小于/等于56位的Ipv6路由，根据该路由对应的路由操作修改IP查找树；
遍历软件同步表的第一级的下一跳索引中该条路由覆盖地址段，对上述地址段中的每一个地址，反向计算出地址IP的前16/56位作为KEY，在IP查找树中查找KEY对应的路由项；
比较在IP查找树中找到的路由项与软件同步表中记录的路由项是否存在差异；
若存在差异，根据IP查找树中找到的路由项更新软件同步表中的下一跳索引的路由项值，并将需要更新的下一跳索引、以及对应的软件同步表的第一级的地址，配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
9.如权利要求8所述的系统，其特征在于，所述配置模块具体还用于：
对于掩码长度大于16位的IPv4路由或掩码长度大于56位的Ipv6路由，以IPv4/Ipv6路由地址的前16/56位进行哈希运算得到一个地址作为软件同步表的第二级的地址索引，保存到软件同步表的第一级中；
若第二级的地址索引无效，建立第一级对应的软件同步表的第二级块，从IP查找树中恢复出当前路由地址的原始第二级块数据填入新建的第二级块；
根据该路由对应的路由操作修改IP查找树；
通过当前路由地址和掩码长度计算出该路由在软件同步表的第二级块中所覆盖的地址段；
遍历上述地址段，对上述地址段中的每一个地址，结合第二级的地址索引反向计算出完整IP，采用该IP作为KEY，在IP查找树中进行最长匹配查找；
比较在IP查找树中找到的路由项与软件同步表的第二级块中记录的路由项是否存在差异；
若存在差异，将第一级中保存的第二级的索引地址、需要更新的下一跳索引配置到硬件发包器中；
根据当前路由掩码长度覆盖的地址范围，配置硬件发包器的发包个数。
10.如权利要求9所述的系统，其特征在于，所述微码模块具体用于：
判断IPV4路由掩码长度是否小于等于16或IPV6路由掩码长度是否小于等于56位；
如果为是，提取报文头部中第一级的地址和第一级的下一跳索引，将发包个数控制器的计数值加上第一级的地址，将第一级的下一跳索引更新至各地址对应的DRAM路由表项；
如果为否，将IPV4路由的IP头部的前16位或IPV6路由的IP头部的前56位进行地址查找，获取第一级的下一跳索引和第二级的地址索引；通过低8位地址加上第二级的地址索引进行地址查找，获取第二级的下一跳索引，如果查找到的第二级的下一跳索引有效，采用该第二级的下一跳索引作为需更新的下一跳索引；如果查找到的第二级的下一跳索引无效，采用第一级的下一跳索引作为需更新的下一跳索引；提取报文头部中第二级的基地址，将发包个数控制器的计数值加上第二级的基地址，将需更新的下一跳索引更新至各地址对应的DRAM路由表项。
CN202010544458.9A 2020-06-15 2020-06-15 一种通过硬件发包机制提升路由下发效率的方法及系统 Active CN111865804B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010544458.9A CN111865804B (zh) 2020-06-15 2020-06-15 一种通过硬件发包机制提升路由下发效率的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010544458.9A CN111865804B (zh) 2020-06-15 2020-06-15 一种通过硬件发包机制提升路由下发效率的方法及系统

Publications (2)

Publication Number Publication Date
CN111865804A true CN111865804A (zh) 2020-10-30
CN111865804B CN111865804B (zh) 2022-03-11

Family

ID=72987400

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010544458.9A Active CN111865804B (zh) 2020-06-15 2020-06-15 一种通过硬件发包机制提升路由下发效率的方法及系统

Country Status (1)

Country Link
CN (1) CN111865804B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268608A (zh) * 2021-12-20 2022-04-01 卓米私人有限公司 一种地址段检索方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1561050A (zh) * 2004-02-20 2005-01-05 三层转发信息下发硬件lpm表的方法
CN105721303A (zh) * 2016-03-31 2016-06-29 华为技术有限公司 一种路由控制方法、网络设备及控制器
CN108337172A (zh) * 2018-01-30 2018-07-27 长沙理工大学 大规模OpenFlow流表分级存储架构与加速查找方法
US20190057063A1 (en) * 2016-04-22 2019-02-21 Cambricon Technologies Corporation Limited Appartus and methods for submatrix operations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1561050A (zh) * 2004-02-20 2005-01-05 三层转发信息下发硬件lpm表的方法
CN105721303A (zh) * 2016-03-31 2016-06-29 华为技术有限公司 一种路由控制方法、网络设备及控制器
US20190057063A1 (en) * 2016-04-22 2019-02-21 Cambricon Technologies Corporation Limited Appartus and methods for submatrix operations
CN108337172A (zh) * 2018-01-30 2018-07-27 长沙理工大学 大规模OpenFlow流表分级存储架构与加速查找方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268608A (zh) * 2021-12-20 2022-04-01 卓米私人有限公司 一种地址段检索方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN111865804B (zh) 2022-03-11

Similar Documents

Publication Publication Date Title
US6434144B1 (en) Multi-level table lookup
US6862287B2 (en) Method and apparatus for a four-way hash table
US7630373B2 (en) Packet transfer apparatus
EP1623347B1 (en) Comparison tree data structures and lookup operations
US6665297B1 (en) Network routing table
US7774538B2 (en) Method for ternary contents address memory table management
TW468116B (en) High speed Internet protocol address lookups method for saving memory
US7418505B2 (en) IP address lookup using either a hashing table or multiple hash functions
US8880507B2 (en) Longest prefix match using binary search tree
US20070171911A1 (en) Routing system and method for managing rule entry thereof
US7630367B2 (en) Approach for fast IP address lookups
US20040230583A1 (en) Comparison tree data structures of particular use in performing lookup operations
US9049157B1 (en) Method and device for improving scalability of longest prefix match
JP2000196670A (ja) 高速検索方法及び高速検索装置
US10515015B2 (en) Hash table-based mask length computation for longest prefix match caching
WO2001005116A2 (en) Routing method and apparatus
CN107528783A (zh) 利用对前缀长度进行两个搜索阶段的ip路由缓存
US7478109B1 (en) Identification of a longest matching prefix based on a search of intervals corresponding to the prefixes
US20040044868A1 (en) Method and apparatus for high-speed longest prefix match of keys in a memory
CN111865804B (zh) 一种通过硬件发包机制提升路由下发效率的方法及系统
US7299317B1 (en) Assigning prefixes to associative memory classes based on a value of a last bit of each prefix and their use including but not limited to locating a prefix and for maintaining a Patricia tree data structure
CN105227468B (zh) 一种查找装置、查找方法和配置方法
US20050114393A1 (en) Dynamic forwarding method using binary search
CN110995876B (zh) 一种ip存储与查找的方法及装置
JP2006246488A (ja) ネットワーク・ルータ、アドレス処理方法及びコンピュータ・プログラム

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
GR01 Patent grant
GR01 Patent grant