张杰 蒋林涛 许都 田野 蒋雪莲 孙亚楼

(1.中国信息通信研究院,北京 100191;2.电子科技大学信息与通信工程学院,成都 611731;3.北京邮电大学网络与交换技术全国重点实验室,北京 100876)

0 引言

经济社会发展对网络提出新需求,需要网络持续的演进与创新,以解决网络特别是数据承载网络在确定性、安全性、广域虚拟网、广域组播等多方面的能力缺失问题。数据承载网络的创新活动既有面向单个技术点的创新,又包含网络体系架构的探索,将会涉及网络层的数据面、控制面和管理面。针对网络层体系架构的创新,通常需要产学研用多实体联合创新,创新技术的部署与应用需要实验验证,规模性、可信服是重要指标。因此构建一个具有规模性、异构适应性、敏捷性以及资源确定性供给的实验验证环境,可以有效降低创新门槛,支撑来自产学研用多实体构建的创新活动。

1 驱动与目标

在现有IP网络协议基础上,网络5.0产业和技术创新联盟基于“以网络为中心、能力内生”的核心主旨,通过打造新型网络协议体系,赋予网络确定性、可信度、空间主权等属性,连通分散的计算、存储及网络等资源,使网络具备按需可达、就需服务、确权管理、安全可信等内在能力[1]。

为有效支撑网络5.0在体系架构、网络协议与关键技术、网络设备与系统等多层面的创新,利用未来网络试验设施中国网络创新试验环境(China Environment for Network Innovations,CENI)的全国性资源以及网络5.0产业和技术创新联盟成员开放的网络试验设施,建设了网络5.0创新实验平台(简称“平台”)。平台虽被称为网络5.0创新实验平台,驱动和前期的主要服务对象是网络5.0的创新活动,然而其设计与建设的目标是面向网络层创新的通用平台。平台具有可以支持持续演进的、多样化的网络创新活动的如下能力。

一是底层异构资源确定性供给能力。确定性成为创新网络的重点特征,因此确定性也成为网络5.0创新实验平台的基础能力,平台必须具备确定的底层资源供给能力,这些资源不仅包括IT资源,如CPU核、内存、存储等,还必须包括网络资源,特别是虚拟资源的连接保障能力。

二是多样性能力。伴随着网络创新活动,针对体系架构、网络协议与关键技术、网络设备与系统等多层面的验证需求也是多样性的,体现在验证网络的网络规模、拓扑类型、编址方案、网元设备种类、协议种类、标识机制以及验证工具等方面,而验证过程中的组合方式也呈现出多样性。这种多样性还表现为随着基础设施层的不断扩展,平台环境中的基础设施的种类也会越来越多,并且随着联合创新的深入,过程与软件/系统的集成与管理更是加剧了这种多样性。平台应具备这种异构多样性的适应与支撑能力。

三是用户定制化能力。平台的最终目的是服务于用户,如何快速方便地帮助用户构建验证环境是实验平台的关键服务能力。平台需要提供用户的定制功能,支持多样化需求表达的用户接口和界面功能,接收多样化的需求,调度资源,完成自动化的部署。用户可以定制网络拓扑、网元功能及接口、验证工具,以及之间的连接等。

四是持续创新能力。网络创新具有研发与验证的反复迭代特征,平台提供这种循环迭代的过程管理支持,汇集多方创新结果,可以极大地减少创新者繁琐的重复性工作,有效地支持网络创新。

2 网络5.0创新实验平台架构

网络5.0创新实验平台采用3层架构(见图1),包括基础设施层、实例资源仓库、创新服务层,最终服务于网络创新,支持体系架构、网络协议与关键技术、网络设备与系统等多层面的验证[1]。

图1 网络5.0创新实验平台基础架构[2]

基础设施层中主要包含IT基础设施以及多类型的链路资源,提供IT资源和基础的本地与长距连接。这些长距资源中除了实验室提供的室内长距光纤,更多的是CENI提供的长途光链路资源。这些本地和长距链路经由交叉连接设备连接,在系统中被称为拓扑连接器,可以提供接口允许在线配置端口的交叉连接关系。基础设施层还包括用于测验的第三方物理或虚拟的应用/测试设备等。最终,形成种类丰富的基础资源池,满足实验验证过程中在地理空间、资源类型、实验规模等方面的多样化需求。基础设施层提供开放接口用于对外提供资源管理。

实例资源仓库主要用来汇集网络创新的相关虚拟网元功能集,并提供实验验证活动中用到的通用/特色测试工具、网络实验数据以及典型应用等。实例资源仓库提供软件集的存储、管理,并对外提供接口以上传、下载、标注等。

创新服务层是平台的核心,通过用户界面及接口等多种方式允许用户对网络拓扑、虚拟网元、验证活动以及结果分析等进行定制,将用户的复杂需求综合起来,进行基础资源、实例仓库的调度,实现自动化加载。如何有效地选择、编排这些资源是创新服务层必须解决的基本问题。

3 关键技术研究

3.1 通信资源的确定性供给

虚拟化/云技术是当前实验验证环境基础设施层的常用技术。在网络创新平台中大部分设施将用于虚拟网络设备(以下称为虚拟网元),传输能力是虚拟网元的主要能力体现,由这些虚拟网元和物理网元混合构建的网络,其端到端通信资源的确定性供给成为平台需要重点解决的问题。

通常云平台的目标是最大化利用资源,资源会超量配置,即便不采用超配,资源(特别是通信资源)竞争也仍然存在,成为环境中不确定性的一个重要原因[3]。表1列出了传统虚拟网元通信方案。总体而言,方案(1)和方案(2)灵活且支持程度高,质量无法保障;方案(3)和方案(4)的通信性能有保障;方案(3)需软硬件支持,配置复杂。然而,方案(3)和方案(4)的最大问题是网元间拓扑连接受限表现为物理资源数量受限,降低了外部连接的灵活性。

表1 虚拟网元通信方式

在组网架构方面,伴随着应用体量和服务质量(Quality of Service,QoS)要求,Google数据中心10年时间增长100+倍交换容量,当前云数据中心主要还是采用Clos架构及其改进架构[4]。数据中心网络主要通过持续提升服务器连接速率和网络设备交换容量满足数据中心网络的流量需求。然而,不同于常规云数据中心,实验环境中网络架构不仅要考虑扩展性和无阻塞,模拟现网通信环境也是平台中必不可少的目标。因此,在实验环境中不再追求一致性,而是会特意引入一些特殊资源如长延时链路、特定的验证设备,而这些资源在环境中相较于其他资源表现出稀缺性,因此需要重新审视组网架构及资源调度。

另外,在跨域组网方面,现有技术方案中多是提供L1VPN、L2VPN以及L3VPN。例如,利用光传输网络(Optical Transport Network,OTN)电路直通提供L1VPN,可以提供强确定性能力,由于独占广域电路资源,引入扩展性问题;L2VPN可以提供更复杂的拓扑,连接更多数量的实验网元,扩展性更强,然而在骨干网链路的统计复用中,可能引入不确定性;L3VPN由于直接由IP技术构建,通常用来验证IP技术相关的技术与应用。

在网络5.0创新实验平台设计中,为了保障从虚拟网元到虚拟网元的通信资源的确定性供给,在域内和域间基础设施层面避免使用IP技术,通过将物理网卡、域内组网物理连接和域间的L1/L2连接进行池化,统一通过拓扑连接器进行连接,由拓扑连接器提供链路的交叉连接,实现链路资源的统一可定制。这些拓扑连接器群采用了类似分域布设,逻辑域内则采用层次化或近似全连接等多方式进行组织,逻辑域间引入长延时链路,如50 km长距连接,这样在一期工程中形成了仿3个域的物理网络拓扑(见图2)。

图2 物理资源连接拓扑示意图

3.2 实验平台环境中的资源调度

如何将用户多样化的需求映射为平台环境中的资源并连接起来,是平台的关键工作。传统数据中心(Data Center,DC)调度是指将计算资源(例如CPU、内存)分配给作业,以达到资源效率、任务放置延迟和可扩展性方面的一些设定要求[5]。相关学者在单类型和多类型资源的资源调度方面开展了很多工作[6-7]。

网络5.0创新实验验证环境不再追求资源一致性,而是特意引入多类型资源以满足多样化的实验验证需求。这些资源不仅表现出性能差异,而且由于其所在基础设施层的组网关系引发位置约束,这就要求平台在资源调度中必须考虑这些异构资源带来的复杂性。

性能异构性。在平台中除了常用的linux bridege/ovs方式,还有为了提升传输性能和隔离性而采用的直通网卡模式,在资源调度中为了更进一步发挥直通网卡的性能提升作用,需要感知物理服务器的非一致性内存访问架构(Non Uniform Memory Access,NUMA)配置,进行物理网卡与CPU、内存的NUMA-aware联合调度。另外,链路资源在性能上也体现出了多级别传输能力如短距、城域(如50 km)、广域(如500 km+)等不同距离的链路,以及具有不同切片能力(如FlexE)的链路等。

位置约束。大多数异构资源都会引入位置约束。用户在选择了特定的网卡、特定的链路资源或者是特定的物理网元之后,必然会直接影响对其他资源的选择。例如用户选择了平台提供的工控端系统作为实验拓扑中应用,由于该工控端系统在北京花园北路站点,平台将会优先选择同站点,甚至是同拓扑连接器连接的虚拟资源来构建用户实验拓扑中的虚拟网元。因此,针对这些异构性能资源调度需要更准确的调度和更细粒度的感知。例如对于性能敏感的资源要求,调度系统需要考虑CPU、网卡等在NUMA节点中的分布,以及当前基础资源是否支持NUMA等。

因此在创新服务器层,网络5.0创新实验平台构建了一个新的资源调度系统,将用户定制要求作为复合资源请求(可能包括常规虚拟资源、性能要求、特定的链路资源、特定的物理网元),确定请求关键元素,引入约束策略,分解网络资源,实现用户复合请求到资源的映射。

4 网络5.0创新实验平台资源调度系统

针对网络5.0创新实验平台中资源构成复杂且受限、大量资源位置绑定、用户需求多样、能力确定性供给等问题,同时为了充分利用平台资源以尽可能服务更多的创新服务请求,平台资源调度系统设计尤为重要。图3给出了该系统的整体架构,功能主要围绕资源调度分配展开。

图3 创新实验平台资源调度系统总体架构

通过图形化Web界面,获取并处理来自用户浏览器的实验请求;对请求参数的解析和映射,产生当前实验所需细分资源列表;然后核心资源调度模块基于当前平台的资源状态,在给定策略下通过优化算法给出相应的资源分配方案;最后通过虚拟机控制接口和拓扑连接器控制接口,控制平台服务器和拓扑连接器/交换机构建出完整的、符合用户参数要求的实验网络。

其中,Web服务采用Flask框架实现,向用户提供包括实验节点、节点间互连的放置、增删、拖拽、属性调整等的图形化编辑界面,以方便用户通过其本地浏览器输入实验网络拓扑。实验平台虽然集成少量高性能或特殊的网元设备资源,如入侵检测系统、P4交换机等,但大量用户实验节点的能力是通过虚拟化网络功能(Virtual Network Function,VNF)技术在通用x86服务器上实现的。因此用户在前端界面上给出的网络拓扑中需明确定义各个节点的资源需求,如CPU核数、随机存取存储器(Random Access Memory,RAM)空间大小、亲和性要求等;同时指定该节点VNF的镜像文件,如路由功能、防火墙功能、Net5.0网元功能等。节点间链路也需通过属性参数声明,包括带宽、硬件时戳能力、网卡的CPU亲和性、本地或跨域连接等。

实验用户可以在过程中的拓扑输入、部署等阶段保存当前实验拓扑,平台定义了完整的平台实验拓扑导入/导出文件格式,并提供文件和版本管理能力,使得离线编辑实验拓扑、恢复原有实验或在某个版本实验的基础上做调整的工作更为便捷。用户拓扑文件中包括实验拓扑名称、节点、连边及其完整的属性参数等,不仅可读取后再次图形化地呈现给用户,而且可快速部署到平台上开始下一次实验。

平台在用户身份管理方面也做了严格设计,以确保平台稳定运行和资源的合理使用。严格区分管理员身份和用户身份,且不同用户等级对应不同的可用平台资源上限。使用管理员身份登录系统后,能够查看完整的平台资源状态、调整普通用户资源配给、设置不同平台资源分配策略,同时能够干预、终止出现异常的用户实验。

平台资源初始化是管理员通过平台配置文件导入的。类似一般数据中心采用的ToR(Top of Rack)形式实现服务器的网络互连,创新实验平台的特殊之处在于单物理服务器所提供的网卡和网口数更多,如大于16个网口,这使得ToR间的连接端口数成为用户拓扑部署时的关键约束条件之一。因此,在资源状态初始化时,以Pod为基本单元,即同一台交换机下连接的服务器作为一个对象,并将Pod交换机间的连接关系显式定义并存入数据库,以方便后续的资源调度计算处理。

平台数据库中不仅保存了完整的系统资源状态信息,如每个Pod中资源占用数/总量、细分的每台服务器资源(包括CPU核、RAM、磁盘、网卡、图像等)状态,还包括拓扑连接器可用端口、活动端口及连接对象,同时存有完整的用户实验拓扑信息,包括拓扑及分割子拓扑信息、计算分配资源预留、实际资源占用、实验运行时间等。因此,平台数据库是整个资源调度系统的核心模块,调度算法、用户交互、跨越部署、平台监控等均涉及对数据库的频繁操作。

4.1 资源分配

在用户绘制、定义完成实验拓扑并确认部署后,所有当前实验相关数据自动存入平台数据库,并启动资源分配算法。需注意的是平台支持多用户并发使用平台启动实验,因此资源分配模块采用任务队列方式对并发请求做串行化处理,以避免资源分配过程中可能出现的状态不一致性。

资源分配模块首先进行的是实验拓扑校验,即确认用户下发的拓扑是否合法,包括拓扑完整性、节点属性参数合法性、边参数合法性等,同时确认当前用户身份是否有相应的资源使用资格,由此避免用户下发不合理的、不满足条件的部署请求。

然后是资源预分配,基于当前域资源状态计算实验拓扑部署请求的可行资源分配方案。由于用户需部署的拓扑复杂度/资源需求可能超过当前可用资源,因此预分配的目的在于确认当前请求是否可在该域完整部署,若不满足则进行拓扑分割,发起跨域部署请求。

基于上述定义,虚拟网元部署优化问题对应的数学模型表达式为

(1)

(2)

(3)

(4)

其中,公式(1)中的第一项和第二项分别表示完成所有网元部署占用的Pod数量和服务器数量,π为0到1之间的实数,用于权衡对两者的侧重,某种程度上反映了资源碎片化限制;公式(2)限制任何网元部署且只能部署在一台服务器上;公式(3)包括多重约束,要求任何服务器上所承载网元的资源量总需求不超过该服务器的可用资源总量,含CPU、RAM、网卡等,同时跨Pod的边数量不大于当前可用Pod间剩余端口数;公式(4)表示决策变量只能取值0或1。对该模型的近似求解有多种方法,考虑到系统响应时间要求决定了算法复杂度不可过高,且单域资源(Pod、Pod中服务器、Pod间连接资源等)有限,采用贪婪搜索快速得到趋优解较为合理。

上述算法得到的实验拓扑部署资源分配方案,决定了拓扑中每个网元和每条边在平台中的物理位置,在平台数据库中对相应资源进行预更新后做锁定,在后续部署请求到达时这些预分配资源呈不可用状态。同时启动具体的部署操作,如调用openstack接口和拓扑连接器驱动,分别在所分配的服务器上创建各网元对应的虚拟机并加载相应的镜像,通过服务器网卡、拓扑连接器端口直通建立网元间连接关系。由于该部署过程较长,如虚机的创建、启动,采用阻塞等待其完成会导致系统中其他用户等待时间过长,因此采用预分配方式先锁定资源,允许后续部署请求的其他操作,等实际部署操作完成并返回确认后再更新数据库状态,使得系统处理能力加强,请求响应时间缩短。

若算法给出的结果表明当前域资源无法满足部署要求,将对实验拓扑进行迭代分割,使得子拓扑满足资源限制,并将另一部分子拓扑发送到跨域平台协调器Orchestrator,尝试在其他可能的域进行跨越实验部署。后续的操作与单域部署类似,只是在预部署和部署环节需分别等待协调器返回的预部署和部署完成确认信息。

4.2 跨域实验部署

跨域实验部署分两种情况:一是单域资源不足所导致的子拓扑跨越部署;二是实验拓扑本身要求部分网元间互连是跨域链路。后者同样需对请求部署的拓扑进行分割,只是该分割是基于用户所定义的边进行的,相对前者更为简单明确。

跨域资源部署功能的设计如图4所示,其中域A/B分别为域A和域B的资源调度系统,平台A/B分别为域A和域B的域内平台资源,平台A和平台B间的红色连线表示这两个域之间有一条可用的物理跨域链路;Orchestrator同步获取所有域的最新资源状态,维护一个完整的多域资源数据库,其本身并不运行资源调度算法,而是接收、转发来自各个域的拓扑(子拓扑)部署请求。因此,从跨域全平台的角度看,这种结构下的资源分配并非是一个最优解问题,而是可行解问题--只要来自某个域A的子拓扑部署请求在另一个域B得到满足,则表明域A的部署请求是可满足的。这在很大程度上是以资源效率换取了整个系统的松耦合和高可用性。

图4 创新实验平台跨域部署

单域资源调度系统与跨域多平台协调器Orchestrator的接口同样由Web服务提供,因为原则上其他域的实验拓扑部署请求与本地用户的实验请求是一致的,即点、边及属性。通过Web前后端的restful调用,当前平台无论是处理本地请求还是来自协调器的远端请求,抑或是需通过协调器发往其他域的请求,均采用统一的json格式,解析/映射后从资源分配模块部分看并无差异。这在很大程度上简化了域间控制交互的设计复杂度,大量单域控制逻辑在跨域部署时可重用。

5 平台实例资源开发实践

5.1 实例资源池架构

在图1所描述的创新实验平台基础架构中,平台提供了包含网络软件功能池等在内的实例资源仓库,在实验平台中对此部分实例资源进行了开发实践,资源池内部结构如图5。

图5 实例资源池内部结构

实例资源池中的实例按照软件定义网络(Software Defined Network,SDN)进行组织,并依据其职能的不同划分为控制与管理层实例、转发层实例。其中,网络管理系统实例负责对网络整体资源使用状态进行监控,执行智能接纳决策;控制层中的路由控制实例资源主要负责域内各个实例间的路由计算,根据网络资源状态动态调整路由计算策略;转发层中的实例资源,可选实例资源包括IP实例资源、分组通信数据网(Public Telecommunication Data Networks,PTDN)实例资源与网络5.0(Network 5.0,N5)实例资源。其中IP实例资源包含IPv4与IPv6实例资源,以及具备实现IP协议栈相关能力的各类网元。PTDN与N5实例资源则主要包含边缘接入网实例,提供边缘接入网络能力,负责隧道封装、安全接入与接纳策略执行,核心网络中的路由实例负责处理核心网的报文基础转发与路由策略执行。此外,地址翻译实例支持对PTDN与N5报文中的地址字段,按照前缀长度等翻译为实际转发层面使用的网络地址。

图5中提到的所有类型实例资源,均可通过本文提到的资源调度系统进行动态加载,由于实例形态灵活、组网便捷,支持实验用户快速搭建自定义拓扑,验证相关路由策略、资源管理机制。

5.2 实例资源技术选型与性能优化

面对高性能架构,如何进行合理的技术选择和优化成为了开发实践过程中的关键任务。传统网络元件采用的Linux内核网络协议栈,作为一个经过多年积累和优化的成熟技术,提供了丰富的网络功能和广泛的兼容性。然而在处理大量并发数据包时,由于涉及的系统调用、缓冲区管理、上下文切换等因素,可能出现性能“瓶颈”。此外,基于内核的开发也面临着更为严格的限制和更高的复杂性,这在某种程度上限制了开发的灵活性和创新性。因此实例资源开发中采用了数据平面开发套件(Data Plane Development Kit,DPDK)这样的用户态数据包处理框架,与传统内核网络协议栈不同,DPDK在用户态运行,极大降低了上下文切换的开销。这不仅提升了数据包处理效率,还为开发者提供了更加灵活的编程环境。DPDK的轮询模式避免了频繁的中断,确保数据包能够连续、高效地被处理。此外,DPDK提供了先进的内存管理,结合大页内存技术和无锁环形缓冲区,DPDK实现了低延迟、高吞吐量的内存访问。

实例资源开发中,针对内存、计算资源的合理配置与高性能I/O做了相关性能优化。

(1)NUMA优化:通过在单一NUMA节点上绑定CPU、内存和网卡,确保了实例中数据访问的局部性,大大降低了资源之间的访问延迟。

(2)网卡的直通与虚拟功能IO(Virtual Function I/O,VFIO):直通模式为虚拟机提供了接近物理硬件的性能,而VFIO技术进一步简化了用户态与硬件之间的交互,实现了高效的数据包传输。

(3)线程的细粒度调度:利用Linux的调度器,可以将DPDK的处理线程绑定到特定的CPU核心上,确保了数据处理的并发性。

6 网络5.0创新实验平台实施与应用

平台在2021年开始一期系统搭建,在中国信息通信研究院搭建了30+物理服务器构建的本地环境,环境中包含了50 km等特征链路,并同期开展了实例开发工作。在2022年借助CENI以及科学技术部专项的支持,开展了二期跨域建设,在二期建设中覆盖南京、深圳、贵阳、武汉等地。在建设过程中,充分利用已建成部分支撑科技部和联盟的多项网络创新实践,不断改善平台系统功能与易用性。实验平台的应用案例如下。

关于N5P协议验证的应用案例。国家重点研发计划“基于全维可定义的新型网络体系架构和关键技术”项目组实现了网络5.0协议(Network 5.0 Protocols,N5P),除了进行4站点的原型设备组网实验,利用一期平台构建了20个节点的网络拓扑,进行了相关规模性验证工作。该实验验证了平台的基础功能,包括网络功能镜像管理、用户拓扑绘制、资源分配以及拓扑实例加载等。

关于确定性网络的应用案例。平台在进行设计和搭建过程中得到国家重点研发计划“大规模确定性骨干网络示范验证”项目支持,建设成果同时也支撑了该项目的确定性骨干网络搭建和实验验证工作。如图6所示,在实验验证中,平台除了提供骨干10 G链路资源,更为重要的是通过提升平台虚拟网元与物理设备(即项目原型设备)混合组网能力,充分利用拓扑灵活定制和资源调度能力,补充项目骨干实验网络和业务之间的城域和接入组网空缺(图6中虚线),提供业务在不同确定性平面(即项目中MB级切片确定性技术平面和DIP确定性技术平面)的接入调度。最终,平台很好地支撑确定性网络实验验证工作。

图6 实验验证案例拓扑示意图

7 结束语

网络5.0产业和技术创新联盟正在开展多域建设,引入更多类型的资源,完善北京、南京、武汉、深圳、贵阳五城市七站点的网络5.0创新实验平台。平台已经成为一个规模性、异构适应性、敏捷性以及资源确定性供给的实验验证环境,能够提供底层资源确定性供给,实现虚拟网元与物理网元联合组网、网络拓扑和验证活动的可定制化管理与编排。未来平台将继续丰富网络资源类型、实例类型和验证工具,优化调度算法,简化开发和使用流程,服务于网络创新活动。