基于可编程网络的UPF边缘调度机制研究

摘要

【目的】介绍了基于可编程网络的UPF边缘调度机制,在开源网络操作系统中实现了网元功能和UPF网元统一调度。该方式旨在实现UPF网元下沉到边缘开放网络设备上,形成UPF网元在边缘场景下和可编程网络融合。现有的网络设备大多数只提供有限的网络接入方式和网络功能,面向边缘场景多样性需求,现有的网络接入和资源调度方式难以满足场景需求。【方法】从目前主流的开源网络操作系统SONiC出发,基于容器技术实现网络功能的编排调度能力以及UPF的集成方法,阐述了以云原生方式来实现SONiC和UPF融合资源调度方案。【结果】基于该方案,实现了面向边缘场景下的UPF下沉到可编程网络设备上进行统一调度和管理,并且做了可行性分析。【局限】作为基于可编程网络的UPF边缘调度整体技术架构,实现了UPF网元在边缘侧的网络设备上的部署和调度,如何通过UPF网元N4接口的开放和解耦来实现远程管理,通过该方案如何构建确定性网络以及云边协同的算力资源管理是其下一步需要解决的重要问题。【结论】基于可编程网络的UPF边缘调度方案可以广泛应用于物联网、车联网、智慧城市等领域,进一步增强了边缘侧的网络开放能力和算力调度能力,有助于解决我国智能产业领域在边缘侧的网络连接能力和算力不足等现实问题。

关键词： 可编程网络; 容器技术; UPF; 边缘计算

引言

随着互联网应用场景的不断增长,对于网络的需求呈现爆发式增长,传统的网络能力已经无法满足面向互联网灵活多变的业务需求,而SDN技术的产生使得传统的网络功能实现了控制和转发分离,加强了网络的实时控制能力[1]。可编程网络技术的兴起,又进一步实现了网络设备的软硬件分类,网元功能虚拟化可以部署并运行在通用X86处理器或者专有芯片上,从而使得网络设备能够承载更多不同的网元功能。

另一方面,5G移动网络的不断普及,尤其是5G网络架构的云原生转型,使得传统的核心网和接入网等网元进一步解耦。核心网的网元,尤其是UPF等转发面的网元可以结合不同的边缘场景需求,进一步下沉到边缘端,利用开放的融合网络设备来承载UPF（User Plane Function,用户面功能）的转发功能,通过开放网络和5G移动网络共同构建网络切片和确定性网络等能力,满足不同行业应用场景需求[2],同时运营商也可以提供不同的网络质量保障能力,通过这种差异化的网络服务质量来实现不同的网络服务。

随着边缘计算在行业应用的不断发展,基于固移融合的开放网络技术目前是行业内研究的重点。而异构算力的普及,使得在同一个网络硬件设备上往往可以集成不同的处理单元,基于轻量化云原生的算力调度可以轻松地将不同的网元功能调度不同的处理单元运行实现自定义的网络功能,同时还能够开放一部分的算力资源用于处理边缘计算场景下的计算需求[3]。而本文结合上述的行业发展热点,采用开源的可编程网络架构SONiC和UPF融合的方式,利用云原生的方式来实现异构算力的调度能力,并提出整体的技术架构和解决方案,从而实现了在开源可编程网络设备中集成了承载网的转发能力和5G UPF的转发能力,并且实现了异构算力的整体调度能力。

1 SONiC介绍

SONiC（Software for Open Networking in the Cloud）是一款开源网络操作系统,由微软于2016年发起,并在一年后贡献给了开放计算项目（OCP）。SONiC是基于Linux建立在交换机抽象接口（SAI）之上进行开发,并且可以运行在各种交换机和ASIC芯片上。SONiC是内核补丁、设备驱动程序、实用程序等的集合,旨在解决云网络的可靠性和可用性以及可扩展性的问题。

1.1 SONiC整体技术架构

SONiC构建在Linux系统之上,并且利用键值数据库、容器技术、标准化硬件接口定义等技术,使其成为一个标准软硬件接口、模块松耦合、高可靠、易于扩展、开源开放的网络软件系统。

如文献[4]所描述,SONiC系统的体系结构所包含的模块通过集中式和可扩展的基础结构相互交互[4]。整个基础架构的各模块主要依赖于Redis数据库来实现交互。其中数据库提供两个方面的功能：一方面,提供独立于语言接口的键值数据库功能;另一方面,用于所有各子系统之间的数据持久性、复制和多进程通信的方法。

同时,随着容器技术的应用,SONiC将每个模块实现了容器化封装,并且每个组件都与平台完全解耦。SONiC的主要技术架构如图1所示。

图1

图1   SONiC技术架构图

Fig. 1   Technology architecture of SONiC

依据上述SONiC技术架构图,其整体技术架构分为三层：硬件层主要包含各种硬件以及asic芯片等;操作系统内核主要是集成了面向平台、网络和asic芯片的驱动等;而在用户面则包含了整个SONiC的主要容器化的组件功能。其主要组件包括以下几个方面：

●TEAMDED容器 ：在设备中负责运行链接聚合功能（LAG）。基于Linux的LAG协议的开源实现,允许team子系统和南向子系统之间进行交互;

●PMON容器：负责运行“sensored”的守护进程,该守护进程用于定期记录硬件组件中的传感器读数并在发出警报时触发警报。Pmon容器还托管“fancontrol”进程,从相应的平台驱动程序中收集与风扇相关的状态;

●SNMP容器：托管snmp功能 。该组件包括两个相关的进程（Snmpd进程和Snmp_ax_impl ）;

●DHCP容器：负责将DHCP请求从没有DHCP服务器的子网中继到其他子网上的一台或多台DHCP服务器中;

●LLDP容器：负责承载lldp功能,主要负责运行Lldp、Lldp_syncd以及Lldpmgr进程;

●BGP容器：负责运行支持的路由堆栈之一。虽然该网络功能容器是BGP命名的,但是路由堆栈也可以支持其他各种协议（如ospf、isis、ldp等）。该容器主要包括：bgpd、zebra、fpmsyncd等进程;

●数据库容器：托管redis数据库引擎,应用程序可以通过redis-daemon来访问数据库。redis引擎托管的主要数据库包括：APPL_DB、CONFIG_DB、ASIC_DB、COUNTERS_DB等;

●SWSS容器：交换状态服务（Swss）容器包含一组工具,允许所有SONiC模块之间进行有效通信。和数据库容器用于提供存储功能不同,Swss主要提供机制来促进所有不同模块之间的通信和仲裁;

●SYNCD容器：同步（Syncd）容器主要负责提供一种机制,允许交换机的网络状态与交换机的实际硬件/ASIC进行同步,包括交换机的ASIC当前状态的初始化、配置和收集等;

●CLI/sonic-cfggen：负责提供CLI功能和系统配置功能。

1.2 SONiC SAI接口抽象

根据文献[5]所述,交换机抽象接口（Switch Abstraction Interface, SAI）是2015年微软向开放计算项目（Open Compute Project, OCP）开源的项目,参与的厂商主要包括：Centec、Intel/Barefoot、Dell、HP、Broadcom、Mellanox、Cavium以及Metaswitch等公司。SAI主要致力于在ASIC之上提供一个与硬件无关的抽象标准化API接口,为上层应用和开发者提供更便捷、灵活的底层资源调用接口[5]。

在SONiC之前,硬件的底层复杂性与协议栈软件之间的紧耦合,剥夺了我们为网络需求选择最佳硬件和软件组合的自由。而芯片厂商参与SAI的定义和开发,为SONiC屏蔽了不同芯片SDK API的差异,从而使基础设施平台简洁、一致、稳定。标准化的SAI API还允许网络硬件提供商开发创新的硬件架构,满足硬件产品快速的研发需求。此外,SAI还能够让系统厂商专注在系统协议的开发,而不需要重复适配各种芯片,满足软件产品快速迭代开发需求。

因此基于SAI接口的可编程网络白盒设备的软件开发工具包（Software Development Kit,SDK）整体架构如图2所示。

图2

图2   SDK架构图

Fig. 2   Technology architecture on SDK

基于上述架构,SDK以芯片硬件分层封装的形式,逐渐对上层应用提供统一的适配层和调用接口,并且遵守最小化、完整性、直观化、易记忆、简单易用的接口设计原则,进一步降低上层开发人员的应用开发门槛,同时SDK能够尽可能地适配不同的操作系统平台和应用,从而便于移植和集成。

2 基于可编程网络的UPF边缘调度方案

随着白盒网络设备技术的发展,从传统的网络设备主要基于专有网络芯片作为主要处理单元专门实现数据转发等。如文献[6]、[7]所述,目前行业内白盒网络设备普遍采用“MCU+ASIC”的SOC架构。其中MCU作为整个系统的管理单元主要采用ARM、X86等通用处理单元,负责设备整体的资源调度和消息处理;而ASIC作为专有芯片主要负责数据处理和数据转发等[6]。另一方面,随着云原生技术的发展,在边缘设备终端上逐渐采用容器化的方式来实现底层资源的管理和上层应用服务化能力的编排,从而可以实现算力资源的弹性扩缩容以及服务功能的敏捷管理[7]。因此本文采用轻量化Kubernetes来实现白盒网络设备的资源调度,实现SONiC的容器化封装的网元和UPF容器化封装的网元调度到不同的处理单元,并且在服务编排层实现了承载网的网络转发功能和UPF转发功能的融合。

2.1 整体技术架构

在面向可编程网络的UPF边缘调度架构中,由于传统SONiC和UPF分别在不同的技术架构中实现了各自的容器化部署方式以及数据库管理方式。另一方面,面向边缘端的白盒网络设备算力资源存在异构性和有限性等问题[7],因此在实现SONiC和UPF融合调度的过程中,需要实现调度层面和数据层面的融合。本文针对边缘场景下资源有限的问题,采用统一的调度层和数据管理层来实现SONiC和UPF的融合方案,通过统一的Kubernetes调度平台为SONiC网元和UPF网元分别创建不同的命名空间（namespace）,并且调度到不同的处理单元上运行,通过统一的数据库层面来实现SONiC和UPF内部的数据管理能力的共平面管理,其整体的技术架构如图3所示。

图3

图3   可编程网络整体技术架构

Fig. 3   Technology architecture on programmable network

依据上述整体技术架构,可编程网络设备管控平台实现了对可编程网络设备的应用管控和功能管控。根据场景需求,5G核心网通过向可编程网络设备管控平台发送UPF网元远程调度的指令,触发管控平台将UPF网元下沉到边缘可编程网络设备中进行部署,并且通过N4接口实现和5G核心网的纳管。而在可编程网络设备中基于统一的Kubernetes服务编排平台实现了对底层的异构算力的统一管理和编排调度,在算力调度方面,根据SONiC和UPF网元功能的不同,UPF网元通过Kubernetes调度平台调度到CPU运行,而SONiC网元则通过Asic驱动调度到asic芯片上运行。并且在硬件层构建数据通道从而打通承载网网元和移动网网元转发面的数据交互流程,从而使得网络设备具备了承载网和UPF的数据转发能力。而在数据操作和共享方面,整体技术架构在中间的数据层提供统一的数据库操作引擎用于支撑上层SONiC能力和UPF能力对于数据操作的要求,通过上层提供统一的数据库访问接口,SONiC和UPF根据自身网元功能和数据访问需求调用不同的接口来访问数据库,而数据层可以根据需要集成Redis和Etcd等键值数据库功能,或者通用的MySQL数据库功能,从而使得数据层可以根据需求进行横向扩展。由于对上层应用提供统一的接口封装,随着SONiC网元功能的进一步解耦以及和UPF的进一步融合,在数据访问上构建统一的数据访问对象,可以进一步整合底层数据库资源,通过统一的数据库或者配置参数表来完成数据访问和管理,从而可以进一步节约硬件资源和提高数据访问效率。

因此,基于上述整体技术架构,主要包含如下几个方面：

●硬件层：主要集成网络设备不同的处理芯片和相关硬件,包括通用处理芯片（CPU、arm）、专有芯片（Asic）、转发芯片以及可编程芯片等;

●硬件驱动层：主要围绕底层的硬件芯片提供必要的驱动程序,目前在整体的SONiC框架中,主要依托SONiC的SDK架构和开源SAI来集成和扩展不同芯片的驱动程序,通过松耦合的方式来集成;

●操作系统层：目前主要提供通用的或者定制化的Linux操作系统,并且集成SONiC SDK以便兼容底层的硬件驱动,同时集成容器引擎以便为上层提供容器化调度能力;

●调度编排层：主要基于Kubernetes来实现统一的底层资源管理和上层的容器化服务编排管理;

●数据层：主要统一提供数据库访问,集成了包括Redis、Etcd、MySQL等数据库处理能力,并且对上层提供统一的数据访问接口,从而可以实现上层网元访问数据库能力;

●能力层：主要集成了SONiC的网元功能和UPF的网元功能,提供承载网和移动网的数据转发能力;

●用户面：主要是面向外部提供基于SONiC的网络控制能力和5G移动网的控制面的外部访问能力。

基于网络设备的分层管理技术架构,本文实现了面向可编程网络设备的UPF调度和固移融合。通过基于网络设备上的异构算力来分别承载不同的网元功能,实现了在资源调度管理方面的共平面;另一方面,通过集中的数据层来实现数据处理的集中,并且通过统一的方位接口可以实现不同的网元功能集中实现数据访问和处理,为后续不同架构的网元之间融合提供统一的数据访问能力。

2.2 网元功能调度机制

在网元功能调度机制方面,本文主要采用Kubernetes来实现不同的网元功能在不同的处理单元上进行执行。通过Kubernetes为SONiC和UPF创建不同的命名空间（namespace）,在不同的namespace环境中,Kubernetes可以调度SONiC或者UPF的网元功能在不同的处理单元上执行。从而可以实现不同网元功能的逻辑隔离,同时在网元容器创建过程中,通过脚本指定CRD资源来实现网元容器的处理单元,具体的调度机制如图4所示。

图4

图4   网元容器调度机制

Fig. 4   scheduling mechanism on network element container

基于上述网元容器调度机制,通过Kubernetes分别创建了两个namespace,并且在sonic的命名空间中创建了swss网元功能,同时为该网元功能制定了处理单元为asic专有芯片,副本为一;另外在5gc-upf的命名空间中创建upf的网元功能upfd用于实现upf数据的转发进程,同时为该进程指定了处理单元分别在不同的处理器上运行,包括在通用处理器CPU上运行,以及在FPGA的智能加速卡上运行,用于加速UPF转发面的数据处理能力。该脚本通过Kubelet可以将相应的网元通过驱动层（Driver）分别在指定的处理单元上运行,从而实现了网元功能的资源调度和运行。

2.3 数据交互机制

为了实现UPF在Kubernetes云原生平台上的部署,通过Kubernetes的容器网络接口（container network interface, CNI）以及容器运行接口（container runtime interface, CRI）来集成UPF网元功能。同时在UPF网元转发过程中,考虑到UPF转发面需求的特殊性,基于控制与转发的UPF模式,本文在操作系统层面预留片上资源以供UPF后续在部署和转发过程使用,从而可以压缩SONiC网元在注册时所占用的资源空间,并且预留的数据共享空间直接交付给UPF模块进行使用,提高数据转发效率。SONiC在SAI基础上封装PRC接口供UPF调用,UPF模块调用SAI接口在规定的范围内使用片上资源,也可以直接通过SAI接口获取相应的状态和表项信息,UPF模块可以通过SAI来注册自己的报文处理回调函数进行报文处理。从而实现了UPF和SONiC之间的互通,其交互机制如图5所示。

图5

图5   数据交互流程图

Fig. 5   Data exchange process

基于上述数据交互流程图,SONiC通过Netconfig/CLI向操作系统用户提供外部接口,并且通过网络服务配置模块调用底层的svc模块实现对硬件网卡和芯片资源的访问。而UPF经过SONiC访问底层资源的过程中,通过硬件网卡和芯片资源实现在SAI的注册,实现了控制层面的应用调用注册和管理,并且在数据转发层面,在Linux user层面专门为用户创建一个数据包的资源空间,该资源空间负责打通UPF模块和SAI之间的数据通道,UPF模块将转发数据存放在该空间里面,并且通过该空间和SAI进行互通,再通过底层的硬件芯片进行数据转发,从而实现了UPF和SONiC之间的数据交互。

通过这种方式,在操作系统层面构建一个资源共享空间来实现UPF和SONiC之间的数据交互,从整体技术架构来看,整个交互流程只需要在操作系统层面划定固定的数据共享空间用于数据转发,对本身的硬件架构和软件架构改动较小。另一方面,由于网络设备自身的资源空间有限,需要在操作系统层划分特定的空间来进行数据转发,在一定程度上影响系统本身的运行效率。同时相比于硬件层面的数据传输,片上系统级别的数据软交换在数据传输性能和传输速率方面还存在一定的劣势。因此基于本文的整体技术架构和业务流程,在具体的实现方面,主要采用两种方式来实现：（1）通过扩展网络设备的计算能力,增加相应的存储和计算板卡来增加算力;（2）通过建立计算单元和专有芯片Asic之间的硬件数据通道采用FPGA等硬件加速芯片来满足硬件转发的可扩展性等,从而实现硬件的数据转发能力和数据加速处理能力。

3 可行性分析

可编程网络设备硬件性能的不断提升,打破了设备本身的计算瓶颈,并且异构SoC芯片架构设计的广泛采用以及加速卡在网络设备上的集成,不断增强网络设备本身的计算能力,因此已经完全能够满足不同场景的边缘应用和数据转发处理能力[8]。另一方面,开源软件SONiC可编程网络架构的不断发展,使得SONiC在底层集成各种芯片的驱动并且对上层应用提供统一的资源封装进行调用,同时在网元功能的服务编排调度架构中积极引入云原生技术来实现调度和服务编排,从而实现整体架构的松耦合集成方式,便于弹性扩展和横向扩容,可以根据不同的场景需求来进行组合[9]。

本文基于SONiC开放软件架构提出了面向边缘场景的可编程网络的UPF边缘调度整体技术架构和相关数据交互流程。其中在面向边缘网络设备架构中,结合不同的场景需求往往在底层硬件的设备形态各异,并且软件架构类型也不尽相同。传统的嵌入式系统在硬件系统开发和软件移植等方面,不同的平台往往开发部署模式都不相同,而本文基于三个方面来分析所提出的整体技术方案的可行性。

（1）硬件兼容性

相比与传统的嵌入式系统网络功能开发主要基于底层硬件平台和操作系统,开源SONiC架构通过SAI接口封装了底层硬件驱动,并且对上层应用统一提供开放接口进行调用,随着SONiC版本升级和迭代,目前最新版本已经集成了主流的Asic芯片驱动和SDK能力,因此在系统部署和运行过程中,上层网络功能进一步和底层硬件解耦,系统不需要关心底层硬件的差异性,而是通过驱动层来访问底层硬件资源。

另一方面,网元功能实现了容器化封装,并由云原生平台来实现统一的底层资源调度和上层服务编排[10]。而底层的容器引擎继承操作系统层的内核和驱动,对上层提供了标准的OCI接口和容器运行时,因此也进一步屏蔽了底层硬件的差异性,实现不同硬件的兼容性。

（2）数据交互性

基于可编程网络的UPF边缘调度机制在网络设备上实现了承载网转发面和移动网转发面的数据互通。本文所提出的基于SONiC的共享数据包转发机制,在操作系统层面预先开辟为用户创建一个数据包的资源空间,该资源空间用于UPF模块的数据转发。并且资源空间和SONiC的SAI接口进行对接,从而实现了UPF通过SAI接口向底层Asic专用芯片转发数据从而实现了数据互通。

随着硬件性能的提升以及硬件架构设计的改进,在整体的技术方案中可以引入基于FPGA作为硬件的数据转发通道,以加速卡的形态来实现硬件级别的数据转发,从而在转发效率上会进一步提升[11]。

（3）UPF N4接口解耦和SMF纳管

对于UPF下沉到边缘侧的网络设备,一方面需要和边缘网络设备建立数据互通能力,从而打通移动网数据转发面和承载网数据转发面的数据通道,从而更好的实现面向边缘固移融合场景下的数据流量融合 。但是UPF作为整体5G核心网SBA架构下的转发面网元功能随边缘设备能够调度和下沉到边缘数据中心用于流量转发,但是在面向上层5G核心网控制面网元管理方面,现有的行业解决方案和相关标准主要是通过N4接口解耦的方式来对外暴露,以便上层的SMF进行纳管和调用。另一方面,推进N4接口解耦能够进一步实现5G核心网的C/U分离,可以实现UPF适配不同方案的SMF纳管能力,并且通过制定统一的接口实现方案,达到解耦的目的,从而使得基于可编程网络的UPF边缘调度方案可以适配不同方案的5G核心网接入方案,减少了对SMF的影响,也有利于现网环境的部署和实施。

4 应用场景

随着工业互联网以及物联网等行业应用的不断发展,很多实际落地场景中对于网络接入有特殊的要求,比如需要具备承载网和5G移动网等两种网络接入方式,要求提供网络切片、确定性等网络质量保障[12]。以智慧城市业务场景下的可编程网络UPF边缘调度为例,智慧交通系统以及车载系统一方面在保证低延时的数据处理需求的情况下,需要将数据和控制尽可能的保证在本地进行处理,同时需要通过UPF和承载网实现多种网络连接方式从而实现低时延的确定性网络连接功能;另一方面,由于车载系统本身的计算和存储能力有限,因此也需要基于正如本文所述的基于云原生等轻量级的资源调度系统来实现承载系统的资源管理与应用运行,具体如图6所示。

图6

图6   面向智能驾驶的SONiC算网边缘调度

Fig. 6   Resource scheduling of SONiC computing network for intelligent driving

 

5 结论和展望

可编程网络技术的发展,进一步打开了面向网络的开放能力,将传统的黑盒式网络设备进一步演变为面向计算和网络统一承载的白盒算网融合设备[13]。未来算网融合设备将广泛的边缘计算节点能够纳入到统一的资源管理,提供了承载网和移动网等多种网络接入方式,从而在网络接入方面可以保障网络确定性、网络时延以及网络传输质量等。同时,在算网融合设备中引入嵌入式设备管理和自主资源调度机制,改变了传统的嵌入式设备只能被动接受服务器制定和上传数据采集等模式,使得嵌入式设备集群更具有自适应能力,也为未来的异构算力的能力开放以及神经网络架构下的深度学习分层在边缘设备集群上的部署和运行,以及边缘侧设备的自主学习能力和智能交互提供了可能。随着未来具备AI能力的专有芯片的发展和普及,基于可编程网络的算网融合设备除了在数据中心和边缘数据中心的网络中作为网络转发面设备进行资源纳管外,对于边缘侧设备的自主学习能力和自适应能力会提出更高的要求[14]。通过本文所提出的基于可编程网络的UPF调度机制实现算网融合设备技术架构方案的研究,可以更好地实现可编程网络和移动网络统一接入的算网融合应用在边缘计算、物联网、车联网等应用场景下的统一网络接入,资源调度管理以及智能化的运行模式[15]。