问题描述

技术背景

首先以运营商为例，放眼全球，大部分运营商都面临着收入下降、OPEX 上升的问题。同时，随着 OTT 对其市场份额的不断蚕食，越来越多的运营商将 OTT 作为其竞争对手，这些都促使了运营商要做网络转型。此时，运营商必然面临的问题是如何做到多网融合、多厂商协同以及快速高效地管理好融合网络；

在 5G 时代，所有人都预测 5G 将催生新的服务、新的业务。但纵观历史新业务的上线方式都是由运营商提出诉求，再由设备厂商去实现，其周期短则大半年，长则需要几年。而 OTT 推出新业务只需要几个月，这使得运营商和 OTT 完全无法平等竞争。业务上线慢原因众多，其中之一便是运营商和厂商之间存在一个 GAP，即运营商不懂设备，而厂商不懂运营商业务。如何消除这个 GAP 的影响，让运营商和厂商在各自熟悉的领域发挥最大的作用，快速开通新业务，这是急需解决的问题；

最后，厂商生产的产品具有普适性，即适用于大部分运营商。运营商希望系统能够和其业务需求以及企业文化相匹配，故而有定制的需求。例如某运营商将定制能力写入标书，或通过定制企业规范来实现。而从厂商的角度，客户的定制需求会产生大量的成本，因此，最好的方案就是提供可定制的能力，由客户自己完成定制的工作；

对于其他企业，云时代的到来同样面临相同的问题。云化是趋势，基础设施均有被云平台统一纳管的需求。同时云数据中心业务变更频繁对自动化有极高需求，这些需求都要求一个更开放的网络；

在传统的网络中，所谓的网络自动化指的仅仅是依赖模板机制形成命令行脚本，再通过网络管理协议让设备运行接收到的命令行脚本。它并没有改变与网络设备交互的方式。在具体的设备适配过程中，网络管理工程师们使用 Python 或 Perl 等脚本语言编写一段具体的，适用范围较窄的函数来实现一系列操作的自动化，也可以借助 Ansible 和 Puppet 这样的自动化工具来实现更为复杂的自动化任务。无论是自己写也好，借用自动化工具也罢，网络管理工程师们都需要逐一适配待支持的网络设备。脚本规模越来越大，其可维护性也持续下降，增加新配套所耗费的时间也会随之增加。随着万物互联时代的到来，新业务的上市时间（TTM）越来越成为了企业赖以生存的核心指标；

随着云计算商业化取得的巨大成功，“软件定义网络”（SDN，有时也称为“软件驱动网络”）这个之前只在学术圈流行的概念开始大放异彩。在 SDN 网络中，备受推崇的理念就是控制面和转发面的分离（即“转控分离”）。在理想的 SDN 网络中，集中控制器成了一个必不可少的基点。作为整个网络的大脑，它会收集全网拓扑，然后根据业务需求，全局计算出一条最优路径并通知路径途经的设备。当接收到业务报文时，这些设备就会按照集中控制器确定的路径转发报文。此时企业可通过控制面暴露出来的应用编程接口（API）直接操控网络设备的转发面，这也为现代的网络自动化铺平了道路；

在 “转控分离”的现代网络中，由于转发面和控制面的分离及控制面的集中使得网络自动化的对象由之前的“一对多”转为“一对一”。网络工程师们再也不用为设备适配操心了。得益于开源社区贡献的 PCEP（RFC 5440）、FORCES（RFC 5810）、BGP-LS（RFC 7752）及 NETCONF/YANG（RFC 6241/RFC7950），各软件厂商就可以构建一套符合行业标准的模型来描述被管理的对象，并以基于这些模型生成的 API 供自动化脚本或网络配置应用程序调用；

使用基于模型的 API 带来的好处显然易见：由于模型本身是与协议和编码规则解耦的，一套模型可以适配多种协议和编码规则。这为统一适配支持不同网络管理协议的网络设备提供了解决方案；

有了统一的设备适配方案，以前想做却做不了的事情就有了新的努力方向：
1）使用基于模型的 API，企业可以快速实现对全网设备的遥测，自动收集设备级和业务级网络运行数据，帮助网络运维工程师及时了解网络运行情况；
2）使用基于模型的 API 还可以帮助企业构建工具链，用以完成用户意图识别、自动业务发放、自动全网遥测和基于数据分析的自动网络调整及优化，从而实现意图驱动网络；

该笔记将记录：Huawei iMaster-NCE 业务开放可编程相关的内容，以及相关问题的解决办法。针对我们的场景，鉴于日后可能不太会接触相关的技术，所以这里仅简单了解；

解决方案

NCE 业务开放可编程基于 YANG 模型驱动的开放架构，以网元驱动包和业务包的的形式，使能网元层和网络层开放可编程，实现新设备的快速对接和新网络业务的快速构建；

NCE 业务开放可编程属于自动化引擎的一部分，它在 NCE 的整个开放编程体系中是形成闭环的关键一环；

在 NCE 的整体开放可编程能力中，包括了自动化、分析和意图三大块。其目标是打造全生命周期的开放可编程架构，匹配客户开放可编程诉求。其中 NCE 业务开放可编程是属于自动化引擎的一部分，它在 NCE 的整个开放可编程体系中是形成闭环的关键一环，相当于人体的四肢，是执行器，需要能够像手一样灵活，才能支撑由智简网络大脑驱动的自动化闭环能力；

原理简述

NCE 业务开放可编程的实现依托于两个关键软件包：网元驱动包（Specific NE Driver，SND）和业务包（Specific Service Plugin，SSP）。通过编写并加载两个驱动包，实现新设备的快速对接和新业务的快速构建；

简单说，业务开放可编程的目的是根据业务的需要来构建网络；

特性特征

设备能力开放
业务能力开放
业务屏蔽设备差异
多协议对接
批量配置
事务机制
业务冲突检测
安全审计

应用场景

支持跨厂商设备管理，快速对接第三方设备；
快速构建业务，自动生成北向接口；
南向支持 NETCONF、STelnet 两种协议的设备对接；

概念术语

设备原子驱动包（SND）

软件包的一种，为开放可编程系统提供与网元交互的数据模型；
该数据模型通常包含一个.py 文件和若干特性的数据模型（YANG）。

其中：
前者用于定义网元的相关信息，如设备类型、厂商、连接信息等；
后者描述了网元相关特性的数据结构；

业务包（SSP）

软件包的一种，定义了完成一条网络级业务配置对应的数据模型；
该数据模型通常包含一个 Jinja2 模板文件、一个 Python 映射脚本和业务 YANG 模型。其中：
Jinja2 模板描述了业务的数据结构，并使用 Jinja2 语法完成了诸如插值、条件判断、循环等操作；
Python 映射脚本描述了如何将用户提交的数据填充到模板，并映射到网元数据结构中；
业务 YANG 模型描述了业务的相关参数，按照业务输入，构建业务 YANG 模型；