中国电信天翼云2025年白盒交换机集中采购项目资格预审公告
设备尺寸
1.设备高度必须≤1U；
2.宽度尺寸应满足19英寸标准机柜安装；侧面预留导轨接口。
交换芯片
1.交换机均采用单交换芯片设计，不可采用多交换芯片组合设计方案；
2.交换容量必须≥4Tbps。
业务端口数
同时满足8*100GE QSFP28端口和48*25GE SFP28端口。
CPU类型
1.必须使用x86架构CPU；
2.CPU核心数目必须≥4个物理core ，并支持超线程；
3.CPU主频必须≥2.2GHz。
内存容量
1.内存容量≥8GB，支持双通道；
2.内存单通道容量≥4GB，SODIMM内存条，支持ECC；
3.内存速度必须支持DDR4-2133MT/s及以上。
硬盘
硬盘必须使用SSD存储且必须≥240G，M.2,支持PLP。
Console口
必须支持1个RJ45，默认速率115200bps，与BMC共用。
Mgmt管理口
必须支持1个RJ45，必须支持10/100MBase-T，与BMC共用。
USB2.0接口
必须支持1个Type A。
I2C
必须支持可反复读取寄存器不挂死。
风扇
1.风扇模块必须≥4个；
2.风扇模块必须支持N+1冗余，必须支持热插拔；
3.必须支持采用前后风道；
4.风扇有独立的LED指示风扇状态；
5.支持风扇监控，风扇插拔、故障等信息需要上报且写入日志。
电源
1.至少2个电源模块，支持热插拔，1+1冗余，内部风冷散热，前后风道；
2.供电模式必须为直接供电方式，禁止使用外部整流或逆变模块；
3.电源具备输入输出过流、过压、过温保护，输出均流、欠压保护；
4.设备应能在下列供电变化范围内正常工作:
直流额定电压 240V，输入范围:204V~288V
交流:单相220V，变化范围为10%，频率50Hz，变化范围为5%，线电压波形畸变率小于5%。
其它要求
1.BMC相关：支持BMC在线升级；支持对主系统上下电；
2.光模块支持：QSFP28-100Gbase-SR4；SFP28-25Gbase-SR
3.软件：
（1）支持风扇、电源、硬件异常信号监控；
（2）支持eeprom、电源、外设、固件信息显示；Transceiver管理，光模块信息查看，光模块控制，端口LED 控制，模块插拔告警；支持查看接口发送和接收的光功率大小。
（3）可读取主交换芯片、CPU、进风口、光模块温度；风扇、PSU状态；风扇转速、整机能耗；
（4）固件在线升级；
（5）提供platform BSP 源码，可适配招标人制定的白盒交换机系统版本，保证编译可通过，系统可运行；
（6）提供SDK、SAI代码二进制安装包，可适配招标人制定的白盒交换机系统版本，确保系统所需软件特性的SAI接口均可支持；
（7）招标人制定的白盒交换机系统为TeleNOS系统，基于SONiC的202205分支研发，需要在白盒交换机上成功加载运行，并通过测试；
（8）支持ONIE，支持在线安装白盒交换机系统。
天翼云自研交换机系统TeleNOS的选择与SONiC社区的主要区别
下文来自天翼云开发者社区
背景
网络操作系统（NOS）有开源和商用两种模式，商用网络操作系统因为并不符合白盒的开放、灵活可定制的理念思路，也难以享受到对应的收益。天翼云自研交换机对业内网络操作系统的使用情况进行了充分调研，选择基于开源社区SONiC（Software for Open Networking in the Cloud）开发天翼云自研TeleNOS（Telecom Network Operating System）。
天翼云选择SONIC作为交换机系统，有以下几个因素：
-
开源社区的活跃度高：sonic支持人员较多， 各ODM，芯片厂商均有自己的软件对其进行sonic的移植，相比较传统确定合作厂商后提供代码开始移植，能将项目进度提前2-3个月；另外，sonic支持的多的好处是问题发现得相对快，可以开发中进行问题的移植和合并，共享社区红利； -
软件架构生态丰富：sonic的松耦合架构，基于linux发行版Debian组合各开源软件，交换机软件系统容器化等创新技术解决方案，一些新的开源项目如Docker，Redis，Quagga和LLDP, TEAMD等很容易的集成利用起来； -
软件网络管理框架成熟：sonic是微软从网络管理自动化延伸发展出来的项目，整体上对自动化的支持会比较好，网络管理不用从头开始构建，减少开发的代价； -
软件功能成熟度：国内的网络发展整体相对于国外仍是略微落后，一些网络特性微软已经在sonic上开发发展，如IPv6, RDMA 、vxlan, tunnel相关特性等，标准化的网络系统架构有利于广泛吸收开源社区、产业链的技术及资源红利。
SONiC是微软主导和开源的网络操作系统，具有开放和开源的特点，自研选用SONiC作为白盒交换机的软件平台，并在此基础上做定制化研发，借助开源社区的能力可以帮助自研NOS进行快速迭代。
SONiC网络交换机系统
SONiC是一个将传统交换机操作系统软件分解成多个容器化组件的创新方案，便于增加新的组件和功能。SAI(Switch Abstraction Interface)接口和容器化是SONiC的两个突出的亮点。SAI使得SONiC可以兼容不同芯片的设备。各组件运行在Docker中，各自有独立的运行环境，极大减少了相互的影响；下面是SONiC的架构图：
SONiC的架构具有以下特点：
-
数据驱动：系统上的各个组件通过Redis进行交互。从传统关注流程转变为关注数据，实现了功能模块之间的解耦，根据数据订阅来进行相应的操作。
-
软件解耦合：在模块化方案设计上，SONiC将交换机软件拆分为多个容器化组件的解决方案。容器化使得SONiC可以充分利用现有的开源软件，比如redis, Quagga/FRR, GoBGP等。
社区SONiC Vs 自研SONiC
社区SONiC经过几年的发展迭代，已经可以满足绝大部分数据中心的需求。但由于微软数据中心的运维方式与国内数据中心的不同，在SONiC的设计上存在以下问题：
-
配置不支持无损动态修改，微软的数据中心的所有网络设备的配置都不会动态更改，当需要进行配置更改的时候对设备进行reload操作。一方面微软服务的弹性迁移能力很强，在配置变更之前很方便将受影响的业务进行迁移走，另一方面，国外对网络的SLA制定的比较合理，允许网络有一定的故障修复时间，国内对SLA有更高的要求。
-
设备事件联动处理的不好，如端口出现down以后，需要进行FDB、路由的删除，以免出现路由黑洞现象，但在SONiC中没有这部分的处理。这是因为在微软的网络中，如T0设备出现端口down事件以后，如果是和服务器的连接端口，此时不需要做处理；如果是和T1设备相连接的端口，则由BGP协议的keepalive进行路由的切换。
-
没有完善的CLI，在SONiC中的命令行是Linux的shell风格的，没有统一的命令行入口，命令比较分散，同时很多配置命令也是缺失的，这也是和微软的运营方法有关系。微软的网络管理平台很完善，不需要运营工程师登陆设备进行操作，所有的操作都是在平台上完成。
-
缺少线上网络故障定位功能支持，如交换机上的芯片底层寄存器的流统能力，格式化主动推送故障能力等。这是因为很多网络故障定位的工具是运行在服务器上，如pingmesh、everflow等，可以在服务器上部署agent通过这些功能实现网络的故障发现和定位；
-
功能定义方面差异，如RDMA功能，微软使用的参数是和它的网络、流量模型有关，这些与网络流量的模型被直接写入到SONiC代码中，其他厂商使用RDMA功能就比较困难；
-
缺少一些必要的网络功能，比如，当前数据中心的去堆叠方案，monitor-link, nd proxy等，以及基本网络功能，对称性hash，link-delay, pfc watchdog，pbr等；也缺少一些静态配置功能，比如：静态FDB，静态NEIGHBOR，静态路由配置等。
-
缺少精细化网络可视化监控，随着网络规模、网络带宽容量越来越大，对报文的路径以及丢包可视化的要求也越来越高，需要构建端到端的监控能力，满足灵活多变的精细化监控能力要求。比如，秒级监控技术，以及INT/MOD技术等精细化监控技术；
自研选用SONiC作为白盒交换机的软件平台，并在此基础上做定制化研发和快速迭代，进行全面的网络功能排查，补齐天翼云网络数据中心功能需求，建立全面的TeleNOS网络操作系统。
相关阅读：