类型a：原创研究学术报告
一、作者、机构与发表信息
本文的研究由三位学者合作完成，他们分别是来自希腊雅典国立技术大学（National Technical University of Athens）电气与计算机工程学院的Georgios Drainakis、色萨利大学（University of Thessaly）信息与电信系的Peristera Baziana，以及西阿提卡大学（University of West Attica）信息与计算机工程系的Adonis Bogris。该研究于2025年8月4日投稿，历经修订后于2026年3月4日被接收，并于2026年4月10日正式发表在《Journal of Optical Communications and Networking》第18卷第5期上。
二、研究背景与目标
本研究属于数据中心网络（Data Center Network, DCN）与光通信交叉领域。随着人工智能（AI）、机器学习（ML）、云原生服务和企业数字化的迅猛发展，现代数据中心面临着前所未有的异构流量压力。不同应用对服务质量（Quality of Service, QoS）的要求差异极大——例如自动驾驶和智能交通要求端到端（End-to-End, E2E）延迟低至微秒级，而批量存储备份则可容忍毫秒级延迟。然而，现有大多数DCN方案要么将流量统一对待，要么仅依据“大象流/老鼠流”等流大小启发式规则进行分类，缺乏真正的应用感知（Application-Aware）能力。
针对这一空白，作者提出了ALAS-DCN架构——一种应用感知、低延迟、可扩展的光分组交换（Optical Packet Switching, OPS）数据中心网络架构，覆盖机架内（Intra-Rack）和机架间（Inter-Rack）通信域。其核心目标是：根据商用QoS规范和真实流量模式，为共存于同一数据中心的不同应用提供差异化的端到端延迟保障。该架构将DCN划分为三个层级的光学子网，分别为机架内子网、机架间子网和桥接（Bridge）子网，每个子网由专门设计的波分复用（Wavelength Division Multiplexing, WDM）介质访问控制（Medium Access Control, MAC）协议管理。这些协议依据应用级延迟需求动态优先调度关键流量包。值得一提的是，ALAS-DCN借鉴了2D环面（2D-Torus）拓扑结构，由m个机架组成，每个机架容纳n台服务器，总规模为m×n台服务器。
三、研究的详细工作流程
本研究的工作流程主要包含三个环节：流量分类框架设计、三层光子网MAC协议设计与实现、基于离散事件模拟的综合性评估。
（1）应用感知流量分类框架
作者首先分析了文献中记载的五类典型数据中心：大学校园（University, UNI）、私营企业（Private Enterprise, PRI）、商业云（Commercial Cloud, COM）、社交网络（Social Network, SOC）和AI/ML导向型数据中心（AI）。每类数据中心承载不同的应用组合。作者将应用归纳为四个代表性类别：网页搜索（Web Search, Web）、云存储（Cloud Storage, Cloud）、媒体流（Media Streaming, Media）和Hadoop/计算密集型负载（Hadoop）。针对每个应用，作者根据商用文献确定了其RTT（Round-Trip Time）延迟阈值，并据此分配优先级：延迟需求越严格的应用优先级越高。例如，AI数据中心中的Hadoop应用RTT阈值为0.02–0.2 ms，被分配为高优先级；而社交网络中的媒体流RTT阈值高达25 ms，被分配为低优先级。此外，作者定义了两种流量分布场景：SC1为“香草”（Vanilla）基线场景，SC2为“高优先级流量强化”场景，后者将高优先级应用的流量占比显著提高以进行压力测试。
（2）三层光子网MAC协议设计与实现
机架内子网（Intra-Rack Sub-Network） 采用一个n×n无源光耦合器实现同一机架内n台服务器的全互联。每台服务器通过w+1个波长连接至耦合器：1个控制波长λ_intra_c和w个数据波长λ_intra_1至λ_intra_w。每台服务器配备两条光网络接口：一条用于机架内通信，另一条为桥接上行链路接口用于与机架顶部交换机（Top-of-Rack, ToR）通信。每台服务器维护多组先进先出（FIFO）缓冲队列，每类应用对应一个出站缓冲队列。传输时间被划分为固定时长的数据周期T_intra = T_m + 2T_s，其中T_m为最大数据包传输时长，2T_s为激光器开/关切换的保护间隔。控制周期T_control可配置为数据周期的整数倍（本研究设为4倍），控制信道被划分为n个等长时隙，每台服务器被预分配一个时隙。每个控制周期内，每台服务器可传输至多k_intra个控制包（本研究设为8个），携带待传数据包的元数据。收到控制信息后，每台服务器独立执行分布式调度算法，高优先级包先于中、低优先级包获得传输权。相邻服务器传输之间设置2T_s的保护间隔以防止冲突。
桥接子网（Bridge Sub-Network） 采用时分复用（Time-Division Multiplexed, TDM）光网络架构，将服务器与其对应的ToR交换机相连。上行链路方向，来自服务器的机架间包通过协调的TDM周期传输，周期时长T_br与T_intra相等以保证同步；下行链路方向，ToR作为唯一发送端将包广播至机架内所有服务器。桥接接口使用固定波长收发器（上行λ_br_ul，下行λ_br_dl），并配备半导体光放大器（SOA）实现纳秒级切换。控制协调复用机架内的控制波长λ_intra_c，服务器在该控制信道上额外传输k_inter个控制包（本研究设为3个）用于机架间包的调度。
机架间子网（Inter-Rack Sub-Network） 基于二维环面拓扑，由y×y的机架网格构成（本研究采用y=4，即16个机架）。每个ToR与其四个直接邻居（北、南、东、西）通过双向光链路相连，每条方向使用两个光纤。通信由8个数据波长（λ_inter_1至λ_inter_8）和1个专用控制波长（λ_inter_c）承载。每个ToR配备波长可调发射器（Wavelength-Tunable Transmitter, WTT）和突发模式接收器。光-电转换仅在源和目的ToR发生，中间ToR实现光旁路（Optical Bypass），从而大幅降低延迟。每个ToR为每个目的ToR和每类应用维护独立缓冲队列。传输调度在周期T_inter内进行：每个ToR在控制信道上广播至多15个传输请求，集中式SDN控制器聚合所有16×15=240个请求，执行贪婪匹配算法。该算法遵循三条约束：（1）优先服务延迟敏感应用；（2）每个源ToR最多4个传输请求（对应4个方向链路）；（3）每个目的ToR每个方向最多1个入站请求。算法复杂度为O(n log n)。
（3）基于离散事件模拟的综合性评估
作者使用Python开发了定制离散事件模拟器，实现了三个子网的完整MAC协议。模拟拓扑采用m=16、n=16，共256台服务器。服务器和ToR缓冲容量均设为1 MB。流量生成使用开源框架TrafPy，该框架支持生成五类数据中心的应用级真实流量模式。默认配置为80%机架内流量、20%机架间流量（流量比r=80/20）。关键参数为：机架内往返传播延迟T_p=16.7 ns（对应2.5 m距离），机架间T_p=500 ns（对应75 m距离）；机架内数据波长w=4，单波长速率400 Gbps；保护带为90字节（对应T_s=900 ps切换时间）。机架内子网标称容量为1.6 Tbps，机架间子网聚合容量为25.6 Tbps，全网E2E标称容量为32 Tbps。评估性能指标包括：吞吐量（Throughput）、吞吐效率（Throughput Efficiency，即吞吐量与提供负载之比）、丢包率（Drop Rate）和E2E延迟。
四、详细实验结果
（1）基线配置下的性能（SC1场景）
在机架内子网中，MAC协议在高达1470 Gbps的提供负载（相当于标称容量的92%）下实现了100%的吞吐效率。超过此阈值后开始出现数据包丢失，吞吐量在UNI、PRI、COM、SOC和AI五类数据中心分别稳定在1477、1531、1541、1516和1533 Gbps，平均吞吐效率约95%。机架间子网在所有类别中均未达到饱和——聚合提供负载始终低于7 Tbps（不足其标称容量的30%），吞吐效率保持100%。网络整体层面，PRI、COM、SOC和AI数据中心在约30 Tbps负载（总容量的93.75%）前保持了100%吞吐效率，饱和后仍维持95.5%的效率；UNI配置在24 Tbps负载时即出现饱和，最大吞吐效率约88.5%。关键延迟结果如下：32 Tbps标称负载下，UNI的云存储（高优先级）延迟为0.32 µs、网页搜索（中）为0.41 µs、媒体流（低）为119 µs，对应阈值分别为5 ms、15 ms和20 ms，高出三个数量级的延迟余量。AI数据中心中Hadoop流量在所有负载下最大延迟仅8 µs，比0.02 ms的严格阈值低一个数量级。
（2）高优先级流量强化场景（SC2）
在SC2下，UNI高优先级云流量从35%增至65%，PRI媒体流从20%增至45%，COM Hadoop从40%增至70%，SOC云存储从20%增至27%。结果表明，高优先级包的E2E延迟增幅极小：UNI的云流量在32 Tbps下延迟最大增幅10%，PRI为11.1%，COM为10.8%，SOC为6.2%，全部仍在亚微秒量级。有趣的是，低优先级流量表现出分类差异化的延迟行为：UNI和PRI中低优先级流量延迟反而下降高达80%（24–26 Tbps区间），这归因于SC2未改变低优先级流量的绝对比例而高优先级流量排空更快；SOC中低优先级流量延迟则增加高达74%，因为其低优先级流量占比本就高达70%且保持不变，导致排队延迟累积加剧。所有数据中心的丢包率始终低于提供负载的4%。
（3）服务器规模扩展（n=16/20/24）
随着每机架服务器数量从16增至20和24，高优先级包的延迟增幅在所有类别和场景中保持在12%以内，即使在超容量过载条件下仍能满足RTT阈值。COM中Hadoop延迟保持在6 µs以下（阈值5 ms），AI中Hadoop仅在极端过载下增加至182 µs，仍满足绝大多数AI负载要求。中低优先级包在高负载下延迟增幅显著：例如UNI中媒体流延迟从n=16时的302 µs增至n=24时的2161 µs（增幅615.6%），但相对20 ms阈值仍有充裕余量。服务器吞吐量随规模扩展呈比例下降：n=20和n=24时的平均每服务器吞吐量分别比n=16基线低21%和37%（归一化负载=1）。
（4）波长数扩展（w=4/6/8）
增加机架内数据波长（从4增至6和8）对高优先级流量延迟改善微乎其微（UNI中至多降低5.1%），但AI数据中心例外——由于全部流量均为高优先级Hadoop，Hadoop延迟降低达76%。低优先级流量则获得显著收益，延迟降低高达90%（32 Tbps负载下）。丢包率显著下降：w增至8后，COM、SOC和AI的丢包率降至提供负载的1.38%以下，UNI和PRI降至4.6%以下。
（5）机架内/机架间流量比变化（r=80/20、70/30、60/40）
随着机架间流量占比增加，高优先级包的延迟保持稳健：UNI中云存储在r=60/40时仍仅0.53 µs。中优先级包最敏感：UNI网页搜索延迟从0.39 µs（r=80/20）升至36.60 µs（r=70/30）和104.64 µs（r=60/40）。低优先级包相对增幅较小，但其绝对值保持较高水平。值得注意的是AI数据中心：r=60/40时Hadoop延迟达86.74 µs（负载32 Tbps），虽未超出20–200 µs的AI阈值范围，但表现出显著敏感性，揭示了静态固定配置架构在AI负载波动下的局限性。
（6）与最先进架构的对比
ALAS-DCN在支持6144台服务器的配置下实现亚微秒级高优先级延迟，优于aosphere（12 µs）、RGAIA（5–15 µs）、DaCon（18 µs）和ODRAD（7 µs）。功耗方面，ALAS-DCN在4096台服务器时总功耗0.27 MW，优于aosphere（5k服务器需1 MW）。成本方面，ALAS-DCN的CAPEX较EPS架构更高，但通过降低每比特能耗可实现长期OPEX节省。
五、结论与价值
本研究的科学价值在于：首次将商用QoS规范（而非自定义基准）直接嵌入光DCN架构的MAC协议设计中，实现了真正应用感知的协议级差异化服务。此前研究要么忽略应用分类，要么仅基于流大小启发式规则，而ALAS-DCN通过三层WDM MAC协议的协同设计，将优先级调度从流量层面提升至应用层面。其应用价值在于：为边缘数据中心（最多6144服务器）提供了可部署的低延迟解决方案，同时通过线性功耗增长扩展至20000台服务器的集中式云部署，为云服务商和共置设施提供了兼顾性能与能效的架构选择。作者也坦诚指出了局限：静态调度设计难以适应高度波动的AI流量，未来工作应引入SDN驱动的动态重构、控制器冗余和故障切换机制。
六、研究亮点