李銘軒，曹暢，唐雄燕，龐冉，劉瑩，劉秋妍

1.中國(guó)聯(lián)通研究院，未來(lái)網(wǎng)絡(luò)研究部，北京 100048

2.中國(guó)聯(lián)通研究院，網(wǎng)絡(luò)技術(shù)研究部，北京 100048

2.中國(guó)聯(lián)通研究院，無(wú)線技術(shù)研究部，北京 100048

引 言

隨著互聯(lián)網(wǎng)應(yīng)用場(chǎng)景的不斷增長(zhǎng)，對(duì)于網(wǎng)絡(luò)的需求呈現(xiàn)爆發(fā)式增長(zhǎng)，傳統(tǒng)的網(wǎng)絡(luò)能力已經(jīng)無(wú)法滿足面向互聯(lián)網(wǎng)靈活多變的業(yè)務(wù)需求，而SDN 技術(shù)的產(chǎn)生使得傳統(tǒng)的網(wǎng)絡(luò)功能實(shí)現(xiàn)了控制和轉(zhuǎn)發(fā)分離，加強(qiáng)了網(wǎng)絡(luò)的實(shí)時(shí)控制能力[1]?？删幊叹W(wǎng)絡(luò)技術(shù)的興起，又進(jìn)一步實(shí)現(xiàn)了網(wǎng)絡(luò)設(shè)備的軟硬件分類(lèi)，網(wǎng)元功能虛擬化可以部署并運(yùn)行在通用X86 處理器或者專(zhuān)有芯片上，從而使得網(wǎng)絡(luò)設(shè)備能夠承載更多不同的網(wǎng)元功能。

另一方面，5G 移動(dòng)網(wǎng)絡(luò)的不斷普及，尤其是5G 網(wǎng)絡(luò)架構(gòu)的云原生轉(zhuǎn)型，使得傳統(tǒng)的核心網(wǎng)和接入網(wǎng)等網(wǎng)元進(jìn)一步解耦。核心網(wǎng)的網(wǎng)元，尤其是UPF 等轉(zhuǎn)發(fā)面的網(wǎng)元可以結(jié)合不同的邊緣場(chǎng)景需求，進(jìn)一步下沉到邊緣端，利用開(kāi)放的融合網(wǎng)絡(luò)設(shè)備來(lái)承載UPF（User Plane Function，用戶面功能）的轉(zhuǎn)發(fā)功能，通過(guò)開(kāi)放網(wǎng)絡(luò)和5G 移動(dòng)網(wǎng)絡(luò)共同構(gòu)建網(wǎng)絡(luò)切片和確定性網(wǎng)絡(luò)等能力，滿足不同行業(yè)應(yīng)用場(chǎng)景需求[2]，同時(shí)運(yùn)營(yíng)商也可以提供不同的網(wǎng)絡(luò)質(zhì)量保障能力，通過(guò)這種差異化的網(wǎng)絡(luò)服務(wù)質(zhì)量來(lái)實(shí)現(xiàn)不同的網(wǎng)絡(luò)服務(wù)。

隨著邊緣計(jì)算在行業(yè)應(yīng)用的不斷發(fā)展，基于固移融合的開(kāi)放網(wǎng)絡(luò)技術(shù)目前是行業(yè)內(nèi)研究的重點(diǎn)。而異構(gòu)算力的普及，使得在同一個(gè)網(wǎng)絡(luò)硬件設(shè)備上往往可以集成不同的處理單元，基于輕量化云原生的算力調(diào)度可以輕松地將不同的網(wǎng)元功能調(diào)度不同的處理單元運(yùn)行實(shí)現(xiàn)自定義的網(wǎng)絡(luò)功能，同時(shí)還能夠開(kāi)放一部分的算力資源用于處理邊緣計(jì)算場(chǎng)景下的計(jì)算需求[3]。而本文結(jié)合上述的行業(yè)發(fā)展熱點(diǎn)，采用開(kāi)源的可編程網(wǎng)絡(luò)架構(gòu)SONiC 和UPF 融合的方式，利用云原生的方式來(lái)實(shí)現(xiàn)異構(gòu)算力的調(diào)度能力，并提出整體的技術(shù)架構(gòu)和解決方案，從而實(shí)現(xiàn)了在開(kāi)源可編程網(wǎng)絡(luò)設(shè)備中集成了承載網(wǎng)的轉(zhuǎn)發(fā)能力和5G UPF 的轉(zhuǎn)發(fā)能力，并且實(shí)現(xiàn)了異構(gòu)算力的整體調(diào)度能力。

1 SONiC 介紹

SONiC（Software for Open Networking in the Cloud）是一款開(kāi)源網(wǎng)絡(luò)操作系統(tǒng)，由微軟于2016年發(fā)起，并在一年后貢獻(xiàn)給了開(kāi)放計(jì)算項(xiàng)目（OCP）。SONiC 是基于Linux 建立在交換機(jī)抽象接口（SAI）之上進(jìn)行開(kāi)發(fā)，并且可以運(yùn)行在各種交換機(jī)和ASIC芯片上。SONiC 是內(nèi)核補(bǔ)丁、設(shè)備驅(qū)動(dòng)程序、實(shí)用程序等的集合，旨在解決云網(wǎng)絡(luò)的可靠性和可用性以及可擴(kuò)展性的問(wèn)題。

1.1 SONiC 整體技術(shù)架構(gòu)

SONiC 構(gòu)建在Linux 系統(tǒng)之上，并且利用鍵值數(shù)據(jù)庫(kù)、容器技術(shù)、標(biāo)準(zhǔn)化硬件接口定義等技術(shù)，使其成為一個(gè)標(biāo)準(zhǔn)軟硬件接口、模塊松耦合、高可靠、易于擴(kuò)展、開(kāi)源開(kāi)放的網(wǎng)絡(luò)軟件系統(tǒng)。

如文獻(xiàn)[4]所描述，SONiC 系統(tǒng)的體系結(jié)構(gòu)所包含的模塊通過(guò)集中式和可擴(kuò)展的基礎(chǔ)結(jié)構(gòu)相互交互[4]。整個(gè)基礎(chǔ)架構(gòu)的各模塊主要依賴(lài)于Redis 數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)交互。其中數(shù)據(jù)庫(kù)提供兩個(gè)方面的功能：一方面，提供獨(dú)立于語(yǔ)言接口的鍵值數(shù)據(jù)庫(kù)功能；另一方面，用于所有各子系統(tǒng)之間的數(shù)據(jù)持久性、復(fù)制和多進(jìn)程通信的方法。

同時(shí)，隨著容器技術(shù)的應(yīng)用，SONiC 將每個(gè)模塊實(shí)現(xiàn)了容器化封裝，并且每個(gè)組件都與平臺(tái)完全解耦。SONiC 的主要技術(shù)架構(gòu)如圖1所示。

圖1 SONiC 技術(shù)架構(gòu)圖Fig.1 Technology architecture of SONiC

依據(jù)上述SONiC 技術(shù)架構(gòu)圖，其整體技術(shù)架構(gòu)分為三層：硬件層主要包含各種硬件以及asic芯片等；操作系統(tǒng)內(nèi)核主要是集成了面向平臺(tái)、網(wǎng)絡(luò)和asic芯片的驅(qū)動(dòng)等；而在用戶面則包含了整個(gè)SONiC 的主要容器化的組件功能。其主要組件包括以下幾個(gè)方面：

●TEAMDED 容器 ：在設(shè)備中負(fù)責(zé)運(yùn)行鏈接聚合功能（LAG）?；贚inux 的LAG 協(xié)議的開(kāi)源實(shí)現(xiàn)，允許team 子系統(tǒng)和南向子系統(tǒng)之間進(jìn)行交互；

●PMON 容器：負(fù)責(zé)運(yùn)行“sensored”的守護(hù)進(jìn)程，該守護(hù)進(jìn)程用于定期記錄硬件組件中的傳感器讀數(shù)并在發(fā)出警報(bào)時(shí)觸發(fā)警報(bào)。Pmon 容器還托管“fancontrol”進(jìn)程，從相應(yīng)的平臺(tái)驅(qū)動(dòng)程序中收集與風(fēng)扇相關(guān)的狀態(tài)；

●SNMP 容器：托管snmp 功能 。該組件包括兩個(gè)相關(guān)的進(jìn)程（Snmpd 進(jìn)程和Snmp_ax_impl ）；

●DHCP 容器：負(fù)責(zé)將DHCP 請(qǐng)求從沒(méi)有DHCP服務(wù)器的子網(wǎng)中繼到其他子網(wǎng)上的一臺(tái)或多臺(tái)DHCP服務(wù)器中；

●LLDP 容器：負(fù)責(zé)承載lldp 功能 ，主要負(fù)責(zé)運(yùn)行Lldp、Lldp_syncd 以及Lldpmgr 進(jìn)程；

●BGP 容器：負(fù)責(zé)運(yùn)行支持的路由堆棧之一。雖然該網(wǎng)絡(luò)功能容器是BGP 命名的，但是路由堆棧也可以支持其他各種協(xié)議（如ospf、isis、ldp 等）。該容器主要包括：bgpd、zebra、fpmsyncd 等進(jìn)程；

●數(shù)據(jù)庫(kù)容器：托管redis 數(shù)據(jù)庫(kù)引擎，應(yīng)用程序可以通過(guò)redis-daemon 來(lái)訪問(wèn)數(shù)據(jù)庫(kù)。redis 引擎托管的主要數(shù)據(jù)庫(kù)包括：APPL_DB、CONFIG_DB、ASIC_DB、COUNTERS_DB 等；

●SWSS 容器：交換狀態(tài)服務(wù)（Swss）容器包含一組工具，允許所有SONiC 模塊之間進(jìn)行有效通信。和數(shù)據(jù)庫(kù)容器用于提供存儲(chǔ)功能不同，Swss 主要提供機(jī)制來(lái)促進(jìn)所有不同模塊之間的通信和仲裁；

●SYNCD 容器：同步（Syncd）容器主要負(fù)責(zé)提供一種機(jī)制，允許交換機(jī)的網(wǎng)絡(luò)狀態(tài)與交換機(jī)的實(shí)際硬件/ASIC 進(jìn)行同步，包括交換機(jī)的ASIC 當(dāng)前狀態(tài)的初始化、配置和收集等；

●CLI/sonic-cfggen：負(fù)責(zé)提供CLI 功能和系統(tǒng)配置功能。

1.2 SONiC SAI 接口抽象

根據(jù)文獻(xiàn)[5]所述，交換機(jī)抽象接口（Switch Abstraction Interface,SAI）是2015年微軟向開(kāi)放計(jì)算項(xiàng)目（Open Compute Project,OCP）開(kāi)源的項(xiàng)目，參與的廠商主要包括：Centec、Intel/Barefoot、Dell、HP、Broadcom、Mellanox、Cavium 以及Metaswitch等公司。SAI 主要致力于在ASIC 之上提供一個(gè)與硬件無(wú)關(guān)的抽象標(biāo)準(zhǔn)化API 接口，為上層應(yīng)用和開(kāi)發(fā)者提供更便捷、靈活的底層資源調(diào)用接口[5]。

在SONiC 之前，硬件的底層復(fù)雜性與協(xié)議棧軟件之間的緊耦合，剝奪了我們?yōu)榫W(wǎng)絡(luò)需求選擇最佳硬件和軟件組合的自由。而芯片廠商參與SAI 的定義和開(kāi)發(fā)，為SONiC 屏蔽了不同芯片SDK API 的差異，從而使基礎(chǔ)設(shè)施平臺(tái)簡(jiǎn)潔、一致、穩(wěn)定。標(biāo)準(zhǔn)化的SAI API 還允許網(wǎng)絡(luò)硬件提供商開(kāi)發(fā)創(chuàng)新的硬件架構(gòu)，滿足硬件產(chǎn)品快速的研發(fā)需求。此外，SAI還能夠讓系統(tǒng)廠商專(zhuān)注在系統(tǒng)協(xié)議的開(kāi)發(fā)，而不需要重復(fù)適配各種芯片，滿足軟件產(chǎn)品快速迭代開(kāi)發(fā)需求。

因此基于SAI 接口的可編程網(wǎng)絡(luò)白盒設(shè)備的軟件開(kāi)發(fā)工具包（Software Development Kit，SDK）整體架構(gòu)如圖2所示。

圖2 SDK 架構(gòu)圖Fig.2 Technology architecture on SDK

基于上述架構(gòu)，SDK 以芯片硬件分層封裝的形式，逐漸對(duì)上層應(yīng)用提供統(tǒng)一的適配層和調(diào)用接口，并且遵守最小化、完整性、直觀化、易記憶、簡(jiǎn)單易用的接口設(shè)計(jì)原則，進(jìn)一步降低上層開(kāi)發(fā)人員的應(yīng)用開(kāi)發(fā)門(mén)檻，同時(shí)SDK 能夠盡可能地適配不同的操作系統(tǒng)平臺(tái)和應(yīng)用，從而便于移植和集成。

2 基于可編程網(wǎng)絡(luò)的UPF 邊緣調(diào)度方案

隨著白盒網(wǎng)絡(luò)設(shè)備技術(shù)的發(fā)展，從傳統(tǒng)的網(wǎng)絡(luò)設(shè)備主要基于專(zhuān)有網(wǎng)絡(luò)芯片作為主要處理單元專(zhuān)門(mén)實(shí)現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)等。如文獻(xiàn)[6]、[7]所述，目前行業(yè)內(nèi)白盒網(wǎng)絡(luò)設(shè)備普遍采用“MCU+ASIC”的SOC 架構(gòu)。其中MCU 作為整個(gè)系統(tǒng)的管理單元主要采用ARM、X86 等通用處理單元，負(fù)責(zé)設(shè)備整體的資源調(diào)度和消息處理；而ASIC 作為專(zhuān)有芯片主要負(fù)責(zé)數(shù)據(jù)處理和數(shù)據(jù)轉(zhuǎn)發(fā)等[6]。另一方面，隨著云原生技術(shù)的發(fā)展，在邊緣設(shè)備終端上逐漸采用容器化的方式來(lái)實(shí)現(xiàn)底層資源的管理和上層應(yīng)用服務(wù)化能力的編排，從而可以實(shí)現(xiàn)算力資源的彈性擴(kuò)縮容以及服務(wù)功能的敏捷管理[7]。因此本文采用輕量化Kubernetes 來(lái)實(shí)現(xiàn)白盒網(wǎng)絡(luò)設(shè)備的資源調(diào)度，實(shí)現(xiàn)SONiC 的容器化封裝的網(wǎng)元和UPF 容器化封裝的網(wǎng)元調(diào)度到不同的處理單元，并且在服務(wù)編排層實(shí)現(xiàn)了承載網(wǎng)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)功能和UPF 轉(zhuǎn)發(fā)功能的融合。

2.1 整體技術(shù)架構(gòu)

在面向可編程網(wǎng)絡(luò)的UPF 邊緣調(diào)度架構(gòu)中，由于傳統(tǒng)SONiC 和UPF 分別在不同的技術(shù)架構(gòu)中實(shí)現(xiàn)了各自的容器化部署方式以及數(shù)據(jù)庫(kù)管理方式。另一方面，面向邊緣端的白盒網(wǎng)絡(luò)設(shè)備算力資源存在異構(gòu)性和有限性等問(wèn)題[7]，因此在實(shí)現(xiàn)SONiC 和UPF 融合調(diào)度的過(guò)程中，需要實(shí)現(xiàn)調(diào)度層面和數(shù)據(jù)層面的融合。本文針對(duì)邊緣場(chǎng)景下資源有限的問(wèn)題，采用統(tǒng)一的調(diào)度層和數(shù)據(jù)管理層來(lái)實(shí)現(xiàn)SONiC 和UPF 的融合方案，通過(guò)統(tǒng)一的Kubernetes 調(diào)度平臺(tái)為SONiC 網(wǎng)元和UPF 網(wǎng)元分別創(chuàng)建不同的命名空間（namespace），并且調(diào)度到不同的處理單元上運(yùn)行，通過(guò)統(tǒng)一的數(shù)據(jù)庫(kù)層面來(lái)實(shí)現(xiàn)SONiC 和UPF 內(nèi)部的數(shù)據(jù)管理能力的共平面管理，其整體的技術(shù)架構(gòu)如圖3所示。

圖3 可編程網(wǎng)絡(luò)整體技術(shù)架構(gòu)Fig.3 Technology architecture on programmable network

依據(jù)上述整體技術(shù)架構(gòu)，可編程網(wǎng)絡(luò)設(shè)備管控平臺(tái)實(shí)現(xiàn)了對(duì)可編程網(wǎng)絡(luò)設(shè)備的應(yīng)用管控和功能管控。根據(jù)場(chǎng)景需求，5G 核心網(wǎng)通過(guò)向可編程網(wǎng)絡(luò)設(shè)備管控平臺(tái)發(fā)送UPF 網(wǎng)元遠(yuǎn)程調(diào)度的指令，觸發(fā)管控平臺(tái)將UPF 網(wǎng)元下沉到邊緣可編程網(wǎng)絡(luò)設(shè)備中進(jìn)行部署，并且通過(guò)N4 接口實(shí)現(xiàn)和5G 核心網(wǎng)的納管。而在可編程網(wǎng)絡(luò)設(shè)備中基于統(tǒng)一的Kubernetes 服務(wù)編排平臺(tái)實(shí)現(xiàn)了對(duì)底層的異構(gòu)算力的統(tǒng)一管理和編排調(diào)度，在算力調(diào)度方面，根據(jù)SONiC 和UPF 網(wǎng)元功能的不同，UPF 網(wǎng)元通過(guò)Kubernetes 調(diào)度平臺(tái)調(diào)度到CPU 運(yùn)行，而SONiC 網(wǎng)元?jiǎng)t通過(guò)Asic 驅(qū)動(dòng)調(diào)度到asic 芯片上運(yùn)行。并且在硬件層構(gòu)建數(shù)據(jù)通道從而打通承載網(wǎng)網(wǎng)元和移動(dòng)網(wǎng)網(wǎng)元轉(zhuǎn)發(fā)面的數(shù)據(jù)交互流程，從而使得網(wǎng)絡(luò)設(shè)備具備了承載網(wǎng)和UPF的數(shù)據(jù)轉(zhuǎn)發(fā)能力。而在數(shù)據(jù)操作和共享方面，整體技術(shù)架構(gòu)在中間的數(shù)據(jù)層提供統(tǒng)一的數(shù)據(jù)庫(kù)操作引擎用于支撐上層SONiC 能力和UPF 能力對(duì)于數(shù)據(jù)操作的要求，通過(guò)上層提供統(tǒng)一的數(shù)據(jù)庫(kù)訪問(wèn)接口，SONiC 和UPF 根據(jù)自身網(wǎng)元功能和數(shù)據(jù)訪問(wèn)需求調(diào)用不同的接口來(lái)訪問(wèn)數(shù)據(jù)庫(kù)，而數(shù)據(jù)層可以根據(jù)需要集成Redis 和Etcd 等鍵值數(shù)據(jù)庫(kù)功能，或者通用的MySQL 數(shù)據(jù)庫(kù)功能，從而使得數(shù)據(jù)層可以根據(jù)需求進(jìn)行橫向擴(kuò)展。由于對(duì)上層應(yīng)用提供統(tǒng)一的接口封裝，隨著SONiC 網(wǎng)元功能的進(jìn)一步解耦以及和UPF 的進(jìn)一步融合，在數(shù)據(jù)訪問(wèn)上構(gòu)建統(tǒng)一的數(shù)據(jù)訪問(wèn)對(duì)象，可以進(jìn)一步整合底層數(shù)據(jù)庫(kù)資源，通過(guò)統(tǒng)一的數(shù)據(jù)庫(kù)或者配置參數(shù)表來(lái)完成數(shù)據(jù)訪問(wèn)和管理，從而可以進(jìn)一步節(jié)約硬件資源和提高數(shù)據(jù)訪問(wèn)效率。

因此，基于上述整體技術(shù)架構(gòu)，主要包含如下幾個(gè)方面：

●硬件層：主要集成網(wǎng)絡(luò)設(shè)備不同的處理芯片和相關(guān)硬件，包括通用處理芯片（CPU、arm）、專(zhuān)有芯片（Asic）、轉(zhuǎn)發(fā)芯片以及可編程芯片等；

●硬件驅(qū)動(dòng)層：主要圍繞底層的硬件芯片提供必要的驅(qū)動(dòng)程序，目前在整體的SONiC 框架中，主要依托SONiC 的SDK 架構(gòu)和開(kāi)源SAI 來(lái)集成和擴(kuò)展不同芯片的驅(qū)動(dòng)程序，通過(guò)松耦合的方式來(lái)集成；

●操作系統(tǒng)層：目前主要提供通用的或者定制化的Linux 操作系統(tǒng)，并且集成SONiC SDK 以便兼容底層的硬件驅(qū)動(dòng)，同時(shí)集成容器引擎以便為上層提供容器化調(diào)度能力；

●調(diào)度編排層：主要基于Kubernetes 來(lái)實(shí)現(xiàn)統(tǒng)一的底層資源管理和上層的容器化服務(wù)編排管理；

●數(shù)據(jù)層：主要統(tǒng)一提供數(shù)據(jù)庫(kù)訪問(wèn)，集成了包括Redis、Etcd、MySQL 等數(shù)據(jù)庫(kù)處理能力，并且對(duì)上層提供統(tǒng)一的數(shù)據(jù)訪問(wèn)接口，從而可以實(shí)現(xiàn)上層網(wǎng)元訪問(wèn)數(shù)據(jù)庫(kù)能力；

●能力層：主要集成了SONiC 的網(wǎng)元功能和UPF 的網(wǎng)元功能，提供承載網(wǎng)和移動(dòng)網(wǎng)的數(shù)據(jù)轉(zhuǎn)發(fā)能力；

●用戶面：主要是面向外部提供基于SONiC的網(wǎng)絡(luò)控制能力和5G 移動(dòng)網(wǎng)的控制面的外部訪問(wèn)能力。

基于網(wǎng)絡(luò)設(shè)備的分層管理技術(shù)架構(gòu)，本文實(shí)現(xiàn)了面向可編程網(wǎng)絡(luò)設(shè)備的UPF 調(diào)度和固移融合。通過(guò)基于網(wǎng)絡(luò)設(shè)備上的異構(gòu)算力來(lái)分別承載不同的網(wǎng)元功能，實(shí)現(xiàn)了在資源調(diào)度管理方面的共平面；另一方面，通過(guò)集中的數(shù)據(jù)層來(lái)實(shí)現(xiàn)數(shù)據(jù)處理的集中，并且通過(guò)統(tǒng)一的方位接口可以實(shí)現(xiàn)不同的網(wǎng)元功能集中實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)和處理，為后續(xù)不同架構(gòu)的網(wǎng)元之間融合提供統(tǒng)一的數(shù)據(jù)訪問(wèn)能力。

2.2 網(wǎng)元功能調(diào)度機(jī)制

在網(wǎng)元功能調(diào)度機(jī)制方面，本文主要采用Kubernetes 來(lái)實(shí)現(xiàn)不同的網(wǎng)元功能在不同的處理單元上進(jìn)行執(zhí)行。通過(guò)Kubernetes 為SONiC 和UPF 創(chuàng)建不同的命名空間（namespace），在不同的namespace環(huán)境中，Kubernetes 可以調(diào)度SONiC 或者UPF 的網(wǎng)元功能在不同的處理單元上執(zhí)行。從而可以實(shí)現(xiàn)不同網(wǎng)元功能的邏輯隔離，同時(shí)在網(wǎng)元容器創(chuàng)建過(guò)程中，通過(guò)腳本指定CRD 資源來(lái)實(shí)現(xiàn)網(wǎng)元容器的處理單元，具體的調(diào)度機(jī)制如圖4所示。

圖4 網(wǎng)元容器調(diào)度機(jī)制Fig.4 scheduling mechanism on network element container

基于上述網(wǎng)元容器調(diào)度機(jī)制，通過(guò)Kubernetes分別創(chuàng)建了兩個(gè)namespace，并且在sonic 的命名空間中創(chuàng)建了swss 網(wǎng)元功能，同時(shí)為該網(wǎng)元功能制定了處理單元為asic 專(zhuān)有芯片，副本為一；另外在5gc-upf 的命名空間中創(chuàng)建upf 的網(wǎng)元功能upfd 用于實(shí)現(xiàn)upf 數(shù)據(jù)的轉(zhuǎn)發(fā)進(jìn)程，同時(shí)為該進(jìn)程指定了處理單元分別在不同的處理器上運(yùn)行，包括在通用處理器CPU 上運(yùn)行，以及在FPGA 的智能加速卡上運(yùn)行，用于加速UPF 轉(zhuǎn)發(fā)面的數(shù)據(jù)處理能力。該腳本通過(guò)Kubelet 可以將相應(yīng)的網(wǎng)元通過(guò)驅(qū)動(dòng)層（Driver）分別在指定的處理單元上運(yùn)行，從而實(shí)現(xiàn)了網(wǎng)元功能的資源調(diào)度和運(yùn)行。

2.3 數(shù)據(jù)交互機(jī)制

為了實(shí)現(xiàn)UPF 在Kubernetes 云原生平臺(tái)上的部署，通過(guò)Kubernetes 的容器網(wǎng)絡(luò)接口（container network interface,CNI）以及容器運(yùn)行接口（container runtime interface,CRI）來(lái)集成UPF 網(wǎng)元功能。同時(shí)在UPF 網(wǎng)元轉(zhuǎn)發(fā)過(guò)程中，考慮到UPF 轉(zhuǎn)發(fā)面需求的特殊性，基于控制與轉(zhuǎn)發(fā)的UPF 模式，本文在操作系統(tǒng)層面預(yù)留片上資源以供UPF 后續(xù)在部署和轉(zhuǎn)發(fā)過(guò)程使用，從而可以壓縮SONiC 網(wǎng)元在注冊(cè)時(shí)所占用的資源空間，并且預(yù)留的數(shù)據(jù)共享空間直接交付給UPF 模塊進(jìn)行使用，提高數(shù)據(jù)轉(zhuǎn)發(fā)效率。SONiC在SAI 基礎(chǔ)上封裝PRC 接口供UPF 調(diào)用，UPF 模塊調(diào)用SAI 接口在規(guī)定的范圍內(nèi)使用片上資源，也可以直接通過(guò)SAI 接口獲取相應(yīng)的狀態(tài)和表項(xiàng)信息，UPF 模塊可以通過(guò)SAI 來(lái)注冊(cè)自己的報(bào)文處理回調(diào)函數(shù)進(jìn)行報(bào)文處理。從而實(shí)現(xiàn)了UPF 和SONiC 之間的互通，其交互機(jī)制如圖5所示。

圖5 數(shù)據(jù)交互流程圖Fig.5 Data exchange process

基于上述數(shù)據(jù)交互流程圖，SONiC 通過(guò)Netconfig/CLI 向操作系統(tǒng)用戶提供外部接口，并且通過(guò)網(wǎng)絡(luò)服務(wù)配置模塊調(diào)用底層的svc 模塊實(shí)現(xiàn)對(duì)硬件網(wǎng)卡和芯片資源的訪問(wèn)。而UPF 經(jīng)過(guò)SONiC 訪問(wèn)底層資源的過(guò)程中，通過(guò)硬件網(wǎng)卡和芯片資源實(shí)現(xiàn)在SAI 的注冊(cè)，實(shí)現(xiàn)了控制層面的應(yīng)用調(diào)用注冊(cè)和管理，并且在數(shù)據(jù)轉(zhuǎn)發(fā)層面，在Linux user 層面專(zhuān)門(mén)為用戶創(chuàng)建一個(gè)數(shù)據(jù)包的資源空間，該資源空間負(fù)責(zé)打通UPF 模塊和SAI 之間的數(shù)據(jù)通道，UPF 模塊將轉(zhuǎn)發(fā)數(shù)據(jù)存放在該空間里面，并且通過(guò)該空間和SAI 進(jìn)行互通，再通過(guò)底層的硬件芯片進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，從而實(shí)現(xiàn)了UPF 和SONiC 之間的數(shù)據(jù)交互。

通過(guò)這種方式，在操作系統(tǒng)層面構(gòu)建一個(gè)資源共享空間來(lái)實(shí)現(xiàn)UPF 和SONiC 之間的數(shù)據(jù)交互，從整體技術(shù)架構(gòu)來(lái)看，整個(gè)交互流程只需要在操作系統(tǒng)層面劃定固定的數(shù)據(jù)共享空間用于數(shù)據(jù)轉(zhuǎn)發(fā)，對(duì)本身的硬件架構(gòu)和軟件架構(gòu)改動(dòng)較小。另一方面，由于網(wǎng)絡(luò)設(shè)備自身的資源空間有限，需要在操作系統(tǒng)層劃分特定的空間來(lái)進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，在一定程度上影響系統(tǒng)本身的運(yùn)行效率。同時(shí)相比于硬件層面的數(shù)據(jù)傳輸，片上系統(tǒng)級(jí)別的數(shù)據(jù)軟交換在數(shù)據(jù)傳輸性能和傳輸速率方面還存在一定的劣勢(shì)。因此基于本文的整體技術(shù)架構(gòu)和業(yè)務(wù)流程，在具體的實(shí)現(xiàn)方面，主要采用兩種方式來(lái)實(shí)現(xiàn)：（1）通過(guò)擴(kuò)展網(wǎng)絡(luò)設(shè)備的計(jì)算能力，增加相應(yīng)的存儲(chǔ)和計(jì)算板卡來(lái)增加算力；（2）通過(guò)建立計(jì)算單元和專(zhuān)有芯片Asic之間的硬件數(shù)據(jù)通道采用FPGA 等硬件加速芯片來(lái)滿足硬件轉(zhuǎn)發(fā)的可擴(kuò)展性等，從而實(shí)現(xiàn)硬件的數(shù)據(jù)轉(zhuǎn)發(fā)能力和數(shù)據(jù)加速處理能力。

3 可行性分析

可編程網(wǎng)絡(luò)設(shè)備硬件性能的不斷提升，打破了設(shè)備本身的計(jì)算瓶頸，并且異構(gòu)SoC 芯片架構(gòu)設(shè)計(jì)的廣泛采用以及加速卡在網(wǎng)絡(luò)設(shè)備上的集成，不斷增強(qiáng)網(wǎng)絡(luò)設(shè)備本身的計(jì)算能力，因此已經(jīng)完全能夠滿足不同場(chǎng)景的邊緣應(yīng)用和數(shù)據(jù)轉(zhuǎn)發(fā)處理能力[8]。另一方面，開(kāi)源軟件SONiC 可編程網(wǎng)絡(luò)架構(gòu)的不斷發(fā)展，使得SONiC 在底層集成各種芯片的驅(qū)動(dòng)并且對(duì)上層應(yīng)用提供統(tǒng)一的資源封裝進(jìn)行調(diào)用，同時(shí)在網(wǎng)元功能的服務(wù)編排調(diào)度架構(gòu)中積極引入云原生技術(shù)來(lái)實(shí)現(xiàn)調(diào)度和服務(wù)編排，從而實(shí)現(xiàn)整體架構(gòu)的松耦合集成方式，便于彈性擴(kuò)展和橫向擴(kuò)容，可以根據(jù)不同的場(chǎng)景需求來(lái)進(jìn)行組合[9]。

本文基于SONiC 開(kāi)放軟件架構(gòu)提出了面向邊緣場(chǎng)景的可編程網(wǎng)絡(luò)的UPF 邊緣調(diào)度整體技術(shù)架構(gòu)和相關(guān)數(shù)據(jù)交互流程。其中在面向邊緣網(wǎng)絡(luò)設(shè)備架構(gòu)中，結(jié)合不同的場(chǎng)景需求往往在底層硬件的設(shè)備形態(tài)各異，并且軟件架構(gòu)類(lèi)型也不盡相同。傳統(tǒng)的嵌入式系統(tǒng)在硬件系統(tǒng)開(kāi)發(fā)和軟件移植等方面，不同的平臺(tái)往往開(kāi)發(fā)部署模式都不相同，而本文基于三個(gè)方面來(lái)分析所提出的整體技術(shù)方案的可行性。

（1）硬件兼容性

相比與傳統(tǒng)的嵌入式系統(tǒng)網(wǎng)絡(luò)功能開(kāi)發(fā)主要基于底層硬件平臺(tái)和操作系統(tǒng)，開(kāi)源SONiC 架構(gòu)通過(guò)SAI 接口封裝了底層硬件驅(qū)動(dòng)，并且對(duì)上層應(yīng)用統(tǒng)一提供開(kāi)放接口進(jìn)行調(diào)用，隨著SONiC 版本升級(jí)和迭代，目前最新版本已經(jīng)集成了主流的Asic 芯片驅(qū)動(dòng)和SDK 能力，因此在系統(tǒng)部署和運(yùn)行過(guò)程中，上層網(wǎng)絡(luò)功能進(jìn)一步和底層硬件解耦，系統(tǒng)不需要關(guān)心底層硬件的差異性，而是通過(guò)驅(qū)動(dòng)層來(lái)訪問(wèn)底層硬件資源。

另一方面，網(wǎng)元功能實(shí)現(xiàn)了容器化封裝，并由云原生平臺(tái)來(lái)實(shí)現(xiàn)統(tǒng)一的底層資源調(diào)度和上層服務(wù)編排[10]。而底層的容器引擎繼承操作系統(tǒng)層的內(nèi)核和驅(qū)動(dòng)，對(duì)上層提供了標(biāo)準(zhǔn)的OCI 接口和容器運(yùn)行時(shí)，因此也進(jìn)一步屏蔽了底層硬件的差異性，實(shí)現(xiàn)不同硬件的兼容性。

（2）數(shù)據(jù)交互性

基于可編程網(wǎng)絡(luò)的UPF 邊緣調(diào)度機(jī)制在網(wǎng)絡(luò)設(shè)備上實(shí)現(xiàn)了承載網(wǎng)轉(zhuǎn)發(fā)面和移動(dòng)網(wǎng)轉(zhuǎn)發(fā)面的數(shù)據(jù)互通。本文所提出的基于SONiC 的共享數(shù)據(jù)包轉(zhuǎn)發(fā)機(jī)制，在操作系統(tǒng)層面預(yù)先開(kāi)辟為用戶創(chuàng)建一個(gè)數(shù)據(jù)包的資源空間，該資源空間用于UPF 模塊的數(shù)據(jù)轉(zhuǎn)發(fā)。并且資源空間和SONiC 的SAI 接口進(jìn)行對(duì)接，從而實(shí)現(xiàn)了UPF 通過(guò)SAI 接口向底層Asic 專(zhuān)用芯片轉(zhuǎn)發(fā)數(shù)據(jù)從而實(shí)現(xiàn)了數(shù)據(jù)互通。

隨著硬件性能的提升以及硬件架構(gòu)設(shè)計(jì)的改進(jìn)，在整體的技術(shù)方案中可以引入基于FPGA 作為硬件的數(shù)據(jù)轉(zhuǎn)發(fā)通道，以加速卡的形態(tài)來(lái)實(shí)現(xiàn)硬件級(jí)別的數(shù)據(jù)轉(zhuǎn)發(fā)，從而在轉(zhuǎn)發(fā)效率上會(huì)進(jìn)一步提升[11]。

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

對(duì)于UPF 下沉到邊緣側(cè)的網(wǎng)絡(luò)設(shè)備，一方面需要和邊緣網(wǎng)絡(luò)設(shè)備建立數(shù)據(jù)互通能力，從而打通移動(dòng)網(wǎng)數(shù)據(jù)轉(zhuǎn)發(fā)面和承載網(wǎng)數(shù)據(jù)轉(zhuǎn)發(fā)面的數(shù)據(jù)通道，從而更好的實(shí)現(xiàn)面向邊緣固移融合場(chǎng)景下的數(shù)據(jù)流量融合 。但是UPF 作為整體5G 核心網(wǎng)SBA 架構(gòu)下的轉(zhuǎn)發(fā)面網(wǎng)元功能隨邊緣設(shè)備能夠調(diào)度和下沉到邊緣數(shù)據(jù)中心用于流量轉(zhuǎn)發(fā)，但是在面向上層5G 核心網(wǎng)控制面網(wǎng)元管理方面，現(xiàn)有的行業(yè)解決方案和相關(guān)標(biāo)準(zhǔn)主要是通過(guò)N4 接口解耦的方式來(lái)對(duì)外暴露，以便上層的SMF 進(jìn)行納管和調(diào)用。另一方面，推進(jìn)N4 接口解耦能夠進(jìn)一步實(shí)現(xiàn)5G 核心網(wǎng)的C/U 分離，可以實(shí)現(xiàn)UPF 適配不同方案的SMF 納管能力，并且通過(guò)制定統(tǒng)一的接口實(shí)現(xiàn)方案，達(dá)到解耦的目的，從而使得基于可編程網(wǎng)絡(luò)的UPF 邊緣調(diào)度方案可以適配不同方案的5G 核心網(wǎng)接入方案，減少了對(duì)SMF 的影響，也有利于現(xiàn)網(wǎng)環(huán)境的部署和實(shí)施。

4 應(yīng)用場(chǎng)景

隨著工業(yè)互聯(lián)網(wǎng)以及物聯(lián)網(wǎng)等行業(yè)應(yīng)用的不斷發(fā)展，很多實(shí)際落地場(chǎng)景中對(duì)于網(wǎng)絡(luò)接入有特殊的要求，比如需要具備承載網(wǎng)和5G 移動(dòng)網(wǎng)等兩種網(wǎng)絡(luò)接入方式，要求提供網(wǎng)絡(luò)切片、確定性等網(wǎng)絡(luò)質(zhì)量保障[12]。以智慧城市業(yè)務(wù)場(chǎng)景下的可編程網(wǎng)絡(luò)UPF邊緣調(diào)度為例，智慧交通系統(tǒng)以及車(chē)載系統(tǒng)一方面在保證低延時(shí)的數(shù)據(jù)處理需求的情況下，需要將數(shù)據(jù)和控制盡可能的保證在本地進(jìn)行處理，同時(shí)需要通過(guò)UPF 和承載網(wǎng)實(shí)現(xiàn)多種網(wǎng)絡(luò)連接方式從而實(shí)現(xiàn)低時(shí)延的確定性網(wǎng)絡(luò)連接功能；另一方面，由于車(chē)載系統(tǒng)本身的計(jì)算和存儲(chǔ)能力有限，因此也需要基于正如本文所述的基于云原生等輕量級(jí)的資源調(diào)度系統(tǒng)來(lái)實(shí)現(xiàn)承載系統(tǒng)的資源管理與應(yīng)用運(yùn)行，具體如圖6所示。

圖6 面向智能駕駛的SONiC 算網(wǎng)邊緣調(diào)度Fig.6 Resource scheduling of SONiC computing network for intelligent driving

5 結(jié)論和展望

可編程網(wǎng)絡(luò)技術(shù)的發(fā)展，進(jìn)一步打開(kāi)了面向網(wǎng)絡(luò)的開(kāi)放能力，將傳統(tǒng)的黑盒式網(wǎng)絡(luò)設(shè)備進(jìn)一步演變?yōu)槊嫦蛴?jì)算和網(wǎng)絡(luò)統(tǒng)一承載的白盒算網(wǎng)融合設(shè)備[13]。未來(lái)算網(wǎng)融合設(shè)備將廣泛的邊緣計(jì)算節(jié)點(diǎn)能夠納入到統(tǒng)一的資源管理，提供了承載網(wǎng)和移動(dòng)網(wǎng)等多種網(wǎng)絡(luò)接入方式，從而在網(wǎng)絡(luò)接入方面可以保障網(wǎng)絡(luò)確定性、網(wǎng)絡(luò)時(shí)延以及網(wǎng)絡(luò)傳輸質(zhì)量等。同時(shí)，在算網(wǎng)融合設(shè)備中引入嵌入式設(shè)備管理和自主資源調(diào)度機(jī)制，改變了傳統(tǒng)的嵌入式設(shè)備只能被動(dòng)接受服務(wù)器制定和上傳數(shù)據(jù)采集等模式，使得嵌入式設(shè)備集群更具有自適應(yīng)能力，也為未來(lái)的異構(gòu)算力的能力開(kāi)放以及神經(jīng)網(wǎng)絡(luò)架構(gòu)下的深度學(xué)習(xí)分層在邊緣設(shè)備集群上的部署和運(yùn)行，以及邊緣側(cè)設(shè)備的自主學(xué)習(xí)能力和智能交互提供了可能。隨著未來(lái)具備AI 能力的專(zhuān)有芯片的發(fā)展和普及，基于可編程網(wǎng)絡(luò)的算網(wǎng)融合設(shè)備除了在數(shù)據(jù)中心和邊緣數(shù)據(jù)中心的網(wǎng)絡(luò)中作為網(wǎng)絡(luò)轉(zhuǎn)發(fā)面設(shè)備進(jìn)行資源納管外，對(duì)于邊緣側(cè)設(shè)備的自主學(xué)習(xí)能力和自適應(yīng)能力會(huì)提出更高的要求[14]。通過(guò)本文所提出的基于可編程網(wǎng)絡(luò)的UPF 調(diào)度機(jī)制實(shí)現(xiàn)算網(wǎng)融合設(shè)備技術(shù)架構(gòu)方案的研究，可以更好地實(shí)現(xiàn)可編程網(wǎng)絡(luò)和移動(dòng)網(wǎng)絡(luò)統(tǒng)一接入的算網(wǎng)融合應(yīng)用在邊緣計(jì)算、物聯(lián)網(wǎng)、車(chē)聯(lián)網(wǎng)等應(yīng)用場(chǎng)景下的統(tǒng)一網(wǎng)絡(luò)接入，資源調(diào)度管理以及智能化的運(yùn)行模式[15]。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。