网络管理技术及电信管理网的开发
出处：论文网
时间：2006-09-06
四、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开发中的关键技术。目前，各标准化组织针对不同的管理业务制定和发布了许多信息模型。这些模型大部分是针对网元层和网络层，业务层和事务层的模型几乎没有，还有相当的标准化工作正在继续研究。业务层和事务层的模型是将来研究的重点。
除了Q3接口外，TMN的接口还包括X，F，Qx接口。它们的Q3接口相同也包括通信模型和信息模型两个部分。各标准化组织几乎没有发布针对这些接口的规范。F接口和具体的一个TMN系统的实施密切相关，没有必要对其的通信模型和信息模型进行规范化。Qx是不完善的Q3接口，它是非标准的厂家专用的Q接口，虽然在管理系统的实施中，很多产品采用Qx接口作为Q3接口的过渡，但是随着标准化进程的推进，Qx接口将逐步被抛弃。电信工业的变化日新月异，宽带网络使得分布系统互连成为可能，使得不同的电信服务公司和运营公司相互竞争、相互合作来向用户提供服务。在这种环境下，整个电信网络管理将涉及到不同的组织以及它们的管理系统。基于TMN的多域管理（TMN-Based Multi-Domain Management）将成为未来电信网管的重要研究方向。X接口位于两个TMN系统之间，对它研究是基于TMN的多域管理系统的重点。
TMN有技术上的先进、强调公认的标准和接口等优点。但它也有目标太大、抽象化要求太高、信息模型的标准化进程太慢、OSI满协议栈的效率不高等问题。TMN自身需要进一步发展。在网络管理技术方面，除了TMN一种体系结构以外，还有ITU & ISO的开放分布处理（ODP），OSF的分布处理和管理环境（DCE／DME），NMF的OMNIPoint，OMG的公共对象请求代理体系结构（CORBA）以及TINA-C的电信信息网络体系结构（TINA）。目前，CORBA技术越来越被电信、网络部门接受和采用。CORBA体系结构是对象管理组织OMG为解决分布式处理环境中，硬件和软件系统的互连而提出的一种解决方案。CORBA适用于业务层和事务层的管理应用。对于下几层（网元层、网元管理层和网络管理层）而言，还没有比TMN更好的体系结构。TINA体系结构是基于分布式计算，面向对象以及电信和计算机业界的其它和标准，如ODP，IN，TMN和CORBA；它将电信业务和管理业务综合到同一种体系结构中，是电信业务与电信网络技术无关，从而使电信业务的开放与管理不受多厂商设备的影响。虽然TINA处于发展中，还不很成熟，但它是未来电信体系结构的最终方向。
- 上一篇：网络化：出版信息管理的必由之路
- 下一篇：我国手机市场的发展状况与发展趋势
