1 / 64

第十七讲 下一代网络的管理 自学讲义

第十七讲 下一代网络的管理 自学讲义. 主要内容. 一、下一代网络的管理概述 二、基于角色的网络和业务管理架构 三、基于策略的网络和业务管理架构 四、两种网络和业务管理架构的特点. 一、下一代网络的管理概述. 下一代网络的管理概述. 网络和业务管理的演进 下一代网络和业务管理的目标. 网络和业务管理的演进. 电信网络正在从以语音为中心的电话网络向以数据为中心的、基于分布式计算的多业务网络演进，与之相适应，网络和业务的管理也必须进行变革。 现在的电信业完全以客户和业务为中心，且其运行简单灵活。

terena
Download Presentation

第十七讲 下一代网络的管理 自学讲义

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第十七讲 下一代网络的管理自学讲义

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

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

  4. 下一代网络的管理概述 • 网络和业务管理的演进 • 下一代网络和业务管理的目标

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

  6. 网络和业务管理的演进 • 目前网络和业务管理的现状是：任何一个厂商都不能单独满足所有业务供应商的要求。在日益复杂的异构网络顶部，运营商面对多种厂家的软件环境，需要一种以IP为中心的、多厂商的、多业务的网络管理架构。 • 创造由应用驱动的管理架构的方法： 鼓励应用的设计、开发和传送； 利用核心层的应用来刺激用户通过直接观察就可以理解的、相互能够通信的其它应用的出现。

  7. 网络和业务管理的演进 • 网络与业务管理的基本功能包括 ： 网络管理提供相关的操作，倾向于缩小各种单个网络单元间的差别并支持各种网络功能；还包括拓扑、配置、恢复、速度/连接测试、重选路由/重定向、协调、安全等功能； 业务管理的基本功能支持以客户为中心和以业务为中心的观点，包括账户供给、业务激活、业务层面规约管理和报告、业务质量(QoS)监测、计费等。

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

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

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

  11. TOM模型

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

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

  14. 业务、网络和元素的管理体系结构 • 该管理体系结构显示了一种简单的构建模块的观点： 应用程序分为四个层次； 说明跨越应用的网络基础部件的临界度，并提出与企业内部或外部的软件进行健壮性整合的需求。 特定的应用软件应当容易与构建模块进行适配，而且，垂直跨越水平边界的软件应该受到属主的健壮性检查。

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

  16. 实现管理架构的需求和推动力 • 实现管理架构的需求： 运行支持系统应该鼓励新业务的创建；应该更容易操作和维护；对进入运营商系统环境的专门集成技术的需求微乎其微。 • 从实现的观点看，高层的需求描述可以转化为三个基本的驱动力： 特性：提高简单性、灵活性，开放性和演进性； 战略蓝图：建立一种通用的架构战略和开发方式以方便多厂家解决方案和嵌入式系统的端到端整合；

  17. 实现管理架构的需求和推动力 • 关键组件和工具：提供一种快速填补业务和网络管理功能缺口的机制，而且能够避免那些不相容和重复的工作。 • 实现网络和业务管理架构的市场趋势： 增加管理应用智能及其适应性； 对那些看起来相互分离的应用进行整合，以满足商业和运营的需求。

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

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

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

  21. 应用是管理架构的动力

  22. 管理架构的实现 • 关于业务和网络管理架构，存在两种观点： 基于TMN/TOM模型的观点 基于应用模型的观点 • 基于TMN/TOM模型的分层架构非常清晰，强调了不同类型的应用和应用接口、通用数据模型、网络元素行为的分离（或抽象）分别具有不同的要求。

  23. 基于TMN/TOM模型观点的架构

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

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

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

  27. 基于TMN/TOM模型的架构的组成 • 网络和元素管理的“外壳”包括： “i-Engineer”应用是网络工程所关注的，它包括物理设备清单、插件、端口、物理电路安装和配置等； “i-Provision”应用将支持设备的排列、在业务供给过程中变换到网络元素、逻辑电路的修正以及事务化工作流程的管理； “i-Assure”应用支持端到端的电路监测、业务性能监测、业务告警表示以及电路、业务、客户或历史、趋势分析、周期性报告、业务层规约（SLA）一致性报告所造成的与网络相关的故障。

  28. 基于TMN/TOM模型的架构的组成 • 数据模型包括三种： 客户信息模型包括与特定客户信息进行接口的数据和处理行为； 业务信息模型包括业务提供商提供（通过业务目录）的所有业务的定义。 网络信息模型需要解决所有技术驱动的网络类型问题，如网络拓扑、被管理元素、子网络和业务流量描述符。

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

  30. 基于应用观点的架构

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

  32. 基于应用观点的架构的组成 • “i-Connect”应用通过三种方式从网络信息数据库中获取物理/逻辑端口和拓扑信息： 直接通过JDBC访问信息数据库； 通过“i-Engineer”（作为代理）间接访问数据库； 直接从网络元素中获取所有与网络相关的数据，而不用访问任何网络数据资料库。

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

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

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

  36. 基于策略的网络和业务管理概述 • 策略的实现方法如下： 利用C或Java语言编写的程序，通过SNMP（或其它内部协议）和modem池进行通信并自动设置参数。然而，这种方法需要大量的编程工作，且其策略很难改变。 通过一种书写简单但表达清楚的策略描述语言(PDL)来设计基于策略的网络管理系统。

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

  38. 基于策略的软交换管理系统 • 从管理的视角看，软交换应是分布式的、可伸缩的软件系统，其主要目标是建立一种业务创建环境，且应该遵循如下几个设计原则： 可伸缩性或分布式原则：各种管理组件应该分布在网络的不同位置； 对象的抽象原则：具有相同语义的事件应该被策略编写人员抽象为相同的事件； 内部监测和故障容限原则：管理层应该具有故障免疫能力和自监测机制； 扩展性原则：系统应能快速生长，从而支持新设备的部署。

  39. 策略描述语言（PDL） • 在PDL策略中，策略规则命题的表达形式如下： event causes action if condition 策略规则读作：如果在给定条件下发生某种事件，则执行该动作； • 策略定义事件(pde)命题表达形式为： event triggers pde(,…, ) if condition 策略定义事件命题则读作：如果在给定条件下发生某种事件则触发该事件定义策略pde。

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

  41. 策略描述语言（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的零或多个发生序列。

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

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

  44. 管理系统体系结构简介

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

  46. 业务接口

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

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

  49. 管理系统体系结构简介 • 为了收集性能和错误统计数据， SNMP子代理向聚合器报告设备的健康状态，并且能按命令改变设备的配置情况，提供额外的通道。 • PEP的优点： 一个指定语义的事件可以由不同的设备/供应商以不同的形式唤醒，但为了编写一个策略则必须抽出这些差异 ； 被来自一个设备的几个低层事件组成一个单一的策略事件唤醒 ； 可以唤醒一些不是由所连接的设备产生事件。

  50. 管理系统体系结构简介 • 聚和器形成下一层，并且聚合PEP，向外部的SNMP管理进程和策略编制者提供软交换机的单一示图。 • 一个聚合器业务节点在其内运行下面两种业务： 设备/事件聚合器：对策略引擎提供事件注册和通告业务，并在策略规则点火后将动作选路到各个不同的PEP； SNMP聚合器：允许用户通过让操作员查询一个单点来查询网络的全局示图和获取包含在当前配置的管理层中的所有组件的信息。

More Related