网管设备、分级网管系统及其查询被管设备状态的方法

文档序号:7869492阅读:384来源:国知局
专利名称:网管设备、分级网管系统及其查询被管设备状态的方法
技术领域
本发明涉及网络领域,尤其涉及ー种网管设备、分级网管系统及其查询被管设备状态的方法。
背景技术
分级网管系统如图1所示,各级设备依次相连后与网管设备相连,所述各级设备均为被管设备;其中,上级设备和下级设备是相对的概念。例如,在图1中,一级设备是ニ级至N级设备的上级设备,ニ级设备又是三级至N级设备的上级设备。相対的,ニ级至N级设备都是一级设备的下级设备,三级至N级设备又是ニ级设备的下级设备。为了描述简单,将图1抽象成如图2所示的模型网管设备通过上级设备连接下级设备。在分级网管 系统中,网管设备对各级被管设备的网管指令可简单的分为两种状态查询和命令。当各级被管设备收到网管设备的状态查询指令时,响应自己的状态。收到网管设备的命令指令吋,响应执行是否成功。在图2所示的模型中,上级设备起着承上启下的作用向下中转网管设备对下级设备的指令,向上汇报下级设备对网管设备的响应。为了保证响应的速度,状态报文通常采用逐级代理的方式。即上级设备定时查询下级设备,并将下级设备的状态报文保存在本地的下级设备状态缓冲区中,当网管设备来查下级设备的状态时,直接将本地保存的下级设备状态上报。如图3所示,随着设备功能的増加,常常出现新做的下级设备有多种类型的状态
块的情况,比如图3中下级设备里的状态1、状态2、......、状态n。而上级设备只有ー块
下级设备状态缓冲区(可能是由于上级设备没有资源,也可能是上下级的通信协议根本不能区分不同的状态块的类型)。此时,如果下级设备直接采用轮流上报几种类型状态块的方式,那么当网管设备的轮询周期大于下级设备状态上报的周期时,就可能出现网管设备永远也收不到某块状态的情況。例如,网管设备第一次查询时,收到了下级设备的第I种类型的状态块;接着网管设备去轮询其他设备了,一段时间后,当第二次查询该下级设备的状态时,却收到了第3种类型的状态块。因为在网管设备轮询其他设备的那段时间内,下级设备已经上报过第2种类型的状态块了,但是网管设备却没有查。

发明内容
本发明要解决的技术问题是如何使上级设备只用一块缓冲区就可以代理下级设备多个状态块。为了解决上述问题,本发明提供了一种分级网管系统查询被管设备状态的方法,包括各级被管设备向网管设备上报状态块,每次仅上报一种类型的状态块,并在上报时携带所上报状态块的类型;所述网管设备在收到一被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。进一步地,所述的方法还包括网管设备下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的一种。进一步地,各级被管设备上报状态块的格式包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型用于标识是哪一种类型的状态块;网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。进一步地,被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的;所述各级被管设备向网管设备上报状态块的步骤包括当到达状态发送时刻时,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块。进一步地,所述的方法还包括网管设备当预定时间到达时或当收到的某个被管设备本次上报的状态块的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,选择位于最近一次上报的类型之后的类型,作为所查询状态块的类型,向该被管设备发送状态查询命令。进一步地,任一项所述的方法还包括各级被管设备当上报某一块非预设的状态块的时间长度超过第一时间阈值或次数超过次数阈值吋,恢复为上报预设的状态块。本发明还提供了一种分级网管系统,包括各级被管设备及网管设备;所述各级被管设备用于向网管设备上报状态块,每次仅上报一种类型的状态块,并在上报时携帯所上报状态块的类型;所述网管设备用于在收到一被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。进一步地,所述网管设备还用于下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的一种。进一步地,各级被管设备上报状态块的格式包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型用于标识是哪一种类型的状态块;网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。进一步地,被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的; 所述各级被管设备向网管设备上报状态块是指各级被管设备当到达状态发送时刻时,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块;通常可以将对于本设备来说最基本最重要的状态块作为预设的状态块。进ー步地,所述网管设备还用于当预定时间到达时或当收到的某个被管设备本次上报的状态块的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。进ー步地,各级被管设备还用于当上报某ー块非预设的状态块的时间长度超过第ー时间阈值或次数超过次数阈值时,恢复为上报预设的状态块。本发明还提供了ー种网管设备,其特征在于,应用在各级被管设备向网管设备上报状态块、毎次仅上报一种类型的状态块并在上报时携帯所上报状态块的类型的分级网管系统中;包括接收模块,用于接收被管设备上报的状态块;记录模块,用于将所接收的状态块中所携帯的类型,记录为该被管设备本次上报的状态块的类型。进ー步地,所述的网管设备还包括查询模块 ,用于下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在本网管设备中的、该被管设备的状态块的类型中的ー种。进ー步地,网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。进ー步地,所述的网管设备还包括控制模块,用于当预定时间到达时或当收到的被管设备本次上报的状态块的类型和上次不一样时,从预先定义在本网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,指示所述查询模块将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。本申请的至少ー个实施例中,由于网管设备掌握了各级被管设备上报哪ー块状态的主动权,因此上级设备可以不必了解下级被管设备各状态块的类型,也不必为各类型的状态块单独准备缓冲区,因而可使得上级设备只用一块缓冲区就可以代理下级设备的多个状态块,且实现简单,功能良好。这样,在下级设备功能升级,报文增加的情况下,不需升级上级设备,也不需大量更改通信协议,网管设备就能完整的查询到下级设备的所有状态。


图1是现有技术中的分级网管系统的结构示意图;图2是现有技术中的分级网管系统的简略示意图;图3是现有技术中分级网管系统中的状态上报示意图;图4是实施例一中的上报状态块的协议格式示意图5是实施例一中的状态查询命令的协议格式示意图;图6是实施例一的上报状态块的例子中的协议格式示意图;图7是实施例一的状态查询命令的例子中的协议格式示意图;图8是实施例一中一种备选方案的流程不意图;图9是实施例一中另ー种备选方案的流程示意图。
具体实施例方式下面将结合附图及实施例对本发明的技术方案进行更详细的说明。需要说明的是,如果不冲突,本发明实施例以及实施例中的各个特征可以相互结合,均在本发明的保护范围之·内。另外,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。实施例一,一种分级网管系统查询被管设备状态的方法,包括各级被管设备向网管设备上报状态块,每次仅上报一种类型的状态块,并在上报时携带所上报状态块的类型;所述网管设备在收到ー被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。本实施例的一种备选方案中,所述方法还包括网管设备下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的ー种。各被管设备中状态块的多种类型会预先定义在网管设备的配置信息或其它文件中;如果新增被管设备或状态块的类型,则会更新所述配置信息或其它文件。如果根据预先定义,某个被管设备的状态块只有ー种类型,则网管设备可不发送状态查询命令。本实施例的一种备选方案中,为了让各级被管设备上报状态时携带状态块的类型、以及让网管设备可下发携带所查询状态块的类型的状态查询命令,可修改网管设备和各级被管设备之间的通信协议。在各级被管设备上报的状态块中増加状态块的类型。网管设备下发的命令中増加状态查询命令,其中包括所查询状态块的类型。各级被管设备上报状态块的格式可如图4所示,包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型为新增字段,用于标识是哪ー种类型的状态块。网管设备下发状态查询命令的格式可如图5所示,包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。假设ー个例子中,某级设备有3块状态信息,分别是类型为A的状态块、类型为B的状态块、类型为C的状态块;则上报状态块时的三种消息格式如图6所示,与图4所示的协议格式基本相同,只是其中的状态块类型分别为A、B、C。网管设备下发给下级设备的通信协议中应增加状态查询命令,在上例中,根据其中携帯的所查询状态块的类型的不同共有三种命令格式,如图7所示,与图5所示的协议格式基本相同,只是其中的命令块类型分别为A、B、C,分别表示用于查询类型为A的状态块、查询类型为B的状态块、查询类型为C的状态块。本实施例的一种备选方案中,被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的。所述各级被管设备向网管设备上报状态块的步骤具体包括当到达状态发送时刻(比如状态发送的周期的开始时刻)时,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块;通常可以将对于本设备来说最基本最重要的状态块作为预设的状态块。这样当网管设备未发送状态查询命令时,下级设备可以只上报某ー状态块;当收到来自网管设备的状态查询命令时,再固定上报该状态查询命令中指定的状态块。这样网管设备就掌握了各级被管设备上报哪ー块状态的主动权,从而保证网管设备能够收齐各级被管设备的所有状态信息。假设某级设备最基本最重要的状态块为状态块A,则将状态块A作为预设的状态块。当到达状态发送时刻,上报状态开始,如果未收到过网管设备发送的状态查询命令,该设备可以只上报状态块A。如果收到过网管设备的状态查询命令,则根据该状态查询命令中的命令块类型判断要查询的状态块类型,如果是查询状态块A则上报状态块A ;如果是查询状态块B则上报状态块B ;如果是查询状态块C则上报状态块C ;如果均不是,则说明该设备中没有状态查询命令中的命令块类型,进行报错、或者不发状态块。流程如图8所示。本实施例的一种备选方案中,所述方法还包括网管设备当预定时间到达时或当收到的某个被管设备本次上报的状态块的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,选择位于最近一次上报的类型之后的类型,作为所查询状态块的类型,向该被管设备发送状态查询命令。 如果是因为预定时间到达要发送状态查询命令,则最近一次上报的类型为到达该预定时间前最后一次收到的状态块的类型;如果是因为状态块变化而要发送状态查询命令,则最近一次上报的类型为本次上报的状态块的类型。网管设备中,各状态块的顺序可以为默认的或预先排定的。本实施例的其它备选方案中,网管设备还可以采用其它发送状态查询命令的策略,而且对不同的被管设备可以采用不同的策略;比如对有的被管设备采用上述备选方案中“到达预定时间或状态块的类型发生变化时发送状态查询命令来查询下ー个状态块”的策略;而对有的被管设备则可以采用基于状态信息的策略,网管设备分析被管设备的预设状态,当发现被管设备的某些状态有变化、需要获知其它状态时,发送状态查询命令查询所需要获知的状态块;收到需要获知的状态块后,还可以再发送ー个状态查询命令查询预设的状态块。采用哪种策略,由被管设备状态块之间的关系決定。当被管设备状态块之间关系不紧密,重要性相当时,可选用上述备选方案中的策略。当被管设备某些状态块不重要,不需时时上报,而又依附于预设的或其它状态块时,可以采用基于状态信息的策略;在有的情况下,也可以两者混合使用。实际方案中不限于上述提及的策略,还可以根据需要自行设计策略。这样网管设备可以充分掌握被管设备上报哪ー类型状态块的主动权。比如在ー个具体例子中,流程如图9所示,当网管设备进入接收状态后,先接收状态块,假设被管设备先一直发送预设的状态块,则在定时时间到达前,网管设备会判断收到的状态块和上次的相同;因此不发送命令就结束接收状态。当预定时间到达后,网管设备再进入接收状态时会先接收状态块,然后判断预定时间到达,因此发送查询下ー个状态块的状态查询命令,如果本次发送的是状态块A/B/C,则发送查询状态块B/C/A的状态查询命令(假设预先定义的排列顺序为状态块A、B、C)。该备选方案中,状态块改变再发命令的主要目的是防止被管设备状态上报慢,而网管设备查询快,这样会多发许多不必要的命令。所述定时时间的长度选取与被管设备状态上报的周期长度有夫,最好略大于状态上报的周期长度。本实施例的一个备选方案中,可以将ー个分级网管系统中的被管设备设置成不同的上报策略,比如有的被管设备在没收到网管设备的状态查询命令时只上报预设的状态块,而另一些被管设备在没收到网管设备的状态查询命令时则轮流上报各类型的状态块。在本实施例的一个备选方案中,所述方法还可以包括各级被管设备上,当上报某一块非预设的状态块的时间长度(即从第一次上报该状态块的时刻到当前时刻的时间长度)超过第一时间阈值或次数超过次数阈值时,恢复为上报预设的状态块(比如可以丢弃所保存的要求查询其它类型状态块的状态查询命令,或将该状态查询命令标识为不使用;这样在到达状态上报时刻后,就会上报预设的状态块)。在本实施例的一个备选方案中,所述方法还可以包括在网管设备上,发送状态查询命令后如果未发生信息块变化的时间长度(即从上一次发送状态查询命令的时刻到当前时刻的时间长度)超过第二时间阈值,则再次重发状态查询命令。这两个备选方案是为了避免通信异常,造成上报状态错误或丢失命令,使网管设备长时间不能收到某些状态块。实施例ニ,ー种分级网管系统,包括各级被管设备及网管设备;所述各级被管设备用于向网管设备上报状态块,每次仅上报ー种类型的状态块,并在上报时携帯所上报状 态块的类型;所述网管设备用于在收到一被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。本实施例的一种备选方案中,所述网管设备还用于下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的ー种。本实施例的一种备选方案中,各级被管设备上报状态块的格式包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型用于标识是哪ー种类型的状态块;网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。本实施例的一种备选方案中,被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的;所述各级被管设备向网管设备上报状态块是指各级被管设备当到达状态发送时刻时,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块;通常可以将对于本设备来说最基本最重要的状态块作为预设的状态块。本实施例的一种备选方案中,所述网管设备还用于当预定时间到达时或当收到的某个被管设备本次上报的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。本实施例的一种备选方案中,各级被管设备还用于当上报某ー块非预设的状态块的时间长度超过第一时间阈值或次数超过次数阈值时,恢复为上报预设的状态块。实施例三,ー种网管设备,应用在各级被管设备向网管设备上报状态块、毎次仅上报ー种类型的状态块并在上报时携帯所上报状态块的类型的分级网管系统中;包括接收模块,用于接收被管设备上报的状态块;其特征在于,还包括记录模块,用于将所接收的状态块中所携帯的类型,记录为该被管设备本次上报的状态块的类型。本实施例的一种备选方案中,所述的网管设备还包括查询模块,用于下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在本网管设备中的、该被管设备的状态块的类型中的ー种。本实施例的一种备选方案中,网管设 备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。本实施例的一种备选方案中,所述的网管设备还包括控制模块,用于当预定时间到达时或当收到的被管设备本次上报的状态块的类型和上次不一样时,从预先定义在本网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,指示所述查询模块将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成,所述程序可以存储于计算机可读存储介质中,如只读存储器、磁盘或光盘等。可选地,上述实施例的全部或部分步骤也可以使用ー个或多个集成电路来实现。相应地,上述实施例中的各模块/単元可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明的权利要求的保护范围。
权利要求
1.一种分级网管系统查询被管设备状态的方法,包括 各级被管设备向网管设备上报状态块,毎次仅上报一种类型的状态块,并在上报时携带所上报状态块的类型; 所述网管设备在收到ー被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。
2.如权利要求1所述的方法,其特征在于,还包括 网管设备下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的ー种。
3.如权利要求2所述的方法,其特征在于 各级被管设备上报状态块的格式包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型用于标识是哪ー种类型的状态块; 网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。
4.如权利要求2所述的方法,其特征在于 被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的; 所述各级被管设备向网管设备上报状态块的步骤包括 当到达状态发送时刻吋,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块。
5.如权利要求2到4中任一项所述的方法,其特征在于,还包括 网管设备当预定时间到达时或当收到的某个被管设备本次上报的状态块的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,选择位于最近一次上报的类型之后的类型,作为所查询状态块的类型,向该被管设备发送状态查询命令。
6.如权利要求2到4中任一项所述的方法,其特征在于,还包括 各级被管设备当上报某ー块非预设的状态块的时间长度超过第一时间阈值或次数超过次数阈值吋,恢复为上报预设的状态块。
7.ー种分级网管系统,包括各级被管设备及网管设备; 其特征在于 所述各级被管设备用于向网管设备上报状态块,毎次仅上报一种类型的状态块,并在上报时携帯所上报状态块的类型; 所述网管设备用于在收到一被管设备上报的状态块后,将其中所携帯的类型记录为该被管设备本次上报的状态块的类型。
8.如权利要求7所述的系统,其特征在于 所述网管设备还用于下发状态查询命令给被管设备,在所述状态查询命令中携帯所查询状态块的类型;其中,所查询状态块的类型为预先定义在该网管设备中的、该被管设备的状态块的类型中的ー种。
9.如权利要求8所述的系统,其特征在于 各级被管设备上报状态块的格式包括协议头、状态块类型、状态块净荷、协议尾;其中,状态块类型用于标识是哪一种类型的状态块; 网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。
10.如权利要求8所述的系统,其特征在于 被管设备当收到网管设备的状态查询命令时,保存该状态查询命令;如果该被管设备中存在之前收到的状态查询命令,则用新收到的状态查询命令代替之前收到的; 所述各级被管设备向网管设备上报状态块是指 各级被管设备当到达状态发送时刻时,如果存在保存的状态查询命令,则上报该状态查询命令中所指定类型的状态块;否则上报预设的状态块;通常可以将对于本设备来说最基本最重要的状态块作为预设的状态块。
11.如权利要求8到10中任一项所述的系统,其特征在于 所述网管设备还用于当预定时间到达时或当收到的某个被管设备本次上报的状态块的类型和上次不一样时,从预先定义在该网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。
12.如权利要求8到10中任一项所述的系统,其特征在于 各级被管设备还用于当上报某一块非预设的状态块的时间长度超过第一时间阈值或次数超过次数阈值时,恢复为上报预设的状态块。
13.—种网管设备,其特征在于,应用在各级被管设备向网管设备上报状态块、每次仅上报一种类型的状态块并在上报时携带所上报状态块的类型的分级网管系统中;包括 接收模块,用于接收被管设备上报的状态块; 其特征在于,还包括 记录模块,用于将所接收的状态块中所携带的类型,记录为该被管设备本次上报的状态块的类型。
14.如权利要求13所述的网管设备,其特征在于,还包括 查询模块,用于下发状态查询命令给被管设备,在所述状态查询命令中携带所查询状态块的类型;其中,所查询状态块的类型为预先定义在本网管设备中的、该被管设备的状态块的类型中的一种。
15.如权利要求14所述的网管设备,其特征在于 网管设备下发状态查询命令的格式包括协议头、命令块类型、命令块净荷、协议尾;其中,命令块类型用于表示所查询状态块的类型。
16.如权利要求14或15所述的网管设备,其特征在于,还包括 控制模块,用于当预定时间到达时或当收到的被管设备本次上报的状态块的类型和上次不一样时,从预先定义在本网管设备中的该被管设备的状态块的类型中,查询位于最近一次上报的类型之后的类型,指示所述查询模块将所查询到的类型作为所查询状态块的类型,向该被管设备发送状态查询命令。
全文摘要
本发明公开了一种网管设备、分级网管系统及其查询被管设备状态的方法;所述方法包括各级被管设备向网管设备上报状态块,每次仅上报一种类型的状态块,并在上报时携带所上报状态块的类型;所述网管设备在收到一被管设备上报的状态块后,将其中所携带的类型记录为该被管设备本次上报的状态块的类型。本发明能使上级设备只用一块缓冲区就可以代理下级设备多个状态块。
文档编号H04L12/24GK103051475SQ201210558668
公开日2013年4月17日 申请日期2012年12月20日 优先权日2012年12月20日
发明者李静芳 申请人:瑞斯康达科技发展股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1