CN1965542A - 处理分组标头 - Google Patents

处理分组标头 Download PDF

Info

Publication number
CN1965542A
CN1965542A CN200580012679.5A CN200580012679A CN1965542A CN 1965542 A CN1965542 A CN 1965542A CN 200580012679 A CN200580012679 A CN 200580012679A CN 1965542 A CN1965542 A CN 1965542A
Authority
CN
China
Prior art keywords
grouping
check field
packet
network interface
interface unit
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
Application number
CN200580012679.5A
Other languages
English (en)
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.)
Solarflare Communications Inc
Original Assignee
Level 5 Networks Inc
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 Level 5 Networks Inc filed Critical Level 5 Networks Inc
Publication of CN1965542A publication Critical patent/CN1965542A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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/742—Route cache; Operation thereof
    • 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 Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

一种在主机设备与网络之间提供接口的网络接口设备，用于在网络上接收分组并至少将这些分组中的一些送到主机设备的端口，每个分组包括控制部分，该控制部分具有一个或多个表示分组类型和数据协议的字段、一个表示分组源地址的源地址字段、一个表示分组目的地址的目的地址字段、一个表示分组源地址的源端口字段和一个表示分组目的地址的目的端口字段；该网络设备包括：一个用于存储将被送到主机设备的分组的说明的数据存储器，每个说明包括第一、第二和第三校验字段；一个根据数据存储器的内容来选择哪个在网络上接收到的分组将要被送到主机设备的分组选择单元，该分组选择单元能够识别所收到分组的协议并按照至少以下模式之一进行操作：第一种模式为，对于第一协议和表示要建立一种新连接请求的类型的分组，仅当数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配预留的数据报且第三校验字段匹配分组的目的端口时，其将这种分组送到主机设备；以及第二种模式为，对于第二协议的分组，仅当数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配分组的目的端口且第三校验字段匹配预留的数据报时，其将这种分组送到主机设备。

Description

处理分组标头
本发明涉及一种网络接口，例如将计算机连接到网络的接口设备。
图1是如网络接口卡(NIC)等网络接口设备及可将该设备用于其中的***的总体架构的原理图。网络接口设备10通过数据链路5连接到处理设备如计算机1，并且通过数据链路14连接到数据网络20。另外的网络接口设备如处理设备30也与网络相连，用于在网络和另外的处理设备如处理设备40之间提供接口。
例如，计算机1可以是个人计算机、服务器或专用处理设备例如数据记录器或控制器。在本例中，它包括处理器2、程序存储器4和内存3。程序存储器存储定义操作***和可以在操作***上运行的应用程序的指令。操作***提供驱动程序和接口库等工具，利用该工具应用程序可以访问连接于计算机的***硬件设备。
网络接口设备最好能够在用户级支持如TCP、RDMA和ISCSI等标准传输协议：即，通过一种方式可使它们能够访问运行在计算机1上的应用程序。这种支持使得能够进行需要使用标准协议的数据传送，而不需数据通过内核栈。在本例的网络接口设备中，在计算机1的操作***可访问的传输库中实现标准传输协议。
图2说明了这样的一个实现。在这个架构中，实现了两次TCP(以及其它)协议：如图2中TCP1和TCP2所示。在一个典型的操作***中，TCP2是内置于计算机的操作***中的TCP协议的标准实现。为了控制网络接口设备和/或与网络接口设备通信，运行在计算机上的应用程序可发出API(应用程序编程接口)调用。已提供的支持网络接口设备的传输库能够处理一些API调用。对于应用程序直接可用的传输库所不能处理的API调用，通常通过应用程序和操作***之间的接口传送由操作***可用的库处理。对于具有多个操作***的实现，方便的做法是令传输库经由OS接口，使用现有的基于Ethernet/IP的控制平面架构，例如SNMP和ARP协议。
在用户级实现传输协议具有很多困难。到目前为止的多数实现均是基于把预先存在的内核代码基础移植到用户级。这样的例子有Arsenic和Jet-stream。这证明了用户级传输的潜力，但是没有解决取得一个完善的、鲁棒的、高性能的、商业上可行的实现所需的诸多问题。
图3示出一个使用标准内核TCP传输(TCPk)的架构。
该架构的操作如下：
当从网络接口硬件(例如网络接口卡(NIC))进行分组接收时，NIC将数据送入预先分配的数据缓冲区(a)，并通过中断线调用OS中断处理程序(步骤i)。中断处理程序管理硬件接口，例如公布新的接收缓冲区，并且传递已接收的(在本例中，通过Ethernet)寻找协议信息的分组。如果一个分组被识别为指定了有效的协议，例如TCP/IP，就将其传递(不复制)到适当的接收协议处理块(步骤ii)。
进行TCP接收侧的处理并且从分组识别目的部分。如果分组包含端口的有效数据，那么将分组加入到端口的数据队列(步骤iii)，把该端口标记为(可能需要调度程序和被阻止的进程的唤醒)持有有效数据。
TCP接收处理可能需要其它分组已经传送(步骤iv)，例如，如果应当再次传送此前已传送的数据或者可以现在传送之前已入队的数据(或许因为TCP窗口已经打开)。在这种情况下，分组与用于传送的OS“NDIS”驱动程序一起排队。
为了使一个应用程序能够检索数据缓冲区，它必须引用OS API(步骤v)，例如使用recv()，select()或poll()等调用。如此做具有这样的效果：通知应用程序数据已经收到并且(在recv()调用的情况下)将数据从内核缓冲区复制到应用程序缓冲区。复制使内核(OS)能够重新使用它的网络缓冲区，该缓冲区具有如DMA可访问的特殊属性并意味着应用程序不必在网络所提供的单元中处理数据，否则应用程序需要预先知道数据的最终目的地，应用程序必须预先分配以后能够用于数据接收的缓冲区。
应当注意的是，在接收侧具有至少两个不同的异步交互的控制线程：来自中断的向上调用和来自应用程序的***调用。许多操作***也将向上调用分开，以避免在中断优先级执行太多的代码，例如通过“软中断”或“延迟程序调用”技术。
除了通常存在一条执行路径外，发送过程以类似的方式运作。应用程序通过加以要传送的数据调用操作***API(例如，使用send()调用)(步骤vi)。该调用将数据复制到内核数据缓冲区中并且引用用TCP发送处理。此时，应用了协议且完好形成的TCP/IP分组与接口驱动程序一起排队用于传送。
如果成功的话，***调用返回一个对经调度的(由硬件)用于传送的数据的指示。然而，在一些情况下，网络接口设备无法使数据入队。例如，传输协议使未决的确认或窗口更新进行排队，设备驱动程序使到硬件的未决的数据传送请求以软件的形式进行排队。
由必须根据时间变化执行的动作生成贯穿***的一个第三控制流。一个例子是，对重发算法的触发。通常，操作***为所有OS模块提供时间和调度服务(由硬件时钟中断驱动)，使TCP栈能实现在基于每个连接的定时器。
如果在用户级实现标准内核栈，那么架构通常如图4中所示。应用程序与传输库链接而不是直接与OS接口链接。该架构与具有由用户级程序包提供的如定时器支持等服务的内核栈实现，以及由用户级虚拟接口模块替代的设备驱动程序接口很相似。然而，为了提供TCP实现所需要的一个异步处理模型，在传输库内必需有一些活动的执行线程：
(i)由应用程序提供的***API调用
(ii)定时器生成协议代码的的调用
(iii)虚拟网络接口和协议代码内合成的向上调用的管理(对于一些架构，可将ii和iii组合)
然而，这样安排带来一些问题：
(a)在这些线程间的上下文转换和实现闭锁以保护共享数据架构的开销可能是巨大的，从而消耗了大量的处理时间。
(b)通常使用提供定时器/时间支持的操作***来操作用户级定时器代码。来自定时器模块的***调用所产生的大的开销导致***不能获得满意的阻止操作***和数据路径间相互作用的目的。
(c)可能有许多独立的应用程序，每个应用程序管理网络连接的一个子集；一些是通过它们自己的传输库，一些是通过现有的内核栈传输库。NIC必须能够有效地解析分组，并将他们传送到基于如IP端口和主地址位等协议信息的适当的虚拟接口(或OS)。
(d)一个应用程序可能将对特定网络连接的控制传送到另一个应用程序，例如在Unix操作***上的fork()***调用期间。这要求：将需要一个完全不同的传输库例访问连接状态。更糟糕的是，许多应用程序可能共享一个网络连接，意味着传输库通过(进程间通信)技术共享所有权。现有的用户级传输不支持这样。
(e)通常要求传输协议命令网络连接的寿命长于其所连接的应用程序。
例如，使用TCP协议，传输必须竭力进行发送，除了不被确认的数据，当发送应用程序退出或失效时适当的关闭一个连接。对于内核栈实现，不管应用程序的状态如何，都能够将“定时器”输入到协议栈是没有问题的，但是如果应用程序退出、失效或者在调试程序中终止，对于将消失(可能是不适当地)的传输库则存在问题。
另一个问题是，如果网络接口设备打算进行分组过滤，都希望用于过滤的方式尽可能有效。一种过滤分组的方式为使用内容可寻址内存(CAM)处理分组标头。通常在多个头字段上执行过滤，包括源端口，目的端口和地址。可以提供CAM有足够的宽度在每一行上来容纳要进行过滤的所有字段的全宽度。然而，最好能在较窄的CAM上实现操作。这有特别意义，由于CAM通常为标准的宽度，例如64或128位，字段的全宽度可能落入这些宽度的范围内，也可能需要使用更宽的CAM。
希望提供一个***至少部分地解决a-e这些问题中的一个或几个问题。
根据本发明提供的一种在主机设备与网络之间提供接口的网络接口设备，用于在网络上接收分组并至少将这些分组中的一些送到主机设备的端口，每个分组包括控制部分，该控制部分具有一个或多个表示分组类型和数据协议的字段、一个表示分组源地址的源地址字段、一个表示分组目的地址的目的地址字段、一个表示分组源地址的源端口字段和一个表示分组目的地址的目的端口字段；该网络设备包括：一个用于存储将被送到主机设备的分组的说明的数据存储器，每个说明包括第一、第二和第三校验字段；一个根据数据存储器的内容来选择哪个在网络上接收到的分组将要被送到主机设备的分组选择单元，该分组选择单元能够识别所收到分组的协议并按照至少以下模式之一进行操作：第一种模式为，对于第一协议和表示要建立一种新连接请求的类型的分组，仅当数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配预留的数据报且第三校验字段匹配分组的目的端口时，其将这种分组送到主机设备；以及第二种模式为，对于第二协议的分组，仅当数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配分组的目的端口且第三校验字段匹配预留的数据报时，其将这种分组送到主机设备。
本发明的其它方面和优选特征在权利要求中陈述。
现在结合附图通过例子来说明本发明，其中：
图1是一个通用的网络接口设备的原理图；
图2示出了传输库架构的一个实现；
图3示出使用用户级TCP传输的标准内核TCP传输的架构；
图4示出在用户级实现标准内核栈的架构；
图5示出一个TCP传输架构的例子；
图6示出网络接口设备过滤进入的TCP/分组所采取的步骤；
图7示出通过内容可寻址内存的服务器(passive)连接的操作。
图5示出一个TCP传输架构的例子，该架构适合在如图1中的设备10的网络接口设备和如图1的计算机1的计算机之间提供一个接口。该架构不限于这个实现。
图5中例子的架构和传统架构之间的主要区别如下。
(i)代表网络连接执行协议处理的TCP代码既位于传输库又在OS内核中。该代码执行协议处理的事实是非常重要的。
(ii)连接状态和数据缓冲区保持在内核内存和映射在传输库的地址空间的内存中。
(iii)内核与传送库代码均可访问针对和代表某一特殊网络连接的虚拟硬件接口。
(iv)通过虚拟硬件接口可管理定时器(这些定时器对应于网络接口设备上的真实定时器)，不需***调用来对他们设置和清零。NIC生成定时器事件，由网络接口设备驱动程序接收该事件并将其传送到设备的TCP支持代码上。
应当注意的是，网络接口设备的TCP支持代码是一般OS TCP的实现的补充。这能够很好的与网络接口设备栈共存。
为该架构的效果如下。
(a)要求多个线程活动于传输库中
由于既能作为***API调用的结果在传输库中执行TCP代码(例如recv())(见图5步骤i)，也可作为定时器事件的结果由内核执行TCP代码(见图5步骤ii)，对于图5的架构，不存在这一需求。在这两种情况中，均可以管理VI(虚拟接口)且两个代码路径可以访问连接状态或数据缓冲区，可以由共享内存锁管理对他们的保护和他们间的互斥。并且能够去除在传输库级的线程切换的开销，该特点能够应用程序制止它们的线程和信号处理假设的需求：例如在一些情况下，要求一个单线程的应用程序与一个多线程的库链接是不能接受的。
(b)替换针对定时器管理的***调用
由于网络接口设备能够实现一些可分配在特殊虚拟接口例的多个定时器：例如，每个活动的TCP传输库可有一个定时器，因此这一需求没有表现在图5的架构中。可以通过由内存映射的VI使这些定时器成为可编程的(见图5步骤iii)，并且导致发布事件(见图5步骤iv)。因为不用***调用就可以设置和清零定时器，可大大降低定时器管理的开销。
(c)至多传输库的分组的正确送达
网络接口设备可以包括或者访问内容可寻址内存，这能够匹配从进入的分组标头所取得的比特，作为并行硬件匹配操作。可以将取得的匹配结果指示必须用于送达的目的虚拟接口，并且硬件可以开始将已经被推进VI的分组的送达缓冲区。下面将说明匹配处理的一种可能的配置。可以扩展下面说明的配置来对与IPv6关联的更大的主地址解复用，尽管与所描述的配置相比这将要求对应每个分组更宽的CAM查找或多CAM查找。
为了这个目的使用CAM的一个选择是使用散列算法，该算法允许来自分组标头的数据被处理以确定要被使用的虚拟接口。
(d)在进程/应用程序/线程之间连接的切换
当切换网络连接时，可以在应用程序间传送相同***宽的资源句柄。例如，可以是文档描述符。网络接口设备的架构能够将所有与网络连接相关联的状态附加于(例如)该文件描述符，并要求传输库内存映射至这个状态。网络连接切换后，尽管新的应用程序在不同的地址空间中执行，新的应用程序(无论是应用程序、线程或进程)也能够进行内存映射并且继续使用该状态。另外，通过使用与在内核和传输库之间使用的相同的返回源语，任何应用程序能够共享具有由标准***API指定的相同的语义的网络连接的使用。
(e)当传输库停止、失效或解除时，完成传输协议操作
在网络接口设备的架构中可以完成这个步骤，因为连接状态和协议代码能够驻留于内核。可以按照与通用TCP(TCPk)协议栈相同的方式通知OS内核代码应用程序状态的改变。被停止的应用程序将不会提供线程去进行协议执行，但是协议将通过定时器事件继续，例如，对于现有技术内核栈协议，这是人们所熟悉的。
有很多新出现的协议如IETF RDMA和iSCSI。至少其中一些协议设计为运行在TCP和其它协议代码执行在网络接口设备上的环境中。现在来说明这种协议能够在主CPU上执行的工具(即使用连接有网络接口卡的计算机的处理设备)。这种实现是先进的，因为其使用户能够利用主CPU技术相对于协处理器技术的价格性能比优势。
如RDMA等协议涉及在TCP流内的成帧信息的嵌入和循环冗余校验。成帧信息在协议库内的计算是微不足道的，而CRC的计算(对比校验和)运算量大且最好由硬件完成。为了适应这一点，当TCP流带有RDMA或相似的封包(encapsulation)时，可以在虚拟接口内进行选择，例如通过标志位。当检测到这个选择时，NIC在传送期间将解析传送中的每个分组，恢复RDMA帧，使用RDMA CRC算法以及快速***CCRC。相对如iSCSI等对误差校验数据的运算的运算密度相对较大的其它协议，使用类比程序是有益的。
根据这一***，网络接口设备还能使用相似的逻辑验证所接收的分组上的CRC。例如，可以用类似于标准TCP校验和卸载技术的方式来执行校验。
RDMA等协议还对如RDMA READ等附加操作进行授权，传统的实现需要在网络接口设备上具有附加的智能。这种类型的实现使人们相信RDMA/TCP最好应当由协处理器网络接口设备来实现。在这里所述类型的架构中，可对特定硬件过滤器编码来捕获针对特定网络连接的这种上级协议请求。在这种情况下，NIC能够生成类似于定时器事件的事件，以请求运行在附属计算机上的软件的动作和一个传送数据消息。通过以这种方式触发事件，NIC能够得到这样的结果：传输库和内核帮助程序之一得到请求就立即动作。这样可以避免直到传输库被调度时才执行内核扩展这一潜在问题，如果需要还可以应用到其它上级协议。
对于协处理器TCP实现，已经具有的一个优点是，在发送和接收时具有执行零复制操作的能力。实际中，如果在接收路径上(关于如上所述的架构)没有上下文交换或其它缓存或TLB(发送旁视缓冲)清理操作，由于这是用于在处理器中装入已接收数据的目的，几乎在接收时没有单一复制的开销。当应用程序后来访问数据时，它不受缓存错误的影响，而对零复制接口情况就不同了。
然而在发送时，传输库进行的单一复制在处理器周期和缓存污染中产生附加的开销。例如，如果可实现下列机制，上述的架构可以避免发送操作时的复制：
(i)能够快速确认发送数据(例如在低延迟环境)；或者
(ii)在一次传递中的所有的数据在发送前，数据几乎被完全地确认(例如若带宽与延迟的乘积小于信息大小)。
传输库能够简单地保持发送缓冲区直到来自它们的数据得到确认，并且不用复制发送数据。这当由应用程序使用异步网络APIs时也可完成。
甚至在数据复制不可避免的地方，传输库可以使用执行非临时存储的内存复制例行程序。这样可以在内存(而非缓存)中留下复制的数据，因此避免了缓存污染。由于传输的下一步骤将是通过网络接口设备的数据DMA，并且在内存而非缓存中的数据不可能影响DMA操作的性能，因此不在缓存中的数据不会影响性能。
图6示出了可由上述网络接口设备所采取的过滤一个入TCP分组的步骤。在步骤i，网络接口设备从网络上接收分组，该分组进入接收解码线路。在步骤ii，硬件从分组选取相关比特形成出现在CAM的过滤器(本例中为32比特长)。配置和相关比特的数量取决于使用的协议；这个例子涉及TCP/IP和UDP/IP。在步骤iii，当进行CAM匹配时，产生一个返回的索引：MATCH-IDX，可用于查看送达信息(例如这个连接的下一个接收缓冲区的内存地址)。在步骤iv，将送达信息反馈给分组解码线路并将分组送达适当的内存位置。
下面说明比特的选择和它们形成过滤器的用法。
确定CAM过滤器配置的逻辑取决于将要使用的协议。在实际的实现中，CAM可以由虚拟接口通过使用传输库代码来配置，为了特殊的实现允许将其动态地建立。
在TCP协议下，为了清楚的指定唯一的端点标识，通常需要所有的主机和端口字段。出现这个需求是因为TCP协议定义允许：多个客户端用相同的目的主机和端口地址连接网络端点，既可从客户端也可从服务器、或者服务器网络端点初始化连接，以在单一的端点接受连接请求并且生成新的网络端点处理数据传递。
典型地，这种分组标头的长度是是96比特。然而，由于通常商业上可用的CAM多为64或128(而非96)比特长，因此用现有CAM构建96位的过滤器效果不佳。上述机制能够更有效的构建64位过滤器。可以选择CAM的长度以适合应用程序。一个合适的尺寸是16kb。
网络接口设备为了能够在实行中暂停网络标头，其可以中断或缓冲进入的分组流。这样使得它能够不影响数据流而在入分组中识别相关比特序列。对于TCP和/或UDP分组，由于这种分组的标头布局简单，因此可以使用，例如一个简单的解码线路实现比特序列的识别。这样导致许多字段保持在寄存器中。
假定零既不是有效的端口数字也不是有效的IP地址，且在独立的进程中接口不共享本地IP地址和端口对(除了在fork()或相当的命令后共享套接口)。后面的条件意味着当对接收到的TCP分组解复用时，不考虑本地IP地址是安全的。
对于一个监听TCP套接口，仅需考虑本地IP和端口数字，反之，对于一个已建立的TCP套接口，远程IP和端口数字均应考虑。因此，由网络接口设备执行的处理(通常在硬件中)确定接收到的分组是TCP还是UDP分组，对于TCP分组，必须检查SYN及ACK比特。因此，可以形成一个在CAM中查找的令牌。下面的表格示出了CAM的操作：
比特0-31     比特32-47   比特48-63
A  TCP SYN＝1&ACK＝0 本地(目的)IP     0   目的端口
B  TCP其它情况时 远程(源)IP     源端口   目的端口
C  UDP 本地(目的)IP     目的端口   0
表格1
在这个表格中，第一列表示接收到的分组的类型，其它列分别表示令牌的前32比特、中间16比特和最后的16比特的内容。假设使用相同的惯例，比特的顺序就是不重要的。
表格1按A、B和C行示出了三种过滤器布置的类型。应当认为假设在装入CAM时和在执行查找时所使用的数据的形式间保持一致，比特的顺序是不重要的。
在多数情况下，当在NIC和它的主机设备(例如与之相连的数据处理设备)之间配置数据信道时，在CAM的一行或多行装入数据使得通过执行下述程序由NIC传送该信道所需的分组。对于在CAM内的每一行，该行相关的信道的标识符的指示由NIC在，例如一个第二CAM中，存储。通过这样，当一个入分组一旦与CAM特殊行匹配，NIC就通过第二查找操作确定将该分组送至哪个信道。当所述信道毁坏时，就从CAM中删除相应的数据。
当接收入分组时，由NIC提取在它的标头内的数据子集并排序来形成对CAM的查找输入数据。将该查找输入数据应用于CAM，用以返回任何匹配地址。根据是配查找到匹配及匹配的性质，由CAM决定是允许将分组传送到主机还是抛弃它。哪些数据将从标头提取及其排列的顺序取决于哪种过滤器布置会被使用。选择表格1中的A、B和C行的过滤器布置，使得对于根据过滤器配置之一排序的有效分组标头的组件，可能没有与另一个过滤器配置有关的CAM的匹配。
对于用CAM处理接收到的TCP和UDP分组，可使用多个程序模式。TCP模式的选择与UDP模式的选择是相独立的。
处理接收到的分组的第一个步骤是确定分组是TCP还是UDP分组。根据所选择的一个TCP模式处理TCP分组。根据所选择的一个UDP模式处理UDP分组。
TCP模式1
如上所述为TCP模式1。进行一个校验以确定TCP分组是SYN分组不是ACK分组，即确定SYN比特被设置为1且ACK比特设置为0。如果是这样，根据过滤器配置A执行CAM查找：即按照比特0-31为本地(目的)端口、比特32-47为零、比特48-63为本地(目的)端口的顺序形成64比特字符串，并应用到CAM。如果不是这样，则根据过滤器配置B执行CAM查找：即以比特0-31为远程(源)地址、比特32-47为远程(源)端口、比特48-63为本地(源)端口形成64比特字符串。在每个情况中，如果存在匹配，NIC将分组传送到适当的主机信道，否则抛弃它或者将其传送到能够由运行在主机上的软件处理的主机默认信道。
TCP模式2
TCP模式1的缺点为每个信道需要CAM内的一行。对于支持非常多的远程主机连接的服务器，例如很大负荷的万维网服务器，将需要很长的CAM。采用TCP模式2可克服这个缺点。
在TCP模式2中，根据过滤器配置B对所有TCP分组执行CAM检查。如果存在匹配，NIC将分组传送到适当的主机信道，否则抛弃它。
如果使用这个模式，对每个目的地址在主机上只能有一个传输库。然而，不需要为每个有连接的源地址在CAM中配置一行。
TCP模式3
在TCP模式3中，根据过滤器布置B对所有TCP分组执行CAM查找。如果存在匹配，NIC将分组传送到主机的适当信道，否则NIC根据过滤器布置A执行CAM查找。如果存在匹配，NIC将分组传送到主机的适当信道，否则抛弃它。这些过滤步骤的顺序可以颠倒，但不是最佳方式。
本模式的优点为避免了对每个连接的需要单一CAM条目，同时可以支持多个传输库。
UDP模式1
在UDP模式1中，根据过滤器布置C对所有UDP分组执行CAM查找。如果存在匹配，NIC将分组传送到适当的主机信道，否则抛弃它。
UDP模式2
UDP模式1的缺点为它不支持NIC级的已连接的UDP，希望简化主机所需要的处理。在已连接的UDP中，主机能指定信道一个远程的主机地址：端口对是唯一的在该信道上接收分组的一个，来自远程主机的UDP分组将被路由到该信道。
UDP模式2支持已连接的UDP。如表格2中所示，提出了附加的过滤器布置D1和D2。必须对任何已连接的UDP的连接都要配置，并且在连续的CAM行内建立。对于其它UDP连接，由于与其它过滤器布置不同，比特0-31被设为0，这些行不形成匹配。
  比特0-31 比特32-47   比特48-63
 D1   0 远程(源)IP   源端口
 D2   0 本地(目的)IP   目的端口
表格2
在UDP模式2中，根据过滤器配置D1对所有UDP分组执行CAM查找。如果存在匹配，则NIC存储进行匹配的行的地址并根据过滤器布置D2执行CAM查找。如果在第一次查找产生匹配的行之后在CAM行上立即有匹配，则NIC将分组传送到主机的适当信道，否则抛弃它。如果在第一次查找没有匹配，则根据过滤器布置C执行CAM查找。如果存在匹配，则NIC将分组传送到适当的主机信道，否则抛弃它。
由于一些模式需要对每个分组进行两次CAM查寻，如果支持上述所有模式，CAM应当能够支持查找速率是NIC的数据进入速率的至少两倍。使用CAM的选择包括执行每个查找步骤的散列技术：例如，基于RAM的散列。
下表给出了数据如何形成的例子：
 分组类型   比特0-31  比特32-47   比特48-63
 1.TCP监听   192.168.123.135  0   80
 2.TCP已建立   66.35.250.150  33028   80
 3.TCP已建立   66.35.250.150  23   28407
 4.UDP   192.168.123.135  123   0
表格3
在此例中，数字1表示本地万维网服务器在192.168.123.135：80上监听的情形；数字2表示由该服务器从66.35.250.150：33028接收的连接的情形；数字3表示开始与本地的远程登录(telnet)连接到66.35.250.150；数字4表示应用程序在端口123接收UDP分组的情形。
如表格1的第一行，通过分出TCP SYN＝1 & ACK＝0的情形，可以确定该项目匹配TCP连接请求信息(在LISTEN状态时指定的套接口)，但是不匹配连接应答(在SYN-SENT状态时指定的套接口)。
可以使用零字段的其它组合在其它字段上解复用。例如，可以在Ethernet标头的ETHER-TYPE字段上执行解复用。
通过如图7中所示的服务器(PASSIVE)连接的例子，CAM(由服务器传输库编程)的内容和由NIC在每个分组上送到CAM的过滤器示出上述程序。包括以下步骤：
(a)传输库通过驱动程序分配CAM条目。
(b)驱动程序通过它的被保护的控制接口对硬件编程以将已分配的CAM映射到分配在传输库的虚拟接口地址空间。
(c)传输库通过它的虚拟接口对CAM项目编程。在认为应用程序没有足够的访问权接收可编程的CAM项目时，通过OS调用可运行获得允许。
(ii)TCP/IP连接分组到达。因为在分组标头的SYN比特被置为1且分组标头的ACK比特被置为零，网络接口设备可以从分组标头的比特建立过滤器：
{dest host，0，dest port}
并将其送到CAM。这引起匹配产生CAM索引X。网络接口设备能够检查并且在SRAM内找到虚拟接口β的基地址。NIC能够将分组送达到虚拟接口β。
由于连接分组，服务器应用程序可以产生另一个网络端点来处理网络连接。该端点可以在它自己或另一个应用程序上下文的内部，因此可以由另一个传输库来管理。在任一情况下，可产生网络连接：
{dest host，port}
至
{source host，port}
服务器对新CAM项目编程：
{source host，source port，dest port}。
(iii)当分组到达新网络连接，将使它的SYN比特置为零，使得NIC构建过滤器：
{source，host source port，dest port}
当送到CAM时，产生索引θ，在SRAM中与虚拟接口σ相匹配。应当注意的是如果由与服务器端点相同的传输库管理网络连接，σ可以与β相同。
相似地，这一编码，可用于对于由主机初始化的活动(客户机)连接和在TCP和UDP协议说明中指定的所有通信模型。
编码设计的显著好处是能使硬件仅使用一个CAM查找来确定虚拟接口的地址。
网络接口最好也支持能简单地将分组解复用到传输库上而不是到网络端点上的操作模式。这对于设备在网络和需要同时服务大量网络连接的服务器之间处理通信是有益的。这个例子可以是高容量的万维网服务器节点。可以有两个选择。一个选择是将
{dest host，dest port}
形式的过滤器存储在CAM中。另一个选择是使用三组CAM，能够屏蔽使用“don′t care”比特。应当注意的是，如果两个可同时被使用，因为由于当在接收到的SYN比特被置为零可能需要两个CAM检查，就可能使效率降低。如果在一个时间仅可使用一个模式，将会避免这个需求。
这样，使用64比特的CAM可匹配TCP/IP和UDP/IP，如果使用在整个标头采用比特-比特匹配的标准大小的CAM，将需要128比特的CAM。
申请人分别披露了所述每个单独的特点和两个或多个这些特点的组合，在这种意义上，不管这些特点或组合是否解决这里所披露的所有问题，不限制权利要求的范围，按照本领域技术人员的通常的整体知识，基于本说明能够实现这些特点和组合。申请人指出本发明可以包括这些单独的特点或者这些特点的组合。由于前面的描述，这是显然的对于本领域技术人员在本发明的范围内可作出各种修改。

Claims (16)

1.一种在主机设备与网络之间提供接口的网络接口设备，用于在网络上接收分组并至少将这些分组中的一些送到主机设备的端口，每个分组包括控制部分，所述控制部分具有一个或多个表示分组的类型及数据协议的字段、一个表示分组源地址的源地址字段、一个表示分组目的地址的目的地址字段、一个表示分组源地址的源端口字段和一个表示分组目的地址的目的端口字段；该网络设备包括：
一个用于存储将被送到所述主机设备的分组说明的数据存储器，每个说明包括第一、第二和第三校验字段；以及
一个根据数据存储器的内容来选择哪个在网络上接收到的分组将被送到所述主机设备的分组选择单元；
所述分组选择单元能够识别所收到分组的协议，并按至少以下模式之一进行操作：
第一种模式为，对于第一协议和表示要建立一种新连接请求的类型的分组，仅当所述数据存储器存储的说明为第一校验字段匹配分组的目的地址、第二校验字段匹配预留的数据报且第三校验字段匹配分组的目的端口时，将这种分组送到主机设备；以及
第二种模式为，对于第二协议的分组，仅当所述数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配分组的目的端口且第三校验字段匹配预留的数据报时，其将这种分组送到主机设备。
2.如权利要求1所述的网络接口设备，其中，在第一模式中，对于没有表示建立一个新连接的请求的第一协议的分组，仅当所述数据存储器存储一个说明，该说明为第一校验字段匹配分组的源地址、第二校验字段匹配分组的源端口且第三校验字段匹配分组的目的端口时，所述分组选择单元可进行将这种分组送到主机设备的操作。
3.如权利要求1或2所述的网络接口设备，其中，所述分组选择单元可按照第三模式进行操作，在第三模式中：对于第一协议的所有分组，仅当所述数据存储器存储了一个说明，该说明为第一校验字段匹配分组的源地址、第二校验字段匹配分组的源端口且第三校验字段匹配分组的目的端口时，所述分组选择单元将这种分组送到主机设备。
4.如之前任一权利要求所述的网络接口设备，其中，所述分组选择单元可按照第四模式进行操作，在第四模式中：对于第一协议的所有分组，仅当所述数据存储器存储的一个说明为第一校验字段匹配分组的目的地址、第二校验字段匹配预留的数据报且第三校验字段匹配分组的目的端口，或者当所述数据存储器存储的一个说明为第一校验字段匹配分组的源地址、第二校验字段匹配分组的源端口且第三校验字段匹配分组的目的端口时，所述分组选择单元将这种分组送到主机设备。
5.如权利要求3或4所述的网络接口设备，其中，所述分组选择单元可选择地按照第一模式和它支持的第三或第四模式之一的模式进行操作。
6.如之前任一权利要求所述的网络接口设备，其中，所述分组选择单元可按照第五模式进行操作，在第五模式中：对于第二协议的所有分组，仅当所述数据存储器存储一个第一说明为第一校验字段匹配预留的数据报、第二和第三校验字段中的一个匹配分组的源地址且第二和第三校验字段中的另一个匹配分组的源端口时，且当所述数据存储器以一种与第一说明的预先确定关系相关联的方式存储的一个第二说明为第一校验字段匹配预留的数据报、所述第二和第三校验字段中的一个匹配分组的源端口且所述第二和第三校验字段中的另一个匹配分组的目的端口时，所述分组选择单元将这种分组送到主机设备。
7.如权利要求6所述的网络接口设备，其中，所述预先确定关系为在存储器中以与第一说明预先确定的间隔存储第二说明。
8.如权利要求6或7所述的网络接口设备，其中，分组选择单元可选择地按照第二和第五模式之一的模式进行操作。
9.如之前任一权利要求所述的网络接口设备，其中，预留数据报的所有比特都为零。
10.如之前任一权利要求所述的网络接口设备，其中，第一协议为TCP协议。
11.如权利要求10所述的网络接口设备，其中，表示建立新连接的请求的类型为SYN比特为1且ACK比特为0的类型。
12.如之前任一权利要求所述的网络接口设备，其中，第一校验字段的长度为32比特。
13.如之前任一权利要求所述的网络接口设备，其中，第二校验字段的长度为16比特。
14.如之前任一权利要求所述的网络接口设备，其中，第三校验字段的长度为16比特。
15.如之前任一权利要求所述的网络接口设备，其中，数据存储器为内容可寻址内存。
16.如权利要求15所述的网络接口设备，其中，内容可寻址内存的宽度为64比特。
CN200580012679.5A 2004-04-21 2005-04-08 处理分组标头 Pending CN1965542A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0408870.4 2004-04-21
GBGB0408870.4A GB0408870D0 (en) 2004-04-21 2004-04-21 Processsing packet headers

Publications (1)

Publication Number Publication Date
CN1965542A true CN1965542A (zh) 2007-05-16

Family

ID=32344131

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200580012679.5A Pending CN1965542A (zh) 2004-04-21 2005-04-08 处理分组标头

Country Status (5)

Country Link
US (1) US20070076712A1 (zh)
EP (1) EP1738544A1 (zh)
CN (1) CN1965542A (zh)
GB (1) GB0408870D0 (zh)
WO (1) WO2005104453A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7984180B2 (en) 2005-10-20 2011-07-19 Solarflare Communications, Inc. Hashing algorithm for network receive filtering
CN101030843B (zh) * 2007-03-22 2010-05-19 ***通信集团公司 多媒体会议控制模式的转换方法
US20080298354A1 (en) * 2007-05-31 2008-12-04 Sonus Networks, Inc. Packet Signaling Content Control on a Network
US9825913B2 (en) * 2014-06-04 2017-11-21 Nicira, Inc. Use of stateless marking to speed up stateful firewall rule processing
US11683621B2 (en) * 2021-09-22 2023-06-20 Bose Corporation Ingress resistant portable speaker

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452455A (en) * 1992-06-15 1995-09-19 International Business Machines Corporation Asynchronous command support for shared channels for a computer complex having multiple operating systems
EP0610677A3 (en) * 1993-02-12 1995-08-02 Ibm Communication device management module operating in two modes.
US5606668A (en) * 1993-12-15 1997-02-25 Checkpoint Software Technologies Ltd. System for securing inbound and outbound data packet flow in a computer network
US5802320A (en) * 1995-05-18 1998-09-01 Sun Microsystems, Inc. System for packet filtering of data packets at a computer network interface
US6070219A (en) * 1996-10-09 2000-05-30 Intel Corporation Hierarchical interrupt structure for event notification on multi-virtual circuit network interface controller
US7284070B2 (en) * 1997-10-14 2007-10-16 Alacritech, Inc. TCP offload network interface device
US6988274B2 (en) * 1998-06-12 2006-01-17 Microsoft Corporation Method, system, and computer program product for representing and connecting an underlying connection-oriented device in a known format
US6768992B1 (en) * 1999-05-17 2004-07-27 Lynne G. Jolitz Term addressable memory of an accelerator system and method
US6751701B1 (en) * 2000-06-14 2004-06-15 Netlogic Microsystems, Inc. Method and apparatus for detecting a multiple match in an intra-row configurable CAM system
US6675200B1 (en) * 2000-05-10 2004-01-06 Cisco Technology, Inc. Protocol-independent support of remote DMA
JP3601445B2 (ja) * 2000-12-06 2004-12-15 日本電気株式会社 パケット転送装置及びそれに用いる転送情報管理方法並びにその転送情報検索方法
US6744652B2 (en) * 2001-08-22 2004-06-01 Netlogic Microsystems, Inc. Concurrent searching of different tables within a content addressable memory
US7719980B2 (en) * 2002-02-19 2010-05-18 Broadcom Corporation Method and apparatus for flexible frame processing and classification engine
JP4406604B2 (ja) * 2002-06-11 2010-02-03 アシシュ エイ パンドヤ Ｔｃｐ／ｉｐ、ｒｄｍａ、及びｉｐストレージアプリケーションのための高性能ｉｐプロセッサ
US7171439B2 (en) * 2002-06-14 2007-01-30 Integrated Device Technology, Inc. Use of hashed content addressable memory (CAM) to accelerate content-aware searches
US7313667B1 (en) * 2002-08-05 2007-12-25 Cisco Technology, Inc. Methods and apparatus for mapping fields of entries into new values and combining these mapped values into mapped entries for use in lookup operations such as for packet processing

Also Published As

Publication number Publication date
EP1738544A1 (en) 2007-01-03
GB0408870D0 (en) 2004-05-26
US20070076712A1 (en) 2007-04-05
WO2005104453A1 (en) 2005-11-03

Similar Documents

Publication Publication Date Title
US10838891B2 (en) Arbitrating portions of transactions over virtual channels associated with an interconnect
CN101047714B (zh) 一种处理网络数据的方法及***
US8005084B2 (en) Mirroring in a network device
CN100552626C (zh) 用网络栈同步和上载已卸载网络栈连接的方法
US7643477B2 (en) Buffering data packets according to multiple flow control schemes
US8249072B2 (en) Scalable interface for connecting multiple computer systems which performs parallel MPI header matching
CN101156408B (zh) 用于操作***分区的网络通信
CN100478926C (zh) 发送数据的方法和***及接收数据的方法和***
US8363654B2 (en) Predictive packet forwarding for a network switch
US8095686B2 (en) Method and system for communicating information between a switch and a plurality of servers in a computer network
EP2486715B1 (en) Smart memory
US11277350B2 (en) Communication of a large message using multiple network interface controllers
US7570639B2 (en) Multicast trunking in a network device
US8756270B2 (en) Collective acceleration unit tree structure
WO2003036902A2 (en) Method and apparatus for a packet classifier using a two-step hash matching process
CN102904871A (zh) 流分配
US20050097300A1 (en) Processing system and method including a dedicated collective offload engine providing collective processing in a distributed computing environment
US7124231B1 (en) Split transaction reordering circuit
US20100142536A1 (en) Unicast trunking in a network device
CN1965542A (zh) 处理分组标头
US7733857B2 (en) Apparatus and method for sharing variables and resources in a multiprocessor routing node
US20150003237A1 (en) Traffic Data Pre-Filtering
US8085766B2 (en) S-flow in a network device
US8325768B2 (en) Interleaving data packets in a packet-based communication system
US20050169169A1 (en) Determination of an endpoint association from a transport address

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20090313

Address after: American California

Applicant after: Solarflare Communications Inc.

Address before: california

Applicant before: LEVEL 5 Networks Inc.

ASS Succession or assignment of patent right

Owner name: SOLFUREIL COMMUNICATION CO., LTD.

Free format text: FORMER OWNER: LEVEL5 NETWORK CO., LTD.

Effective date: 20090313

C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Open date: 20070516