用于多点对多点中继的干线网络系统

摘要

在干线网络中，每个节点在被从另一个节点中通知了外部连接端口所属的组的状态改变时改变外部连接端口的状态，以使外部设备检测传输路由的故障。端口状态监控单元预先把外部连接端口分类成组，并存储外部连接端口和这些组的对应关系。端口状态监控单元随后检测外部连接端口的状态改变。当在端口状态监控单元中检测到任何外部连接端口的状态改变时，组状态管理单元把包括与该外部连接端口相对应的那些组的状态的状态信息报告给构成该干线网络的其他节点。一旦从任何其他节点接收到状态信息，根据包括在状态信息中的组的状态，组状态管理单元改变属于这些组的外部连接端口的状态。

说明书

发明背景

技术领域

本发明涉及用于实现多点对多点中继的干线网络，并且尤其涉及干线网络中的故障通知。

背景技术

存在被提供替换路由以防止故障而改善可靠性的网络。在提供有替换路由的网络中传输路由上有故障的情形中，通过转换到替换路由可以继续分组的传输。然而，在这样的情况下，在故障发生到转换完成的时间间隔期间，通信被中断(drop)。

结果，缩短从故障出现直到完成转换的时间间隔(此后称为“路由转换时间间隔”)既获得其中通信被中断的时间间隔的相应缩短又改善了网络的可靠性。路由转换时间间隔包括从故障出现直到其检测(此后称作“故障检测时间间隔”)所需的时间间隔，并且这个故障检测时间间隔在确定网络的可靠性中是至关重要的因素。

存在具有提供多点对多点连接的分组转换能力的干线网络，这些干线网络在多个外部设备诸如路由器或MAC转换器之间提供连接。通过使用这种类型的干线网络，利用多个节点将外部设备互相连接。

如果在这种类型的干线网络中出现故障，则不再能够保证通过干线网络的分组的可达性。阻止分组可达性的故障的例子包括外部设备的故障、与外部设备连接的中继节点的端口的故障或中继节点的故障。

直接连接到故障的地点的设备可以检测设备故障或端口故障为链路失效(link down)(断开)。通过比较，没有直接与故障的地点连接的外部设备不能直接检测到该故障。

一旦检测到链路失效，则提供点对点连接的设备能引起其他链接的断开并因而能把故障通知给不能直接检测到失效的链路的设备(例如，参见JP-A-2003-087276)。

另一方面，具有多种方法，其中作为一种在提供多点对多点连接的干线网络中验证分组可达性的方法，即，作为检测故障的方法，外部设备为了残存验证(survival verification)而彼此交换控制分组。外部设备以指定周期连续地把控制分组发送到对方设备，并且进一步监控是否在从对方设备连续接收控制分组。当不再接收到控制分组时，外部设备则确定可达性已被阻止，并因此转换分组的传输路由。

然而，上述的背景技术具有下列问题：

在具有上述类型的点对点连接的设备中，一个链接的断开加速其他链接断开的方法不能适用于提供多点对多点连接的干线网络。这种无能是在提供多点对多点连接的干线网络中缺少链路之间的一对一对应关系的结果。换句话说，当检测到特殊链接的断开时，确定哪一个其他的链接将被断开是有问题的，这是因为在多点干线网络中链路之间的各种连接都是有可能的。

结果，每个外部设备最好利用一些方法来验证是否保证通过干线网络的分组的可达性，即是否出现了故障。作为一个例子，具有一种方法，其中为了验证残存而交换上述控制分组。

然而，这种方法通常需要长的时间间隔来检测故障。缩短用于发送控制分组的周期可以缩短故障检测时间间隔。然而，缩短用于发送控制分组的周期趋于增加外部设备中的负载处理或对传输线的通信带宽施加压力。因此，一般限制缩短控制分组的传输周期，并因此充分地缩短转换时间是有问题的。利用残存验证控制分组实现的方法一般需要范围从10秒到几分钟的故障检测时间间隔。

结果，在从故障出现直到转换完成的长时间间隔期间，外部设备继续发送分组到其中可达性已经被阻止的路由，这延长了通信被中断的时间间隔。

发明内容

本发明的目的是提供一种干线网络，其中外部设备可以在短的时间间隔内检测到传输路由中的故障。

为了实现上述目的，本发明的节点设备是构成用于共同连接外部设备的干线网络的节点设备，并包括外部连接端口、端口状态监控单元和组状态管理单元。

外部连接端口是用于连接到外部设备的端口。端口状态监控单元提前把外部连接端口分类成组，存储外部连接端口和组的对应关系，并检测外部连接端口的状态中的改变。

当在端口状态监控单元中检测到任何外部连接端口的状态改变时，组状态管理单元把包括对应于那个外部连接端口的组的状态的状态信息报告给构成干线网络的其他节点，并在从任何其他节点中接收到状态信息时，根据包括在那个状态信息中的组的状态信息来改变属于那个组的外部连接端口的状态。

根据本发明，节点设备的外部连接端口被提前分类成组，并在每个节点设备的端口状态监控单元中监控外部连接端口。以这样的方式，检测每个组的状态改变，从已经检测到组状态改变的节点设备的组状态管理单元把组的状态变化报告给其他的节点，并且属于那个组的端口的状态在其它节点设备的组状态管理单元中被改变。结果，连接到由节点设备构成的干线网络的外部设备能利用端口状态的改变在短时间间隔内了解故障的发生。此外，因为以组为单位来报告状态变化，所以当在任何端口中出现状态变化时，只在与那个端口相关的端口中生成状态变化并随后实现对外部设备的通知。

从下面结合附图的描述中，本发明的上述和其他的目的、特点和优点将变得显而易见，其中附图示例了本发明的例子。

附图说明

图1是显示根据第一实施例的干线网络的方框图；

图2是显示根据第一实施例在中继节点的每个外部连接端口中设置的属性的表；

图3是显示根据第一实施例的中继节点的方框图；

图4是显示端口状态监控单元的操作的流程图；

图5是显示特定节点的组状态的表；

图6是显示其它节点的组状态的表；

图7显示在第一实施例的操作例子中每个中继节点的端口的属性的表；

图8是显示当在中继节点3中检测到端口25的故障时操作的例子的顺序图；

图9是显示在中继节点1中被控制的其它节点的组状态的示例的表(在中继节点3的故障出现之前)；

图10是显示当在中继节点3中出现故障并且其他的中继节点1、2和4检测到与中继节点3的可达性的障碍时操作的例子的顺序图；

图11是显示根据第二实施例的干线网络的方框图；

图12显示在第二实施例的理想例子中每个中继节点的端口的属性的表；

图13是显示根据第二实施例的中继节点的方框图；和

图14是显示当在中继节点8中检测到端口64的故障、随后在中继节点9中检测到端口65的故障时的操作的顺序图。

具体实施方式

下面的解释涉及本发明的第一实施例。参考图1，第一实施例的干线网络5包括中继节点1-4。

中继节点1包括外部连接端口21，22和节点连接端口31和32。端口21和22被连接到外部设备11。中继节点2包括外部连接端口23和24以及节点连接端口33和34。端口23和24被连接到外部设备12。中继节点3包括外部连接端口25和26以及节点连接端口35和36。端口25和26被连接到外部设备13。中继节点4包括外部连接端口27以及节点连接端口37和38。端口27被连接到外部设备14。

此外，连接中继节点1的端口32和中继节点2的端口33，连接中继节点2的端口34和中继节点3的端口36，连接中继节点2的端口35和中继节点3的端口36，连接中继节点3的端口35和中继节点4的端口37，以及连接中继节点4的端口38和中继节点1的端口31。

例如，外部设备11、12、13和14是分组交换设备，比如路由器或MAC交换机。干线网络5从外部设备把分组传送到写在标题中的地址的外部设备。换句话说，外部设备11、12、13和14是利用干线网络5连接的多点对多点。

各种属性被提前设置在中继节点1-4的每个外部连接端口中。

图2是显示根据第一实施例在中继节点的外部连接端口中设置的属性的表格。参考图2，在每个端口中设置组、通知属性和控制属性。

利用所述设置将每个中继节点的外部连接端口分类成组。确定这些组的方法对于变化是开放的，但根据可以被考虑的一种方法，可以进行设置，以便组是由受该组内的任何端口中故障出现的影响的端口组成的。根据另一种可被考虑的方法，包括在同一设置的冗余构成中的端口可以被分在同一个组中。

通知属性是表示当在那个端口上出现故障时是否要向其他的中继节点通知该组的故障的属性信息，该属性被设置为“ON(通)”或“OFF(断)”。故障通知的“ON”设置表示要报告故障，而“OFF”设置表示将不报告故障。

控制属性是表示一个端口当属于已被从另一个中继节点通知故障时是否将被强制地断开的属性信息；该属性被设置为“ON”或“OFF”。控制属性的“ON”设置表示强制断开，而“OFF”设置表示将不执行强制断开。

图3是显示根据第一实施例的中继节点的结构的方框图。作为示例，在该图中示出中继节点1，但其他的中继节点24具有相同的结构。

参考图3，中继节点1包括：端口状态监控单元51，组状态管理单元52，拓扑控制单元53，消息处理器54，以及端口21，22，31和32。

端口状态监控单元51以允许参照的形式提前保持图2所示的每个端口的属性信息。端口状态监控单元51监视外部连接端口21和22中的状态变化，并且在检测到端口状态改变时，如果该端口中设置的通知属性是“ON”，则把端口状态的变化报告给组状态管理单元52。

图4是显示端口状态监控单元的操作的流程图。参考图4，端口状态监控单元51首先监控端口状态中是否有变化(步骤101)。当端口状态有变化时，端口状态监控单元51接下来确定那个端口的通知属性是否为“ON”(步骤102)。如果通知属性是“OFF”，则端口状态监控单元51就返回到步骤101，以监视端口状态的改变。

如果该端口的通知属性是“ON”，则端口状态监控单元51接着确定是否端口状态的变化将“up(连接)”链路(连接)(步骤103)。如果变化将“up”链路，则端口状态监控单元51就通知组状态管理单元52：该端口所属的组处于“up”状态(步骤104)并返回到步骤101。

如果在步骤103确定状态的变化不是“链路连接(link up)”，则端口状态监控单元51接着确定该端口的状态变化是否是“链路失效(link down)”(断开)(步骤105)。如果变化是“链路失效”，则端口状态监控单元51就通知组状态管理单元52：那个端口所属的组处于“down(失效)”状态(步骤106)并随后返回到步骤101。

如果在步骤105确定状态变化不是“链路失效”，则端口状态监控单元51就返回到步骤101。

返回到图3的解释，组状态管理单元52基于来自端口状态监控单元51的通知来管理它自己的节点的每个外部连接端口所属的组的状态(以下称作“其自己节点的组状态”)。将假定每个组处于“up”状态或“down”状态。“up”状态是其中可以正常操作是可能的状态，而“down”状态是其中由于一些原因(比如故障)而暂停操作的状态。

图5是显示主题(subject)节点的组状态的图表。在图5的表中控制主题节点的端口所属的每个组的状态。

当它自己的节点的组状态中出现变化时，组状态管理单元52发送每个组的状态信息给消息处理器54并指令消息的准备和发送。

此外，基于利用消息处理器54的来自其它节点的通知，组状态管理单元52管理每个外部连接端口所属的组的状态，其中在每个其他的节点中通知属性是“ON”(以下称作“其它节点的组状态”)。执行这个管理，以便根据其它节点的状态变化来控制它自己的节点的端口，并且该管理对于其中在其他节点中通知属性是“OFF”的外部连接端口(即，对于那些即使在故障情况中通知也不出现的端口)来说不是必需的。

图6是显示其它节点的组状态的图表。图6是一种用于管理具有通知属性“ON”的其它节点的端口所属的每个组的状态的手段。

组状态管理单元52检查它自己的节点的组状态和所有其它节点的组状态，并在任何节点中发现处于“down”状态的组(以下称作“‘down’状态组”)和所有节点的处于“up”的组(以下称作“‘up’状态组”)。

当有一个组从“up”状态组改变到“down”状态组时，组状态管理单元52强制断开属于那个组的而且其控制属性是“ON”的它自己节点中的任何端口。强制断开意味着强制地将链路置于“down”状态并让为连接目的地的外部设备识别该断开。用于强制断开的方法例如包括无效代码的传输、暂停光信号、暂停电信号和关闭电源。在认识到该链路是失效的之后，外部设备能够暂停分组到那个链路的传输。该解决方式能防止不会到达的分组流到干线网络5并因此能够更有效利用带宽。可替换地，如果传输路由被复制，则外部设备可以采取强行断开作为路由转换的一种提醒方式(prompt)。该解决方法相比于将控制分组用于残存验证来说，较大地缩短了故障检测时间间隔，并且还缩短了路由转换时间间隔，因而导致网络可靠性的改善。

另一方面，如果有一个组从“down”状态组改变到“up”状态组，则组状态管理单元52释放属于那个组的而且具有控制属性“ON”的它自己节点的端口的强行断开。被连接到这些端口的外部设备可以采取这种强制断开的释放作为恢复分组到该链路的传输的一种提醒方式，或作为转换回到该路由的提醒方式。

此外，当从拓扑控制单元53中通知组状态管理单元52：到任何其它节点的可达性被阻止时，组状态管理单元52在如图6所示的其他节点的组状态中将其它节点的所有组都置于“down”状态。作为把这些组置于“down”状态的结果，如果有一些组已经从“up”状态组改变到“down”状态组，如先前所描述的，组状态管理单元52强行断开属于这些组而且控制属性设置为“ON”的端口。

拓扑控制单元53检查从它自己的节点到其它节点的可达性。在此使用的检验方法对于变化是开放的，但能在更短的时间间隔中验证可达性的方法相比于使用控制分组来残存验证的方法是更可取的。作为一个例子，可以使用在IEEE802.17中规定的RPR(Resilient Packet Ring弹性分组环)。RPR能够在几十毫秒内进行故障检测。当从特定节点到另一个节点的可达性被阻止时，拓扑控制单元53把该状态报告给组状态管理单元52。

消息处理器54准备和发送消息到其他的节点，而且进一步接收和分析来自其它节点的消息。

下面的解释涉及根据第一实施例的干线网络的操作的实际示例。

图7显示了表示在第一实施例的操作中每个中继节点的端口的属性的表。图7A是中继节点1的属性表41，图7B是中继节点2的属性表42，图7C是中继节点3的属性表43，和图7D是中继节点4的属性表44。

作为干线网络5的操作的例子，由中继节点1的端口21、中继节点2的端口23和中继节点3的端口25组成的第一集合不同于由中继节点1的端口22、中继节点2的端口24和中继节点3的端口26组成的第二集合，利用这对集合构成冗余系统。尽管在外部设备14和中继节点4之间未保持冗余，但是中继节点4的端口27被假设包括在第二集合中。

在该网络操作的前提下，提前确定组，以便中继节点1的端口21、中继节点2的端口23和中继节点3的端口25属于组1，并且中继节点1的端口22、中继节点2的端口24、中继节点3的端口26和中继节点4的端口27属于组2。

对于端口22、端口24、端口25、端口26和端口27，通知属性和控制属性都被设置为“ON”。对于端口21，将通知属性设置为“OFF”，并将控制属性设置为“ON”，并且对于端口23，将通知属性设置为“ON”，并将控制属性设置为“OFF”。

在这个示例中，对于其中在中继节点3中检测到端口25的故障的情况，显示操作。图8是显示其中在中继节点3中检测到端口25的故障的情况的操作示例的顺序图。

参考图8，中继节点3首先在端口状态监控单元51中检测到端口25的故障(步骤A1)。

已经检测到端口25的故障的端口状态监控单元51参考图7C的属性表43并检查端口25所属于的组的通知属性。在此情况下，端口25属于组1，并且组1的通知属性是“ON”。结果，端口状态监控单元51将表明组1处于“链路失效”状态中的状态变化通知组状态管理单元52。基于来自端口状态监控单元51的通知，组状态管理单元52指令消息处理器54准备和发送表示组1的“链路失效”的消息。根据来自组状态管理单元52的指令，消息处理器54准备和发送消息，于是该消息从中继节点3被发送到其他中继节点1、2和4。

中继节点2在消息处理器54中接收和分析来自中继节点3的消息(步骤A2)。中继节点2随后参考组状态管理单元52中的图7B的属性表42，以检查属于组1的端口的控制属性。在此情况下，端口23的控制属性是“OFF”，并因此中继节点2对属于组1的端口23不采取动作(步骤A5)。

中继节点1在消息处理器54中接收和分析来自中继节点3的消息(步骤A3)。中继节点1接着参考组状态管理单元52中的图7A的属性表41，以检查属于组1的端口的控制属性。在此情况下，端口21的控制属性是“ON”，并因此中继节点1利用组状态管理单元52来强行断开属于组1的端口21(步骤A6)。

中继节点4在消息处理器54中接收和分析来自中继节点3的消息(步骤A4)。中继节点4接着利用组状态管理单元52参考图7D的属性表44，但不采取动作，因为在中继节点4中没有端口属于组1(步骤A7)。

如从该示例的操作中可以明白的，根据本实施例，当在干线网络5的任何中继节点的外部连接端口中出现故障时，该端口所属的那个组的断开被报告给其他中继节点，并在其他节点中，属于该组的而且具有控制属性被设置为“ON”的端口被强制断开。

尽管在此图中未显示，但是一旦从中继节点3的端口25的故障中恢复，中继节点3就确定组1的故障已经恢复并把表示组1的故障恢复的消息发送到其他中继节点1、2和4。已经接收到该通知而且控制属性被设置到“ON”的中继节点1、2和4解除属于组1的端口的强制断开。

下面的解释涉及根据第一实施例的干线网络的操作的第二个例子。

假设每个中继端口的端口的属性与图7所示的相同。在此情况下，显示了其中中继节点1检测到端口21的故障的情况的操作。该示例的操作是简单的，并因此在图中未显示。

中继节点1首先在端口状态监控单元51中检测端口21的故障。已经检测到端口21的故障的端口状态监控单元51参考图7A的属性表，并检查端口21所属的组1的通知属性。在此情况下，端口21属于组1，并且组1的通知属性是“OFF”，端口状态监控单元51不把该端口的状态变化通知组状态管理单元52。结果，不把消息发送到其他的中继节点，并且在其他的中继节点中不执行强制断开。

下面的解释涉及根据第一实施例的干线网络操作的第三个例子。

假设每个中继端口的端口的属性与图7所示的相同。

图9是显示在中继节点1中管理的其它节点的组状态的示例的表(在中继节点3的故障出现之前)。参考图9所示的表45，在中继节点3中出现故障之前的状态下，中继节点1认识到中继节点2的组1和2、中继节点3的组1和2以及中继节点4的组2都处于“up”状态。换句话说，中继节点1认识到组1和2都是“up”状态组。

这里显示的是针对其中中继节点3中出现故障并且其它的节点1、2和4检测到与中继节点3的可达性被阻止的的情况的操作。图10是显示了一种情况的操作例子的顺序图，其中在中继节点3中出现故障，并且其它的节点1、2和4检测到与中继节点3的可达性被阻止。

参考图10，故障首先出现在中继节点3中(步骤A7)。

中继节点1在拓扑控制单元53中检测到至中继节点3的可达性已被阻止(步骤A10)。已经检测到至中继节点3的可达性被阻止的拓扑控制单元53把这个状态报告给组状态管理单元52。已从拓扑控制单元53接收到通知的组状态管理单元52更新图9中所示的表并把中继节点3的每个端口所属的组1和2置于“down”状态。作为把组1和2置于“down”状态的结果，组1和2从“up”状态组改变为“down”状态组。组状态管理单元52因此强行断开属于这些组1和2而且具有被设置到“ON”的控制属性的端口21和22(步骤A11)。

中继节点4在拓扑控制单元53中检测到至中继节点3的可达性被阻止(步骤A8)。已检测到至中继节点3的可达性已被阻止的拓扑控制单元53把这个状态报告给组状态管理单元52。已经从拓扑控制单元52接收到该通知的组状态管理单元52把中继节点3的每个端口所属的组1和2置于“down”状态。作为把组1和2置于“down”状态的结果，组1和2从“up”状态组改变为“down”状态组。中继节点4缺少属于组1的任何端口，并且组状态管理单元52因此强制断开属于组2而且具有被设置到“ON”的控制属性的端口27(步骤A13)。

中继节点2在拓扑控制单元53中检测到至中继节点3的可达性被阻止(步骤A9)。已检测到至中继节点3的可达性被阻止的拓扑控制单元53把该状态报告给组状态管理单元52。已经从拓扑控制单元52接收到该通知的组状态管理单元52把中继节点3的每个端口所属的组1和2置于“down”状态。作为把组1和2置于“down”状态的结果，组1和2从“up”状态组改变为“down”状态组。组状态管理单元52因此强制断开属于这个组2而且具有被设置到“ON”的控制属性的端口24(步骤A12)。

如能够从该示例的操作明白的，在本实施例中，当干线网络5的任何中继节点中出现故障时，在其他中继节点中检测到到达其中出现故障的中继节点的可达性被阻止，并且那些具有控制属性已被设为“ON”而且属于其中出现故障的中继节点的端口所属的那个组、并且其通知属性被设为“ON”的端口被强行断开。

尽管在图中未显示，但是一旦从中继节点3的故障中恢复，到中继节点3的可达性也在中继节点1、2和4中恢复，并因此中继节点1，2和4检测从中继节点3的故障中的恢复，而且解除属于组1和2并具有被设置为“ON”的控制属性的端口的强行断开。

如前面的解释中所述的，根据本实施例，构成干线网络5的每个中继节点1-4的外部连接端口21-27被提前分类成组，通过在每个中继节点1-4的端口状态监控单元51中监视外部连接端口21-27来检测每个组的状态改变，利用消息处理器54从检测到组状态变化的中继节点的组状态管理单元52中将组状态的改变报告给其他的中继节点，而且属于这个组的端口在其他中继节点的组状态管理单元52中被强制断开，借此利用外部设备11-14的断开，可以在短时间间隔中检测故障的出现。

此外，根据本实施例，利用端口的断开把故障的出现报告给外部设备，并因而在中继节点和外部设备之间不要求使用特殊协议。

另外，根据本实施例，干线网络中的外部连接端口被分成组，并在组单元中执行通知，借此当任何端口中出现故障时，有可能只强行断开与那个端口相关的端口并把故障报告给外部设备11。

根据本实施例，报告或不报告故障(通知属性的ON/OFF)和执行或不执行强行断开控制(控制属性的ON/OFF)可以被设置成用于外部连接端口的参数，并因而本实施例允许灵活的是否报告故障给其他中继节点或是否强行断开的操作。例如，对于具有高度重要性的端口，可以将通知属性设置为“ON”。此外，对于具有低度重要性的端口，可以将控制属性设置为“OFF”，并对其不建立可替换的路由。还有，可以将特殊端口的通知属性设置成“OFF”，以便利用同一组内的其他端口进行连续通信。

根据本实施例，组状态管理单元52强制地对于任何其他节点把属于处于“down”状态中的那个组的外部连接端口置于“链路失效”状态中，并对于所有其它节点，把属于处于“up”状态中的那些组的外部连接端口置于“链路连接”状态；借此，如果在一个组内具有通知属性被设置为“ON”的甚至一个端口中出现故障，组状态管理单元52也可以把故障的出现通知给其他的外部设备。

下面的解释有关本发明的第二实施例。

在第二实施例中，所示的结构是一种理想的例子，其中作为外部设备将服务器和客户设备(以下称作“客户机”)连接到中继节点。

图11是显示根据第二实施例的干线网络的结构的方框图。参考图11，干线网络10包括中继节点6-9。

中继节点6包括外部连接端口61和节点连接端口71和72。端口61被连接到客户机17。中继节点7包括外部连接端口62和节点连接端口73与74。端口62被连接到客户机18。中继节点8包括外部连接端口63和64以及节点连接端口75和76。端口64被连接到服务器16，并且端口63被连接到客户机19。中继节点9包括外部连接端口65以及节点连接端口77与78。端口65被连接到服务器15。

连接中继节点6的端口72和中继节点7的端口73，连接中继节点7的端口74和中继节点8的端口76，连接中继节点8的端口75和中继节点9的端口77，而且连接中继节点9的端口78和中继节点6的端口71。

在第二实施例中，服务器15和16以及客户机17-19作为外部设备被连接到干线网络10。如在第一实施例中，干线网络10把分组从外部设备传送到具有的地址被写在标题中的外部设备。换句话说，服务器15和16以及客户机17-19是利用干线网络10来多点-多点连接。多个客户机17-19共享服务器15和16的使用。服务器15和服务器16可以构成一个冗余对。

在中继节点6-9的每个外部连接端口中预先设置各种属性。在中继节点6-9的每个外部连接端口中设置的属性与图2所示的第一实施例的相同。然而，在本实施例中，作为一个理想例子，各种属性的设置根据该端口是被连接到客户机还是被连接到服务器而不同。

图12显示了表示第二实施例的理想例子中每个中继节点的端口属性的图表。图12A是中继节点6的属性表46，图12B是中继节点7的属性表47，图12C是中继节点8的属性表48，和图12D是中继节点9的属性表49。

所有的外部连接端口61-65都属于同一组1。被连接到服务器15和16的端口65和64具有被设置为“ON”的通知属性和被设置为“OFF”的控制属性。被连接到客户机17-19的端口61-63利用通知属性“OFF”和控制属性“ON”来设置。

图13是显示根据第二实施例的中继节点的结构的方框图。在此情况下，中继节点6被显示为一个例子，但其他的中继节点7-9具有相同的结构。

参考图13，中继节点6包括：端口状态监控单元51，组状态管理单元55，拓扑控制单元53，消息处理器54，以及端口61、71和72。

端口状态监控单元51、拓扑控制单元53和消息处理器54与第一实施例中的组件相同。此外，端口61、71和72与第一实施例中的端口相同。

有关它自己节点的组状态的管理，组状态管理单元55的操作与第一实施例的组状态管理单元52的相同。至于第一实施例的组状态管理单元52，当在它自己节点的组状态中出现改变时，组状态管理单元55把每个组的状态信息发送到消息处理器54并指令消息的准备和传输。

然而，有关其它节点的组状态的处理，组状态管理单元55的操作不同于第一实施例的组状态管理单元52的操作。

基于来自其它节点的通知，组状态管理单元55利用消息处理器54来管理其它节点的组状态，如图6所示。组状态管理单元55为了根据其它节点的状态变化控制它自己节点的端口而执行管理，并且不需要管理其它节点中具有通知属性为“OFF”的外部连接端口，即，无论是否有故障，对其不执行通知的端口。为此，组状态管理单元与第一实施例的相同。

在此情况下，组状态管理单元55检查它自己节点的组状态和所有其它节点的组状态，并发现所有节点中处于“down”状态中的组为“失效状态组”和发现至少一个节点中处于“up”状态中的组为“连接状态组”。在此时，操作不同于第一实施例的操作。

如在第一实施例中，当具有一些组从“up”状态组改变到“down”状态组时，组状态管理单元55强制地断开属于这些组而且具有控制属性“ON”的它自己节点的任何端口。如果有一些组从“down”状态组改变到“up”状态组时，组状态管理单元55就解除属于这些组而且具有控制属性“ON”的它自己节点中任何端口的强行断开。

此外，如在第一实施例中，当被从拓扑控制单元53通知到任何其他节点的可达性被阻碍时，组状态管理单元55在如图6所示的其它节点的组状态中把所有其它节点的组都置于“down”状态中。如果具有组作为把这些组置于“down”状态的结果而已经从“up”状态组改变到“down”状态组时，组状态管理单元52强制断开属于这些组而且具有控制属性“ON”的端口，如前所述。

下面的解释涉及根据第二实施例的干线网络的操作的实际例子。

图14是显示当在中继节点8中检测到端口64的故障、接着在中继节点9中检测到端口65的故障时操作的例子的顺序图。

参考图14，中继节点8首先在端口状态监控单元51中检测到端口64的故障(步骤B1)。

已经检测到端口64的故障的端口状态监控单元51参考图12C的属性表48，并检查端口64所属的那个组的通知属性。在此情况下，端口64属于组1，而且组1的通知属性是“ON”。结果，端口状态监控单元51将表明组1链路是“down”的状态变化通知给组状态管理单元55。基于来自端口状态监控单元51的通知，组状态管理单元55指令消息处理器54准备和发送表示组1的链路是“down”的消息。根据来自组状态管理单元55的指令，消息处理器54准备和发送消息，于是从中继节点8发送消息到其他的节点6、7和9。

中继节点7在消息处理器54中接收来自中继节点8的消息并分析该消息(步骤B2)。然而，中继节点6和9的组1的状态是“up”，并因此中继节点7的组状态管理单元55不把组1作为“down”状态组。结果，中继节点7对端口62不采取动作(步骤B5)。

中继节点6在消息处理器54中接收来自中继节点8的消息和分析该消息(步骤B3)。然而，中继节点7和9的组1的状态处于“up”状态，并因此中继节点6的组状态管理单元55不把组1当成“down”状态组。结果，中继节点6对端口61不采取动作(步骤B6)。

中继节点9在消息处理器54中从中继节点8接收消息和分析消息(步骤B4)。然而，在中继节点9中，不采取动作，因为没有其中控制属性是“ON”的外部连接端口(步骤B7)。

中继节点9接着在端口状态监控单元51中检测端口65的故障(步骤B8)。

已经检测到端口65的故障的端口状态监控单元51参考图12D的属性表49，并检查端口65所属的那个组的通知属性。在此情况下，端口65属于组1，并且组1的通知属性是“ON”。结果，端口状态监控单元51把表示组1的链路是“down”的状态变化报告给组状态管理单元55。基于来自端口状态监控单元51的通知，组状态管理单元55指令消息处理器54准备和发送表示组1的“链路失效”的消息。根据来自组状态管理单元55的指令，消息处理器54准备和发送消息，于是从中继节点3把消息发送到其他的中继节点6、7和8。

中继节点8在消息处理器54中接收和分析来自中继节点9的消息(步骤B9)。中继节点8随后在组状态管理单元55中参考图12C的属性表48。在此情况下，端口63的控制属性是“ON”，并因此中继节点8强制断开端口63(步骤B12)。

中继节点7在消息处理器54中接收来自中继节点9的消息(步骤B10)。中继节点7随后在组状态管理单元55中参考图12B的属性表47并检查每个端口的控制属性。在此情况下，端口62的控制属性是“ON”，并因此中继节点7强制断开端口62(步骤B13)。

中继节点6在消息处理器54中接收和分析来自中继节点9的消息(步骤B11)。中继节点6随后参考组状态管理单元55中的图12A的属性表46并检查每个端口的控制属性。在此情况下，端口61的控制属性是“ON”，并因此中继节点6强制断开端口61(步骤B14)。

根据在前面的解释中所述的当前实施例，组状态管理单元52对于所有其它节点强制地把属于“down”状态中的组的外部连接端口都置于链路“down”状态，并且对于任何其他节点把属于处于“up”状态中的组的外部连接端口都置于“链路连接”状态。因此，组状态管理单元55可以保持状态，即使在组中残存通知属性被设置到“ON”的一个端口，并在所有端口都出现故障时报告故障。例如，对于连接到作为外部设备的服务器的端口，将通知属性设置为“ON”，以及对于连接到客户机的端口，将通知属性设置为“OFF”，使得在所有服务器都出现故障时可以实现通知。

虽然已经使用特定术语描述了本发明的优选实施例，但是这样的描述只是用于示例性的目的，并且应该明白，在不脱离下面的权利要求的精神或范围的情况下，可以作出改变和变化。