网络设备及网络设备内查询数据的方法
【专利摘要】本发明提供一种网络设备及一种网络设备内查询数据的方法，该网络设备包含：哈希存储器，包含多个哈希表，其中每个哈希表包含多个条目，且每个哈希表中的每个条目包含签名栏及钥匙栏；控制器，用于映射搜寻钥匙至所述多个哈希表的多个条目，并基于所述多个哈希表中所映射的每个所述条目的所述签名栏与所述钥匙栏，对所述搜寻钥匙执行最长前缀匹配操作。本发明能够在哈希表内避免冲突，并高效地用哈希表来查询IP地址。
【专利说明】
网络设备及网络设备内查询数据的方法
技术领域
[0001]本发明关于一种网络设备，更明确地，关于一种支持最长前缀匹配(longest prefix matching，LPM)的采用哈希存储器架构的网络设备。【背景技术】
[0002]随着连接到网络设备的装置越来越多，数据率的要求也越来越高，支持更高传输率的新技术的需求日渐增多。针对此种情况，产业多方都在努力开发，包含甚至能让传输率超过每秒上Gbps的数据率的技术。举例来说，IEEE 802.3标准分别定义了数据传输率分别在 10Mbps、100Mbps、lGbps以及lOGbps的媒体存取控制(Medium Access Control，MAC)接口以及物理层(PHY)的双绞缆线的以太网连接。如此，随着数据率因为lGbps与lOGbps的以太网交换机的广泛部署，快速IP地址查询对于核心路由器及边缘路由器变得不可或缺。
[0003]同时，在核心路由器中的前缀的数量也经历了爆炸式的增长。IP地址查询的早期解决方案是通过软件指令来一次几比特地逐步匹配IP地址。如此，前缀都储存在树状的数据结构中来支持最长前缀匹配，其是指从匹配给定的IP地址选择最长的前缀。另外，哈希表对快速IP查询提供了一个具有吸引力的方法，因为其恒定的时间查询延迟。哈希表还因为其可用在普通的SRAM中具有吸引力。因为SRAM较便宜，更节能，并且比三态内容寻址储存器 (TCAM)密度更高。可是，哈希表不能记录具有“不关心(don’t care)”比特的条目，且数据冲突可能发生在哈希表中。因此，在执行IP查询时使用哈希表效率不高。
【发明内容】
[0004]因此，本发明为了解决哈希表在执行IP查询时的效率不高的技术问题，特提供一种新的网络设备以及网络设备内查询数据的方法。
[0005]本发明的一个实施例提供一种网络设备，包含:哈希存储器，包含多个哈希表，其中每个哈希表包含多个条目，且每个哈希表中的每个条目包含签名栏及钥匙栏;控制器，用于映射搜寻钥匙至所述多个哈希表的多个条目，并基于所述多个哈希表中所映射的每个所述条目的所述签名栏与所述钥匙栏，对所述搜寻钥匙执行最长前缀匹配操作。
[0006]本发明另一个实施例提供一种网络设备内查询数据的方法，包含:提供具有多个哈希表的哈希存储器，其中每个所述哈希表包含多个条目，且每个所述哈希表中的每个所述条目包含签名栏与钥匙栏;映射搜寻钥匙至所述多个哈希表的多个条目；以及基于所述多个哈希表中所映射的每个条目的所述签名栏与所述钥匙栏，对所述搜寻钥匙执行最长前缀匹配操作。
[0007]本发明能够在哈希表内避免冲突，并高效地用哈希表来查询IP地址。
[0008]本发明的这些及其他的目的对于本领域的技术人员来说，在阅读了下述优选实施例的详细说明以后是很容易理解和明白的，所述优选实施例通过多幅图予以揭示。【附图说明】
[0009]图1是根据本发明一实施例的网络设备的方框示意图。
[0010]图2是根据本发明一实施例的哈希条目的格式示意图。
[0011]图3根据本发明一实施例的执行LPM操作时哈希存储器中执行搜寻操作的示意图。
[0012]图4A是根据本发明一实施例的执行LPM时哈希存储器中的插入操作的示意图。 [〇〇13]图4B是根据本发明的另一实施例的执行LPM时哈希存储器中的插入操作的示意图。
[0014]图5是根据本发明一实施例的网络设备的搜寻数据的方法流程图。【具体实施方式】
[0015]本说明书及权利要求书使用了某些词语代指特定的组件。本领域的技术人员可理解的是，制造商可能使用不同的名称代指同一组件。本文件不通过名字的差别，而通过功能的差别来区分组件。在以下的说明书和权利要求书中，词语“包括”是开放式的，因此其应理解为“包括，但不限于...”。
[0016]图1是根据本发明一实施例的网络设备的方框示意图。网络设备100包含哈希计算单元110,控制器120,哈希存储器130,三态内容寻址存储器(ternary content addressable memory，TCAM) 140。哈希计算单元110使用哈希函数，其可将MAC地址或IP地址转换为哈希存储器130中的对应最长前缀匹配(LPM)哈希码。举例来说，哈希计算单元110可通过一个微控制器、处理器或集成电路来实施。哈希存储器130包含支持网络数据包的大多数前缀的多个哈希表，哈希钥匙(hash key)的长度是可配置的。而且，每个哈希条目的匹配长度也是可配置的。因为网络数据包的前缀的长度可以根据一些特定长度统计，因此具有同样长度的前缀可被存储在同一个哈希表中。控制器120可在哈希表130及TCAM140中查询数据。TCAM140可储存哈希存储器130中前缀有冲突的条目，或者是不被哈希存储器130中的哈希表所支持的条目。[0〇17] 在一实施例中，当哈希计算单元110接收到MAC地址，控制器120可首先基于哈希计算单元110得到的哈希码来查询哈希存储器130。如果哈希操作“命中”哈希存储器130中的至少一条目，控制器120可报告该“命中”结果及条目的长度。如果哈希存储器130发生“错失”，控制器120可启用TCAM140来进行后续数据搜寻。较佳地，TCAM140能被划分为多个存储库，例如存储库141?144,每个存储库可记录具有特定范围内的长度的条目。举例来说，存储库144可记录具有0比特到8比特的长度的条目。存储库143可记录具有9比特到16比特的长度的条目。存储库142可记录具有17比特到24比特的长度的条目。最后，存储库141可记录具有大于24比特的长度的条目。需要注意的是，每个存储库记录的条目的长度可基于实际条件进行调整。较佳地，TCAM140的存储库141?144设计来涵盖不同长度的条目的前缀。 [〇〇18]图2是根据本发明一实施例的哈希条目200的格式示意图。哈希条目200可包含签名栏230,以及钥匙栏240。举例来说，签名栏230可表示不同的旗标(flags)，例如长度，优先级，或“不关心”掩码。钥匙栏240表示的数据是哈希存储器130和/或TCAM140中在条目查询流程中用来比较的数据，其可为IP地址。另外，哈希条目200也可进一步包含有效栏210与数据栏220。有效栏210指示哈希条目200是有效的还是无效的。数据栏220指示哈希条目200的对应数据，例如输出端口号码或特定操作。
[0019]举例来说，当签名栏230表示“长度”，条目200包含长度信息(例如数据中最高比特)来支持LPM功能。当签名栏230表示条目的“优先级”以及要搜寻多个条目时，具有最高优先级的条目会被选择为查询的结果。当签名栏230表示“不关心掩码”时，数据栏220中的数据的每个比特都可在签名栏230中具有一对应掩码比特。举例来说，当签名栏中的最高比特是“1”时，当对掩码哈希钥匙(masked hash key)与数据栏220中的数据执行数据比较时，在数据栏220中对应的最高比特会被忽略。当签名栏230中的最高比特是“0”时，数据栏220中的对应最高比特未被掩码(masked)。本领域内技术人员可了解在签名栏230及数据栏220对应比特中使用掩码比特，本发明并不限于前述的实施例。
[0020]在本实施例中，请参考图1及图2,当控制器120不能在哈希存储器130中找到该数据时，控制器120可继续在TCAM140中进行搜寻。当控制器120能够在哈希存储器中找到该数据时，后续在TCAM140中的搜寻就针对具有更长长度的条目。举例来说，当在哈希存储器130 中命中24比特的条目(例如第一搜寻结果)时，后续的搜寻就在记录的条目长度超过24比特的存储库(例如本实施例中的存储库141)中执行。当在TCAM140的存储库中进行的后续搜寻并没有命中任何条目，哈希存储器130的LPM结果确定为最终LPM结果。当TCAM140的存储库中的后续搜寻命中一个条目(例如第二搜寻结果)，最终LPM结果会基于在搜寻的条目的记录在签名栏230中的长度或优先级来根据是从TCAM140来的搜寻条目的数据或是根据从哈希存储器130来的数据被确定。也就是说，具有更高的优先级或是更长长度的搜寻的条目会被确定为LPM结果。
[0021]图3根据本发明一实施例的执行LPM操作时哈希存储器中执行搜寻操作的示意图。 该32比特的搜寻钥匙300表示IP地址“163.25.133.134”。第一掩码搜寻钥匙“163.25.0.0” 是用输入IP数据包300通过利用16比特掩码从哈希计算单元310获得，第二掩码搜寻钥匙 “163.25.133.0”是使用24比特掩码通过哈希计算单元320获得。第一掩码搜寻钥匙更进一步用来在哈希表330中搜寻条目，而第二掩码搜寻钥匙更进一步在哈希表340中搜寻条目。 举例来说，当哈希计算单元310确定第一掩码搜寻钥匙时，选择哈希表330中的存储桶 (bucket) 332。类似地，当哈希计算单元320确定第二掩码搜寻钥匙，选择哈希表340中的存储桶342。[〇〇22]并且，哈希表330中的存储桶332中有两个存储槽334及336,这两个存储槽334及 336中的两个条目在签名栏具有不同数值16和17,其表示执行LPM的长度。控制器120比较16 比特掩码搜寻钥匙“163.25.0.0”与存储槽334的钥匙栏中的数据“163.25.0.0”，且比较17 比特掩码搜寻钥匙“163.25.128.0”与存储槽336的钥匙栏中的数据“163.25.128.0”。可是， 控制器120可确定存储槽334与336中的比较结果都是“命中”。然后，控制器120可选择存储槽336中储存的条目作为哈希表330的查询结果，因为存储槽336中比较的数据长度比存储槽334的长。[〇〇23]类似地，哈希表340中的存储桶342中有两个存储槽344及346,这两个存储槽334及 336中的两个条目在签名栏具有相同数值24,其表示执行LPM的长度。控制器120比较24比特掩码搜寻钥匙“163.25.133.0”与存储槽344的签名栏中的数据“163.25.133.0”，且比较24 比特掩码搜寻钥匙“163.25.133.0”与存储槽346的签名栏中的数据“140.25.128.0”。然后， 控制器120可确定存储槽344的比较结果是“命中”，因为24比特搜寻钥匙“163.25.133.0”与存储槽344的签名栏中的数据“163.25.133.0”相匹配。控制器120可选择存储槽344中储存的条目作为哈希表340的查询结果。
[0024]需要注意的是，第一掩码哈希钥匙“163.25.0.0”与第二掩码哈希钥匙 “163.25.133.0”分别用来计算哈希数值并确定要选择哈希表330与340中的哪个存储桶。当执行LPM时，比较的数据长度用哈希表330及340中的选择的存储桶的每个存储槽的签名栏中的长度数值来确定。为了简便起见，前述的掩码哈希钥匙、掩码搜寻钥匙，以及每个条目的钥匙栏的数据都是遵循IPv4格式，但本发明并不限制于此。举例来说，IPv4的搜寻钥匙 (例如IP地址)的前缀长度是32比特，IPv6的搜寻钥匙(例如IP地址)的前缀长度是128比特。 [〇〇25] 而且，控制器120可进一步确定从哈希表330及340中选择哪个查询结果。因为哈希表340中的数据比较长度比哈希表330中的长，控制器120可确定将哈希表340的查询结果作为最终LPM结果。也就是说，具有更高优先级/更长长度的查询结果会被控制器120选择。
[0026]图4A是根据本发明一实施例的执行LPM时哈希存储器中的插入操作的示意图。当在哈希存储器130的哈希表中构造条目时，控制器120可确定是否一个进入的条目400已经在哈希表中记录。举例来说，哈希表330的存储桶332中的存储槽334与336已经被不同的条目所充满。当进入的条目400要被插入到哈希表330及340中的一个时，哈希计算单元310与 320仍然在计算分别被映射到哈希表330与340中的第一掩码哈希钥匙与第二掩码哈希钥匙。哈希计算的细节可参考图3的实施例。然后，控制器120可比较进入的条目400与非空的存储槽334、336及346中的条目。控制器120可确定存储槽334、336及346中的任何一个钥匙栏是否匹配一个对应的掩码搜寻钥匙。举例来说，存储槽334中要进行匹配钥匙栏的插入的条目的掩码钥匙栏的数据是“163.25.0.0”，而存储槽336中要进行匹配钥匙栏的插入的条目的掩码钥匙栏的数据是“163.25.128.0”。如图4A所示，存储槽334中的钥匙栏是 “163.25.0.0”，其与插入的条目“163.25.0.0”的掩码钥匙栏是同样的。可是，控制器120仍然确定进入的条目并不匹配存储槽334中的条目，因为记录在该两个条目中的签名栏的前缀长度数值是不同的。类似地，控制器120确定进入的条目不匹配存储槽336与346中的条目。也就是说，进入的条目并没有记录在哈希表330与340中，进入的条目可记录在映射的存储桶中的一个空的存储槽中，例如存储槽344中。
[0027]图4B是根据本发明的另一实施例的执行LPM时哈希存储器中的插入操作的示意图。在图4B中的插入操作与图4A中的类似。图4B与图4A中的区别在于图4B中的映射的存储桶332与342中的存储槽334、336、344、及346已充满条目。可是，进入的条目410的签名栏记录的长度为8比特，哈希计算单元310与320不会计算进入条目的哈希码，因为要比较的条目长度比哈希计算单元310及320中的掩码长度要短。于是，控制器120可确定进入条目410的插入操作失败。另外，控制器120可将进入的条目储存到TCAM140中以进行后续查询操作。
[0028]图5是根据本发明一实施例的网络设备的搜寻数据的方法流程图。在步骤S510中， 提供具有多个哈希表的哈希存储器，其中每个哈希表包含多个条目，并且每个哈希表中的每个条目具有一签名栏，与一钥匙栏。在步骤S520中，一搜寻钥匙被映射到哈希表的其中一个条目。在步骤S530中，基于映射的哈希表的条目的签名栏，对该搜寻钥匙执行最长前缀匹配(LPM)操作。
[0029]本领域的技术人员将注意到，在获得本发明的指导之后，可对所述装置和方法进行大量的修改和变换。相应地，上述公开内容应该理解为，仅通过所附加的权利要求的界限来限定。
【主权项】
1.一种网络设备，包含:哈希存储器，包含多个哈希表，其中每个哈希表包含多个条目，且每个哈希表中的每个 条目包含签名栏及钥匙栏；控制器，用于映射搜寻钥匙至所述多个哈希表的多个条目，并基于所述多个哈希表中 所映射的每个所述条目的所述签名栏与所述钥匙栏，对所述搜寻钥匙执行最长前缀匹配操 作。2.如权利要求1的网络设备，其特征在于，所述签名栏表示所述多个哈希表中每个条目 的前缀的长度。3.如权利要求1的网络设备，其特征在于，所述签名栏表示所述多个哈希表中每个条目 的优先级。4.如权利要求1的网络设备，其特征在于，所述签名栏表示用于掩码所述搜寻钥匙中对 应比特的掩码比特。5.如权利要求1的网络设备，其特征在于，每个所述哈希表中的每个条目更包含指示每 个条目是否有效的有效栏。6.如权利要求1的网络设备，其特征在于，更包含:多个哈希计算单元，每个所述哈希计算单元用于计算掩码搜寻钥匙，其中所述控制器 基于所述搜寻钥匙定位所述映射条目；以及三态内容寻址存储器，包含多个存储库，其中每个存储库记录长度在特定范围内的条目。7.如权利要求6所述的网络设备，其特征在于，其中当没有最长前缀匹配的搜寻结果被 从所述映射哈希表得到时，所述控制器更进一步在所述三态内容寻址存储器中查询所述搜 寻钥匙。8.如权利要求6所述的网络设备，其特征在于，当从所述多个哈希表获得最长前缀匹配 的第一搜寻结果时，所述控制器更进一步基于所述第一搜寻结果，在所述三态内容寻址存 储器的所述一个或多个存储库中查找所述搜寻钥匙，其中当从所述三态内容寻址存储器获得最长前缀匹配的第二搜寻结果时，所述存储器 更进一步基于所述第一搜寻结果的所述签名栏及所述第二搜寻结果的所述签名栏，确定所 述第一搜寻结果或所述第二搜寻结果为所述最长前缀匹配结果。9.如权利要求6所述的网络设备，其特征在于，所述控制器更比较所述掩码搜寻钥匙与 所述钥匙栏中的数据，且所述控制器更在所述掩码搜寻钥匙匹配所述钥匙栏中的所述数据 时选择所述钥匙栏中的所述数据。10.如权利要求1所述的网络设备，其特征在于，所述搜寻钥匙是IP地址或MAC地址。11.如权利要求1所述的网络设备，其特征在于，每个所述多个哈希表中的每个所述条 目更包含数据栏，其表示每个所述条目的输出端口数量或特定操作。12.—种网络设备内查询数据的方法，包含:提供具有多个哈希表的哈希存储器，其中每个所述哈希表包含多个条目，且每个所述 哈希表中的每个所述条目包含签名栏与钥匙栏；映射搜寻钥匙至所述多个哈希表的多个条目；以及基于所述多个哈希表中所映射的每个条目的所述签名栏与所述钥匙栏，对所述搜寻钥匙执行最长前缀匹配操作。13.如权利要求12所述的网络设备内查询数据的方法，其特征在于，所述签名栏表示所 述多个哈希表中的每个条目的前缀的长度。14.如权利要求12所述的网络设备内查询数据的方法，其特征在于，所述签名栏表示所 述多个哈希表中每个条目的优先级。15.如权利要求12所述的网络设备内查询数据的方法，其特征在于，所述签名栏表示用 于掩码所述搜寻钥匙的对应比特的掩码比特。16.如权利要求12所述的网络设备内查询数据的方法，其特征在于，每个所述哈希表中 的每个条目更包含表示所述每个条目是否有效的有效栏。17.如权利要求12所述的网络设备内查询数据的方法，其特征在于，更包含:计算掩码搜寻钥匙；基于所述掩码搜寻钥匙获得所述映射的哈希表；以及将在所述多个哈希表内具有前缀冲突的条目或是具有所述多个哈希表不支持的前缀， 储存进所述网络设备的三态内容寻址存储器。18.如权利要求17所述的网络设备内查询数据的方法，其特征在于，更包含:当从所述映射的哈希表没有获得搜寻结果来执行最长前缀匹配时，在所述三态内容寻 址存储器中查询所述搜寻钥匙。19.如权利要求17所述的网络设备内查询数据的方法，其特征在于，更包含:当从所述映射的哈希表中获得最长前缀匹配的第一搜寻结果时，基于所述第一搜寻结 果的长度，通过在所述三态内容寻址存储器中查询所述搜寻钥匙来提供第二搜寻结果；以 及当最长前缀匹配的所述第二搜寻结果是从所述三态内容寻址存储器获得时，基于所述 第一搜寻结果的所述签名栏与所述第二搜寻结果的所述签名栏，确定所述第一搜寻结果或 所述第二搜寻结果为所述最长前缀匹配结果。20.如权利要求17所述的网络设备内查询数据的方法，其特征在于，更包含:在所述掩码搜寻钥匙与所述钥匙栏中的数据之间执行最长前缀匹配；以及当所述掩码搜寻钥匙匹配所述签名栏中的所述数据时，选择所述钥匙栏中的所述数 据。21.如权利要求12所述的网络设备内查询数据的方法，其特征在于，所述搜寻钥匙是IP 地址或MAC地址。22.如权利要求12所述的网络设备内查询数据的方法，其特征在于，每个所述多个哈希 表的每个所述条目更包含数据栏，其表示每个所述条目的输出端口的数量或特定操作。
【文档编号】H04L12/743GK105978814SQ201610140421
【公开日】2016年9月28日
【申请日】2016年3月11日
【发明人】朱峻源, 陈俊宏, 林恕平
【申请人】联发科技股份有限公司