开源与标准的协作：ONAP进展

邓灵莉（中国移动，ONAP社区技术指导委员会副主席）;邓辉（华为，ONAP社区技术指导委员会模型子委员会主席）;Stephen Terrill（爱立信，ONAP社区技术指导委员会架构子委员会主席）

作为持续推动开放网络技术创新与产业力量融合发展的一部分, Linux网络基金会社区一直与通信网络领域各个标准组织保持着密切的合作,以期实现行业组织间的优势互补与高效协作。为此，2017年在Linux网络基金会成立之初发布的”协作2.0：开源和标准如何推动跨IT协作”和”统一电信领域开放源码与标准”白皮书中最早提出了加强开源与标准的协作倡议。
https://www.linuxfoundation.org/wp-content/uploads/2018/03/LFN_ONAP_HarmonizingOpenSourceStandards_03.23.18.pdf

以此为基础，2018年4月初发布的白皮书”协调开源和标准：ONAP案例研究”就与ONAP项目有关的标准组织和可能的合作模式进行了深入分析与初步探讨。
https://www.linuxfoundation.org/publications/2017/05/new-networking-harmonization/

本文则从开源社区和标准组织的角度更详细地阐述了这一进程中的进展和现状。我们以ONAP社区的业务场景/蓝图作为载体,从架构、模型驱动和API三个维度来对ONAP相关的行业标准和最佳实践展开叙述。希望通过分享我们迄今的经验与困惑,促进更多产业力量积极加入，为实现这一共同目标贡献智慧和力量。

ONAP用例

ONAP旨在建立一个通用的、业务无关的、模型驱动的自动化平台,支持各类通信业务网络基础设施服务的灵活设计、按需部署与智能运维。而传统的电信行业标准组织(或简写为SDO)则是依据传统网络设备所属的不同专业领域（比如，接入、传输、核心等）来进行分工的。因此,为了全面说明ONAP针对各个领域的用例/蓝图对接对应专业领域的SDO相关工作内容与进展情况，我们选择了以下4个典型的用例作为示例。

接入网业务用例：vCPE

vCPE用例面向家庭宽带业务场景。ONAP用于设计、实例化、配置和管理虚拟化业务的能力，包括高速互联网接入、IPTV和VoIP服务，也可以和其他宽带增值的云服务同时放在云端。

核心网业务用例：VoLTE

VoLTE用例面向移动核心网业务场景。ONAP 用于设计、部署、扩展和终止演进分组核心网（EPC）和IP多媒体子系统（IMS）网络服务。此外，ONAP还可以通过VIM和VNF的KPI指标监控服务状态，自动触发根因分析进行业务自动恢复。

传输网用例：CCVPN

CCVPN用例面向企业专线业务场景。ONAP用于设计、实例化、按需动态修改业务，为企业总部和分支机构等为其提供多站点的VPN连接、可以自动发现底层拓扑、按需增删站点和调整带宽，并可以面向站点提供一些增值业务功能，如防火墙，负载均衡或者业务链SFC以及边缘AI服务等。

端到端业务用例：5G

5G 用例团队首先从支持无线侧物理网络功能(PNF)自动注册、软件升级和数据采集等基础功能起步逐步完善,目前正在研究如何利用ONAP平台能力支持RAN切片以及端到端网络切片业务的设计、编排与管理。

ONAP架构

架构概述

面向网络基础设施的业务和资源(包括VNF、PNF、基于容器的 VNF 等)的生命周期管理，ONAP提供了一套完整的功能体系架构,包括各个组件及其接口,以及它们的开源实现。与此同时，通过服务化设计，它也提供产品研发与商用部署的灵活性，运营商和厂商们可以根据需要采用整个平台，也可以只采用最适合其特定业务或需求而选择的组件子集。

如图1所示，ONAP系统由设计态和运行态组成,前者支持业务设计人员通过图形化界面导入描述软件化的基础网元资源的描述文件，并以此为基础通过各类基础资源的组装、拼接，设计出复杂的业务蓝图经过测试验证后发布到运行态。由后者负责响应网络运维人员或者来自最终用户的业务管理请求基于业务蓝图实施对应业务及其依赖资源的实例化以及全生命周期管理。

图2提供了一个更为详细的ONAP卡萨布兰卡版本架构图，并在其中以橙色高亮显示标注了使用或受到行业标准影响的模块。

相关SDO与用例协作

表1更进一步给出了与各个图2中高亮的ONAP平台模块相关的SDO。

从概念上来理解作为业务无关的通用平台，ONAP对它所管理的业务和资源是不可知的，其涵义包含两个方面：一方面，业务提供商可以使用ONAP来管理不同领域的业务及其依赖资源,并通过嵌入到ONAP中或被ONAP使用的模板或应用程序，来管理这些业务和资源;另一方面,ONAP各个功能组件也在努力向模型驱动方向演进,这意味着业务提供商可以根据自身需求灵活选择适用其特定网络场景的ONAP组件。上述趋势在目前的社区用例中也得到了很好的反映。例如，

• VCPE用例第1阶段利用SO进行业务和VNF的编排工作(包含设计功能),而第2阶段利用VF-C 进行网络服务和VNF的编排(不涉及设计功能)。
• VoLTE和CCVPN用例利用SO进行端到端业务编排,VF-C用于网络服务的编排，并采用第三方VNFM进行VNF编排。

ONAP模型

模型驱动

模型驱动是IT系统设计中广泛采用的方法,通常用于大型企业或复杂系统中的业务需求描述。其中软件应用程序的业务逻辑通过高层次抽象模型进行定义，从而实现与代码的解耦。可以通过修改模型而不需要修改代码来动态调整软件系统的执行行为，从而更敏捷地支持不同的业务应用的需求。

换句话说，通过采用模型驱动方法，只需要提供遵循ONAP数据模型语法要求、参照ONAP信息模型语义约定描述的业务模板（及其所依赖的资源模板），而不需要对ONAP功能组件进行任何代码修改，就可以支持针对该业务的生命周期管理。

如图3所示，为了协调标准内外工作从而更好地利用来自其他标准组织的既有成果，ONAP系统内在不同模块之前流转的业务/资源模板分为外部模板、内部模板和实例模板三类。顾名思义，外部模板是来自ONAP系统之外，由外部实体或组织针对特定资源或服务的部署与管理提供的模板，包括提供给设计态模块和运行态模块的模板。内部模板特指由设计态模块完成设计、验证并发布给运行态模块的业务模板，包括其自身的资源和业务描述，以及许可、策略、闭环设计等其他信息。而实例模板主要被A&AI模块用于描述被运行态模块所管理的各类活跃资源和业务的运行状态。

相关SDO与用例协作

下表列出了与ONAP模型相关的行业组织。

为了有效统筹各个功能模块的模型设计、实现与验证工作，ONAP的技术指导委员会下专门设立了模型委员会。作为ONAP卡萨布兰卡发布版本的一部分，模型子委员会发布了以下模型规范（模板的范式）：

• 基于ETSI NFV SOL001的VNFD和NSD外部模型;
• 基于OpenStack HOT的VNFD外部模型；
• VNFD、SD以及VES内部模型与VNF的实例模型。

后续社区计划定义并支持更多的模型规范,包括策略和许可的内部模型、YANG配置模型等。

第[1]节中描述的ONAP用例一方面通过使用多种不同的ONAP模型对模型驱动方法进行了演示和验证，另一方面也指出了模型工作的新方向，比如:

• vCPE蓝图第1阶段使用OpenStack HOT外部VNFD模板及ONAP TOSCA内部业务模板。
• vCPE蓝图第2阶段使用ETSI NFV SOL001 VNFD / NSD外部模板。
• 5G用例团队参考3GPP SA5规范来增强ONAP内部SD模型用于网络切片的业务建模。

ONAP API

ONAP API设计原则

为了使ONAP的业务提供商和用户能够快速地将ONAP与其现有业务与网络管理系统(如OSS/BSS)进行集成,ONAP采用具有明确定义的API架构,促进ONAP内部与协作项目和应用之间的互操作性。

ONAP平台中有两类API，它们均遵循上述设计原则:

1.ONAP外部API：通过提供ONAP平台功能的抽象视图,使ONAP被视为”黑盒”。同时这些API还可用于调用其他系统的平台能力。
2.ONAP内部API：这些是由单个ONAP模块提供的API，用于与其他内部模块交换信息并共同实现ONAP的功能。

ONAP的External API框架项目（如图2所示）为北向对接OSS/BSS提供了统一接口。

相关SDO与用例协作

下表列举了与ONAP API开发相关的SDO。

截止目前,大多数ONAP API都是ONAP独有的。随着我们继续推进标准的协调工作, 我们预计 ONAP 内部API将与标准保持一致,反观ONAP也可能影响行业标准的制定。

以ONAP用例为例,CCVPN参考TMF的openAPI实现ONAP东西向接口。vCPE第2阶段验证了C版本中分别将ETSI NFV中的SOL005和SOL003用于VF-C北向和南向接口实现。

开源社区与标准协同工作

ONAP社区设立了标准协调员，负责定期组织ONAP与行业组织SDO的联合研讨会议，以收集当前社区开发工作中遇到的标准协作的意向与问题，并同时征求来自SDO的反馈意见。

来自其他行业组织SDO的代表可以作为ONAP社区个人贡献者和提交者参与社区技术方案制定（例如模型或架构委员会）或方案实现的具体实施 (例如用例或功能模块开发)。与此同时，通过共同的公司/个人参与者作为纽带，相关行业组织SDO同时积极致力于基于与ONAP社区的技术交流或集成测试中收集的反馈来规划和修订其制定的规范。例如：

ETSI NFV ISG
ETSINFV ISG定义了NFV架构框架、接口和交互数据,以部署与管理虚拟化网络功能。

其中的IFA 和 SOL 工作组分别制定了ETSI NFV VNFD/NSD的信息模型（IFA011/IFA014)和数据模型(SOL001)，ONAP参考了上述模型并在其基础上进行了增强。ETSI设立了专门的会议以讨论ONAP模型委员会的反馈意见。

此外,ETSI NFV还与ONAP在VNF包增强（SOL004)等方面进行了密切的合作。

作为合作的结果，相应的ETSI NFV标准（包括IFA011 2.5.1和SOL001 2.5.1）已基于ONAP的反馈进行了更新。

3GPP
3GPPSA5 定义了3GPP 网络的操作和管理的体系架构。目前其正在研究 ONAP 的DCAE功能 (数据收集分析与事件) 以及控制器融入3GPP管理架构,其结果记录于3GPP 技术报告28.890。此外, 3GPP SA5还评估了ONAP通过 YANG/NETCONF 标准配置网络功能的方法, 并采纳了这一方法。

3GPPSA2 在TS 23.501中定义了NWDAF (网络数据分析功能)，面向5GC NF, AF和OAM提供分析服务的功能。这是一个需要更多合作的领域,因为它有可能使用ONAP的DCAE组件实现。

总结

ONAP通过提供设计态和运行态环境作为平台的一部分，为管理、编排业务和资源提供了一个自动化平台。在进行平台实现时，ONAP处于一个标准组织的生态系统中，其中产生的交叉影响为行业发展带来了推动力量。但ONAP并不一定要遵守所有的SDO规范。它必须在部署灵活性与实现一致性之间进行权衡。例如，虽然ONAP内部VNF/业务模型与某些行业标准模型不同，但后者也被同时接纳作为支持导入的外部模型。至于外部API，ONAP尽可能地支持更多的方案。如对于北向API，它可以支持TMF API以及ETSI NFV SOL005。

显然,随着ONAP的成熟,未来的每个版本将引入更多的平台功能,与SDO等组织加强合作融合行业标准在确保ONAP平台实现可扩展和可互操作的生态系统上的作用会变得越来越重要。

缩写附录

本文转载自LFAPAC官微