初探数通网络开放可编程

炒香菇的书呆子

发布于 2021-03-16 15:12:33

9320

发布于 2021-03-16 15:12:33

网络运维面困难与挑战

行业趋势

5G时代，网络运维面临越来越多的挑战。从价值目标来说，网络运维是从节约成本到收益的转变，网络运维更像是流量管理。传统的网络运维是典型的“人流量”人工运维模式，具有半人工半自动化的特点，也在朝着全自动化的目标努力演进。网络运维首先要改变的是传统的思维方式，从开发运维分离到开发运维一体化。这就要求运营商运维部门具备DevOps能力，网络运维将从传统的CT运维走向多元化的ICT运维。

在云计算快速发展的时代，OTT通过云原生架构保障云服务体验的设计理念深刻影响了运营商的网络建设模式。无论是运营商强调云前自下而上的网络，还是自上而下的OTT网络，战略选择差异背后共同的驱动因素是企业的数字化转型正在加速云网络融合的需求。网络与云的融合意味着运营商和企业都需要根据自己的需求灵活定制，以满足未来的业务场景。

面临困难

在传统的“人流量”人工操作维护模式下，操作人员面临以下痛点：

运营商网络陷入多厂商设备管理的困境。厂商设备多元化是运营商和企业避免被套牢的长期策略。但是单个厂商控制器只能管理自己的网络设备，没有统一的接口标准与OSS系统集成。随着新设备的增加，适配效率取决于制造商的能力和响应速度，这限制了端到端网络服务自动化的发展。长期以来发展缓慢，已经成为业内公认的瓶颈。
新业务推出慢，周期短需要等半年，长的需要等一两年，不能满足新时代的要求。新业务推出缓慢的原因有很多，其中一个原因是新业务是以传统的开发和运维分离的方式推出的：运营商首先提出新的服务需求，各种设备厂商开发发布版本，运营商重新接受使用，整个过程持续很长一段时间。
网络设备适配和网络割接工作需要手动执行海量命令行脚本，容易出错。随着脚本规模的增加，其可维护性也持续下降，使得网络运维逐渐成为一个高风险职业。
显然，这种基于单一厂商配置和基线的网络管控理念已经不能满足运营商日益灵活敏捷的运维需求，开放可编程的多厂商网络管控解决方案应运而生。

图表 1 传统的“人流量”人工操作维护模式

数通网络可开放编程简介

面对网络运维的严峻挑战，开放可编程系统以YANG模型驱动为基础，提供了端到端的开放可编程能力：设备驱动可编程、网络业务可编程、开放设备和业务北向接口，并且提供了安全可靠的保障机制。

图表 2 适合人群

应用场景

多厂商设备快速适配

运营商和企业网络一般都有多厂商设备共存的场景(如多厂商5G站自动上线、多厂商CPE配置等)。缺乏统一的管理和控制。新设备集成慢，自动化程度低，开通周期长，成为端到端业务交付的瓶颈。开放式可编程系统通过YANG接口自动识别并读取设备的YANG模型文件，生成网元驱动包并加载到系统中，一天即可完成一个新的设备适配管，适配效率提高90%。

新业务快

新服务的推出依赖于OSS系统和厂商控制器的版本更新，受API接口集成不足、定制成本高的问题困扰，导致推出周期长，难以满足业务场景灵活变化的需求。开放式可编程系统支持自定义业务YANG模型和业务逻辑，自动生成北行API接口，实现与OSS系统的快速集成，完成设备和网络服务的添加、删除、修改和检查等操作。开发时间从6-9个月发布缩短到1个月按需发布，业务上线周期缩短80%。

网络变更可靠

存量网络运维存在大量业务迁移变更的诉求，基本依赖人工操作或命令行脚本，出错率高。海量脚本维护困难，网络变更风险高，正确率难以保证。开放可编程系统提供Dryrun、回滚、事务、并发等安全可靠机制保障，网络变更正确率提升到99.9%。

管控析全栈可编程

面对5G网络切片与智能运维的场景，基于用户自定义网络业务模型，除了实现业务发放可编程外，开放可编程系统还提供控制算路与智能分析可编程能力，最大程度支持运营商业务面向未来网络演进。

图表 3以Windows为例，客户对网络操作平台能力诉求

特性介绍

动态加载软件包

通过编写和加载软件包，实现新设备的快速纳管和新业务的快速构建。

图表 4 AOC开放可编程平台所需具备的架构和能力系统提供的软件包包括：

SND包：网元驱动包（Specific NE Driver Pkg），为开放可编程系统提供与网元交互的数据模型。该数据模型通常包含一个.py文件和若干特性的数据模型（YANG），前者用于定义网元的相关信息，如设备类型、厂商、连接信息等，后者描述了网元相关特性的数据结构。系统通过加载网元驱动包，可以和设备建立连接，进行数据查询和配置下发，实现设备纳管。支持的SND包类型包括：NETCONF SND、CLI SND、NETCONF&CLI双协议SND、RESTCONF SND和Customized SND（提供YANG到其它协议的通用驱动）。
SSP包：业务包（Specific Service Plugin Pkg），定义了完成一套网络级业务配置对应的数据模型。该数据模型通常包含一个Jinja2模板文件、一个Python映射脚本和业务YANG模型。其中：

Jinja2模板描述了业务的数据结构，并使用Jinja2语法完成了诸如插值、条件判断、循环等操作。
Python映射脚本描述了如何将用户提交的数据填充到模板，并映射到网元数据结构中。
业务YANG模型描述了业务的相关参数，按照业务输入，构建业务YANG模型。
系统通过加载业务包，可以进行业务配置下发，实现新业务的快速构建。

图表 5 Yang模型驱动

事务机制

系统提供了事务机制，配置变化支持在一个原子事务里提交，保证开放可编程系统中的数据和转发器的数据一致性。同一个事务里的数据会并发下发到多台设备，要么全部成功，要么全部回退，没有部分数据成功。

图表6事务机制:失败自动回滚，保障配置安全

数据一致性

开放可编程系统保存了下发到设备数据的副本，能够采集设备数据，发现设备数据和开放可编程系统上数据的差异并在界面呈现，可以以开放可编程系统为准或者以设备为准进行数据同步。

图表 7 数据一致性:多头管理及时发现

用户开放编程

支持RESTCONF和CLI等北向接口，支持基于Python脚本在开放可编程系统上开发新的能力。
支持模型驱动的编程接口。用户在编写SSP包（业务包）时，使用系统提供的EasyMap算法，只需要写创建流程，更新和删除都由算法比较计算得出，简化用户编程，降低开发难度。
支持YANG模型自动生成南向报文，提升驱动开发效率。