CN101309215B - 一种以太环网链路恢复检测方法及以太环网主交换机 - Google Patents
一种以太环网链路恢复检测方法及以太环网主交换机 Download PDFInfo
- Publication number
- CN101309215B CN101309215B CN200810115524XA CN200810115524A CN101309215B CN 101309215 B CN101309215 B CN 101309215B CN 200810115524X A CN200810115524X A CN 200810115524XA CN 200810115524 A CN200810115524 A CN 200810115524A CN 101309215 B CN101309215 B CN 101309215B
- Authority
- CN
- China
- Prior art keywords
- link
- port
- message
- recovery message
- cached
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Abstract
本发明提供一种以太环网链路恢复检测方法及以太环网主交换机,该方法包括:以太环网的主交换机确定从主端口、从端口都接收到链路恢复消息后,阻塞所述从端口,并通过所述主端口、从端口向待恢复的链路两端的交换机发送释放临时阻塞端口的指令消息。本发明提高了EAPs环的健壮性,在那些对通信质量要求很高又必须部署EAPs环的场合,应用本发明可以避免设备响应延迟而造成的通信的长时间中断问题,使得EAPs环可以应对更多的实际环境。
Description
技术领域
本发明涉及以太网技术,特别涉及一种提高以太环网健壮性的方法,具体地,涉及一种以太环网链路恢复检测方法及以太环网主交换机。
背景技术
随着以太网技术的飞速发展以及应用的不断提升,采用性价比极高的以太网技术来构建大型的企业网、城域网已经成为一个不可阻挡的趋势。在这类规模大、业务多的网络环境里面,绝大部分都是部署环形拓扑,如图1所示,环形拓扑的特征就是每台设备使用两个端口和相邻设备互连,形成一条闭合链路。
如果使用以太网交换机来构建这种环形拓扑,我们就将其称为以太环网。在一个以太环网里面,最关键的两个功能就是冗余和故障恢复。
所谓冗余是指在环路完整的时候,必须有个端口阻塞数据转发,以避免数据在环路里面不断循环,形成所谓的广播风暴。
如图2所示,交换机A把和交换机B互连的端口给阻塞住,图中的圆圈表示阻塞,这样图2中交换机A和交换机B之间的链路10就无法转发数据,于是这个以太环网就不会形成广播风暴,而链路10此时被称为备份链路,也就是说正常情况下,该链路10是不做数据转发的,而除此以外的其它链路都是可以转发数据的,被称为工作链路,比如图2中交换机A到交换机D间的链路就是工作链路。这就是以太环网冗余的含义。
所谓的故障恢复是指某条工作链路故障之后,数据转发可以从其它链路进行转发。
如图3所示,当交换机D和交换机C间的工作链路出现故障后,交换机D和C间的通讯将中断(因为图2中交换机A到B的端口是阻塞的,于是交换机D、C间直连链路故障后,交换机D、C将无法通信),也就是出现了通信故障。此时可以将交换机A和B间的阻塞端口设置为可转发数据的状态,于是图2中的备份链路就变成了图3中的工作链路了,交换机D和C间的通信将通过交换机A、B来进行中转。这种情况我们将其称为故障恢复。当然了如果交换机A和B间的链路也出现故障,交换机D和C就将一直无法通信,这也是因为以太环网只有一条备份链路而导致的不足,因此本发明里面,我们提到的故障都是指一个环里面只有一条链路出现故障。
rfc3619定义了一种用于实现以太环网的技术,称为以太网自动保护切换(EAPs,Ethernet Automatic Protection switching),它同样涵盖了上面我们讲到冗余和故障恢复功能。EAPs技术被很多业界厂商支持,使用广泛。它的原理大致如下:
如图4所示,EAPs环定义了两种设备角色,Master(主交换机)和传输交换机。如图4所示在一个环路完整的情况下,Master负责将一个端口阻塞,避免数据形成环路。这里被阻塞的端口称为从端口,另外一个可转发数据的端口叫主端口。而对于传输交换机来说,则没有区分,都可以转发数据。在此需要说明的是,对于所有的交换机来说,阻塞仅仅表示无法转发,转发的意思是从一个端口到另一个端口,但是阻塞的端口无法阻挡来自本设备发出的报文,也无法阻挡来自其他设备发给本设备的报文,但可以阻挡需要经过本设备的报文。图4中的箭头表示了EAPs环完整时数据传输的情况,可以看到,Master的从端口到交换机B的链路100是无法转发数据的。
如图5所示,当环中某条链路出现故障,比如交换机D和C间链路出现断裂,则交换机D和C分别向Master发送一个链路断裂(down)消息,告诉Master有链路出现断裂。
如图6所示,Master收到down消息后,直接将从端口设置为可以转发数据,此时的EAPs环的拓扑变成图6所示的样子。图6中的箭头表示了新拓扑下数据传输的方向。
如图7所示,当交换机D和C间的链路再次恢复时,两台设备必须先阻塞各自刚刚恢复的端口,同时向Master发送链路恢复(up)消息,告诉master链路恢复了。必须先阻塞刚恢复的端口的原因是此时master的从端口是可以转发数据的,如果交换机D和C不阻塞的话,就会形成数据环路。
Master收到up消息后需要再次将从端口阻塞,同时分别向交换机C和D发送一个释放临时阻塞端口的指令(flush消息),这个flush消息是用于告诉交换机D和C:Master已经阻塞从端口了,可以将之前阻塞的端口恢复了。交换机D和C就可以放心的将图8中交换机D和C间的链路两端的两个端口设置为可转发数据,于是拓扑又恢复成图4的样子。
图7中交换机C和D会阻塞刚恢复的端口并向Master发送一个up消息,之后需要等待Master回复一个flush消息,就如图8所示。但是现实环境中可能存在某些异常导致Master无法回复这个up消息,比如网络拥塞等异常。一旦这种情况发生,如果交换机C和D还一直维持端口阻塞的状态,那么显然交换机C、D之间直连的链路将一直无法转发数据,更进一步的,一旦这种问题在多处链路发生,那么就会出现多条链路无法转发数据,这样会导致整个EAPs环通信异常。因此EAPs针对这种情况制定了一个flush消息超时机制。设备会等待一个时间段,如果超过了这个时间还没有收到Master的flush消息,那么设备应该将那些阻塞的端口恢复到可转发状态。这个超时时间最小是3秒,允许用户根据实际环境配置新的值。
可以看到EAPs的处理分两部分:传输交换机负责向Master通告链路是故障还是恢复了(通过down消息和up消息);Master负责根据收到消息决定从端口该阻塞还是可以转发数据,同时告诉传输交换机释放可能被阻塞的端口(通过flush消息)。
EAPs协议的设计比较理想化,在实际应用中会遇到一些问题,这里我们关注图7的情况,我们来仔细考虑一下图7的拓扑在实际应用中会遇到什么问题。设备在实际应用中各自的系统负荷是不一样的,因此它们对外界事件的响应速度也是不一样的。在图7中假设了交换机D和C间链路恢复后两台设备可以几乎同时发现这个恢复事件并向master报告。但实际应用中并不是这样的,设备间会由于很多原因,比如硬件配置等级不一样、处理的数据流量不一样、所处的物理环境不一样等导致它们的响应速度不一样,这种响应速度上的差异小则几个微妙,大则好几秒。而对于EAPs来说,如果这种差异达到一定的量级,会导致运行出错。同样以图7为例说明,假设这样一种情况:
交换机D先发现了链路恢复事件,阻塞了和交换机C相连的端口并向Master发送了up消息;由于EAPs协议的规定,即便只收到一个up消息,master也必须向两边发送flush消息,因此Master收到交换机D的up消息后,阻塞了从端口,同时向交换机D和C发送flush消息此时交换机D显然可以在收到flush消息后将端口恢复成可转发状态;但此时交换机C由于正在做一些繁忙处理,在收到Master的flush消息时还无法发现和交换机D连的链路已经恢复了,因此它会自动丢弃Master发送过来的flush消息。一段时间之后,交换机C才发现链路恢复了,于是它按照EAPs协议的约定阻塞和交换机D相连的端口,然后向Master发送一个up消息;但此时Master的从端口已经处于阻塞状态,也就是说Master认为此时环路应该已经是正常了,因此它会丢弃这个up消息,换句话说,EAPs协议是假定了设备间的响应速度相差无几,对这种异常情况没有提供处理措施。于是环路拓扑会变成如下一种情况:
如图9所示,由于Master不会处理交换机C的up消息,交换机C将无法收到Master的flush消息,进而导致交换机C和D相连的端口会一直阻塞。这样从图9中我们可以看到交换机C、B将无法和交换机D通信(因为有两个口被阻塞住了)。这种错误的状态会持续一段时间,也就是进入前面介绍的EAPs的超时等待时间,直到C认为Master的flush消息已经完全超时了,才能恢复和D相连的端口的转发状态。根据EAPs的规定,这个时间最小是3秒。而3秒的通信中断在很多应用中是无法被接受的,比如语音业务。
发明内容
有鉴于如上问题,本发明的主要目的在于提供一种以太环网链路恢复检测方法,以保证EAPs环在链路恢复时不会因为设备响应延迟而出现拓扑计算错误的情况。
相应地,本发明还提供一种以太环网主交换机。
为了实现上述目的,本发明实施例提供的以太环网链路恢复检测方法以太环网的主交换机确定从主端口、从端口都接收到链路恢复消息后,阻塞所述从端口,并通过所述主端口、从端口向待恢复的链路两端的交换机发送释放临时阻塞端口的指令。
本发明实施例还提供的以太环网主交换机包括:
接收单元,用于接收链路恢复消息;
确认单元,用于确认从主端口、从端口都接收到链路恢复消息;以及
发送单元,用于根据所述确认单元的确认阻塞所述从端口,并通过所述主端口、从端口向所述待恢复的链路两端的交换机设备发送释放临时阻塞端口的指令。
本发明提高了EAPs环的健壮性,在那些对通信质量要求很高又必须部署EAPs环的场合,应用本发明可以避免设备响应延迟而造成的通信的长时间中断问题,使得EAPs环可以应对更多的实际环境,并且本发明并没有修改EAPs协议本身,而是通过技术点上的完善使得EAPs协议本身更健壮,对已有的EAPs协议没有任何影响。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,并不构成对本发明的限定。在附图中:
图1为现有的以太网环形拓扑图;
图2为现有技术中显示了阻塞端口的以太网环拓扑图;
图3为现有技术中具有链路故障的以太网环拓扑图;
图4为现有技术中正常时的EAPs环拓扑图;
图5为图4对应的具有链路故障的EAPs环拓扑图;
图6为图5中故障处理后的EAPs环拓扑图;
图7为图6中故障链路恢复时的EAPs环拓扑图;
图8为图7中Master处理up消息时的EAPs环拓扑图;
图9为图8中故障链路两端的设备响应速度不同时导致的错误EAPs环拓扑;
图10为Master不处理up消息时的拓扑图;
图11为本发明实施例的可以提高以太环网的健壮性的以太环网链路恢复检测方法流程图;
图12为本发明实施例中对down消息的处理流程图;
图13为本发明实施例的以太环网主交换机的结构框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图对本发明的具体实施例进行详细说明。在此,本发明的示意性实施例及其说明用于解释本发明,但并不作为对本发明的限定。
在详细说明本发明的技术方案之前,首先分析一个EAPs环的特点,由此可以导出本发明的技术方案。
在图6中,交换机C、D间链路断裂后,Master将从端口设置为可以转发数据状态,于是图中四台设备都可以彼此正常通信。在图7中,交换机C、D间的链路再次恢复时交换机C、D会将刚恢复的链路所在的端口阻塞,并向Master发送up消息。分析一下这个时候设备间的通信情况,假设交换机C、D间链路恢复后,交换机C、D不会向Master发送up消息,由于没有up消息,Master的从端口将一直处于可转发状态,显然此时四台设备间的通信还是正常不中断的。即便此时交换机C、D直连的链路是不能转发的,但由于Master的从端口可以转发,所以实际效果上并不会影响设备间的通信。因此如果交换机C、D不向Master发up消息,显然即使交换机C、D间存在响应延迟,环上设备间的通信也不会中断。
不让交换机C、D向Master发up消息是一种方法,还有另外一种方法就是Master不处理up消息,这样从端口也不会变成阻塞状态,从而也可以达到通信不中断的目的,也就是如图10所示的情况。
但是交换机C、D不发up消息以及Master不处理up消息这两种方法都不能采用,因为EAPs协议的其它运算需要这些消息,这一点我们无法改变。但从上面分析中可以发现一个非常重要的特性:当链路再次恢复的时候,up消息处理的快慢其实不会影响到设备间的通信。正是基于EAPs环的这个特点,本发明对上面提出的up消息处理机制做一个改良:对第一个up消息延迟处理。于是就得到了本发明的新的、可行的提高以太环网健壮性的技术方案。
本发明实施例提供一种避免EAPs环在链路恢复时由于设备响应延迟而造成设备间通信中断的方法。实施方案如下:
(1)以太环网部署EAPs。
(2)链路恢复时Master对收到的第一个up消息进行缓存。
(3)直到在主端口和从端口上都收到了up消息,Master才向EAPs环上的其它设备发送flush消息。
(4)在缓存up消息期间,如果又收到down消息,则直接取消之前缓存的up消息。
经过以上方案实施,部署EAPs环时就无须担心设备响应延迟问题而导致的通信错误中断的问题。
下面对如上步骤进行详细说明:
根据本发明,交换机设备发现链路恢复后依然按EAPs的协议要求向Master发送up消息。Master在接收到第一个up消息后并不马上处理,而是先将该消息在对应接收端口上缓存起来。通过图7的介绍可以知道一条链路恢复会使得Master收到2个up消息。因此如果Master无法在主端口、从端口上都分别收到up消息,将不对之前的up消息做处理,之前的up消息会被一直缓存。直到主端口、从端口都收到了up消息(显然主端口、从端口上收到up消息的时间差,正好是设备响应的延迟差距),那么Master可以确定此时恢复的链路两端的设备都已经探测到了故障恢复并做了响应,于是Master才正式向主端口、从端口发送flush消息。于是恢复链路两端的设备都可以正确的处理fush消息。
另,本发明中,如果是在up消息缓冲的时间内收到down消息,则up消息必须被马上取消。从图5的介绍中可以知道down消息意味着EAPs环上有链路断裂,那么此时Master一定要保持从端口处于可转发状态。假如不取消这个缓存的up消息,一旦后面那个延迟的up消息到来的时候,2个up消息一匹配会导致Master又将从端口阻塞,从而导致通信又中断了。而通过将缓存的up消息取消,一方面符合Master对down消息的处理,另一方面,也可以避免延迟达到的up消息使得Master的从端口又错误的被阻塞。
图11为本发明实施例的Master处理up消息的流程图,具体包括如下步骤:
步骤110,Master接收到up消息;
步骤120,判断本设备是否已经缓存有up消息;
步骤130,当判断未缓存有up消息,则缓存所接收的消息;以及
步骤140,当判断已经缓存有up消息,则阻塞该主交换机的从端口,并发送flush消息至待恢复的链路两端的交换机设备。
图12为本发明实施例的在up消息缓存期间Master处理down消息的流程图,具体包括如下步骤:
步骤210,Master接收到down消息;
步骤220,判断本设备是否已经缓存有up消息;
步骤230,当判断未缓存有up消息,则设置该交换机的从端口为可转发状态;以及
步骤240,当判断已经缓存有up消息,则取消缓存的up消息。
如图13所示为实现如上以太环网链路恢复检测方法的以太环网主交换机(Master)示意图,该Master可包括:
接收单元,用于接收up消息;
确认单元,用于确认从主端口、从端口都接收到链路恢复消息。以及
发送单元,用于根据所述确认单元的确认阻塞所述从端口,并通过所述主端口、从端口向所述待恢复的链路两端的交换机设备发送flush消息。
所述确认单元包括缓冲存储器及第一判断单元。其中,缓冲存储器用于缓存up消息;第一判断单元用于在接收单元接收到up消息时判断所述缓冲存储器中是否缓存有up消息,并在判断未缓存有up消息时,控制所述缓冲存储器缓存接收单元接收的up消息,在判断已经缓存有up消息时确认从主端口、从端口都接收到up消息。
该Master还包括:第二判断单元,用于在接收到down消息时,判断是否已经缓存有up消息;以及处理单元,用于在所述第二判断单元判断未缓存有up消息时,设置该交换机的从端口为可转发状态,并在所述第二判断单元判断已经缓存有up消息时,取消缓存的up消息。
按照本发明上述的技术方案,可以保证EAPs环在链路恢复时不会因为设备响应延迟而出现拓扑计算错误的情况。本发明的优点体现在于:
(1)提高了EAPs环的健壮性
在那些对通信质量要求很高又必须部署EAPs环的场合,应用本发明可以避免设备响应延迟而造成的通信的长时间中断问题,使得EAPs环可以应对更多的实际环境。
(2)对EAPs协议本身没有任何影响
本发明并没有修改EAPs协议本身,而是通过技术点上的完善使得EAPs协议本身更健壮,对已有的EAPs协议没有任何影响。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读取存储介质中,比如ROM/RAM、磁碟、光盘等。
以上所述的具体实施例,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施例而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (6)
1.一种以太环网链路恢复检测方法,其特征在于:
以太环网的主交换机确定从主端口、从端口都接收到链路恢复消息后,阻塞所述从端口,并通过所述主端口、从端口向待恢复的链路两端的交换机发送释放临时阻塞端口的指令。
2.根据权利要求1所述的方法,其特征在于,该方法具体包括:
以太环网的主交换机接收到链路恢复消息时,判断是否已经缓存有链路恢复消息;
当判断未缓存有链路恢复消息,则缓存所接收的消息;以及
当判断已经缓存有链路恢复消息,则阻塞该主交换机的从端口,并发送释放临时阻塞端口的指令至待恢复的链路两端的交换机设备。
3.根据权利要求2所述的方法,其特征在于,该方法还包括:
以太环网的主交换机接收到链路断裂消息时,判断是否已经缓存有链路恢复消息;
当判断未缓存有链路恢复消息,则设置该交换机的从端口为可转发状态;以及
当判断已经缓存有链路恢复消息,则取消缓存的链路恢复消息。
4.一种以太环网主交换机,其特征在于,该以太环网主交换机包括:
接收单元,用于接收链路恢复消息;
确认单元,用于确认从主端口、从端口都接收到链路恢复消息;以及
发送单元,用于根据所述确认单元的确认阻塞所述从端口,并通过所述主端口、从端口向待恢复的链路两端的交换机设备发送释放临时阻塞端口的指令。
5.根据权利要求4所述的以太网主交换机,其特征在于,所述确认单元包括:
缓冲存储器,用于缓存链路恢复消息;以及
第一判断单元,用于在接收单元接收到链路恢复消息时判断所述缓冲存储器中是否缓存有链路恢复消息,并在判断未缓存有链路恢复消息时,控制所述缓冲存储器缓存接收单元接收的链路恢复消息,在判断已经缓存有链路恢复消息时确认从主端口、从端口都接收到链路恢复消息。
6.根据权利要求5所述的以太网主交换机,其特征在于,该以太网主交换机还包括:
第二判断单元,用于在接收到链路断裂消息时,判断是否已经缓存有链路恢复消息;
处理单元,用于在所述第二判断单元判断未缓存有链路恢复消息时,设置该交换机的从端口为可转发状态,并在所述第二判断单元判断已经缓存有链路恢复消息时,取消缓存的链路恢复消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810115524XA CN101309215B (zh) | 2008-06-25 | 2008-06-25 | 一种以太环网链路恢复检测方法及以太环网主交换机 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810115524XA CN101309215B (zh) | 2008-06-25 | 2008-06-25 | 一种以太环网链路恢复检测方法及以太环网主交换机 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101309215A CN101309215A (zh) | 2008-11-19 |
CN101309215B true CN101309215B (zh) | 2010-12-15 |
Family
ID=40125440
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200810115524XA Expired - Fee Related CN101309215B (zh) | 2008-06-25 | 2008-06-25 | 一种以太环网链路恢复检测方法及以太环网主交换机 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101309215B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101651616B (zh) * | 2009-09-04 | 2011-09-28 | 杭州华三通信技术有限公司 | 主链路恢复控制方法和交换机系统以及交换机 |
CN102055660B (zh) * | 2009-11-10 | 2012-07-11 | 杭州华三通信技术有限公司 | 主链路恢复控制方法和交换机系统 |
CN101764731B (zh) * | 2009-12-09 | 2011-11-30 | 熊伟 | 一种以太网环网算法切换方法 |
CN103200172B (zh) | 2013-02-19 | 2018-06-26 | 中兴通讯股份有限公司 | 一种802.1x接入会话保活的方法及系统 |
CN104243334B (zh) * | 2014-09-26 | 2017-08-11 | 新华三技术有限公司 | 防止链路拥塞的方法和设备 |
CN107171840B (zh) * | 2017-05-22 | 2019-12-06 | 杭州迪普科技股份有限公司 | 一种基于erps协议的保护倒换方法和装置 |
CN113055041B (zh) * | 2019-12-26 | 2022-04-05 | 大唐移动通信设备有限公司 | 基带单元、扩展单元、射频单元及数字室分设备自检方法 |
-
2008
- 2008-06-25 CN CN200810115524XA patent/CN101309215B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN101309215A (zh) | 2008-11-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101309215B (zh) | 一种以太环网链路恢复检测方法及以太环网主交换机 | |
CN101001192B (zh) | 一种环网链路保护的方法、系统及设备 | |
JP5471240B2 (ja) | スイッチ装置、リングネットワークシステム、通信制御方法、および装置のプログラム | |
JP5073812B2 (ja) | 分散型イーサネットシステムおよび該システムに基づいて障害を検出する方法 | |
KR101460391B1 (ko) | 이더넷 링 네트워크 시스템, 그 전송 노드 및 그 초기화 방법 | |
CN101212366B (zh) | 以太环网中的故障检测方法、系统及主节点 | |
US7440397B2 (en) | Protection that automatic and speedily restore of Ethernet ring network | |
US8213296B2 (en) | Link aggregation protection | |
EP2194676B1 (en) | Ethernet ring system, its main node and intialization method | |
CN101330422A (zh) | 以太环网中防止广播风暴的方法及以太环网传输交换机 | |
AU737333B2 (en) | Active failure detection | |
EP2207307B1 (en) | Method for processing the failure of the slave port of the master node in an ethernet ring network system | |
US8264954B2 (en) | Method and device for operating a network and communication system comprising such device | |
CN100454880C (zh) | 一种实现环网保护的方法及系统 | |
CN101094190B (zh) | 以太环网保护控制报文的传输方法 | |
CN101436975B (zh) | 一种在环网中实现快速收敛的方法、装置及系统 | |
WO2013078997A1 (zh) | 一种处理mrp环网中的故障的方法和mrp环网 | |
JP4405941B2 (ja) | 回線冗長化方法およびこれに用いる中継装置 | |
CN101547131B (zh) | Eaps环网单通故障定位和保护方法 | |
JP2008544678A (ja) | 通信ネットワークシステム | |
CN102238067A (zh) | 一种快速环网保护协议环上的切换方法和装置 | |
CN101753368A (zh) | 一种以太网的保护方法 | |
JP5004758B2 (ja) | レイヤ2ネットワークおよびネットワーク接続装置 | |
CN101641915A (zh) | 重构通信网络的方法 | |
WO2006075403A1 (ja) | 伝送装置および障害通知方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20101215 Termination date: 20210625 |
|
CF01 | Termination of patent right due to non-payment of annual fee |