编者按：本文系SDNLAB技术分享系列，本次分享来自ONOS研究群（群号：454644351）群直播，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。

分享嘉宾
--------------------------------------------------------------------------------------------------
徐世萍，从事信通相关工作5年多，精通BGP、MPLS、VPN等技术，熟悉IPRAN、IP CORE场景，近两年开始投入SDN领域研究，负责控制器设计和开发，主导过ONOS 标签资源、Tunnel管理，ONOS IPRAN，Agile VPN等项目。
--------------------------------------------------------------------------------------------------

第二部分，创新项目及ONOS特性增强项目介绍

NFV相关

随着云计算、SDN、虚拟化等理念和技术的不断成熟，以通用替代专有将原本传统专业的网元设备上的网络功能提取出来虚拟化、软件化，运行在通用的硬件平台上，这种变化即网络功能虚拟化，Network Function Virtualization (NFV)。网络对用户提供的服务是由多种运行在虚拟容器中的网络功能组合而成的，其中每一个小的网络功能其实就是个网络服务Network Function as a Service (NFaaS)。当网络重载时只需要增加网络功能节点即可达到扩容；网络轻载时释放网络功能节点即可减少资源占用；新业务部署只是多种网络功能的重新组合。网络功能虚拟化让网络更加灵活。

ONOS Framework (ONOSFW) for OPNFV

OPNFV是一个网络功能虚拟化的开放框架，ONOSFW项目使ONOS作为SDN控制器集成进OPNFV框架中，实现OpenStack利用ONOS进行虚拟网络资源管理。

用户通过OpenStack提出对网络的需求，ONOS实现Neutron L2、L3插件获取网络、主机数据。ONOS的VTN Resource manager App负责存储从Neutron获取的数据，并对外提供统一的接口。

VTN manager App根据网络数据生成配置信息及流表，通过OVSDB和Openflow完成对OVS的配置及流表下发实现主机互通。VTN manager App监听ONOS core事件，同时通过VTN Resource manager监听Neutron事件，当OVS或主机上下线时更改配置信息及流表，及时响应网络变化。

图表 1. ONOSFW 示意图

Service Function Chaining (SFC)

很多场景中，需要把用户的数据分类，不同类型的数据要做不同的处理。例如移动终端用户数据等在运营商的网络中有一些要根据流量计费，有一些要根据需要送到特定服务提供商等。Service Function Chaining (SFC)业务链就是把流量分类后，为不同类别的流量定制不同路径做分类处理的技术。

ONOSFW项目让主机间实现了互通，在此基础上，给某一些VM赋予一些业务功能（例如防火墙，DPI等），则这些VM在SFC场景中称为SF（Service Function）。一个数据包从源发出，根据用户指定沿途会顺序经过多个SF，这些SF组成的路径就是SFP（Service Function Path）。ONOS的SFC就是让ONOS按照用户策略给OVS下发流表，控制数据包走不同的SFP。

图表 2. ONOS SFC场景示意图

CORD

CORD即Central Office Reimagined as a Datacenter的缩写，用SDN、NFV、Cloud技术，基于商用硬件和开源软件试图搭建打造一个面向未来的运营商Central Office。目前ONOS已经有面对移动网络的M-CORD，面对企业网络的E-CORD，和面对固定网络的R-CORD。

图表 3. ONOS CORD项目

CORD中的技术作用如下：
1、SDN，实现网络设备控制面和数据面分离，使网络能力开放、可编程；
2、NFV，实现网络功能虚拟化，降低CAPEX及OPEX；
3、Cloud，利用云技术提升业务\网络伸缩性，使业务部署更敏捷。

CORD: NFV(NFaaS)

ONOS的NFV（NFaaS）项目是ONOS CORD项目的一个子项，它把CORD网络的各种物理设备实现的功能，转换为软件实现的网络服务Network Function Software (NFS)的组合，主要目的是降低CAPEX及OPEX，同时使网络部署更加敏捷。

NFV项目中，用OpenVirteX (OVX)实现网络功能虚拟化，用ONOS的VxLan实现NFS间的互通，用OpenCloud（XOS）平台把项目中的开源软件集合有机地结合在一起。

图表 4. XOS、OpenStack和ONOS

CORD: Leaf-Spine Fabric with Segment Routing

Leaf-Spine Fabric网络是数据中心的基础网络，可以为大规模的数据中心提供可靠的无阻塞的数据传输。ONOS的Leaf-Spine Fabric项目是CORD项目的另外一个子项，主要目的是用Segment Routing搭建Leaf-Spine Fabric网络，作为NFV网络的underlay网络。

图表 5. Leaf-Spine Fabric作为underlay网络

CORD: vCPE + vOLT

GPON网络中终端通过驻地网关（RGW）接入ONT（光网络终端），经过分光器汇聚到OLT（光线路终端）上。OLT是GPON网络中的汇聚节点，下行连接众多的ONT，上行连接宽带网络网关（BNG）对业务做控制并连接到骨干网。

图表 6. GPON接入网

项目中的CPE指的是RGW设备是用户网关，相当于用户网络到光纤接入网络的出口。

图表 7. CPE (RGW)功能

项目中所谓“vCPE”是把用户驻地网关换成白盒交换机，由SDN控制器统一控制。而原来CPE实现的三层功能则在中心局中用NFV技术实现。

“vOLT”是把OLT功能分为两部分，光信号处理等仍然使用物理设备，而汇聚后对业务的处理则同样在中心局用NFV技术实现。

图表 8. CORD项目中的vCPE和vOLT

ONOS特性增强类项目（Feature）

Kafka Integration

目前非Java语言写的App只能使用ONOS Restful API，但很多数据或消息并没有提供Restful接口只能通过Java API获取。为了能让非Java语言写的App也能获得这些数据，该项目提出在ONOS上集成Kafka系统的方案。Kafka是LinkedIn开发的一个开源的高吞吐分布式消息系统，结构如图。集成后ONOS上会运行一个Kafka App作为外部App的代理，把ONOS Java API获取到的数据发布到Kafka服务器上。

图表 9. Kafka示意图

Producer是消息的发布者；Broker是消息中间件处理结点，即kafka节点；Consumer是消息订阅者。Broker中的Topic是按照消息类型来分的，而partition是具体的消息序列。

消息生产以后Producer会根据指定的策略把消息送到某个Broker上的某个topic的partition（即图中part）中。消费者根据自己的需要自己到BROKER中获取消息。

外部App向ONOS中的Kafka App注册成为Consumer，并知会自己关心哪些事件；
Kafka App创建对应事件的Listener，若该类型事件的Listener已经存在则不再创建，同时将Kafka服务器的地址和topic信息返回给外部App；
外部App根据Kafka App返回的信息，找到Kafka服务器，注册成为Consumer，当有新消息送到时Kafka服务器会通知给外部App来服务器上获取消息。

图表 10. Kafka集成示意图

YANG Models in ONOS

目的是在ONOS中引入模型化语言YANG。主要思路是在保持ONOS现有接口不变的情况下，用YANG Shell将ONOS目前的CORE北向接口YANG化，供YANG定义的App调用，同时对外提供Restconf接口。计划完成ONOS的YANG Tools，以L3VPN为例实现App和南向驱动。

图表 11. YANG Models

ONOS Multi-Clusters Peering Provider

同一个集群中的ONOS实例间的网络信息是共享的，但是很多时候，端到端的业务会需要部署在跨多个ONOS集群的场景，此时ONOS集群间同样需要网络资源信息的共享。这个项目就提出可以让ONOS集群间通过东西向接口共享网络TOPO信息，部署跨ONOS集群的业务。

为了实现这个功能，ONOS新增了一种新的Provider即Multi-Clusters Peering Provider。它的功能主要由以下几项：

1、在一个集群中，leadership机制会选出主Provider，只有主Provider才会将本集群中的网络拓扑进行抽象，暴露给其他的Cluster；同时获取其他Cluster的网络信息并添加到自己的集群中。主Provider故障时leadership会重新选主。

2、Provider抽象本集群网络信息的方法，是将本集群管理的网络抽象为单个交换机，连接用户设备和其他集群的ConnectPoint被抽象为该交换机的接口。其中连接用户的ConnectPoint称为CEP，与其他集群连接的链路称为IL。Multi-Clusters Peering Provider在本地Store中存储网络拓扑与网络抽象的对应关系，并将这些信息暴露给其他集群。并从其他集群获取网络抽象信息添加到自己的集群中。

图表 12. Multi-Clusters Peering Provider对网路的抽象

图表 13. 集群间网络资源信息同步

3、连接到某一集群上的App发布集群间Intent时，Multi-Clusters Peering Provider会通过北向接口安装Intent，并保存到本地Store中。

图表 14. 集群间Intent安装

Q&A

Q1：对于Multi-Clusters Peering Provider，是扩展了一种新的intent作为跨域流量用吗
A1：是，支持了跨域的intent的安装

Q2：整个项目目前的开发如何了呢？主要功能是否已经OK？
A2：你是说Multi-Cluster吧？这个项目本身依赖了ONOS东西向通信的很多机制，这些机制还在做。

Q3：ONOS中也使用了YANG,这个和ODL中的YANG所发挥的作用有什么异同
A3：ONOS的YANG主要在北向和南向，CORE还是原来的CORE

Q4：Multi-Cluster好像不属于单个app，请问这个项目有jira或者gerrit链接吗
A4：这个项目应该还在做，它对madan的机制有依赖

Q5：madan的机制是指？
A5：集群间通信机制，在wiki上有表述

Q6：一般是南向吧，北向用YANG的不多
A6：在北向做了一YANG SHELL，把ONOS的CORE北向接口YANG化，使YANG定义的APP可以对接上来，南向也有

就是这个图里面黄色的部分，L3VPN是在YANG shell上对接的YANG开发的APP

-----------------------------------------------------------------------------------------------------
ONOS研究群（群号：454644351）定位为面向ONOS相关技术的爱好者进行交流、学习、分享，每周会组织定向的技术及业界动态分享，如果你有需要分享的请加QQ或微信：353176266联系。