中国电信尹川:电信自研白盒路由器的创新实践

5月24日,2022网络开源技术生态峰会(线上)盛大开幕,本届大会由“科创中国”未来网络专业科技服务团指导,江苏省未来网络创新研究院主办,SDNLAB社区承办。在“SONiC技术与应用”分论坛上,中国电信研究院网络能力研发中心产品经理尹川分享了《电信自研白盒路由器的创新实践》主题演讲。

中国电信白盒路由器研发背景

尹川分享了运营商做白盒设备的动力,‍‍首先是定制化功能,随着5G和6G的研究与建设,‍‍从边缘的无线网到承载网再到核心网,都需要大量专有的定制功能。另外,面向企业的应用包括算力网络确定性网络等‍‍,都会提出各种各样的个性化功能,这些需求都不是标准的网络设备能做到的。‍‍‍‍当运营商需要对网络做出一些功能层面的变更,或者想将客户的需求进行快速转换时,‍‍就需要底层网络设备的支持,‍‍这时候对网络设备的开放性和可编程性就有很高的要求。定制化只是做白盒的动力之一,还有一些其他的原因,比如降低成本、‍‍业务快速上线运营、核心技术自主研发等。‍‍

‍‍目前白盒设备在中国电信主要的应用场景有数据中心、网络边缘设备、‍‍固网接入设备,还有一些终端设备。

数据中心:数量大(约20万台/年),业务创新和业务定制需求旺盛,但运营商定制需求相对较弱;
网络边缘设备:数量较多(10万/年),业务相对稳定,如IP RAN A设备、PTN设备、宽带接入的BRAS/SR、5G边缘UPF等;
固移接入设备:数量大(数十万)、业务功能简单,有一定管理功能定制、业务创新需求,如IP RAN U设备、VPN CE设备、小基站;
终端设备:数量巨大(数百万以上)、有一定管理功能定制、业务创新需求,如家庭网关、定制化CPE。

尹川主要介绍了在STN网络中的A设备。目前电信的白盒路由器主要应用在STN网络中,STN网络是中国电信为了满足5G的承载需求,在原先IP RAN的基础上引入了SRv6、FlexE等新技术构建的一个新型的承载网。STN网络分为了接入层、‍‍汇聚层和核心层,核心层根据规模又分成了省域或是城域的核心层。‍‍在电信的规范中将接入层定义为A设备,‍‍汇聚层是B设备,ER是核心设备。

目前来说电信自研的白盒路由器主要应用的是STN网络中的A设备,‍‍也就是接入层的设备。‍‍它可满足5G STN移动回传、政企专线、满足新型城域网SRv6、EVPN新业务特性的需求,提供固移业务的灵活接入。‍‍A设备的设备形态也不相同,‍‍根据中国电信的规范,A设备按照处理性能分为了A1设备、A2设备和A3设备,‍‍其中A1是盒式设备,A2和A3一般为框式设备。

下图是电信通过梳理STN设备的技术规范/测试规范、调研现网设备实际配置,整理得出STN系列设备所需的300+项功能需求。

社区版的SONiC与这300多个功能项对比,‍‍相对来说社区版上的SONiC功能不完善的。‍‍‍‍SONiC用作数据中心交换机的NOS相对来说是比较成熟的,但是用作路由器的NOS还有很多工作要做。‍‍

接下来尹川分享了目前SONiC用作白盒路由器NOS所面临的问题‍:社区版SONiC没有经过深度优化、拷机测试等不能直接商用,同时没有针对国内业务进行相应的网管对接等,无法即插即用,且原生不支持CLI命令行/Web界面配置,对运维人员的要求较高。现有商用SONiC主要针对于数据中心的交换场景,对运营商网络的路由场景支持较少;支持的硬件平台均为交换机,对路由器的硬件平台支持较少。

总结来说,不管是社区版还是商用版SONiC主要存在的问题有:

硬件架构支持不足;
业务主要面向IDC,路由功能缺乏;
驱动层面SAI定义不完整。

基于SONiC的C3NoS的创新实践

基于以上各种问题,中国电信基于全新开放体系架构,研发面向商用的云网融合操作系统(C3NoS),打造自主掌控的多业务网关平台,应用于新型网络边缘设备的研发。‍‍

在白盒路由器上,电信C3NoS针对社区版的SONiC做了一些的改动:
新增运营商级300+项功能需求如:NSR、Anti-DDoS、EVPN、SRv6、FlexE、OAM、IEEE1588等功能;
基于社区版SONiC,优化SONiC中各功能模块,新增、修改代码650万行;
针对框式双主控设备进行SONiC改进,业界首家实现SONiC系统与框式设备完美适配;
针对路由ASIC,进行深度优化,对SAI接口补全完善,共完善和新增150+ SAI接口。

C3NoS在原版SONiC的基础上,还做了很多创新型功能和性能改进,‍‍包括研发高精度的时钟同步算法、基于进程热迁移的NSR技术、5G承载新特性敏捷开发快速迭代以及端到端层次化OAM功能等。

NSR业务介绍

NSR全称是不间断路由,一般用到框式设备的双主控上,目的是通过协议备份的机制,‍‍实现当主用主控发生故障时,备用主控感知到主用主控板故障,‍‍生成新的主用主控板。路由协议在主备切换的过程中不会和邻居路由器断连。该切换过程对邻居路由器无感知。

目前业界主流的设备厂商‍‍主要有三类NSR的处理方案,‍‍第一种是针对某种类型报文进行备份处理来实现不间断路由。‍‍第二种是针对某一网络协议进行路由器主备倒换的不间断路由处理。‍‍第三种是针对TCP/IP链接协议栈层面进行链接的热备份来实现不间断路由处理。

根据实际的业务需求以及现有的处理方案的分析,电信‍‍发现目前NSR方案都是针对协议的某一个方面,或者是某个协议的单一模块来实现不间断路由,‍‍不具备通用性。若对路由器中所有需要NSR支持的服务进行各自的开发,‍‍将面临技术复杂、开发周期长、难以维护等问题。‍‍针对于上述问题,电信提出了基于进程的热迁移技术,将相关需要NSR支持的服务进行了一个抽象化,抽象成了各种的APP形式,如下图所示,‍‍通过中间件来实现多类协议的进程热迁移,‍‍无需针对某种特定的协议的NSR功能单独开发,大大缩短了NSR功能的开发周期,‍‍同时也降低了热迁移时对外部程序的依赖,提高了整体热迁移的效率。

NSR的主要功能模块包括CLI模块、API模块、‍‍同步模块和数据模块。

CLI模块主要负责定义NSR相关的命令,‍‍对用户输入的命令进行分析,并进行下发配置;
API模块主要负责对系统进行监控,为源节点与备份节点提供http服务,提供主备节点管理功能,提供主备节点控制信息同步功能,支持通过命令对备份节点进行管理;
同步模块负责对协议进程/进程树进行实时备份与热迁移;根据备份文件对进程/进程树进行恢复;
数据模块主要是存储NSR备份文件,提供文件传输服务,并对系统进行实时监控。

尹川接下来介绍了各个模块之间是如何配合使用来完成备份操作。

用户使能NSR:用户在命令行界面输入NSR使能命令后,nsr-cli模块对命令进行解析及校验,然后将配置信息下发至nsr-api模块;
nsr-api建立连接:nsr-api模块收到NSR使能配置信息后,通过HTTP服务与备用主控板建立连接,再根据进程特征确认所需备份的进程,将进程信息发送至nsr-sync模块;
程序备份:nsr-sync模块接收到备份程序信息后,开始进行备份,并将备份文件存储在nsr-data模块中。nsr-data模块接收到备份数据后,与备用主控板建立连接,并开始文件传输;
实时备份:完成第一轮批量备份后,nsr-sync开始对备份程序进行实时增量备份。

系统在备份阶段完成之后,就到了NSR系统切换阶段。

用户手动切换:用户在命令行界面输入NSR系统切换命令,通知nsr-api进行NSR系统切换;
nsr-api自动切换:nsr-api模块对系统进行实时软件监控,发现到故障后,触发NSR系统切换;
LPU通知切换LPU感知到主用主控板故障,通知SMB进行升主操作;
SMB升主:SMB的nsr-api模块接收到系统切换信息后,通知nsr-sync模块进行系统恢复,nsr-sync模块从nsr-data模块中读取备份文件,通过criu-restore对程序进行恢复。

通过备份加切换的阶段,就完成了一次NSR的处理。

后续研究方向

分布式架构是电信后续的研究方向之一。尹川简单介绍了用普通的盒式设备来组成框式设备会出现的一些问题。‍‍

盒式设备虽然解决了像框式设备所不具备的灵活扩展性问题,‍‍但目前还是很难做到统一的控制面。‍‍因为框式设备不管插多少个线卡,控制面都是在主控上,‍‍但盒式设备组网之后是一个分布式的控制面,‍‍每一个盒子都单独运行自己的网络操作系统,每个盒子在网络当中都是一个路由节点。这种情况下随着网络规模的增加,盒式设备也会越来越多,‍‍在后续的管理和维护上都是比较麻烦的。‍‍

第二点就是在Spine-Leaf组网中,Leaf将流量转发给Spine时,为了增加链路利用率会配置ECMP。‍‍在配置ECMP时,为了防止报文乱序问题,会配置成逐流模式。‍‍但配置成逐流模式的话,会不可避免的出现哈希不均的问题。‍‍‍‍

要解决这些问题,目前来说比较好的方式就是在Fabric侧或Spine侧采用信元交换机。‍‍Leaf层的交换机在将报文转发给Leaf时,会对报文进行切片,切成一个个大小相等的信元,‍‍然后再将信元以逐包的方式发给Spine,这种情况下充分利用了Spine和Leaf之间的链路。‍‍接收到信元的Leaf交换机也具备了信元重组的功能,‍‍采用了这种信元交换技术之后,能将Spine和Leaf之间的链路利用率提高30%以上。‍‍

另外就是控制面的统一,当Spine层采用了信元交换机之后,‍‍这类交换机无需运行复杂的NOS,只需做一个简单的信元转发。‍‍在这种情况下,整网的架构就非常适合做SDN,‍‍做到真正转控分离的SDN架构,整网所有的控制面都在控制器上,‍‍控制器上实现相关的路由器处理,做到一个统一的控制面。

‍‍在这种情况下,理论上整个Fabric就是一个路由节点,如果把它放在一个典型的云数据中心上,‍‍下面连接的所有服务器在一个控制面来看,就全是直连路由。‍‍那么不管网络多么大,都是一个控制面,避免了传统盒式设备增多‍‍之后带来的管理和维护麻烦的问题,这个方案也是电信后续的一个研究和落地的方向。‍‍


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/25765.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于22-05-25
0