网络管理技术开发范文

本站小编为你精心准备了网络管理技术开发参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

一、网络管理技术概述

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

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

在简单网络管理协议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函数即可。

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

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