SDEWAN CNF for OpenNESS

SDEWAN CNF

简介

SDEWAN CNF定义为NFV中的VNF角色，用于实现SDWAN功能。

首先，NFV为一种网络功能虚拟化的标准，参见：NFV基本概念。VNF为NFV中的通信网元，根据NFV分层介于NFVI和OSS/BSS之间，常见NFV有多种：vRouter, vSwitch, vFW等，我们的SDWAN是其中的一种VNF。
根据当前NFV主流趋势，一种是以虚拟机为代表的方式实现网络功能，另一种是以Container为代表的轻量化虚拟技术，而SDWAN CNF后者的一种实现。
容器虚拟化则以Docker为代表，K8S基于Docker提供了一套集群管理方案，用于管理集群Docker网络。

综上所述，SDEWAN CNF是运行中K8S网络中的Pod/Container，实现了SDWAN网络功能。

应用场景及需求

关于SDWAN的应用场景，可参考：SDWAN到底是什么。以前我前期关于SD-WAN的论述：SD-WAN技术实现方案
这里再对SDWAN进行简要说明。
首先，SDEWAN为边缘场景下的SDWAN,根据OpenNESS解决方案，SDEWAN用于在多个K8S集群间建立多条安全的通信隧道，并基于软件定义网络技术使多个集群实现内部组网和通信。目前对SDEWAN有两种实现方式：

1. 基于OpenWRT的SDEWAN CNF
2. 基于VPP的SDEWAN CNF

OpenWRT SDEWAN CNF由于基于Linux OS，功能实现更丰富，但性能存在不足； VPP SDEWAN CNF基于VPP/DPDK技术，性能相对优越，但功能略有欠缺。对于OpenWRT SDEWAN CNF多用于CE侧，即Customer侧，作为网络接入设备需要实现更多用户类需求，性能要求不高；而VPP SDEWAN CNF多用于PE侧，即Provider侧，用为汇聚层/核心层设备功能相对固定而对性能要求较高。
两者通过互补的方式实现SDEWAN整体解决方案，这类解决方案要求：
 支持多WAN接入和智能选路
 支持接入LAN
 支持接入K8S CNI
 支持IPSEC和VXLAN
 支持被K8S CR管理
 支持被 Overlay Controller管理
 支持单核2G+ IPSEC流转发能力
如下章节针对上述需求进行解读。

支持多WAN接入和智能选路

网络设备访问Internet 需要首先接入网络运营商提供的服务网络，比如家庭光猫通过拨号的方式获得IP地址的方式接入，对于SDEWAN CNF也存在相同的道理，其接入运营商网络有多种形式，如
 同时接入有线和无线（WIFI/5G）

 同时接入移动和电信

 多拨接入移动/电信

这种方式使SDEWAN CNF具备多条访问外部网络的通路，多条通路可能过主备、负载的方式进行组网。其中，对于负载型组网，区别于传统路由负载技术，在SDWAN中引入智能选路的负载技术，为不同SLA要求的业务报文选择/创造与其需求符合的通路，保障业务报文传输质量，相当于进一步将网络进行快慢车道、潮汐车道的划分。

支持接入LAN

SDEWAN CNF除了为K8S虚拟网络提供接入服务外，同时支持为本地物理网络提供接入服务，并提供物理网络和虚拟网络的通信能力。
LAN接入时，SDEWAN CNF作为Gateway提供功能包括：
 DHCP Server
 DNS代理A
 WiFi AP
 MVRF
上述功能使SDEWAN CNF作为Gateway角色管理内部网络，达成虚拟网络和物理网络的归一化管理，减少OPEX。另外，虚拟网络可同时为物理网络提供Cloud Native服务，这是一种新型的混合组网模型。

支持接入K8S CNI

SDEWAN CNF同时为Cluster网络提供接入服务，Cluster网络模型如下：

K8S网络是由多组Docker网络组成的工作集群，并在Pod为资源管理单位，Container为调度单位进行管理。在原生Docker网络中，各个Container使用Linux BR进行网络管理,并以主机为单位自成独立网络（NODE），CNI的引入使多组Node形成了超大集群网络。CNI有多种类型，如：Calico, OVN4NFV等，为Container提供跨主机的L2/L3通信服务。
SDEWAN CNF在K8S网络中作为普通的Pod运行，故受K8S网络的管理，但SDEWAN CNF同时又作为Gateway的网关角色，具备网关的一定特性。

SDEWAN CNF Pod接入Cluster网络的方式是对CNI接管，如SDEWAN CNF(VPP based)需要VPP接管CNI接口，不同的CNI提供了不同的接入方式，如TAP，vETH, MemIF等。
除此之外，接入后路由的管理也相当重要。在未接入SDEWAN CNF前，Gateway由某个Node的CNI代理，并由Linux Kernel 提供包括路由、防火墙等功能，在接入SDEWAN CNF后，原有出口通道发生变更，由Kernel变更为SDEWAN CNF。

支持IPSEC和VXLAN

Cluster Network属于内部网络，不同Cluster Network之间通信仍然属于内部网络范围。由于Cluster通常跨Internet Network，打通Cluster Network网络的方式通常采用Overlay的方式进行，本方案中需要各个Cluster Network的Gateway(即SDEWAN CNF)之间建立IPSEC Overlay Network，如果需要支持L2 Overlay，还需要支持VXLAN Over IPSec。

IPSEC用于确保Cluster间通信的安全性，并通过IKE协商密钥或手工证书的方式。VXLAN为扩展LAN，通过Over IPSec即可实现Cluster间安全的L2通信。另外，关于多播的支持，可采用MGRE Over IPSec方式。

支持被K8S CR管理

SDEWAN CNF以Pod的方式运行在K8S网络中，故受K8S的管理。K8S Pod支持包括deployment, service, volume等标准资源管理，而对于某些未扩展功能，侧通过Customer Resource的方式支持管理。

如上图所示，K8S通过Etcd数据库维护集群状态和配置数据，各个Pod通过向API Server注册服务的方式获取信息（监控者模式），K8S API Server作为中心单元负责路由所有控制流和管理流，并暴露K8S API给Kubctl和外部第三方应用。
在上述管理模型下，为了简化SDEWAN CNF的实现，将K8S管理功能进行抽离为独立Pod注册到K8S API，将其作为代理人受K8S的网络的管理，此模块为CRD Controller。

CRD Controller的分离模型为控转分离架构，降低了SDEWAN CNF的实现复杂度，所有针对SDEWAN CNF的管理由CRD Controller代理并转换为CNF支持的更简单的API。

支持被 Overlay Controller管理

单个Cluster Network通过K8S API Server管理，并由K8S API Server暴露接口给第三方应用。Overlay Controller 属于OpenNESS网络中的中心控制单元，其通过K8S API同时管理多个Cluster Network。

通常，Overlay Controller部署于Center Cloud侧，而K8S及API Server部署于内部私有网络（无公网IP）。按OpenNESS解决方案，当前需要在Center Cloud和Edge侧间打通基础网络，Overlay Network是一种方案，如上述IPSec方式。对于Hub侧（有公网IP），则无需建立Overlay Network。
Overlay Controller通过操纵K8S API实现对Cluster Pod的管理，SDEWAN CNF属于其管理范围，管理包括：
 配置IPSec tunnel
 配置ACL,FW
 配置Multi-WAN
 配置Overlay 路由

支持单核2G+ IPSEC流转发能力

对于用户态数据面(VPP/DPDK)，单核IPv4通常转发能力在6G左右（64B小包），而IPSEC性能通常不足IPv4裸转的10%，300~600M左右，无法满足2G+转发性能。
对于IA，某些网卡支持针对特定算法的硬件加速功能，如DES/AES等。针对网络转发，IPSEC流转发涉及大量的加解密运算，而这类运算会消耗掉60%以上的CPU算力，对于Intel 89XX系列网卡通常支持QAT功能，通过CPU+Nic(QAT)的交互配合，加速对IPSEC转发流量的处理，使性能达到2G+。

组网拓扑

SD-WAN组网存在两种模型：
 Hub-Spoke
 Full-Mesh
Hub-Spoke为总部+分支型组网，总部作为整个Overlay Network的Internet Gateway； Full-Mesh为星型组网，两两Cluster之间可直接互通。非典型情况下，SD-WAN组网为混合组网方式，即部分Cluster通过Hub互通，另一部分Cluster可两两互通。

上图为典型的Hub-Spoke组网，各Cluster运行对等的K8S Cluster Service，其中一个具有Public IP的Cluster作为Hub，由Overlay Controller控制整个Overlay Network，介绍如下：
 Edge Cluster运行包括APP Pod的完整K8S Service
 Hub Cluster可以仅作为Bridge，其它Service未运行
 Hub Cluster由于中转整个Overlay Network流量，性能要求较高
 每个Cluster通过K8S API Server暴露接口给第三方，比如Overlay Controller
 Overlay Controller作为Client调用K8S API管理整个Overlay Network

关于SDEWAN CNF和CNI的网络连接图，参考如下：

对接Pod所属的接口会同时会VPP接管，使Pod的出入流量经VPP管理。
备注：CNI接口未被VPP接管，由VPP新增vTAP导入Kernel。

模块组成

SDEWAN CNF定位于K8S Cluster中的APP Pod，并作为K8S中的基础网络组件（即此Pod角色为Gateway）。不同于其它基础组件（如Kube Proxy,Kublet），CNF将K8S 基础框架部分独立进行管理，新增CRD Controller。
上图为云原生模式下的模块示意图，详情请参见K8S组成。
整个Solution涉及两个主要开发模块，CNF, CRD Controller。其中SDEAN CNF由VPP + Sweetcomb + CRD Controller Adapter组成，串联工作模型如下：

 Overlay Controller – K8S API Server: K8S API
 K8S API Server – CRD Controller: K8S CR API
 CRD Controller – CRD Controller Adapter: CNF Rest API
 CRD Controller Adapter – Sweetcomb : Sysrepo Shell API
 Sweetcomb – VPP: vAPI

模块介绍

Overlay Controller

上图为两种NFV控制模型，其中基于K8S的OpenNESS的为第一种部署方式，Overlay Controller角色有定位于Controller，对于K8S网络，Controller直接通守K8S* master管理所有K8S集群。
Overlay Controller有两部分组成：SCC + SCC CNF

SCC实现整个Controller的控制逻辑，而SCC CNF则用于辅助SCC实现Overlay Controller与Edge Cluster通信。
当前实现模型下，由于K8S API Server通过HTTPs Server暴露Rest API, 但往往Edge Cluster运行于NAT之后，为了打通Overlay Controller与Edge Network需要建立tunnel实现。Overlay Controller复用了SDEWAN CNF实现了控制面tunnel的建立。
Overlay Controller定位于Overlay Network的管理和配置，包括：
 管理Tunnel
 管理FW/ACL
 管理SLA(流QoS)
 管理Multi-WAN
对于Underlay Network的管理通常作为网络开局的一部分或由ODL控制。

CRD Controller

CRD Controller用于为SDEWAN CNF转换K8S CR API：即作为适配层模块用于将K8S API转换为CNF RestAPI，从而实现对CNF的配置和管理；CRD Controller北向接收K8S API消息并将其转换为CRD Controller Adapter下发到CRD Controller Adapter模块，同时将存储配置数据到K8S etcd数据库。

根据上图所示，整个集群网络的配置由Overlay Controller负责下发到各个集群的K8S API Server，并经CRD Controller转递到CNF。

实际上CRD Controller与CNF是强耦合关系，两者作为CNF Solution的一部分。上文有介绍，CRD Controller是从CNF分离出来用于支持K8S基础服务的，实现上可采用Golang实现基础K8S通信功能，且支持管理多个CNF或多样化的CNF（如OpenWrt CNF或VPP CNF）。

CNF(VPP based)

CNF（Container Network Function）属于K8S中的普通APP Pod，其内部含多个Container,如VPP、FRR、Dnsmasq、Sweetcomb等。集成主要功能包括：
 L2/L3基础转发
 路由协议(BGP/OSPF)
 DHCP/DNS
 IPSec/IKE/ACL/VXLAN
 Netconf/Yang

SDEWAN CNF分为三个功能平面：以FRR为控制面； 以Sweetcomb为管理面，以VPP为数据面。三个平面自成Container运行于SDEWAN Pod中。

其它关联模块

K8S API Server

k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的管理，是整个集群的管理入口和数据中心。参见K8S API Server介绍。
在SDEWAN Solution中，需要扩展CR对CNF的管理，即Kubctl中新增对IPSEC、FW/ACL、Mutli-WAN的配置参数。

CNI

CNI(Container Network Interface)是一个标准的容器网络接口，通过对APP Pod提供虚拟接口的方式控制和管理集群网络。参见CNI介绍。
在SDEWAN Solution中，需要扩展SDEWAN CNF支持接入CNI，并打通CNI和CNF的路由。
PS ：从功能分层上来看，CNI和CNF都属于网络功能，两者是可以合二为一的，如Contiv CNI。

参考文档

CNI
Contiv
CNI多种类型
NFV基本概念
K8S介绍
K8S组成
K8S API Server
SDWAN到底是什么
SD-WAN技术实现方案
QAT
vAPI
OpenNESS
VPP
FRR
Sweetcomb