任旭东 著
第1章
网络自动化挑战及ONAP介绍
什么是ONAP？运营商在网络转型中遇到的挑战是什么？云服务厂商和OTT服务商在其网络自动化实践中有何经验可以借鉴？为什么ONAP是电信产业网络自动化领域最有前景的开源实现方式？本章试图从以上几个问题入手，逐步揭开ONAP的神秘面纱。
在介绍ONAP之前，我们先来了解网络在自动化演进过程中面临的挑战。
1.1 网络自动化演进的挑战
自贝尔于1876年2月14日在美国专利局申请电话专利权，这一百多年来电信基础设施网络飞速发展。时至今日连接超过50亿移动用户的电信行业已彻底改变了世界。它让我们彼此相连，带给我们娱乐、传递给我们新闻，给予我们灵感。长期以来，电信运营商都是引领社会数字化的弄潮儿，是自动化的引领者。近年以来，互联网服务商，尤其是公有云巨头们凭借强大的软件能力，实现了高度自动化的基础设施运维模式，大大提升了劳动生产率。相对而言，运营商们的网络运维和运营模式却变化不大，自动化水平不高，效率提升不明显，在同OTT争夺未来ICT基础设施服务市场的竞争中处于不利地位。主要原因为：
（1）受组织架构和技术水平等的限制，如今的电信网络仍然主要靠人工来管理，自动化程度不高。
大量工作需要人来手动完成，导致业务发放时间长，业务无法及时上市；运行过程中故障平均恢复时长让用户无法忍受。这些都影响了网络敏捷和终端用户体验。
一方面，运营商在部署新业务时，往往需要数月甚至更长的时间，这严重影响了电信业务的创新效率；另一方面，在网络运维中心，工程师们不仅每天监控着成千上万的告警，还要创建故障单来跟踪问题的解决过程。运维工程师必须经过专业培训才能使用软件系统执行日常任务。他们未必清楚如何增强软件以适应不断变化的需求，还可能受限于不支持定制功能的软件。由于手动操作的单调性和重复性，常年累月，运维人员会失去动力，枯燥的工作会导致严重的运维人员流失。
依赖重复的手工流程体现在：操作人员要么把相应的步骤写入手册，要么将其形成个人知识库。但即便手册说明足够详细，操作人员经验足够丰富，依赖手工流程也容易出错。不精准的分析和不正确的配置所带来的风险极高，甚至可能会带来服务中断、收入损失和客户流失等问题。
（2）烟囱式的运维模式使得网络无法全生命周期统一管理，网络运维不可视，故障无法实时感知。
运营商目前使用的大多数运维支撑软件（OSS）都是基于封闭的软件架构设计的。这些架构基于不同领域部署，从而形成一个个运维孤岛，使得软件变更周期不可控，新业务的上市时间长，网络跨域故障无法快速修复。可以毫不夸张地说：“我们使用的是21世纪的4G网络、光纤网络，甚至5G商用已经此起彼伏，但网络自动化程度在某种意义上还停留在20世纪。我们很多的运维工具和手段让人感觉身处石器时代。”
运维组织的层级化、地域化严重阻碍了网络自动化程度。例如，通常有三个层级的客户服务和网络运维，这也是烟囱式软件和流程式烟囱的一个表现，并且在级与级之间存在大量的手动切换。典型的运维模式是按照国家、省、地市等行政地域来进行的，网络虽然全程全网打通，信令可达，但是运维指令是被局限在这些行政区域之内的，严重依赖人为协调、沟通、审批等工单流程，实际上是无法自动化完成一条跨省电路实施的。除去基本的语音业务以外，其他业务在不同区域的业务体验、运维体验也都是不连续的，最终导致用户在不同地域会明显感觉到差异。
（3）网络扩容的计划模式难以适应业务的变化，难以实时响应业务诉求。
随着业务种类、数量的快速变化，对网络本身的弹性也提出了更高的要求。资源的自动扩缩可以有效节省成本，比如在业务的低谷期可以将资源降下来，在业务高峰期可以自动扩容。每年的春晚以及其他一些大型活动期间，在短时间内会召回大量平时不活跃的用户，给网络带来数倍于日常的流量。可以说网络的重大事件服务保障堪比一场重大战役，需要调动各种资源并准备各种预案以应对。
另外，突发业务诉求和流量变更也往往需要运营商网络随之快速适配。但现实中，大部分业务仍然无法实现按需调整。业务能否按需调整直接关系到已有客户的黏性和新客户的拓展。总体来说，目前这样的弹性调配在运营商网络中还很难完全自动化实现。
（4）运营支持系统复杂且支离破碎，缺乏统一平台和框架，导致网络转型难以成功。
面对越来越复杂的业务，面对越来越多样化的用户需求，从初期机房中的几十台设备发展到如今庞大的数据中心，单靠人工已经无法满足技术、业务、管理等方面的要求。自动化、架构优化、过程优化等降低运维成本的因素越来越被人们所重视。
从2000年开始，运营商已开启网络转型之路。然而，转型并不容易。由于种种原因，超过80%的转型最终无法完全实现既定目标。全球一大批运营商接连开展了一波又一波的转型实践，但是目前为止，还没有走出一条清晰且公认成功的转型之路。
从运维管理支撑系统角度来看，无论是早期的ITU-T的TMN的五层模型，还是后来TMF（电信管理论坛）的NGOSS的eTOM模型，以及再后来演化的ZOOM模型等，带给产业界的依然是各种烟囱林立的、割裂的、定制化的信息孤岛，而且年复一年积累下来，每个大型电信运营商无不积累了数百套甚至上千套这样的系统，它们每个都有具体的用途，但没有一个人能把全部系统的关系说清楚，更谈不上自动化打通各系统间的数据流和业务流。这也是转型不容易的原因之一。
面对电信产业的众多挑战，要提高成本效益和质量，运营商需要探索创新的自动化模式。电信运营商参考其他行业的优秀自动化实践，包括OTT厂商、云服务提供商、标准产业组织和开源产业组织，希望从其他行业汲取经验，以便建立更加敏捷的网络自动化模式。在自动化的基础上，还可以引入AI，增加更多网络智能化及网络自动驾驶的能力。
1.2 网络自动化商业实践
1.2.1 AT&T的网络自动化实践
AT&T是全球技术实力最强的电信运营商之一，ECOMP是AT&T为实现网络转型而新设计的自动化平台，全称是Enhanced Control, Orchestration，Management & Policy（增强的控制、编排、管理与策略）。
2016年ECOMP正式上线，到2016年年底支撑AT&T实现网络虚拟化比例到30%，在接下来的两年中ECOMP持续扩展，到2018年年底，AT&T公开表示完成了65.5%的网络虚拟化。
2017年AT&T基于ECOMP平台开源了OpenECOMP项目，2018年OpenECOMP和Open-O合并形成ONAP。
ECOMP的架构图（见图1-1）主要由两部分组成：一部分是用于对业务进行设计、定义和编码的设计态环境；另一部分是自动执行设计态输出结果（业务逻辑及策略驱动的闭环工作流）的运行态环境。
ECOMP的设计态主要模块如下：
- 业务设计和创建（AT&T Service Design & Creation）是一个集成了工具、技术和资源库的开发环境，用来定义、仿真、认证AT&T的网络资产及其关联流程和策略。
- 策略创建（Policy Creation）是设计策略的工具。策略关注引发动作的特定条件，输出机器可读的规则，定义基于触发或请求的动作。
- 分析应用设计（Analytic Application Design）是设计大数据分析应用的平台，输出的应用可以运行在DCAE平台上。
ECOMP的运行态主要模块如下：
- 主业务编排器（Master Service Orchestrator，MSO）是一个高层工作流执行器，其自动按顺序执行创建、修改或移除网络/应用或基础设施服务和资源所需的活动、任务、规则和策略。
- 控制器（Controllers）是居于云和网络之上，执行配置、实时策略，并控制分布式组件和业务状态的应用。AT&T并没有使用一个庞大的控制层，而是分别使用三个控制器来管理指定控制域：云计算资源（基础设施控制器，通常在云上）、网络配置（网络控制器）和应用（应用控制器）。
- 数据收集、分析和事件（Data Collection，Analytics and Events，DCAE）是个支持分析和事件的框架型组件。它收集性能、使用率和配置数据；进行计算分析；辅助进行排障；公布事件、数据并分析数据。
- 活动和可用资源库（Active and Available Inventory，A&AI）提供资源、业务及其相关实时“自顶向下”视图，展现了一个客户所买产品与组成这些产品的原材料所构成的资源关系。A&AI不仅登记了业务和资源，还维护了相互关系视图。
ECOMP聚焦如下三个核心能力：
- 使能新业务：ECOMP平台创新性地改进了新业务上线方式，使得AT&T、网络Vendor、OSS集成商、第三方应用开发者、云服务提供商等可以基于一套平台（ECOMP）工作，显著提升了新业务上线的自动化水平，使得AT&T能快速扩展面向云消费者和企业业务的产品组合，增加AT&T网络对客户的价值。
- 策略驱动客户体验保障：ECOMP平台通过支持对网络、业务和容量进行准实时策略驱动的自动化再配置来提升客户体验。
- 端到端生命周期管理：ECOMP平台为运营商在实时工作负载情况下的产品/业务提供设计、新建和生命周期管理的能力。
1.2.2 互联网企业的网络自动化实践
大型互联网企业建设和维护着一张覆盖全球、连接大量数据中心的网络。他们一般开发自己的自动化平台来运维网络，以降低故障、提升效率。
Google的DevOps理念的核心是用软件来自动化重复的工作，从而使运维者的精力可以主要用来开发软件。Facebook和Alibaba的自动化工具比较类似，都是采用模型驱动的方式来自动化网络配置。
互联网企业的理念和技术思路对电信产业有借鉴意义，故这里进行简单介绍。
1. Google的DevOps运维实践
Google的产品和服务是全球部署的，通常没有时间和人力像其他组织一样手动维护系统，因此Google更倾向于在其系统中实现自动化。Google的运维团队把大部分时间用于开发自动化平台。
Google认为自动化的价值在于一致性、平台性和自愈性。
- 一致性：体现在自动化系统可以无数遍地、一致性地执行范围明确且步骤已知的程序。而任何个人或者群体在执行数百次重复动作过程中，不可能保证每次都以相同的方式进行，因为没有人能像机器一样永远保持一致。不一致性会导致错误和疏漏，以及其他可靠性问题。这在电信行业尤为重要。
- 平台性：是指自动化的系统可以提供一个可以扩展的、广泛适用的平台。一个平台可以将错误集中化，修改一个错误就意味着该错误被永远修复。一个平台更容易被扩展，从而执行额外的任务，这显然比给人赋能并让人去执行更容易。此外，平台通过越来越多的可视化手段，可以暴露自身的各项指标，帮助人们发现流程中的细节，并在过程中衡量这些细节和指标。
- 自愈性：采用自动化系统解决常见故障，由于平台对问题和故障可以自动感知，故平台可以基于已有经验或者预置策略实现常见故障自动化修复。这样可以明显降低常见故障的平均修复时间（MTTR）。在Google的基础设施中，自动化系统应用广泛，能够快速响应对服务的变化和支持。
2. Facebook的自动化平台Robotron
Robotron主要是在业务发放方面，将运维人员的运维意图自动翻译成异构的设备配置。除了配置之外，Robotron还承担管控的角色，即需要实时掌控网络的配置部署情况，防止网络的部署与规划产生偏差。如图1-2所示，Robotron的功能覆盖于整个网络的管理周期：网络设计→配置生成→部署→监控。
Robotron信息完全依赖于FBNet抽象层，FBNet将对整个网络，包括网络物理或逻辑组件，进行面向对象的建模，比如设备、端口、链路、IP地址等。基于这个网络抽象模型对象，运维人员可进行网络设计（Network Design）、配置生成（Config Generation）、部署（Deployment）和监控（Monitoring）。
- 网络设计：主要是确定各种网络资源对象的拓扑和关联关系，设计的输出是对目标网络的抽象。
- 配置生成：基于网络设计的输出，配置生成模块可以根据设备的厂商和型号信息，自动生成设备的配置脚本。这个模块要针对不同的设备类型来开发对应的配置生成模块。
- 部署：部署是配置下发的工作流，为了消除配置下发的风险，需要完成设备初始状况的比较确认、配置任务的原子化（同一个时间段只有一个操作）、配置的校验、配置的回滚等工作。
- 监控：监控是通过收集设备的实时配置，生成网络的实际状态，以确认网络配置被正确下发，确认网络运行状态与抽象层相符合。
从Robotron平台我们可以学习到抽象建模和Top-Down的思路，用抽象模型来表述目标配置，用Top-down的方式来生成具体的配置。
3.阿里NetCraft网络配置自动化实践
阿里开发的NetCraft主要是为了解决网络变更的配置问题，以降低人工操作引起的故障。NetCraft也用模型的方式来描述网络的配置。阿里认为网络模型要满足四个要素：
- 可解释性：网络模型的可描述性，即要深入到网络的方方面面，包括连通性、协议层，只有信息足够全，才是高质量的模型。
- 互操作性：网络模型要能方便地转换为网络配置，反之亦然。这个是基于意图网络模型的技术底座。
- 灵活性：操作粒度要原子化，并支持下发、回滚等操作，只有将业务意图解构为足够细的原子化操作，才能保证自动化工作的平滑切换。
- 独立性：网络模型要能屏蔽多厂商之间的差异。
NetCraft网络模型的关键设计就是其多图层机制。NetCraft的设计思路是将网络自下而上划分为多个图层：最底层是物理层，包含网络设备的物理链接关系，可以包含设备名称、LLDP、ETH-Trunk信息；物理层之上是IP层，包含接口的IP地址信息；再之上是各种协议图层，如BGP、OSPF、ISIS、MPLS。NetCraft会为所有的路由协议单独构建一个图层。不同图层之间的关联是通过设备接口、设备自身等图层间共享的实体实现的，BGP和OSPF图层之间通过IP图层的三层IP接口相关联的。
在属性定义方面，NetCraft和Robotron一样，所有的属性都是依存于网络图层中的各种实体。NetCraft的这种多层图机制易于理解，能达成良好的可解释性。
NetCraft的架构如图1-3所示。
网络操作者的主要工作是设计目标网络模型（Target Network Model），配置生成器（Configuration Generator）负责解析目标网络模型，并结合预定义的配置模板，将目标网络模型转换为对应的设备配置命令。迁移规划器（Transition Planner）根据目标模型要修改的配置，计算上述多个图层之间的配置依存关系，通过精心设计的业务编排来达成业务的平滑部署。配置下发（Configuration Executer）结合目标配置和切换规划，进行具体配置的逐步下发，每下发一步都会检测网络状态，如果异常则回滚。模型生成器（Model Generator）将配置逆向解析回运行网络模型（Running Network Model），用于网络诊断工作。
可以看到，NetCraft同Robotron的整体架构和思路是非常类似的，都是Top-down的思路。NetCraft的多层网络建模和关联关系建模也值得借鉴。
1.2.3 网络设备厂商的自动化系统
业界领先的网络设备厂商，比如华为、思科，一般也会提供比较强大的网络管理工具，尤其是在电信专用设备领域，比如光网络（SDN、OTN）、接入网络（DSL、PON）、无线网络（2G、3G、4G、5G）、电信核心网（IMS、EPC）等，厂商提供的网管软件普遍支撑图形化界面、端到端的业务自动发放、告警管理、性能管理等功能。
对于最新兴起的SD-WAN解决方案，网络控制器一般都提供CPE设备的自动开局（即插即用）功能和业务自动化发放（即Zero-touch-provisioning）功能。
最近几件，SDN概念的兴起，简化了分布式控制，采用集中化路由技术和控制的方式提升网络效率。比如采用Segment Routing技术来简化MPLS的控制器，采用BGP协议来集中控制和调度流量。因此厂商提供的软件工具往往是管理和控制融合的产品。比如华为公司的NCE是SDN增强型“管理、控制和分析一体化集成”的新产品。
厂商提供的网络设备管理和控制软件，除提供GUI界面外，也提供API接口。用户可以直接在GUI上进行网络配置，也可以通过API集成到电信运营商的综合网管系统里。
大部分场景下，厂商提供的管理软件是必不可少的，尤其是电信网络，其设备数量、规模巨大，让OSS层面的系统直接管理设备是不现实的。而利用厂商的管理软件，把一张大规模的复杂网络抽象成一个相对简单的网络是大有好处的。
本书介绍的ONAP平台，主要是通过对接厂商管理软件的API，进行网络对象的抽象资源建模，以实现全网范围内的业务自动化。
1.3 开放网络自动化平台—ONAP
ONAP（Open Network Automation Platform）项目是Linux基金会下的一个开源项目，2017年4月由OpenECOMP和OPEN-O项目合并而来。
1. OpenECOMP
2017年2月，AT&T正式向Linux基金会贡献ECOMP（增强控制、编排、管理和策略）平台的业务无关的代码，从而形成OpenECOMP开源项目。
2. Open-O
Open-O是2016年年初在中国移动、华为和Linux基金会的倡导下发起的协同器开源项目，该项目得到首批15家企业成员的支持，包括中国电信、韩国电信、中兴通讯、Intel、爱立信、GigaSpaces、InfoBlox、Red Hat等。这个项目也是由Linux基金会管理的。
2016年11月7日，Open-O正式发布了Open-O 1.0版本，该版本名称为Sun。
3. ONAP
为了聚集产业力量，减少产业分裂，共同打造网络自动化的准事实标准，开源项目Open-O和OpenECOMP经过多次接触，最终达成合并协议，2017年4月，新项目诞生，并正式改名ONAP。
ONAP是电信产业联合打造的一个网络自动化平台，会员覆盖了全球领先的运营商、设备制造商、IT企业、芯片公司、互联网厂商和云服务商等。
ONAP继承了原来OpenECOMP项目及Open-O项目的主要成员，其中运营商会员覆盖全球移动用户超过70%，成员包括AT&T、中国移动、中国电信、中国联通、Orange、Vodafone、加拿大Bell等。ONAP厂商成员包括华为、Juniper、思科、爱立信、Giga-Spaces、IBM、英特尔、Metaswitch、微软、新华三、诺基亚、Raisecom、Reliance Jio、Tech Mahindra、VMware、Wind River和ZTE等。
2018年，ONAP成为网络开源项目LFN（Linux Foundation Networking，Linux网络基金会）旗下的项目之一。截至2019年3月，ONAP已经拥有110多个会员，已发展成为电信产业规模最大且最具影响力的开源社区之一。
关于Linux基金会和LFN
Linux基金会（Linux Foundation，LF），是一家非营利性组织，致力于围绕开源项目构建可持续的生态系统，以加速技术开发和行业采用。Linux是开源软件项目历史上规模最大、应用范围最广的项目。除Linux外，LF作为业界*开源基金会，还积极监管了许多成功的开源项目，包括Xen、KVM、CNCF、Hyperledger等。ONAP也是其中之一。
2018年1月LF宣布成立LFN项目，将旗下多个面向网络领域的开源项目合并。目前LFN拥有七个网络开源项目，分别是ONAP、OPNFV、OpenDaylight、FD.io、PNDA、SNAS.io和Tungsten Fabric。LFN成立旨在协调目标相似的开源项目，消除不同项目之间的重叠或冗余，并创建更高效的流程，加快其工作。LFN为各项目之间的合作提供一个平台，同时保证技术上的独立性。
LFN中的七个项目构成了从数据平面到控制平面、编排、自动化和端到端测试的网络堆栈的基础，ONAP自身与LFN中的项目联系紧密，尤其是开源控制器项目ODL（OpenDayLight）及端到端测试项目OPNFV。
ONAP定位为一个开源的自动化平台和编程框架，旨在通过为大规模的物理和虚拟网络设备提供全局的编排功能来解决传统模式因规模和成本带来的挑战。ONAP平台为物理和虚拟网络功能提供了一个模型驱动的业务编排和策略驱动的实时闭环自动化平台。ONAP平台可以快速自动化部署新业务，并支持全生命周期管理。
ONAP的目标是打造与业务、厂商无关的自动化业务使能平台，解决运营商数字化转型面临的挑战。ONAP平台核心能力包括：
- 实现网络敏捷性、弹性和自愈能力，实时感知和响应业务诉求。
- 使运营商或第三方能近乎实时地重新配置网络、编排服务和扩缩容量，缩短新产品上市时间。
- 成为全生命周期管理高度动态化的网络与软件系统，实现可视化。
ONAP自动化目标是闭环自动化，覆盖设计→创建→收集→分析→检测→发布→响应，覆盖业务全生命周期闭环自动化，各种关键角色，如供应商、网络设计人员、网络运维人员，在同一流程和自动化平台上衔接，显著减少人工干预以提升工作效率：
- 供应商：按需提供相应产品包后，能自动上线到运营商的ONAP系统。
- 网络设计人员：完成对业务的规划设计后（包括对新增业务的设计或对已有业务的设计、修改），支持新业务自动部署与发放，并在后续的运维全流程中自动响应网络和资源状况变化而无须人工介入。
- 网络运维人员：从后期重复繁重的维护工作中解放出来，一旦完成对特定运维动作的规划设计，则后续此类运维工作即可自动进行，运维人员可把时间花在更有创造性的工作中，比如针对不在规划范围内的异常进行总结分析，给出新的规划设计后部署实施，不断提升网络维护效率。
图1-4所示从较高层级示意了闭环自动化及业务生命周期内不同阶段的自动化。
ONAP通过提供一套通用、开放、可互操作的北向REST接口来同运营商的OSS/BSS系统集成，南向可以与多个VIM、VNFM、SDN控制器甚至传统网络设备的集成来支持各种网络环境。ONAP采用标准模型，降低了异构设备的集成和部署成本，同时最大限度地减少了管理的碎片化。在ONAP平台上，网络运营商和他们的网络/云业务提供商可以在一个动态、闭环的过程中进行协作，实例化网络设备和业务，并对操作类事件进行实时响应。
ONAP源代码遵循Apache 2.0协议，文档遵循Creative Commons Attribution 4.0 Interna-tional Public License，只要给出适当的署名即可*分享和演绎，详见附录A。总之，ONAP遵循的协议是比较宽松的许可协议，这使得为ONAP做贡献和将其作为商业使用非常方便。
ONAP项目官网：https://www.onap.org/
ONAP项目Wiki：https://wiki.onap.org/
ONAP社区贡献：https://onap.biterg.io/
Apache 2.0协议：http://www.apache.org/licenses/LICENSE-2.0
1.4 ONAP版本路标及关键特性
ONAP的版本命名按照英文字母A～Z排序，每个版本选用不同的世界城市命名，社区计划每6个月发布一个版本。截至2019年3月，共发布了3个版本、分别是Amsterdam版本、Beijing版本和Casablanca版本。最新版本Casablanca（简称C版本）包含了30多个项目，C版本新增代码总量60多万行，代码提交12万次以上，开发者超过500，参与代码贡献的组织30多个，社区贡献持续活跃。最新版本Dublin版本预计在2019年6月发布。目前，ONAP社区规划的前6个版本的发布时间如图1-5所示。
1.4.1 Amsterdam版本
作为ONAP的第一个版本，Amsterdam版本于2017年11月16日发布。该版本基于统一的体系架构，整合了来自OpenECOMP和OPEN-O的代码。
Amsterdam版本为两个场景提供了经过验证的蓝图。第一个蓝图是VoLTE（Voice Over LTE），它允许通过虚拟化核心网络把语音业务统一在IP网络上进行处理。ONAP用于设计、部署、监控端到端VoLTE业务以及生命周期管理。第二个蓝图是Residential vCPE（面向家庭的宽带接入业务），它通过ONAP部署基于虚拟化技术的网络宽带接入服务，这意味着CSP可以快速并按需向家庭客户提供新服务。
Amsterdam版本提供如下功能模块：
（1）Portal：基于不同的用户角色，在设计态和运行态提供一致的用户体验。
（2）设计态框架（Design-time Framework）：一个全面的开发环境，包含用于定义或描述网络资源、网络服务和产品需要的工具、技术和存储库。其包括如下组件。
- 业务设计和创建（SDC）：提供网络业务设计和创建人员所需的工具，用于定义、模拟、认证网络服务、网络资产及与其相关的自动化处理流程和策略。
- VNF软件开发套件（VNFSDK）：提供给VNF供应商的VNF打包和验证的工具。
- 策略创建（Policy）：提供给网络策略的创建和管理人员的工具，提供了创建和验证策略/规则、识别策略重叠、解决策略冲突及根据需要派生其他策略的功能。
- 闭环自动化管理平台（CLAMP）：提供了设计和管理自动化控制闭环的方法和工具。
（3）运行态框架（Run-time Framework）：运行态框架执行由设计态框架分发的配置、规则和策略，以及与管理对应的控制器。
- Service Orchestrator（SO）：执行指定的基础设施服务工作流，自动创建、修改或删除服务所需的资源、规则、策略和配置。
- SDN控制器（SDN-C）：执行网络领域的资源配置和管理。
- 应用程序控制器（APPC）：执行虚拟网络功能（VNF）配置和生命周期管理操作。
- 虚拟功能控制器（VF-C）：执行网络业务（NS）的配置和生命周期管理，同时使用VNF Manager来执行VNF的配置与生命周期管理操作。
- 活动和可用资源库（A&AI）：提供系统资源、服务、产品及与其相关的实时视图。
（4）闭环自动化：设计→创建→收集→分析→检测→发布→响应。
- 数据收集、分析和事件（DCAE）：收集事件、性能、使用情况，并将信息发布到与执行闭环操作相关的部件（如SO）以触发策略。其子项目Holmes将收集到的信息与A&AI中的对象关联，为电信基础设施和服务提供告警关联分析。
- 公共服务：保障ONAP组件正常运营的服务，包括活动记录、报告、通用数据层、访问控制、弹性和软件生命周期管理等部分。
1.4.2 Beijing版本
Beijing版本于2018年6月7日发布。在Beijing版本中，社区聚焦平台和闭环自动化增强，以确保可扩展性、安全性、稳定性和性能，并支持实际部署。该版本扩展平台支持容器化部署，并为虚拟VNF开发人员、服务设计人员和运营维护人员提供强大的文档支持。
Beijing版本增强了如下组件：
- External API：该组件从北向集成角度提高和TMF标准的互操作性，有利于同BSS的集成。
- ONAP Operations Manager（OOM）：提供了基于Kubernetes托管云环境的ONAP安装和部署功能，大大简化了ONAP的安装部署流程。
- Multi-site State Coordination Service（MUSIC）：提供跨站点的高可用基础服务，支持ONAP扩展到多站点环境，以支持全球规模部署的基础架构要求。
- ONAP Optimization Framework（OOF）：ONAP优化框架提供了一种声明式、策略驱动的方法，用于创建和运行优化应用程序，如位置归属、部署和变更管理调度优化。
Beijing版本增强了如下特性：
信息模型、工作流和策略模型：增强了对相关标准的遵从，包括ETSI NFV MANO、TM Forum SID、OASIS TOSCA、IETF和MEF等。
- 变更管理（Change Management）：支撑虚拟网关（vG）VNF的升级工作流程和自动化。
- 硬件平台感知（Hardware Platform Awareness）：通过感知容量、位置、硬件能力的差异，将资源（如VNF等）置于正确的云/区域（HPA定义DPDK、SR-IOV等规则）。
- 手动触发的自动扩缩（Auto-scaling out with manual trigger）：手动触发系统横向扩展或缩小，以应对变化的容量或负载需求。
1.4.3 Casablanca版本
Casablanca版本于2018年11月30日发布。Casablanca进一步增加了ONAP的可部署性，引入了新的应用场景蓝图CCVPN，不仅支持虚拟网元（VNF），而且支持物理网元（PNF）和新的工作流编排工具。
Casablanca版本增加了组件Post Orchestration Model Based Audit（POMBA）：该组件基于事件驱动，对业务的设计态属性、运行态属性和网络真实的属性进行交叉对比，生成审计报告。
Casablanca版本增加了如下特性：
- 从7个维度继续提升ONAP的软件质量：稳定性、安全性、可扩展性、性能、弹性、可管理性和可用性。
- 简化ONAP安装和部署：使用Kubernetes（Docker和Helm Chart技术）简化安装，OOM支持可插拔的存储，为用户提供更多存储选项。
- 引入新场景蓝图：支持5G新蓝图，新增CCVPN蓝图（结合OTN与SD-WAN的企业VPN专线业务）。
- SDC支撑两个新的设计工具：DCAE Design Studio和SO Workflow Designer。
- 支持ETSI NFV-SOL003标准。
- DCAE：支持与Linux Foundation的PNDA项目集成，作为对CDAP的补充。
- A&AI：通过提供历史数据来支持审计功能。
- External API：继续与TMF（围绕ServiceOrder）和MEF API（围绕Legato和Interlude API）协调，以简化与OSS/BSS的集成流程。
- CLAMP：提供了新仪表板功能，用于在设计态和运行态查看DMaaP和其他事件，方便Close Loop闭环自动化的调试。
1.4.4 Dublin及后续版本展望
社区Dublin版本截至本书截稿前还处在开发阶段，计划于2019年6月正式发布。
Dublin版本将继续朝着ONAP商用部署的目标努力，不会引入新的组件，目前已经收集了30多个需求，其中增强5G use case、BBS use case等处于较高优先级，特性增强方面包括：变更管理扩展；5G需求、PNF发现、参数支持、算法、模型配置；VNF扩缩容增强；核心服务、VNF生命周期管理状态和转换模型等。
1.5 ONAP与相关标准开源组织协同
ONAP一直在紧跟标准组织在SDN/NFV方面的进展，并在实施过程中尽量遵循与继承标准已有成果，比如ETSI、MEF、TMF、IETF、3 GPP、BBF等。同时，ONAP还与许多开源社区开展了协同工作，典型的有OpenStack、Kubernetes和OPNFV等。
1.5.1 ONAP与ETSI NFV
欧洲电信标准组织（European Telecommunications Standards Institute，ETSI）是电信产业具有全球影响力的电信设备和网络标准制定者。ETSI NFV是2012年在ETSI下面专门成立的聚焦在NFV相关架构和接口定义的产业标准组（Industry Specification Group），是NFV领域的标准权威组织。
ETSI NFV定义的NFV架构如图1-6所示。
ETSI NFV的标准定义聚焦在VNF和NS（Network Service）的生命周期管理，也就是图1-6中右边方框内所示的MANO（NFVO和VNFM在一起的统称）的相关架构和接口。
从功能范畴上来说，ONAP的范围远远大于MANO的范畴，ONAP要解决的是全部网络基础设施端到端的自动化运维问题，而MANO仅关注NFV的生命周期自动化。
在架构和实现上，ONAP的VF-C模块相当于ETSI的NFVO功能，而VNFM模块一般由厂商来实现，VIM模块一般由云平台供应商来实现。ONAP同厂商特有的VNFM和VIM的集成接口都遵循ETSI NFV的相关标准（SOL003、SOL005等）
ONAP在VNF的信息模型和SO、VF-C模块的接口上遵循ETSI NFV的相关标准。
ETSI VNF的相关标准还在持续演进中，还有很多标准没有定稿，ONAP同ETSI VNF的关系是互相促进，互相影响的。ONAP的开源实现可能领先于ETSI的标准制定，并促成ETSI相关标准的成熟。
1.5.2 ONAP与MEF
城域以太网论坛（MEF）是2001年成立的一个专注于解决城域以太网专线业务技术标准的非营利性组织。最近几年MEF的工作重点转移到推动运营商的数字化转型和业务标准定义上来。MEF根据用户和运营商之间的消费关系提出了LSO（Lifecycle Service Orchestration，生命周期服务编排）的概念和对应的参考架构。
如图1-7所示，在一个运营商的域内（SP Domain），从上到下分别有：
- Business Application：商务相关的系统，对应传统的BSS系统，以及客户关系、报价、计费等系统。
- Service Orchestration Functionality：业务编排功能，进行网络业务的完整生命周期管理，包括创建、修改、保障、修复和终结等。
- Infrastructure Control and Management：基础设施的控制和管理，比如云管理平台、SDN控制器、MANO等软件系统（一般由设备商提供软件系统）。
- Element Control and Management：网元的控制和管理（设备商实现）。
2017年11月，ONAP宣布同MEF达成合作，一起推动网络业务的敏捷运营。在MEF的LSO参考架构里面，ONAP实现了Service Orchestration Functionality的功能。ONAP的External API项目会参考LSO的LEGATO、INTERLUDE、PRESTO的接口标准。
在Casablanca版本的CCVPN用例中，在External API（北向接口项目中）支持跨运营商的企业以太专线定义中，参考了MEF的Interlude（MEF中定义的，用于Service Orche-strator间交互接口的API标准名）接口标准。
1.5.3 ONAP与TMF
TMF（TeleManagement Forum，电信管理论坛）是一个为电信运营和管理提供策略建议和实施方案的世界性组织，是专注于通信行业OSS（Operations Support Systems，运维支撑系统）和管理问题的全球性非营利性社团联盟。TMF提出的NG OSS（New Generation Operations Systems and Software，下一代运维系统）功能模型，包括TOM（Telecom Opera-tions Map，电信运营图）和eTOM（enhanced Telecom Operations Map，增强电信运营图），被国际电信运营商、设备制造商及电信运营支撑系统开发商广泛接受，成为事实上的国际标准。
TMF的Open API计划是一项全球性计划，旨在实现跨复杂生态系统服务的端到端无缝连接及其互操作性和可移植性。该计划正在创建一个Open API套件，该套件是一套基于REST的标准API，可在运营和管理系统之间实现快速、可重复和灵活的集成，从而更轻松地创建、构建和运营复杂的创新服务。
2018年3月，ONAP与TMF宣布正式合作，以确保开放API成为ONAP等关键开源项目的一部分。TMF开放API成为ONAP Beijing版本（2018年6月发布）的重要组成部分。在ONAP的Casablanca版本的CCVPN用例中，External API（北向接口项目中）实现对TMF接口标准的框架支持，包括为了实现跨ONAP的通信，支持了TMT 641（Service Order API，业务订单接口）标准，后续还会支持TMF 633（目录接口）、TMF638（业务状态变更通知）等标准接口。
1.5.4 ONAP与IETF
IETF（Internet Engineering Task Force）负责互联网标准的开发和推动。IETF制定了TCP、IP、MPLS等关键互联网协议。
IETF面向SDN各技术领域开展标准化工作，IETF的SDN参考架构已基本成为SDN的主流标准架构。
IETF定义了网络配置模型语言YANG，并且定义了很多网络资源和业务模型，比如L3VPN、L2VPN、L1VPN等。
SDN控制器北向接口的配置模型，一般会遵照IETF模型。ONAP同SDN厂商进行对接时，一般采用IETF定义的RestConf接口和对应的YANG模型。
在Casablanca版本的CCVPN用例中，ONAP同OTN控制器的接口采用了IETF定义的ACTN（Abstraction and Control of TE networks）相关标准，包括拓扑模型、业务模型等。
1.5.5 ONAP与3GPP
3GPP（3rd Generation Partnership Project，第三代合作伙伴计划）是1998年全球各大标准组织为了协同3G标准合作建立的组织。3GPP成立后就成为无线通信领域的权威组织，并制定了WCDMA、TD-SCDMA等3G标准，以及4G标准LTE和最新的5G标准。
2018年3GPP发布了首个5G标准版本R15，标志着世界正式进入5G时代。
4G改变生活，5G改变社会。5G的基站网络规模会大大超过4G的；5G大量采用虚拟化技术来实现核心网业务；5G要求支持网络切片（Network Slicing）；5G的基站分成DU和CU等，这类新的特点导致5G的自动化运维成为一个很大的挑战。
5G是ONAP的一个核心应用场景，5G蓝图是ONAP持续多个版本的蓝图。
3GPP也成立了专门的工作组来研究5G同ONAP集成的运维架构。
1.5.6 ONAP与BBF
BBF（Broadband Forum，宽带论坛）是1994年成立的全球标准组织，聚焦在定义宽带接入的相关技术，比如DSL和PON等。
BBF近年来积极推动把NFV引入电信机房，提出CloudCO（Cloud Central Office）架构。
ONAP社区的vCPE和BBS两个蓝图，都是聚焦在未来的家庭宽带业务场景，相关标准参照BBF。
以上介绍了ONAP与部分标准组织的合作，接下来介绍ONAP与几个主要开源社区开展的协同工作。
1.5.7 ONAP与OpenStack
OpenStack是当前最主流的开源云计算基础设施管理平台，目标是帮助服务商和企业内部实现类似于Amazon EC2和S3的云基础架构服务（Infrastructure as a Service，IaaS）。
电信运营商的NFVi基础设施普遍采用OpenStack作为云操作系统，提供虚拟机的编排管理和虚拟网络资源的配置管理等功能。
ONAP从第一个版本开始就在MultiVIM项目中支持与OpenStack的集成，多数组件也同时支持通过OpenStack的Heat脚本进行部署管理。从Beijing版本开始ONAP支持通过OOM集成的Kubernetes实现容器化部署与管理。
1.5.8 ONAP与Kubernetes
Kubernetes（简称K8s）是Google开源的一个容器编排引擎，目前是CNCF（Cloud native Computing Foundation，云原生云计算基金会）基金会下面的项目。K8s是集群中负责管理跨多台主机容器化应用的开源系统，支持自动化部署、大规模可伸缩、应用容器化管理，其目标是让部署容器化的应用简单且高效。
K8s目前已是面向云原生的应用，是容器化部署场景的最热门的开源项目，尤其是从VNF向CNF演进的过程，K8s被认为是默认配套。
ONAP在很多项目中都在开展与K8s的集成，包括Multi-VIM项目、OOM项目等。OOM对ONAP的支持就是通过K8s实现的，使用了Rancher、Helm、Kubectl等组件。
1.5.9 ONAP与OPNFV
OPNFV（Open Platform for NFV）是2014年9月在Linux基金会下成立的一个开源项目，专注于加速NFV的发展，其目标是建立一个运营商级的、集成的开源参考平台。运营商与厂商共同推进NFV的演进，确保多个开源组件之间的一致性、性能和互操作性。
OPNFV的工作范畴是构建NFV基础设施（NFVi），虚拟化基础架构管理（VIM），并将应用程序可编程接口（API）包括在其他NFV元素中。这些NFV元素一起构成了虚拟网络功能（VNF）和管理、网络编排（MANO）组件。OPNFV有望提高性能和功率效率，提高可靠性、可用性和可维护性。
截至2018年11月，OPNFV共发布了7个版本，OPNFV项目能够很好地与上下游的开源项目紧密合作，共同促进NFV的发展和应用。
OPNFV是一个集成型的开源项目，成立多年，在NFV和NFVi的功能测试、性能测试上积累了大量的测试工具和测试用例。
2018年OPNFV成立OPNFV Verified Program（OVP）认证项目，针对商用VIM产品进行认证。
LFN成立以后，ONAP对NFV的认证和OPNFV对VIM的认证将统一运作，在LFN成立统一的CVC（Compliance andVerification Committee）进行管理。
1.6 运营商部署实践进展
ONAP得到了全球主要大型运营商的支持，很多运营商都成立了专门的ONAP团队，对ONAP进行测试、验证和试点，或者基于ONAP进行商业版本开发，把ONAP引入到生产环境里面。到本书截稿时为止，基于部分运营商在ONAP社区中的公开信息，进展汇总如下。
1.美国电信电报公司（AT&T）
AT&T的网络自动化生产系统ECOMP就是ONAP在其生产系统中的应用。AT&T已经商业化部署的新业务，比如Network On Demand、5G实验网，都是基于ONAP进行的。AT&T采用社区优先（ONAP First ）战略，生产系统对平台的新需求优先在ONAP社区开发，保证生产系统和ONAP版本的同步更新。
AT&T自身有很强大的软件开发和架构能力，对ONAP的商业开发其仍然引入了商业合作伙伴（如Amdocs、Tech Mahindra等公司），共同推动ONAP在自身网络中的落地。
AT&T的网络技术演进的完整战略还包含引入人工智能和边缘计算，与此相对应，它也在主动推进两个新开源项目：聚焦网络人工智能的Acumos AI项目和聚焦边缘计算的集成软件栈项目Akraino。同时AT&T也在积极推进ONAP同Acumos和Akraino的集成、协同。
2.中国移动
自2017年年初加入ONAP社区以来，中国移动一直积极参与并为社区做贡献，现担任技术指导委员会的副主席，参与架构设计，在多个核心模块积极贡献代码。中国移动还设有ONAP实验室，并负责管理。
在ONAP的第一版本中，中国移动在社区发布了核心网的用例VoLTE，初步验证了ONAP的端到端的业务能力；在第二版本中验证了CPE用例；在第三版本中，联合沃达丰和华为推出CCVPN用例，以实现跨运营商、跨域、跨层的VPN业务连接。目前团队仍在进行CCVPN用例的扩展工作，比如多站点业务的创建、业务修改、AI应用的自动部署等，希望借助该用例，进一步增强ONAP平台的能力。
着眼于下一代网络的主要场景，依托于下一代网络的关键技术，中国移动基于开源社区ONAP的开源版本，自主研发了用于运营商网络设计编排、自动化和智能化运维管理的商用产品。2018年8月，在浙江部署整套ONAP环境，并进行了技术验证；2018年11月份在陕西省进行商用测试，从一阶段测试结果看，对外接口已经可以满足企标要求，当前正在进行二阶段性能、可靠性等测试。2019年将与5G规模试验网同步，支持切片和子网切片的编排与管理。
3.中国电信
中国电信参考ONAP架构研发的网络服务编排器已在现网应用。对于重点业务，如云网协同和智能专线等，中国电信在积极研究基于ONAP平台来编排智能专线业务并积极推动试点。同时，中国电信在国际网络CTGNet中也积极尝试ONAP的应用与部署。中国电信也投入专门团队研究和贡献ONAP社区项目，承担了社区Benchmark项目相关工作并进行S3P验证测试。后续中国电信也将继续积极跟进ONAP社区，寻求商业合作伙伴，将其作为面向CTNet2025的核心网络运营系统引擎，提升网络的自动化、智能化水平。
4.中国联通
中国联通基于ONAP开源代码积极开展产品创新，自研开发IPRAN+骨干网跨域编排器，实现了跨网络领域、跨地市和跨厂家的统一业务编排与网络协同。在社区方面，中国联通积极参与并贡献相关项目，牵头完成ONAP白皮书中文版翻译工作，推动ONAP相关接口标准的商业实践，致力于ONAP中国社区及相关产业的发展和壮大。
5.法国电信（Orange）
法国电信把ONAP作为实现集团OSS简化和网络自动化战略的关键措施并坚定推行。法国电信明确要求从2019年起，所有的招标书都会把ONAP作为必选项。2018年，法国电信联合华为在生产环境公有云上验证了SD-WAN业务的自动化。
2019年是法国电信推动ONAP落地的关键年，法国电信为此专门发出了ONAP伙伴标书，寻找商业伙伴，为法国电信提供定制开发、系统集成和业务设计服务，并计划在西班牙子网开展现网试点。
6.加拿大Bell电信（Bell Canada）
加拿大Bell电信也是最早把ONAP引入到商业生产环境的电信运营商之一。从ONAP第一个版本（Amsterdam）开始，Bell就把ONAP用于虚拟化基础设施层（NFVi）的自动化和商业SD-WAN业务的自动化，其SD-WAN业务已经推向市场。
加拿大Bell计划逐步把ONAP推广到整个运营商网络，包含有线、无线、骨干网、数据中心等。Bell对ONAP的商业化途径也是寻求与商业合作伙伴共同开发，需要商业合作伙伴提供定制开发、集成和业务设计等服务。
7.沃达丰（Vodafone）
沃达丰积极参与了ONAP的CCVPN Blueprint的验证。沃达丰是一个全球运营商，在很多国家拥有独立运营的子网，沃达丰的自动化战略是为每个国家子网引入基于ONAP的商业编排器，并要求所有子网的编排器必须兼容ONAP的外部接口，并能够实现多个国家编排器之间的互联互通。
8.土耳其电信（Turk Telekom）
土耳其电信计划基于ONAP第三个版本（Casablanca）进行商业化部署，推出SD-WAN业务。
从中国三大运营商到欧洲大T，再到北美的领先运营商，全球很多电信运营商正基于ONAP开展商用部署实践活动，或是基于ONAP的架构重构自己的网络OSS系统，以期在未来的网络自动化浪潮中保持先进地位。在这个如火如荼的过程中，中国的运营商和设备厂商也正在发挥越来越重要的作用，在未来网络自动化进程中必将占有一席之地。
1.7 本章小结
本章首先介绍了网络自动化演进的历史和挑战，介绍了AT&T的自动化实践，以及互联网厂商的相关实践。
ONAP是电信产业集中力量应对网络自动化挑战的产物，ONAP为物理和虚拟网络功能提供了一个模型驱动的业务编排和策略驱动的实时闭环自动化平台，可以快速自动化部署新业务，并支持全生命周期管理。本章简单介绍了ONAP要解决的问题及其解决思路，并介绍了目前几个ONAP版本的演进情况，以期读者对ONAP有一个初步的认识。
本章还简单介绍了ONAP同一些标准组织和开源组织的关系，这些知识有利于读者在一个很大的框架下理解ONAP的功能和角色。
本章最后还介绍了全球运营商基于ONAP开展的实验和部署实践。