具有性能监测的主动多路径网络冗余的制作方法

相关申请的交叉引用

本申请要求于2009年9月23日提交的美国临时申请序列号61/245,170的权益，并且本申请还要求于2010年3月31日提交的美国临时申请序列号61/319,363的权益，为了所有的目的，这些申请的披露通过引用结合在此。

技术领域

实施方案涉及冗余报文处理，并且更具体地涉及对来自同一源节点并且具有不同IP地址的冗余报文进行报文层处理。

背景技术：

图1是开放系统互联(OSI)模型的一个列表。该OSI模型可表示为具有比特、帧和数据包数据单元的媒质层以及表示为具有数据和数据段的主机层。这些层可进一步细分为物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。用户数据报协议(UDP)是一个为使用互联网协议(IP)的网络中的计算机间的报文交换提供有限服务的通信协议，即轻量级协议。UDP使用IP从一个计算机/节点向另一个计算机/节点传输数据单元，即数据报。具体地讲，UDP不提供为到达的数据包排序。

技术实现要素：

实施方案可以包含互联网络中的一个节点，该节点包括：一个处理器和可寻址存储器，其中该处理器被配置成：(a)读取所接收的一个数据包的一个序列号和一个起始端标识符，该数据包具有一个报文；(b)将与该起始端标识符相关联的一个已存储的最高序列号和所接收的数据包的序列号进行比较；(c)如果所接收的数据包的序列号小于或等于同该起始端标识符相关联的已存储的最高序列号，则丢弃所接收的数据包；并且(d)如果所接收的数据包的序列号大于同该起始端标识符相关联的已存储的最高序列号，则基于一个上层协议将所接收的数据包中的报文交付给一个应用。可选地，该节点可被配置成从两条或更多条路径接收具有相同起始端标识符的数据包。该起始端可包括一个近实时控制器，并且该节点可包括一个网关和以下各项中的至少一个：(1)一个对所接收的帧的有效载荷信息进行响应的效应器；(2)一个射频发射器；(3)一个射频接收器；以及(4)一个传感器。

在一个实施方案中，该起始端包含一个近实时控制器，并且该节点包括一个网关和一个射频发射器。在一个实施方案中，该起始端包括一个近实时控制器，并且该节点包括一个网关和一个射频接收器。在一个实施方案中，该起始端包括一个近实时控制器，并且该节点包括一个网关和一个传感器。

例如，一些实施方案还可以是一种冗余报文处理方法，该方法包括：(a)通过一个起始端节点的一个处理器将：(i)一个帧序列号分配给一个第一数据包的一个帧；(ii)一个起始端标识号分配给该第一数据包的该帧；(iii)该帧序列号分配给一个第二数据包的一个帧；以及(iv)一个起始端标识号分配为给该第二数据包的该帧；(b)由一个目的节点的一个处理器来记录：包括该第一数据包和该第二数据包的一个组的一个第一被接收的数据包的帧序列号和起始端号；并且(c)由该目的节点的该处理器来丢弃：具有所记录的帧序列号以及所记录的起始端号的一个第二被接收的数据包。在丢弃步骤之前，该方法的一些实施方案可以进一步包括：由该目的节点的该处理器在如果该第二被接收的数据包的帧序列号与所记录的第一被接收的数据包的帧序列号的差值大于一个上限值或低于一个下限值时，记录具有所记录的该第一被接收的数据包的起始端号的第二被接收的数据包的一个帧序列号和一个起始端号。该方法的一些实施方案可进一步包括：由该起始端节点经过一个第一网络接口电路来发送该第一数据包并且经过一个第二网络接口电路来发送该第二数据包。

一些方法实施方案还包括一种网络节点健康评估方法，该方法包括：(a)向一个网络中的多个网络节点广播一个健康请求；(b)接收来自该多个网络节点中的至少一个节点的一个健康请求响应报文，其中所接收的健康请求响应报文包括该响应节点的一个以太网MAC地址；(c)将一个时间戳与所接收的健康请求响应报文相关联；(d)存储所接收的响应节点的以太网MAC地址以及与其相关联的时间戳；并且(e)基于所接收的和存储的一个或多个节点的以太网MAC地址向两个或更多个网络接口电路(NIC)以太网驱动程序提供完全相同的输出报文。该示例性方法实施方案还可以包括基于所接收的和存储的一个或多个节点的以太网MAC地址的一个或多个时间戳对网络健康进行评估。该示例性方法实施方案还可以包括对通过两条或更多条NIC路径发送的数据包与通过该两条或更多条NIC路径接收的数据包进行比较，并确定该两条或更多条NIC路径中的每条路径的丢包数量。

附图说明

通过举例对多个实施方案进行了展示，但不限于附图中的图示，并且在附图中：

图1是开放系统互联模型的一个列表；

图2是一个示例性上层系统图；

图3描绘了一个实施方案的示例性分层；

图4描绘了一个上层关系接口图；

图5描绘了一个关系接口图；

图6示出了一个示例性帧头内容结构和报文内容结构；

图7是描绘示例性顺序过滤和ping请求操作的一个上层流程图；

图8是描绘一个示例性顺序过滤实施方案的流程图；

图9是一个描绘了为健康评估而采用的一种具有数据收集的示例性基于以太网的通信流程的功能框图；并且

图10将一种示例性算法结构描绘为一个GoComMux流程图。

具体实施方式

参阅描述示例性实施方案的附图。图2是一个示例性上层系统图200。在此，处理器被定义为一个计算机或具有一个中央处理单元(CPU)和可寻址存储器的计算装置，其中可以通过可执行的机器可读指令、电路或其组合对一个计算装置进行配置从而使其具有特定计算装置的功能。网络可以由一个包含处理器的一个源节点、包含一个处理器的一个目的节点以及部署于这些节点之间的一个网络链路组成。该源节点可生成一个报文，比如用于目的节点的命令。该示例性报文可以由多个网络接口卡来准备和发送。在图2的示例性图中，该源节点210通过两个网络接口装置215、220或可以是网络接口卡(NIC)的计算机电路板与网络相连接。于是每个NIC可以连接至一个路由交换器231-234，例如，具有定向端口路由表的交换器。在图2的示例性网络中，该第一NIC可向一个第一交换器(SW_1)231发送，并且该第一交换器可向一个第二交换器(SW_2)232发送。同样在图2的示例性网络中，第二NIC 220可以像第一NIC 215一样向一个第四交换器(SW_4)234发送相同的报文，第四交换器234可向一个第三交换器(SW_3)233发送。第二交换器232和第三交换器233可向目的节点230发送数据包/数据报。因此，举例来说，目的节点230可以通过两个或更多个信道接收到来自一个源节点210的冗余报文

图3描绘了一个实施方案的示例性分层300，从物理层310到UDP/IP320到短消息协议330，然后至应用层340。图3还描述了大数据流350、一个套接字封装360、以及一个网络控制堆栈370。图4是一个上层关系接口图400，描述了介于套接字层420和应用层430之间的报文处理层410。本例中的套接字层420管理套接字的打开和关闭、处理UDP数据包的接收和发送、并支持单播和多播UDP数据报。本例中的报文处理层410对ping报文进行响应，使用嵌入的序列号对报文进行过滤，并且，如果可以与实时操作系统(RTOS)节点一起工作，当有新报文可用时还会调用应用层430。图5是展现一个示例性应用接口510的关系接口图500。本图示出了发向和来自应用层的报文的示例性流程。

图6描绘了一个示例性帧头内容结构和报文内容结构600。所示的帧头610具有一个序列号615和起始端识别码(ID)625。为实现应用级的连续性，可以结合起始端ID 625参考序列号615。序列号615可以是由一个特定起始端发送的帧中的一个16比特的整数。每个起始端节点可有两个或更多个NIC，各自具有一个不同的IP地址。起始端ID 625可以是唯一地标识一个帧发自哪个节点的一个8比特的整数。节点ID头文件可用来获取节点号列表。

图7是描绘顺序滤波710和ping请求处理720的示例性过程的一个上层流程图700。两个或更多个源能够以帧的形式提供报文，其中这些报文是完全相同的，并且这些序列号是相同的。报文处理层730可存储最后接受到的序列号，并对该序列号与所接收的帧的序列号进行比较。网络控制器节点可以使用嵌入的序列号来过滤报文，当有新报文可用时调用应用层740，通过向所有节点发送ping报文确定网络连通性和/或健康性，并处理对应的响应。该网络控制器节点可以根据对周期ping报文的响应或响应缺失建立一个网络连通性图750或关系表格，并向应用层740提供回调以获取连通性信息。

图8是描绘本发明的一个示例性顺序过滤实施方案的流程图800。当接收并读取数据包(步骤810)时，一个示例性接收实施方案可对新接收的数据包与具有相同起始端ID的之前、最近接收的数据包的序列号进行比较(820)。如果新接收的数据包的序列号小于或等于所记录的号(测试830)，则可以丢弃该新接收的数据包(步骤840)。在一些实施方案中，接收节点的报文处理层可以对新接收数据包的序列号与所记录的号的差值大小进行比较。然后，接收端可以重置为该新序列号，可以记录一个顺序颠倒事件，并相应地可以保存该新接收的数据包用于处理(步骤860)。

一个示例性实施方案可以是在一种飞行器系统中，在该飞行器的航空网络中具有两个或更多个飞行控制计算器(FCC)。每个FCC有两个网络接口电路或网络接口卡(NIC)，相应地它们向该飞行器的航空网络提供两个接入点。如上所述，如上述披露的该网络的一个示例性架构是使得每个NIC通过网络分段可以向每个子系统提供无重叠的连接。即，从特定FCC的一个第一NIC到任何特定子系统的路径均没有与从该特定FCC的一个第二NIC到该子系统的路径一样的物理层网络连接。该示例性容错网络实施方案部分基于被配置成从它的每个NIC产生冗余报文的FCC。可以用于FCC的网络堆栈可能不支持将单播业务量直接引导至一个特定的NIC。本实施方案中的堆栈是在存在到任何特定子网的一个单一连接的假设下进行运行的，并相应地将该业务量自动路由至一个适当的NIC。具体而言，由该堆栈维护的地址解析协议(ARP)表不要求两个NIC位于同一子网中，并从而可以阻止网络堆栈向这些子系统发送冗余单播。如果网络堆栈确定向特定NIC的直接多播会如预期那样工作，一个替代实施方案将不会使用单播。

一些示例性实施方案包括(例如)通过使用与标准VxWorks堆栈相结合而工作的VxWorks muxLib接口直接向两个NIC发送双重冗余的以太网数据包。直接向两个NIC发送双重冗余的以太网数据包通常情况下会避免在尝试向具有两个连接的子网发送单播时遇到的单播路由和ARP查表挑战。

当IP数据报由多归属主机发出时，它会被传递到具有到目的端的最直观路由的接口。相应地，该数据报可包含该多归属主机中一个接口的源IP地址，但是由一个不同的接口放到媒质中。该帧的源媒质接入控制地址是将该帧实际发送到媒质的接口的地址，且源IP地址是该发送应用的发起者，而未必是与网络连接UI中的发送接口相关联的一个IP地址。所谓的“弱端模型”系统(在该系统中一个地址指的是一个主机而不是接口)包含于包括Microsoft^TM Windows^TM在内的一些操作系统中。“弱端模型”意思是当一个数据包到达一个多归属系统上的接口之一时，只要其目的地址与这些地址之一匹配就会被网络堆栈选中。另一方面，所谓“强端模型”系统要求数据包的目的地址与其到达的下层接口地址匹配。对于发送数据包，弱端系统将从与该数据包的源IP地址不匹配的接口发送数据包，而强端系统不会从与数据包的源IP地址不匹配的接口发送数据包。

通常对于性示例性系统架构而言，参照图9，其中FCC应用900一分为二成内核空间910和实时处理(RTP)970。内核910管理驱动器接口，并且RTP 970管理航空实施方案的报文发送和飞行控制功能。作为标准IP UDP以太网帧的有效载荷的一部分，包含名为“goCom”层911的层会起到以下促进作用：(a)基于goFrame头的副本序列号而丢弃所接收的冗余报文；以及(b)收集副本报文的统计信息。可以参考所收集的数据并将其用于监测任一和全部冗余路径的健康。在一个示例性实施方案中，VxWorks提供了muxLib接口912从而能够访问在网络接口上接收的以太网数据包。该muxLib还用于向特定网络接口发送以太网报文。

接收到一个数据包时，在接收中断情况下可以执行已安装的应用回调。由mux接口提供指向包含所接收的数据包的缓冲器的一个指针。通过一系列的滤波器对该数据包进行检查，以使其成为有效的“goCom”帧。如果该报文来自网络中的子系统，例如传感器、效应器和/或收发器节点组成的航空网络，该子系统的以太网地址可存储在由子系统IP地址标引的表913中。相应地，可以参考所标引的子系统以太网地址表向与已存储的地址相对应的子系统回发单播报文。该示例性表可以取代ARP而运行-单独的实施方案机制-在某种程度上是因为ARP不会在航空双重网络路径实施方案下持续地运行。相应地，注意到FCC不能向任何没有向其发送过报文的子系统发送报文-因为FCC是通过所标引的表格来访问或学习这些子系统的以太网MAC地址。为主动填充表格，一个示例性实施方案要求网络中的所有节点都要对多播“健康请求”进行响应。此健康请求可选自系统的典型或标准功能。也就是说，对可用健康请求的调整或修改不需要支持双单播容错网络设计。相应地，当这些子系统用健康响应报文对健康请求作出响应时，FCC立即学习到网络上每个节点的以太网MAC地址。何时从子系统收到数据包的时间戳也被存储于该表格中。这允许基于每条路径的近期连通性来评估网络健康。还收集了每条路径上丢失了多少数据包的统计信息。这些统计信息的收集将即使是单一数据包丢失的灵敏检测也考虑在内。高级的灵敏检测为早期检测并隔离网络问题提供了可能。

从RTP到内核的报文信道接口可用于传输有待冗余地发自两个NIC的单播报文。一个示例性实施方案具有固定大小缓冲区的报文信道，该缓冲区足以容纳系统预期产生的最大可支持的以太网数据包或媒质传输单位(MTU)。一个示例性实施方案可以具有大小为1536字节的MTU。报文信道920接口可被配置成可变的，并允许向网络内任何子系统发送大范围的单播。可以参照报文缓冲区前端的元数据来确定该报文准备发送的IP地址和端口。

当内核910接收到从RTP 970发往特定子系统的报文时，它可以首先对其检查以确定该子系统的一个有效以太网地址是否存储在以太网表格913中。如果没有，可以将该报文默默地丢弃，即，不用通知网络的其他元素和FCC应用RTP就丢弃。如果该以太网地址对于子系统而言可用，则基于报文920形成930两个数据包。除了它们所起源的NIC外，这两个报文是完全相同的。具体而言，两个数据包使用相同的序列号。然后将这两个数据包通过muxLib接口912发往两个NIC(具体而言它们对应的NIC以太网驱动器951和952)用于传输。

可以与一个共享数据库支持(例如sdLib支持)一起构建体现为Vxworks内核的内核910，以提供一个从数据包接收处理器向RTP代码传递统计信息的高效机制，该代码用网络统计信息生成goCom报文。内核实施方案将muxLib用作由网络堆栈使用的标准接口。

非易失性存储器(如闪存或NVRAM)可以用于存储Hobbs时间，即运行时间，用于给所接收的以太网数据包添加时间戳。尽管相对较快，但NVRAM接入仍比RAM接入要慢，而且由于每个所接收的数据包被添加了时间戳，需要考虑读取性能。RAM可以是32比特的接入装置，与此相对的是，NVRAM可以是8比特的接入装置。该8比特接入与秒数计数器的冗长的4字节交叉进行数据相干检测，而32比特接入是固有的基元。相应地，Hobbs秒数计数器既存储于RAM也存储于NVRAM，并且作为二分之一的中断处理可以在两个位置对其进行更新。

在引导加载程序将应用下载到低端内存的同时使用高端内存的情况下，可以使用标准的RAM图，比如Vxworks标准RAM图。启动时，该应用以SYSMEMTOP开始使用高端内存来建立堆栈。堆栈降低。任何固定存储器分配都不受位于上述SYSMEMTOP中的OS或编译器管理。该内核应用使用sdLib创建由内核管理的指定的共享数据区。然后，可以由RTP应用打开该指定区域从而可以读取该以太网数据包统计信息。

适于VxWorks的Curtis Wright BSP可用来提供以太网驱动器。相应地，该muxLib以太网驱动器接口可被配置成运行于MUX_PROTO_SNARF模式。该配置允许对所有的接收数据包进行混合检查。然后，可选地将这些数据包返回至muxLib以发送至标准网络堆栈进行标准处理。

图10的GoComMux流程图描绘了一个示例性算法结构。应用层可以为goComMux模块1010初始化或产生一个进程。一旦该模块被初始化1020，然后goComMux模块可以绑定一个第一NIC 1030和绑定一个第二NIC 1040-以便可以确定其源于哪个NIC。可以执行一个初始化报文发送的进程1050，其中内核可以对驱动器接口进行处理并向内核发送信道读取RTP报文1060，例如数据包/数据报。该GoComMux模块可以向FCC应用RTP 970发送帧1070。该GoComMux模块可以接受向第一NIC 1080和第二NIC 1085的中断，并调用一个从MuxLib接收数据帧的进程1090。

考虑到可以对上述实施方案的特定特征和方面作出不同组合和/或子组合，但仍然属于本发明的范畴。相应地，应当了解到本披露实施方案的不同特点和方面可以相互结合或彼此替换以组成本披露发明的不同模式。进一步地，通过举例披露的本发明的范围不由以上特定披露实施方案所限制。