专利名称：用于在交换机asic中集成线速应用识别的系统和方法
用于在交换机ASIC中集成线速应用识别的系统和方法
相关专利的交叉引用
本申请主张享有于2011年11月30日提交的美国临时申请第61/565，423号和2011年12月20日提交的美国非临时申请第13/331，542号的优先权，其内容通过对其引用结合于此。技术领域
本发明总体上涉及网络系统，更具体地，涉及用于在交换机ASIC中集成独立的线速应用识别(line-rate application recognition)的系统和方法。
背景技术：
深度数据包检测(DPI)系统能够实现复杂的服务，诸如入侵检测、流整形和负载平衡。这样的DPI系统的关键元件是被设计为将数据包有效载荷与多个已知签名的签名匹配引擎。日益提高的网络速度使得DPI系统为了满足这种提高的性能要求而负担增加。迄今为止，现有的解决方案需要添加昂贵的外部处理器，通常带有专门的加速器硬件。因此，所需要的是能够以有效且经济的方式执行线速应用识别的DPI系统和方法。发明内容
作为在权利要求中更完整阐述的用于在交换机ASIC中集成的线速应用识别的系统和/或方法，基本上如附图中的至少一个所示和/或结合附图中的至少一个所描述。
(I) 一种在交换机ASIC中具有集成的线速应用识别的交换机，包括:
流跟踪器会话表，所述流跟踪器会话表具有多个条目，所述多个条目中的每一个与独特的数据包流关联，其中，至少基于共用源以及由多个数据包共享的目的地址来区分数据包流；
流跟踪器，审阅在入口管道进入所述交换机的数据包，在识别出要被跟踪的新的数据包流时，所述流跟踪器在所述流跟踪器会话表中创建条目，所述流跟踪器审阅与识别出的所述流相关联的数据包并生成将连同经审阅的所述数据包被转发至所述交换机中的存储器管理单元的流信息，所述流信息包括标识经审阅的所述数据包关联的特定数据包流的流指数；以及
签名匹配弓丨擎，从所述交换机中的所述存储器管理单元接收经审阅的所述数据包和所述流信息，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查经审阅的所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发生至所述入口管道的响应数据包中，
其中，所述流跟踪器使用在所述入口管道接收的所述响应数据包中包含的流指数来更新所述流跟踪器会话表中的条目，以表明要施加到由所述流跟踪器审阅的后续数据包的策略，所述后续数据包与所述流跟踪器会话表中的所述条目关联的流相关。
( 2)根据(I)所述的交换机，其中，基于源地址、目的地址、源端口、目的端口和协议来识别数据包流。
(3)根据(I)所述的交换机，其中，所述流跟踪器会话表位于能够看到双向流中的所有数据包的位置。
(4)根据(I)所述的交换机，其中，在多个管道中共享所述流跟踪器会话表。
(5)根据(I)所述的交换机，其中，所述签名匹配引擎包含在与出口管道分离的辅助管道中。
(6)根据(I)所述的交换机，其中，所述表达式匹配状态机是确定有限状态自动机状态机。
(7)根据(I)所述的交换机，其中，所述响应数据包包括标识应当应用于流中的数据包的策略的策略指数。
(8) 一种用于执行数据包检测的交换机，包括:
入口管道，所述入口管道包括审阅在所述入口管道进入交换机的数据包的流跟踪器，在识别出要被跟踪的新的数据包流时，所述流跟踪器在流跟踪器会话表中创建条目，所述流跟踪器审阅与所述新的数据包流相关联的其它数据包并生成将连同经审阅的所述数据包被转发至所述交换机中的存储器管理单元的流信息，所述流信息包括标识经审阅的所述数据包关联的特定数据包流的流指数；以及
耦接至所述存储器管理单元的辅助管道，所述辅助管道与同样耦接至所述存储器管理单元的出口管道分离，所述辅助管道包括签名匹配引擎，所述签名匹配引擎从所述交换机中的所述存储器管理单元接收经审阅的所述数据包和所述流信息，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查经审阅的所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发送至所述入口管道中的所述流跟踪器的响应数据包中。
(9)根据(8)所述的交换机，其中，基于源地址、目的地址、源端口、目的端口和协议来识别数据包流。
(10)根据(8)所述的交换机，其中，所述表达式匹配状态机是确定有限状态自动机状态机。
(11)根据(8)所述的交换机，其中，所述响应数据包包括标识应当应用于流中的数据包的策略的策略指数。
(12) 一种用于执行数据包检测的交换机，包括:
耦接至所述交换机中的存储器管理单元的辅助管道，所述辅助管道与同样耦接至所述存储器管理单元的出口管道分离，所述辅助管道包括签名匹配引擎，所述签名匹配引擎从所述交换机中的所述存储器管理单元接收数据包，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发生至所述交换机的入口管道的响应数据包中，其中，所述入口管道中的流跟踪器使用在所述交换机的所述入口管道上接收的所述响应数据包，以对包含在所述响应数据包中的流指数标识的数据包流中的后续数据包应用策略行为。
(13)根据(12)的方法，其中，基于源地址、目的地址、源端口、目的端口和数据包协议来识别数据包流。
(14)根据(12)的方法，其中，所述表达式匹配状态机是确定有限状态自动机状态机。
(15)根据(12)的方法，其中，所述响应数据包包括标识应当应用于流中的数据包的策略的策略指数。
(16)根据(12)的方法，其中，由所述入口管道中的所述流跟踪器将所述数据包转发至所述签名匹配引擎。
(17)根据(12)的方法，其中，在所述流跟踪器和所述签名匹配引擎之间不存在直接连接。
为了描述可以获得本发明的上述和其它优点和特征的手段，将参照附图中所示出的具体实施方式
来呈现以上简要描述的本发明的更具体描述。应理解，这些附图仅描述了本发明的典型实施方式，而不应认为是限制其范围，将通过使用附图以额外的特征和细节来描述和解释本发明，其中:
图1示出示例流跟踪器的组件的框图。
图2示出会话表的实例。
图3示出随着每个数据包被传递至签名匹配引擎的报头中的入口管道生成和出口管道生成字段的实例。
图4示出签名匹配引擎的实施方式。
图5示出数据包缓冲器的实施方式。
图6示出具有四个正则表达式引擎的实例。
图7示出范围值编码布局的实例。
图8示出位图编码布局的实例。
图9示出匹配处理器的实施方式。
图10示出签名匹配数据包流的实例。
图11示出签名匹配流表条目中的字段的实施方式。
图12示出匹配表条目中的字段的实施方式。
图13A至图13C示出结果数据包的示例格式。
图14描述了结果报头中的字段。
图15示出针对数据包的检索策略行为的示例实施方式。
具体实施方式
下面将详细讨论本发明的各种实施例。虽然讨论具体的实现方式，但应理解，这仅是出于说明目的。相关技术领域的技术人员将认识到，在不脱离本发明的精神和范围的情况下，可使用其它组件和配置。
在本发明中，DPI通常是指以下机制，在该机制中，可检查流中的数据包从而确定潜在的应用。可通过在所交换的应用数据的最初2K字节中寻找“揭秘(telltale)”模式来确认几乎所有受关注的应用，虽然有些可能需要更多字节。对于数量较大的应用，不会在单个数据包中发生确凿的数据匹配，而是需要在针对流的多个数据包中匹配模式。
根据本发明，流跟踪能够为具有有效载荷数据的流选择出那些初始数据包，并发送副本以供签名匹配。由于仅对这些采样的数据包执行签名匹配，所以不需要以系统数据包吞吐率进行签名匹配。
根据本发明，DPI可用于扩展常规分类，因为它能够超越L2至L4报头，并针对附加信息而浏览整个数据包。因此，其提供了以下能力:检查有效载荷中的任意字段并将这些字段与最常见应用的已知签名匹配。一旦识别出，则提供通过各种手段(诸如速率计、服务质量排队、重定向、数据包过滤等)监督这些流的能力。
在本发明中，可以通过两个主要单元:签名匹配(SM)引擎和流跟踪器来实现DPI。SM引擎提供检查数据包的有效载荷中的任意字段的能力。这可以作为找寻签名的正则表达式匹配状态机或在具体应用中发现的公共模式来体现，并在找到时表明匹配。一旦流排队等待检查，就可以负责处理和识别流。
由流跟踪器处理流管理和策略行为。因为对于识别应用所需的有效载荷可能不一定包含在单个数据包中，所以需要流跟踪器。因此，提供了一种方法，其用于存储和跟踪构成流的大量的这些数据包组。在操作中，流跟踪器可以将流组合和格式化为字节流，以便可以进行正则表达式匹配。此外，一旦流被分类，流跟踪器就能够提供对这些流进行跟踪并对流的数据包应用行为的手段。
可以将流跟踪器处理分解和分组成下面列出的一组基本功能。
.识别流:解析输入数据包。识别所关注的流
.跟踪流:创建状态条目并保持流状态
.导向数据包以供检测:将数据包转发至SM引擎以供签名匹配
.处理签名匹配结果:获得签名匹配结果、更新策略、CPU通知
.应用行为:对后续数据包应用签名策略行为
.终止流:标识何时应该终止流并不再跟踪流
.报告统计:生成具有统计的记录，并输出到CPU
图1示出流跟踪器的组件和该流跟踪器如何装入交换机结构核心芯片100的管道结构中的框图。如图所示，流跟踪器110可以分解为两个主要结构:流跟踪器会话表112和流跟踪器策略表114。正如其名称所暗示的，会话表112可负责识别和保持流的状态，而策略表114可负责一旦流已被分类即对它们应用行为。会话表112可保持关于流的所有信息，包括键标、状态、计数器和策略指数。策略表114可保持一旦流已被分类即可应用到该流中的数据包的行为。这两个表都可位于入口字段处理器(IFP)级中的入口管道。如进一步的说明，流跟踪器会话表112还具有附接的出口 FIF0116，其用于在流已经结束时报告该流的状态和数据包/字节计数器。
SM引擎120可位于辅助管道(AXP)中。在一个实施方式中，在流跟踪器110和SM引擎120之间没有直接的接口。相反，可以通过每个数据包排队的报头来实现流跟踪器110和SM引擎120之间的通信。
流跟踪器会话表可放置在可观察和记录双向流的所有数据包的位置处。在单个管道实现方式中，因为在处理所有数据包时它们都在同一路径流动，所以有很大的灵活性。入口或出口管道的任何位置都会看到双向流中的所有数据包。在多管道的情况下(即，每个管道只能看到针对端口子集的数据包)，在管道间可共享会话表。这保证了两个方向都可以被跟踪。可替换地，会话表被定位使得其能够由入口和出口管道两者访问。在此，并非在流进入芯片时跟踪所有流，而是将跟踪集中在从前面板端口进入的数据包，以及出口至前面板端口的数据包。这是有效的，原因在于双向流的正向和反向路径中的数据包会通过相同的前面板端口。该端口对分组允许来自不同的前面板端口的流被独立地跟踪，并允许用于扩展到多个管道的装置。将会话表分割成更小的组块使得查询带宽增加成比例的量。只要会话表的相同实例(instance)跟踪前面板端口对，会话表就可以被分割成任意数量的组块。
在下面的描述中，使用入口管道中的单个观测点，其中，当所有输入的通信量进入芯片，且在入口管道中应用所有流跟踪行为时，记录所有输入的通信量。应当理解的是，本发明的原理并不限于这种实现方式。
为了说明流跟踪器的流识别功能，考虑检查遵循TCP/UDPL4协议IP的数据包的实例。在此，可通过标准5元组(IP源和目的地址，L4源和目的端口以及IP协议)识别流，并且可以跟踪流达整个连接持续时间。可通过观察数据包(TCP连接)内的标记来检测流创建和终止。连接是双向的，因此可以检测和处理流的两个方向。应注意，虽然以下的说明参照示例TCP/UDP流，但是本发明的原理并不限于这种流类型。
可以每个物理端口或以WLAN虚拟端口为单位来实现流跟踪。可以有不同的配置选项，其可选择地过滤允许哪种类型的数据包创建流跟踪器条目。
流跟踪每端口属性可来自于四个源之一:入口物理端口、出口物理端口、源虚拟端口或目的地虚拟端口。如果四个来源中的任何来源可用，则该流适于进行流创建。
如果输入的数据包在流跟踪端口进入或者如果输入的数据包在流跟踪端口出去，则它们适于进行流跟踪。在一个实例中，跟踪输入或输出前面板端口的流。如果有两个观测点，一个作为数据包在端口上进入的观测点，另一个作为数据包出去该端口的观测点，则可以完成该过程。在一个实施方式中，在入口管道中只使用一个观测点。
在一个实施方式中，可以进行一些预过滤来限制应被考虑以供流跟踪的数据包。该预过滤可容纳有限资源，该有限资源规定多少流可以被跟踪和签名匹配。此外，不需要对每种类型的数据包进行流跟踪。在此，可以应用某些约束以简化实现方式。在一般情况下，流跟踪的范围可考虑SM引擎的能力、流跟踪器的能力以及应被跟踪的受关注的流。
一旦流识别和适当性得到解决，则可以确定何时是适当时间来开始跟踪流。对于TCP连接，检测交换的最初几个数据包通常足以识别基本应用。对于许多签名，进行匹配所需的数据在流中较早发生，并且对于整个流持续时间仅可用一次。为此，针对TCP流的流跟踪可在检测到新的TCP连接开始时启动，该TCP连接的开始由SYN或SYN-ACK数据包表示。对于UDP流，对于流开始没有等效指示符，因此可将看到的第一个数据包视为初始数据包。一旦确定了需要跟踪流，可保持该流的状态，以便按照有序方式进行处理。被创建从而保持针对所有跟踪的流的状态的数据结构称为会话表。
为了识别流过交换机的基本应用，SM引擎需要访问将跨越TCP/UDP流中的多个数据包的数据。在本发明中，构造可识别输入TCP/UDP流和存储其状态的数据结构。来自SM引擎的、关于所识别的流的签名匹配结果也存储并应用至已识别的流的后续数据包。标准5元组可用于识别流并作为用于索引到会话表的键标。图2示出会话表字段的一个实例。
SM引擎可以在TCP/UDP流的两个方向上检测数据包。为了适应这种情况，可以将会话表设置为使得每个条目在两个方向上跟踪数据包。对于这两个方向的5元组基本上是相同的，其中不同之处在于调换了源/目的地字段。可以标准化键标，使得哈希会产生独立于方向的相同结果。这可以经由源和目标IP地址的简单算术比较来进行。方向位可以存储在条目中以指示存储的顺序。
一旦在会话表中已创建了流条目，就将该流中的数据包发送至SM引擎进行处理。在理想的情况下，将所有数据包都发送至SM引擎，直至能够生成匹配。然而，缓冲和处理需求会使其不切实际。因此，可将流跟踪器设计为仅发送该流的最初N个数据包(或字节)，以保证可缓冲和处理设定数目的流。这可能是足够的，原因在于，对于大部分所关注的应用，所需的数据包含在流的最初几个数据包中。
如图1所示，SM引擎120包括在AXP中。如所指出的，在一个实施方式中，没有从流跟踪器110到SM引擎120的直接接口。相反，可通过附至被转发到SM引擎120的每个数据包的报头来中继信息。可在入口管道中计算报头的一部分，而当该数据包出列并由出口管道处理时，可添加另一部分。图3示出在随着每个数据包被传递到SM引擎120的报头中的入口管道生成字段和出口管道生成字段的实例。
发送至SM引擎的数据包流注释有第一标记和最后标记。这些标记可用于对准和划界正被跟踪和发送以供处理的流。流指数可与各个数据包一起传递，指示数据包属于哪个流。只要数据变得对于任何流可用，SM引擎就可开始处理。不必等待流的所有数据包都变为可用。每个流跟踪器条目在连接的两个方向上记录流，所以报头可提供方向位，用于指示数据包是正向还是反向路径的一部分。
流中的所有数据包都可被标记有用作针对该流的ID的时间戳。这可用于当由SM引擎正在出列数据包时检查流一致性。从流跟踪器接收的不一致时间戳值可表明或是发生了错误或是已经创建了新的流并且正在以相同的流指数进行跟踪。无论在哪种情况下，SM引擎都应停止对当前流的处理，记录错误，并且在检测到开始标记时启动对该新的流的处理。
流跟踪器可将本地序列数(Packet_num)添加到转发至SM引擎的每个数据包的报头。该数字代表数据包被流跟踪器看到的顺序。SM引擎可使用该数字来确认在MMU中没有丢失数据包。可通过观看带有LAST标记设置的数据包来确定发送的数据包总数。在此，应注意，针对流的两个方向可共享该计数。错误位指示符(FT_error)发出信号指示:检测到某种错误进而不应该处理该数据包。在这种情况下，针对该流，不应该发送其它数据包。然后，SM引擎应尝试与先前发送的数据包进行签名匹配。
在将数据包呈现给SM引擎之前，可以预先解析这些数据包，以便可以提取对于该数据包的相关偏移量。恰好在将偏移量发送至SM引擎所驻留的AXP之前，可由出口管道进行偏移量计算。应注意，这些偏移量不必连同每个数据包而存储在MMU中。因此，在出口管道提取该信息的成本相对较低。
发送至SM引擎的字节数和数据包的最大数可以是可配置的。流跟踪器可转发数据包以供处理，直至超过最大有效载荷阈值(例如，2k字节)、最大数据包阈值(例如，10)等。流跟踪器可被配置为跟踪发送至SM引擎的数据包/字节数，并且也跟踪看到的针对该流数据包/字节的累计总数。
在一般情况下，SM引擎使用可编程状态机来对流中的前几个数据包的L4有效载荷进行模式匹配。如果识别到匹配，则发送消息至流跟踪器，从而启动同一流中的其它数据包的行为。在一个实施方式中，SM引擎作为AXP内部的非-线速功能而实现。
图4示出SM引擎的实施方式。如图所示，SM引擎400有四个主要的子块:数据包缓冲器410、流管理420、正则表达式处理器430和匹配处理器440。数据包缓冲器410接收数据包和元数据，对其进行缓冲，并在需要时发送报告数据包。流管理420处理流确认，并将匹配数据存储在签名匹配流表422中。正则表达式处理器430包含可编程状态机。在一个实施方式中，正则表达式处理器430具有32个可编程状态机，其被分组为八个正则表达式瓦片。最后，匹配处理器440在检查其它限定符之后求解最佳匹配，并且如果需要，则利用数据包将消息发送至交换机管道中的流跟踪器。除了这四个主要子块，SM引擎400还包括用于控制和状态的寄存器。
数据包缓冲器410管理通过SM引擎400的数据包和报头数据。图5更详细地示出数据包缓冲器的实施方式。在一个实施方式中，有四个进出数据包缓冲器500的数据包流。数据包数据来自AXP。当数据包被接收时，元数据和某些报头字段被写入16-条目队列。此外，完整的数据包被存储于存储器中。
正则表达式引擎读取并处理有效载荷。正则表达式引擎通过32字节高速缓存器与数据包缓冲器500接口，从而保持四条存储器线路。每个正则表达式引擎可独立处理该数据窗口中的任何字节。
如果存在匹配或数据包被标记为最后一个数据包，则匹配信息和报头字段被放置在要出去的4-条目队列中。然后，该数据包与任何匹配信息一起被发送出AXP接口至流跟
在一个实施方式中，可使能数据包缓冲器来执行数个数据包检查，以确定该数据包对于匹配是否有效，或者是否应该丢弃该数据包。丢弃的数据包不会产生匹配结果，且中间数据包将被丢弃。例如，数据包缓冲器可响应AXP控制信号、流跟踪器误差信号(例如，FT报头包括使已经排队以供签名匹配的数据包无效的错误位)、TCP/UDP校验和、数据包长度(例如，小于或等于接收的实际有效载荷字节数的IP长度)等。
流管理420包括SM流表查询、流有效性检查，并针对同一流中的其它数据包存储流结果。一旦数据包已被确定为有效，则正则表达式引擎开始匹配。
SM引擎中的SM流表422从属于流跟踪器。流跟踪器将流与索引关联，并将该索引提供至SM引擎。签名匹配在SM流表422中进行查找。当匹配完成后，将流的状态写回到SM流表422中。
如果到达的数据包被标记为首个数据包，则基于报头和元数据来初始化SM流表条目。然后，正则表达式引擎开始匹配该数据包。否则，如果该数据包不是首个数据包，则针对来自SM流表422的先前流数据进行数个不同的检查。如果所有的检查都通过，则正则表达式引擎开始匹配。
控制寄存器可用于确定如何处理流检查失败。如果启用的检查失败，则丢弃并计数数据包，置位状态位，且不进行匹配。如果检查被禁用，则仍对失败的检查进行计数，并置位状态位，但是将当前的流值插入表中，且设置“丢失的包”标记以表示失败。
SM引擎的关键元件是基于存储器的状态机组，其被设计为将数据包字节流针对正则表达式大集合进行并行匹配。在一个实施方式中，SM引擎具有32个正则表达式引擎，用于访问用于存储状态树和多数据包模式上下文的总共IMB的片上存储器。
这32个正则表达式引擎和片上存储器可在八个瓦片中平均划分。如图6所示，每个瓦片可具有共享128KB单端口存储器的四个正则表达式引擎。四个独立的正则表达式引擎(RE0、RE1、RE2、RE3)接收对应于输入数据包的应用有效载荷(例如，第4层有效载荷)的字节流。对于每个字节，正则表达式引擎发出一个或更多存储器读取，以取出用于确定状态树的“下一个状态”的“当前状态”信息。重复执行该序列，直至到达数据包的最后。每当检测到“匹配状态”时，正则表达式引擎输出匹配ID。这些匹配被转发至匹配处理器。
在一个实施方式中，正则表达式状态表存储器是258位宽和4k条目深。每行包括2位编码类型和32字节状态表数据。多达四个正则表达式引擎和一个软件接入端口共享单个状态表存储器。它们在那些当前活动之间循环运行。非活动的那些允许其它利用存储器带宽。
对于每个瓦片，状态表是128KB存储器，用于保持针对多达四个正则表达式引擎的状态、转换和多包状态上下文。状态表信息允许正则表达式引擎来基于当前状态和数据字节确定下一个状态。
如果启用，则正则表达式引擎可管理状态表存储器中的数据结构(例如，2KB至16KB)中的多数据包状态上下文。在一个实施方式中，SM引擎可跟踪高达8k单独的流。这是影响所有基于流的跟踪的单独设置。如果当前状态指针是16位或使用16个交叉签名标记，则取决于所跟踪的流数，针对该上下文，可在状态表存储器中保留高达每个引擎16KB的存储。在一个实施方式中，不会将状态表信息放置在存储了上下文的同一个区域中。当正则表达式引擎不需要多数据包状态上下文时，该空间可用于附加状态表信息。
如果在SM流表中没有有效的流，则多数据包匹配上下文空间不需要进行初始化。流中的首个数据包从寄存器中得到其开始状态，然后在数据包的最后，将其状态保存到存储器的上下文区域中。仅在同一有效流中的后续的数据包上，是由多数据包状态上下文确定的开始状态。
在一个实施方式中，有支持状态和过渡数据的两个编码:范围值(RangeValue)和位图(BitMap)。RangeValue (RV)状态是被作为RangeValue条目而编码的可能状态机过渡的可变长度列表。RV条目编码可包括具有接受的字符范围的下一个状态指针。范围可以由最小(min)和最大(max)字符(每个具有O至255的字符范围)来指定。在此，如果max_char=min_char,则指定单字符过渡,如果max_char>min_char,则指定多字符过渡。此外,特定RV条目编码可用于指示(例如)匹配ID (Match ID)位于下一个状态指针字段。图7中示出示例RangeValue编码布局。
另一方面，位图编码可包括256位的位图字段，以表示哪些字符采取非默认过渡。每个位都可对应ASCII字符的过渡，其中“O”表示过渡到下一个默认状态，“ I ”表示过渡到由下一个状态指针列表表示的、非默认的下一个状态。在位图字段之后，所有有效的“下一个状态指针”都被连续(以与位图矢量中所经历的相同顺序)放置在存储器中。下一个状态指针尾随着多达每行15个指针连同信息(Info)字段。信息字段被复制到每行，从而仅必须读出包含由位图表示的指针的行。在一个实施方式中，信息字段可包括匹配状态字段和匹配ID字段。图8中示出示例性BitMap编码布局。
匹配处理器的主要功能是用于在由正则表达式引擎报告的、与给定流关联的所有匹配中确定出最佳签名，用于筛选掉由正则表达式引擎报告的、不具有与签名(例如，应用于给定的L4端口范围，或仅应用于UDP或匹配必须以EOP发生)关联的正确限定符的匹配，用于通过数据包缓冲器将“最佳匹配”与其它元数据一起转发至流跟踪器，以及针对交叉签名标记进行更新和检查。
图9示出匹配处理器的实施方式，如图所示，匹配处理器900从正则表达式处理器(即，每正则表达式一个引擎)接收32个匹配流。内部地，它们被分为八块，并分配到专用的256深的匹配表存储器。简单循环仲裁器可用于服务8个匹配FIFO中的一个，并授予其访问匹配表存储器的权利。
由于有四个不同的匹配表存储器，所以匹配处理器900每个时钟周期可处理最多四个匹配。如果每个引擎在每个字节上生产一个匹配，则平均每个周期4-8个匹配(取决于每个状态的存储器查找的数量)。每个周期处理四个匹配给出同一最坏情况下的吞吐量，然而在正常情况下，不会成为限制因素，原因是不会在每个引擎的每个字节上发生匹配。
对于由正则表达式引擎报告的每个匹配，匹配处理器900读取来自由匹配ID索引的匹配表的条目。匹配处理器然后检查限定符，以确定匹配是否是有效的。例如，某些签名仅应用于具有给定L4端口范围的数据包。在这个实例中，如果触发签名，但是端口范围检查失败，则简单地丢弃该匹配。
一旦匹配已合格，则匹配处理器900确定该匹配(如果它是第一个匹配，则它会被自动存储)是否是比当前存储的匹配具有更高优先级的匹配。每个签名都具有与其关联的匹配优先级字段和匹配报告级。通过考虑这些字段连同匹配ID，匹配处理器900确定最佳匹配以进行报告。
匹配处理器900被设计为:如果数据包被标记为最后，则匹配处理器生成报告，即使没有发现有效的匹配。如果最佳匹配报告级为“最终报告”或“发送报告”，则也在当前数据包结束时生成报告。
为了进一步说明SM引擎的处理，现在参考图10，其示出签名匹配数据包流。如图所示，签名匹配过程开始于验证数据包1002。如果数据包通过了该验证，则过程继续到验证流1004。如果流被验证，则过程继续到运行确定性有限状态自动机(DFA)1006，以针对多个模式同时匹配数据包。
一般情况下，DFA是状态图，其中，数据包字节连同当前状态确定下一状态将是什么。图中的一些状态将是匹配状态，表明可能的签名匹配。正则表达式引擎使用表示存储在存储器中的该图的状态表遍历该图。应理解，在不脱离本发明的原理的情况下，可以使用其它类型的状态表。
一旦DFA运行，则过程继续到后匹配处理1008，以确定到目前为止的最佳匹配，然后，如果有指示则将响应发送至流跟踪器。下面详细提供签名匹配数据包流的每个阶段内的示例处理。
可通过执行各种检查来验证数据包。例如，如果已经由流跟踪器将数据包标记为错误，将不处理该数据包。在另一个实例中，可以做出有关数据包的长度是否足以容纳L4有效载荷的确定。这将检测(例如)数据包是否已在中间系统中被截断。在又一实例中，可以进行校验和验证，以检测数据包是否已在中间系统中损坏。应理解，在验证过程中进行的检查的具体集合可以取决于实现方式。
如前所述，签名匹配保持从属流表，其被配置有与流跟踪器会话表相同数量的条目。由流指数(流ID，Flow Id)索引该从属流表，流跟踪器在签名匹配请求中包含该指数。图11示出签名匹配流表条目中的字段的实施方式。
当签名匹配具有要处理的数据包时，它提取流指数，并使用它来查找从属流表条目。然后，通过执行各种处理(诸如将Fl0W_TimeStamp与签名匹配请求中的时间戳进行匹配以确保数据包属于当前的流，检查Flow_entry_valid字段,检查Next_packet_num是否匹配签名匹配要求中的数据包数以确保数据包是下一个期望的数据包，等等)来验证流。
在数据包和流已被验证之后，可以执行签名匹配。签名包括两部分:待匹配的实际正则表达式和一组匹配属性。可通过软件将正则表达式编译至正则表达式引擎所使用的并存储在状态表存储器中的状态表。该存储器可以是可配置的，以便保持状态表和多数据包匹配状态。
载入状态表中的每个签名可在由软件配置的签名匹配表中具有对应的一组匹配属性。签名匹配可被设计为处理作为正则表达式写入的签名。然后，正则表达式被编译至状态表，并使用正则表达式引擎与数据包有效载荷进行匹配。
正则表达式可使用以下结构来代表一组字符串的简明描述:
.交替(alternation，间隔)一正则表达式由通过“ I ”分隔的零个或多个分支组成。如果替换的分支中的至少一个分支匹配，则正则表达式匹配。
级联(concatenation) —分支由零个或更多个序列组成。为了匹配，分支必须以指定顺序匹配序列中的所有块。
定量(闭合)一块由可能由以下字符中的一个跟随的原子组成:“*”，“ + ”，或“？”(这些被称为重复字符)。
.后面跟随的原子匹配原子的O个或多个匹配序列。
.后面跟随“ + ”的原子匹配原子的I个或多个匹配序列。
.后面跟随“？”的原子可选地匹配原子或空串。
.后面跟随“ {} ”中所括的数字的原子匹配原子的确切数量的匹配的序列。
原子是下列之一:
.通配符一 ”匹配任何单个字符。这必须能够包括所有字符(包括换行)，但也可以如下所述被修改为排除换行符。
起始锚一 “ ~ ” 一作为块的首个字符，在数据包有效载荷开始处匹配空串，将该块锚定在首个字节。然而，如果状态表具有使能的交叉数据包状态，则该块被锚定在逻辑“流”的首个字节。这是首个数据包中的有效载荷的首个字节，这必须伴随第一标记集。
停止锚一 “$”作为块的最后一个字符，在数据包有效载荷结尾处匹配空串，将块锚定在最后一个字节。然而，如果状态表具有使能的交叉数据包状态，则块必须被锚定在逻辑“流”的最后一个字节，即，针对该流匹配的最后一个字节。
.转义一后面跟随单个字符的“\”，匹配特殊字符，如“\r”表示回车字符，或“\W”表示空格字符。单个“\”可通过另一个“\”进行转义。
.文字十六进制一后面跟随两个十六进制字符的“\X”，匹配十六进制值，例如，\xOFo
.分组表达式一括号中的正则表达式(对于针对正则表达式的匹配进行匹配)
范围一在“ □”中括起来的字符序列。范围通常匹配来自序列的任意单个字符。如果序列以“ ~ ”开始，则其匹配不是来自该序列的其余部分的任何单个字符。如果序列中的两个字符由分离，则对于它们之间的ASCII字符(例如，“
”匹配任何十进制数字)的完整列表，这是速记的。为了在序列中包括文字“]”，使其成为第一个字符(跟随可能的“ ~ ”)，或者使用“\”转义。为了包括文字使其成为第一个或最后一个字符，否则使用“\”转义。
除了上述之一以外的任何单个字符，匹配该字符。例如，串“abcdef”由五个原子的序列组成。
正则表达式被括号括起来，且后面可跟随以下修饰符中的一个或多个:
.(“/”)，表示不区分大小写的匹配
.(“/X”)，表示完全忽略空格的匹配
.(“/N”)，表示忽略所有NULL字符的匹配
可以支持锚定在换行符上的匹配，从而对应于使用修饰符“/m”。
下面是一些正则表达式例子。首先基于单个响应数据包(第一块，被视为单行线上的连续串)或POST请求数据包(第二块)认识HTTP。这会进行不区分大小写的匹配并使用来自范围“ [\x09-\x0d- ]”的零个或多个字符匹配空格运行。应注意，在此范围内的空格是有义字符，并可能由\x20表示。
('http/ (0\.9 I 1\.0 I 1\.1) [1-5]
[\x09-\x0d_ ]* (connection: | content-type: | content-length: date:) |'post [\x09-\x0d_ ]氺http/
\.
) /i
下面会使用不区分大小写的匹配认识特殊类型的HTTP请求。应注意，其并未被锚定在任何事物的开始，而且可报告在有效载荷中的任何地方开始的匹配。
(http/ (0\.9 I 1\.01\.1).* (user-agent:1tunes)) /i
典型的HTTP报头可以有由换行符分隔的多个报头字段。下面将在显示换行符终止的行内的HTTP请求中的用户代理报头字段中的具体内容进行匹配，然后匹配内容类型响应报头。因此，这取决于交叉数据包状态来继续对响应数据包进行匹配。
((user-agent:quicktime\(qtver=
.
.
;os=[\x09-\x0d_ ]+\)\x0d\x0a).氺(content-type:[\x09-\x0d_ ]+video/quicktime\x0d\x0a))/i
以下两个签名针对DirectConnect对等会话识别特定交换。第一个签名查找在数据包开始处以“$Lock”锚定并在数据包结尾处以“ I ”锚定的数据包。这必须在服务器到客户端(反向)方向被赋予资格，并设置交叉签名标记。第二个签名也必须在该数据包的开始和结尾处被锚定，并且必须通过特定的交叉签名标记被设置的事实赋予资格，并且该签名处于客户端到服务器(正向)方向。仅在第二个匹配(其潜在地可能在该流的稍后发生几个数据包)之后报告匹配。在一般情况下，资格可用于有利于避免潜在的误报。
'\x24Lock.*\x7c$
'\x24ValidateNick.*\x7c$
可基于单个数据包(其通常是连接上交换的第一个数据包)识别很多应用。对于需要检查多个数据包的那些应用，由本发明提供两种模式。以下，这两种模式被称为交叉数据包状态模式和交叉签名标记 模式。以每个流为单位保持这些状态。每个DFA可支持这些模式中的至少一个的可选配置。
一般情况下，可针对每个正则表达式引擎来打开和关闭这些模式。为了允许单个模式匹配交叉任意数据包边界，当针对同一流的另一个数据包来到时，正则表达式引擎可以将当前状态上下文保存在稍后要被检索的正则表达式状态表存储器中。这样，模式可继续被匹配，而不论在两个数据包之间有多少其它流被分析。
交叉数据包状态模式在逻辑上等同于重组单个缓冲器中的流，然后在该缓冲器之间匹配。在此，流被认为是以它们到达的顺序的有效载荷的简单串联，而不论方向(例如，HTTP请求然后HTTP响应)如何。然而，取代在缓冲器中累积流，DFA随着数据包到达对其进行匹配，从而在数据包结束时保存匹配状态，并使用该匹配状态作为下一个的起始状态。为了支持交叉数据包状态模式，DFA能够以每个数据流为单位将下一个状态指针保持在其大小与流表的大小相同的交叉数据包状态表中。
在交叉签名标记模式下，针对每个数据包使用不同的签名，但仅在出现匹配的特定序列时才报告匹配。交叉签名标记用于链接匹配，通过在不被报告的情况下使一个成功的匹配设置标记，并使随后的一个依赖于所设置的该标记，以便赋予匹配资格。为此，标记的向量可与流状态关联。在一个实施方式中，至少16个标记支持交叉签名标记模式使能的每个DFA。这些标记都可以作为标记的全局池，以利用使能的交叉签名标记模式来赋予来自任何DFA的匹配的资格。
通过交叉签名标记模式，第一个签名包含对匹配初始数据包的内容的表达式，并且作为匹配行为来设置交叉签名标记位。第二个签名将包括修饰符，仅在指定的签名标记位已经被流中的前一个数据包置位时才考虑该修饰符。
匹配处理器处理交叉签名标记更新以及检查。由于这些交叉签名标记是特定流的属性，所以交叉签名标记被存储在状态表的配置区域中。当数据包正在被处理时，有两个保持的交叉签名标记副本。一个是更新副本，其中根据当前数据包进行变化。另一副本用于检查并反映前一个数据包结尾处的交叉签名标记的状态。
针对交叉签名标记更新，匹配表中的以下字段(参见图12)可以被定义为:Match_cross_sig_flag_index,用于指定行为应用至哪个交叉签名标记；Match_cross_sig_f lag_is_set,当置位时，由索引引用的交叉签名标记将在当前数据包结束时由匹配处理器设置；以及Match_cross_sig_flag_is_cleared,当其复位时，由索引引用的交叉签名标记将在当前数据包结束时由匹配处理器复位。
更新交叉签名标记的签名首先应当通过其所有的匹配限定符是有效的。然而，更新交叉签名标记的签名不需要是最高优先级或最佳匹配。如果匹配是有效的，则交叉签名标记将被更新。
可以针对交叉签名标记检查来定义匹配表内的以下字段:Check_cross_sig_flag_index,用于指定检查应用至哪个交叉签名标记；Check_cross_sig_flag_is_set,当对其置位时，匹配是有效的；以及Check_cross_sig_flag_is_cleared,当不对其置位时，匹配是有效的。被检查的交叉签名应标记应已经被同一流中的先前数据包设置。
对于新流的第一个数据包，匹配处理器可以将所有的交叉签名标记初始化为“O”。当正则表达式引擎检测需要交叉签名标记更新的匹配时，匹配处理器修改交叉签名标记的更新副本。一旦匹配处理器达到EOP条件，则其传送交叉签名标记的该更新的副本，以按照每个流来存储。
对于后续数据包，状态表针对该特定流读取活动的交叉签名标记信息。如果任何检测到的匹配指示了交叉签名标记变化，则修改该更新的副本。只要签名匹配要求交叉签名标记检查，交叉签名标记的检查副本(而不是更新的副本)就用于此目的。
交叉签名标记被存储在数据流表和状态表存储器中。在一个实施方式中，其可以按照16个标记块被配置，多达512个标记。前16个标记按照每个流被存储在16位CroSS_sig_flags字段的流表中。如果被配置，其余31个标记块可以存储在状态表中。针对该每个流存储的配置是作为特定多数据包模式处于正则表达式引擎中。对于8K流，标记块将需要16KB的状态表存储器，以分配用于存储。可以在I至32个块中使能任意数量。如果启用了所有512个标记，则将分配512KB或存储器。
如果被启用，每个引擎可以具有其存储的标记的特定范围。在一个实施方式中，正则表达式引擎I可以管理用于标记16至32的存储，一直到达正则表达式引擎31，其可以管理标记496至511的存储。正则表达式引擎O无需存储前16个标记，因为它们可以被存储在数据流表中。存储标记的正则表达式引擎可以完全独立于对标记进行更新的正则表达式引擎。此外，启用的引擎/标记块不必是连续的。任何块都可以独立地在相应的正则表达式引擎中启用或禁用。在数据包的开始，所有存储标记的引擎都可以将标记加载到全局标记缓冲器。任何签名可以更新任何标记。在数据包结尾，更新被写回状态表中。
一般情况下，正则表达式匹配将数据包有效载荷与签名数据库比较，并报告所有匹配。匹配基于状态机，并有多个状态机或DFA。每个DFA在特定状态下开始，并针对数据包的每个字节进行过渡，直到它达到不再采取过渡的状态，或直到它达到有效载荷的结尾。
基本上，DFA被实现为状态表。逻辑上，DFA状态表中的每个状态包含两部分:256条目下一状态跳转表和匹配报告值。下一状态跳转表中的每个条目构成指向另一个DFA状态的指针。匹配报告值表示状态是否是匹配状态(即，匹配正则表达式)以及要报告的值。
输入串的处理开始于第一字节以及起始DFA状态表。字节用于索引至下一状态表，以获得指向下一状态的指针。使用下一 DFA状态在串中重复针对下一个字节的查找，直到或是达到没有用于输入字节的下一个状态指针的状态或是达到串的结尾。如果在运行期间由状态表示，则将会报告该匹配。
对于许多正则表达式，下一状态表是相对稀疏的(S卩，只有少数精确匹配条目具有实际的下一状态指针)，或具有指向相同的下一状态(例如，针对值的范围)的多个条目。
DFA可能会达到没有过渡的状态，在这种情况下，在数据包完成之前，完成该状态。特定IDLE状态可用于防止针对该数据包的进一步匹配。
在针对数据包进行处理期间，每个DFA可以报告一个或多个匹配。每个匹配可以指示match_indeX成为签名匹配表中的一个，并且指示它是否在该数据包的最后一个字节上匹配。图12示出签名匹配表条目中的属性的示例。可以按照每个签名有一个签名匹配表条目。
一般情况下，签名匹配表可包括三种属性:匹配(Match)，其用于匹配处理期间；检查(Check),其用于赋予匹配作为确定最佳匹配的一部分的资格；以及报告(Report),其包括如果是最佳匹配则在签名匹配响应中要发送至流跟踪器的值。
在一个实施方式中，逻辑上具有一个1024条目签名匹配表，它被划分成4个256条目子表。每组八个DFA弓丨擎可以被配置为共享签名匹配子表，并将8位匹配索引报告到它的表。在此，应注意，阴影数据流表可以作为10位实体而保持针对该流的最佳匹配索引，其中最佳匹配索引的两个最低有效位可用于选择签名匹配表。
针对多个原因，DFA可以报告多个匹配。特别地，通配符可能导致正则表达式匹配多个地方中的输入。此外，因为协议具有“子协议”，所以不同的正则表达式可以匹配。例如，这可能在以下情况发生:当要区分HTTP上运行的不同应用时，或当有误报(即，签名太概括并且在本不应该时却进行了匹配)时。
后匹配处理可以使用签名匹配表中的标准使得有资格匹配，求解有资格的匹配从而找到迄今为止针对该数据流或所有发现的那些数据流的最佳匹配，并根据需要发送匹配报告数据包。逻辑上，在对所有DFA进行了匹配数据包之后，可针对每个数据包进行后匹配处理。
通过将来自针对有资格的候选匹配的签名匹配表的报告参数与目前为止最佳匹配的那些报告参数进行比较，推断出数据包的最佳匹配。在一个实施方式中，最佳匹配可以求解如下:如果匹配是最终的，且目前为止没有最佳匹配，则采取新的匹配；如果两者都是最终的，则采取具有较高优先级的匹配；如果两者具有相同的优先级，则采取较小编号签名id的匹配。匹配应该在无依赖关系的情况下以任意顺序求解。
在求解了有资格的匹配之后，按照需要发送匹配报告数据包。在一个实施方式中，如果报告了最佳匹配，那么如果是最终的，或者如果来自签名匹配的最后一个数据包，则报告最佳匹配。然后，流条目失效，以在流跟踪器处理签名匹配响应之前，忽略可能会到达签名匹配的随后数据包。如果报告了最佳匹配，如果不是最终的，但指示报告应发送，则签名匹配响应被创建并发送至流跟踪器。
如果没有匹配要报告，但它是最后一个数据包，则流无效，并且发送签名匹配响应，以指示没有匹配的签名。最后，如果没有匹配，而且这不是最后一个数据包，且有交叉数据包状态，则流表中的交叉数据状态被更新。
如已经描述的，一旦SM引擎完成了处理数据流，则响应被发送回流跟踪器，以便适当行为可应用于流的其余数据包。如上所述，这可通过利用从AXP至入口管道的数据包接口来完成。数据包被注入入口管道，以便流跟踪器会话表可以被更新。使得结果通过数据包中继这提供了更新会话表的通用方法，该方法与结果是否来自内部签名匹配引擎、夕卜部签名匹配引擎或这两者组合无关。这允许表访问要利用输入的数据包流和CPU开始更新被调度的会话表。当在入口管道调度结果数据包时，隐式完成针对存储器访问会话表的仲裁。
在一个实施方式中，内部SM引擎可以被优化，以针对一组最常见的签名匹配。为了扩大流识别功能，可以添加外部签名匹配引擎或CPU来处理更复杂的情况，并提供缩放签名个数的方法。
图13A至图13C中示出结果数据包的示例格式。如图所示，图13A的数据包包括触发匹配的原始未修改的数据包、8字节结果报头和L2封装报头。在图13B中进一步详细说明了 8字节结果报头，而在图13C中进一步详细说明了 8字节结果报头中包含的结果标记。
通过将目的MAC地址和类型字段与预配置值匹配，在签名结果数据包进入入口管道时识别它们。当流跟踪器从SM引擎接收到结果数据包时，它使用报头中的流指数来检索会话表条目。然后针对会话项中的值验证报头中的时间戳，以确保结果的确是针对该流。处于流跟踪目的，流指数和时间戳可以用于唯一地标识该流。如果存在不匹配或者如果流条目是不正确的状态，则该条目将不会被更新。这可能在以下情况发生:如果SM引擎提供的是针对已经结束的流的结果，或者由于一些其它的错误条件，导致流跟踪和SM引擎不同止/J/ O
SM引擎接收流中的数据包用于处理，其主动寻找字节流上匹配的。根据匹配规则是如何配置的，可能存在以下情况:期望SM引擎继续搜索字节流，即使在发现了中间匹配结果以后。由于更多的数据包到达进而更多的数据可用，这可以有助于寻找更好的匹配。为了适应这种情况，流跟踪器可以被布置为从SM引擎接受中间结果。这可以通过最后位清零而显示在结果报头中。中间结果被存储在会话条目中，但并不立即是指流跟踪器利用该结果。仅在设置的超时期间之后从未接收到最终结果匹配时，才会利用其并对其采取行为。
图14中进一步描述了结果报头中的字段。其指示是否找到匹配，应如何处理流，并提供了有关哪个签名匹配的信息。如果有匹配，则更新针对该条目的流状态。策略指数、签名id和年龄指数被存储供以后使用。流中的后续数据包的分析将看到该流已被签名匹配且由策略指数指定的该行为将被应用于数据包。流条目保持这种状态，直到流终止或处于非活动状态达指定时间量。
如前面所指出的，Final位表明该结果是否是中间结果或者它是否应该被立即采取行为。Keep_fl0W位表明流是否应保持在会话表中并被跟踪，或者它是否不受关注并应该被释放以供另一个流再使用。Apply_aCtion位表明是否跟踪的流应该对流中的随后的数据包应用行为，或者它是否应该被视为仅计数的流。如果针对流而激活行为，则报头中指定的策略指数用于检索一组行为，以应用于该数据包。SM_err0r标记表明在流处理期间遇到错误。这将被记录在针对流的会话表中，但如果此位被置位，则将不会对流采取特定行为。Http_persistent标记表明该流所需的特定处理。在发送新数据包以进行匹配之前,该流将继续进行到活动状态，并等待检测到新连接。Age指数提供了签名特定非活动超时值，其可用于规定何时应当将活动的数据流从会话表中删除。C0py_t0_Cpu字段指定数据包是否应该被复制到CPU。
在正常处理过程中，会话表条目更新由硬件专门处理，原因在于更新流状态所需的所有信息可独立于CPU干预而被检索。对会话表条目的这些更新包括经由数据包发送并且不需要任何显式CPU控制的签名匹配结果。在某些情况下，针对CPU利用不能被硬件直接访问的信息来更新会话表可能是必要的。这可以经由发给会话表的表运算命令(例如，tbl_insert, tbl_lookup 和 tbl_delete)支持。
一旦流已被签名匹配，期望对流中的后续数据包应用策略行为。流跟踪器提供了一种方法，其存储来自SM引擎的结果，识别流中的后续数据包，并对这些数据包应用指定的行为。可支持的一些行为包括丢失、计量、改变优先级或服务类别(CoS)、镜像、复制数据包至CPU等。
流跟踪器可以平衡现有的策略行为和IFP中定义的决议逻辑。这提供了一组稳健的行为，其可以应用至进行流跟踪的任何流。会话表可以被集成到IFP模块中，因此，它看起来像另一片。如图15所示，流跟踪器会话表查找可与其它片中的字段处理器三态内容寻址存储器(TCAM)查找一致，并可产生用于针对数据包检索策略行为的索引。
在一个实施方式中,在策略表中具有共256个条目。在此,假设每个支持的签名将需要一个策略表条目。对可能会被看到的不同签名的大致数量来设置该表的大小。虽然可能针对流的每个方向提供不同的策略行为，但在实际使用中，可以接受对流的两个方向应用相同策略行为。
可以利用IFP中可用的现有资源进行流计量。在一个实施方式中，支持用于针对每个正被跟踪的流的单独的速率计。所支持的策略索引的数目可以限制可选择的计量器数量。在一个实施方式中，使用共同的共享计量器来节流带有特定的签名匹配索引的所有流。还可以在IFP中包括额外的模式，其可以重新映射所选的计量器，以便按照每个端口为单位来跟踪它们。这将允许流按照每个签名/每个端口为单位来计量。
作为流跟踪功能的一部分，硬件监视每个单独流并确定何时应终止流并从会话表中移走。流条目的数量可以由于多种原因而过期，包括:不活动(例如，在足够长的时间内没有看到数据包)，显式指示符(例如，TCP流有显式地表明该流结束的数据包)，处理中的错误(例如，在匹配过程中，错误检测或超时)，CPU终止，等等。
每当有更新流的会话表条目的事件时，可以由流跟踪器执行这些检查。这可能是访问该表的流中的定期数据包的结果、来自更新条目的SM引擎的结果数据包、CPU表操作命令，或通过背景年龄扫描过程。在上述每种情况下，所执行的检查依赖于流条目的状态。
通过阅读前面的详细描述，本发明的这些和其它方面对于本领域的技术人员将变得显而易见。虽然上面已经描述了本发明的一些显著特征，但是本发明能够有各种实现方式和可以按照在阅读所公开的本发明之后对于本领域的普通技术人员显而易见的多种方式来实现和执行，因此，上面的描述不应该被认为排除这些其它实施方式。此外，应理解，本文所采用的措辞和术语是用于说明的目的，并且不应该被视为限制。
权利要求
1.一种在交换机ASIC中具有集成的线速应用识别的交换机，包括: 流跟踪器会话表，所述流跟踪器会话表具有多个条目，所述多个条目中的每一个与独特的数据包流关联，其中，至少基于共用源以及由多个数据包共享的目的地址来区分数据包流； 流跟踪器，审阅在入口管道进入所述交换机的数据包，在识别出要被跟踪的新的数据包流时，所述流跟踪器在所述流跟踪器会话表中创建条目，所述流跟踪器审阅与识别出的所述流相关联的数据包并生成将连同经审阅的所述数据包被转发至所述交换机中的存储器管理单元的流信息，所述流信息包括标识经审阅的所述数据包关联的特定数据包流的流指数；以及 签名匹配引擎，从所述交换机中的所述存储器管理单元接收经审阅的所述数据包和所述流信息，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查经审阅的所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发生至所述入口管道的响应数据包中， 其中，所述流跟踪器使用在所述入口管道接收的所述响应数据包中包含的流指数来更新所述流跟踪器会话表中的条目，以表明要施加到由所述流跟踪器审阅的后续数据包的策略，所述后续数据包与所述流跟踪器会话表中的所述条目关联的流相关。
2.根据权利要求1所述的交换机，其中，基于源地址、目的地址、源端口、目的端口和协议来识别数据包流。
3.根据权利要求1所述的交换机，其中，所述流跟踪器会话表位于能够看到双向流中的所有数据包的位置。
4.根据权利要求1所述的交换机，其中，在多个管道中共享所述流跟踪器会话表。
5.根据权利要求1所述的交换机，其中，所述签名匹配引擎包含在与出口管道分离的辅助管道中。
6.根据权利要求1所述的交换机，其中，所述表达式匹配状态机是确定有限状态自动机状态机。
7.根据权利要求1所述的交换机，其中，所述响应数据包包括标识应当应用于流中的数据包的策略的策略指数。
8.一种用于执行数据包检测的交换机，包括: 入口管道，所述入口管道包括审阅在所述入口管道进入交换机的数据包的流跟踪器，在识别出要被跟踪的新的数据包流时，所述流跟踪器在流跟踪器会话表中创建条目，所述流跟踪器审阅与所述新的数据包流相关联的其它数据包并生成将连同经审阅的所述数据包被转发至所述交换机中的存储器管理单元的流信息，所述流信息包括标识经审阅的所述数据包关联的特定数据包流的流指数；以及 耦接至所述存储器管理单元的辅助管道，所述辅助管道与同样耦接至所述存储器管理单元的出口管道分离，所述辅助管道包括签名匹配引擎，所述签名匹配引擎从所述交换机中的所述存储器管理单元接收经审阅的所述数据包和所述流信息，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查经审阅的所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发送至所述入口管道中的所述流跟踪器的响应数据包中。
9.一种用于执行数据包检测的交换机，包括: 耦接至所述交换机中的存储器管理单元的辅助管道，所述辅助管道与同样耦接至所述存储器管理单元的出口管道分离，所述辅助管道包括签名匹配引擎，所述签名匹配引擎从所述交换机中的所述存储器管理单元接收数据包，所述签名匹配引擎使用针对已知签名进行搜索的表达式匹配状态机检查所述数据包，其中，所述签名匹配引擎将来自所述表达式匹配状态机的结果包含在由所述签名匹配引擎发生至所述交换机的入口管道的响应数据包中，其中，所述入口管道中的流跟踪器使用在所述交换机的所述入口管道上接收的所述响应数据包，以对包含在所述响应数据包中的流指数标识的数据包流中的后续数据包应用策略行为。
10.根据权利要求所述9的交换机，其中，在所述流跟踪器和所述签名匹配引擎之间不存在直接 连接。
全文摘要
一种用于在交换机ASIC中集成线速应用识别的系统和方法。可以使用此功能连同传统控制平面处理器而不是更昂贵的专用处理器来建立交换平台。可以使用流跟踪器和签名匹配引擎在交换机ASIC中嵌入深度包检测系统。流跟踪器位于交换机ASIC的可观察和记录双向流中的数据包的入口部分位置。流跟踪器生成签名匹配请求，该签名匹配请求被转发至辅助管道中的签名匹配引擎。签名匹配引擎使用签名匹配状态机分析数据包并使用发送至入口管道的响应数据包向流跟踪器报告签名匹配结果。
文档编号H04L12/741GK103139072SQ201210504399
公开日2013年6月5日 申请日期2012年11月30日 优先权日2011年11月30日
发明者约瑟夫·塔多, 道华, 纳特·希尔, 斯坦尼斯拉斯·沃尔斯基 申请人:美国博通公司