第十七讲

下一代网络的管理

自学讲义

主要内容

一、下一代网络的管理概述二、基于角色的网络和业务管理架构三、基于策略的网络和业务管理架构四、两种网络和业务管理架构的特点

一、下一代网络的管理概述

下一代网络的管理概述

网络和业务管理的演进下一代网络和业务管理的目标

电信网络正在从以语音为中心的电话网络向以数据为中心的、基于分布式计算的多业务网络演进，与之相适应，网络和业务的管理也必须进行变革。 现在的电信业完全以客户和业务为中心，且其运行简单灵活。当前网络和业务管理存在的问题是：业务供应商希望厂家能够提供一种能够在多厂家设备环境中解决运行支持、操作、网络管理和业务供给的综合方案。

网络和业务管理的演进

网络和业务管理的演进目前网络和业务管理的现状是：任何一个厂商都不能单独满足所有业务供应商的要求。在日益复杂的异构网络顶部，运营商面对多种厂家的软件环境，需要一种以 IP 为中心的、多厂商的、多业务的网络管理架构。创造由应用驱动的管理架构的方法：

鼓励应用的设计、开发和传送； 利用核心层的应用来刺激用户通过直接观

察就可以理解的、相互能够通信的其它应用的出现。

网络和业务管理的演进网络与业务管理的基本功能包括 ：

网络管理提供相关的操作，倾向于缩小各种单个网络单元间的差别并支持各种网络功能；还包括拓扑、配置、恢复、速度 / 连接测试、重选路由 / 重定向、协调、安全等功能；

业务管理的基本功能支持以客户为中心和以业务为中心的观点，包括账户供给、业务激活、业务层面规约管理和报告、业务质量 (QoS) 监测、计费等。

下一代网络和业务管理的目标从网络管理的角度来看，软交换作为分组化主干网的中继接入和控制解决方案，必须同时满足分组网和电路交换网管理技术的要求，其中包括简单网络管理协议（ SNMP ）、电信管理网（ TMN ）、公共对象请求结构（ CORBA ）和远程登录 (Telnet) 等。网络管理系统必须能够动态地支持业务，必须具有灵活性并能够管理不可预测的网络增长。业务管理系统必须能够改善服务质量和适应市场的发展速度，并能压缩运营代价，还必须能够管理各种网络元素。

二、基于角色的网络和业务管理架构

基于角色的网络和业务管理架构

电信运营图 (TOM)模型 业务、网络和元素的管理体系结构网络和业务管理架构的实现

TOM模型

QoS-业务质量

商业信息 分析和

决策确定

用户

搅动管理 假货管理

用户接口管理

业务实现 业务保险 业务计费

用户 个性化

处理

销售管理

订购处理

销售管理

QoS用户管理

销售管理

业务发展 和运作

程序

业务计划和发展

业务结构

业务问题管理

业务质量管理

评价和折扣

网络和 系统管理

程序

网络计划和优化

网络装备提供

网络存货管理

网络维护与重建 错误 性能 管理 管理

使用量调节管理

元部件管理技术相关的

/网络物理层 信息技术

TOM模型

从水平方向上看， TOM模型根据销售 /业务的实现、业务的保证和计费考虑了用户接口的管理。在垂直方向， TOM模型描绘了用户喜好处理、业务开发和操作过程以及网络和系统管理过程等功能。TOM模型内的功能对于网络类型是不可知的。

业务、网络和元素的管理体系结构

紧圈业务管理跨越实现，保险和计费

增值应用程序（在基础的顶部）

EMS/ NMS基础

公共单元接口

底部基础设施

拥有健壮合作程序的综合附属设施

EMS-元件管理系统NMS-网络管理系统

业务、网络和元素的管理体系结构该管理体系结构显示了一种简单的构建模块的观点：

应用程序分为四个层次； 说明跨越应用的网络基础部件的临界度，

并提出与企业内部或外部的软件进行健壮性整合的需求。

特定的应用软件应当容易与构建模块进行适配，而且，垂直跨越水平边界的软件应该受到属主的健壮性检查。

网络和业务管理架构的实现

实现管理架构的需求和推动力“网络就是应用”的概念应用是管理架构的动力管理结构的实现

实现管理架构的需求和推动力实现管理架构的需求：

运行支持系统应该鼓励新业务的创建；应该更容易操作和维护；对进入运营商系统环境的专门集成技术的需求微乎其微。从实现的观点看，高层的需求描述可以转化为三个基本的驱动力：

特性：提高简单性、灵活性，开放性和演进性；

战略蓝图：建立一种通用的架构战略和开发方式以方便多厂家解决方案和嵌入式系统的端到端整合；

实现管理架构的需求和推动力关键组件和工具：提供一种快速填补业务和网络管理功能缺口的机制，而且能够避免那些不相容和重复的工作。实现网络和业务管理架构的市场趋势：

增加管理应用智能及其适应性； 对那些看起来相互分离的应用进行整合，

以满足商业和运营的需求。

“网络就是应用”的概念从业务和网络管理的角度来看，“网络就是应用”中的应用可以被理解为“管理应用”；从终端用户的角度来看， “网络就是应用”中的应用将是普遍存在的、连接千家万户的应用 / 业务。“网络就是应用”和“网络就是计算机”以及“网络就是数据库”同样生动精确，是对“网络就是计算机”和“网络就是数据库”的最好的补充。

应用是管理架构的动力传统实现架构的方法：

事先定义了所有的分层结构以及各层之间的接口，并定义了各个层面上的架构业务和功能。最后再选择架构的实现技术，而且，架构的开发要依赖于特定的组织。传统实现方法的缺点：架构的开发周期较长，在架构真正投入市场时，其实现技术已经过时，功能和业务需求也不能满足用户的需要。

应用是管理架构的动力

架构体系是由管理应用驱动的，实现是由技术驱动的，而技术的选择则依赖于“应用就是架构”这样的标准。架构是由应用“支撑”的，应用又包括架构。下图显示了架构和应用的关系。

应用是管理架构的动力

管理应用程序

CORBA* EJ B XML Other

SNMP CLI TFTP COPS

Other

LDAP

J DBC

数据模型

可管理组件

OA&M

网页浏览器

管理架构的实现

关于业务和网络管理架构，存在两种观点：

基于 TMN/TOM模型的观点 基于应用模型的观点

基于 TMN/TOM模型的分层架构非常清晰，强调了不同类型的应用和应用接口、通用数据模型、网络元素行为的分离（或抽象）分别具有不同的要求。

基于 TMN/TOM模型观点的架构网页浏览器

HTML XML表示提取总线（例如， ， ）

客户信息数据库

业务信息数据库

i - TakeCare入口

i - FAB业务

CORBA*+EJ B+J DBC+LDAP)业务定向工作流总线（

网络信息数据库

i - Provi si on业务

i -Assure业务

i -Regul ate策略

CORBA+J DBC)网络定向传输总线（

i - Engi neer业务

前面终端平台

监督管理器供给管理器

配置管理器

CMI P TL1 CORBA， ， SNMP DCE， SNMP CLI TFTP COP LDAP， ， ， ，

光网络组件 IT网络组件 “ Hot” 第三方网络组件

数据网络组件

UI和OA&M

基于 TMN/TOM模型的架构的组成 管理门户：业务履行、保证和计费的入口

自顾的管理门户（ i-Takecare ）是用户进入OSS/BSS 解决方案的通道。门户通过轻量级目录接入协议（ LDAP ）对用户进行认证和授权。通过一个装有 Java 应用程序的网页浏览器可以访问门户 。门户不仅可以作为设置和修改命令的通道，同时也能够根据用户的授权允许用户检查业务（被激活）的可用性、性能状态等。

基于 TMN/TOM模型的架构的组成

基于企业应用整合 (EAI) 技术的应用事务处理总线：能够提供一种高度灵活和高度可伸缩的应用平台。通过 EJB 技术建立的应用事务处理总线支持各种与业务相关的应用（如业务预定、新业务创建、业务供给等）的即插即用。使用开放数据库互连（ ODBC ）和 /或 Java 数据库互连（ JDBC ）适配器支持的对象并通过相同的应用事务处理总线就可以访问数据，实现数据与应用的完全分离。

基于 TMN/TOM模型的架构的组成

网络和信息技术基础设施的管理对于管理架构的实现而言，管理接口和数据访问的系统化非常关键，而网络和元素管理“外壳”迫使其所管理的元素行为符合标准。常用的接口包括：简单网络管理协议（ SNMP ）：负责故障和性能测量； 小型文件传输协议(TFTP) ：负责硬件配置； 命令行接口(CLI) 协议 ：负责接入控制列表；

基于 TMN/TOM模型的架构的组成

网络和元素管理的“外壳”包括： “i-Engineer” 应用是网络工程所关注的，它包括物

理设备清单、插件、端口、物理电路安装和配置等；

“i-Provision” 应用将支持设备的排列、在业务供给过程中变换到网络元素、逻辑电路的修正以及事务化工作流程的管理；

“i-Assure” 应用支持端到端的电路监测、业务性能监测、业务告警表示以及电路、业务、客户或历史、趋势分析、周期性报告、业务层规约（ SLA ）一致性报告所造成的与网络相关的故障。

基于 TMN/TOM模型的架构的组成

数据模型包括三种： 客户信息模型包括与特定客户信息进行

接口的数据和处理行为； 业务信息模型包括业务提供商提供（通

过业务目录）的所有业务的定义。 网络信息模型需要解决所有技术驱动的

网络类型问题，如网络拓扑、被管理元素、子网络和业务流量描述符。

基于 TMN/TOM模型的架构的组成

OA&M工具：是一套可重用的管理工具。该工具在所有的管理应用中严格执行，包括整合这些应用的结果。可以作为对新的管理应用和解决方案的一种要求 。采用 OA&M工具使得供应商要开发的新管理应用首先在其所喜欢的硬件和软件（操作系统）平台上实现，然后根据商业需求可再进行移植。

基于应用观点的架构网络浏览器

LDAP目录 LDAPi -TakeCare入口

EJ B i -Workfl ow

业务信息数据库

客户信息数据库

网络信息数据库 J DBC

i -Engi neer

i -Connect

EJ B XML

J DBC*

CORBA

TL1 TCP/ I P上的

光网络组件

UI和OA&M

基于应用观点的架构的组成应用程序（“ i-Connect” ）包含XML、 EJB/J2EE、 CORBA和 JDBC 等。 XML将被用来向用户提供动态的内容（相对于 HTML 的静态表示）；利用 EJB/J2EE 技术实现 “ i-TakeCare”门户和整个“ i-Connect” 应用 。“i-Connect” 通过与业务信息数据库进行交互来提取被请求业务的特定信息。根据输入的数据并通过光域业务互连 (ODSI) 、基于 TCP/IP或 SNMP或 CORBA 的专用协议等，“ i-Connect” 应用可以将连接直接路由到光网络元素。

基于应用观点的架构的组成

“i-Connect” 应用通过三种方式从网络信息数据库中获取物理 /逻辑端口和拓扑信息：

直接通过 JDBC访问信息数据库； 通过“ i-Engineer” （作为代理）间接访问数

据库； 直接从网络元素中获取所有与网络相关的数

据，而不用访问任何网络数据资料库。

三、基于策略的网络和业务管理架构

基于策略的网络和业务管理架构

基于策略的网络和业务管理概述基于策略的软交换管理系统策略描述语言策略管理系统的体系结构

基于策略的网络和业务管理概述

当前网络管理和操作主要包括观察网络中的某些事件或者情况，然后根据预先确定的策略采取适当的行动来对这些事件作出反应。策略存在于大多数的软件系统和网络中，只是常常隐藏在处理逻辑中，因此并不适合具有特定需求的应用。

基于策略的网络和业务管理概述

策略的实现方法如下： 利用 C或 Java 语言编写的程序，通过

SNMP （或其它内部协议）和 modem池进行通信并自动设置参数。然而，这种方法需要大量的编程工作，且其策略很难改变。

通过一种书写简单但表达清楚的策略描述语言 (PDL) 来设计基于策略的网络管理系统。

基于策略的软交换管理系统利用策略建立的软交换管理系统，可以使组件的管理具有高度的可编程性并能够满足不同的客户需求。软交换设备应该是纯软件的、基于 Java 的，其组件是运行于标准硬件上的；能够将符合工业标准的信令协议转化成通用的呼叫信令格式，从而对特定的协议进行抽象；应该为新应用原型的快速创建提供 API ，同时应该提供免费的协议处理功能。

基于策略的软交换管理系统从管理的视角看，软交换应是分布式的、可伸缩的软件系统，其主要目标是建立一种业务创建环境，且应该遵循如下几个设计原则：

可伸缩性或分布式原则：各种管理组件应该分布在网络的不同位置；

对象的抽象原则：具有相同语义的事件应该被策略编写人员抽象为相同的事件；

内部监测和故障容限原则：管理层应该具有故障免疫能力和自监测机制；

扩展性原则：系统应能快速生长，从而支持新设备的部署。

策略描述语言（ PDL ） 在 PDL 策略中，策略规则命题的表达形式如下：

event causes action if condition 策略规则读作：如果在给定条件下发生某种事件，则执行该动作；策略定义事件 (pde)命题表达形式为：

event triggers pde(,…, ) if condition 策略定义事件命题则读作：如果在给定条件

下发生某种事件则触发该事件定义策略 pde 。

策略描述语言（ PDL ）在 PDL 语言中，有一套固定的原事件符号。如果运行在策略机上的策略服务观察到原事件实例的预设事件流后，便会做出策略决定。这里，称事件实例流为“事件历史记录”。同时发生于一个事件流中的原事件实例的集合则称作一个“并发事件集合（ epoch ）”。事件的文字表示可以是一个原事件符号“ e” 来表示。 “ !e”表示在并发事件集合中没有事件“ e” 的实例。采用标准的点“ .”表示一个事件的属性。

策略描述语言（ PDL ）定义 1：基本事件的表达形式为：

e&......&e表示在当前的 epoch( 并发事件集合 ) 中发生了从 e到 e 的事件实例（即，模仿n 个事件的发生），这里 e 是一个事件代码。

e︱ ...︱ e表示在当前的 epoch 中发生了一个事件实例 e， e 是一个事件代码。定义 2：一个复杂事件可以是一个基本事件，或者一组事件（用 group(E)表示），这里 E是一个基本事件，即 n 个事件 E，…， E 的一个序列，事件“ E” 前加上“ ^”即“ ^E”（或者用（ E ）表示），则表示事件 E 的零或多个发生序列。

策略描述语言（ PDL ）策略规则的条件是一系列表达式“ tθt’” 的断言 (predicate) 。t和 t’ 可以是出现在规则的事件部分的原事件属性，也可以是常数，或者是对出现在该事件中的原事件属性进行操作结果。θ 是比较操作符（如 < 、＝、 > 等）。“聚合器 (aggregator)” 是一类特殊操作符，可被用作表示项。对于一个“通用的”聚合器 Agg 来说，该操作符的句法为 Agg(e.x,e.xθt)或者 Agg(e) 。

策略管理系统的体系结构

管理系统体系结构简介 消息流程典型装置故障恢复处理与系统升级

管理系统体系结构简介

事件管理进程

数据协调器

/业务视图管理进程

设备号码薄 数据库

LCDS

设备聚合器SNMP主控

HP OpenVi ew

Snmp

策略执行引擎

P0 P1 P3

PEP策略使能点（ ）

SNMP子代理

(EF)事件过滤器

(AE)动作估价器

设备接口

SNMP子代理

设备接口

Stys/Snmp

Stys

Stys

网络组件网络组件

注册业务

(AE)动作估价器

(EF)事件过滤器

PEP策略使能点（ ）

管理系统体系结构简介基于策略的管理系统分为三层：策略使能点(PEP) 、聚合器和策略引擎，而且这三者都通过目录协调器载入或储存各自的状态信息。上述三个层面建立在一个业务节点的基础层面上。业务节点就是一个能动态加载的业务包装器(wrapper) 并且能够运行任意多个业务，而且后者是符合业务接口的 Java类。关于业务接口的说明如下图所示：

业务接口publ i c i nterface Servi ceI nterface{/ **Thi s method i s cal l ed by the housi ng Servi ceNode(whi ch i tsel f has the arg)upon i ni t i al i zat i ong*/voi d setServi ceNode(Servi ceNode aServi ceNode)；/ **Cal l ed when a sessi on i s opened wi th thi s Servi ceI nterface*/voi d onOpen (Sessi on aSessi on);/ **Cal l ed when a sendMessage i s made to thi s Servi ceI nterface*/voi d onMessage(Sessi on aSessi on, Stri ng aMessage);/ **Cal l ed when a cl ose i s made to thi s Servi ceI nterface coul d be avi od onAbnormal Cl ose(Sessi on aSessi on);}

业务接口图示说明了应用如何变成来自网络上任何地方的可接入业务。业务节点屏蔽了在同一业务节点内或运行于不同业务节点中的两个业务之间进行通信的复杂性。 实现机制：在加电启动后，业务节点读入其配置数据，然后加载并运行指定的业务。业务节点在运行中可以动态地加入和退出。上述实现机制非常适合进行日志交换和冗长代码调试变更，而且更重要的是能够在运行着的系统中加载或卸载策略。

管理系统体系结构简介策略使能点 (PEP) ：是为每一个必须获得“策略使能”的硬件 / 软件设备创建的策略使能点。从广义上来说， PEP 是设备之下的代理，并且由运行于其内部的业务进行详细地描述。PEP 包括事件过滤器（ EF ）、动作评价器（AE ）和 SNMP子代理。EF 能够将来自指定网络元素的“全局事件”聚和 /翻译 /映射为“策略事件” 。AE 能够执行被指定为一个 URL 的本地或远端动作来改变该 PEP 正在管理的全局对象的属性。

管理系统体系结构简介为了收集性能和错误统计数据， SNMP子代理向聚合器报告设备的健康状态，并且能按命令改变设备的配置情况，提供额外的通道。PEP 的优点：

一个指定语义的事件可以由不同的设备 /供应商以不同的形式唤醒，但为了编写一个策略则必须抽出这些差异 ；

被来自一个设备的几个低层事件组成一个单一的策略事件唤醒 ；

可以唤醒一些不是由所连接的设备产生事件。

管理系统体系结构简介聚和器形成下一层，并且聚合 PEP ，向外部的 SNMP 管理进程和策略编制者提供软交换机的单一示图。一个聚合器业务节点在其内运行下面两种业务：

设备 /事件聚合器：对策略引擎提供事件注册和通告业务，并在策略规则点火后将动作选路到各个不同的 PEP ；

SNMP聚合器：允许用户通过让操作员查询一个单点来查询网络的全局示图和获取包含在当前配置的管理层中的所有组件的信息。

管理系统体系结构简介

策略引擎 (PE)： PE 业务节点根据其内部的不同业务运行策略，为每个策略提供一个独立的环境。 通信目录服务器（ LCDS ）是 PEP 、聚合器和 PE 三层所使用的公共组件，它为持久存储提供了一个独立于层次的平台和接受数据访问的 Java或 LDAP 接口。

消息流程策略的执行主要包含三个步骤：

事件注册；事件通告；动作执行 事件注册：策略文件的第一个模块包括一系列该策略希望作用的各种设备不同事件的声明，声明模块被转换为一系列的注册事件存储在设备所对应的PEP 中。 事件通告：注册阶段结束后，策略服务器不必做任何事情。仅当特定事件在不同的 PEP 中被唤醒时，这些事件才会通过聚合器模块转送到对应的策略中。

消息流程动作执行：根据外部 / 内部事件，策略规则可能在某个时刻点火。在这点上，策略规则可以请求在一个或多个 PEP上执行动作。这些动作再次通过聚合器选路到各自的PEP 中。动作的执行有如下方式：

执行一个本地高速缓冲的方法； 动态地加载一个对象类并在其内部调用一

个方法； 接入一个远程的在网络某个地方的已知业

务，并且执行所需的动作。

典型装置在一个典型配置的软交换系统中，包括如下设备：

呼叫协调器、利用 SS7 协议连接到分组语音网关的 SS7 设备服务器、通过 H.323 协议连接到接入网关的 H.323 设备服务器和一个分布式处理监控器、用于产生时钟嘀嗒事件的可控定时器 PEP（ CTpep ）和能够将软交换内部告警转化为对应的 SNMP trap 并将其分发到多个网络控制中心的OVpep 。

典型装置为了对上面所述的典型配置进行管理，需要一些策略，具体描述如下：

告警监测 / 过滤策略：能够收集来自软交换内部处理的事件并将其转换为 SNMP trap发送到管理工作站；

突发错误计数策略：对突发错误事件进行计数并在突发结束时向管理节点报告一个客户化的事件（连同前一个突发错误计数值）；

夜间重载策略：能够在每天的午夜时分重新读取数据库，从而简化了每一个软件进程配置的内部重装。

典型装置

基于 DPC 的错误策略：能够维护基于DPC 的错误计数并周期性地向网络监管者进行上报；

故障恢复策略：能够控制进程的备份 。上述的策略代表了它们的模式，通过简单地复制就可以其它事件执行相似动作。

故障恢复处理与系统升级 监测 / 管理系统自身的软件故障监测的解决办法是：除了使最高层的软件具有高度的可靠性和可用性以外，监控系统也需要执行一定的自我监控程序。软交换的管理 / 监测系统的需求：极低的年故障中断时间；能进行不中断业务的系统升级。 为了满足上述两个需求，系统需要对两种故障情况做出正确的处理：组件故障恢复和系统故障恢复。

组件故障恢复策略管理系统中的三个核心组件是策略使能点 (PEP) 、聚合器和策略引擎。每一个组件的恢复规则如下：

如果某一组件自行消亡或者突然终止，则通过外部的监测脚本重新启动该组件；

如果组件不能找到它所需要的另一个实体，将进入重试模式并通过目录来更新该实体的位置；

如果在一规定的时间段内从其他设备上断开或者不能连接到其它设备， PEP将产生内部告警；

组件故障恢复聚合器维护在每个 PEP上执行事件注册状态；策略引擎通过聚合器监测连接状态，如果聚合器重新启动，则策略引擎在重建连接的同时重新加载策略；策略引擎通过目录来记忆需要运行的策略。为了支持基于组件的故障恢复，上面的规则需要相互作用。只有在 LCDS 发生故障时，系统才会不能执行“故障恢复”功能，否则将不会影响对稳态系统的操作。

通过备份硬件进行系统故障恢复

管理系统的所有处理过程都应该具有相应的硬件备份。进程实例的标记可以是主用的，也可以是备用的。而且，有两个 PEP 都指向设备服务器的“主用”实例。如果主用进程出现故障，相应的 PEP 就会产生一个断连事件，并通过内置的故障处理策略触发备用进程来替代主用进程。

通过备份硬件进行系统故障恢复

对于管理系统内部的故障，需要通过对等PEP （彼此交叉安装并通过一种保持在激活状态的协议来通信）的方式来处理。所有的事件注册和其它启动活动同时在主用和备用系统中执行（备用系统的策略引擎不能使策略状态机的状态前移）。如果不能连接主用的对等 PEP ，则备份的策略引擎开始工作。

四、两种网络和业务管理架构的特点

TOM模型的特点TOM模型对评价和分析当前用户的需要很有价值，它是建立一个连贯发展结构的必须步骤。在 TOM模型中，基于角色的建模方法使得能够以用户的观点来发展软件产品。利用 TOM 模型来指导软件开发将有助于我们开发出更加智能化的软件，进而使得业务供应商和用户不必理解网络底层的细节，可减少对网络和业务管理操作技术方面的大量培训代价。

基于策略的软交换网络管理模型

基于策略的软交换网络管理解决方案，可以使构成下一代网络的组件具有高度的可编程性，并且能够满足不同客户的需求，从而增强了软交换系统的价值。对于解决复杂的下一代网络的各种各样的智能管理问题，基于策略的解决方案是众多新方案中的一个，并且还有许多细节问题需要进一步研究解决。