1、SDN以及控制器简介
SDN(Softeware Defined Network)是由美国斯坦福大学Clean-Slate课题研究组提出的一种新型网络创新架构，是网络虚拟化的一种实现方式。其核心技术是通过将网络设备的控制面与数据面分离，实现网络流量的灵活控制，使网络更智能。SDN尝试摆脱网络对硬件设备的依赖，通过直接的编程方式，实现网络的管控、配置、升级等功能。
Fig1.典型SDN架构图
SDN控制器是SDN控制面的代表，是SDN的大脑。作为SDN架构中的核心部件，SDN控制器以集中式管控方式管理整个网络的策略和流量。SDN控制器能够明显提高网络资源的利用率，缩短业务上线周期，较大提升运维效率。与此同时，SDN控制器可以提供统一的安全策略，为网络提供自上而下的安全防护。
2、SDN控制器发展历史
SDN控制器从早期的NOX控制器一直到如今的企业级控制器，经过了多个发展历程。功能逐渐完善、强大。按照其发展路线可以分为：以ODL、ONOS为代表的开源路线以及以Orion为代表的商业控制器路线。
➢ 第一代控制器：NOX是第一款OpenFlow控制器，采用OpenFlow协议进行管控，由Nicira Networks公司研发，并于2008年开源发布。作为最早的控制器，NOX为后面的控制器提供了很好的范例。不过由于其使用C++语言编写，SDN应用的开发成本较高，逐渐在控制器竞争中失去优势。其后续版本改为Python开发，名为POX，但POX在架构和性能上存在一定的缺陷，逐渐被新兴控制器取代。
➢ 通用SDN控制平台：随着设备厂商加入SDN控制器市场竞争，对SDN控制器提出更高的要求，由多家设备厂商联合而非运营商主导的开源SDN控制器OpenDaylight应运而生。ODL支持多种南向协议，不仅限于OpenFlow、Netconf、OVSDB等。ODL的诞生意味着SDN进入了一个崭新的时期。控制器实现从仅支持单一协议向支持多种南向协议演进。在这一时期，控制器的部署形式也由单体应用转化为分布式平台部署。
经过几年的发展，SDN控制器之间相互竞争越来越激烈。ODL社区凭借设备厂商的大力支持，处于开源控制器的领导者地位。而定位运营商市场，同样采用OSGI架构的ONOS以更优秀的性能在市场上取得了相当不错的占有份额。同期，多种闭源框架也在相互竞争，2013年，Google推出的ONIX控制器更是将宽带利用率提升到接近100%的地步。
➢ 云原生SDN控制器：随着越来越多的业务上云，尤其是大规模数据中心的发展,对控制器的要求也越来越高。SDN控制器也越来越多的与云管平台进行整合运行。SDN控制器结合AI技术、意图网络等内容，向着更智能、更方便的方向发展。ODL、ONOS等开源平台逐渐聚焦智能化运维，Google的新一代控制器Orion更是全面应用微服务架构以及调和理念，采用大规模分布式部署方案，实现大规模生产网络的控制与管理。
3、主流控制器介绍
当前开源社区活跃的控制器主要包括：OpenDayLight、ONOS、Ryu、POX等。闭源控制器以Orion为代表，另外还有HP的VAN、Cisco的DNA Center等。
每种控制器都具有各自的特点以及长处，下面就以几种主流的控制器为大家介绍控制器的相关技术和功能：
3.1 ODL控制器
OpenDayLight（ODL）控制器是由Linux基金会管理和维护的开源SDN控制器,于2013年推出。采用社区驱动的开发模式，主要贡献者为各大设备厂商，如华为、中兴等。旨在提供一个通用、可编程的SDN控制器。能够支持多种硬件和软件平台，实现灵活、可扩展的网络管理和控制。
3.1.1 架构方案
ODL采用OSGi框架进行开发，通过MD-SAL模型架构对南向协议进行抽象化建模以及管理，实现与设备以及协议的解耦，能够支持多种南向传输协议。控制器中核心插件提供了数据存储、配置管理、网络流量管理、服务质量管理、网络监控和调试等功能，并通过RESTful API等北向协议提供对接三方应用，为第三方业务提供设备的数据支持。
如图为一种典型的ODL架构设计方案：
图片
图片来源 OpenDayLight官网
3.1.2 核心概念
- 模型驱动：ODL的模型驱动指将网络设备的配置和状态信息表示为YANG数据模型，统一描述网络设备的属性、配置和状态信息，并基于YANG模型定义一组标准的RESTful API，用于控制器和设备之间的通信。ODL通过YANG模型实现了多协议支持、插件化和可编程化等功能。
- OSGi：ODL基于OSGi框架进行功能开发，天生支持模块化的设计，使用户能够轻松的实现功能的添加和删除。同时Karaf框架提供了良好的运行底座，能够轻松实现业务的高可用，减少了开发难度。
- Yang：一种轻量化的数据建模语言。YANG模型定义了数据的层次化结构。ODL采用YANG来定义网络配置，能够轻松区分配置和状态，具有很强的扩展性。随着标准化的推行，YANG正逐渐成为业界主流的数据描述规范，标准组织、厂商、运营商、OTT纷纷定义各自的YANG模型。
3.1.3 典型模块
- AAA：AAA为Authentication, Authorization and Accounting ，为控制器提供了鉴权、认证和计费的功能。该模块用于控制对资源的访问，强制执行使用资源的策略，并审核统计资源的使用状况，为控制器提供了有效的网络管理和基本的安全架构。
- BGPCEP：该模块为典型应用模块，主要有BGP插件以及PCEP插件构成。BGP插件为用户提供BGP协议的实现以及基于BGP协议的业务实现。PCEP为路径计算通讯协议，用于在MPLS和GMPLS标签交换路径的上下文中在PCC和PCE之间进行通讯。PCEP插件提供构建基于 PCE 的控制器所需的所有基本服务单元。此外，它还为 Active Stateful PCE 提供 LSP 管理功能——这是大多数支持 PCE 的 SDN 解决方案的基石。
下图为基于PCE的路径计算架构：
图片来源 OpenDayLight官网
- Controller：控制器模块是基于 Java 的模型驱动控制器，使用 YANG 作为系统和应用程序各个方面的建模语言，为其他 OpenDaylight 应用程序的提供基础平台。其依赖于MD-SAL、Netconf、RestConf等模块。
- MD-SAL：模型驱动服务适配层 (MD-SAL) 是受消息总线启发的可扩展中间件组件，它根据应用程序开发人员定义的数据和接口模型（即用户定义的模型）提供消息传递和数据存储功能。该模块定义了公共层、概念、数据模型构建块和消息传递模式，并为应用程序和应用程序间通信提供基础设施/框架。
- Netconf模块：NETCONF本身是一种基于XML的传输协议，用于配置和监控网络中的设备。ODL中的Netconf模块支持NETCONF协议作为北向服务器和南向插件，同时提供了一组用于模拟NETCONF设备和客户端测试的工具。
3.2 ONOS控制器
ONOS是首款开源的SDN网络操作系统，主要面向服务提供商和企业骨干网。ONOS社区聚集了知名的服务提供商（如AT&T、NTT通信）、高标准的网络供应商（如Ciena、Ericsson、Fujitsu、Huawei、Intel、NEC）、网络运营商（如Internet2、CNIT、CREATE-NET），以及其他合作伙伴（如SRI、Infoblox），并且获得ONF的鼎力支持。
3.2.1 架构方案
ODL是一个典型的分布式架构系统，自上而下可分为：APP层、北向接口API、分布式核心层、南向接口层。其中，分布式核心平台保证了控制器能够以高可靠、易扩展以及高稳定性进行运行。北向接口抽象为图像化界面以及更友好的管控配置服务提供了重要支撑。可插拔式的南向接口抽象层，使ONOS控制器能够支持OpenFlow设备和传统设备。南向接口的抽象屏蔽了底层设备和协议的差异性，能够同时支持多种设备的管控。其架构图如下：
图片来源 ONOS官网
3.2.2 核心概念
SDN操作系统：一个操作系统需要具备以下基本特征：
（1）用户资源管理；
（2）用户隔离;
（3）服务和资源的抽象化管理；
（4）用户安全机制；
（5）高效的服务使用。
ONOS具备一个操作系统的基本功能，因而不仅仅是一个SDN控制器，而是一个SDN操作系统。
- 软件模块化：ONOS可以像软件操作系统一样，为开发者以及服务提供商更块、更便捷的开发、调试、维护和升级服务。ONOS本身是由一系列功能模块组成，每个功能模块由一个或者多个组件组成，对外提供一种特定服务，这种基于SOA的框架同时支持对组件的全生命周期管理，支持动态加载、卸载组件。
- 统一的网络模型：ONOS 抽象出了统一的网络资源和网元模型，奠定了第三方SDN应用程序互通的基础，使得运营商可以做灵活的业务协同和低成本业务创新。
3.2.3 典型组件
- REST API：提供开放的北向抽象接口，方便运营商以及用户基于ONOS开发应用以及插件。
- 功能组件：ONOS提供统一的网络资源和网元模型，更有利于运营商进行业务开发。统一的组件和模型结构如下图：
[引用feiskyer中ONOS组件和服务章节]
图片来源 gitbook-SDN指南
- Cluster：ONOS集群间通信支持Gossip以及Raft两种算法。Cluster提供了较好的分区容错性以及弹性扩展机制。Cluster能够保障节点失效对业务无影响，当ONOS节点宕机时，其他节点会接管该节点对网元的控制权，当节点恢复后，通过loadbalance命令恢复节点对网元的控制并使整体的控制达到负载均衡。ONOS屏蔽了负责的分布式机制，只对外暴露业务接口，使应用开发更加简单。集群机制如下：
[引用feiskyer中ONOS集群原理章节]
图片来源 gitbook-SDN指南
3.3 Orion分布式控制器
Orion控制器是Google独立开发的第二代控制器。Google于2021年NSDI会议上发表Orion相关论文，论文详细阐述了Orion的设计原则、整体架构以及在网络中的应用情况。论文发布时，Orion已经在现网中稳定运行了四年。相比Google第一代控制器Onix，Orion具有以下特征：
(1)完全独立开发。
(2)微服务架构，分布式程序，具有更高的稳定性。
(3)基于敏捷的开发，更快的迭代速度。
3.3.1 架构方案
Orion是一个典型的微服务应用。其本身的工作模式是基于协调（reconciliation）的模式。从设计的根本原理上看，Orion和Kubernetes的原理几乎一致。
整体框架如下：
图片来源论文：《Orion：Google`s Software-Defined Networking Control Plane》
从架构上看，最上层是各种具体的网络应用，如负责域内算路的Routing Engine。
中间的核心层实现了控制器的通用功能，包括了NIB数据库，配置模块，拓扑模块以及流管理模块。中间层的每个模块都是微服务应用。
下层则是OpenFlow协议栈，Orion控制的所有路由器均只有OpenFlow协议栈，没有传统协议栈，传统协议都是在控制器上完成，可以说是彻底实现了SDN化。
3.3.2 核心概念
- 意图驱动：Orion面向大规模生产网络，在大规模生产网络中，宏观的意图远比细琐的过程更稳定，更不容易出错，因而意图驱动（intent-based）成为了必然选择。Orion本身就被设计成一个翻译和细化意图的控制器。而控制器最终会将管理人员的意图转化为设备可识别的Openflow原语。Intent链式反应图如下：
图片来源论文：《Orion：Google`s Software-Defined Networking Control Plane》
- 分布式控制器：传统控制器多为集中式控制器，控制器单元由一个中心多个分中心的方式进行管理，而Orion采用的是逻辑上的集中。在论文中提到：控制器为逻辑集中控制器，为了实现高性能，控制器需要具有基于内存的状态表示以及在松散协调的微服务SDN应用程序之间使用适当的一致性级别[ 引用《Orion: Google's Software-Defined Networking Control Plane》第一章描述]。
3.3.3 典型设计
- 微服务框架：Orion彻底摆脱了传统控制器的集中式管控制约，采用和K8S类似的架构进行设计，将网络业务抽象为独立的服务，方便了业务的开发、部署以及维护。在万物上云时代，基于微服务架构的设计思路更贴合业务的实现与部署方案。
微服务框架是未来SDN控制器中重要的发展方向。中国移动智慧家庭运营中心自研的SDN控制器就是基于微服务架构对网络业务进行划分，采用协调机制实现高效的业务配置与调度。 - Intent和Ground Truth的链式反应：如上图意图网络所示，Intent有多种来源，通过控制器一级一级的协调，最终将配置转化为机器原语。在意图网络中，最终还是要从人的意图出发。
正如论文中写到的：“Intentbased networks specify management or design changes by describing the new intended end-state of the network (the“what”) rather than prescribing the sequence of modifications to bring the network to that end-state (the “how”)[ 引用论文《Orion: Google's Software-Defined Networking Control Plane》3.1中意图网络原理的描述]”。
4、总结
通过前面大概的介绍，我们了解了控制器的发展历史和方向。这为我们自研控制器提供了很好参考和范例。
目前，中国移动智慧家庭运营中心在自研控制器领域尤其是面向SDWAN自研控制器领域已具备一定的技术积累，基于ODL的开源控制器已在公司部分业务上面进行了试商用，并取得了良好的成效。中国移动智慧家庭运营中心正在将自研控制器向微服务化的分布式控制器演进。在未来，基于微服务架构的控制器将以更快的迭代速度，更稳定的性能，更高的服务效率为移动网络云时代发展提供支撑。
