网络管理技术范例6篇

网络管理技术

网络管理技术范文1

CORBA网络管理技术是随着网络技术的发展应运而生的。这种管理技术可以对分布对象进行交叉管理,提升网络管理的效率。其最显著的特征就是可以屏蔽操作系统、编程语言及网络协议的不同,借助多透明性对网络系统进行全方位管理。虽说这种网络管理技术很受欢迎,但还是不能完全替代SNMP技术跟CMIT技术。此种技术网络协议的发展过程很长久,还要花费很多的人力、物力和财力。

2网络技术的发展问题及分析

2.1 网络管理趋向于综合化从网络整体运作性能的高低可以看出网络管理技术的好坏。网络管理系统跟网络协议的发展都不断完善和综合,网络管理技术的发展也应该更加简便和综合。在处理信息方面,可以进行统一的操作及管理,达到信息传递跟处理的全面化和综合化目的。综合化发展可以说是网络管理技术发展的最明显特征。2.2 网络管理趋向于智能化通常而言,网络管理就是要处理一些较为复杂的信息,在管理跟维护方面的工作量都很大。要提升网络管理的效率,其发展就必然会走向智能化管理。借助各种网络管理用具跟网络管理方式,不断创新网络管理技术,促进网络管理的智能化发展。2.3 网络管理技术问题分析当前,网络管理技术的发展已经比较稳定和成熟,但在实际管理工作中还是存在各种各样的问题。一是构建网络平台问题。要有统一的网络平台对信息进行处理,但其构建还有一定的难度。二是协调管理问题。各个管理人员之间缺乏有效的沟通交流,导致协调管理受到阻碍。

3网络管理技术的发展趋势

最早的网络管理体系中,基本上都是单一主机的Manager—Agent模型,如HP公司的Open—View,3COM的Transcend系列,SUN公司的Sun—NetManage,D—Link公司的D—view等。随着网络技术的不断发展(规模不断拓展、业务不断增加),必然会出现网管主机超负荷运作的情况,这对网络管理系统的运作有很大影响。而且,集中式管理模式的逐渐渗透也给管理工作提出了挑战。就整体层面来说,最新的综合网络管理软件必须要有开放系统的功能,也就是必须具备兼容性、可互相操作性、可移植性、可伸缩性等特点,这是网络管理技术的发展趋势。而且,网络管理技术发展的核心促进力量就是分布式技术,这一点也应该重视。除此之外,还有B/S结构也将逐渐发展成为主导力量,这种结构对远程管理而言是很有用的。要满足不同规模网络管理的需要,网络管理软件的发展结构也会多种多样,如分布式结构、集中式结构、集中分布式结构等。各种人工智能技术(如智能模拟、自动诊断故障等)也将会被广泛应用到网络管理软件中。总之,网络管理技术的发展将会越来越丰富,会逐渐倾向于网络业务、系统的应用管理。网络管理软件在网络规划中占据的地位也会越来越重要,逐渐成为网络安全管理和故障管理之外的最重要的管理功能。

4结语

网络管理技术范文2

关键词:网络环境;信息技术;高校图书馆

电子计算机与现代通讯技术相结合,为人类创造了全新的信息技术——网络信息技术。它是电子计算机和现代通讯技术相互结合基础上构建起来的宽带、高速、综合、广域型数字式电信网络,这种网络通过网中设网、网际互联可以覆盖一国、数国乃至全球。网络技术的形成和迅猛发展,信息机构以网络为传输手段,以数字化的信息资源为基础,为用户提供准确、及时、个性化和全程式的信息服务创造了条件和提供了可能。图书馆的传统服务方式受到前所未有的极大冲击和挑战。

高校图书馆不但是学校文献信息中心,也是为教学和科研服务的教育学术性机构,现代信息技术是影响图书馆发展最深刻的环境因素。高密度的信息储存技术,在变革了人们生产、收集、组织、传递和使用知识信息的方式的同时,也使信息服务的机制、结构与服务手段发生了巨大的变化。如何将一些先进的信息技术结合运用到图书馆的管理和服务中,用这些技术来促进日常工作,改变限于向读者提供馆藏文献,还提供所有网络上的可利用的文献,协助教学和科研是目前我们高校图书馆的工作重点。网络技术将带来信息的聚集、包装、检索、传播、复制、再生产的变化。如何在网络信息技术环境下发挥高校图书馆的最佳效益,网络环境下高校图书馆工作受到了哪些影响,是人们十分关注的问题。

一、网络信息技术对图书管理工作的影响

进入21世纪,数字化、网络化的信息革命从根本上推动了图书馆的发展进程,计算机日益成为图书馆的主要设备,图书馆采用了各种自动化集成系统建立自己的内部网络环境,呈现出网络化、信息化、智能化和社会化的特征。图书馆自动化管理一方面由于开展网上预约、催还书、推荐新书等业务,解决紧俏文献的供需矛盾和逾期罚款的问题,使流通工作更具人性化。另一方面建立起图书馆工作的信息网络,可以合理配置文献资源网上协作采访,集中编目以及馆际互借,管理所需的工作统计也变得非常方便快捷。与传统的手工操作相比,信息技术的使用完善了图书馆的管理工作。例如,在网络环境下,我们开通了网上预约图书,预约书到馆后的管理很重要,这也从另一方面反映了图书馆管理状况。必须按照到馆时间专架存放,便于预约者快捷取书借阅。若是同其它的还书一样入库,则不方便其他读者借书,而且容易引发借阅争端。

二、网络信息技术对图书馆服务工作的影响

长期以来在思维定势支配下,国内图书馆在网络信息服务实践中,对用户服务工作并未充分重视,在理论上表现为大学图书馆未能站在读者角度,制定适当的信息资源和信息服务发展政策,往往还是站在自己的立场上进行馆藏和网络信息资源的搜集和提供,常常缺乏对本校专业和用户对象的针对,从而造成网络信息服务提供与信息用户需求脱节。

高校图书馆的用户大多是学生,他们在利用图书馆的过程中难免会遇到各疑难问题,帮助他们解决问题的渠道是否畅通,问题能否得到及时的解决,在很大程度上制约着他们利用图书馆的效率。在网络环境下,图书馆可以将常见问题以FAQ的形式张贴在图书馆的主页上,供学生查阅;同时可以通过电子邮箱和实时问答等形式及时解决学生的疑难问题,另外,图书馆应设置咨询台,随时随地为用户提供优良的服务。尤其是学生在做毕业论文,需要查找专业的书籍和资料时,图书馆的工作人员能为他们提供专业的服务,指导他们充分利用馆藏和网络资源,在有限的时间内尽有可能多的找到有用的资料。高校图书馆除了具备完善的图书馆和信息服务法规、政策外,其网络信息服务还随着图书联盟和数字图书馆发展而发展。因此图书馆必须提高服务质量,服务质量是图书馆工作的生命线。

三、网络信息技术对图书馆时间的影响

时间管理是实现图书馆全面管理的必须条件。在网络环境下,电子文献、数字文献的大量出现,海量信息蜂拥而至,增大了用户检索和利用的难度,那么,为读者过滤垃圾信息,让他们汲取信息精华,让他们查全查准自己所需的信息,高校图书馆的工作人员责无旁贷。因而,高校图书馆必须加强时间管理,避免浪费读者富贵的时间。

高校图书馆保证足够的开馆时间,才不至于让用户吃闭门羹;科研人员在查新、科研立项、研究中期、结题等阶段,他们特别希望在图书馆获取最新、最快的第一手资料,信息工作人员应该竭尽全力为他们做好文献保障工作,提供快捷的文献传递服务;教师在学期准备暑期用书,在开课前查找相关的资料时,都应该保证他们到馆时,图书馆能提供有力的文献资源支持,保证他们的文献查阅时间。如果开馆时间完全与学生上课时间重叠,用户的需求就无法得到满足,增加开馆时间,就可以有效地保证馆藏文献的充分利用,使有限的资源被重复利用,进而满足广大用户的需求。节省用户的时间就能创造价值,因此从高校图书馆的服务管理的角度上看,要千方百计地节省读者的时间以创造更多的社会价值,取得更好的社会效益。

四、网络信息技术对图书馆管理人员的影响

图书馆事业的不断发展,新技术、新方法的不断引进,图书馆专业工作者的知识内容需要不断更新,信息技术的发展将不可避免的对原有的图书馆服务思想和服务体系带来冲击,图书馆管理人员在信息技术日益发展的环境下,要明确图书馆的使命并没有改变,信息技术并非取代了图书馆管理人员,相反,图书馆管理人员作桥梁、导航作用将变得更为重要。信息技术使图书馆工作变得更加便利和高效,使资源共享更容易实现,只有传统的方式与现代的信息技术相结合,人和机器相协调才能为读者提供更加优质的服务,才能提高学校的科研和教学水平。因此在网络环境下,对图书馆工作人员的工作技能和工作效益提出了更高的要求:必须加强自身的业务学习,掌握必要的计算机及网络知识,提高自身的综合素质,才能为读者提供优质、高效的信息服务。

网络信息服务实际上汇集无数最新科技成果,并随技术发展而发展,国内大学图书馆目前在基础网络建设上与国外差距并不大,但在图书馆学、计算机科学、通讯科学和其它相关技术上仍需紧紧跟随国际最新进展,希望能够迎头赶上。

参考文献

[1]刘晨,美国高校图书馆网络信息服务的现状分析与启示[J]图书馆工作与研究,2005,(6)

[2]龙叶,宁凤英,网络环境下高校图书馆用户时间资源的开发与利用[J]图书馆工作与研究,2005,(6)

网络管理技术范文3

【关键词】网络管理;主动网络技术;优势

随着计算机技术的快速发展,网络规模越来越大,其结构也越来越复杂,提供的服务也越来越多,为此网络在人们的日常生活和工作中的地位越来越重要。如果计算机网络系统出现故障,哪怕是仅仅几分钟都会严重的影响人们的日常生活,特别是金融、电信、交通以及商业领域,所以必须加强对网络的管理。只有通过适当的网络管理,才能实现功能强大的网络的安全运行,因此网络管理性能的好坏是评价一个网络好坏的重要性指标。目前使用较广泛的是基于TCP/IP的网络管理协议,在工作过程中它是以轮询为基础,定期对计算机网络进行检查,观察其是否有异常现象。在对反馈数据的分析中只有一小部分的信息能够有效的反应异常状态,并且数据上传过程中会出现数据资料的发送拖延等,为此主动网络技术便应运而生。

1.传统的网络管理技术的缺陷

目前在计算上使用比较多的是ICP/IP协议,该协议遵循端到端的原则,在进行数据传输时其网络层提供不可靠的传输服务,其应用的可靠性和安全性由端系统来保证,大大简化了网络本身的复杂度。传统的网络管理系统主要包括网络管理工作站(NMS)、管理(Agent)、网络管理信息库(MIB)、网络节点设备和SNMP管理协议五部分,日常的应用实践证明了TCP/IP协议的可靠性,但是随着网络规模的不断扩大,该协议也暴露除了一些不足之处:

(1)随着设备使用数量的增加,NMS需要轮询的节点数量增加,容易造成通信瓶颈,大大降低网络信息传输的效率。

(2)网络上传输了大量的冗余数据,造成了宽带的浪费。

(3)管理Agent仅仅是NMS和MIB间的接口,它接收了NMS发出的请求报文后根据MIB中的信息返回其响应报文,它只能通过少量的Trap信息主动报告自己的状态,本身不具备主动计算和管理功能,也不能对异常事件进行处理。

(4)被管理节点间主动性较差,不具备相互间协作的功能,在大型网络中不能对其运行状态做出及时、准确的反应。

所以随着网络规模的不断扩大和网络信息的不断增加,传统的网络管理模式已经不能满足用户的需求,急需得到改善。

2.主动网络技术及其实例

主动网络是一种可计算的网络模型,它是针对传统网络的不足而提出的一种新的网络体系结构。其基本思想是:网络中传输的分组不仅能够携带用户数据,而且还能够携带用户定制的程序代码,使得分组在经过网络节点转发处理时不仅识别头部标识,还可以通过运行分组携带的代码,决定分组的转发行为,从而将传统网络中“存储-转发”的处理模式改变为“存储-计算-转发”的模式。在主动网络中我们将网络中携带的程序代码的报文称为主动报文或主动包,把执行主动包中携带程序的网络节点称为主动节点。跟传统的网络技术相比,主动网络技术具有以下几个优点:

(1)可编程性:可编程是主动网络的最大特色,其报文、服务等都可以通过语言进行描述,用户通过构件封装在主动包中的程序代码实现对网络的编程,其功能远远大于传统的存储-转发功能。

(2)可移动性:主动网络技术中能够实现对携带程序代码的主动包的传送,主动包能够在不同的平台上移动,流经的主动节点可以获取主动包中的代码并执行。

(3)可扩展性:主动网络具有较好的扩展性能,由于其节点的可编程性,用户可以将其服务代码注入到网络节点中,对其功能进行扩展。

图1 基于主动网络技术的网管模型

图1所示是一个采用主动网络技术的网管模型,跟传统网络管理的不同是它将实现管理功能的应用代码分发到有数据的网元上,采用一个弹器提供便携式操作系统的扩展来支持委托的运行,一个委托协议用来将委托动态分配到远端服务器上并控制它的执行。

3.利用主动网络技术实现网络管理的优势

网络技术的快速发展对网络服务的要求越来越多,网络应用也在不断进行更新,这就要求在现有网络中增加新的网络服务和协议,并且要求能够根据需要定制这些服务。现有网络管理系统不能真正实现对某种应用的可定制性,正是由于这种可定制性的缺乏和难于变化的特性推动了主动网络技术的研究和发展。利用主动网络技术来实现对复杂网络的管理,是一种智能化、标准化的网络管理模式的尝试,它具有以下几个方面的优势:

(1)占用的网络资源较少

在主动网络技术中其主动包在靠近被管设备的地点处运行,避免了管理者和间通信占用大部分的带宽。另外可以对其返回到网络管理中心的信息进行裁剪,减少了网络中信息的流量和处理时间。

(2)减轻了网络系统的负担

主动包具有一定的管理功能,能够实现对其能力范围内信息的管理,只将其无法处理的事件交由网络管理系统来完成,减轻了网络管理系统所要处理的信息量。

(3)动态配置

在主动网络技术中其管理系统能够根据实际需要,动态配置各种新的网络管理策略,具有较强的灵活性。

随着网络规模的不断扩大,主动网络技术在网络管理中的优势越来越明显,它充分利用了网络中的各个节点,降低了对系统内存以及CPU资源的占用,解决了大型网络传输中的通信瓶颈问题。另外在主动网络系统的管理过程中程序代码向数据移动,避免了大量未经处理的原始数据在网络中的传输,提高了系统的相应时间和性能。

4.结论

基于主动网络技术的网络管理是当今网络管理的必然发展趋势,解决了传统网络管理系统的不足,实现了网络管理的分布性、主动性和智能性。本文介绍了传统网络管理技术的不足之处,指出了随着网络规模的不断增大,其管理模式的缺陷逐渐暴露,为了弥补这种不足将主动网络技术应用到了网络管理中,利用其节点可编程性解决了传统网络中出现的问题,并且介绍了使用主动网络技术实现网络管理的优势。

参考文献

[1]任丰源,任勇,山秀明.主动网络的研究与进展[J].软件学报,2001,12(11):1614-1622.

[2]邹显春,张伟群.一种主动网络管理系统结构的分析与研究[J].计算机科学,2006,33(10):58-60.

网络管理技术范文4

一、网络管理技术概述

网络管理已经成为计算机网络和电信网研究中最重要的内容之一。网络中采用的先进技术越多,规模越大,网络的维护和管理工作也就越复杂。计算机网络和电信网的管理技术是分别形成的,但到后来渐趋同化,差不多具有相同的管理功能和管理原理,只是在网络管理上的具体对象上有些差异。

通常,一个网络由许多不同厂家的产品构成,要有效地管理这样一个网络系统,就要求各个网络产品提供统一的管理接口,即遵循标准的网络管理协议。这样,一个厂家的网络管理产品就能方便地管理其他厂家的产品,不同厂家的网络管理产品之间还能交换管理信息。

在简单网络管理协议SNMP(SimpleNetworkManagementProtocol)设计时,就定位在是一种易于实施的基本网络管理工具。在网管领域中,它扮演了先锋的角色,因OSI的CMIP发展缓慢同时在Internet的迅猛发展和多厂商环境下的网络管理解决方案的驱动下,而很快成为了事实上的标准。

SNMP的管理结构如图1所示。它的核心思想是在每个网络节点上存放一个管理信息库MIB(ManagementInformationBase),由节点上60(agent)负责维护,管理者通过应用层协议对这些进行轮询进而对管理信息库进行管理。SNMP最大的特点就是其简单性。它的设计原则是尽量减少网络管理所带来的对系统资源的需求,尽量减少agent的复杂性。它的整个管理策略和体系结构的设计都体现了这一原则。

SNMP的主要优点是:

·易于实施;

·成熟的标准;

·C/S模式对资源要求较低;

·广泛适用,代价低廉。

简单性是SNMP标准取得成功的主要原因。因为在大型的、多厂商产品构成的复杂网络中,管理协议的明晰是至关重要的;但同时这又是SNMP的缺陷所在——为了使协议简单易行,SNMP简化了不少功能,如:

·没有提供成批存取机制,对大块数据进行存取效率很低;

·没有提供足够的安全机制,安全性很差;

·只在TCP/IP协议上运行,不支持别的网络协议;

·没有提供管理者与管理者之间通信的机制,只适合集中式管理,而不利于进行分布式管理;

·只适于监测网络设备,不适于监测网络本身。

针对这些问题,对它的改进工作一直在进行。如1991年11月,推出了RMON(RernoteNetworkMonitor)MIB,加强SNMP对网络本身的管理能力。它使得SNMP不仅可管理网络设备,还能监测局域网和互联网上的数据流量等信息,1992年7月,针对SNMP缺乏安全性的弱点,又公布了S-SNMP(SecureSNMP)草案。到1993年初,又推出了SNMPVersion2即SNMPv2(推出了SNMPv2以后,SNMP就被称为SNMPv1)。SNM-Pv2包容了以前对SNMP的各项改进工作,并在保持了SNMP清晰性和易于实现的特点以外,吸取了CMIP的部分优点,功能更强,安全性更好,具体表现为:

·提供了验证机制,加密机制,时间同步机制等,安全性大大提高;

·提供了一次取回大量数据的能力,效率大大提高;

·增加了管理者和管理者之间的信息交换机制,从而支持分布式管理结构,由位于中间层次(intermediate)的管理者来分担主管理者的任务,增加了远地站点的局部自主性。

·可在多种网络协议上运行,如OSI、AppleTalk和IPX等,适用多协议网络环境(但它的缺省网络协议仍是UDP)。

·扩展了管理信息结构的很多方面。特别是对象类型的定义引入了几种新的类型。另外还规范了一种新的约定用来创建和删除管理表(managementtables)中的“行”(rows)。

·定义了两种新的协议数据单元PDU(ProtocolDataUnit)。Get-Bulk-Request协议数据单元允许检索大数据块(largedatablocks),不必象SNMP那样逐项(itembyitem)检索;Inform-Request协议数据单元允许在管理者之间交换陷阱(tran)信息。

CMIP协议是在OSI制订的网络管理框架中提出的网络管理协议。CMIP与SNMP一样,也是由管理者、、管理协议与管理信息库组成。

CMIP是基于面向对象的管理模型的。这个管理模型表示了封装的资源并标准化了它们所提供的接口。如图2所示了四个主要的元素:

·系统管理应用进程是在担负管理功能的设备(服务器或路由器等〕中运行的软件:

·管理信息库MIB是一组从各个接点收集来的与网络管理有关的数据;

·系统管理应用实体(systemmanagementapplicationentities)负责网络管理工作站间的管理信息的交换,以及与网络中其它接点之间的信息交换;

·层管理实体(layermanagemententities)表示在OSI体系结构设计中必要的逻辑。

CMIP模型也是基于C/S结构的。客户端是管理系统,也称管理者,发起操作并接收通知;服务器是被管系统,也称,接收管理指令,执行命令并上报事件通知。一个CMIP操作台(console)可以和一个设备建立一个会话,并用一个命令就可以下载许多不同的信息。例如,可以得到一个设备在一段特定时间内所有差错统计信息。

CMIP采用基于事件而不是基于轮询的方法来获得网络组件的相关数据。

CMIP已经得到主要厂商,包括IBM、HP及AT&T的支持。用户和厂商已经认识到CMIP在企业级网络管理领域是一个比较好的选择。它能够满足企业级网管对横跨多个管理域的对等相互作用(peertopeerinteractions)的要求。CMIP特别适合对要求提供集中式管理的树状系统,尤其是对电信网(telecommunicationsnetwork)的管理。这就是下面提到的电信管理网。

二、电信管理网TMN

电信管理网TMN是国际电联ITU-T借鉴0SI中有关系统管理的思想及技术,为管理电信业务而定义的结构化网络体系结构,TMN基于OSI系统管理(ITU-UX.700/ISO7498-4)的概念,并在电信领域的应用中有所发展.它使得网络管理系统与电信网在标准的体系结构下,按照标准的接口和标准的信息格式交换管理信息,从而实现网络管理功能。TMN的基本原理之一就是使管理功能与电信功能分离。网络管理者可以从有限的几个管理节点管理电信网络中分布的电信设备。

国际电信联盟(ITU)在M.3010建议中指出,电信管理网的基本概念是提供一个有组织的网络结构,以取得各种类型的操作系统(OSs)之间、操作系统与电信设备之间的互连。它采用商定的具有标准协议和信息的接口进行管理信息交换的体系结构。提出TMN体系结构的目的是支撑电信网和电信业务的规划、配置、安装、操作及组织。

电信管理网TMN的目的是提供一组标准接口,使得对网络的操作、管理和维护及对网络单元的管理变得容易实现,所以,TMN的提出很大程度上是为了满足网管各部分之间的互连性的要求。集中式的管理和分布式的处理是TMN的突出特点。

ITU-T从三个方面定义了TMN的体系结构(Architecture),即功能体系结构(FunctionalArchitecture),信息体系结构(InformationArchitecture)和物理体系结构(PhysicalArchitecture)。它们分别体现在管理功能块的划分、信息交互的方式和网管的物理实现。我们按TMN的标准从这三个方面出发,对TMN系统的结构进行设计。

功能体系结构是从逻辑上描述TMN内部的功能分布。引入了一组标准的功能块(Functionalblock)和可能发生信息交换的参考点(referencepoints)。整个TMN系统即是各种功能块的组合。

信息体系结构包括两个方面:管理信息模型和管理信息交换。管理信息模型是对网络资源及其所支持的管理活动的抽象表示,网络管理功能即是在信息模型的基础上实现的。管理信息交换主要涉及到TMN的数据通信功能和消息传递功能,即各物理实体和功能实体之间的通信。

物理体系结构是为实现TMN的功能所需的各种物理实体的组织结构。TMN功能的实现依赖于具体的物理体系结构,从功能体系结构到物理体系结构存在着映射关系。物理体系结构随具体情况的不同而千差万别。在物理体系结构和功能体系结构之间有一定的映射关系。物理体系结构中的一个物理块实现了功能体系结构中的一个或多个功能块,一个接口实现了功能体系结构中的一组参考点。

仿照OSI网络分层模型,ITU-T进一步在TMN中引入了逻辑分层。如图3所示:

TMN的逻辑分层是将管理功能针对不同的管理对象映射到事务管理层BML(BusinessManagementLayer),业务管理层SML(ServiceManagementLayer),网络管理层NML(NetworkManagementLayer)和网元管理层EML(ElementManagementLayer)。再加上物理存在的网元层NEL(NetworkElementLayer),就构成了TMN的逻辑分层体系结构。从图2-6可以看到,TMN定义的五大管理功能在每一层上都存在,但各层的侧重点不同。这与各层定义的管理范围和对象有关。

三、TMN开发平台和开发工具

1.利用TMN的开发工具开发TMN的必要性

TMN的信息体系结构应用OSI系统管理的原则,引入了管理者和的概念,强调在面向事物处理的信息交换中采用面向对象的技术。如前所述,TMN是高度强调标准化的网络,故基于TMN标准的产品开发,其标准规范要求严格复杂,使得TMN的实施成为一项具有难度和挑战性的工作;再加上OSI系统管理专业人员的相对缺乏,因此,工具的引入有助于简化TMN的开发,提高开发效率。目前比较流行的基于TMN标准的开发平台有HPOVDM、SUNSEM、IBMTMN平台和DSET的DSG及其系列工具。这些平台可以用于开发全方位的TMN管理者和应用,大大降低TMN/Q3应用系统的编程复杂性,并且使之符合开放系统互连(OSI)网络管理标准,这些标准包括高级信息模型定义语言GDM0,OSI标准信息传输协议CMIP,以及抽象数据类型定义语言ASN.1。其中DSET的DSG及工具系列除了具备以上功能外,还具有独立于硬件平台的优点。下面将比较详细论述DSET的TMN开发工具及其在TMN开发中的作用。

2.DSET的TMN开发工具的基本组成

DSET的TMN开发工具从功能上来讲可以构成一个平台和两大工具箱。一个平台:分布式系统生成器DSG(DistributedSystemGenerator);两个工具箱:管理者工具箱和工具箱。

分布式系统生成器DSG

DSG是用于顶层TCP/IP、OSI和其它协议上构筑分布式并发系统的高级对象请求0RB。DSG将复杂的通信基础设施和面向对象技术相结合,提供构筑分布式计算的软件平台。通信基础设施支持分布式计算中通信域的通信要求。如图4所示,它提供了四种主要的服务:透明远程操作、远程过程调用和消息传递、抽象数据服务及命名服务。借助于并发的面向对象框架,一个复杂的应用可以分解成一组相互通信的并发对象worker,除了支持例如类和多重继承等重要的传统面向对象特征外,为了构筑新的worker类,DSG也支持分布式对象。在一个开放系统中,一个worker可以和其它worker进行通信,而不必去关心它们所处的物理位置。

DSG提供给用户用以开发应用的构造块(buildingblock)称为worker。一个worker可以有自己的控制线程,也可以和别的线程共享一个控制线程,每个Worker都有自己的服务访问点SAP(ServiceAccessPoint),通过SAP与其它worker通信。Worker是事件驱动的。在Worker内部,由有限状态机FSM(FiniteStateMachine〕定义各种动作及处理例程,DSG接受外部事件并分发到相应的动作处理例程进行处理。如图5所示,独占线程的此worker有三个状态,两个SAPs,并且每个SAP的消息队列中都有两个事件。DSG环境通过将这些事件送到相应的事件处理程序中来驱动worker的有限状态机。

Worker是分布式的并发对象,DSG用它来支持面向对象的特点,如:类,继承等等。Worker由workerclass定义。Worker可以根据需要由应用程序动态创建。在一个UNIX进程中可以创建的Worker个数仅受内存的限制。

管理者工具箱由ASN.C/C++编译器、CMIP/ROSE协议和管理者代码生成器MCG构成,如图6所示。

其中的CMIP/ROSE协议提供全套符合Q3接口选用的OSI七层协议栈实施。由于TMN在典型的电信环境中以面向对象的信息模型控制和管理物理资源,所有被管理的资源均被抽象为被管对象(M0),被管理系统中的帮助管理者通过MO访问被管理资源,又根据ITU-TM.3010建议:管理者与之间通过Q3接口通信。为此管理者必须产生与通信的CMIP请求。管理者代码生成器读取信息模型(GDMO文件和ASN.1文件),创立代码模板来为每个被定义的MO类产生CMIP请求和CMIP响应。由于所有CMIP数据均由ASN.1符号定义,而上层管理应用可能采用C/C++,故管理者应用需要包含ASN.1数据处理代码,管理者工具箱中的ASNC/C++编译器提供ASN.1数据到C/C++语言的映射,并采用“预处理技术“生成ASN.1数据的低级代码,可见利用DSET工具用户只需编写网管系统的信息模型和相关的抽象数据类型定义文件,然后利用DSET的ASNC/C++编译器,管理者代码生成器即可生成管理者部分代码框架。

工具箱包括可砚化生成器VAB、CMIP翻译器、ASN.C/C++Toolkit,其结构见图7。用来开发符合管理目标定义指南GDMO和通用管理信息协议CMIP规定的应用.使用DSET独具特色的工具箱的最大的好处就是更快、更容易地进行应用的开发。DSET在应用的开发上为用户做了大量的工作。

一个典型的GDMO/CM1P应用包括三个代码模块:

·、MIT、MIB的实施

·被管理资源的接口代码

·后端被管理资源代码

第一个模块用于处理与MO实施。工具箱通过对过滤、特性处理、MO实例的通用支持,自动构作这一个模块。DSET的这一部分做得相当完善,用户只需作少量工作即可完成本模块的创建。对于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed这些CMIP请求,第一个模块中包含有缺省的处理代码框架。这些缺省代码都假定管理者的CMIP请求只与MO打交道。为了适应不同用户的需求,DSET工具箱又提供在缺省处理前后调用用户程序的接入点(称为Userhooks)。当某CMIP请求需与实际被管资源或数据库打交道时,用户可在相应的PRE-或POST-函数中加入自己的处理代码。例如,当你需要在二层管理应用中发CMIP请求,需望获取实际被管资源的某属性,而该属性又不在相应MO中时你只需在GDMO预定义模板中为此属性定义一PRE-GET函数,并在你自己的定制文件中为此函数编写从实际被管设备取到该属性值的代码即可。DSET的Agent代码在执行每个CMIP请求前都要先检查用户是否在GDMO预定义文件中为此清求定义了PRE-函数,若是,则光执行PRE-函数,并根据返回值决定是否执行缺省处理(PRE-函数返回D-OK则需执行缺省处理,否则Agent向管理者返回正确或错误响应)。同样当Agent执行完缺省处理函数时,也会检查用户是否为该请求定义了POST-函数,若是则继续执行POST-函数。至于Agent与MO之间具体是如何实现通信的,用户不必关心,因为DSET已为我们实现了。用户只需关心需要与设备交互的那一部分CMIP请求,为其定制PRE-/POST函数即可。

第二个模块实现MO与实际被管资源的通信。它的实现依赖于分布式系统生成器DSG所提供“网关处理单元”(gateway)、远程过程调用(RPC)与消息传递机制及MSL语言编译器。通信双方的接口定义由用户在简化的ROSE应用中定义,在DSG中也叫环境,该环境定义了双方的所有操作和相关参数。DSG的CTX编译器编译CTX格式的接口定义并生成接口表。DSG的MSL语言编译器用以编译分布式对象类的定义并生成事件调度表。采用DSG的网关作为MO与实际被管资源间的通信桥梁,网关与MO之间通过定义接口定义文件及各自的MSL文件即可实现通信,网关与被管设备之间采用设备所支持的通信协议来进行通信,例如采用TCP/IP协议及Socket机制实现通信。

第三个模块对被管理资源进行实际处理。这一模块根据第二个模块中定义的网关与被管设备间的通信机制来实现,与工具没有多大联系。

四、TMN开发的关键技术

电信管理网技术蕴含了当今电信、计算机、网络通信和软件开发的最新技术,如OSI开放系统互连技术、OSI系统管理技术、计算机网络技术及分布式处理、面向对象的软件工程方法以及高速数据通信技术等。电信管理网应用系统的开发具有巨大的挑战性。

工具的引入很大程度上减轻了TMN的开发难度。留给开发人员的最艰巨工作就是接口(interface)的信息建模。尤其是Q3接日的信息建模问题。

Q3接口是TMN接口的“旗舰”,Q3接口包括通信模型和信息模型两个部分,通信模型(0SI系统管理)的规范制定的十分完善,并且工具在这方面所作的工作较多,因此,当我们设计和开发各种不同管理业务的TMN系统时,主要是采用一定的方法学,遵循一定的指导原则,针对不同电信领域的信息建模问题。

为什么说建模是TMN开发中的关键技术呢?从管理的角度而言,在那些先有国际标准(或事实上的标准),后有设备的情况下,是有可能存在一致性的信息模型的,例如目前SDH和七号信令网的TMN系统存在这样的信息模型标准。但即使这样,在这些TMN系统的实施过程,有可能由于管理需求的不同而对这些模型进行进一步的细化。在那些先有设备而后才有国际标准(或事实上的标准)的设备,而且有的电信设备就无标准而言,由于不同厂家的设备千差万别,这种一致性的信息模型的制定是非常困难的。

例如,近年来标准化组织国际电信联盟(ITU-T)、欧洲电信标准组织(ETSI)、网络管理论坛(NMF)和ATM论坛等相继颁布了一些Q3信息模型。但至今没有一个完整的稳定的交换机网元层的Q3信息模型。交换机的Q3信息模型提供了交换机网元的一个抽象的、一般的视图,它应当包含交换机的管理的各个方面。但这是不可能的。因为随着电信技术的不断发展,交换机技术也在不断的发展,交换机的类型不断增加,电信业务不断的引入。我们很难设计一个能够兼容未来交换机的信息模型。如今的交换机已不再是仅仅提供电话的窄带业务,而且也提供象ISDN这样的宽带业务。交换机趋向宽带窄带一体化发展,因此交换机的Q3信息模型是很复杂的,交换机Q3信息建模任务是很艰巨的。

五、TMN管理者和的开发

下面结合我们的开发工作,探讨一下TMN管理者和的开发。

1.管理者的开发

基于OSI管理框架的管理者的实施通常被认为是很困难的事,通常,管理者可以划分为三个部分。第一部分是位于人机之间的图形用户接口GUI(GraphicalUserInterfaces),接收操作人员的命令和输入并按照一种统一的格式传送到第二部分——管理功能。管理功能提供管理功能服务,例如故障管理,性能管理、配置管理、记费管理,安全管理及其它特定的管理功能。接收到来GUI的操作命令,管理功能必须调用第三部分——CMSIAPI来发送CMIP请求到。CMISAPI为管理者提供公共管理信息服务支持。

大多数的网管应用是基于UNIX平台的,如Solaris,AIXandHP-UX。若GUI是用X-Window来开发的,那么GUI和管理功能之间的接口就不存在了,从实际编程的的角度看,GUI和管理功能都在同一个进程中。

上面的管理者实施方案尽管有许多优点,但也存在着不足。首先是费用昂贵。所有的管理工作站都必须是X终端,服务器必须是小型机或大型机。这种方案比采用PC机作客户端加上UNIX服务器的方案要昂贵得多。其次,扩展性不是很好,不同的管理系统的范围是不同的,用户的要求也是不一样的,不是所有的用户都希望在X终端上来行使管理职责。因此,PC机和调终端都应该向用户提供。最后由于X-Window的开发工具比在PC机上的开发工具要少得多。因此最终在我们的开发中,选择了PC机作为管理工作站,SUNUltral作为服务器。

在实际工作中我们将管理者划分为两个部分——管理应用(managementapplication)和管理者网关(managergateway)。如图8所示。

管理应用向用户提供图形用户接口GUI并接受用户的命令和输入,按照定义好的消息格式送往管理者网关,由其封装成CMIP请求,调用CMISAPI发往。同时,管理者网关还要接收来自的响应消息和事件报告并按照一定的消息格式送往管理应用模块。

但是这种方案也有缺点。由于管理应用和管理者网关的分离,前者位于PC机上,后者位于Ultral工作站上。它们之间的相互作用须通过网络通信来完成。它们之间的接口不再是一个参考点(ReferencePoint),而是一个物理上的接口,在电信管理网TMN中称为F接口。迄今为止ITU-T一直没能制定出有关F接口的标准,这一部分工作留给了TMN的开发者。鉴于此,我们制定了管理应用和管理者网关之间通信的协议。

在开发中,我们选择了PC机作为管理工作站,SUNUltral作为我们的管理者网关。所有的管理应用都在PC机上。开发人员可以根据各自的喜好来选择不同开发工具,如Java,VC++,VB,PB等。管理者网关执行部分的管理功能并调用CMISAPI来发送CMIP请求,接收来自的响应消息和事件报告并送往相应的管理应用。

管理者网关的数据结构是通过编译信息模型(GDMO文件和ASN.1文件)获得的。它基于DSG环境的。管理者网关必须完成下列转换:

数据类型转换:GUI中的数据类型与ASN.1描述的数据类型之间的相互转换;

消息格式转换:GUI和管理者网关之间的消息格式与CMIP格式之间的相互转换;

协议转换:TCP/IP协议与OSI协议之间的相互转换。

这意味着管理者网关接收来自管理应用的消息。将其转换为ASN.1的数据格式,并构造出CMIS的参数,调用CMISAPI发送CMIP请求。反过来,管理者收到来自的消息,解读CMIS参数,构造消息格式,然后送往GUI。GUI和管理者网关之间的消息格式是由我们自己定义的。由于管理应用的复杂性,消息格式的制定参考了CMIS的参数定义和ASN.1的数据类型。

管理者网关是采用多线程(multi-thread)编程来实现的。

2.的开发

的结构如图9所示。

为了使部分的设计和实现模块化、系统化和简单化,将agent分成两大模块——通用模块和MO模块——进行设计和实现。如图所示,通用agent向下只与MO部分直接通信,而不能与被管资源MR直接进行通信及操作,即通用agent将manager发来的CMIP请求解析后投递给相应的M0,并从MO接收相应的应答信息及其它的事件报告消息。

的作用是代表管理者管理MO。利用工具的支持,采用面向对象的技术,分为八个步骤进行agent的设计和实现,这八个步骤是:

第一步:对信息模型既GDMO文件和ASN.1文件的理解,信息模型是TMN系统开发的基础和关键。特别是对信息模型中对象类和其中各种属性清晰的认识和理解,对于实际的TMN系统来说,其信息模型可能很复杂,其中对象类在数量上可能很多。也就是说,在设计和实现agent之前,必须作到对MO心中有数。

第二步:被管对象MO的定制。这一部分是agent设计和实现中的关键部分,工具对这方面的支持也不是很多,特别是涉及到MO与MR之间的通信,更为复杂,故将MO专门作为一个模块进行设计和实现MO和MR之间的通信以及数据和消息格式的转换问题,利用网关原理设计一个网关来解决。

第三步:创建内置的M0。所谓内置MO就是指在系统运行时,已经存在的物理实体的抽象。为了保证能对这些物理实体进行管理,必须将这些被管对象的各种固有的属性值和操作预先加以定义。

第四步:创建外部服务访问点SAP。如前所述,TMN系统中各个基于分布式处理的worker之间通过SAP进行通信,所以要为agent与管理者manager之间、agent与网关之间创建SAP。

第五步:SAP同内置MO的捆绑注册。由于在TMN系统中,agent的所有操作是针对MO的,即所有的CMIP请求经解析后必须送到相应的M0,而基于DSG平台的worker之间的通信是通过SAP来实现的。因而,在系统处理过程中,当进行信息的传输时,必须知道相应MO的SAP,所以,在agent的设计过程中,必须为内置MO注册某一个SAP。

第六步:agent配置。对agent中有些参数必须加以配置和说明。如队列长度、流量控制门限值、agent处理单元组中worker的最大/最小数目。报告的处理方式、同步通信方式中超时门限等。

第七步:agent用户函数的编写,如agentworker初始化函数、子函数等的编写。

第八步:将所有函数编译,连接生成可运行的agent。

MO模块是agent设计中的一个重要而又复杂的部分。这是由于,一方面工具对该部分的支持不是很多:另一方面,用户的大部分处理函数位于这一部分;最主要的还在于它与被管资源要跨平台,在不同的环境下进行通信。MO模块的设计思想是在MO和MR之间设计一个网关(gateway),来实现两者之间的消息、数据、协议等转换。

MO部分的主要功能是解析,执行来自管理者的CMIP请求,维持各MO的属性值同被管资源的一致性,生成CMIP请求结果,并上报通用agent模块,同时与MR通信,接收和处理来自MR的事件报告信息,并转发给通用agent。

MO部分有大量的用户定制工作。工具只能完成其中一半的工作,而另一半工作都需要用户自己去定制。用户定制分为两大类;

第一类是PRE-/POST-函数。PRE-/POST-函数的主要功能是在agent正式处理CMIP请求之前/之后与被管资源打交道,传送数据到MR或从MR获取数据并做一些简单的处理。通过对这些PRE-/POST-函数的执行,可以确保能够真实地反映出被管资源的运行状态。PRE-/POST-函数分为两个层次:MO级别和属性级别。MO级别层次较高,所有对该对象类的CMIP操作都会调用MO级别的PRE-/POST-函数。属性级别层次低,只有对该属性的CMIP操作才会调用这些函数。DSET工具只提供了PRE-/POST-函数的人口参数和返回值,具体的代码需要完全由用户自己编写。由于agent与被管资源有两种不同的通信方式,不同的方式会导致不同的编程结构和运行效率,如果是同步方式,编程较为简单,但会阻塞被管资源,适合于由大量数据返回的情况。异步方式不会阻塞被管资源,但编程需要作特殊处理,根据不同的返回值做不同的处理,适合于数据不多的情况,在选择通信方式时还要根据MO的实现方式来确定。比如,MO若采用Doer来实现,则只能用同步方式。

第二类是动作、事件报告和通知的处理,动作的处理相对比较容易,只需考虑其通信方式采用同步还是异步方式。对事件报告和通知的处理比较复杂。首先,需要对事件进行分类,对不同类别的事件采用不同的处理方法,由哪一个事件前向鉴别器EFD(EventForwardingDiscriminator)来处理等等。比如,告警事件的处理就可以单独成为一类。其次,对每一类事件需要确定相应的EFD的条件是什么,哪些需要上报管理应用,哪些不需要。是否需要记入日志,这些日志记录的维护策略等等。

除了这两类定制外,MO也存在着优化问题。比如MO用worker还是Doer来实现,通信方式采用同步还是异步,面向连接还是无连接等等,都会影响整个的性能。

如果MO要永久存储,我们采用文件方式。因为目前DSET的工具只支持Versant、ODI这两种面向对象数据库管理系统OODBMS,对于0racle,Sybase等数据库的接口还需要用户自己实现。MO定制的工作量完全由信息模型的规模和复杂程度决定,一个信息模型的对象类越多,对象之间的关系越复杂(比如一个对象类中的属性改变会影响别的类),会导致定制工作的工作量和复杂程度大大增加。

者agent在执行管理者发来的CMIP请求时必须保持与被管资源MR进行通信,将manager传送来的消息和数据转发给MR,并要从MR获取必要的数据来完成其操作,同时,它还要接收来自MR的事件报告,并将这些事件上报给manager。

由上述可知,与被管资源MR之间的通信接口实际上是指MO与MR之间的通信接口。大部分MO是对实际被管资源的模拟,这些MO要与被管资源通信。若让这些MO直接与被管资源通信,则存在以下几个方面的弊端:

·由于MO模块本身不具备错误信息检测功能(当然也可在此设计该项功能,但增加了MO模块的复杂性),如果将上向发来的所有信息(包括某些不恰当的信息)全部转发给MR,不仅无此必要,而且增加了数据通信量;同理MR上发的信息也无必要全部发送给MO。

·当被管资源向MO发消息时,由于MIT对于被管资源来说是不可知的,被管资源不能确定其相应MO在MIT中所处的具置,从而也就无法将其信息直接送到相应的MO,因而只能采用广播方式发送信息。这样一来,每当有消息进入MO模块时,每个MO都要先接收它,然后对此消息加以判断,看是否是发给自己的。这样一方面使编程复杂化,使软件系统繁杂化,不易控制,调试困难;另一方面也使通信开销增大。

·MO直接与被管资源通信,使得系统在安全性方面得不到保障,在性能方面也有所下降,为此,采用计算机网络中中网关(gateway)的思想,在MO与被管资源建立一个网关,即用一个gatewayworker作为MO与被管资源通信的媒介。网关在的进程处理中起到联系被管资源与MO之间的“桥梁”作用。

六、总结与展望

Q3接口信息建模是TMN开发中的关键技术。目前,各标准化组织针对不同的管理业务制定和了许多信息模型。这些模型大部分是针对网元层和网络层,业务层和事务层的模型几乎没有,还有相当的标准化工作正在继续研究。业务层和事务层的模型是将来研究的重点。

网络管理技术范文5

网络管理已经成为计算机网络和电信网研究中最重要的内容之一。网络中采用的先进技术越多,规模越大,网络的维护和管理工作也就越复杂。计算机网络和电信网的管理技术是分别形成的,但到后来渐趋同化,差不多具有相同的管理功能和管理原理,只是在网络管理上的具体对象上有些差异。

通常,一个网络由许多不同厂家的产品构成,要有效地管理这样一个网络系统,就要求各个网络产品提供统一的管理接口,即遵循标准的网络管理协议。这样,一个厂家的网络管理产品就能方便地管理其他厂家的产品,不同厂家的网络管理产品之间还能交换管理信息。

在简单网络管理协议SNMP(SimpleNetworkManagementProtocol)设计时,就定位在是一种易于实施的基本网络管理工具。在网管领域中,它扮演了先锋的角色,因OSI的CMIP发展缓慢同时在Internet的迅猛发展和多厂商环境下的网络管理解决方案的驱动下,而很快成为了事实上的标准。

SNMP的管理结构如图1所示。它的核心思想是在每个网络节点上存放一个管理信息库MIB(ManagementInformationBase),由节点上60(agent)负责维护,管理者通过应用层协议对这些进行轮询进而对管理信息库进行管理。SNMP最大的特点就是其简单性。它的设计原则是尽量减少网络管理所带来的对系统资源的需求,尽量减少agent的复杂性。它的整个管理策略和体系结构的设计都体现了这一原则。

SNMP的主要优点是:

·易于实施;

·成熟的标准;

·C/S模式对资源要求较低;

·广泛适用,代价低廉。

简单性是SNMP标准取得成功的主要原因。因为在大型的、多厂商产品构成的复杂网络中,管理协议的明晰是至关重要的;但同时这又是SNMP的缺陷所在——为了使协议简单易行,SNMP简化了不少功能,如:

·没有提供成批存取机制,对大块数据进行存取效率很低;

·没有提供足够的安全机制,安全性很差;

·只在TCP/IP协议上运行,不支持别的网络协议;

·没有提供管理者与管理者之间通信的机制,只适合集中式管理,而不利于进行分布式管理;

·只适于监测网络设备,不适于监测网络本身。

针对这些问题,对它的改进工作一直在进行。如1991年11月,推出了RMON(RernoteNetworkMonitor)MIB,加强SNMP对网络本身的管理能力。它使得SNMP不仅可管理网络设备,还能监测局域网和互联网上的数据流量等信息,1992年7月,针对SNMP缺乏安全性的弱点,又公布了S-SNMP(SecureSNMP)草案。到1993年初,又推出了SNMPVersion2即SNMPv2(推出了SNMPv2以后,SNMP就被称为SNMPv1)。SNM-Pv2包容了以前对SNMP的各项改进工作,并在保持了SNMP清晰性和易于实现的特点以外,吸取了CMIP的部分优点,功能更强,安全性更好,具体表现为:

·提供了验证机制,加密机制,时间同步机制等,安全性大大提高;

·提供了一次取回大量数据的能力,效率大大提高;

·增加了管理者和管理者之间的信息交换机制,从而支持分布式管理结构,由位于中间层次(intermediate)的管理者来分担主管理者的任务,增加了远地站点的局部自主性。

·可在多种网络协议上运行,如OSI、AppleTalk和IPX等,适用多协议网络环境(但它的缺省网络协议仍是UDP)。

·扩展了管理信息结构的很多方面。特别是对象类型的定义引入了几种新的类型。另外还规范了一种新的约定用来创建和删除管理表(managementbrs)中的“行”(rows)。

·定义了两种新的协议数据单元PDU(ProtocolDataUnit)。Get-Bulk-Request协议数据单元允许检索大数据块(largedatablocks),不必象SNMP那样逐项(itembyitem)检索;Inform-Request协议数据单元允许在管理者之间交换陷阱(tran)信息。

CMIP协议是在OSI制订的网络管理框架中提出的网络管理协议。CMIP与SNMP一样,也是由管理者、、管理协议与管理信息库组成。

CMIP是基于面向对象的管理模型的。这个管理模型表示了封装的资源并标准化了它们所提供的接口。如图2所示了四个主要的元素:

·系统管理应用进程是在担负管理功能的设备(服务器或路由器等〕中运行的软件:

·管理信息库MIB是一组从各个接点收集来的与网络管理有关的数据;

·系统管理应用实体(systemmanagementapplicationentities)负责网络管理工作站间的管理信息的交换,以及与网络中其它接点之间的信息交换;

·层管理实体(layermanagemententities)表示在OSI体系结构设计中必要的逻辑。

CMIP模型也是基于C/S结构的。客户端是管理系统,也称管理者,发起操作并接收通知;服务器是被管系统,也称,接收管理指令,执行命令并上报事件通知。一个CMIP操作台(console)可以和一个设备建立一个会话,并用一个命令就可以下载许多不同的信息。例如,可以得到一个设备在一段特定时间内所有差错统计信息。

CMIP采用基于事件而不是基于轮询的方法来获得网络组件的相关数据。

CMIP已经得到主要厂商,包括IBM、HP及AT&T的支持。用户和厂商已经认识到CMIP在企业级网络管理领域是一个比较好的选择。它能够满足企业级网管对横跨多个管理域的对等相互作用(peertopeerinteractions)的要求。CMIP特别适合对要求提供集中式管理的树状系统,尤其是对电信网(telecommunicationsnetwork)的管理。这就是下面提到的电信管理网。

二、电信管理网TMN

电信管理网TMN是国际电联ITU-T借鉴0SI中有关系统管理的思想及技术,为管理电信业务而定义的结构化网络体系结构,TMN基于OSI系统管理(ITU-UX.700/ISO7498-4)的概念,并在电信领域的应用中有所发展.它使得网络管理系统与电信网在标准的体系结构下,按照标准的接口和标准的信息格式交换管理信息,从而实现网络管理功能。TMN的基本原理之一就是使管理功能与电信功能分离。网络管理者可以从有限的几个管理节点管理电信网络中分布的电信设备。

国际电信联盟(ITU)在M.3010建议中指出,电信管理网的基本概念是提供一个有组织的网络结构,以取得各种类型的操作系统(OSs)之间、操作系统与电信设备之间的互连。它采用商定的具有标准协议和信息的接口进行管理信息交换的体系结构。提出TMN体系结构的目的是支撑电信网和电信业务的规划、配置、安装、操作及组织。

电信管理网TMN的目的是提供一组标准接口,使得对网络的操作、管理和维护及对网络单元的管理变得容易实现,所以,TMN的提出很大程度上是为了满足网管各部分之间的互连性的要求。集中式的管理和分布式的处理是TMN的突出特点。

ITU-T从三个方面定义了TMN的体系结构(Architecture),即功能体系结构(FunctionalArchitecture),信息体系结构(InformationArchitecture)和物理体系结构(PhysicalArchitecture)。它们分别体现在管理功能块的划分、信息交互的方式和网管的物理实现。我们按TMN的标准从这三个方面出发,对TMN系统的结构进行设计。

功能体系结构是从逻辑上描述TMN内部的功能分布。引入了一组标准的功能块(Functionalblock)和可能发生信息交换的参考点(referencepoints)。整个TMN系统即是各种功能块的组合。

信息体系结构包括两个方面:管理信息模型和管理信息交换。管理信息模型是对网络资源及其所支持的管理活动的抽象表示,网络管理功能即是在信息模型的基础上实现的。管理信息交换主要涉及到TMN的数据通信功能和消息传递功能,即各物理实体和功能实体之间的通信。

物理体系结构是为实现TMN的功能所需的各种物理实体的组织结构。TMN功能的实现依赖于具体的物理体系结构,从功能体系结构到物理体系结构存在着映射关系。物理体系结构随具体情况的不同而千差万别。在物理体系结构和功能体系结构之间有一定的映射关系。物理体系结构中的一个物理块实现了功能体系结构中的一个或多个功能块,一个接口实现了功能体系结构中的一组参考点。

仿照OSI网络分层模型,ITU-T进一步在TMN中引入了逻辑分层。如图3所示:

TMN的逻辑分层是将管理功能针对不同的管理对象映射到事务管理层BML(BusinessManagementLayer),业务管理层SML(ServiceManagementLayer),网络管理层NML(NetworkManagementLayer)和网元管理层EML(ElementManagementLayer)。再加上物理存在的网元层NEL(NetworkElementLayer),就构成了TMN的逻辑分层体系结构。从图2-6可以看到,TMN定义的五大管理功能在每一层上都存在,但各层的侧重点不同。这与各层定义的管理范围和对象有关。

三、TMN开发平台和开发工具

1.利用TMN的开发工具开发TMN的必要性

TMN的信息体系结构应用OSI系统管理的原则,引入了管理者和的概念,强调在面向事物处理的信息交换中采用面向对象的技术。如前所述,TMN是高度强调标准化的网络,故基于TMN标准的产品开发,其标准规范要求严格复杂,使得TMN的实施成为一项具有难度和挑战性的工作;再加上OSI系统管理专业人员的相对缺乏,因此,工具的引入有助于简化TMN的开发,提高开发效率。目前比较流行的基于TMN标准的开发平台有HPOVDM、SUNSEM、IBMTMN平台和DSET的DSG及其系列工具。这些平台可以用于开发全方位的TMN管理者和应用,大大降低TMN/Q3应用系统的编程复杂性,并且使之符合开放系统互连(OSI)网络管理标准,这些标准包括高级信息模型定义语言GDM0,OSI标准信息传输协议CMIP,以及抽象数据类型定义语言ASN.1。其中DSET的DSG及工具系列除了具备以上功能外,还具有独立于硬件平台的优点。下面将比较详细论述DSET的TMN开发工具及其在TMN开发中的作用。

2.DSET的TMN开发工具的基本组成

DSET的TMN开发工具从功能上来讲可以构成一个平台和两大工具箱。一个平台:分布式系统生成器DSG(DistributedSystemGenerator);两个工具箱:管理者工具箱和工具箱。

分布式系统生成器DSG

DSG是用于顶层TCP/IP、OSI和其它协议上构筑分布式并发系统的高级对象请求0RB。DSG将复杂的通信基础设施和面向对象技术相结合,提供构筑分布式计算的软件平台。通信基础设施支持分布式计算中通信域的通信要求。如图4所示,它提供了四种主要的服务:透明远程操作、远程过程调用和消息传递、抽象数据服务及命名服务。借助于并发的面向对象框架,一个复杂的应用可以分解成一组相互通信的并发对象worker,除了支持例如类和多重继承等重要的传统面向对象特征外,为了构筑新的worker类,DSG也支持分布式对象。在一个开放系统中,一个worker可以和其它worker进行通信,而不必去关心它们所处的物理位置。

DSG提供给用户用以开发应用的构造块(buildingblock)称为worker。一个worker可以有自己的控制线程,也可以和别的线程共享一个控制线程,每个Worker都有自己的服务访问点SAP(ServiceAccessPoint),通过SAP与其它worker通信。Worker是事件驱动的。在Worker内部,由有限状态机FSM(FiniteStateMachine〕定义各种动作及处理例程,DSG接受外部事件并分发到相应的动作处理例程进行处理。如图5所示,独占线程的此worker有三个状态,两个SAPs,并且每个SAP的消息队列中都有两个事件。DSG环境通过将这些事件送到相应的事件处理程序中来驱动worker的有限状态机。

Worker是分布式的并发对象,DSG用它来支持面向对象的特点,如:类,继承等等。Worker由workerclass定义。Worker可以根据需要由应用程序动态创建。在一个UNIX进程中可以创建的Worker个数仅受内存的限制。

管理者工具箱由ASN.C/C++编译器、CMIP/ROSE协议和管理者代码生成器MCG构成,如图6所示。

其中的CMIP/ROSE协议提供全套符合Q3接口选用的OSI七层协议栈实施。由于TMN在典型的电信环境中以面向对象的信息模型控制和管理物理资源,所有被管理的资源均被抽象为被管对象(M0),被管理系统中的帮助管理者通过MO访问被管理资源,又根据ITU-TM.3010建议:管理者与之间通过Q3接口通信。为此管理者必须产生与通信的CMIP请求。管理者代码生成器读取信息模型(GDMO文件和ASN.1文件),创立代码模板来为每个被定义的MO类产生CMIP请求和CMIP响应。由于所有CMIP数据均由ASN.1符号定义,而上层管理应用可能采用C/C++,故管理者应用需要包含ASN.1数据处理代码,管理者工具箱中的ASNC/C++编译器提供ASN.1数据到C/C++语言的映射,并采用“预处理技术“生成ASN.1数据的低级代码,可见利用DSET工具用户只需编写网管系统的信息模型和相关的抽象数据类型定义文件,然后利用DSET的ASNC/C++编译器,管理者代码生成器即可生成管理者部分代码框架。

工具箱包括可砚化生成器VAB、CMIP翻译器、ASN.C/C++Toolkit,其结构见图7。用来开发符合管理目标定义指南GDMO和通用管理信息协议CMIP规定的应用.使用DSET独具特色的工具箱的最大的好处就是更快、更容易地进行应用的开发。DSET在应用的开发上为用户做了大量的工作。

一个典型的GDMO/CM1P应用包括三个代码模块:

·、MIT、MIB的实施

·被管理资源的接口代码

·后端被管理资源代码

第一个模块用于处理与MO实施。工具箱通过对过滤、特性处理、MO实例的通用支持,自动构作这一个模块。DSET的这一部分做得相当完善,用户只需作少量工作即可完成本模块的创建。对于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed这些CMIP请求,第一个模块中包含有缺省的处理代码框架。这些缺省代码都假定管理者的CMIP请求只与MO打交道。为了适应不同用户的需求,DSET工具箱又提供在缺省处理前后调用用户程序的接入点(称为Userhooks)。当某CMIP请求需与实际被管资源或数据库打交道时,用户可在相应的PRE-或POST-函数中加入自己的处理代码。例如,当你需要在二层管理应用中发CMIP请求,需望获取实际被管资源的某属性,而该属性又不在相应MO中时你只需在GDMO预定义模板中为此属性定义一PRE-GET函数,并在你自己的定制文件中为此函数编写从实际被管设备取到该属性值的代码即可。DSET的Agent代码在执行每个CMIP请求前都要先检查用户是否在GDMO预定义文件中为此清求定义了PRE-函数,若是,则光执行PRE-函数,并根据返回值决定是否执行缺省处理(PRE-函数返回D-OK则需执行缺省处理,否则Agent向管理者返回正确或错误响应)。同样当Agent执行完缺省处理函数时,也会检查用户是否为该请求定义了POST-函数,若是则继续执行POST-函数。至于Agent与MO之间具体是如何实现通信的,用户不必关心,因为DSET已为我们实现了。用户只需关心需要与设备交互的那一部分CMIP请求,为其定制PRE-/POST函数即可。

网络管理技术范文6

一、网络管理技术概述

网络管理已经成为计算机网络和电信网研究中最重要的内容之一。网络中采用的先进技术越多,规模越大,网络的维护和管理工作也就越复杂。计算机网络和电信网的管理技术是分别形成的,但到后来渐趋同化,差不多具有相同的管理功能和管理原理,只是在网络管理上的具体对象上有些差异。

通常,一个网络由许多不同厂家的产品构成,要有效地管理这样一个网络系统,就要求各个网络产品提供统一的管理接口,即遵循标准的网络管理协议。这样,一个厂家的网络管理产品就能方便地管理其他厂家的产品,不同厂家的网络管理产品之间还能交换管理信息。

在简单网络管理协议snmp(simple network management protocol)设计时,就定位在是一种易于实施的基本网络管理工具。在网管领域中,它扮演了先锋的角色,因osi的cmip发展缓慢同时在internet的迅猛发展和多厂商环境下的网络管理解决方案的驱动下,而很快成为了事实上的标准。

snmp的管理结构如图1所示。它的核心思想是在每个网络节点上存放一个管理信息库mib(management information base),由节点上60(agent)负责维护,管理者通过应用层协议对这些进行轮询进而对管理信息库进行管理。snmp最大的特点就是其简单性。它的设计原则是尽量减少网络管理所带来的对系统资源的需求,尽量减少agent的复杂性。它的整个管理策略和体系结构的设计都体现了这一原则。

snmp的主要优点是:

·易于实施;

·成熟的标准;

· c/s模式对资源要求较低;

·广泛适用,代价低廉。

简单性是snmp标准取得成功的主要原因。因为在大型的、多厂商产品构成的复杂网络中,管理协议的明晰是至关重要的;但同时这又是snmp的缺陷所在——为了使协议简单易行,snmp简化了不少功能,如:

·没有提供成批存取机制,对大块数据进行存取效率很低;

·没有提供足够的安全机制,安全性很差;

·只在tcp/ip协议上运行,不支持别的网络协议;

·没有提供管理者与管理者之间通信的机制,只适合集中式管理,而不利于进行分布式管理;

·只适于监测网络设备,不适于监测网络本身。

针对这些问题,对它的改进工作一直在进行。如1991年11月,推出了rmon(rernote network monitor)mib,加强snmp对网络本身的管理能力。它使得snmp不仅可管理网络设备,还能监测局域网和互联网上的数据流量等信息,1992年7月,针对snmp缺乏安全性的弱点,又公布了s-snmp(secure snmp)草案。到1993年初,又推出了snmp version 2即snmpv2(推出了snmpv2以后,snmp就被称为snmpv1)。snm-pv2包容了以前对snmp的各项改进工作,并在保持了snmp清晰性和易于实现的特点以外,吸取了cmip的部分优点,功能更强,安全性更好,具体表现为:

·提供了验证机制,加密机制,时间同步机制等,安全性大大提高;

·提供了一次取回大量数据的能力,效率大大提高;

·增加了管理者和管理者之间的信息交换机制,从而支持分布式管理结构,由位于中间层次(intermediate)的管理者来分担主管理者的任务,增加了远地站点的局部自主性。

·可在多种网络协议上运行,如osi、appletalk和ipx等,适用多协议网络环境(但它的缺省网络协议仍是udp)。

·扩展了管理信息结构的很多方面。特别是对象类型的定义引入了几种新的类型。另外还规范了一种新的约定用来创建和删除管理表(management tables)中的“行”(rows)。

·定义了两种新的协议数据单元pdu(protocol data unit)。get-bulk-request协议数据单元允许检索大数据块(large data blocks),不必象snmp那样逐项(item by item)检索; inform-request协议数据单元允许在管理者之间交换陷阱(tran)信息。

cmip协议是在osi制订的网络管理框架中提出的网络管理协议。cmip与snmp一样,也是由管理者、、管理协议与管理信息库组成。

cmip是基于面向对象的管理模型的。这个管理模型表示了封装的资源并标准化了它们所提供的接口。如图2所示了四个主要的元素:

·系统管理应用进程是在担负管理功能的设备(服务器或路由器等〕中运行的软件:

·管理信息库mib是一组从各个接点收集来的与网络管理有关的数据;

·系统管理应用实体(system management application entities)负责网络管理工作站间的管理信息的交换,以及与网络中其它接点之间的信息交换;

·层管理实体(layer management entities)表示在osi体系结构设计中必要的逻辑。

cmip模型也是基于c/s结构的。客户端是管理系统,也称管理者,发起操作并接收通知;服务器是被管系统,也称,接收管理指令,执行命令并上报事件通知。一个cmip操作台(console)可以和一个设备建立一个会话,并用一个命令就可以下载许多不同的信息。例如,可以得到一个设备在一段特定时间内所有差错统计信息。

cmip采用基于事件而不是基于轮询的方法来获得网络组件的相关数据。

cmip已经得到主要厂商,包括ibm、hp及at&t的支持。用户和厂商已经认识到cmip在企业级网络管理领域是一个比较好的选择。它能够满足企业级网管对横跨多个管理域的对等相互作用(peer to peer interactions)的要求。cmip特别适合对要求提供集中式管理的树状系统,尤其是对电信网(telecommunications network)的管理。这就是下面提到的电信管理网。

二、电信管理网tmn

电信管理网tmn是国际电联itu-t借鉴0si中有关系统管理的思想及技术,为管理电信业务而定义的结构化网络体系结构,tmn基于osi系统管理(itu-u x.700/iso 7498-4)的概念,并在电信领域的应用中有所发展.它使得网络管理系统与电信网在标准的体系结构下,按照标准的接口和标准的信息格式交换管理信息,从而实现网络管理功能。tmn的基本原理之一就是使管理功能与电信功能分离。网络管理者可以从有限的几个管理节点管理电信网络中分布的电信设备。

国际电信联盟(itu)在m.3010建议中指出,电信管理网的基本概念是提供一个有组织的网络结构,以取得各种类型的操作系统(oss)之间、操作系统与电信设备之间的互连。它采用商定的具有标准协议和信息的接口进行管理信息交换的体系结构。提出tmn体系结构的目的是支撑电信网和电信业务的规划、配置、安装、操作及组织。

电信管理网tmn的目的是提供一组标准接口,使得对网络的操作、管理和维护及对网络单元的管理变得容易实现,所以,tmn的提出很大程度上是为了满足网管各部分之间的互连性的要求。集中式的管理和分布式的处理是tmn的突出特点。

itu-t从三个方面定义了tmn的体系结构(architecture),即功能体系结构(functional architecture),信息体系结构(information architecture)和物理体系结构(physical architecture)。它们分别体现在管理功能块的划分、信息交互的方式和网管的物理实现。我们按tmn的标准从这三个方面出发,对tmn系统的结构进行设计。

功能体系结构是从逻辑上描述tmn内部的功能分布。引入了一组标准的功能块(functional block)和可能发生信息交换的参考点(reference points)。整个tmn系统即是各种功能块的组合。

信息体系结构包括两个方面:管理信息模型和管理信息交换。管理信息模型是对网络资源及其所支持的管理活动的抽象表示,网络管理功能即是在信息模型的基础上实现的。管理信息交换主要涉及到tmn的数据通信功能和消息传递功能,即各物理实体和功能实体之间的通信。

物理体系结构是为实现tmn的功能所需的各种物理实体的组织结构。tmn功能的实现依赖于具体的物理体系结构,从功能体系结构到物理体系结构存在着映射关系。物理体系结构随具体情况的不同而千差万别。在物理体系结构和功能体系结构之间有一定的映射关系。物理体系结构中的一个物理块实现了功能体系结构中的一个或多个功能块,一个接口实现了功能体系结构中的一组参考点。

仿照osi网络分层模型,itu-t进一步在tmn中引入了逻辑分层。如图3所示:

tmn的逻辑分层是将管理功能针对不同的管理对象映射到事务管理层bml(business management layer),业务管理层sml(service management layer),网络管理层nml(network management layer)和网元管理层eml(element management layer)。再加上物理存在的网元层nel(network element layer),就构成了tmn的逻辑分层体系结构。从图2-6可以看到,tmn定义的五大管理功能在每一层上都存在,但各层的侧重点不同。这与各层定义的管理范围和对象有关。

三、tmn开发平台和开发工具

1.利用tmn的开发工具开发tmn的必要性

tmn的信息体系结构应用osi系统管理的原则,引入了管理者和的概念,强调在面向事物处理的信息交换中采用面向对象的技术。如前所述,tmn是高度强调标准化的网络,故基于tmn标准的产品开发,其标准规范要求严格复杂,使得tmn的实施成为一项具有难度和挑战性的工作;再加上osi系统管理专业人员的相对缺乏,因此,工具的引入有助于简化tmn的开发,提高开发效率。目前比较流行的基于tmn标准的开发平台有hpov dm、sun sem、ibm tmn平台和dset的dsg及其系列工具。这些平台可以用于开发全方位的tmn管理者和应用,大大降低tmn/q3应用系统的编程复杂性,并且使之符合开放系统互连(osi)网络管理标准,这些标准包括高级信息模型定义语言gdm0,osi标准信息传输协议cmip,以及抽象数据类型定义语言asn.1。其中dset的dsg及工具系列除了具备以上功能外,还具有独立于硬件平台的优点。下面将比较详细论述dset的tmn开发工具及其在tmn开发中的作用。

2.dset的tmn开发工具的基本组成

dset的tmn开发工具从功能上来讲可以构成一个平台和两大工具箱。一个平台:分布式系统生成器dsg(distributed system generator);两个工具箱:管理者工具箱和工具箱。

分布式系统生成器dsg

dsg是用于顶层tcp/ip、osi和其它协议上构筑分布式并发系统的高级对象请求0rb。 dsg将复杂的通信基础设施和面向对象技术相结合,提供构筑分布式计算的软件平台。通信基础设施支持分布式计算中通信域的通信要求。如图4所示,它提供了四种主要的服务:透明远程操作、远程过程调用和消息传递、抽象数据服务及命名服务。借助于并发的面向对象框架,一个复杂的应用可以分解成一组相互通信的并发对象worker,除了支持例如类和多重继承等重要的传统面向对象特征外,为了构筑新的worker类,dsg也支持分布式对象。在一个开放系统中,一个worker可以和其它worker进行通信,而不必去关心它们所处的物理位置。

dsg提供给用户用以开发应用的构造块(building block)称为worker。一个worker可以有自己的控制线程,也可以和别的线程共享一个控制线程,每个worker都有自己的服务访问点sap(service access point),通过sap与其它worker通信。worker是事件驱动的。在worker内部,由有限状态机fsm(finite state machine〕定义各种动作及处理例程,dsg接受外部事件并分发到相应的动作处理例程进行处理。如图5所示,独占线程的此worker有三个状态,两个saps,并且每个sap的消息队列中都有两个事件。dsg环境通过将这些事件送到相应的事件处理程序中来驱动worker的有限状态机。

worker是分布式的并发对象,dsg用它来支持面向对象的特点,如:类,继承等等。worker由worker class定义。worker可以根据需要由应用程序动态创建。在一个unix进程中可以创建的worker个数仅受内存的限制。

管理者工具箱由asn.c/c++编译器、cmip/rose协议和管理者代码生成器mcg构成,如图6所示。

其中的cmip/rose协议提供全套符合q3接口选用的osi七层协议栈实施。由于tmn在典型的电信环境中以面向对象的信息模型控制和管理物理资源,所有被管理的资源均被抽象为被管对象(m0),被管理系统中的帮助管理者通过mo访问被管理资源,又根据itu-t m.3010建议:管理者与之间通过q3接口通信。为此管理者必须产生与通信的cmip请求。管理者代码生成器读取信息模型(gdmo文件和asn.1文件),创立代码模板来为每个被定义的mo类产生cmip请求和cmip响应。由于所有cmip数据均由asn.1符号定义,而上层管理应用可能采用c/c++,故管理者应用需要包含asn.1数据处理代码,管理者工具箱中的asn c/ c++编译器提供asn.1数据到c/c++语言的映射,并采用“预处理技术“生成asn.1数据的低级代码,可见利用dset工具用户只需编写网管系统的信息模型和相关的抽象数据类型定义文件,然后利用dset的asn c/c++编译器,管理者代码生成器即可生成管理者部分代码框架。

工具箱包括可砚化生成器vab、cmip翻译器、asn.c/c++ toolkit,其结构见图7。用来开发符合管理目标定义指南gdmo和通用管理信息协议cmip规定的应用.使用dset独具特色的工具箱的最大的好处就是更快、更容易地进行应用的开发。dset在应用的开发上为用户做了大量的工作。

一个典型的gdmo/cm1p应用包括三个代码模块:

·、mit、mib的实施

·被管理资源的接口代码

·后端被管理资源代码

第一个模块用于处理与mo实施。工具箱通过对过滤、特性处理、mo实例的通用支持,自动构作这一个模块。dset的这一部分做得相当完善,用户只需作少量工作即可完成本模块的创建。对于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed这些cmip请求,第一个模块中包含有缺省的处理代码框架。这些缺省代码都假定管理者的cmip请求只与mo打交道。为了适应不同用户的需求,dset工具箱又提供在缺省处理前后调用用户程序的接入点(称为user hooks)。当某cmip请求需与实际被管资源或数据库打交道时,用户可在相应的pre-或post-函数中加入自己的处理代码。例如,当你需要在二层管理应用中发cmip请求,需望获取实际被管资源的某属性,而该属性又不在相应mo中时你只需在gdmo预定义模板中为此属性定义一pre-get函数,并在你自己的定制文件中为此函数编写从实际被管设备取到该属性值的代码即可。dset的agent代码在执行每个cmip请求前都要先检查用户是否在gdmo预定义文件中为此清求定义了pre-函数,若是,则光执行pre-函数,并根据返回值决定是否执行缺省处理(pre-函数返回d-ok则需执行缺省处理,否则agent向管理者返回正确或错误响应)。同样当agent执行完缺省处理函数时,也会检查用户是否为该请求定义了post-函数,若是则继续执行post-函数。至于agent与mo之间具体是如何实现通信的,用户不必关心,因为dset已为我们实现了。用户只需关心需要与设备交互的那一部分cmip请求,为其定制pre-/post函数即可。

第二个模块实现mo与实际被管资源的通信。它的实现依赖于分布式系统生成器dsg所提供“网关处理单元”(gateway)、远程过程调用(rpc)与消息传递机制及msl语言编译器。通信双方的接口定义由用户在简化的rose应用中定义,在dsg中也叫环境,该环境定义了双方的所有操作和相关参数。dsg的ctx编译器编译ctx格式的接口定义并生成接口表。dsg的msl语言编译器用以编译分布式对象类的定义并生成事件调度表。采用dsg的网关作为mo与实际被管资源间的通信桥梁,网关与mo之间通过定义接口定义文件及各自的msl文件即可实现通信,网关与被管设备之间采用设备所支持的通信协议来进行通信,例如采用tcp/ip协议及socket机制实现通信。

第三个模块对被管理资源进行实际处理。这一模块根据第二个模块中定义的网关与被管设备间的通信机制来实现,与工具没有多大联系。

四、tmn开发的关键技术

电信管理网技术蕴含了当今电信、计算机、网络通信和软件开发的最新技术,如osi开放系统互连技术、osi系统管理技术、计算机网络技术及分布式处理、面向对象的软件工程方法以及高速数据通信技术等。电信管理网应用系统的开发具有巨大的挑战性。

工具的引入很大程度上减轻了tmn的开发难度。留给开发人员的最艰巨工作就是接口(interface)的信息建模。尤其是q3接日的信息建模问题。

q3接口是tmn接口的“旗舰”,q3接口包括通信模型和信息模型两个部分,通信模型(0si系统管理)的规范制定的十分完善,并且工具在这方面所作的工作较多,因此,当我们设计和开发各种不同管理业务的tmn系统时,主要是采用一定的方法学,遵循一定的指导原则,针对不同电信领域的信息建模问题。

为什么说建模是tmn开发中的关键技术呢?从管理的角度而言,在那些先有国际标准(或事实上的标准),后有设备的情况下,是有可能存在一致性的信息模型的,例如目前sdh和七号信令网的tmn系统存在这样的信息模型标准。但即使这样,在这些tmn系统的实施过程,有可能由于管理需求的不同而对这些模型进行进一步的细化。在那些先有设备而后才有国际标准(或事实上的标准)的设备,而且有的电信设备就无标准而言,由于不同厂家的设备千差万别,这种一致性的信息模型的制定是非常困难的。

例如,近年来标准化组织国际电信联盟(itu-t)、欧洲电信标准组织(etsi)、网络管理论坛(nmf)和atm论坛等相继颁布了一些q3信息模型。但至今没有一个完整的稳定的交换机网元层的q3信息模型。交换机的q3信息模型提供了交换机网元的一个抽象的、一般的视图,它应当包含交换机的管理的各个方面。但这是不可能的。因为随着电信技术的不断发展,交换机技术也在不断的发展,交换机的类型不断增加,电信业务不断的引入。我们很难设计一个能够兼容未来交换机的信息模型。如今的交换机已不再是仅仅提供电话的窄带业务,而且也提供象isdn这样的宽带业务。交换机趋向宽带窄带一体化发展,因此交换机的q3信息模型是很复杂的,交换机q3信息建模任务是很艰巨的。

五、tmn管理者和的开发

下面结合我们的开发工作,探讨一下tmn管理者和的开发。

1.管理者的开发

基于osi管理框架的管理者的实施通常被认为是很困难的事,通常,管理者可以划分为三个部分。第一部分是位于人机之间的图形用户接口gui(graphical user interfaces),接收操作人员的命令和输入并按照一种统一的格式传送到第二部分——管理功能。管理功能提供管理功能服务,例如故障管理,性能管理、配置管理、记费管理,安全管理及其它特定的管理功能。接收到来gui的操作命令,管理功能必须调用第三部分——cmsi api来发送cmip请求到。cmis api为管理者提供公共管理信息服务支持。

大多数的网管应用是基于unix平台的,如solaris,aix and hp-ux。若gui是用x-window来开发的,那么gui和管理功能之间的接口就不存在了,从实际编程的的角度看,gui和管理功能都在同一个进程中。

上面的管理者实施方案尽管有许多优点,但也存在着不足。首先是费用昂贵。所有的管理工作站都必须是x终端,服务器必须是小型机或大型机。这种方案比采用pc机作客户端加上unix服务器的方案要昂贵得多。其次,扩展性不是很好,不同的管理系统的范围是不同的,用户的要求也是不一样的,不是所有的用户都希望在x终端上来行使管理职责。因此,pc机和调终端都应该向用户提供。最后由于x-window的开发工具比在pc机上的开发工具要少得多。因此最终在我们的开发中,选择了pc机作为管理工作站,sun ultral作为服务器。

在实际工作中我们将管理者划分为两个部分——管理应用(management application)和管理者网关(manager gateway)。如图8所示。

管理应用向用户提供图形用户接口gui并接受用户的命令和输入,按照定义好的消息格式送往管理者网关,由其封装成cmip请求,调用cmis api发往。同时,管理者网关还要接收来自的响应消息和事件报告并按照一定的消息格式送往管理应用模块。

但是这种方案也有缺点。由于管理应用和管理者网关的分离,前者位于pc机上,后者位于ultral工作站上。它们之间的相互作用须通过网络通信来完成。它们之间的接口不再是一个参考点(reference point),而是一个物理上的接口,在电信管理网tmn中称为f接口。迄今为止itu-t一直没能制定出有关f接口的标准,这一部分工作留给了tmn的开发者。鉴于此,我们制定了管理应用和管理者网关之间通信的协议。

在开发中,我们选择了pc机作为管理工作站,sun ultral作为我们的管理者网关。所有的管理应用都在pc机上。开发人员可以根据各自的喜好来选择不同开发工具,如java,vc++,vb,pb等。管理者网关执行部分的管理功能并调用cmis api来发送cmip请求,接收来自的响应消息和事件报告并送往相应的管理应用。

管理者网关的数据结构是通过编译信息模型(gdmo文件和asn.1文件)获得的。它基于dsg环境的。管理者网关必须完成下列转换:

数据类型转换:gui中的数据类型与asn.1描述的数据类型之间的相互转换;

消息格式转换:gui和管理者网关之间的消息格式与cmip格式之间的相互转换;

协议转换:tcp/ip协议与osi协议之间的相互转换。

这意味着管理者网关接收来自管理应用的消息。将其转换为asn.1的数据格式,并构造出cmis的参数,调用cmis api发送cmip请求。反过来,管理者收到来自的消息,解读cmis参数,构造消息格式,然后送往gui。gui和管理者网关之间的消息格式是由我们自己定义的。由于管理应用的复杂性,消息格式的制定参考了cmis的参数定义和asn.1的数据类型。

管理者网关是采用多线程(multi-thread)编程来实现的。

2.的开发

的结构如图9所示。

为了使部分的设计和实现模块化、系统化和简单化,将agent分成两大模块——通用模块和mo模块——进行设计和实现。如图所示,通用agent向下只与mo部分直接通信,而不能与被管资源mr直接进行通信及操作,即通用agent将manager发来的cmip请求解析后投递给相应的m0,并从mo接收相应的应答信息及其它的事件报告消息。

的作用是代表管理者管理mo。利用工具的支持,采用面向对象的技术,分为八个步骤进行agent的设计和实现,这八个步骤是:

第一步:对信息模型既gdmo文件和asn.1文件的理解,信息模型是tmn系统开发的基础和关键。特别是对信息模型中对象类和其中各种属性清晰的认识和理解,对于实际的tmn系统来说,其信息模型可能很复杂,其中对象类在数量上可能很多。也就是说,在设计和实现agent之前,必须作到对mo心中有数。

第二步:被管对象mo的定制。这一部分是agent设计和实现中的关键部分,工具对这方面的支持也不是很多,特别是涉及到mo与mr之间的通信,更为复杂,故将mo专门作为一个模块进行设计和实现mo和mr之间的通信以及数据和消息格式的转换问题,利用网关原理设计一个网关来解决。

第三步:创建内置的m0。所谓内置mo就是指在系统运行时,已经存在的物理实体的抽象。为了保证能对这些物理实体进行管理,必须将这些被管对象的各种固有的属性值和操作预先加以定义。

第四步:创建外部服务访问点sap。如前所述,tmn系统中各个基于分布式处理的worker之间通过sap进行通信,所以要为agent与管理者manager之间、agent与网关之间创建sap。

第五步:sap同内置mo的捆绑注册。由于在tmn系统中,agent的所有操作是针对mo的,即所有的cmip请求经解析后必须送到相应的m0,而基于dsg平台的worker之间的通信是通过sap来实现的。因而,在系统处理过程中,当进行信息的传输时,必须知道相应mo的sap,所以,在agent的设计过程中,必须为内置mo注册某一个sap。

第六步:agent配置。对agent中有些参数必须加以配置和说明。如队列长度、流量控制门限值、agent处理单元组中worker的最大/最小数目。报告的处理方式、同步通信方式中超时门限等。

第七步:agent用户函数的编写,如agent worker初始化函数、子函数等的编写。

第八步:将所有函数编译,连接生成可运行的agent。

mo模块是agent设计中的一个重要而又复杂的部分。这是由于,一方面工具对该部分的支持不是很多:另一方面,用户的大部分处理函数位于这一部分;最主要的还在于它与被管资源要跨平台,在不同的环境下进行通信。mo模块的设计思想是在mo和mr之间设计一个网关(gateway),来实现两者之间的消息、数据、协议等转换。

mo部分的主要功能是解析,执行来自管理者的cmip请求,维持各mo的属性值同被管资源的一致性,生成cmip请求结果,并上报通用agent模块,同时与mr通信,接收和处理来自mr的事件报告信息,并转发给通用agent。

mo部分有大量的用户定制工作。工具只能完成其中一半的工作,而另一半工作都需要用户自己去定制。用户定制分为两大类;

第一类是pre-/post-函数。pre-/post-函数的主要功能是在agent正式处理cmip请求之前/之后与被管资源打交道,传送数据到mr或从mr获取数据并做一些简单的处理。通过对这些pre-/post-函数的执行,可以确保能够真实地反映出被管资源的运行状态。pre-/post-函数分为两个层次:mo级别和属性级别。mo级别层次较高,所有对该对象类的cmip操作都会调用mo级别的pre-/post-函数。属性级别层次低,只有对该属性的cmip操作才会调用这些函数。dset工具只提供了pre-/post-函数的人口参数和返回值,具体的代码需要完全由用户自己编写。由于agent与被管资源有两种不同的通信方式,不同的方式会导致不同的编程结构和运行效率,如果是同步方式,编程较为简单,但会阻塞被管资源,适合于由大量数据返回的情况。异步方式不会阻塞被管资源,但编程需要作特殊处理,根据不同的返回值做不同的处理,适合于数据不多的情况,在选择通信方式时还要根据mo的实现方式来确定。比如,mo若采用doer来实现,则只能用同步方式。

第二类是动作、事件报告和通知的处理,动作的处理相对比较容易,只需考虑其通信方式采用同步还是异步方式。对事件报告和通知的处理比较复杂。首先,需要对事件进行分类,对不同类别的事件采用不同的处理方法,由哪一个事件前向鉴别器efd(event forwarding discriminator)来处理等等。比如,告警事件的处理就可以单独成为一类。其次,对每一类事件需要确定相应的efd的条件是什么,哪些需要上报管理应用,哪些不需要。是否需要记入日志,这些日志记录的维护策略等等。

除了这两类定制外,mo也存在着优化问题。比如mo用worker还是doer来实现,通信方式采用同步还是异步,面向连接还是无连接等等,都会影响整个的性能。

如果mo要永久存储,我们采用文件方式。因为目前dset的工具只支持versant、odi这两种面向对象数据库管理系统oodbms,对于0racle,sybase等数据库的接口还需要用户自己实现。mo定制的工作量完全由信息模型的规模和复杂程度决定,一个信息模型的对象类越多,对象之间的关系越复杂(比如一个对象类中的属性改变会影响别的类),会导致定制工作的工作量和复杂程度大大增加。

者agent在执行管理者发来的cmip请求时必须保持与被管资源mr进行通信,将manager传送来的消息和数据转发给mr,并要从mr获取必要的数据来完成其操作,同时,它还要接收来自mr的事件报告,并将这些事件上报给manager。

由上述可知,与被管资源mr之间的通信接口实际上是指mo与mr之间的通信接口。大部分mo是对实际被管资源的模拟,这些mo要与被管资源通信。若让这些mo直接与被管资源通信,则存在以下几个方面的弊端:

·由于mo模块本身不具备错误信息检测功能(当然也可在此设计该项功能,但增加了mo模块的复杂性),如果将上向发来的所有信息(包括某些不恰当的信息)全部转发给mr,不仅无此必要,而且增加了数据通信量;同理mr上发的信息也无必要全部发送给mo。

·当被管资源向mo发消息时,由于mit对于被管资源来说是不可知的,被管资源不能确定其相应mo在mit中所处的具置,从而也就无法将其信息直接送到相应的mo,因而只能采用广播方式发送信息。这样一来,每当有消息进入mo模块时,每个mo都要先接收它,然后对此消息加以判断,看是否是发给自己的。这样一方面使编程复杂化,使软件系统繁杂化,不易控制,调试困难;另一方面也使通信开销增大。

·mo直接与被管资源通信,使得系统在安全性方面得不到保障,在性能方面也有所下降,为此,采用计算机网络中中网关(gateway)的思想,在mo与被管资源建立一个网关,即用一个gateway worker作为mo与被管资源通信的媒介。网关在的进程处理中起到联系被管资源与mo之间的“桥梁”作用。

六、总结与展望

q3接口信息建模是tmn开发中的关键技术。目前,各标准化组织针对不同的管理业务制定和了许多信息模型。这些模型大部分是针对网元层和网络层,业务层和事务层的模型几乎没有,还有相当的标准化工作正在继续研究。业务层和事务层的模型是将来研究的重点。