开源的边缘网络服务平台：OpenNESS（上）

关于开源的边缘网络服务平台OpenNESS，作者分为上下两部分进行阐述，本文主要分享上部分内容，大纲如下：
OpenNESS 的电梯间演讲OpenNESS 与 ETSI MECOpenNESS 的部署方案OpenNESS 的架构
下部分分享的内容如下：
OpenNESS 作为一个边缘应用程序管理系统OpenNESS 作为一个边缘网络的服务平台LTE CUPS 流量策略配置
OpenNESS 的电梯间演讲
OpenNESS（Open Network Edge Services Software）是一个开源的边缘应用程序管理系统，使服务提供商和企业能够在任何网络的边缘上构建、部署和操作自己的边缘应用程序（ME APP），支持通过简易的方式将运行在 Telco/Public Cloud 中的 APP 迁移到边缘。
OpenNESS is an Open Platform that enables Service Providers and Enterprises to build, deploy, and operate an Edge Services Management System on any Network Edge.
同时，OpenNESS 还是一个边缘网络的服务平台，支持在多云环境中跨越多种类型的网络平台（Network Platform，e.g. NTS、OvS、vPP）以及多种类型的访问技术（Access Technologies，e.g. S1_U、SGi、IP）。让用户能够轻松的编排和管理运行在边缘上的应用程序，并为客户端（UE）和边缘应用程序提供端到端（End to End）的网络连接服务。
An open source software toolkit to enable easy orchestration and management of edge services across diverse network platform and access technologies in multi-cloud environments.
注：端到端是一种网络连接。网络要通信，必须建立连接，不管有多远，中间要经过有多少机器，都必须在两头（源和目的）间建立连接，一旦连接建立起来，就说已经是端到端连接了，即端到端是逻辑链路。端到端是传输层的，TCP 就是用来建立端到端连接的协议。比如你要将数据从 A 传送到 E，中间可能经过 A→B→C→D→E，对于传输层来说并不知道 B，C，D的存在，传输层只认为报文数据是从 A 直接到 E 的，这就叫做端到端。一旦通信完成，这个端到端的连接就会释放，物理线路可能又被别的应用用来建立连接了。
OpenNESS 与 ETSI MEC
简而言之，OpenNESS 就是一个可以充当 ETSI MEC 参考模型中的 MEPM、MEP 以及 Data Plane 角色的平台级开源软件。
MEPM（ME platform manager，移动边缘平台管理器）：具有 MEP 元素管理、ME APP 生命周期管理以及 ME APP 的规则与需求管理等功能。
ME APP 生命周期管理：包括 ME APP 的创建和终止，并且为 MEO 上报 ME APP 相关事件的指示消息。
ME APP 规则与需求管理：包括身份认证、流量规则、DNS 配置和 UE 切换导致的冲突协调（非合作博弈，纳什均衡算法）等。
MEP（ME platform，移动边缘平台）：从 MEPM、ME APP 或 ME Service（支撑 MEP 的底层 Services）处接收流量转发规则（Traffic Rules），并且基于转发规则向 Dataplane（数据面）下达转发指令。另外，MEP 还支持本地 DNS 服务、代理服务器的配置，可以将数据流量重定向到预期的 ME APP 或 ME Service。MEP 还可以通过 Mp3 参考点与其他的 MEP 进行通信，在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 MEP 互联协作的基础。
ME APP（移动边缘应用） ：是运行在 ME VIM 上的 Application 实例，ME APP 通过 Mp1 参考点与 MEP 相互通信。Mp1 参考点要求提供 ME APP 可用性（Availability）标识，发生 UE 切换时为用户准备或重定位 ME APP 会话状态等额外功能。

根据 ETSI MEC 参考模型，OpenNESS 采用了 Edge Controller Software（简称 Controller）与 Edge Platform Software（简称 Edge）分离的分布式软件架构设计思路。其中，Edge Controller Software 充当着 MEPM 的角色运行在 Data Center 或 Cloud 中，而 Edge Platform Software 则充当 MEP 以及 Dataplane 的角色运行在任何 Network Edge 之上，包括：uCPE（通用客户端设备）、vRAN（虚拟无线接入网）以及 NGCO（新一代的电信机房，或称中央办公室）。

Edge Controller Software 的功能清单
前端 WebUI、用户账号管理、边缘应用镜像注册、EPC CUPS核心网配置、边缘节点生命周期管理、边缘应用生命周期管理、边缘虚拟化基础设施管理、监控。
Web UI front endUser account managementEdge compute application image repositoryCore Network ConfigurationEdge Node Lifecycle ManagementEdge Application Lifecycle ManagementEdge virtualization infrastructure managementTelemetryEdge Platform Software 的功能清单
Edge Node 注册、Edge Node 网络接口配置、本地 DNS 服务、Edge Node 虚拟化基础设施、ME APP 流量策略、数据平面服务、应用认证。

Edge Node Enrolling（Edge Node 注册）：在 Edge Node 首次启动时，需要注册到 Controller 中。由 ELA 完成。前提是需要拿到 Controller 颁发的 CA 证书来建立 TLS API 通信。
Edge node interface configuration（Edge Node 网络接口配置）：在 Edge Node 注册到 Controller 之后，Edge Node 会将自身的 Network Interface 信息上报到 Controller。以此作为配置 Upstream、Downstream 或者 local breakout 网口（Local Break-out Port，LBP）的依据。由 ELA 完成。
DNS service（DNS 服务）：为 ME APP 提供 DNS 服务，属于数据面的 DNS。基于 Go DNS library 实现。
Edge Node Virtualization infrastructure（Edge Node 虚拟化基础设施）：从 Controller/NFV-O 接收启动或停止 ME APP VI 的请求，并执行操作。由 EVA 完成。
Edge application traffic policy（ME APP 流量策略）：为 ME APP 设置数据面流量转发策略。由 EDA 完成。
Data Plane Service（数据平面服务）：通过 Edge Node 上运行的 NTS 服务，将数据面的流量导向 ME APP 或 LBP APP。使用了 DPDK 进行 I/O 加速。
Application Authentication（应用认证）：对 ME APP 进行身份认证/鉴权，以确定 APP 之间具有权限可被调用。只有在 ME APP 打算调用 Edge Application Authentication APIs 时才会进行认证，支持 TLS 连接。需要注意的是，Edge Application Authentication APIs 仅对 Native ME APP 有效，因为 LBP APP 和 Ported ME APP 都不会在 EAA 中进行注册。
NOTE：Edge Node 资源使用要求
所有非关键/非实时（non-critical/non-realtime）的微服务推荐绑定在 Core 0 上运行。
NTS Dataplane 微服务和 DPDK PMD 推荐进行 CPU 绑定。
为 DPDK 库使用大页内存。
使用 RT kernel，在 VNFs 和 APPs 共存的场景中。
OpenNESS 的部署方案
OpenNESS 提供了两种参考部署方案，On-Premise Edge 和 Network Edge。两者最明显的标准在于 VI（虚拟化基础设施）的提供形式，前者提供的是本地的 VI，即 Edge Node 之上的 Docker/Libvirt；而后者提供的则是 MEC VIM 基础设施。用户应该针对不同的场景，考虑使用不同的部署方案。
On-Premise Edge Deployment
On-Premise Edge Deployment，又称为企业级部署方式，Edge Platform Software 部署在 uCEP 上，处于企业网络范围内，而 Edge Controller Software 则部署在 Telco/Public Cloud 之上。

On-Premise Edge Deployment 面向的是将 Edge Node 作为 IaaS 子系统的应用场景，是中心业务向边缘的延伸。在该场景中，用户的需求只是单纯的希望 APP 可以尽量的靠近其服务的终端，来处理一些实时性要求比较强的业务。
所以只需要为 ME APP 提供一个可用于运行的 x86 服务器作为 Edge Node 即可，Edge Platform Software 直接通过 Edge Node 上的 Docker/Libvirt 部署 VI，无需添加 VIM。也因此，该部署方式也只能针对一个租户来使用，而并非是专门为 MEC 而设计的部署方式（MEC 要求多租户可以使用同一边缘云）。通过应用于客户办公室、工厂、体育场或其他单租户设施中。

Network Edge Deployment
Network Edge Deployment，Edge Platform Software 部署在 NFVI 之上，运行于 NGCO 或 vRAM 的无线接入聚合点（Wireless Access aggregation point）中。而 Edge Controller Software 则同样部署在 Telco/Public Cloud 之上。

该部署方式不再面向单一或小规模的 Edge Node，而是拥有针对 MEC 的虚拟化基础设施管理系统（VIM），即：边缘计算基础设施（OpenStack/Kubernets）。要求边缘计算基础设施位于网络运营商的设施内，并作为数据网络（Data Network，包含接入网，核心网以及边缘计算基础设施）的一部分，与 OSS 集成在一起。应用于多租户场景，并且规模非常大。Edge Controller Software 不仅可以管理边缘计算基础架构，还可以通过网络连接管理网络基础架构。是更加贴近于 ETSI MEC 参考模型的部署方式。

OpenNESS 的架构
抽象架构
首先看 OpenNESS 的抽象架构与接口类型，完全符合 ETSI MEC 参考架构标准。

红色框为 OpenNESS 核心组件：Edge Controller Software、Edge Platform Software 以及 Data Plane；
绿色框为 ME APP：可以分为 Edge Native APP 和 Public Cloud APP。
Edge Native APP：原生在 Edge Platform 上运行的 APP，这是我们讨论的重点。
Public Cloud APP：即从公有云迁移到 Edge Platform 的 APP。
蓝色框为 OpenNESS 与蜂窝网络（Cellular Network）集成所需要的互补性商业解决方案：比如 MEO、VIM 等等。
ME APP 的类型
从 ME APP 的作用区别，又可以分为：
Producer APP（生产者应用）：又称 Edge services，为其他 ME APP（Consumer APP）提供服务。 它不直接为最终用户提供服务。e.g. 定位服务，地图服务，代码编译服务等等。
调用 Producer APP 必须要进行身份认证（Authenticate）以及获取 TLS。
Producer APP 必须被其他 ME APP 发现后才能够被调用，而 Producer APP 被发现的前提是要激活它们。
Producer APP 必须具有若干个用于提供 Notification Update（更新通知）的字段，以此来传递消息。
Consumer APP（消费者应用）：直接为最终用户提供服务，Consumer APP 可以选择订阅若干个 Producer APP 为其提供服务。E.g. CDN 服务，AR 服务，VR 服务，视频服务等等。
如果 Consumer APP 无需调用 Edge Application APIs，也就无需进行身份认证。Edge Application APIs 负责为所有 ME APP 提供 API Endpoint，继而对外提供 Services。
Consumer APP 可以订阅若干个 Producer APP，后续版本中要会加入创建 ACL（访问控制列表）的功能。
Consumer APP 与 Producer APP 之间的 Notification Update 通过 Web Socket Connection 来完成，Connection 由 Consumer APP 发起创建。这种方式还可以用于 ME APP 与其他的 NFVI 组件（e.g. OVS/VPP/NIC-VF）进行通信。
软件架构
在看 OpenNESS 的软件架构，Edge Controller Software 和 Edge Platform Software 均由一组特定的微服务组成，微服务之间使用 gRPC（Google Remote Procedure Calls）进行通信。

WebUI Font END：Web 前端操作界面。
Edge Platform/Controller Gateway：Edge Controller Software 与 Edge Platform Software 之间进行通信的物理路由网关。
EAA（Edge Application Agent）：映射到 ETSI MEC Mp1 参考点，作为 ME APP 与 MEP 交互的媒介。Mp1 参考点要求可以标识 ME APP 的可用性、会话状态重定位等功能。
EAA 提供了 Edge Application APIs 给 ME APP 调用，提供服务发现，服务注册，服务间通信等功能，并且支持验证 ME APP 的可用性，支持 UE 切换（基站）时需求的 ME APP 会话状态重定位。激活从 Edge Controller Software（MEPM）通过 ELA 下发的针对 ME APP 的 Traffic Rules 和 DNS rules 配置。
EAA 提供了 Edge Application Authentication APIs 对所有打算调用 Edge Application APIs 的 ME APP 进行身份认证，在验证了 ME APP 的身份之后会向该 APP 颁发 TLS 证书，正式建立通信通道。
ELA（Edge LifeCycle Agent）：映射到 ETSI MEC Mm5 参考点，作为 MEPM 和 MEP 交互的媒介。Mm5 参考点要求实现对 MEP 的配置、对 Traffic Rules 的配置，并且负责管理 ME APP 会话状态重定位方式以及支持 ME APP 的生命周期管理。
ELA 提供了 Edge Lifecycle Management APIs 供 Edge Controller Software（MEPM）调用，进行 MEP 配置的下发（Configuration of Edge Platform）等操作；
ELA 通过调用 EAA 提供的 Edge Application APIs 下发的针对 ME APP 的 Traffic Rules 和 DNS rules 配置，同时也支持 ME APP 的会话状态重定位等功能；
ELA 通过调用 EVA 提供的 Edge Virtualization Infrastructure APIs 来完成 ME APP 的生命周期管理；
ELA 通过调用 EDA（NTS）来完成针对 Upstream/Downstream Interface 的 Traffic Rules 和 DNS rules 配置的下发。
EVA（Edge virtualization Agent）：映射到 ETSI MEC Mm6 和 Mm7 参考点。其中 Mm6 作为 MEPM 和 VIM 的交互媒介，要求支持收集 VIM 虚拟资源信息以及 VIM 虚拟资源使用和管理；Mm7 作为 VIM 和 Dataplane 的交互媒介，完成数据流量的过滤和转发。
EVA 提供了 Edge Virtualization Infrastructure APIs，支持虚拟化资源的管理。需要注意的是，在 OpenNESS 中，虚拟化资源区分为 On-Premise Edge Deployment 中的 Edge Node（Docker/Libvirt）或者是 Network Edge Deployment 中的 MEC VIM（OpenStack/Kubernets）。为了实现后者，在 Edge Controller Software 实现了一个 External EVA Service， 该 Service 会直接调用 External Orchestrator（OpenStack/Kubernets）进行 VI 的部署。
需要注意的是，OpenNESS 没有实现 Mm7 参考点，而是直接通过 EDA 对 NTS 的调用来完成数据转发规则的配置。
EDA（Edge Dataplane Agent）：映射到 ETSI MEC Mp2 参考点，作为 MEP 和 Data plane 之间的交互媒介。在 ME APP，网络，ME Service 之间完成数据路由转发。
OpenNESS 实现了 EDA 来对接 NTS。NTS 本身的 API 是没有保留的，所以 EDA 可以看作是 NTS 的 API。
NTS Dataplane（Network Transport Service Data Plane）：数据面转发模块，将指定的流量规则应用到 Edge Platform 上，实现数据分发。
DNS Server：作为 Edge Platform DNS 服务器，应用于 ME APP。而对于不运行在 Edge Platform 的 APPs，则充当 DNS 转发器（forwarder）。
LTE/CUPS Agent：对接 EPC Control Plane，Edge Controller 用于为 Edge Platform 配置 EPC Control Plane 和 EPC User Plane。

对于往返于 ME APP 与 EAA 之间、往返于 Edge Controller Software 与 EPC CP 之间的交互使用了 RESTful API。OpenNESS 就是通过微服务之间的交互，微服务与 ME APP 之间的交互、微服务于其他第三方商业解决方案（e.g. VIM、MEO、NFVO）之间的交互来完成其功能的。
On-Premise Edge Deployment 的软件架构：

Network Edge Deployment 的软件架构：

Edge Application APIs
Edge Service Activation/Deactivation（边缘服务注册与激活/停用）：该 API Endpoint 使 Producer APP 可以在 Edge Platform 上注册并激活或者停用。执行此 API 之后，Producer APP 才可以被 Consumer APP 发现并使用。e.g. 当 Location Service Producer APP（定位服务提供者应用程序）部署完成后，马上就会调用此接口。
Edge Service Discovery（边缘服务发现）：该 API Endpoint 使 Consumer APP 可以发现 Edge Platform 上所有已激活的 Producer APP 清单。e.g. CDN Application 通过此接口发现 Edge Platform 上的 Location Service Producer APP。
Edge Service Subscription/Unsubscription（边缘服务订阅/取消订阅）：该 API Endpoint 使 Consumer APP 可以订阅/取消订阅指定的 Producer APP，并以此获取 Producer APP 的更新通知。e.g. CDN Application 可以订阅 Location Service Producer APP 以获得更新通知。
Edge Service Notification update（边缘服务更新通知）：该 API Endpoint 的本质是 Web Socket，Socket Connection 由打算订阅 Producer APP 的 Consumer APP 创建。当 Producer APP 有更新时，就通过该 Connection 通知（推送）给 Consumer APP。e.g. 当 Location Service 有更新时，就会推送给订阅了 Location Service Producer APP 的 CDN Application。
Edge Service data update（边缘服务数据更新发布）：该 API Endpoint 使 Producer APP 可以将其更新的数据发布到 Edge Platform。e.g. Location Service Producer APP 使用该 API 将用户的位置更新数据发布到 Edge Platform。
Edge Service list subscription（边缘服务订购列表）：该 API Endpoint 使 Consumer APP 获得其可以使用的 Producer APP 清单。e.g. CDN Application 可以通过该 API 得知其是否订阅了 Local Service Application。
Edge Application APIs 作为 Producer APP 与 Consumer APP 之间的消息总线：