专利名称：利用周期重复序列压缩通过udp传输snmp消息的方法和装置的制作方法
技术领域：
本发明涉及使用UDP(用户数据报协议的简称)传输消息的方法，例如传输SNMP(简单网络管理协议)消息。
这些消息是在数据通信网络，例如互联网中产生并传输地。互联网协议的结构基于四个逻辑层，即应用层、传输层、网络层和连接层。
SNMP消息在网络管理系统(NMS)和被管理的节点之间执行一种简单的通信机制。这使得分别位于称作“网络管理器”的NMS上的以及位于称作“代理”的节点上的特定应用成为可能。因此SNMP消息能在UDP级上发生，并为该目的使用UDP来传输。
背景技术：
对SNMP消息具有独立的网络管理器的称作“代理”的应用(以下均为代理)和当前称作“管理信息库”或简称为MIB的数据库相结合。在这个数据库中，根据相应节点或网络单元的管理和监控，进行相应的信息收集。这种信息特别包括下列部分
—MIB变量，可由网络管理器读取，并获得关于网络单元的信息；
—可由网络管理器写入的MIB变量，能引起网络单元上的动作；以及
—同一代理根据特定的情况对网络管理器(管理器)引起的事件(陷阱)。
因此SNMP级上的通信主要包括
—请求读/写上述变量的消息(GetRequest，GetNextRequest，SetRequest，GetBulk)，由网络管理器发送出去，以及
—响应消息(GetResponse)和陷阱消息，由代理发送。
一个代理管理的所有变量/陷阱的集合与网络单元有关，并明确地表示了相应的MIB，即它们能向网络管理器展示网络单元的操作模式和固有特性。
每个变量或陷阱分别由ASN.1表示法(第一抽象语法表示法)中的一个字符串进行标识，称作对象标识符或OID。
该字符串的框架结构表明ASN.1表示法根据等级树结构允许对对象进行描述，例如“1.3.6.1.2.1.4.21”类型。
MIB的一部分定义为一个标准，支持任何代理，但是其他变量和一些陷阱对每个制造商都是特定的，在一些情况下还成为特定装置类型的独有特征。
1988年诞生的SNMP协议这些年来经过了几次发展。特别是定义了代理必须能够理解的新的消息类型。每个代理必须支持的MIB标准也被扩充了。在本发明的申请日，使用的版本是第一版和第二版，而第三版标准正在进行中。
MIB的大小根据装置类型而不同，对于相应的几百个OID，甚至可达到几百K字节大小。
附图的图1中的示意图显示了一个SNMP消息的典型组成部分。每个组成部分的内容是用ASCII字符写成，且它的最大允许尺寸和UDP消息的最大尺寸是相等的，数据体传送消息的组成部分，等于65,507字节或八位位组(需传送的信息被设计为大约64K字节)。
在图1中的同一个示意图中，特别要注意到存在一个消息头和一个PDU(协议数据单元)部分，其中数字1表示的部分收集如GetRequest，GetNextRequest，SetRequest以及GetResponse等消息，数字2表示的部分收集GetBulk消息，而数字3表示的部分一般涉及到陷阱类型消息。
更特别的是，在SNMP消息头中有下列信息
—版本号用于消息合成的SNMP版本号(V1，V2，V3，...)以及
—共用名称一种密码，能允许对MIB模块中包含的对象通过读和写进行访问。
下列信息是PDU内可用的
—PDU类型消息类型，在版本1中包括的指令例如为GetRequest，GetNextRequest，SetRequest以及Request，而在版本2还可包含的指令例如为GetBulkRequest和InformRequest；
—请求标识符管理器分配的消息的个人标识符，并在应答时被代理使用，目的在于管理器能够把请求的响应和适当的参考基准结合起来；
—错误状态除了响应消息之外所有的消息类型都设成0，其中如果设成1，意味着存在错误；
—错误索引它能够指示出被请求的变量(OID)中发生错误的变量，以及
—变量结这些变量结是OID/数值对；在请求的情况下数值为“空”，在消息响应的情况下进行编译。
图1中左边部分特别显示了收集上述变量结部分的典型结构。
本发明中以及一些附图的标题中，对于需考虑的不同元件，可根据英语中提及的相应的首字母缩写/名称/首字母来进行选择。
这样做的目的是为了得到清晰和直观的描述。上述首字母缩写词、名称和首字母现在被本领域技术人员在国际间运用，因为这些年来没有开发翻译成不同国家的语言。
通过UDP可能实现的SNMP消息的传送，允许在连接到网络上的两台计算机之间进行数据包的交换。UDP消息格式即包含了一个消息头，它的主要数据是发送消息的计算机的IP地址、目标计算机的IP地址以及被传送的PDU的大小。接下来，PDU格式由一个头部分和一个数据部分构成，现在称为“有效载荷”或“八位数据”。因此消息头包含下列数据源端口、目标端口、传送单元的大小、数据单元的完整性检验(CHECKSUM)。
现在通过UDP(从管理器至代理，以及相反路径)传送SNMP消息采用的方法实质上是基于整个SNMP消息是使用BER(基本编码规则)方法进行编码的事实。这种操作方法能够把构成SNMP消息的字节转换成UDP消息的有效载荷适用的十六进制结构。
这样获得的数据UDP传送服务基本上设想为
—在发送阶段为了通过UDP发送消息，先读取SNMP消息，随后对该消息进行十六进制编码(BER编码)，以及
—在接收阶段通过UDP接收消息之后，对PDU进行十六进制解码(BER解码)，随后对消息进行重建。
目前的应用实践证明了在数据通信网络如互联网中产生了这样的需求即要以SNMP消息的格式传送大量的请求/响应信息。
由于信息的总体大小决定了相应的传输和网络业务量所需的时间，以标准格式传输SNMP消息的常规解决方案一般效率相当低。
因为这个原因已经提出了三个IEFT标准(处在草案阶段)来解决该难点。
第一个建议(称为SNMP对象标识符压缩，2001年4月修订版，draft-ietf-eos-oidcompression-00.txt)基于的概念是MIB中包含的大部分信息通过OID来索引，相当大部分是常数格式，而很小部分是变量格式。根据这个原则出发，该建议的目标是根据一种算法通过一个较短的编号方式对OID的常数部分进行编码。这种方案只能部分地优化需传送的信息量，而没有大量减少信息的大小。
第二个建议(称为“大量SNMP数据的有效传输，2001年4月修订版，draft-ietf-eos-snmpbulk-00.txt”)面对的问题是GetBulk指令管理可允许对给定信息集的同步收集。SNMP版本2中引入的指令不能优化信息收集，因为管理器必须声明所需收集的单元数量，而不知道被请求的信息集由多少单元构成。UDP协议的修正曾建议改进消息的编码算法(从BER改为PER，它支持分组编码规则)或采取FTP(文件传输协议的首字母缩写)类型的传送模式。上面引用的文件中描述的方案在代理端引入了新的指令，叫做GetColsRequest，还在管理器端引入了相关消息，能够识别需传送的单元的数量，能识别出被请求的信息集的结束，从而优化了请求和网络业务量。但是，这个方案也不能优化对需发送的消息的大小和数量的管理。
第三个考虑的方案(称为“SNMP有效荷载压缩，2001年4月修订版，draft-irtf-nmrg-snmp-compression-01.txt”)在原理上和第一个建议相似，因为它提出了一种差分编码算法，叫做“OID DeltaCompression”或简称为ODC。这种方案从一个OID根出发，设想能够存储随后的OID，并把和OID根相关的代码分配给该OID，随后是OID的变化的部分。实质上，这些变化以与根单元相比较的差分增量形式被存储起来。该方案的缺点是和以前的协议版本不兼容。另外，它特别对求递归OID值(即数据阵列)时估计能够节省30％，而它在递归项数目很少的情况下效率是很低的。
发明内容
本发明的目的是提供一种和以前实行的解决方案相比的另一种可选择的替代方案，且能够通过UDP对如SNMP的消息进行优化传输，而不会影响协议以及代理端和管理器端的执行性能。
根据本发明，实现这个目的的方法具有权利要求中特定的技术特征。本发明还以独立的方式，涉及到相关系统和数据处理产品，当上述数据处理产品在计算机上运行时，能够直接载入到计算机的内部存储器中，并包括执行本发明所述方法的软件代码部分。
本质上，本发明的方案是基于整个消息(消息头和PDU)的压缩。
特别能够预见两种不同的传送模式。第一个模式把SNMP消息封装成一种新的特有类型的SNMP消息，并使用UDP以一种标准模式发送该消息。
第二个模式直接通过驱动器来驱动UDP，得到的结果是把SNMP消息压缩为八位数据。
所述压缩技术实质上基于对消息中周期性出现的序列进行识别。
特别地，在本发明的优选实施例中，使用的压缩技术是已知的LZ77技术的变形(见Ziv.J.，Lempel A.的著作“A Universal Algorithm forSequential Data Compression”，IEEE Transactions on InformationTheory，Vol.23，No.3，PP.337-343)，在UNIX环境中是很有名的，叫做gzip(gzip格式—RFC 1952)，也被更流行的PKZIP所使用。这种技术规范是众所周知的，同时还可使用源库，用于不同的开发环境和操作系统来执行和使用这个方案，如HP-UX，Digital，Beos，Linux，OS/2，Java，Win32，WinCE。
特别在win32上可通过使用“zLib”库来使用该算法的接口。作为参考，可以参见站点http//www.info-zip.org/pub/infozip/zlib/。这个库的主要特征是可以对二进制数据结构和字符串进行实时和联机存储器压缩，这成为和系统性能相关的一个重要因素。
现在通过一个不受限的实例，参照附图对本发明进行描述，其中
—图1和背景技术有关，前面已作了描述；
—图2是根据本发明的方案的一个典型应用结构的一般结构框图的形式；
—图3至图5，每个图再分成两部分，分别是发送(a部分)和接收(b部分)，以流程图的形式阐释了本发明的方案的不同类型的实施例；
—图6是一个补充的流程图，阐释了本发明的方案的一般特性；以及
—图7和图8根据基本上类似于图1中采用的特征，通过两种可行的变型，描述了本发明的方案的实施例标准。
具体实施例方式
图2的一般框图中，符号N表示了根据本发明的方案的一个规定了典型应用环境的数据通信网络(可以考虑互联网作为一个直接的例子)。
符号A表示了现在称作“代理”的模块，它实现的功能是对网络N的相应单元进行控制和监视，并与相应的管理器M以一种双向对话模式进行操作。
后者和一个更高等级水平上的附加代理A’一起确定了一个端口或网关G，它随即和另一个更高等级水平上的附加管理器M’相对接。
后者和一个相应应用一起确定了一个观测模块或观测器O。
符号C1和C2表示两个双向通信信道，一个信道在代理A和网关G之间在较低等级水平上执行通信，另一个信道在网关G和观测器O之间在较高等级水平上执行通信。
在上面提到的信道C1、C2上进行SNMP消息传输。
图3中的流程图描述了SNMP消息压缩(图3a)和解压缩(图3b)的特征。
图4中的流程图(仍然参照图4a中的发送和图4b中的接收)阐释了第一个方案，其中设想通过对SNMP进行封装，然后发送压缩后的SNMP消息。
图5中的流程图是另一种通过UDP封装的传输方案。这个图仍然参照发传(图5a)和接收(图5b)。
图7和图8中的结构图描述了和图1中相同格式的OID表示形式，并且参照压缩和传输操作集，分别举例说明图3和4(图7)中的a)部分以及图3和5(图8)中的a)部分。
首先来看图3中的流程图，在符号100表示的步骤中，整个SNMP消息(消息头+PDU)被读出，用于在随后由102表示的步骤中转换或编码成十六进制格式。这是采用一种BER编码类型的代码来实现的。
这样编码后的消息再通过一种基于对递归序列进行识别的压缩技术进行压缩，例如前面已经提及的zLib库中提到的技术。
这是在104表示的步骤中发生的，目的是在106表示的步骤中获得准备用于发送的压缩后的数据单元。
以一种完全对称的方式，图3的b部分的流程图也包括四个步骤，即206，204，202和200(根据示出的顺序来执行)，其中接收到的压缩数据单元(步骤206)被解压缩(步骤204)，随后进行十六进制解码(步骤202)，其后对整个SNMP消息进行重建(步骤200)。
图3中b部分的流程图的数字符号顺序和它们的执行顺序是相反的，这样做的唯一目的是强调这个过程和步骤100到106的压缩过程的对称性。图4和图5的流程图中也选择了同样的方式。
如图所示，图4和图7涉及到一种发送方案，设想将压缩后的数据单元封装成一个标准SNMP消息，其特征在于专有的或特殊的“变量结”，以及通过UDP的标准发送性质。
压缩数据单元的封装形式在步骤106处获得，还包括一个用108表示的初始化步骤，在该步骤中压缩后的数据单元按字节读出，然后再随后用110表示的编码步骤中转换成相应的ASCII字符集。
在下面一个步骤112中(可能在此之前加上辅助功能，例如ACKTAB+NULL-见图7中模块110a)，第一个OID和专有的或特殊的编号方式(例如1.3.6.1.4.666.1)构成的消息生成了“变量结”，其包含的数值是字符串_zip_xxxx，其中xxxx表示原文件的大小。上面引用的例子中，特定代码666.1表示此时还没有在IANA(Internet AssignedNumbers Authority)注册，但其他任何没有注册过的代码都可以使用。
其后适时地转换成ASCII字符的包含有压缩数据单元的变量结单元由OID/数值对构成。其数值包括压缩数据单元转换成ASCII字符的部分，最大为255个字符。
然后SNMP消息的消息头进行重建。这都发生在步骤112中，其后是步骤114，执行一个根据BER方法的额外的编码，用于生成数据发送(步骤116)中所需的UDP消息的PDU载荷(PDU-UDP的有效载荷)。
还是在这种情况下，图4的b)部分中重复出现的步骤216，214，212，210和208被设计为根据前面所引用的顺序来执行，这些步骤表示出接收端实现的涉及到发送操作的步骤108到116的双重功能。
采用图4和图7中提及的方案，压缩后的SNMP消息具有一个标准的逻辑SNMP格式，但是内容是专有的或特殊的。因此，它需要代理管理器的功能扩充，尽管很小，从而能够进识别和编码/解码。
申请人进行的实验证明这种方案是完全可行的，不会影响网络结构。
图5和图8提到的另一种方案，设想根据图3所示的性质，准备来自SNMP消息的压缩数据单元，然后把上述数据单元直接封装入PDU-UDP的有效载荷中。
很明显对于正确的操作，这个方案需要使用专用的发送器和接收器，例如前提条件是要确保UDP端口的可用性和标准端口不同。因此发送器必须能识别接收器使用的UDP端口，反过来也是一样。使用的端口信息可根据下文中将要详细解释的标准，通过一种标准SNMP格式的同步消息在更高层上进行交换。
采用图5和图8中描述的另一个替代方案时，在步骤108处得到的用于替代消息的BER的压缩数据单元成为PDU-UDP消息的有效载荷。
图5和图8中相关的操作用标号为118、120的步骤表示，上述步骤在发送步骤122之前，用于接收器的各个专用端口(一般称作端口x)。
还是在这种情况下，其余操作包括三个步骤，分别是222(该时刻用作接收器的模块的端口Y的接收)、220(PDU-UDP有效载荷的提取)、218(接收到压缩数据单元，用于传送至图3中b)部分流程图的步骤206处)。
同样在这种情况下，步骤222、220、218按照上面已经提及的顺序来执行。
前面提到的同步消息由管理器按照“应用到应用”的基本原则发至SNMP代理，使用了含有专用或特殊的“变量结”的标准SNMP格式。
被传送的信息可能的类型为
OID 数值
管理器向SNMP管理器发送一个专用消息，把用于UDP传输的端口号(例如1024)编译成<UDP_TX_PORT>值，并且把用于UDP接收的端口号(例如1224)编译成<UDP_RX_PORT>值。
代理向管理器答复一个类似的包含自身信息的消息。这种方法增加了技术方案的效率，从而减少了处理时间。
图6中的框图还显示了对上面描述的方案的推广，以适用于任何使用UDP作为传输端口的消息类型(例如SNMP、PING等等)。这种推广使得能够实现一种取代目前正在使用的UDP驱动器。
这种方案能够估计要传送的有效载荷的大小，并使用此处提到的方法进一步处理(假定大小是足够大的(例如大于20字节))。为了表明发送至接收端的UDP消息的简洁性，例如一或多个比特时，可以把UDP消息头中(目前这些比特没有使用，缺省设置为0)第62个比特到第69个比特之间的8个比特置为1。
特别是图6的框图中，符号300表示出现发送能够通过UDP传输的消息的需求的任何步骤，随后是对有效载荷进行压缩的步骤302，根据图3中描述的特性来实现。
接下来的步骤304中设想了根据上面提到的原则生成UDP消息头，同时下面的步骤306对应了整个UDP消息的创建，考虑了IP传输，在步骤308中实现。
提及的方法能够实现一种一般用途的解决方案，能够支持任何一种使用UDP-IP协议栈的应用类型。
上述方案特别适用于硬件实现或“on-chip”方案。
上述方案的一个功能性延伸能够独立于用于数据传输的方法来实现，以及消息的编码或等效的BER或八位数据UDP。对此考虑采用了一种安全有效的方法，现在称为“block cipher Rijndael”，也叫做“AES”。
这里描述的方案的优点在于允许对SNMP消息进行压缩，以一种组合的方式，既参考了一种灵活的压缩技术，又参考了其他压缩技术(如MPEG)克服了说明书中提到的缺点。这种技术及其算法可在多个操作系统下使用，使该方案成为一个可以再次使用和重复实现的方案。另外，上述方案对管理器和代理端的影响都是最小的，因为它需要建立消息压缩和解压缩的一个简单的上层结构。
该方案证明是高效率的，因为它能够对网络业务量进行优化，时间间隔相等时，能够通过较小的消息数量来传送相同数量或更大量的信息。它也是个安全的解决方案，因为信息被压缩和编码之后，在网络中以明文进行传输。
显然，在本发明的原理不改变的情况下，考虑到此处描述和阐释的方面，具体实施方式
以及实施例可能会不同，这并没有偏离权利要求所限定的本发明的主旨和范围。
权利要求
1.通过UDP(用户数据报协议)传输包含有效载荷(OID)的消息的方法，其特征在于该方法包括基于对消息中周期性出现的序列进行识别，至少将所述有效载荷提交给压缩步骤(302，104，204)的步骤。
2.如权利要求1中所述的方法，其特征在于所述压缩步骤是根据gzip类型的技术来实现的，如zLib技术。
3.如权利要求1或2中所述的方法，其特征在于该方法包括在通过UDP传输的消息中表示出已执行的压缩步骤的步骤。
4.如权利要求3中所述的方法，其特征在于该方法使用了UDP消息头的一个比特字段来表示已执行的压缩步骤(302)。
5.如权利要求4中所述的方法，其特征在于UDP消息头的第62个比特到第69个比特被用来表示已执行的压缩步骤(302)。
6.如权利要求5中所述的方法，其特征在于该方法包括把UDP消息头的第62个比特到第69个比特中的至少一个比特设置成1的步骤。
7.如权利要求1至6中任一项所述的方法，用于传输SNMP消息，其特征在于压缩步骤包括以下操作
—读取(100)整个SNMP消息，
—用十六进制的格式对读取的消息进行编码(102)，以及
—把用十六进制格式编码的消息提交给压缩步骤(104)。
8.如权利要求1至7中任一项所述的方法，用于传输SNMP消息，其特征在于接收步骤包括以下操作
—把接收到的消息提交给一个和上述压缩步骤相反的解压缩步骤(204)，使得提交给解压缩步骤的消息能得到十六进制的格式，
—对提交给解压缩步骤(204)的消息从十六进制的格式开始进行解码(202)，以及
—从解码后的消息开始重建(20)整个SNMP消息。
9.如权利要求7或8中所述的方法，其特征在于该方法包括把提交给所述压缩步骤(104)的消息封装成标准SNMP消息的步骤。
10.如权利要求9中所述的方法，其特征在于该方法包括以下操作
—把提交给所述压缩步骤(104)的消息按字节读取(108)，并转换(110)成相应的ASCII字符的消息，
—生成(112)了变量结的集合，包括表示原文件大小的第一OID，以及提交给所述压缩步骤(104)的所述消息的后续OID/数值对的承载部分，转换成ASCII字符，
—重建SNMP消息的头信息，
—将由此获得的SNMP消息编码(114)为十六进制的格式，以生成UDP有效载荷，以及
—通过UDP传输由此生成的有效载荷。
11.如权利要求8、9或10中所述的方法，其特征在于接收步骤包括以下操作
—接收提交给所述压缩步骤的消息作为UDP有效载荷(216)，
—把由此接收到的有效载荷提交给十六进制解码操作(214)，
—对提交给十六进制解码的消息的变量结进行识别和组合(212)，以及
—把识别和组合操作(212)中识别和组合之后的消息提交给一个从ASCII到二进制的解码操作(210)，
—把解码为二进制格式的消息提交给所述解压缩步骤(204)。
12.如权利要求7或8中所述的方法，其特征在于该方法包括对提交给所述压缩步骤(104)的消息通过UDP封装进行集成的步骤。
13.如权利要求12中所述的方法，其特征在于该方法包括以下步骤
—将提交给所述压缩步骤(104)的所述消息配置为UDP消息的PDU有效载荷(PDU-UDP有效载荷)，以及
—以这种方式创建的PDU-UDP有效载荷从发送器的给定发送端口传送到接收器的给定接收端口。
14.如权利要求13中所述的方法，其特征在于该方法包括以下步骤
—在接收端口处接收作为PDU-UDP有效载荷接收的消息，以及
—从所述UDP消息中提取出所述有效载荷。
15.如权利要求13或14中所述的方法，其特征在于该方法包括在发送终端(M，M’；A，A’)和接收终端(A，A’；M，M’)之间传送一个SNMP类型的同步消息的步骤，以识别所述发送端口及/或所述接收端口。
16.用于管理数据通信网络的系统，包括至少一个管理器单元(M，M’)以及至少一个代理单元(A，A’)，通过传送消息在至少一条信道(C1，C2)上相互通信，其特征在于所述消息是按照基于权利要求1至15中任一项的方法通过UDP传输的。
17.一种数据处理产品，当所述数据处理产品在数字处理器上运行时，所述数据处理产品能够直接载入到数字处理器的内部存储器中，并包括执行根据权利要求1至15中任一项的方法的软件代码部分。
全文摘要
本发明涉及使用UDP传输来传送信息。一个典型的例子是SNMP消息，用于在管理数据通信网络，如互联网的系统内的管理器单元(M，M’)和代理单元(A，A’)之间进行通信(C1，C2)。消息的有效荷载，最好是作为一个整体的消息，基于在消息中周期性出现的序列的识别，进行压缩操作。
文档编号H04L29/06GK1541475SQ0281588
公开日2004年10月27日 申请日期2002年8月9日 优先权日2001年8月13日
发明者毛利兹奥·齐拉迪, 毛利兹奥 齐拉迪 申请人:意大利电信股份公司