基于TMN的网管系统度量标准的研究.doc

第一章第一章 绪论绪论 .3 1.1 系统性能评价概述3 1.1.1 性能评价简介.3 1.1.2 性能评价方法.3 1.2 计算机系统性能度量标准概述4 1.2.1 TPC 测试简介4 1.2.2 TPC 基准程序5 1.3 网管系统性能度量标准概述6 1.4 相关的研究工作6 第二章第二章 基于基于 TMN 的网络管理系统结构的网络管理系统结构7 2.1 TMN 功能体系结构7 2.2 TMN 物理体系结构9 2.3 TMN 信息体系结构10 2.3.1 管理层次模型.11 2.3.2 管理信息模型.11 2.3.3 管理组织模型.12 2.4 基于 TMN 的网络管理系统结构13 2.4.1 管理者-代理模型13 2.4.2 功能模块的划分.13 2.4.3 功能单元集的划分.14 2.4.4 功能单元的划分.14 2.5 基于 TMN 的网络管理系统结构的分析15 第三章第三章 基于基于 TMN 的网管系统度量标准的研究的网管系统度量标准的研究17 3.1 网管系统性能测试的基本内容.17 3.1.1 测试条件的确定.17 3.1.2 测试参数的选择.17 3.1.3 响应时间的测量.18 3.2 网管系统性能测试系统的设计.18 3.2.1 协调测试法.18 3.2.2 远程测试法.19 3.2.3 两种设计方案的比较与结论.20 3.2.4 测试参数的确定.22 第四章第四章 用户接入网网管系统性能测试的实现用户接入网网管系统性能测试的实现 .26 4.1 用户接入网网管系统概述26 4.1.1 用户接入网网管系统功能.26 4.1.2 用户接入网网管系统结构.27 4.1.3 通信处理机概述.28 4.1.4 平台适配器概述.29 4.2 接入网管系统性能测试的实现.31 4.2.1 模拟GUI的实现31 4.2.2 模拟Agent的实现31 4.2.3 前端探头(Front Probe)的实现31 4.2.4 后端探头(Back Probe)的实现31 4.2.5 测试控制功能(Test Control)的实现31 4.2.6 测试结果分析(Test Analyses)的实现31 4.3 接入网管系统性能测试分析.31 第五章第五章 网管系统性能度量标准的前景网管系统性能度量标准的前景 .31 5.1 网管系统的发展趋势.31 5.2 网管系统性能度量标准的发展.31 结束语结束语 .32 参考文献参考文献 .32 第一章第一章 绪论绪论 1.11.1 系统性能评价概述系统性能评价概述 1.1.11.1.1 性能评价简介性能评价简介 系统性能评价研究的目的主要有三个：选择、改进和设计。在众多的系统 （方案）中选择一个最适合需要的系统（方案） ，即在一定的价格范围内选择性 能最好的系统，达到较好的性能/价格比；对已有系统的性能缺陷和瓶颈进行改 进和提高其运行效率；对未来设计的系统进行性能预测，在性能成本方面实现 最佳设计或配置。 系统性能一般包括以下两个方面：一个方面是它的可靠性或可利用性，亦 即，系统能正常工作的时间，其指标可以是能够持续工作的时间长度，如平均 无故障时间；也可以是在一段时间内，能正常工作的时间所占的百分比。另一 方面是它的处理能力或效率。这又可以分为三个指标：一类指标是各种吞吐率， 如系统在单位时间内能处理正常作业的个数。另一类指标是各种响应时间，即 从系统得到输入到给出输出之间的时间。再一类指标是各种利用率，即在给定 的时间区间中，各种部件（包括硬设备和软系统）被使用的时间与整个时间之 比。当然不同的系统对性能指标的描述有所不同，例如局域网通常使用的性能 评估指标为信道传输速率、信道吞吐量和容量、信道利用率、传输延迟、响应 时间和负载能力等。 系统性能取决多种因素，最基本的因素是系统的配置（即指系统构成所包 括的各种软件、硬件的成分、数量、能力和系统结构、处理和调度策略等）和 系统负载（即指工作负载和工作方式，例如交互方式、批处理方式等） 。 性能评价的主要任务就是研究系统配置、系统负载、性能指标之间的相互 关系。 1.1.21.1.2 性能评价方法性能评价方法 性能评价的方法大致可以分为两类： 1.1.2.1 测量方法 通过一定的测量设备或一定的测量程序可以直接从系统测得各项性能指标 或与之密切相关的量，然后由它们经过一些简单的运算求出相应的指标性能。 这是最直接也是最基本的方法，其他方法在一定程度上也依赖于它。但是这种 方法只能适用于已经存在并且运行的系统，而且比较费时间。测量方案和测量 手段是测量方法的关键。 1.1.2.2 模型方法 首先对要评价的计算机系统建立一个适当的模型，然后求出模型的性能指 标，以便对系统进行性能评价。模型中一般包括许多参数，这些参数的确定往 往依赖于对实际系统的测量结果或对系统参数的估价。与测量方法相比，模型 方法有两个优点：一是它不仅可以应用于已有的系统的性能评价，而且也可以 应用于尚未存在系统的性能预测；二是它的工作量一般比测量方法要小，比测 量手段的费用要小。 模型方法又可分为模拟方法和分析方法两种。模拟方法是用一个程序动态 地模拟一个系统及其负载。一般首先使用一个模拟语言来为系统建立一个模型， 然后在模拟时，通过用负载驱动系统模型从而得出模型的性能指标。模拟方法 可以详细地刻画系统，得出较精确的性能指标，但是构造和使用模型时的费用 较高。 分析方法则是应用数学理论与方法来研究和描述性能与系统、负载之间的 关系。为了数学上描述与计算的方便，往往要对模型进行一些简化和假设，因 而这种模型刻画系统的详细程度比较低，得出的性能指标精度也较低。但是这 种方法理论基础强，可以明显地刻画各种因素之间的关系，而且构造和使用模 型时的费用也较低。 1.21.2 计算机系统性能度量标准概述计算机系统性能度量标准概述 80 年代初期，在线事务处理（on-line transaction processing）逐渐占 据了数据库业务的主导地位，一个最明显的例子是银行自动柜员机（ATM）的大 量涌现。用户不必通过出纳员就可以自己在 ATM 上存取款，而藏在这些柜员机 后面的是无数庞大的数据库服务器。OLTP 系统性能的优劣从根本上讲就取决于 后台数据库服务器的性能。 目前，国内外广泛地使用 TPC 测试来衡量计算机系统的性能，TPC 的基准测 试提供了交易处理和决策支持性能的量化方法，已经成为户能决定其购买行为， 供应商有效地向用户进行市场营销的通用准绳。 1.2.11.2.1 TPCTPC 测试简介测试简介 TPC（Transaction Process Performance Council，事物处理委员会）是 有数 10 家会员公司创建的非赢利组织，它的功能是指定商务应用基准程序 （Benchmark）的标准规范、性能和价格度量，并管理测试结果的发布。TPC 不 给出基准程序的代码，而只给出基准程序的标准规范（Standard Specification） ，任何厂家或其它测试者都 可以根据规范，最优地构造出自己 的系统（测试平台和测试程序） 。为保证测试结 果的客观性，被测试者（通常 是厂家）必须提交给 TPC 一套完整的报告（Full Disclosure Report） ，包括被 测系统的详细配置、分类价格和包含五年维护费用在内的总价格。 TPC 测试修正了以前其他测试的局限性：它能处理来自网络的交易，同时考 虑了与用户的互动性；在测试的执行过程中，对整个系统进行监控，因此测试 者不可能任意修改最终结果而不留任何痕迹，而且在使用时限定了许多条件： 1、 在公布测试结果的同时必须公布全部系统的造价，包括参与测试的硬件 和软件。 2、 必须公布测试过程中的各种参数设置，必须保证其他公司如果按照公布 后的参数进行设置也能够测试出同样的结果。这样做的目的是为了提高 测试结果的公正性。 3、 为工作负载分级。用户数的多少和数据库的大小并不是随意变化的，不 同性能的系统对应不同的测试集。比如数据量从 1G 到 100G 分成 10 段， 在测试自己的系统时，测试者需要选择一个恰当的测试集。 4、 事物的完成量必须严格与相应时间对应。90%的事物必须在 2 秒钟内完 成因为 以上 4 点的重要意义就在于使用该软件测试处的结果能够得到大多数厂商 的承认。试想，不同造价的系统很难在性能上有可比性，昂贵的主机系统在数 据库的处理性能上肯定比普通 RISC 服务器和 PC 服务器好。而用户最关心的是 性能价格比。如果有些用户或厂商对测试结果质疑，那么根据测试者提供的参 数设置，在同样配置的系统上应该也可以得到相同或相近的结果，否则该结果 就是无效的。而且对于 OLTP 系统而言，响应时间是一个最关键的指标，ATM 或 前台终端的录入员不可能无限制的等待后台数据库主机响应自己的请求。 1.2.21.2.2 TPCTPC 基准程序基准程序 TPC 已经推出了四套 OLTP（On Line Transaction Processing，在线事务 处理）基准程序，被称为 TPCA、TPCB、TPCC 和 TPCD。其中 A 和 B 已 经过时，不再使用了。TPCC 是在线事务处理(OLTP)的基准程序，TPCD 是决 策支持(DecisionSupport) 的基准程序。TPC 即将推出 TPCE，作为大型企业 (Enterprise)信息服务的基准程序。 TPCC 模拟一个批发商的货物管理环境。该批发公司有 N 个仓库，每个仓 库供应 10 个地区，其中每个地区为 3000 名顾客服务。在每个仓库中有 10 个终 端，每一个终端用于一个地区。在运行时，10N 个终端操作员向公司的数据库 发出 5 类请求。由于一个仓库中不可能存储公司所有的货物，有一些请求必须 发往其它仓库，因此，数据库在逻辑上是分布的。N 是一个可变参数，测试者 可以随意改变 N，以获得最佳测试效果。 TPCC 使用三种性能和价格度量，其中性能由 TPCC 吞吐率衡量，单位是 tpmC。tpm 是 transactionsper minute 的简称；C 指 TPC 中的 C 基准程序。它 的定义是每分钟内系统处理的新订单 个数。要注意的是，在处理新订单的同时， 系统还要按表 1 的要求处理其它 4 类事务 请求。从表 1 可以看出，新订单请求 不可能超出全部事务请求的 45，因此，当一个系统的性能为 1000tpmC 时， 它每分钟实际处理的请求数是 2000 多个。价格是指系 统的总价格，单位是美 元，而价格性能比则定义为总价格性能，单位是/tpmC。 1.31.3 网管系统性能度量标准概述网管系统性能度量标准概述 反观网管系统，还没有成熟的性能度量标准，网管系统的性能主要依靠用 户的主观感觉去评价。而网管系统的性能还和其硬件环境，网络质量等外部因 素有关。在此通过借鉴 TPC 测试的思想，结合网管系统的特点，对网管系统的 性能度量标准进行研究。 1.41.4 相关的研究工作相关的研究工作 第二章第二章 基于基于 TMN 的网络管理系统结构的网络管理系统结构 电信管理网（TMN）2是一个逻辑上与电信网分离的网络，它通过标准的接 口（包括通信协议和信息模型）与电信网进行传送/接收管理信息从而达到对电 信网控制和操作的目的。通过引入用于管理的通用网络模型，使运用统一的管 理信息和标准接口将网络中各种不同的设备和业务管理起来成为可能。 TMN的提出对于网络管理系统结构的研究是一个质的飞跃，TMN的基本思想 是：在开放的环境中，采用标准的管理协议来传送标准的管理信息，这一基本 思想可以保证网络管理系统的高适应性和可持续性建设的要求。 TMN采用面向对象的方法，使用管理对象来抽象网络资源，使得网管系统可 以与网络的实际物理资源分离开来。使用TMN思想抽象出来的信息模型是独立于 实际物理资源的具体实现方式的，厂商可以不断采用新技术对设备进行革新， 以求更高的性能、更低的成本，但与网管系统之间传送的管理信息是保持不变 的，这样在一定的时期内，网管系统可以以不变应网络设备、网络技术的万变。 随着技术的不断发展，当目前定义的信息模型已不能满足管理需求时，可以增 加新的管理信息模型，同时原有的管理信息模型依然能发挥作用。从这一点来 说，基于TMN的网络管理系统在软件的重用性方面具有很高的优越性。同时， TMN提供不同层次上的软件重用机制，以方便用户以较小的代价构造不同需求、 不同复杂程度的网管系统。 按照基于TMN的网络管理系统结构构造的网管系统，在满足管理现有网络设 备的基础上，提供一定的冗余能力以适应网络的不断发展，具有较好的可扩展 性，符合网管系统向未来平滑过渡的需要。同时，为以后的软件开发提供一些 基本功能块，从而可以提高网络管理系统开发速度。 TMN的管理体系结构比较复杂，ITU-T从功能划分、信息交互、物理实现和 逻辑分层四个方面分别进行描述，即功能体系结构、物理体系结构、信息体系 结构和逻辑分层体系结构。 2.1 TMN 功能体系结构功能体系结构 把 TMN 的功能划分为功能模块7，每一功能模块又是由更小的功能单元来 构成的，这是 TMN 的功能结构的基本原则。这一原则的目的是简化 TMN 的实现， 把功能分布在不同的模块中，功能模块间利用数据通信功能（DCF）来传递消息， 并由功能参考点来分割，各模块可以独立实现，降低了 TMN 的复杂性，提高了 软件的重用度。每个功能块完成一个特定的管理功能，同时它们又互相作用， 交互管理信息来实现 TMN 对电信网的管理。根据新版的 ITU-T M.3011 的建议， TMN 的基本功能块有四种：操作系统功能（OSF） ，工作站功能（WSF） ，Q 适配功 能（QAF）和网元功能（NEF） ，功能参考点分别为 q，f，x，g 和 m。如图 2.1 所示。 WSF QAFNEF OSF m xg q q 图图 2.1 TMN 功能结构功能结构 构图构图 f OSF 对管理信息进行处理以实现对电信网的监视、协调和控制。 WSF 为用户提供接入到 TMN 的手段，其功能包括终端的安全接入和注册、识 别、确认输入输出、支持菜单、窗口和分页等等。 。 QAF 用来连接 TMN 实体与非 TMN 实体，提供 TMN 参考点与非 TMN 参考点之间 的转换。 NEF 表示被管理的功能，同时也提供管理时所需要的通信和支撑功能。 在 TMN 的功能模块间进行消息的传递时，需要用到数据通信功能（DCF） ， DCF 不属于 TMN 的功能实体，但它是 TMN 交换信息的手段，其主要作用是提供 信息传送职能，DCF 可以有选路、转接和互通功能，涉及 OSI 参考模型的下三 层功能，它由数据通信网（DCN）支持。 TMN 功能模块又可细分为功能单元，功能单元（FC）是比功能块（FB）粒度 更小的可重用模块。每一功能模块都是由这些功能单元组合而成的。功能单元 包括： Management Application Function（MAF） MAF 是实现 TMN 管理业务的主要部件，在不同的交互中，依据交互的发起， MAF 可以充当管理者或代理者的角色。根据 MAF 所在的功能实体不同，可以以 包含功能实体的名字来命名 MAF，如 MFMAF，OSFMAF，NEFMAF。 MFMAF：MFMAF 在 MF 中支持代理者或管理者的角色。这些管理应用功 能是 MF 的一部分，用来执行支持 OSF 的管理功能。例如：暂时存储数据，过滤， 门限值设置，安全和测试等。 OSFMAF：OSFMAF 是 OSF 的最必须和最基本的功能。根据需求不同， 它的管理功能可以从简单到复杂，如在存取管理对象的信息时支持实现管理者 或代理者的角色；对原始信息进行处理，统计和性能分析；对上报的信息作出 反应等。 NEFMAF：NEFMAF 在 NEF 中提供支持 NEF 的代理者的角色。 QAFMAF：QAFMAF 在 QAF 中支持实现 QAF 的管理者和/或代理者的角色。 Security Function（SF） 为了满足安全策略或用户需求，为功能实体（FB）提供必须的安全业务。 X.800 建议定义了五种基本的业务：用户授权，接入控制，数据确认，数据一 致性和非拒绝操作。 Directory System Function（DSF） 代表一个基于 X.500 的本地或全局可用的分布式数据库系统，实现对数据 库的管理功能，为要求数据库服务的功能实体提供数据库服务。 Directory Access Function（DAF） 与所有需要访问数据库的功能实体相关，为它所在的功能实体提供访问数 据库的能力。 Information Conversion Function（ICF） ICF 是位于中间层次的管理系统将管理信息模型从一种形式转换为另一种形 式，以适应不同管理系统的需要。管理信息的转换可以在语法层次，也可以在 语义层次。 ICF 是 MF 功能实体的必选功能。如果管理系统不要求信息模型的转换，则 ICF 只实现信息传递功能。 Presentation Function（PF） PF 承担将 TMN 信息模型形式的管理信息和人机界面可以显示的信息格式的 互相转换。PF 提供支持让用户感觉界面友好的一切操作如输入、显示和修改对 象细节的功能。 Human Machine Adaptation（HMA） HMA 负责将 MAF 的管理信息模型转换为 TMN 提供给 PF 的管理信息模型。HMA 同时包含用户的授权和验证功能。 Message Communication Function（MCF） MCF 与所有提供物理接口的功能实体有关。它用于且仅限于与对等实体交换 管理信息。MCF 包含一个使得功能实体接入数据通信网的协议栈。当一个功能 实体与两种不同的接口交互时，两种类型的 MCF 将会提供必须的协议转换。 每个功能块可以包含的功能单元如图 2.2 所示。 MAFICFHMAPFDSFDAFSFMCF OSFMOO-OOOM WSF-M-OOM NEFq3M-OOOM NEFqxO-OOOM MFOMO-OOOM QAFq3OM-OOOM QAFqxOM-OOOM M：MandatoryO：Optional-：Not allowed 图图 2.22.2 功能块与功能单元的关系功能块与功能单元的关系 2.2 TMN 物理体系结构物理体系结构 根据需要，TMN 的功能结构可以灵活地组成不同的物理结构，物理结构由物 理实体组成，物理实体之间为 TMN 的标准接口。TMN 的基本的物理实体包括操 作系统（OS） ，工作站（WS） ，Q 适配器（QA） ，网元（NE）和数据通信网（DCN） ， 它们之间的接口分别为 Q3 接口，F 接口和 X 接口，如图 2.3 所示。 OS 主要完成 OSF 功能，同时也可完成 QAF 功能和 WSF 功能。 WS 是完成 WSF 功能的系统，即完成 TMN 信息模型与人机界面表示形式之间 转换的系统。 QA 是连接非 TMN 网元和 TMN 操作系统之间的设备，完成 QAF 功能。 NE 由电信设备和一些支撑设备组成，主要完成 NEF 功能，也可根据需要完 成 TMN 中的其他功能，如 QAF，OSF 和 WSF 等。 DCN 是 TMN 中完成 DCF 功能的通信网，可以由不同类型的子网（如公用电话 网、公用数字数据网 DDN、公用分组数据网 X.25、专用线、ISDN、WAN、LAN 或 SDH DCC 等）互连而成。DCN 为 TMN 的物理实体间通信提供传输媒质，TMN 物 理实体间的信息交换要用到 OSI 参考模型的全部 7 层功能，而 DCN 只需提供 OSI 参考模型的下三层功能，不需提供 4 到 7 层功能。 当功能块在不同的物理实体中实现时，功能模块之间的功能参考点由物理 实体之间的相应物理接口替代，如 Q3 接口在 q 参考点实现，F 接口在 f 参考点 实现，X 接口在 x 参考点实现。若功能模块在一个物理实体中实现时，功能模 块之间的功能参考点不转化为物理接口。 物理实体以功能块为基本构件组成。物理实体根据功能需求的不同，可以 包含不同的功能块。功能块与物理实体的关系如图 2.4 所示。有些功能块对于 物理实体是必须的，有些则是可选的。 NEFMFQAFOSFWSF NEMOOOO MDMOOO QAM OSOOMO WSM M：必选功能 O：可选功能 图图 2.42.4 TMNTMN 功能块与物理实体的关系功能块与物理实体的关系 2.3 TMN 信息体系结构信息体系结构 TMN 信息体系结构主要用来描述功能块之间交换的不同类型的管理信息，包 OS WS DCN NEQA Q3/X/F F Q3Q3 X 图图 2.3 TMN 物理结构物理结构 括管理层次模型、管理信息模型和组织模型。 2.3.1 管理层次模型管理层次模型 电信网络的种类很多，电信网络的管理非常复杂，对某类电信设备（如交 换机，交叉连接设备 DXC 等）的管理已经显示了其复杂性，若对整个电信网， 甚至只是对某个本地网作到综合管理都将是一项非常艰巨和非常复杂的任务。 TMN 管理分层的概念就为最终实现综合管理提供了一个分步骤的，循序渐进的 实现方法。TMN 把管理功能需求分解为不同的层次，每层相对独立，都有各自 的 OSF 完成特定的管理功能，层与层之间由 q 参考点分割。在 TMN 建设初期可 以只完成低层的管理功能，以后逐步完善高层管理功能，最终实现管理的综合。 TMN 的管理层次分为五层，从低到高依次为：网元层（NEL） ，网元管理层 （EML） ，网络管理层（NML） ，业务管理层（SML）和事务管理层（BML） 。其中网 元层属于被管理层，其他四层属于管理层。 网元管理层对网元进行管理，主要功能包括： （1）控制和协调一个或多个网元。 （2）与网络管理层进行信息交互。 （3）维护涉及网元的统计数据、记录和其他有关数据。 网络管理层从全网的角度对管理域内的网络进行管理，包括： （1）从全网的角度控制和协调本管理域内的所有网元。 （2）根据向用户提供业务的要求对网络能力进行指配，终止或修改。 （3）维护网络性能，并与上面的业务管理层进行交互。 业务管理层主要处理有关业务的事项，它较少涉及网络的物理特性，而着 重于网络所提供的逻辑业务功能。主要包括： （1）为所有业务事项提供与用户的基本联系点。 （2）与业务提供者、下面的网络管理层和上面的事务管理层进行交互。 （3）维护与业务有关的统计数据，处理业务之间的交互。 事务管理层负责网络的高层决策，包括制定计费政策，设定目标任务等， 由网络的最高层管理人员进行管理。 2.3.2 管理信息模型管理信息模型 包含要管理资源和元素的数据库是任何网络管理系统的基础。在 TMN 中， 此数据库指的是管理信息库(MIB)。用于定义和组织 MIB 的通用框架是管理信息 模型，MIM 定义了如何表示与命名 MIB 中的资源。管理信息模型建立在面向对 象的概念的基础上，对于每个要管理的资源，都抽象成管理对象（Managed Object） 。一个管理对象是从管理的角度采用面向对象方法对资源的一种抽象. 通过封装的手段，管理对象屏蔽了与管理无关的资源信息，提供给管理系统一 个用来交换管理信息的标准接口。 一个管理对象类由以下几部分组成： (1)在对象边界可见的属性； (2)可以施加在管理对象上的系统管理操作； (3) 管理对象可发出的通知； (4)包含在管理对象中的可选择包； (5)管理对象的行为描述； (6) 管理对象在继承层次图中的位置。 管理对象使用管理对象定义指南(GDMO)描述。GDMO 定义了九种模板以描述 MO 的特征:管理对象类模板，包模板，行为模板. 属性模板，属性组模板，通 知模板，动作模板，参数模板及命名约束模板。MO 间的关系主要包括继承和包 含关系。 继承关系描述的是管理对象类(MOC)之间的关系. 它与面向对象方法中继承 的概念是一致的. 管理对象继承其父类的特性，包括属性、操作和通知等，并 扩展一些自身的特性. 特定管理域中的所有管理对象类因继承关系而组成的一 树型结构称为继承树。继承为管理信息建模提供了一种强有力的机制，便于实 现管理信息的重用和维护信息的一致性. 包含关系描述的是管理对象实例(MOI)间的关系，实际上可以看作是现实世 界中的包含关系（如一个交换机的插板上有若干个物理端口） 。一个管理对象实 例可以在逻辑上包含相同或不同的管理对象实例，一个管理对象实例只能包含 于一个管理对象实例中。 在一个具体的管理域中，所有对象实例之间以包含关系组成一个树型结构， 这个树型结构称作包含树，也称作管理信息树(MIT)。MIT 中包含对象和被包含 对象被分别称为父节点和子节点。 包含关系用来实现对管理对象实例的命名。每一个管理对象类都有一个关 键属性用于实例的命名,它能够在所有兄弟对象实例中唯一标识自己。在管理信 息树中，从根到某对象实例的相对可区分名序列称为可区分名(DN),用来在管理 域中唯一标识自己。 2.3.3 管理组织模型管理组织模型 组织模型规定了 TMN 的结构，以及管理层内和管理层间的 TMN 功能，它主 要用来描述管理进程担任控制角色（管理者）和被控角色（代理）的能力以及 管理者和代理之间的相互关系。 管理者是管理系统管理命令发出者；代理代理执行管理者的指令，并且在 其维护的 MIB 中管理对象上执行管理指令的具体操作。管理者通过 CMIP 访问各 个代理，对 MIB 中被管对象进行操作，接收操作结果，也可以通过 CMIP 接收通 知。图 2.5 表示管理者和代理、对象间的关系。 管理者 管理开放系统 管理操作 通知 CMI P 代理者 执行操作 发出通知 MI B 图2.5 管理者、代理者、对象之间的关系 被管理开放系统 本地系统环境 2.4 基于基于 TMN 的网络管理系统结构的网络管理系统结构 2.4.1 管理者管理者-代理模型代理模型 首先，由于被管资源和网管系统一般处于分布式的环境，按照 TMN 的组织 模型可以将网络管理系统结构分成两部分：管理者和代理，如图 2.5 所示。对 应于图 2.1TMN 的功能结构，代理完成 NEF 功能，直接与被管设备交互，管理者 完成 WSF、OSF 和 QAF 功能，通过代理间接地对被管资源进行操作。在实现时， 管理者和代理是一对一或一对多的关系。 管理者和代理之间的接口对应 TMN 物理结构中的 Q3 接口，是标准的接口 （包括通信协议和信息模型） 。Q3 接口协议栈的定义见 ITU-T Q.811/Q.812，其 中应用层的协议为 CMIP 协议（适用于交互操作和少量数据传送）和 FTAM 协议 （用于大量数据文件的传送） 。 Q3 接口不仅包括 OSI 七层的通信协议，还包括在第七层中用到的管理信息 模型，例如 ITU-T M.31004定义的面向网元的通用信息模型；ITU-T Q.821/Q.822 定义的关于告警和性能管理支持对象的信息模型。在实际网管开 发中，Q3 接口用于一个特定通信网络的管理时，还要增加用于管理该通信网络 的特定的管理信息模型。这些通用信息模型和管理特定网络的信息模型都是用 GDMO/ASN.1 来描述。例如： moExample MANAGEDMANAGED OBJECTOBJECT CLASSCLASS DERIVEDDERIVED FROMFROM “Rec x.721”:top; CHARACTERIZEDCHARACTERIZED BYBY “ITU_T M.3100 “:attributeValueChangeNotificationPackage , “ITU_T M.3100 “:createDeleteNotificationPackage, moExamplePkg PACKAGEPACKAGE BEHAVIOURSBEHAVIOURS moExampleBeh; ATTRIBUTESATTRIBUTES moExampleId GETGET;-管理对象实例标识 CONTIONALCONTIONAL PACKAGESPACKAGES moExamplePackage1 PRESENTPRESENTIFIF “管理接口符合条件 1”, moExamplePackage2 PRESENTPRESENTIFIF “管理接口符合条件 2”; REGISTEREDREGISTERED ASAS moExampleObjectClass 1; 2.4.2 功能模块的划分功能模块的划分 一个 TMN 系统不能只是一个单一的由功能集组成的实体，而是由一组可以 互操作的系统组成的网络。根据 TMN 功能结构的描述，TMN 的基本功能块有四 种：操作系统功能（OSF） ，工作站功能（WSF） ，Q 适配功能（QAF）和网元功能 （NEF） ，功能参考点分别为 q，f，x，g 和 m。如图 2.1 所示。所以在实际网管 系统开发中，可以将这四个功能模块作为四个独立的分布的实体进行开发，这 四个功能实体相互之间通过各自规定的接口进行通信。 ITU-T M.3010 对 TMN 的物理结构及接口进行了描述。Q3 接口位于 OSF 与 NEF 之间（见 2.4.1 节） 。X 接口是连接两个 TMN 系统或 TMN 系统与其它提供类 似 TMN 接口的非 TMN 网络（或系统）的接口。X 接口最重要的特点是其对安全 性的要求很高，因为 X 接口存在于不同的系统，而这些系统可能存在于不同管 理域或不同国家。所以有必要在连接协议中涉及安全问题，如密码识别等，同 时 X 接口的信息模型也应当限制外部接入，X 接口中所定义的能力集将成为整 个 TMN 系统的接入限制，另外，也可能增加附加的协议要求来提高安全级别。 F 接口位于工作站功能（WSF）与具有 OSF 功能的物理实体之间，将 TMN 的 管理能力呈现给用户，并将用户的干预转呈给管理系统。F 接口是用户与管理 系统交互信息的渠道。通过对 F 接口的标准化，可以使不同厂家，不同网络的 用户通过工作站功能与具有 OSF 功能的物理实体交互，实现对通信网有效、方 便的管理。到目前为止，只有 ITU-T M.3300 提出了 F 接口的管理能力，而用户 的接入方式并没有任何标准来指明。 2.4.3 功能单元集的划分功能单元集的划分 根据 TMN 的五大管理功能域，我们可以进一步把管理者中的 OSF 分为五个 对应的功能单元集：配置管理模块、故障管理模块、性能管理模块、帐务管理 模块和安全管理模块，分别完成相应管理功能域的功能： 1故障管理：故障管理是一组功能集，它提供了对异常操作状态的检测、 隔离和修复的能力。主要功能包括：故障发生的检测与报告；维护和使 用错误日志；跟踪和定位故障；执行故障诊断测试。 2配置管理：配置管理支持为了网络服务而对管理对象进行的控制、鉴别、 从中搜集数据和向其提供数据。主要功能包括：记录网络的当前配置； 记录配置的改变情况；标识网络成员；初始化与关闭网络系统；关闭网 络参数；给对象或对象集命名。 3帐务管理：计帐管理允许网络管理者对网络资源使用决定其费用并计费。 其主要功能包括：将应缴纳的费用通知用户；支持用户费用上限的设置； 在必须使用多个通信实体才能完成通信时，能够把使用多个管理对象的 费用结合起来。 4性能管理：性能管理提供给网络管理者评价和监视系统和网络的性能的 能力。它主要功能包括：收集和散发资源的当前性能数据；维护和检查 性能日志，以便用于规划和分析。 5安全管理：安全管理用于对网络资源的使用进行保护。其主要功能包括： 授权管理；接人控制管理；加密和密码管理；鉴权管理；安全日志管理。 这五个功能单元集可以是物理上分布的，也可以集中在一台机器上。这 五个功能单元集之间的接口是非标准接口，由网管系统开发商自主定义。 2.4.4 功能单元的划分功能单元的划分 按照 2.1 节功能单元的划分方法，每个功能模块以及上一节中划分的功能 单元集都可以进一步分成更小粒度的功能单元，多个功能单元既可以集中在一 台机器上，也可以是分布在其它通过网络可以访问的计算机上，而且分布的功 能单元之间的接口是非标准接口，由网管系统开发商自主定义。 2.5 基于基于 TMN 的网络管理系统结构的分析的网络管理系统结构的分析 综上所述，基于 TMN 的网络管理系统结构可以表示如图 2.6 所示： 网管平台接口 F 接口 OSF 代理（NEF） Q3 接口 网管界面（WSF） 安全管理模块故障管理模块配置管理模块 网管平台 性能管理模块帐务管理模块 图图 2.6基于基于 TMN 的网络管理系统结构的网络管理系统结构 非 Q3 接口 Q 适配器(QAF) 不能提供 Q3 接口的被管 系统 第三章第三章 基于基于 TMN 的网管系统度量标准的研究的网管系统度量标准的研究 3.1 网管系统性能测试的基本内容网管系统性能测试的基本内容 3.1.1 测试条件的确定测试条件的确定 为了使性能测试的结果更加真实、可信，在测试中借鉴了 TPC 的思想，限 定了以下条件： 1 测试结果和测试环境相关，因此在测试结果中包括系统的软、硬件构成； 2 为不同的负载分级； 3 由于在实际使用网管系统时，操作员不可能无限制地等待后台系统响应 自己的请求，因此所有的事物必须在指定的时间内完成。 3.1.2 测试参数的选择测试参数的选择 网管系统的性能的内容很多，有可行性、响应时间、吞吐量、利用铝、服 务级别，传输两，提供的负荷以及一般可用能力等。结合网管系统的实际情况， 主要包含以下四个方面： 1 网管系统的时延，指网管系统实际运行时，在单位时间内网管命令从发 出到得到应答的平均响应时间，这也是反映系统效率最主要的参数。一 个完整的系统响应时间一般包括用户时间（用户的思考、记入时间） ，网 络延迟，处理节点延迟和处理时间。在网管系统中，由于 GUI 的响应时 间固定，并且不随系统负载变化，网管系统的性能基本取决于 Manager，同时为了屏蔽用户时间对测试结果所造成的误差，因此网管系 统的时延只包含 Manager 的响应时间； 2 网管系统的容量，指在网管系统的效率可以接受的情况下，该网管系统 可管理的被管系统的数量，由于一个给定的网管系统可管理的 Agent 有 着相同的接口，因此网管系统的容量可由所接入的 Agent 数目表示； 3 网管系统的网络效率是指在确定的网络带宽情况下，单位时间内传输网 管信息多少； 4 网管系统的可用性，表示了网管系统作为一个整体的性能，它依赖于各 组成部分的技术可靠性，这种可靠性也许非常高（例如 99.999%） ，但不 是无限高。可用性如下计算： MTBF MTBF + MTTD + MTTR + MTOR 其中： MTBF = 故障间隔平均时间 MTTD = 诊断平均时间 MTTR = 修复前平均时间 MTOR = 维修的平均时间 3.1.3 响应时间的测量响应时间的测量 网管系统的性能测试就是对网管系统的时延、容量、效率和可用性进行测 试，在四个参数中的响应时间是最基本的参数，它表示了系统效率，其它参数 都要借助于响应时间的测量结果，因此响应时间的测试方法十分重要。 在考虑响应时间的测试方法是，需要考虑以下几方面的问题： 1为了全面反映待测系统的性能，测试用例的数目很大，必须考虑测试的 效率； 2要能辨别不同请求的权重。例如：一个复杂的查询不能等同与一个简单 的查询操作； 3要能对等待请求响应时的超时情况进行处理； 4测试结果要能便于处理。 测量应用程序响应时间的传统方法是，发送应用程序请求，测量收到的返 回响应的时间。对于网管系统来说，这些请求可以是用户的各种操作请求，也 可以是被管设备上报的各种事件、通知。这种方法效率很低，不能满足我们的 要求，为了实现性能测试的自动化，我们在此基础上进行了扩展，利用探头识 别特定应用程序的请求和响应对（request and response pair） ，从而有效地 测量该应用程序的响应时间。探头记录下测量到的请求的情况（权值、响应时 间分布）和等待请求响应时的超时次数，这样，只需要索引该记录，便可以获 得某个特定服务器的响应时间的测量值。 3.2 网管系统性能测试系统的设计网管系统性能测试系统的设计 在进行测试系统的设计时，测试方法的选择十分重要。它一方面决定了测 试系统的构造，另一方面也决定了抽象测试集的描述。因此我们必须研究具体 的测试系统与被测实现的特性，确定适当的测试方法。 抽象测试方法是根据对 IUT 输入的控制和输出的观察来描述的。在测试中， 测试者可以从本地或远端的不同参考点（PCO）来观察和控制抽象测试原语 （ASP：Abstract Service Primitive）的交互。 在选择测试方法时，需要考虑以下几方面的问题： 1)要能够满足测试覆盖度的要求，即应当尽可能测试管理对象描述中的各 个转移分支及转移路径。 2)要满足自动测试系统实现的可能性。 3)要保证测试方法的可实现性，即减少其实现的复杂度。 借鉴 ISO/IEC9646 中的描述，下面我们概括地介绍几种抽象测试方法：协 调测试法及远程测试法。 3.2.1 协调测试法协调测试法 协调测试法的实质是对测试过程中所交换的信息的进行控制，实现对整 个测试过程的协调。在这种方法中，协调涉及到测试驱动子系统、被测子系统、 控制台三方面，协调过程在测试用例中完成，通过 API 函数实现。 协调测试法的结构如图 31 所示。 整个测试环境由 IUT 和测试器构成，测试器的主用功能分为测试驱动器(TD)和 测试协调过程(TCP)。IUT 为被测实现。 在协调测试法中，TD 负责测试原语的发送，IUT 作为被测实现，负责测试 原语的接收并上报测试应答，为了有效且可靠地执行测试，必须在测试系统的 上端 TD 与下端(IUT)之间实行同步和控制的协调过程，提供对 TD 及 IUT 的协调 机制，包括对测试激励的控制、测试结果的记录、测试顺序的调度及异常情况 处理等。 协调测试法实现了对 TD 及 IUT 的同步及对测试过程中所交换的信息的管理。 这种测试法要求 IUT 侧提供一个用户操作接口或可用于测试目的的标准化程序 接口，可以直接或间接地访问。测试用例中要涉及 TD 的测试步并完成与 IUT 侧 返回的测试应答的协调，并且要加入对整个测试系统的异常状态的处理、测试 结果的记录以及计时器等各项协调内容，而协调过程涉及到 TD、IUT、控制台 三者间的协调，整个测试协调的实现会比较复杂。 3.2.2 远程测试法远程测试法 主要的特点就是在测试用例中没有对测试驱动子系统和被测实现之间的协 调过程，测试协调与测试调度由测试人员手工完成，测试者在进行测试时，从 被测系统外部对被测实现进行观察和控制，根据被测系统执行测试命令的返回 结果操作终端对被测命令的执行情况，决定测试用例的执行顺序。 远程测试法的结构如图 32 所示。 Srevice Provideeer Test Driver (TD) Impletetion Under Tste (IUT) Test Coord. Procedure 2-1 - Test Request Test Response 这种测试法最主要的特点就是测试系统与被测系统之间没有 PCO。在测试用 例中没有对 TD 与 IUT 之间的协调过程，测试协调与测试调度由测试人员手工完 成，测试者在进行测试时，从被测系统外部对 IUT 的实时状态进行观察和控制， 根据被测系统执行测试命令的返回结果操作终端对被测命令的执行情况，决定 测试用例的执行顺序。 这种测试法实现简单，对 IUT 行为的控制能力较强，但效率较低。 3.2.3 两种设计方案的比较与结论两种设计方案的比较与结论 在远程测试方法中，测试以每一测试原语为单位进行。测试实现者向被测 系统发送测试命令后，直接观察测试系统响应，分析测试结果，并判定该测试 项是否满足一致性。 这种测试方法中，测试实现者对一致性测试工作具有最大的干预能力，可 以根据具体的网络实现及测试需求，实时选择测试数据，增强灵活性。 但是，如果测试实例数目太大，若对所有可测试特性均采用人工测试法， 则所需工作量过大，系统效率较低。 在协调测试方法中，采用批处理方式实现测试。在建立测试系统与被测实 现的连接后，一次性向被测系统发送所有测试实例。这种方法中，测试实现者 不必干预测试的执行过程，系统自动实现对各管理对象的测试调度及测试命令 的发送，系统效率较高。 但是，不同网管系统均有一定的专用性。因此，针对不同系统进行性测试 时，其所需的前期测试及后期测试会有所不同，因此有必要针对实际情况确定 测试序列并进行测试用例的实例化。 在性能测试中，尤其是在对系统容量进行测试时，测试实例较多，采用远 程测试效率不高，而且测试人员的干预很容易影响系统的响应时间。因此，在 此采用了协调测试方法，利用模拟 GUI 发出测试序列，测试序列由测试人员确 定。所设计的测试系统如下图所示： Srevice Provideeer Test Driver (TD) Impletetion Under Tste (IUT) Test Coord. Procedure 2-2 Test Request Test Response 测试系统各部分说明如下： 1模拟 GUI 模拟网管系统中的图形用户界面，以批处理的方式，从测试序列文件中， 读出测试实例，以同步发送到待测前端探头；并等待返回应答。当收到应答后， 判断并记录返回应答是否正确。如果超时，则记录超时，开始下一条测试命令。 2模拟 Agent 模拟网管系统中的被管设备，响应从后端探头发来的命令，并上报模拟事 件，通知。 3前端探头(Front Probe) 前端探头(Front Probe)用来测试网管系统的总响应时间（包括网络时延和 模拟 Agent 的响应时间） 。如图所示，在 t1 时刻，前端探头(Front Probe)收到 请求 1，将其立刻发送到待测 Manager，并把该测试命令的标识符和命令时间 t1 发送到测试控制功能；在 t4 时刻，收到响应 1（请求 1 的响应） ，将响应 1 的标识符和响应时间 t4 送到测试控制功能，并将响应返回给模拟 GUI，t4-t1 可以作为网管系统总的响应时间。 4后端探头(Back Probe) 后端探头(Back Probe)的原理与前端探头相同，用来测量网络时延和模拟 测试结果 测试结果分析(Test Analyses) 模拟 GUI1 模拟 GUI2 模拟 GUIN 请求 1，t1- -响应 2，t3 模拟 Agent2 模拟 AgentN 模拟 Agent1 测试控制功能（Test Control） 待测 Manager 前 端 探 头 DCN 后 端