CN102523119B - 基于snmp协议的epon网管系统数据传输方法 - Google Patents
基于snmp协议的epon网管系统数据传输方法 Download PDFInfo
- Publication number
- CN102523119B CN102523119B CN201110429075.8A CN201110429075A CN102523119B CN 102523119 B CN102523119 B CN 102523119B CN 201110429075 A CN201110429075 A CN 201110429075A CN 102523119 B CN102523119 B CN 102523119B
- Authority
- CN
- China
- Prior art keywords
- list
- snmp
- subpackage
- message
- node
- 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.)
- Active
Links
Abstract
本发明提供了基于SNMP协议的EPON网管系统数据传输方法。本发明按分类将属性组织成不同的表单,若表单的长度超过SNMP报文净荷空间约定最大值,则对表单进行压缩处理,若压缩后表单长度仍超过约定最大值,则对压缩后的表单进行分片处理,否则直接进入后续步骤;然后将表单绑定到各自对应的管理信息库变量上,若表单未分片,则直接将表单组装到SNMP报文中,若对表单进行过分片处理,则将分片后的每个子表单组装到单个SNMP报文中;最后在网管服务器和光线路终端的网管代理端之间双向传输组装后的SNMP报文。本发明能减少SNMP网管服务器端与OLT Agent端两者之间SNMP报文交互次数,减少网络间的通信量。
Description
技术领域
本发明属于EPON(以太网无源光网络)领域SNMP(简单网络管理协议)网管服务器与被管OLT(光线路终端)设备SNMP Agent(网管代理端)之间的数据传输技术,特别是涉及一种基于EPON系统SNMP网管服务器与OLT Agent之间通过SNMP协议高效率地传输大量数据的方法。
背景技术
当前,SNMP协议被广泛地应用在EPON网管系统中。下面分别介绍SNMP协议和EPON网管系统的特点。
一.现有的SNMP报文及机制的特点:
当前的SNMP协议存在有缺陷。当通过SNMP协议传输大量信息时,数据传输的效率低下,挤占管理通道带宽,占用网管端CPU处理能力,导致网管端响应性能低下,这些说明SNMP协议不适合检索大量数据,不适合管理很大的网络。这些固有的缺陷具体如下所述:
1.SNMP报文的缺陷:
(1)SNMP报文中单个变量携带的信息量过少。标准的SNMP变量主要包括8位、16位、32位、64位的整型,以及不定长的字符串,每个变量通常仅携带单个信息,例如:以太网端口的速率信息,设备的型号信息等。
(2)SNMP报文包装在UDP(用户数据报协议)报文中传输,单条SNMP报文最大净荷空间是1472字节。但SNMP报文在大多数情况下仅绑定了少量变量,报文净荷空间没有得到充分利用。
(3)即使单条SNMP报文绑定多个变量,达到了报文净荷空间全长,但是报文中每个变量的OID(对象标识符)字段都要占用空间,而且报文所采用的BER(基本编码规则)编码空间利用率低,单条报文中变量信息所占用的空间也不会超过50%。
(4)SNMP协议采用一应一答的交互模式,不能直接DMA(直接存储访问),一次交互两边需要各发送一条报文,浪费了带宽,增加了网络繁忙。
2.SNMP机制的缺陷:
SNMP协议采用轮询的方式从Agent端收集数据,采集数据的负担完全压在网管端上。在工程实际应用中,为了保持数据的历史记录,网管端需要在一定的时间间隔内不断地进行SNMP轮询,并把轮询得到的结果存储在本地以便将来能够对这些数据进行查询和分析。在EPON系统OLT网络中,面对数千台ONU(光网络单元)设备及上万个采集点的数据采集量,网管端的负担太重,网管端甚至不能在设定的时间间隔内做一次完整的轮询。并且大量的SNMP交互报文在网络中传输,严重浪费了管理带宽,甚至导致网络通信阻塞。另外,网管端系统CPU也不堪负重,导致网管性能低下,网管界面响应缓慢。
二.EPON系统网管自身的特点:
1.需要管理的SNMP变量实例数量庞大:
以东研网络公司的框式OLT设备VISTA1600F为例,单台设备满配置需要管理40个PON(无源光网络)口,10个上联口,1280个ONU,5120个UNI(用户网络接口)端口。另外,在每一个UNI端口下,还可以连接32个需要管理的EoC(同轴电缆以太网)设备。如果网管端同时管理10台甚至更多台这样的OLT设备,它需要管理的对象数量是非常庞大的。
2.被管理的网络拓扑结构随时可能发生变化:
在EPON系统OLT网络中,远端的ONU及EoC设备,由于安放在用户处,因此随时都有可能断电下线,整个网络的拓扑随时都可能变动。这就需要网管端不间断地去轮询被管网络,及时更新网络拓扑,这就需要大量的SNMP轮询报文交互。
上述SNMP协议及EPON OLT系统网管两方面特点说明,对于EPON系统的SNMP网管,传统的SNMP协议的固有缺陷,在EPON系统中被放大得更加明显,严重影响了管理网络性能及网管端响应性能,因此在EPON系统中SNMP协议,非常有必要在“高效率地传输大量数据”方面进行改造。
发明内容
本发明所要解决的技术问题是:提供一种基于SNMP协议的EPON网管系统数据传输方法,该方法能减少SNMP网管端与OLT Agent端两者之间SNMP报文交互次数,减少网络间的通信量。
本发明所采用的技术方案是:基于SNMP协议的EPON网管系统数据传输方法,包括:首先对光线路终端中需要管理的属性进行分类,按分类将属性组织成不同的表单;若表单的长度超过一个SNMP报文净荷空间约定最大值,则对表单进行压缩处理,若压缩后表单长度仍超过约定最大值,则对压缩后的表单进行分片处理,否则直接进入后续步骤;然后将表单绑定到各自对应的管理信息库变量上,若表单未分片,则直接将表单组装到SNMP报文中,若对表单进行过分片处理,则将分片后的每个子表单组装到单个SNMP报文中;最后在网管服务器和光线路终端的网管代理端之间双向传输组装后的SNMP报文。
所述的方法,将表单内部相关联的属性分成项目块,并在表单中顺次排列每个项目块。
所述的方法,通过zlib库函数对表单进行压缩。
所述的方法,对于需要分包的表单通过管理信息库树节点的对象标识符节点进行标识,对象标识符节点的子节点包括表单查询标量节点、表单分包数标量节点以及表单净荷表节点。
所述的方法,所述每个表单各对应一个八进制字符串格式的管理信息库变量。
所述的方法,SNMP报文中净荷空间约定最大长度1024字节。
所述的方法,每个表单头部包括分片后的子表单头部,还增加自定义报文头,其格式见下表:
序号 | 字段名称 | 数据长度(单位:字节) | 说明 |
1 | 报文净荷总长度 | 4 | |
2 | 压缩标志位 | 4 | 标示报文净荷是压缩净荷还是非压缩净荷 |
3 | 报文分包总个数 | 2 | |
4 | 本分包序号 | 2 | |
5 | 本分包净荷长度 | 4 | |
6 | 保留 | 8 |
所述的方法,网管服务器和光线路终端的网管代理端之间的动作包括表单查询流程和表单配置流程;
表单查询流程包括以下步骤:
S11)网管服务器端根据查询条件,组织查询条件表单,将该表单绑定到表单查询标量节点,组装成SNMP查询报文并用SNMP Set操作下发到光线路终端;
S12)光线路终端根据收到的查询表单的查询条件执行查询动作;
S13)光线路终端将查询结果组织成应答表单,如果应答表单长度大于约定最大值,将执行压缩动作,如果压缩后长度仍大于约定最大值,将执行分包动作分成复数个表单子包;表单未压缩或未分包时,将表单子包个数设定为1;
S14)光线路终端将表单子包个数绑定到表单分包数标量节点上,将各表单子包数据绑定到表单净荷表节点的各个实例上,组装成各SNMP报文发送到网管服务器;
S15)网管服务器先通过SNMP Get操作表单分包数标量节点,读取本次应答SNMP报文的子包个数;
S16)网管服务器然后通过SNMP Get操作遍历表单净荷表节点的所有实例,并验证实例个数;实例个数应该等于S15步骤中获取的表单分包数标量节点的值,否则本次查询操作失败;
S17)网管服务器将获取的表单净荷表节点的所有实例,根据SNMP报文子包的报文头信息进行组装,得到完整的应答表单;如果应答表单是压缩表单,还执行解压缩动作;
S18)网管服务器处理应答表单数据;
表单配置流程包括以下步骤:
S21)网管服务器填写配置表单数据;
S22)网管服务器检查配置表单数据的长度,如果该长度大于约定最大值,将对表单数据执行压缩;
S23)网管服务器检查压缩后的表单数据长度,如果该长度仍大于约定最大值,将把压缩后的表单数据执行分包动作分成复数个表单子包;表单未压缩或未分包时,子包个数设置为1;
S24)网管服务器将表单子包个数绑定到表单分包数标量节点上,组装成各SNMP Set报文,用SNMP Set操作下发到光线路终端;
S25)光线路终端接收到SNMP Set报文中的表单分包数标量节点后,开辟内存空间,创建、并初始化表单净荷表节点实例,实例数等于表单子包个数;
S26)网管服务器将各表单子包绑定到表单净荷表节点的各个实例上,组装成各SNMP配置子报文,通过SNMP Set操作顺序下发到光线路终端;
S27)光线路终端获取SNMP配置报文中的表单净荷表节点的所有实例并验证实例个数;实例个数应该等于表单分包数标量节点的值,否则本次配置操作失败;
S28)光线路终端将获取的所有表单净荷表节点实例,根据SNMP配置子报文的报文头信息进行组装,得到完整的配置表单;
S29)如果配置表单是压缩表单,将执行解压缩动作,否则直接进入下一步;
S30)光线路终端将配置表单数据配置到到光线路终端硬件。
本发明相对于现有技术的优点:采用表单技术、表单压缩技术以及分包技术后,仅仅通过单个或少量几个SNMP报文,就能够传输大量信息。例如在1∶50的压缩比的情况下,单条SNMP报文就能传输50*1024字节的信息,而传统的单条SNMP报文,最多只能传输1472字节的信息。这样,对OLT这类需要和网管端进行大量数据传输的系统,采用本方法后,就能大大减少两者间SNMP报文交互次数,从而减少网络间通信量,减轻网管端cpu的通信负荷,提高网管界面的响应速度。
附图说明
图1是配置表单或查询结果表单示意图。
图2是查询条件表单示意图。
图3是对表单查询或配置操作的MIB树结构图。
图4是网管端表单set操作流程图。
图5是OLT端表单set操作流程图。
图4、5即为实施例配置流程的示意图。
图6是网管端表单get操作流程图。
图7是OLT端表单get操作流程图。
图6、7即为实施例查询流程的示意图。
图8是增加在表单头部的信息结构。
具体实施方式
本发明首先对OLT系统中需要管理的属性进行分类,按分类将属性组织成不同的表单;若表单长度超过约定最大值(例如1024字节),则对表单进行压缩处理;若压缩后表单长度仍超过约定最大值,则对压缩后的表单进行分片处理;然后将表单绑定到各自对应的OCTETSTRING格式的OID变量上,最后将OID变量组装到SNMP报文中。本发明能减少SNMP网管服务器端与OLT Agent端两者之间SNMP报文交互次数,减少网络间的通信量。
所述的方法,对于需要进行分包的表单,表单的根节点是对象标识节点(xxxObjects),根节点包含三个子节点,分别是表单查询节点(xxxFormInquire)、表单分包数节点(xxxFormSubPackageNum)以及表单净荷表节点(xxxFormPayloadTable)。表单净荷表节点的子节点为表单净荷入口节点(xxxFormPayloadEntry),表单净荷入口节点包括两个子节点,分别是表单净荷索引节点(xxxFormPayloadIndex)和表单净荷节点(xxxFormPayload)。
所述的方法,表单采用八进制字符串,并且每个表单内部还分成一个或复数个项目块,表单包含项目块分块数的信息。
所述的方法,通过zlib库函数对表单内容进行压缩。
所述的方法,SNMP报文最大净荷空间设定为1024字节。
所述的方法,每个表单头部包括分片后的子表单头部,增加如下表的头部信息:
序号 | 字段名称 | 数据长度(单位:字节) | 说明 |
1 | 报文净荷总长度 | 4 | |
2 | 压缩标志位 | 4 | 标示报文净荷是压缩净荷还是非压缩净荷 |
3 | 报文分包总个数 | 2 | |
4 | 本分包序号 | 2 | |
5 | 本分包净荷长度 | 4 | |
6 | 保留 | 8 |
所述的方法,网管服务器和光线路终端之间双向传输的过程包括查询流程和配置流程;
查询流程包括以下步骤:
S11)SNMP网管服务器端根据查询条件,组织查询条件表单,将表单绑定到表单查询MIB节点,用SNMP Set操作下发到OLT端;
S12)OLT端根据查询条件执行查询动作;
S13)OLT端将查询结果组织成应答表单,如果应答表单长度大于1024字节,将执行压缩动作,如果压缩后长度仍大于1024字节,将执行分包动作分成复数个子包;
S14)OLT端将子包个数绑定到表单分包数MIB节点上,将各子包数据绑定到表单净荷MIB节点的各个实例上;
S15)网管服务器先通过SNMP Get操作表单分包个数MIB节点,读取到本次应答报文的子包个数;
S16)网管服务器然后通过SNMP Get操作遍历表单净荷MIB节点的所有实例,并验证实例个数;实例个数应该等于S15步骤中获取的表单分包个数节点的值,否则本次查询操作失败;
S17)网管服务器将获取的表单净荷MIB节点的所有实例,根据子包报文头信息进行组装,得到完整的应答表单;如果应答表单是压缩表单,还执行解压缩动作;
S18)网管服务器处理解压缩后的应答表单数据;
配置流程包括以下步骤:
S21)SNMP网管服务器端填写配置表单数据;
S22)网管服务器检查配置表单数据的长度,如果该长度大于1024字节,将对表单数据执行压缩;
S23)网管服务器检查压缩后的表单数据长度,如果该长度仍大于1024字节,将把压缩后的表单数据执行分包动作分成复数个子包;表单未压缩或未分包时,子包个数设置为1;
S24)网管服务器将子包个数绑定到表单分包数MIB节点上,用SNMP Set操作下发到OLT端;
S25)OLT端接收到表单分包数MIB节点的SNMP Set报文后,开辟内存空间,创建、并初始化表单净荷节点实例,实例数等于子包个数;
S26)网管服务器将各子包绑定到表单净荷节点的各个实例上,通过SNMP Set操作,顺序下发到OLT端;
S27)OLT端获取表单净荷节点的所有实例并验证实例个数;实例个数应该等于表单分包数节点的值,否则本次配置操作失败;
S28)OLT端将获取的所有表单净荷节点实例,根据子包报文头信息进行组装,得到完整的配置表单;
S29)如果配置表单是压缩表单,将执行解压缩动作;
S30)OLT端将配置表单数据配置到到OLT端硬件。
所述的方法,步骤S17和S28在组装时还进行分包序号的校验,在组装结束后还进行报文净荷总长度的校验。
下面以具体实施例来进一步详述本发明。
本发明提出一种改造现有SNMP协议传输的方法,改造方向是减少SNMP网管端与OLTAgent端两者之间的报文交互次数,减少网络间的通信量。本发明的具体措施有:
1.单个SNMP报文净荷空间尽可能全部利用满;
2.单个SNMP变量携带更多信息,减少变量OID字段占用的空间;
3.SNMP变量的值采用压缩方式;
4.当SNMP变量的值压缩后占用的长度,超过SNMP报文净荷空间长度时,采用分包传输;
本发明通过如下改造实现了上述措施:
1.MIB(管理信息库)节点(OID Variable,即OID变量)的值(value)采用OCTET STRING(八进制字符串)的格式,对应一张记录有多个属性的表单;
2.上述表单,采用OCTET STRING的格式,经过压缩之后绑定到MIB变量上,填充到SNMP报文中;
3.上述表单,经过压缩之后,如果长度大于SNMP报文净荷空间长度,将会被分包,采用多个SNMP报文传输;
采用上述技术,能够实现在EPON系统SNMP网管端与OLT Agent端之间通过SNMP协议,高效率地传输大量数据。
下面采用具体实施方式进一步详述本发明,但不限定本发明。
1.表单OCTET STRING变量技术,本发明中称呼为“表单DMA技术”:
标准的SNMP OCTET STRING变量,通常一个变量仅表示一个型号、或一个名称、或一个序列号,例如设备型号,设备序列号,设备生产商名称等。
本发明中,SNMP变量采用OCTET STRING格式,一个变量对应一张表单,在一个表单中,可以设计记录众多的属性。
图1是一张记录以太网端口属性的表单,在该表单中记录了UNI端口的6个属性,分别是端口使能状态、端口速率、端口多工、端口流控、端口自协商、端口隔离。
例如,该表单可以对应到一个OCTET STRING格式的变量xxxUniPortAttribute(OID序号1.3.6.1.4.1.6868.68.1.3.6.2.1.2)上。
采用上述技术后,一个OCTET STRING变量就能携带了大量信息,当绑定到SNMP报文中时仅且只需要一个OID字段,减少了OID字段占用SNMP报文净荷空间。
如果采用常规SNMP变量处理,一个变量表示一个属性,就需要多个OID字段,假设OID字段占用空间和该变量的值占用的空间相等(通常OID字段占用空间比值占用的空间还要大),采用上述技术后,对于单条SNMP报文,至少可以节约50%以上的净荷空间。
2.表单循环技术
表单中属性以项目块的形式组织,多个属性组织成一个项目块。项目块中成员的取值不同(属性的值不同),就构成了不同的项目块。在一个表单中,可以同时包含多个这样的项目块。表单中的第1个字段指示了表单中实际包含的项目块个数。
例如:在图1中,字段“项目块1”记录的是第1个项目块;字段“项目块2”记录的是第2个项目块,依次类推;字段“项目块个数”,记录的是表单中包含的项目块的总个数。
采用上述技术后,尽可能多地在一个表单OCTET STRING变量中记录更多的信息,直到将整个SNMP报文净荷空间占满。
3.表单压缩技术
当采用表单及表单循环技术后,一个表单OCTET STRING变量的值的长度就可能超过SNMP报文净荷空间的长度,本发明采用压缩技术,对长度超过1024字节的表单进行压缩。
采用压缩技术后,假设压缩比为1∶50,在SNMP净荷空间是1472字节的情况下,单个SNMP报文就可以携带50*1472字节长度的信息。对于标准SNMP协议,假设OID字段占用50%的空间,变量的值占用50%的空间,满载荷的SNMP报文单次只能携带1472/2=736字节的信息,传输50*1472字节的信息,至少需要发送100次满载荷的报文,并且对方还需要发送100次的应答报文。
4.表单分包技术
当表单OCTET STRING变量经过压缩后,如果长度大于一个SNMP报文净荷空间,本发明采用分包传输技术,用于传输尺寸更大的压缩表单。
本发明在实施过程中由下面5个环节组成:
(1)表单设计
(2)MIB设计
(3)压缩算法
(4)分包、组包方法
(5)查询、配置方法
下面分别详述各环节的实现方法。
一.表单设计:
1.属性配置表单设计:
首先汇总系统中需要查询的或配置的所有属性,然后将这些属性进行归纳、进行分类,再根据分类的类别将这些属性分别组织到不同的表单中。
图1列举的是一张以太网端口属性配置表单。
该表单用来配置指定UNI端口的使能(即端口状态,enable表示端口可以使用,disable表示不可用,下文类似)、速率、多工、流控、自协商、隔离等属性。其中,槽位号、PON端口号、ONU认证号、UNI端口号均采用位图的格式,因此同一个属性集(使能、速率、多工、流控、自协商、隔离)可以一次性配置到多个槽位下的、多个PON口下的、多个ONU下的多个UNI端口上。
表单以项目块的形式组织,字段“槽位号”、“PON端口号”、“ONU认证号”、“UNI端口号”、“端口状态”、“端口速率”、“端口多工”、“端口流控”、“端口自协商”、“端口隔离”组成一个项目块的成员。
项目块中成员的取值不同(属性的值不同),就构成了不同的项目块。在一个表单中,可以同时包含多个这样的项目块。在表单中的第1个字段“项目块个数”就指示了该表单中实际包含的项目块个数。
2.属性查询表单设计:
图2列举的是一张以太网端口属性条件查询表单。其中,槽位号、PON端口号、ONU认证号、UNI端口号均采用位图的格式,可以查询单个UNI端口的属性,也可以同时查询多个槽位下的、多个PON口下的、多个ONU下的多个UNI端口的属性。
二.MIB设计
图3是对表单进行查询或配置操作时对应的MIB树。
根据表单是否需要分割成多个子包进行传输,可以分类为单包表单和多包表单。
本发明中对于需要分割成多个子包进行传输的多包表单,对应MIB树上一个OBJECTIDENTIFIER(对象标识)节点。在图3中,表单对应的MIB节点是xxxObjects,其中包括两个Scalar(标量)节点,和一个Table(表)节点。
Scalar节点xxxFormInquire,OCTET STRING格式,查询条件单包表单。当需要查询表单中各属性时,将一张查询条件单包表单绑定到该节点,Set操作下发到OLT设备。
Scalar节点xxxFormSubPackageNum,Integer32(32位整型)格式。当需要配置表单中各属性时,将该表单压缩、分包,将分包个数绑定到该节点,Set操作下发到OLT设备。当网管端查询表单中各属性时,OLT端将查询结果的分包个数填写在该变量中。
Table节点xxxFormPayloadEntry由Columnar(柱形)节点xxxFormPayloadIndex和Columnar节点xxxFormPayload组成。OLT端返回的查询结果表单,或网管端下发的配置表单的各个分包,分别绑定到该Table的各实例上。
Columnar节点xxxFormPayloadIndex,Integer32格式,表示分包索引。索引的最大值等于分包个数或实例个数。
Columnar节点xxxFormPayload,OCTET STRING格式,表示分包Data(数据),一个实例就是一个分包Data。如果没有进行分包,就只有一个分包Data,即仅一个实例。
三.压缩算法
本发明实施例中采用zlib库函数(官方网址http://zlib.net/)对表单数据进行压缩及解压缩。但不仅限于该压缩算法。
四.分包及组包方法
在局域网环境下,以太网链路层标准MTU(最大传输单元)值为1500字节,UDP报文的净荷长度可控制在1472字节以内。在Internet网络环境下,标准MTU值为576字节,,UDP报文的净荷长度可控制在548字节以内。
本发明中网管端与OLT设备之间,基本在局域网环境中运行,因此把SNMP报文的最大净荷长度限定在1024字节。
当表单OCTET STRING变量经过压缩后,如果长度大于1024字节,本发明将自动采用如下分包传输技术:
1.分包报文头格式:
每个分包在头部增加图8所示报文头:
2.分包方法:
(1)切割净荷:
当表单OCTET STRING变量经过压缩后,如果长度仍大于1024字节,压缩后的表单将会被按照每段1024字节,切割分成多个分包。
(2)组装分包报文头:
填写报文头对应字段的内容,将报文头增加到对应分包的头部。
对于配置操作,网管端将分包的总个数保存在MIB节点xxxFormSubPackageNum中;对于查询操作,OLT端将分包的总个数保存在MIB节点xxxFormSubPackageNum中。分包数据(Data)就是MIB节点xxxFormPayload的实例,有多少个分包就有多少个实例。
3.组包的方法:
网管端或OLT端在完整地取得MIB节点xxxFormPayload的所有实例后,根据每个分包头部的报文头信息开始组装报文。
(1)报文分包的总个数
获取的节点xxxFormPayload的实例个数,应该等于“报文分包的总个数”,否则不能组装报文。
(2)分包序号
获取的节点xxxFormPayload的实例,“分包序号”应该连续、完整,否则不能组装报文。
(3)报文净荷总长度
报文组装成功后的总长度,应该等于“报文净荷总长度”,否则组装后的报文有差错。
报文组装完成后,如果是压缩报文,还需要进行解压缩。
五.查询、配置流程
1.查询流程:
图6是网管端执行的查询流程图,图7是OLT端执行的查询流程图。
SNMP协议包含Set(设置)操作和Get(获取)操作,相应的报文为SNMP Set报文和SNMPGet报文。
(1)网管端根据查询条件,组织查询条件表单(表单压缩后长度不超过1024字节),将表单绑定到MIB变量xxxFormInquire上,如果是无条件查询,直接将空字符串绑定到MIB变量xxxFormInquire上,用set(设置)操作下发到OLT设备端;
(2)OLT端根据查询条件(或无条件)执行查询动作;
(3)OLT端将查询结果组织成应答表单。如果应答表单长度大于1024字节,将执行压缩动作,如果压缩后长度仍大于1024字节,将执行分包动作;
(4)OLT端将分包后子包个数绑定到变量xxxFormSubPackageNum上,将各子包数据绑定到变量xxxFormPayload的各个实例上;
(5)网管端get(获取)操作变量xxxFormSubPackageNum,从OLT端获取子包个数;
(6)网管端get操作变量xxxFormPayload的所有实例;实例个数应该等于xxxFormSubPackageNum;
(7)网管端将获取的所有xxxFormPayload实例(即所有子包),根据子包报文头信息进行组装,得到完整的应答表单;如果应答表单是压缩表单,将执行解压缩动作;
(8)网管端处理解压缩后的应答表单数据。
2.配置流程:
图4是网管端执行的配置流程图,图5是OLT端执行的配置流程图。
(1)网管端填写配置表单数据;
(2)如果表单数据长度大于1024字节,将执行压缩动作;
(3)如果压缩后表单数据仍大于1024字节,将执行分包动作;
(4)网管端将子包个数绑定到变量xxxFormSubPackageNum上,用set操作下发到OLT设备端;
(5)OLT设备端接收到MIB变量xxxFormSubPackageNum的set报文后,开辟内存空间,创建并初始化变量xxxFormPayload的xxxFormSubPackageNum个实例;
(6)网管端将子包绑定到MIB节点xxxFormPayload的各个实例上,通过set操作,顺序下发到OLT设备端;
(7)OLT端获得变量xxxFormPayload的所有实例;实例个数应该等于xxxFormSubPackageNum;
(8)OLT端将获取的所有xxxFormPayload实例(即所有子包),根据子包报文头信息进行组装,得到完整的配置表单;如果配置表单是压缩表单,将执行解压缩动作;
(9)OLT端将解压缩后的配置表单数据配置到OLT硬件。
Claims (5)
1.基于SNMP协议的EPON网管系统数据传输方法,其特征在于包括:首先对光线路终端中需要管理的属性进行分类,按分类将属性组织成不同的表单;若表单的长度超过一个SNMP报文净荷空间约定最大值,则对表单进行压缩处理,若压缩后表单长度仍超过约定最大值,则对压缩后的表单进行分包处理,否则直接进入后续步骤;然后将表单绑定到各自对应的管理信息库变量上,若表单未分包,则直接将表单组装到SNMP报文中,若对表单进行过分包处理,则将分包后的每个子表单组装到单个SNMP报文中;最后在网管服务器和光线路终端的网管代理端之间双向传输组装后的SNMP报文;
将需要分包的表单对应于管理信息库树上节点,所述管理信息库树上节点包括表单查询标量节点、表单分包数标量节点以及表单净荷表节点;
每个表单头部包括分包后的子表单头部,还增加自定义报文头,其格式见下表:
网管服务器和光线路终端的网管代理端之间的动作包括表单查询流程和表单配置流程;
表单查询流程包括以下步骤:
S11)网管服务器端根据查询条件,组织查询条件表单,将该表单绑定到表单查询标量节点,组装成SNMP查询报文并用SNMP Set操作下发到光线路终端;
S12)光线路终端根据收到的查询表单的查询条件执行查询动作;
S13)光线路终端将查询结果组织成应答表单,如果应答表单长度大于约定最大值,将执行压缩动作,如果压缩后长度仍大于约定最大值,将执行分包动作分成复数个表单子包;表单未压缩或未分包时,将表单子包个数设定为1;
S14)光线路终端将表单子包个数绑定到表单分包数标量节点上,将各表单子包数据绑定到表单净荷表节点的各个实例上,组装成各SNMP报文发送到网管服务器;
S15)网管服务器先通过SNMP Get操作获取表单分包数标量节点,读取本次应答SNMP报文的子包个数;
S16)网管服务器然后通过SNMP Get操作遍历表单净荷表节点的所有实例,并验证实例个数;实例个数应该等于S15步骤中获取的表单分包数标量节点的值,否则本次查询操作失败;
S17)网管服务器将获取的表单净荷表节点的所有实例,根据SNMP报文子包的报文头信息进行组装,得到完整的应答表单;如果应答表单是压缩表单,还执行解压缩动作;
S18)网管服务器处理应答表单数据;
表单配置流程包括以下步骤:
S21)网管服务器填写配置表单数据;
S22)网管服务器检查配置表单数据的长度,如果该长度大于约定最大值,将对表单数据执行压缩;
S23)网管服务器检查压缩后的表单数据长度,如果该长度仍大于约定最大值,将把压缩后的表单数据执行分包动作分成复数个表单子包;表单未压缩或未分包时,子包个数设置为1;
S24)网管服务器将表单子包个数绑定到表单分包数标量节点上,组装成各SNMP Set报文,用SNMP Set操作下发到光线路终端;
S25)光线路终端接收到SNMP Set报文中的表单分包数标量节点后,开辟内存空间,创建、并初始化表单净荷表节点实例,实例数等于表单子包个数;
S26)网管服务器将各表单子包绑定到表单净荷表节点的各个实例上,组装成各SNMP配置子报文,通过SNMP Set操作顺序下发到光线路终端;
S27)光线路终端获取SNMP配置报文中的表单净荷表节点的所有实例并验证实例个数;实例个数应该等于表单分包数标量节点的值,否则本次配置操作失败;
S28)光线路终端将获取的所有表单净荷表节点实例,根据SNMP配置子报文的报文头信息进行组装,得到完整的配置表单;
S29)如果配置表单是压缩表单,将执行解压缩动作,否则直接进入下一步;
S30)光线路终端将配置表单数据配置到到光线路终端硬件。
2.根据权利要求1所述的方法,其特征在于:将被管理的属性组织成表单,将表单内部相关联的属性分成项目块,并在表单中顺次排列每个项目块。
3.根据权利要求1所述的方法,其特征在于:通过zlib库函数对表单进行压缩。
4.根据权利要求1所述的方法,其特征在于:所述每个表单各对应一个八进制字符串格式的管理信息库变量。
5.根据权利要求1所述的方法,其特征在于:SNMP报文中净荷空间约定最大长度1024字节。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110429075.8A CN102523119B (zh) | 2011-12-16 | 2011-12-16 | 基于snmp协议的epon网管系统数据传输方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110429075.8A CN102523119B (zh) | 2011-12-16 | 2011-12-16 | 基于snmp协议的epon网管系统数据传输方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102523119A CN102523119A (zh) | 2012-06-27 |
CN102523119B true CN102523119B (zh) | 2015-01-21 |
Family
ID=46293918
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110429075.8A Active CN102523119B (zh) | 2011-12-16 | 2011-12-16 | 基于snmp协议的epon网管系统数据传输方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102523119B (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103023702A (zh) * | 2012-12-14 | 2013-04-03 | 武汉烽火网络有限责任公司 | 批量mib的处理方法 |
CN103117872A (zh) * | 2012-12-31 | 2013-05-22 | 广东东研网络科技股份有限公司 | 一种提高snmp数据传输效率的方法 |
CN103618636B (zh) * | 2013-12-16 | 2018-06-19 | 陕西广电网络传媒(集团)股份有限公司 | 基于epon+eoc技术的综合网络管理的eoc设备自发现自配置方法 |
CN104052623A (zh) * | 2014-06-25 | 2014-09-17 | 成都广达电子股份有限公司 | 以太网无源光网络中的报文处理方法和报文处理系统 |
CN105049380B (zh) * | 2015-08-27 | 2018-11-23 | 广州市百果园网络科技有限公司 | 一种网络通信处理方法及通信服务设备 |
CN105337767B (zh) * | 2015-10-16 | 2018-10-12 | 上海斐讯数据通信技术有限公司 | SNMPv2协议下数据配置系统及方法 |
CN106572080B (zh) * | 2016-10-14 | 2020-01-17 | 重庆金美通信有限责任公司 | 一种基于lzw压缩算法对snmp报文进行压缩和加密的方法 |
CN111610970A (zh) * | 2019-02-22 | 2020-09-01 | 广东真才企链信息科技有限公司 | 一种大数据量表单封装异步提交的方法 |
CN111611511A (zh) * | 2019-02-22 | 2020-09-01 | 广东真才企链信息科技有限公司 | 一种大数据量表单封装同步提交的方法 |
CN111083161A (zh) * | 2019-12-27 | 2020-04-28 | 中消云(北京)物联网科技研究院有限公司 | 数据传输的处理方法及装置、物联网设备 |
CN111585963A (zh) * | 2020-04-08 | 2020-08-25 | 深圳震有科技股份有限公司 | 一种数据获取方法、系统及存储介质 |
CN111817886B (zh) * | 2020-06-29 | 2023-12-26 | 新华三信息安全技术有限公司 | 一种获取管理对象数据的方法及设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101383786A (zh) * | 2008-07-07 | 2009-03-11 | 深圳市共进电子有限公司 | 利用家庭网关实现光网终端与用户端数据交换的方法 |
CN102045772A (zh) * | 2009-10-21 | 2011-05-04 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN102143198A (zh) * | 2010-09-30 | 2011-08-03 | 华为技术有限公司 | 消息传送方法、装置和系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20060054662A (ko) * | 2004-11-15 | 2006-05-23 | 삼성전자주식회사 | 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법 |
-
2011
- 2011-12-16 CN CN201110429075.8A patent/CN102523119B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101383786A (zh) * | 2008-07-07 | 2009-03-11 | 深圳市共进电子有限公司 | 利用家庭网关实现光网终端与用户端数据交换的方法 |
CN102045772A (zh) * | 2009-10-21 | 2011-05-04 | 华为技术有限公司 | 一种数据传输方法及装置 |
CN102143198A (zh) * | 2010-09-30 | 2011-08-03 | 华为技术有限公司 | 消息传送方法、装置和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN102523119A (zh) | 2012-06-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102523119B (zh) | 基于snmp协议的epon网管系统数据传输方法 | |
CN102082727B (zh) | 一种ptn网络业务流量管理的方法 | |
US20130268640A1 (en) | Method, Proxy Device, and System for Managing Terminal Device | |
CN109302372A (zh) | 一种通信方法、设备及存储介质 | |
CN101986648A (zh) | 一种tcp选项的协商方法、装置及网络设备 | |
CN105262740B (zh) | 一种大数据传输方法和系统 | |
CN100366000C (zh) | 一种基于SNMP的IPv6传感器网络节点管理方法 | |
CN107483279A (zh) | 一种基于以太网侦的本地批量操作网络设备的方法 | |
CN107276840A (zh) | 一种监控数据传输的方法及相关设备 | |
CN103023702A (zh) | 批量mib的处理方法 | |
EP2854350B1 (en) | System and method for cross-network data storage | |
CN100417088C (zh) | 一种前后台告警同步的方法 | |
CN105868364A (zh) | 一种基于字节流的结构化数据表示方法 | |
CN102055767A (zh) | 一种用于通信设备管理系统的多属性传输协议 | |
CN108023895B (zh) | 海量数据定向分类传输方法及系统 | |
CN109861898A (zh) | 一种基于fpga实现数据隔离的方法及其设备 | |
WO2017157023A1 (zh) | 一种soap报文传输方法及系统 | |
CN110167193A (zh) | WiFi自动配网方法和WiFi设备 | |
CN101355501B (zh) | 一种以太网堆叠系统中管理报文的方法及交换机装置 | |
CN1842996B (zh) | 用于数据分离和分段的无线通信设备和方法 | |
CN106982165A (zh) | 数据压缩方法及其系统 | |
CN101909043A (zh) | 一种基于简单网络管理协议的数据传输的方法及系统 | |
JP5839705B2 (ja) | 遠隔制御システム、遠隔制御装置、遠隔制御方法、および遠隔制御プログラム | |
EP3002910A1 (en) | Connecting computer management systems via cellular digital telecommunication networks | |
CN104506461A (zh) | 一种工业通信网络关口设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C53 | Correction of patent for invention or patent application | ||
CB02 | Change of applicant information |
Address after: 515000 Shantou science and technology zone, high tech Zone, Guangdong, No. 6 venture building, floor twelve Applicant after: Guangdong Donyan Network Technologies Co., Ltd. Address before: 515000 Shantou science and technology zone, high tech Zone, Guangdong, No. 6 venture building, floor twelve Applicant before: Guangdong Dongyan Network Technologies Co., Ltd. |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |