CN1703022A - 协商链路集聚的链路协议的方法和设备 - Google Patents

Abstract

本发明提供了一种为一个有一些数据分组要发送的会话协商协议的方法、设备和计算机指令。响应与一个会话端点建立一个链路集聚，选择一个处理在会话中的数据分组的算法，以形成一个优选算法。将一个请求发送给这个端点，这个请求指出处理会话中的数据分组的优选算法。从这个端点接收到一个对这个请求的应答后，确定是否已经发生会聚。响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

Description

协商链路集聚的链路协议的方法和设备

技术领域

本发明与一种得到改善的数据处理系统有关，具体地说，与一种处理数据的方法和设备有关。再具体些说，本发明与用链路集聚(linkaggregation)传送数据的方法、设备和计算机指令有关。

背景技术

随着要用越来越高的速率传送数据的需求的增大，1Gbit/s对于局域网(LAN)交换机之间和从交换机到高要求的网络服务器的许多网络连接来说已经不算是足够的带宽。随着因特网业务供应商(ISP)、应用业务供应商、流媒体供应商等的消耗带宽的应用，传统的网络管理员也可能感觉到他们的服务器连接带宽紧张。业已用干线形成或链路集聚来增大带宽。链路集聚包括允许一个数据处理系统将一个以上的网络接口处理为单个网络接口。也就是说，可以将数据处理系统之间的若干不同的链路“集聚”成单个链路。

除了增大带宽之外，链路集聚还保证了更高的可靠性。历来，为了集聚一个以上的网络接口需要网络管理员人工干预。管理员必须指定在主机(例如，AIX服务器)和在接有网络适配器的交换机上需集聚的接口。这个规定是必需的，因为交换机需要知道发往链路集聚的业务量可以通过任何属于这种集聚的适配器发送。

已经在创建链路集聚的自动化上做了一些工作，诸如IEEE802.3ad标准之类。这个标准规定了网络主机与交换机交换链路集聚控制协议数据单元(LACPDU)分组以决定哪些适配器需集聚在一起的链路集聚控制协议(LACP)。用这些适配器的固有特性(如，双工性和链路速度)来决定哪些适配器属于相同的链路集聚。

IEEE 802.3ad标准规定，所有属于同一个会话(conversation)的分组必须通过同一个适配器发送，以防止链路级的分组重排(reordering)。达到这样传送一个会话的数据的方式是与实现相关的。一个会话是在两个端点之间传送有关数据。会话的一个例子是两个主机之间的会话。一个会话是两个数据处理系统之间的活动连接(active connection)。此外，主机和交换机可以用不同的方式来决定通过哪个适配器发送属于同一个会话的分组。这种情况意味着相当可能从主机发送给交换机的数据分组通过一个适配器发送，而从交换机发回主机的应答数据分组则通过另一个适配器发送。这样发送数据分组是标准所允许的，因为在两个方向上都没有发生分组重排。在传统的网络协议组中，这种情况不是一个问题。

然而，在处理传输控制协议(TCP)卸载的适配器时，这种情况可能就成为一个问题。在TCP卸载的适配器内，TCP/因特网协议(IP)是在适配器的硬件内实现的。因此，通过一个专用配器进行的所有TCP连接的状态包含在适配器内，而不是包含在相同主机上的所有连接之间共享的一个全系统范围的TCP层内。

这种配置使得应答数据分组势必在发送外出数据分组的同一个适配器上接收，因为只有这个适配器知道接收和处理所述应答分组所必需的TCP状态。例如，如果一个数据分组是在适配器1上发送的而它的应答是在适配器2上接收的，适配器2就没有处理这个应答分组所必需的TCP状态。结果，这个应答就要被废弃掉。TCP状态信息的例子包括预期的序号和超时信息。

在现有的自动链路集聚标准中，没有使一个主机与一个交换机可以协商应该用哪个算法来决定应该用哪个适配器来发送属于同一个会话的分组的方式。因此，能有一种得到改善的形成一个链路集聚的方法、设备和计算机指令将是有益的。

发明内容

本发明提供了一种为一个有一些数据分组要发送的会话协商协议的方法、设备和计算机指令。响应与一个会话端点(endpoint)建立一个链路集聚，选择一个处理在会话中的数据分组的算法，以形成一个优选算法。将一个请求发送给这个端点。这个请求指出处理会话中的数据分组的优选算法。从这个端点接收到一个对这个请求的应答后，确定是否已经发生会聚(convergence)。响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

附图说明

本发明的新颖特征在所附权利要求书中给出。然而，从以下结合附图对一个例示性实施例所作的详细说明中可以很好地理解本发明本身及其应用的优选方式、其他目的和优点，在这些附图中：

图1为一个可以实现本发明的一些数据处理系统构成的网络；

图2为按照本发明的一个优选实施例设计的可以作为一个服务器实现的数据处理系统的方框图；

图3为例示一个可以实现本发明的数据处理系统的方框图；

图4为可以实现本发明的一个优选实施例的组成部分的示意图；

图5为可以实现本发明的一个优选实施例的组成部分的另一个例子；

图6为按照本发明的一个优选实施例设计的协议组的示意图；

图7为按照本发明的一个优选实施例设计的数据协议单元的例子；

图8为按照本发明的一个优选实施例设计的启动协商一个处理在一个链路集聚内的数据分组的算法的过程的流程图；以及

图9为按照本发明的一个优选实施例设计的协商一个处理在一个链路集聚内的数据分组用的算法的过程的流程图。

具体实施方式

现在来看这些附图，图1示出了一个可以由一些可以实现本发明的数据处理系统组成的网络。网络数据处理系统100是一个可以实现本发明的计算机网络。网络数据处理系统100含有一个网络102，它是用来提供网络数据处理系统100内连接在一起的各个设备和计算机之间的通信链接的媒体。网络102可以包括诸如有线、无线通信链路或光缆之类的连接。

在所示这个例子中，服务器104与存储单元106一起接到网络102上。此外，客户机108、110和112也接到网络102上。客户机108、110和112可以例如是个人计算机、网络计算机或个人数字助理(PDA)设备。在所示这个例子中，服务器104为客户机108-112提供诸如引导文件、操作系统映像和应用程序之类的数据。客户机108、110和112是服务器104的客户机。服务器104可以作为一个促进诸如客户机106、110和112之类的客户机的用户之间的消息交换的即时消息传送服务器。网络数据处理系统100可以包括图中未示出的其他服务器、客户机和其他设备。

在所示这个例子中，网络数据处理系统100是具有网络102的因特网，表示用传输控制协议/因特网协议(TCP/IP)协议组相互通信的网络和网关的一个世界范围的集合体。因特网的核心是一个在包括数以千计的民用、政府、教育及其他计算机系统的主节点或主计算机之间传送数据和消息的高速数据通信线路的主干网。当然，网络数据处理系统100也可以实现为若干不同类型的网络，诸如内部网、局域网(LAN)或广域网(WAN)之类。图1只是作为一个例子，而不是作为对本发明在体系结构上的限制。

来看图2，图中示出了按照本发明的一个优选实施例设计的一个可以实现为诸如图1中的服务器104之类的服务器的数据处理系统的方框图。数据处理系统200可以是一个包括多个接到系统总线206上的处理器202和204的对称多处理器(SMP)系统。或者，也可以采用一个单处理器系统。也接到系统总线206上的有存储器控制器/高速缓存208，它提供了一个对本地存储器209的接口。I/O总线桥210接到系统总线206上，用来提供一个对I/O总线212的接口。存储器控制器/高速缓存208和I/O总线桥210可以如图所示那样集成在一起。

接到I/O总线212上的外围组件互连(PCI)总线桥214提供了一个对PCI本地总线216的接口。一些调制解调器可以接到PCI本地总线216上。典型的PCI总线实现将支持四个PCI扩展槽或内装连接器。接至图1中客户机108-112的通信链路可以通过经内装板、经由接到PCI本地总线216上的调制解调器218和网络适配器220提供。

其他的PCI总线桥222和224提供了对可以支持其他调制解调器或网络适配器的其他PCI本地总线226和228的接口。这样，数据处理系统200就允许对多个网络计算机的连接。存储映像图形适配器230和硬盘232也可以如图所示直接或间接地接到I/O总线212上。

熟悉该技术领域的一般人员可以理解，图2所示的这些硬件可以有所不同。例如，也可以使用一些诸如光盘驱动器之类的其他外部设备，补充或代替所示的硬件。所示这个例子并不是意味着对本发明体在系结构上的限制。

图2所示的数据处理系统可以是例如IBM的运行高级交互执行(AIX)操作系统或LINUX操作系统的eServer pSeries系统，国际商业机器公司(Armonk，New York)的一种产品。

现在来看图3，图中示出了一个可以实现本发明的数据处理系统的方框图。数据处理系统300是客户机计算机的一个例子。数据处理系统300采用外围组件互连(PCI)本地总线体系结构。虽然所示这个例子用的是PCI总线，但也可以用其他总线体系结构，诸如加速图形端口(ASP)和工业标准体系结构(ISA)。处理器302和主存储器304通过PCI桥308接到PCI本地总线306上。PCI桥308还可以包括一个用于处理器302的集成存储器控制器和高速缓存器。其他与PCI本地总线306的连接可以通过直接组件互连或通过内装板实现。在所示这个例子中，局域网(LAN)适配器310、SCSI主机总线适配器312和扩展总线接口314都通过直接组件连接接到PCI本地总线306上。相反，音频适配器316、图形适配器318和音频/视频适配器319通过插入扩展槽的内装板接到PCI本地总线306上。扩展总线接口314提供对键盘和鼠标适配器320、调制解调器322和附加存储器324的连接。小型计算机系统接口(SCSI)主机总线适配器312提供对硬盘驱动器326、磁带驱动器328和CD-ROM驱动器330的连接。典型的PCI本地总线实现支持四个PCI扩展槽或内装连接器。

操作系统在处理器302上运行，用来协调和提供对图3所示的数据处理系统300内各个组件的控制。这个操作系统可以是一个市售的诸如Microsoft公司的Windows XP的操作系统。诸如Java之类的面向对象的程序设计系统可以配合这个操作系统运行和提供从在数据处理系统300上执行的Java程序或应用对操作系统的调用。“Java”为Sun微系统公司的商标。操作系统、面向对象的程序设计系统和应用或程序位于诸如硬盘驱动器326的存储设备上，可以装入主存储器304，以便由处理器302执行。

熟悉该技术领域的一般人员可以理解，图3所示的硬件可以根据实现而有所不同。诸如快速只读存储器(ROM)、等效的非易失存储器或光盘驱动器之类的其他内部硬件或外部设备可以补充或代替图3中所示的硬件。此外，本发明的过程可以用于多处理器数据处理系统。

图3所示的例子和以上所说明的例子并不意味着对体系结构有所限制。例如，除呈现为一个PDA外，数据处理系统300也可以是一个笔记本计算机或手持式计算机。数据处理系统300也可以是一个公用信息机或Web设备。

本发明提供了一种为处理链路集聚内的数据分组协商协议的方法、设备和计算机指令。本发明的一个机构提供了一种配合或通过诸如IEEE标准802.3ad之类的现有链路集聚协议进行操作的算法协商协议。现有的链路集聚协议处理那些属于一个特定集聚组的适配器。本发明的机制用来识别一个用来通过链路集聚传送数据分组的算法或过程。

来看图4，图中示出了可以实现本发明的优选实施例的一些组成部分的示意图。在这个例子中，交换机400和交换机402用来在服务器404和服务器406之间发送数据。服务器可以用一个诸如图2所示的数据处理系统200之类的数据处理系统实现。对于在交换机400和交换机402内的适配器给出了链路集聚408。本发明的这种机制用来为处理通过链路集聚408传送的数据分组选择一个算法或过程。在这个具体的例子中，算法协商协议可以用交换机400和交换机402内所含有的计算机指令实现。

来看图5，图中例示了可以实现本发明的一个优选实施例的一些组成部分的另一个例子。如图所示，服务器500和服务器502提供了在客户机504、客户机506、服务器508、客户机510和客户机512之间传送数据的连接。链路集聚514用来保证所希望的带宽。用来处理通过链路集聚514传送的数据分组的过程或算法在这些例示性例子中在服务器500和服务器502内实现。

现在来看图6，图中示出了一个按照本发明的一个优选实施例设计的协议组的示意图。协议组600在这个例子中是一个TCP/IP协议组，协议组600包括应用层602、传送层604、网络层606、数据链路层608和物理层610。应用层602在协议组600内是顶层，定义用来与其他程序通信的语言和句法。传送层604保证整个文件或消息的传递。这个层负责在一个会话传输中全部端到端的合法性和完整性。

网络层606用来为不同端点之间的数据进行路由选择。数据链路层608负责在节点之间发送数据分组。物理层610负责发送和接收连接媒体的比特。算法协商协议612包含在数据链路层608内。

在图4和5所示的例子中，端点之一，例如服务器500或交换机400，在一个链路集聚已经建立后启动算法协商协议。在这些例示性例子中协议是可扩展的，因此可以添加一些其他方案。

如所说明的那样，这个协议支持处理通过链路集聚传送的数据分组的基本算法。算法的例子从“最好”到“最差”为：(1)源/宿传输控制协议/用户数据报协议(TCP/UDP)端口，用的是分组的源(或宿)TCP或UDP端口；(2)源/宿IP地址，用的是分组的源(或宿)IP地址的最后一个字节；以及(3)源/宿MAC地址，用的是分组的源(或宿)MAC地址的最后一个字节。

在本发明的这些例示性例子中的协议认为TCP/UDP端口算法是一个“较好的”算法，因为这个算法可能给出比IP地址算法好的分组分发，而IP地址算法可以得到比MAC地址算法好的分组分发。然而，如果其中一个端点不愿意或不能用一个特定的算法，算法协商协议就退回到下一个所希望的处理数据分组的算法。MAC地址算法必须是支持这个协议的所有主机可用的。此外，即使选择TCP/UDP端口算法，如果发送的是没有携带一个TCP或UDP净荷的IP分组(例如，ping分组)，就使用IP地址算法。如果分组不是IP分组(例如为ARP分组)，就使用MAC地址算法。

再来看图5，作为这些算法怎样工作的一个例子，假设链路集聚514是一个在服务器500和服务器502之间的3适配器链路集聚。这个集聚具有一个源MAC地址00-11-22-33-44-55。MAC地址算法取MAC地址的最后一个字节(0x55)，对它进行模为适配器数的模运算(0x55modulus 3＝1)，确定使用哪个适配器。用模算符保证了操作的结果小于集聚体内的适配器数。在这个例示性的例子中，由于运算结果为1，就将分组发送给集聚体内的第二个适配器(编号自零开始)。对适配器的编号超出了这个协议的范围，但应指出的是端口已经用由基层的IEEE 802.3ad协议提供的序号唯一标识。

也就是说，在这个例示性例子中的算法协商协议保证两个端点支持同一个算法。在会聚发生后，两个端点，例如图5中的服务器500和服务器502，都知道各自应使用哪个算法，以保证分组通过相同的适配器发送和接收。

在这个例示性例子中，算法协商协议设计成处在一个现有的链路集聚协议的顶上。结果，本发明的协议可以是非常轻型的。在这些实例中，对于一个协议数据单元(PDU)只需要四个8比特字节来达到会聚。

现在来看图7，图中示出了一个按照本发明的一个优选实施例设计的数据协议单元的一个例子。协议数据单元700含有四个8比特字节。这些8比特字节包括版本702、算法704、标志(flag)706和保留708。版本702是一个含有算法协商协议的版本号的字段。算法704标识了由一个端点选择的算法。标志706用来发送端点之间的信息。保留字段供以后协议扩展用。

对于在这些例示性例子中的协议版本1来说，算法704的这些值定义为：0-源MAC地址；1-宿MAC地址；2-源IP地址；3-宿IP地址；4-TCP/UDP源端口；以及5-TCP/UDP宿端口。

在这些例子中，“发送方”为发送分组数据单元的主机或端点。标志706的值定义为(其中比特0为这个8比特字节内最低有效比特)：比特0指出算法是否已会聚；比特1标识发送方希望为主还是从；以及比特2-7保留给将来使用。

在比特0内，值为0意味着算法还没有会聚，而值为1意味着算法已会聚。比特1的值在形成链路集聚的会话中，如果发送方希望为从，就设置为等于0，而如果发送方希望为主，就设置为等于1。

在这些例示性例子中，“主”(master)是希望选择算法的启动端点，而“从”(slave)是选择由启动端点所选的补充(complementary)算法的响应端点。当然，根据具体情况，启动端点也可以是从。

如果启动端点愿意使用TCP/UDP源端口，响应端点如果可以支持这个算法就选择TCP/UDP宿端口。在这些例子中，在一个主机和一个交换机之间发生算法协商，其中主机是启动端点而交换机是响应端点。主机请求它作为主，而交换机实现宣告本身作为从。在这些例子中发生这种情况，因为用户通常是“关心”使用哪个算法的(例如为了使他的较常见的业务类型达到较好的分发)，而交换机是一个被动网元，通常不关心用哪个算法。然而，如果两个端点都选择“主”或两个端点都选择“从”，在这些例示性例子中MAC地址数字较大的端点将成为主而另一个端点将成为从。

用一个典型的分组数据单元交换来达到会聚，希望成为主的启动端点在协议开始时发送一个表示它的优选算法的分组数据单元。此外，启动端点还将标志706内的比特1置位，以告诉另一个端点它想要成为协商中的主。

如果响应端点支持启动端点所规定的算法，响应端点就发送一个指定启动端点在算法704内所指定的算法的补充算法的应答分组数据单元。例如，如果启动端点指定了“TCP/UDP源端口”(值4)，响应端点就在一个应答分组数据单元内发送“TCP/UDP宿端口”(在算法704内的值5)。响应端点还在应答分组数据单元内将标志706内的比特0置位，告诉启动端点，就其而言算法已经发生会聚。

在启动端点接收到这个分组数据单元时，启动端点就用相同的算法值和标志字段内被置位的比特0发送它自己的应答。现在两个端点都知道已经发生会聚，端点应该开始用商定的算法分发数据分组。

另一方面，在从不支持启动端点所发送的分组数据单元内所指定的算法时，协议就协商一个主和从都支持的算法。从启动端点接收到分组数据单元后，响应端点发送一个在算法704内示出它的优选算法和将标志706内比特0和1清为逻辑0以表明其本身为从和还没有发生会聚的状态的应答分组数据单元，在这种情况下，启动端点可以确定是否支持响应端点所选的算法。如果支持这个算法，就向响应端点发送一个应答分组数据单元，指出已会聚。在处理数据分组中使用的优选算法可以从一个清单中选出，在这个例子中两个端点可以遍历这个清单直到在这些例示性例子中发现两个端点都支持的一个算法。

在协议会聚后，主机或启动端点就用所有外发的分组的源TCP端口来确定通过哪个适配器来发送它们。相反，交换机，在这个例子中为响应端点，用所有进入的数据分组的宿TCP端口来确定在哪个适配器上发送它们。这种情况意味着两个端点用相同的值进行计算。由于它们两个使用补充算法和用同一个值予以操作，因此保证了两侧将最终在相同的适配器(即含有处理分组所必需的TCP状态的适配器)上发送分组。

在另一个例示性例子中，响应端点发送一个应答分组数据单元，告诉启动端点响应端点不支持启动端点所建议的算法，而是支持清单中下一个算法。在这个例子中，算法是“源IP地址”。在这种情况下，启动端点就发送一个第二应答分组数据单元，通过将图7中的标志706内的比特1和0置位为逻辑1来指定“宿IP地址”算法。这个信息告诉响应端点启动端点愿意改为使用IP地址算法，并且就该启动端点而言，算法就已经发生会聚。响应端点于是用一个含有相同的算法值和在标志706内被置位的比特0作出响应。现在，两个端点在处理端点之间形成的链路集聚内的数据分组的算法上达成一致。

作为最后的一个例子，假设响应端点响应指定启动端点本身不支援的算法的初始分组数据单元，发送一个应答数据分组。启动端点通过发送一个指定启动端点支持的下一个最低的算法的应答分组数据单元进行响应。在这种情况下，标志706内的比特1被置位，而比特0清除，因为还没有发生会聚。

响应来自启动端点的这个分组数据单元，如果响应端点支持这个算法，响应端点就返回一个指定启动端点所指定的补充算法的分组数据单元。如果响应端点不支持启动端点所建议的算法，响应端点就返回响应端点支持的下一个最低的算法。算法协商协议内的这个过程一直继续到达到会聚。

虽然这个例示性例子只示出了三组算法，但根据实现方式可以使用其他一些协议。此外，通过至少将源和宿MAC地址包括在算法组内，总是会发生会聚的，因为在最坏的情况下协商将继续到达到这个算法。

现在来看图8，图中示出了按照本发明的一个优选实施例设计的一个启动协商处理在一个链路集聚内的数据分组的算法的过程的流程图。图8所示的过程可以在诸如图2的数据处理系统200之类的数据处理系统内实现。当然，在一个链路集聚内这个过程可以在诸如交换机或路由器之类的其他端点内实现。具体地说，这个机制可以在一个诸如图6中的算法协商协议612之类的算法协商协议内实现。这个过程由一个如以上在例示性例子中所说明的启动端点使用。

过程从选择一个优选算法(步骤800)开始。这个优选算法是从一个列有一些可用来处理数据分组的算法的清单中选出的。在这些个例子中，清单按最优选到最不优选的次序排列这些算法。

然后，产生一个协议数据单元(步骤802)，这个协议数据单元具有一个标识优选算法的值和一些以不同的值设置的标志。这个协议数据单元可以例如是图7所示的协议数据单元700。然后，将这个协议数据单元发送给一个端点(步骤804)。在这个例子中，步骤804中的这个端点是响应端点。

此后，过程等待从响应端点接收对链路集聚的应答(步骤806)。然后，确定是否从响应端点接收到应答协议数据单元(步骤808)。如果接收到应答协议数据单元，就确定在协议数据单元内是否指出会聚(步骤810)。会聚情况可以从一个诸如图7中的标志706之类的标志字段确定。如果在协议数据单元内没有指出会聚，就识别在应答协议数据单元内所指定的一个算法(步骤812)。这个算法是由响应端点选择的一个算法。然后，确定是否支持所指定的算法(步骤814)。如果支持所指定的算法，就向端点发送一个指出会聚的协议数据单元(步骤816)，随后过程结束。

再来看步骤808，如果没有接收到应答协议数据单元，就确定是否已经超时(步骤818)。如果已经超时，就产生一个出错消息(步骤820)，过程结束。然而，如果没有超时，过程就进至如上面所说明的步骤806。

返回到步骤810，如果在协议数据单元内指出会聚，过程也就结束。在步骤814，如果不支持所指定的算法，过程就返回到步骤800，选择下一个优选算法。

现在来看图9，图中示出了按照本发明的一个优选实施例设计的一个协商在处理一个链路集聚内的数据分组中使用的算法的过程的流程图。图9所示的过程可以在诸如图2的数据处理系统200之类的数据处理系统内实现。当然，在一个链路集聚内这个过程可以在诸如交换机或路由器之类的其他端点内实现。具体地说，这个机制可以在一个诸如图6中的算法协商协议612之类的算法协商协议内实现。这个过程由一个如以上在例示性例子中所说明的响应端点使用。

过程从接收到一个协议数据单元(步骤900)开始。这个协议数据单元是从一个启动端点接收到的。然后，确定是否支持在这个协议数据单元内所指定的算法(步骤902)。如果不支持在这个协议数据单元内所指定的算法，就选择一个算法(步骤904)。这个算法可以是根据一个选择方案从一个列有一些算法的列表或组中选出的。

然后，将所选的算法放在一个应答协议数据单元内(步骤906)。然后，将应答协议数据单元发送给启动端点(步骤908)。然后，过程等待来自启动端点的应答协议数据单元(步骤910)。确定是否接收到一个应答(步骤912)。如果接收到应答，就确定在应答内是否指出会聚(步骤914)。如果在应答内指出会聚，就向启动端点返回一个应答，以确认会聚(步骤916)，随后过程结束。

再来看步骤902，如果支持协议数据单元内所指定的算法，过程就进至如上面所说明的步骤916。在步骤912，如果没有接收到应答，就确定是否需要超时(步骤918)。如果需要超时，过程就结束。然而，如果不需要超时，过程就进至如上面所说明的步骤910。在步骤914，如果在应答内没有指出会聚，过程就进至如上面所说明的步骤902。

因此，本发明提供了一种得到改善的处理通过一个链路集聚发送或分发的数据分组的方法、设备和计算机指令。本发明的机制提供了一个决定端点在通过链路集聚传送数据分组中需用什么算法的过程。采用本发明的协议，链路集聚过程可以充分自动化，同时可以通过保证分组在相同连接的相同适配器上发送和接收，与TCP卸载适配器无缝地配合工作。

此外，要注意的是，虽然是以一个功能完全的数据处理系统为背景对本发明进行说明的，但熟悉该技术领域的一般人员可以理解，本发明的机制能以含有各种形式的指令的计算机可读媒体形式分发，而且无论用来实际进行分发所用的承载信号的媒体具体是什么类型，本发明同样可以适用。计算机可读媒体的例子包括：诸如软盘、硬盘驱动器、RAM、CD-ROM、DVD ROM之类的记录型媒体，以及诸如数字和模拟通信系统链路(用诸如射频和光波传送的传送形式的有线或无线通信链路)之类的传输型媒体。计算机可读媒体可以呈现为要在特定数据处理系统内实际使用时解码的经编码的格式。

以上对本发明作了例示性的说明，但这并不是穷举性的或者将本发明局限于所揭示的形式。许多修改和变动对于熟悉该技术领域的一般人员来说都是显而易见的。所以选择和说明这个实施例是为了较好地阐明本发明的原理和实际应用，也为了使熟悉该技术领域的一般人员可以理解本发明的各种为适合要具体使用的情况而作了各种修改的

实施例。

Claims (25)

1.一种在一个数据处理系统内为一个发送数据分组的会话协商协议的方法，所述方法包括下列步骤：

响应与一个会话端点建立一个链路集聚，选择一个处理在会话中的数据分组的算法，以形成一个优选算法；

向所述端点发送一个请求，所述请求指示处理会话中的数据分组的优选算法；

从所述端点接收一个对所述请求的应答；

确定是否已经发生会聚；以及

响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

2.权利要求1的方法，其中所述应答是一个第一应答，而所述方法还包括下列步骤：

响应还没有发生会聚的确定结果，识别在第一应答内指定的一个替代算法；

确定在所述数据处理系统内是否支持所述替代算法；以及

响应在所述数据处理系统内支持所指定的算法的确定结果，向指出会聚的端点发送一个第二应答。

3.权利要求1的方法，其中所述确定步骤包括：

确定所述应答是否指定所述优选算法的一个补充算法。

4.权利要求2的方法，其中通过指定对所述替代算法的补充算法而在第二应答内指出所述会聚。

5.权利要求1的方法，其中所述优选算法是从源媒体访问控制地址算法、宿媒体访问控制地址算法、源因特网协议地址算法、宿因特网协议地址算法、传输控制协议/用户数据报协议源端口算法或传输控制协议/用户数据报协议源端口算法中选出的算法。

6.权利要求1的方法，其中所述请求是一个协议数据单元。

7.权利要求1的方法，其中所述协议数据单元包括算法字段和标志字段的标识。

8.权利要求1的方法，其中标志字段包括一个标明是否已经发生会聚的第一比特和一个指出是请求主职责还是从职责的第二比特。

9.一种用于为一个发送数据分组的会话协商协议的数据处理系统，所述数据处理系统包括：

选择装置，用来响应与一个会话端点建立一个链路集聚，选择一个处理会话中的数据分组的算法，以形成一个优选算法；

发送装置，用来向所述端点发送一个请求，所述请求指示处理会话中的数据分组的优选算法；

接收装置，用来从所述端点接收一个对所述请求的应答；

确定装置，用来确定是否已经发生会聚；以及

处理装置，用来响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

10.权利要求9的数据处理系统，其中所述应答是一个第一应答，所述确定装置是一个第一确定装置，而所述发送装置是第一发送装置，所述数据处理系统还包括：

识别装置，用来响应还没有发生会聚的确定结果，识别在第一应答内指定的一个替代算法；

第二确定装置，用来确定在所述数据处理系统内是否支持所述替代算法；以及

第二发送装置，用来响应在所述数据处理系统内支持所指定的算法的确定结果，向指出会聚的端点发送一个第二应答。

11.权利要求9的数据处理系统，其中所述确定装置包括：

确定装置，用来确定所述应答是否指定所述优选算法的一个补充算法。

12.权利要求10的数据处理系统，其中通过指定对所述替代算法的补充算法而在第二应答内指出所述会聚。

13.权利要求9的数据处理系统，其中所述优选算法是从源媒体访问控制地址算法、宿媒体访问控制地址算法、源因特网协议地址算法、宿因特网协议地址算法、传输控制协议/用户数据报协议源端口算法或传输控制协议/用户数据报协议源端口算法中选出的算法。

14.权利要求9的数据处理系统，其中所述请求是一个协议数据单元。

15.权利要求9的数据处理系统，其中所述协议数据单元包括算法字段和标志字段的标识。

16.权利要求9的数据处理系统，其中标志字段包括一个标明是否已经发生会聚的第一比特和一个指出是请求主职责还是从职责的第二比特。

17.一种在一个计算机可读媒体内的为一个发送数据分组的会话协商协议的计算机程序产品，所述计算机程序产品包括：

第一指令，用来响应与一个会话端点建立一个链路集聚，选择一个处理会话中的数据分组的算法，以形成一个优选算法；

第二指令，用来向所述端点发送一个请求，所述请求指示处理会话中的数据分组的优选算法；

第三指令，用来从所述端点接收一个对所述请求的应答；

第四指令，用来确定是否已经发生会聚；以及

第五指令，用来响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

18.权利要求17的计算机程序产品，其中所述应答是一个第一应答，而所述计算机程序产品还包括：

第六指令，用来响应还没有发生会聚的确定结果，识别在第一应答内指定的一个替代算法；

第七指令，用来确定在所述数据处理系统内是否支持所述替代算法；以及

第八指令，用来响应在所述数据处理系统内支持所指定的算法的确定结果，向指出会聚的端点发送一个第二应答。

19.权利要求17的计算机程序产品，其中所述第四指令包括：

子指令，用来确定所述应答是否指定所述优选算法的一个补充算法。

20.权利要求18的计算机程序产品，其中通过指定对所述替代算法的一个补充算法而在第二应答内指出所述会聚。

21.权利要求17的计算机程序产品，其中所述优选算法是从源媒体访问控制地址算法、宿媒体访问控制地址算法、源因特网协议地址算法、宿因特网协议地址算法、传输控制协议/用户数据报协议源端口算法或传输控制协议/用户数据报协议源端口算法中选出的算法。

22.权利要求17的计算机程序产品，其中所述请求是一个协议数据单元。

23.权利要求17的计算机程序产品，其中所述协议数据单元包括算法字段和标志字段的标识。

24.权利要求17的计算机程序产品，其中标志字段包括一个标明是否已经发生会聚的第一比特和一个指出是请求主职责还是从职责的第二比特。

25.一种数据处理系统，所述数据处理系统包括：

总线系统；

接到总线系统上的存储器，所述存储器包括一组指令；以及

接到总线系统上的处理单元，所述处理单元执行一组实现以下操作的指令：响应与一个会话端点建立一个链路集聚，选择一个用来处理会话中的数据分组的算法，以形成一个优选算法；向所述端点发送一个请求，所述请求指示处理会话中的数据分组的优选算法；从所述端点接收一个对所述请求的应答；确定是否已经发生会聚；以及响应已经发生会聚的确定结果，用所述优选算法处理会话中的数据分组。

Images