2020年管理面数据采集在智能IP网络运维场景中的应用研究.pdf

管理面 数据采集在智能 IP 网络 运维 场景中的应用研究 2020 年 版权声明 本白皮书版权属于 SDN/NFV/AI标准与 产业 推进委员会 ，并受法律保 护。转载、摘编或利用其它方式使用本白皮书文字或者观点，应注明“来 源： SDN/NFV/AI标准与 产业 推进委员会 ”。违反上述声明，本联盟将追 究其相关法律责任。 前 言 本研究报告旨在 分析 管理面 数据采集应用的研究现状， 阐述当前 管理面 数据采集在智能 IP 网络 运维 场景 中应用 面临的问题和挑战，并给出 管理面数据采集三方管理架构，关键技术， 解决 方案和研究建议 。 目录 前 言 . 3 1 研究目标和应用场景 . 6 1.1 研究目标 . 6 1.2 应用场景 . 6 2 国内外研究现状分析 . 7 2.1 IP 网络智能运维数据采集与人工智能、 数字孪生、意图驱动网络的关系 . 7 2.2 IP 网络智能运维数据采集技术分析 . 8 2.3 管理面数据采集技术研究现状 . 8 3 管理面数据采集在 IP 网络智能运维面临技术挑战和问题 . 9 3.1 海量数据采集和处理的挑战 . 9 3.2 数据处理和存储的挑战 . 9 3.3 集中管控面对网络事件快速响应的挑战 . 10 4 管理平面 MDT 三方管理参考架构 . 11 5 MDT 三方管理数据采集关键技术 . 13 5.1 运维数据自动标注技术研究 . 13 5.2 自适应变频采集技术研究 . 18 5.3 基于事件驱动的订阅数据采集技 术研究 . 20 6 IP 网络智能运维场景 MDT 三方管理解决方案 . 25 6.1 运维数据自动标注方案举例 . 25 6.2 变频采集方案举例 . 26 7 总结和后续工作展望 . 27 7.1 当前研究总结 . 27 7.2 后续工作展望 . 28 8 参考文献 . 28 9 作者列表 .错误 !未定义书签。 图目录 图 1-1 管理面数据采集应用场景分类 . 7 图 3-1 海量数据采集和处理 . 9 图 3-2 数据处理和存储挑战 . 10 图 3-3 网络事件快速响应 . 11 图 4-1 MDT 三方管理架构 . 12 图 5-1 OPM 模型剖析 . 13 图 5-2 运维数据标记模型结构示图 . 17 图 5-3 IETF 定义运维标记分类 . 18 图 5-4 WLAN 性能质量监控场景下数据采集策略定义举例 . 19 图 5-5 变频采集订阅模型结构示图 . 19 图 5-6 变频采集通知模型结构示图 . 20 图 5-7 基于事件驱动数据采集示例 . 20 图 5-8 ECA 策略管理模型剖析 . 21 图 5-9 ECA 模型结构图 . 23 图 5-10 ECA 策略管理典型案例 . 24 图 6-1 运维数据标记在 IP 智能运维场景下解决方案举例 . 25 图 6-2 变频采集在 IP 智能运维场景下解决方案举例 . 26 图 7-1 MDT 关键技术相关 IETF 标准工作汇总 . 28 表目录 表 1 对象名举例 . 14 表 2 属性名举例 . 15 表 3 指标名举例 . 16 1 研究 目标和应用场景 1.1 研究 目标 ALL IP 化是未来网络和业务发展的趋势 ， 随着 IP 化 网络的规模和复杂度与日俱增 ,尤其是 IP 网络承载的应用越来越多 , 带宽和流量持续增长 ， 越来越多的领域出现了对海量、高速到达 的数据实时处理需求 ， 如何从浩瀚的 数据海洋 中挖掘有用的知识变得尤为重要。 与此 同时 ， 用 户对 IP 承载网络的 运维 管理 提出了更高的要求，包括监控数据拥有更高的精度以便及时检测和 快速调整微突发流量，同时监控过程要对设备自身功能和性能影响小以便提高设备和网络的利用 率。 另一方面 ，随着应用容器化和微服务的兴起，借由 Docker 和 Kubernetes 等工具， IP 网络承载的 服务的快速开发和部署成为可能，构建微服务应用变得越来越简单。但是随着大型单 体应用拆分为微服务，服务之间的依赖和调用变得极为 复杂。这些服务可能是不同团队开发的， 可能基于不同的语言，微服务之间可能是利用 RPC、 RESTful API，也可能是通过消息队列实现 调用或通讯。如何在这样的 分布式 环境下快速 调试 、追踪 IP 承载 服务 的 处理耗时、查找服务性 能瓶颈、合理对服务的容量评估都变成一个棘手的事情。 本项目研究目标是从当前传统 IP 网络运维 面临的问题和挑战出发 ， 阐述管理面数据采集 IP 网络智能运维场景中的应用价值 。 本报告分析数据采集的分类 ， 数据采集与人工智能 ，数字孪生， 意图驱动网络的关系 ， 数据采集技术现状和挑战 ， 提出模型驱动数据采集三方管理 关键技术 ，实 现精准定向自适应数据采集， 有效减少数据上送量 ， 降低数据传输 、 存储 、 分析的成本 ,提供一 种高价值、 低成本 、 易对接的数据采集技术。 1.2 应用 场景 本研究报告提出的管理面数据采集方法是通用方法 ，可以采集不同 类型 网络设备 ， 不同层的 数据源（ 设备层、 网络层，应用层），不同类型的数据源（配置，状态，转发表等） ， 提供近实 时、全程、全量数据监测、上送 ，并进行 统一数据表达和呈现，构筑高价值的 基础 数据， 可以 应 用于 IP智能网络 运维 1-3-5主动运维场景 (1分钟故障感知、 3分钟故障定位、 5分钟故障修复 )， 网络配置变更验证场景 ， 网络参数 动态调优 等应用场景，也可以应用在分布式体系 ，微服务架构 场景解决故障跟踪，服务质量评估问题。 图 1-1管理面数据采集应用场景分类 2 国内外 研究现状分析 2.1 IP 网络 智能运维数据采集与人工智能、数字孪生、意图驱 动网络的关系 人工智能技术 在 IP 承载网络应用 之所以能取得突飞猛进的进展， 得益于 各类感应器和数据 采集技术的发展，我们开始拥有以往难以想象的海量数据，人工智能是基于大数据采集技术的， 运用于人工设定的特定性能和运算方式来实现的，大数据是不断采集、沉淀、分类等数据积累。 数据采集技术是连接大数据积累到人工智能的重要纽带 ,是在线计算 ， 在线分析的关键技术 。 如 果把 IP 网络 智能 运维 数据采集比作人的眼睛和耳朵，人工智能就是人的大脑。 意图驱动网络是基于 SDN网络架构构筑一个闭环系统， 通过高速大数据采集，掌握网络的实 时运行状况并及时发现网络中的变化 ， 确保用户意图和网络状态的高保真，做到 “ 网随意动 ” 。 IP 网络 智能运维 数据采集是构筑 SDN 网络闭环系统的 必不可少的重要环节 ， IP 网络 数据采集的 精度和性能决定网络随意动的用户体验。 数字孪生是因建模仿真技术而起、因传感技术而兴，并将随着新一代信息技术群体突破和融 合发展而发展壮大。数字孪生是综合运用感知、计算、建模等信息技术，通过软件定义，对物理 空间进行描述、诊断、预测、决策，进而实现物理空间与赛博空间的交互映射。目前数据孪生也 在逐步 向 IP 网络通信领域延伸 1， 数字孪生 中 数据基础、数据模型驱动、软件定义 三大 要素 在 IP 网络中赋予了新的含义 。 而 数据基础依赖 IP 网络 智能运维 数据采集技术构筑强大的数据底 座。 2.2 IP 网络 智能运维 数据采集技术分析 IP网络 智能运维 数据采集技术从数据源角度可以分为： 日志数据 性能数据 配置数据 状态数据 告警事件数据 Web数据 数据库数据 IP网络 智能运维 数据采集技术从采集 精度和速率角度，可以分为 秒级高速数据采集比如 Syslog日志 分钟级低速数据采 集比如 CLI， SNMP get 亚秒级高速数据采集比如 流采集 streaming Telemetry IP网络 智能运维 数据采集技术从网络层 ， 应用层角度 ， 可以分为 网络层数据采集 比如 IETF定义的 YANG Push 订阅发布机制 应用层数据采集 比如 Opentelemetry12定义的跟踪 API， 日志 API， 性能指标 API. IP网络 智能运维 数据采集技术从数据平面 ， 管理平面角度 ， 可以分为 数据面数据采集 比如 IOAM （ In-situ OAM） 14， iFIT（ In-situ Flow Information Telemetry） 13随流检测 管理面数据采集比如 YANG Push订阅发布机制 ， MDT（ Model-driven Telemetry） 三方 管理数据订阅机制 2.3 管理面数据采集技术研究现状 IP 网络 智能运维 管理面数据采集基础协议分为 动 态订阅 ，静态 订阅两种模式 ， 目前已经发 布的标准主要是针对动态订阅场景 ，或者称为 Dial In（网管发起设备纳管） , 是 网管发起订阅 的采集 ： RFC86398提供了动态订阅场景下对数据流订阅和发布机制 ， 实现一次订阅 ， 多次发布 RFC86419提供了动态订阅场景下对数据集的订阅和发布机制 ; RFC8640 10和 RFC865011还为 IETF定义的订阅发布机制提供了 NETCONF， RESTCONF 传输协议支持 。 为了进一步实现静态订阅场景 ， IETF目前正在定义数据采集传输安全，可以广泛应用在 Dial Out(设备主动发起纳管 流程 )场景，实现对 TLS， SSH， HTTPS 等传输协议安全参数的配置，目前 传输安全标准已经稳定，即将进入标准发布环节。 相比传统 SNMP网络设备数据采集 方法 ， IETF基于模型 驱动 的管理面数据采集 方法 （比如动 态订阅，静态订阅） 实现了 从网管系统 发起 查询的 PULL模式 ， 到 基于网络设备 发起的 主动 PUSH 模式 转变 ， 从分钟级的采集 精度提高到 秒级 的精度 。 随着采集精度和广度的增加，也使得采集的数据有了上百倍的增加， 但是 采集精度不准确的 情况，仍旧需要进一步优化 : 进一步提高 采集的精度 ， 比 如亚秒级 采集数据本地预处理 ， 提高采集数据 集中 上送的有效性 ，在 采集数据源头过滤无效 采样 数据 采集数据 快速响应 ，分布式 本地 快速处理 ，实现设备小闭环系统 可以基于事件驱动 Telemetry上报 ,其中事件可自定义； 3 管理面数据采集 在 IP 网络智能运维 面临技术 挑 战和问题 3.1 海量数据采集和处理的挑战 当前 网络层管理面数据采集技术已经可以实现秒级 ， 毫秒级数据采集精度 ， 但是面对 海量数 据采集和处理 ， IP 网络 智能 运维管理平面 仍旧 面临 巨大的 挑战 ， 比如 数据上送通道负载过重 ， 即使网络运维管理平面能够应对数据上送通道瓶颈的挑战，如何从海量数据挖掘高价值的特征数 据，这是大数据采集面临的主要难点。 图 3-1海量数据采集和处理 3.2 数据处理和存储的挑战 相对于 SNMP（ 5分钟采集精度）数据采集 ， 秒级，毫秒级网络层管理面数据采集，数据量成 本增加了 100 倍 ，导致了分析器部署的成本压力非常大。为了应对这一挑战，在很多大规模 IP 智能运维 数据采集应用场景，可以允许设备和分析器支持多个不同采样周期，但是如果总是设定 为高频采集，高频采集对采集通道是一个巨大的压力，浪费了大量的处理器资源，如果总是设定 为低频采集，采集的数据量有限，往往导致很多网络故障无法发现，定位和修复。 图 3-2数据处理和存储挑战 3.3 集中管控面对网络事件 快速响应的挑战 在 IP 网络性能监控过程中，或者 IP网络故障 跟踪管理 过程中，当性能指标或者 IP网络故 障指标超出网络预先设定的门限，网络设备会触发对网络事件的上报，这些 IP 网络事件往往上 报给统一的集中管控平面 ，由统一的集中管控平面对上报的事件进行处理，触发响应的动作， 该 动作会进一步触发新的网络策略的下发。但是从事件上报到新的网络策略 下发往往需要经历很长 的处理时间，虽然能够 实现对网络故障的闭环管理，但是往往很难实现对网络事件的快速响应， 导致这一类的网管故障无法及时发现，恢复。 图 3-3网络事件快速响应 4 管理平面 MDT 三方管理参考架构 MDT三方管理是运营商网管系统对接不同厂商设备 ， 基于模型驱动数据采集机制 实现对不同 厂商设备的管理 。 为了应对 管理面数据采集在 IP 智能运维中的 挑战 ， 本报告提出一套管理平面 MDT 三方管理 参考架构 ， 如图 4-1所示。 该架构主要由设备平面 ， 管控平面 ， 网络运维管理应用平面三部分组 成 ： 设备平面：包含数据存储层，数据建模层，数据生产层，数据输出层。 数据存储层可以支持不同设备，不同版本，不同种类的数据源 数据建模层对 IETF YANG模型， Openconfig YANG, Native YANG的建模 数据生产层提供自动标记，自动变频采样，自动数据预处理能力通告，自动能力通 告支持 数据输出层支持二进制， XML, JSON不同数据编码格式，支持 TCP， UDP,GRPC,安全 传输不同传输的支持 ; 管控平面 ： 包含采集器层 ， 采集管理层 ， 分析器层 采集器层实现对指定数据订阅 ， 对设备发布数据的接收 ; 采集管理层实现对数据的存储以及对设备采集的配置管理 分析器层实现对数据加工包括过滤 ， 压缩 ， 关联 ， 推理分析 。 网络运维管理应用平面 ：多种第三方运维应用，例如可视化运维应用及网络调优等 图 4-1 MDT三方管理架构 模型驱动的数据采集 是基于 YANG 模型对数据采集对象 ，网络的配置和状态 进行 建模设计 ， 根据模型自动化工具生成数据采集的 API，实现对 YANG 模型建模对象的采集 。 管控 平 面和设备 平 面之间 ， 通过 模型驱动 数据采集三方管理协议机制 ， 支持 ： 基于运维数据标记 ， 提供精准数据采集 基于不同数据质量 ， 实现高频 ， 低频变频数据采集 基于 Event驱动 ， 提供事件驱动数据采集 ; 5 MDT 三方管理数据采集 关键技术 5.1 运维数据自动标注技术研究 图 5-1 OPM 模型剖析 运维数据自动标记主要的思想是对运维管理数据 进行 分类， 从特征数据角度，将其 分为对象， 属性，指标三类特征数据 （见图 5-1） ; 对象是 特性中的实体对象，每个特性至少一个根对象，每个对象归属唯一服务 ; 属性 是 对象的属性，一个对象可以有多个属性，也可以没有属性（如容器类对象） ; 指标是 对象的指标，每个指标归属到一个唯一服务 ; 关系是 各 OPM元素之间的关系，允许跨特性，如果没有，可以不必定义关系。 特性是一组相 关对象、属性、指标的集合，特性划分与服务实现划分解耦， 服 务划分变更时， OPM模型 可以 保 持稳定，仅涉及 服务 归属变化。 以下表 1，表 2，表 3分别给出对象，属性和指标的举例说明。 表 1对象名举例 表 2属性名举例 表 3指标名举例 除此以外，运维数据自动标记还可以对运维管理数据从其他角度进行分类，比如 1. 对于性能指标 数据，操作类型标记可以用来 对 KPI 性能指标标识最大值，最小值，平均值， 求和， 阈值 常量，精度范围，取值范围 ; 2. 数据源标记可以将运维管理数据按照数据源划分为 资源类 数据 ，连接类 数据 ，策略类 数据 ， QoS 类 数据，硬件类数据 ; 3. 业务标记可以将运维管理数据按照业务类型划分为 隧道业务类型数据， L3VPN业务类型数 据 ， L2VPN 业务类型数据 ; 4. 任务标记可以将运维管理数据按照任务类型划分为 故障诊断任务数据，业务发放任务数据， 业务保证任务数据 ; 5. 多源汇聚标记可以将运维管理数据 ， 主要是性能指标 KPI 数据按照多源汇聚类型分类 ， 划 分为成员和汇聚两种类型 ; 运维数据自动标记定义在 IETF标准草案 2。 针对运维数据自动标记 , 2定义了 一种数据 节点标记 YANG模型 ， 该模型基于 YANG Extension Statement定义了 9种不同的运维数据标记， 分别代表性能指标标记，操作类型标记，指标精度标记，指标范围标记，指标组标记，业务标记， 任务标记，多源汇聚标记，数据源标记。 同时 ， 允许对 9种不同类型的标记进行标记管理，允许用户在模型设计阶段 ，或者模型实现 部署阶段添加运维数据标记，同时用户自由的从设备中删除设备模型中定义的数据节点标记， 另 外 9种标记不必同时支持 ; ietf-data-object-tags 模型是基于 ietf-module-tags 模型基础上 ， 扩展支持对数据节点 标记对象的增加和删除 ， 具体模型结构如下 ： 图 5-2运维数据标记模型结构示图 该报告以 example-ifm模型举例 ， 介绍如何用数据节点标记模型中定义各类运维数据标记对 example-ifm模型中的特征数据进行标注 ： module example-ifm /. import ietf-data-node-tags prefix ntags; container interfaces ntags:opm-tag “ ietf:object-type”; list interface leaf ifName type pub-type:ifName; ntags:opm-tag “ietf:property”; leaf ifStatiEnable type boolean; container ifStatistics ntags:opm-tag “ietf:metric”; leaf receiveByte type uint64; ntags:operation-type “ietf:sum”; 从这个举例可以看到 ， example-ifm 模型引用了 ietf-data-node-tags 模型 ， 基于 ietf- data-tag模型中定义的 OPM 标记和 operation-type标记对 example-ifm中接口对象 ， 接口名称 属性 ， 接口统计进行标记 ， 同时标记 统计参数的 操作类型 ; 为了在厂商之间形成一套统一运维数据标记标准 ， draft-tao-netmod-yang-node-tag2对 运维数据标记格式进一步进行定义 ， 比如 运维数据标记 采用 “ietf: ” 前缀代表 IETF 定义的前 缀 ，运维数据标记采用 “vendor: ” 前缀代表 vendor 定义的前缀 ， 运维数据标记采用 “user: ” 代表 用户定义的前缀 。 以下表格给出了 IETF定义 ， 采用 “ietf: ” 前缀 的 运维数据标记 ： 图 5-3 IETF定义运维标记分类 5.2 自适应变频采集技术研究 目前网络层数据采集技术支持周期数据采集和增量变化数据采集两种方式，周期数据采集需 要在采集器和网络设备协商固定的周期订阅采集周期，一旦选定 采集周期，数据采集将按照固定 采集频率进行数据采样，而增量变化数据采集， 是在采集对象状态发生变化或者对采集对象的操 作类型（比如增加，删除，修改）发生变化 时 ，触发变化数据上送，或者变化操作类型上送。 当 数据变化非常频繁 时 ，对数据上送通道将是一个巨大的负载挑战。 变频采集假设采集器和网络设备支持多个采集周期，并可以不同的条件满足情况下，切换 到不同的采集周期 ，当采集周期切换时，网络设备会立即通知采集器周期发生变化。 典型的应 用场景是 WLAN网络性能监控场景 （如图 5-4） ， WLAN 信号强度 RSSI比较高的情况下 （比如大 于 -65dB） ， 一般网络质量是稳定的 ， 可以采用低频采集 (比如数据上送周期设为低频 60s)， 少 采一些数据 ； WLAN信号强度 RSSI比较弱的情况 下 (比如小于 -65dB)， 如果采集的数据不够的 话 ， 很难进行故障定位 ， 所以在 WLAN信号弱 时 ， 可以采用高频采集 (比如数据上送周期设为高 频 10s)， 多采一些数据 。 图 5-4 WLAN性能质量监控场景下数据采集策略定义举例 为实现变频数据采集，需要设计变频数据采集订阅策略，订阅策略包括采集周期，上报周期， 条件表达式，条件表达式关联的采集对象，采集对象 阈值 几部分组成，针对 每一个条件表达式可 以设置一个采集对象 阈值 （也可以看成 水线），以及对应的采集周期和上送周期，上送周期是采 集周期的整数倍。变频采集订阅策略是基于 IETF定义的 YANG Push定义发布模型所做的扩展 ， 在支持周期订阅和增量订阅同时 ， 增加了一种新变频采集订阅 ， 具体模型设计如下 图 5-5 变频采集订阅 模型结构示图 当网络设备完成采集周期切换，网络设备需要触发采集周期变化通知上报，具体模型设计如下： 图 5-6变频采集通知模型结构示图 从采集周期变化通知看 ， 该通知内容 包括变化后的采集周期 (period)， 上送周期 (anchor- time)，以及变化后采集周期影响的数据集中的数据对象 (datastore+selection filter); 5.3 基于事件驱动的 订阅数据采集技术研究 基于事件驱动的订阅数据采集主要是监控和跟踪特定采集对象状态的变化 ， 当采集对象的状 态变化满足一定条件的情况下 ， 可以出发不同的动作 ， 实现设备自组织管理 ， 比如自我监控 ， 满 足一定条件的情况下 ， 实现满足条件的采集对象集合对象的状态上报 ， 进一步也可以触发设备对 故障的自我管理 ， 实现故障的自愈 ， 但只局限于设备级的故障事件的修复 。 图 5-7基于事件驱动数据采集示例 draft-wwx-netmod-event-yang-09 草案 3提出 ECA模型 ， 该模型对策略变量 ， 事件 ， 条件 ， 触发动作进行建模 ，策略变量是指定跟踪的采集对象，策略变量可以用来表达事件，满足条件， 触发动作，分为策略变量源，策略变量结果，策略变量源可以是指定采集对象的 XPATH路径，也 可以是常量，或者矢量数组结构体，策略变量结果可以是常量，或者是矢量数组结构体，事件对 象包括几类事件，比如数据集事件，由数据集名，数据对象路径两部分组成，服务器事件，由事 件流，对应的 YANG 模型名称，对应的事件对象组成，另外还可以是定时器事件，可以用来制定 采集周期，故障诊断事件，可以用来调试对应设计的标准 API函数 ，条件，用来表达被跟踪的采 集对象所满足的条 件，比如网络拓扑对象 T中对应链路 L所对应的 TE Metric大于 100， 可以表 达为 ： /nw:networks/nw:networknetwork-id=T/nt:linklink-id=L/tet:te /tet:te-link-attributes/tet:te-delay-metric 100 比如 网络拓扑对象 T中对应链路 L所分配的带宽大于策略变量 B的 75%， 可以表达如下 ： /nw:networks/nw:networknetwork-id=T/nt:linklink-id=L/tet:te /tet:te-link-attributes/tet:max-resv-link-bandwidth (ietf-eca:policy-variables/policy-variablename=B/value) * 0.75 动作目前支持两种动作 ， 一种是事件通知上报 ， 另一种是采集周期切换或者选择 ； ECA 策略管 理由事件，条件，动作三要素共同组成。 图 5-8 ECA策略管理模型剖析 ECA 模型结构如下所示： module: ietf-eca +-rw gncd +-rw policy-variables | +-rw policy-variable* name | +-rw name string | +-rw (xpath-value-choice)? | +-:(policy-source) | | +-rw (pv-source) | | +-:(xpath-expr) | | | +-rw xpath-expr? yang:xpath1.0 | | +-:(scalar-constant) | | | +-rw scalar-constant? string | | +-:(nodeset-constant) | | +-rw nodeset-constant? | +-:(policy-result) | +-rw (pv-result) | +-:(scalar-value) | | +-rw scalar-value? string | +-:(nodeset-value) | +-rw nodeset-value? +-rw events | +-rw event* event-name | +-rw event-name string | +-rw event-type? identityref | +-rw policy-variable* - /gncd/policy-variables/policy- variable/name | +-rw local-policy-variable* - /gncd/ecas/eca/policy-variable/name | +-rw (type-choice)? | +-:(server-event) | | +-rw event-stream? string | | +-rw event-module? string | | +-rw event? | +-:(datastore-event) | | +-rw datatore? string | | +-rw data-path? string | | +-rw data? | +-:(timer-event) | | +-rw time-schedule! | | +-rw period? centiseconds | | +-rw count? uint16 | +-:(diagnostics-event) +-rw conditions | +-rw condition* name | +-rw name string | +-rw (expression-choice)? | +-:(xpath) | +-rw condition-xpath? string +-rw actions | +-rw action* name | +-rw name string | +-rw action-element* name | | +-rw name string | | +-rw action-type? identityref | | +-rw (action-operation)? | | +-:(notify-operation) | | +-rw notify-operation | | +-rw name? string | | +-rw policy-variable* name | | +-rw name string | +-rw time-schedule! | +-rw period? centiseconds | +-rw count? uint16 +-rw ecas | +-rw eca* name | +-rw name string | +-rw username string | +-rw event-name string | +-rw policy-variable* name | | +-rw name string | | +-rw (xpath-value-choice)? | | | +-:(policy-source) | | | | +-rw (pv-source) | | | | +-:(xpath-expr) | | | | | +-rw xpath-expr? yang:xpath1.0 | | | | +-:(scalar-constant) | | | | | +-rw scalar-constant? string | | | | +-:(nodeset-constant) | | | | +-rw nodeset-constant? | | | +-:(policy-result) | | | +-rw (pv-result) | | | +-:(scalar-value) | | | | +-rw scalar-value? string | | | +-:(nodeset-value) | | | +-rw nodeset-value? | | +-rw is-static? boolean | +-rw condition-action* name | | +-rw name string | | +-rw condition? - /gncd/conditions/condition/name | | +-rw action? - /gncd/actions/action/name | +-x start | +-x stop | +-x next-action +-rw eca-func-libs +-rw eca-function* func-name +-rw func-name string +-rw eca* eca-name +-rw eca-name - /gncd/ecas/eca/name 图 5-9 ECA模型结构图 下面举一个 ECA 策略管理的典型案例 ， 比如监控 ietf-interfaces 模型中接口对象 ， 每 5 秒钟扫描指定类型的接口上的收到的错误计数器统计信息，连续 扫描 60秒 ，当满足特定 条件时， 返回匹配条件的接口统计条目信息： ECA策略设计如下，该策略由网管下发给制定的网络设备 event-name interface-self-monitoring event-type server-event event-stream NETCONF event-module ietf-interfaces event if:interfaces/if:interfaceif:type=if:gigabitEthernet interface-self-monitoring server-event NETCONF ietf-interfaces if:interfaces/if:interfaceif:type=if:gigabitEthernet if-monitoring-condition event/statistics/in-errors 1000 if-matched-statistics 5 12 interface-eca-handling interface-self-monitoring sustained-event if-monitoring-condition if-matched-statistics sustained-event interface-eca-handling 图 5-10 ECA策略管理典型案例 6 IP 网络 智能运维 场景 MDT 三方管理 解决方案 6.1 运维数据自动标注方案举例 图 6-1 运维数据标记在 IP智能运维场景下解决方案举例 1.基于 IETF 定义的运维数据标记标准 2，对已经部署的设备 YANG模型比如 BGP 模型，接 口管理模型， IP 地址管理模型定义运维数据标记，标识运维数据的 性能指标 ; 2.基于 IETF 定义运维数据标注服务器能力通告技术 7，对 性能指标 相关的采集对象进行 能力通告 3.采集器根据 RFC8641 定义的订阅发布机制 ， 对 性能指标相关的数据采集对象进行定向数 据 采集 4.多指标，多维数据上报 6.2 变频采集方案举例 图 6-2 变频采集在 IP智能运维场景下解决方案举例 1. 基于 IETF定义数据传输服务器能力通告技术 6，对指定采集对象具有的 阈值 处理功 能，以及那些采集对象支持多个采集周期进行通告 ; 2. 采集器根据数据传输能力通告编排变频数据采集订阅策略 ； 3. 采集器根据 RFC8641定义的订阅发布机制 ，通过 对动态订阅消息扩展 ， 下发变频采集 订阅策略 4. 当设备切换采集周期时，设备自动生成采集周期变化通知消息，上送给网管； 5. 当设备采集周期确定情况下 ， 按照固定采集周期方式 ， 实现数据上送 ; 6.3 事件驱动的订阅数据采集案例 图 6-3 事件驱动 的订阅数据采集在 IP智能运维场景下解决方案举例 1. 基于 IETF定义数据传输服务器能力通告技术 6，对指定采集对象具有的 阈值 处理功 能，以及那些采集对象支持多个采集周期进行通告 ; 2. 采集器根据数据传输能力通告 编排 smart filer 数据采集策略 ; 3. 采集器 基于 ECA模型 3下发 smart filter 策略规则 ; 4. 当 smart filter 采样条件匹配时 ， 实现匹配条件数据上送 。 7 总结和后续工作展望 7.1 当前研究总结 本文从技术应用的角度对数据采集在 IP 智能运维场景方面的应用进行研究和思考。首先阐 述了数据采集的目标和应用，接下来对国内外研究的现状做了分析，然后 探讨了管理面数据采集 面临的挑战和难点，提出了 MDT三方管理参考架构 ，具体 阐述了运维数据自动标注关键技术，变 频数据采集，基于事件驱动的数据采集关键技术 。最后， 给出了运维数据自动标注，变频数据采 集在 IP 智能运维场景应用的解决方案案例。 7.2 后续工作展望 图 7-1 MDT关键技术相关 IETF标准工作汇总 本文从具体应用场景的实际情况阐述了数据采集在 IP 智能运维方面能够起到的作用，可以 看出对网络智能运维而言， MDT三方管理数据采集对实现高价值数据采集，减少数据上送， 以及 实现跨厂商对接起到至关重要的作用。但是，本文中列举的案例，对于 数据传输服务器能力通告， 运维数据标记能力通告，批处理订阅数据采集， ECA在自愈场景下的应用 未展开描述。建议本组 的下一步工作可以在以上方面进行展开研究 。 8 参考文献 1 Zhou, C., Yang, H., and X. Duan, Concepts of Digital Twin Network, draft- zhou-nmrg-digitaltwin-network-concepts-00 (work in progress), July 2020. 2 Wu, Q., Claise, B., Geng,L., and Z. Du, Self Explanation Data Object Tags,draft-tao- netmod-yang-node-tags-05 (work in progress), July 2020. 3 Bierman, A.,Wu, Q., Bryskin,I., Birkholz,H.,Liu,X., and B. Claise, A YANG Data model for ECA Policy Management,wwx-netmod-event-yang-09 (work in progress), July 2020. 4 Wu, Q., Wei,S., Liang,G., and P. Liu, Adaptive Subscription to YANG Notification,draft- wang-netconf-adaptive-subscription-01 (work in progress), July 2020. 5 Wang,Z.,Wu, Q., Liu,P., and H. Cai, Bulk Subscription to YANG Event Notification,draft-wang-netco