<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>深度长文 on 红旗下的蛋</title><link>https://blog.fallleaf.net/tags/deep-dive/</link><description>Recent content in 深度长文 on 红旗下的蛋</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><copyright>fallleaf</copyright><lastBuildDate>Sun, 13 Sep 2026 07:40:00 +0800</lastBuildDate><atom:link href="https://blog.fallleaf.net/tags/deep-dive/index.xml" rel="self" type="application/rss+xml"/><item><title>从 Anthropic 报告谈起，一个不容忽视的安全问题</title><link>https://blog.fallleaf.net/p/anthropic/</link><pubDate>Sun, 13 Sep 2026 07:40:00 +0800</pubDate><guid>https://blog.fallleaf.net/p/anthropic/</guid><description>&lt;img src="https://blog.fallleaf.net/p/anthropic/cover.webp" alt="Featured image of post 从 Anthropic 报告谈起，一个不容忽视的安全问题" /&gt;&lt;h2 id="云端-ai-服务的可见性"&gt;云端 AI 服务的可见性
&lt;/h2&gt;&lt;p&gt;近日，Anthropic 发布了关于模型输入风险、凭据滥用、供应链攻击、越权访问以及 AI 应用安全的研究和威胁情报报告，再次引发了业界对大模型安全问题的关注。&lt;/p&gt;
&lt;p&gt;报告本身当然值得关注。但从另一个视角看，更值得关注的其实是报告背后的一个问题：为什么 AI 服务商能够发现、分析和还原这些攻击行为？&lt;/p&gt;
&lt;p&gt;一个重要原因是，在现有主流云端 AI 服务架构中，用户与 AI 的交互发生在服务商控制的计算和服务环境中。用户请求最终需要进入服务端的计算链路，由模型完成 Tokenization、推理以及必要的工具调用；与此同时，服务侧还可能产生与请求相关的安全检测、会话信息、调用记录和其他遥测数据。具体哪些数据会被记录、保留多久、是否用于模型改进，取决于各服务商的产品策略、企业协议和合规要求；但从架构上看，服务侧至少需要获得足够的明文或明文派生数据，才能完成推理和基础的安全检测。&lt;/p&gt;
&lt;p&gt;这些信息使服务商具备了对 AI 交互过程进行观测、关联和分析的能力，从而能够在一定条件下识别异常行为、分析攻击链条，甚至还原部分攻击过程。&lt;/p&gt;
&lt;p&gt;当然，这并不意味着服务商可以任意查看所有用户数据，也不意味着所有请求都会被完整保存。具体能够看到什么、记录什么、保存多久，取决于具体服务的架构、产品策略和安全机制。&lt;/p&gt;
&lt;p&gt;但从架构层面看，一个基本事实是明确的：只要 AI 推理发生在服务商控制的计算环境中，用户数据就必须进入一种能够被该计算环境处理和理解的状态。对于文本、代码、文档等数据而言，这通常意味着数据本身以人类可理解的形式进入服务端，或者经过 Tokenization 等处理后，仍然保留能够被模型解析和推理的信息，而不是像端到端加密那样始终保持为服务端无法理解的密文。&lt;/p&gt;
&lt;p&gt;这与传统意义上的端到端加密通信存在一个根本区别。&lt;/p&gt;
&lt;p&gt;在端到端加密场景中，服务提供者可以负责传输和转发数据，但通常无法获得应用层的明文内容；而在云端 AI 推理场景中，模型本身必须对用户输入进行计算，因此服务端计算环境必须能够获得并处理相应的数据。&lt;/p&gt;
&lt;p&gt;这就带来了一个过去并不那么突出的安全问题：当数据进入计算环境之后，如何保护它？&lt;/p&gt;
&lt;p&gt;这个问题对于企业用户尤其重要。&lt;/p&gt;
&lt;p&gt;当企业把源代码、内部文档、客户资料、业务数据甚至核心知识交给 AI 进行分析时，安全边界已经不再只是“数据在网络上传输时是否被窃取”，而进一步涉及：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;数据进入 AI 服务后的处理过程；&lt;/li&gt;
&lt;li&gt;模型推理过程中的数据保护；&lt;/li&gt;
&lt;li&gt;上下文、缓存和中间数据的安全；&lt;/li&gt;
&lt;li&gt;AI Gateway、日志和监控等服务环节；&lt;/li&gt;
&lt;li&gt;第三方代理、插件以及工具调用形成的新数据链路。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;因此，AI 时代的数据安全边界正在发生一个重要变化：传统网络安全关注数据如何安全地传输和存储，而 AI 进一步提出了一个问题，数据如何在计算过程中保持安全。&lt;/p&gt;
&lt;p&gt;这也是为什么 Confidential AI、可信执行环境、Confidential GPU、私有化 AI 以及安全 AI Gateway 等技术开始受到关注。&lt;/p&gt;
&lt;p&gt;对于运营商而言，这意味着需要重新审视 AI 基础设施的安全边界，以及自己在这一新的安全边界中能够承担什么样的角色。&lt;/p&gt;
&lt;h2 id="ai时代的数据安全边界正在发生结构性变化"&gt;AI时代的数据安全边界正在发生结构性变化
&lt;/h2&gt;&lt;p&gt;在传统互联网体系中，数据安全的核心边界相对明确：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;确保数据在网络传输过程中不被第三方获取。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;因此形成了 HTTPS、TLS、VPN、IPSec 等成熟的网络安全体系。用户发送数据之前进行加密，数据通过网络传输，服务器收到以后再解密处理。对于中间网络而言，看到的主要是一段不可理解的密文。这种安全模型在过去几十年中非常有效。&lt;/p&gt;
&lt;p&gt;但生成式 AI 改变了数据的使用方式。&lt;/p&gt;
&lt;p&gt;企业今天交给 AI 的，往往已经不是普通的互联网信息，而是越来越有价值的生产数据：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;源代码、内部文档、客户信息、网络配置、业务流程、生产数据以及企业知识库。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这些数据进入 AI 服务以后，不再只是“经过网络”。它们还要被：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;理解、转换、计算、缓存和生成。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;一次典型的 AI 请求，大致会经历：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;用户 → API 网关 → 应用服务 → Token 化 → 模型推理 → GPU 计算 → 返回结果&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;用户请求通过 HTTPS 加密（TLS）传输到云端后，需要在服务端完成解密、解析和后续计算。文本经过 Tokenization 等处理后，进一步转换为模型可以计算的数值表示，进入推理引擎和 GPU 完成计算。&lt;/p&gt;
&lt;p&gt;当企业应用的信息通过加密进入AI服务的入口后，转换成可被大模型计算的数据，之后的每一个环节都可能形成新的数据安全隐患。因此，AI 时代安全与传统网络的主要变化就在于：过去主要关注 &lt;strong&gt;数据在网络中是否安全&lt;/strong&gt; ，而现在还必须关注： &lt;strong&gt;数据在计算过程中是否安全。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="为什么数据到了-ai-服务端必须被看见"&gt;为什么数据到了 AI 服务端必须被“看见”？
&lt;/h2&gt;&lt;h3 id="llm-的数据处理流程决定了这一点"&gt;LLM 的数据处理流程决定了这一点
&lt;/h3&gt;&lt;p&gt;大模型推理并不是简单地把一段文本送进一个“黑盒”。&lt;/p&gt;
&lt;p&gt;一次典型的文本LLM 交互大致经历以下环节：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;用户客户端通过 HTTPS（TLS）将文本请求发送到云端 API 网关；&lt;/li&gt;
&lt;li&gt;TLS 在网关或负载均衡处终止，被解密为明文数据（包含 Prompt、上下文、参数等）；&lt;/li&gt;
&lt;li&gt;服务将文本送入分词器（Tokenizer）转换为 Token ID 序列，再映射为高维向量（Embedding）；&lt;/li&gt;
&lt;li&gt;这些向量以浮点数矩阵形式进入 GPU 显存，参与大模型计算。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在这个过程中： &lt;strong&gt;TLS 只保护“网络传输阶段”&lt;/strong&gt; ，一旦到达云端网关就被解密，后续在应用层、推理引擎和显存中均以明文或明文派生形式（Token ID，向量等）存在；拥有服务器权限的运维人员、被攻破的服务进程、以及拿到日志/追踪数据的攻击者，都有能力读取这些内容。&lt;/p&gt;
&lt;p&gt;这就是传统传输加密与 AI 计算之间的边界。&lt;/p&gt;
&lt;h3 id="澄清误区token-化与向量不是加密"&gt;澄清误区：Token 化与向量不是加密
&lt;/h3&gt;&lt;p&gt;部分人存在一个误解：认为文本进入大模型前被分词并转成 Token ID（如把 &amp;ldquo;Hello&amp;rdquo; 转成 &lt;/p&gt;
\[9906\]&lt;p&gt;），或者转成高维向量（Embedding），就相当于完成了“加密”，这种认识是错误的。&lt;/p&gt;
&lt;p&gt;Token化（分词）是公开编码，而非加密，原因是分词只是基于公开词表（如 BPE 算法）进行的确切语义映射与离散化编码，类似将英文字母转为 ASCII 码。任何人拿着公开词表调用 decode() 函数，都能无损还原原始文本。&lt;/p&gt;
&lt;p&gt;而向量则是保留明文语义，Embedding 是为模型计算设计的语义表示，保留了高精度的空间与语义关联。研究显示，在特定攻击模型和假设条件下，攻击者有可能从这些向量中部分反推原始文本或推断敏感属性，因此不能把向量化理解为“安全转换”。&lt;/p&gt;
&lt;p&gt;所以Token化和向量依然属于“明文数据（plaintext）”的派生表示。只要数据以这种形式在服务侧流转或在显存中计算，数据泄露风险就依然存在。&lt;/p&gt;
&lt;h3 id="为什么不能即时通信那样做端到端加密"&gt;为什么不能即时通信那样做“端到端加密”？
&lt;/h3&gt;&lt;p&gt;传统即时通讯的端到端加密（E2EE）要求服务器只做中转，不理解内容：客户端 A 加密，客户端 B 解密，中间服务器看到的只是一堆无意义的密文。&lt;/p&gt;
&lt;p&gt;但大模型推理的基本条件就是“ &lt;strong&gt;服务商的大模型必须深度理解文本&lt;/strong&gt; ”，总结下来，主要有两点制约了采用加密数据进行大模型计算。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;• &lt;strong&gt;语义破坏&lt;/strong&gt; ：现代加密算法（如 AES-256）的目标之一，是让不知道密钥的观察者无法从密文中识别原始数据的结构和规律，理想情况下，密文在统计上应呈现接近随机的特征。对于没有密钥的大模型而言，加密后的文本表现为近似随机的序列，其中原有的词汇、句法、语义和上下文关系都不可直接获得。将这样的密文直接用于普通大模型训练，模型无法从中学习原始数据所包含的语言和知识规律，因此无法训练出具有相应语义能力的模型。&lt;/li&gt;
&lt;li&gt;• &lt;strong&gt;计算局限&lt;/strong&gt; ：普通大模型的推理需要将输入转换为 Token，并进一步形成模型可以进行数值计算的表示，再通过 Transformer 的矩阵运算完成推理。AES 等传统加密产生的密文不能直接作为具有原始语义的输入参与这一过程；在没有专门隐私计算机制的情况下，数据需要先在受信任的计算环境中解密，再转换为模型可以处理的表示。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;大模型要能工作，就必须“看懂”原始内容，这本身就决定了它在服务侧不可能处于传统意义上的加密保护状态&lt;/strong&gt; 。问题也由此发生了变化，过去需要解决的是“ &lt;strong&gt;传输过程中的数据保密&lt;/strong&gt; ” ， 现在需要进一步解决&amp;quot; &lt;strong&gt;计算过程中的数据保密&lt;/strong&gt; ”。这就是所谓的 &lt;strong&gt;计算安全&lt;/strong&gt; 。&lt;/p&gt;
&lt;h2 id="从传输安全走向计算安全两条技术路线"&gt;从传输安全走向计算安全：两条技术路线
&lt;/h2&gt;&lt;p&gt;如果希望 AI 在处理数据的同时，又尽可能减少计算环境对数据的暴露，目前大致存在两条技术路线。&lt;/p&gt;
&lt;h3 id="全同态加密密码学上的长期方向"&gt;全同态加密：密码学上的长期方向
&lt;/h3&gt;&lt;p&gt;全同态加密（FHE）的核心思想非常直接：允许直接在密文上进行加减乘除等运算，解密后的结果与在明文中计算完全一致。这是一个非常理想的方案。但问题在于计算效率。&lt;/p&gt;
&lt;p&gt;现代大模型涉及巨量矩阵运算，同时还包含注意力机制和各种非线性计算。在这些复杂计算场景下，FHE 仍然面临较大的性能和工程成本。在当下，用 FHE 运行大模型生成一个词可能需要数十分钟，暂不具备商业实用性。因此现阶段更适合把它看成： &lt;strong&gt;值得长期关注的密码学技术方向，而不是当前大规模通用 LLM 推理的主流工程方案&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="硬件机密计算tee--confidential-ai工程上的最佳现实解法"&gt;硬件机密计算（TEE / Confidential AI）：工程上的最佳现实解法
&lt;/h3&gt;&lt;p&gt;另一种思路完全不同。利用现代芯片（如 Intel TDX、AMD SEV-SNP、NVIDIA H100/B200、远程证明 + 密钥管理）在 GPU 和 CPU 内部搭建硬件级物理隔离的“黑盒飞地（Enclave）”。它并不试图让 AI 永远看不到数据。而是基于一个现实： &lt;strong&gt;AI 必须看到数据才能计算。&lt;/strong&gt; 那么需要解决的就是： &lt;strong&gt;能不能让只有可信计算环境看到这些数据？&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这就是 Confidential Computing 和 Confidential AI 的核心思想。其原理就是：数据在用户端通过密钥加密；密文通过加密通道（如 attested TLS）进入芯片内部的硬件安全区；仅在飞地内部解密并计算，计算结果加密后再输出。这种方式的优势在于： &lt;strong&gt;在 TEE 实现本身未被攻破、远程证明可信的前提下&lt;/strong&gt; ，哪怕云服务商的运维人员或操作系统被彻底攻破，也无法读取 TEE 内部的内存明文。其性能损耗通常仅在 &lt;strong&gt;2%–7%&lt;/strong&gt; ，多数场景低于 5%，是目前较为可行的“硬件级安全计算端到端保护”方案。&lt;/p&gt;
&lt;p&gt;需要强调的是，真正的“机密推理”不是简单打开某个 GPU 的安全功能，而是要把 CPU、GPU 和两者之间的数据传输一起保护起来，并在计算开始前确认整个环境是可信的。&lt;/p&gt;
&lt;h2 id="防患于未然应用部署层面的安全防护措施"&gt;防患于未然：应用部署层面的安全防护措施
&lt;/h2&gt;&lt;p&gt;在计算安全技术没有大规模应用普及之前，企业在部署 LLM 应用时，可以根据数据敏感程度采取分层防护措施。&lt;/p&gt;
&lt;h3 id="客户端与网关侧动态数据脱敏masking--redaction"&gt;客户端与网关侧：动态数据脱敏（Masking &amp;amp; Redaction）
&lt;/h3&gt;&lt;p&gt;在数据离开企业内网之前部署 AI 网关或脱敏中间件，利用规则和模型识别 API Key、身份证号、客户信息、财务数据等敏感内容，并用占位符（如 &lt;code&gt;[USER_1]&lt;/code&gt; ）替换后再发送给公网大模型，返回结果后在企业内部完成还原。&lt;/p&gt;
&lt;p&gt;这种方式对结构化敏感信息比较有效，但对于上下文中隐含的敏感信息，以及通过多轮对话逐步暴露的信息，仍然存在识别遗漏的风险。&lt;/p&gt;
&lt;h3 id="云端服务侧严格控制数据留存zero-data-retention"&gt;云端服务侧：严格控制数据留存（Zero Data Retention）
&lt;/h3&gt;&lt;p&gt;对于需要使用公网大模型、但又不希望数据长期留存在服务商侧的场景，应优先选择具有明确数据留存和训练使用策略的企业级 API 服务，并通过合同、配置和审计等方式进行约束。&lt;/p&gt;
&lt;p&gt;需要注意， &lt;strong&gt;ZDR 的核心是“不留存”或尽量减少留存，并不意味着数据在 GPU 中推理时就自动处于不可见状态&lt;/strong&gt; 。如果对计算过程本身也有较高的安全要求，则需要进一步采用机密计算等技术。&lt;/p&gt;
&lt;h3 id="部署形态侧敏感场景采用本地私有化部署local-llm"&gt;部署形态侧：敏感场景采用本地私有化部署（Local LLM）
&lt;/h3&gt;&lt;p&gt;对于核心代码、重要内部资料以及高度敏感的业务数据，可以将模型直接部署在企业私有云或内部计算节点中，使用 Ollama、vLLM 等推理框架运行开源模型。&lt;/p&gt;
&lt;p&gt;这种方式的核心优势是 &lt;strong&gt;数据不需要离开企业控制范围&lt;/strong&gt; 。但本地部署并不意味着“天然安全”，企业仍需负责模型更新、系统安全、访问控制、数据管理以及 GPU 资源和运行成本。&lt;/p&gt;
&lt;p&gt;因此，实际部署中可以根据数据敏感程度形成简单的选择：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;一般数据 → 云端 AI&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;敏感数据 → 脱敏后使用云端 AI&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;核心数据 → 企业私有化部署&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这比试图用一种技术解决所有 AI 数据安全问题，更符合目前的实际情况。&lt;/p&gt;
&lt;h2 id="对电信运营商的深刻启示"&gt;对电信运营商的深刻启示
&lt;/h2&gt;&lt;p&gt;作为拥有庞大网络基础设施、海量高价值用户数据以及承接大量政企信息化建设的运营商（如中国联通、中国移动、中国电信）来说，Anthropic 的报告提供了极具战略价值的启示。AI 时代，运营商参与 AI 安全，不能理解为增加一个新的安全产品，而应充分发挥自身在 &lt;strong&gt;网络、云、算力和边缘资源&lt;/strong&gt; 方面的优势，逐步从“提供连接”向“提供可信的 AI 基础设施”延伸。AI 数据安全将成为运营商进入这一领域的重要切入点。过去运营商解决的是 &lt;strong&gt;“企业如何连接云”&lt;/strong&gt; ，AI 时代可以解决 &lt;strong&gt;“企业如何安全地连接 AI”&lt;/strong&gt; ，再进一步则是 &lt;strong&gt;“企业如何获得可信的 AI 计算环境”&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="从连接安全向-ai-使用安全延伸"&gt;从连接安全向 AI 使用安全延伸
&lt;/h3&gt;&lt;p&gt;通过增强AI智能网关能力，将 AI 访问纳入运营商现有的政企网络和安全服务体系。&lt;/p&gt;
&lt;p&gt;重点不是运营商自己去做一个大模型，而是帮助企业解决AI 可以访问什么、数据能不能出去、应该使用什么模型，以及整个使用过程如何管理。将 AI 安全与政企专线、云联网、SD-WAN 等现有业务结合，逐步形成面向企业的 AI 安全接入能力。&lt;/p&gt;
&lt;h3 id="从提供算力向提供可信-ai-计算环境发展"&gt;从提供算力向提供可信 AI 计算环境发展
&lt;/h3&gt;&lt;p&gt;随着 GPU 算力逐步成为基础资源，单纯提供 GPU 的差异化空间将大大压缩。&lt;/p&gt;
&lt;p&gt;运营商可以进一步强化 AIDC 的 &lt;strong&gt;可信计算和安全保障能力&lt;/strong&gt; ，面向金融、政务、能源、工业以及大型企业等高敏感客户，提供从网络连接到 AI 计算的一体化可信环境。&lt;/p&gt;
&lt;p&gt;发展方向可以概括为： &lt;strong&gt;从“卖算力”向“提供可信的 AI 计算服务”转变&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="发挥网络和边缘资源优势发展分布式-ai"&gt;发挥网络和边缘资源优势，发展分布式 AI
&lt;/h3&gt;&lt;p&gt;AI 的计算位置将不再全部集中于少数大型数据中心。&lt;/p&gt;
&lt;p&gt;运营商应利用现有的省、市、县、园区和企业节点资源，根据业务对时延、数据安全和算力的不同要求，推动 AI 能力向网络边缘延伸。形成 &lt;strong&gt;中心算力负责通用 AI，边缘算力支撑低时延场景，本地算力承载高敏感业务&lt;/strong&gt; 。通过云边协同，使运营商广泛分布的网络和机房资源转化为 AI 基础设施优势。&lt;/p&gt;
&lt;h3 id="从单点能力建设走向云网边算一体化"&gt;从单点能力建设走向云—网—边—算一体化
&lt;/h3&gt;&lt;p&gt;运营商最大的优势并不是掌握某一项 AI 安全技术，而是能同时掌握 &lt;strong&gt;网络连接、数据传输、计算资源和分布式节点&lt;/strong&gt; ，形成系统级的可信 AI 基础设施解决方案。 通过逐步打通 AI 接入、网络连接、算力部署和安全管理，形成统一的 AI 基础设施服务体系，最终实现： &lt;strong&gt;让数据去合适的地方、让 AI 在合适的位置计算，并让整个过程可控、可管、可信。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="结语ai时代的安全边界正在进入计算内部"&gt;结语：AI时代的安全边界正在进入“计算内部”
&lt;/h2&gt;&lt;p&gt;AI 的发展正在改变数据安全的边界。&lt;/p&gt;
&lt;p&gt;过去，重点是保护数据在网络传输和存储过程中的安全；现在，企业越来越多地将代码、文档、客户信息和业务数据交给 AI 处理，安全问题进一步延伸到了 &lt;strong&gt;数据进入计算环境之后&lt;/strong&gt; 。因此，AI 时代的数据安全正在从： &lt;strong&gt;传输安全 → 计算安全 → 全生命周期安全。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;对运营商而言，在 AI 安全领域的演进可以归纳为一条主线： &lt;strong&gt;从“保障网络连接安全”，向“保障 AI 使用安全”，进一步向“提供可信 AI 基础设施”演进。&lt;/strong&gt; 其核心不是与专业 AI 厂商竞争模型和算法，而是发挥运营商 &lt;strong&gt;网络、云、算力和边缘资源的综合优势&lt;/strong&gt; ，成为企业 AI 应用与算力基础设施之间可信赖的连接者、服务者和安全保障者。&lt;/p&gt;
&lt;p&gt;最终需要解决的核心问题其实也很简单： &lt;strong&gt;让数据安全地到达 AI，让 AI 在可信的环境中计算。&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>从 POL 到 DC-POL：PON 正在进入数据中心基础设施网络——从 Hyperscale OOBM 到 Infrastructure Connectivity 的一次架构迁移</title><link>https://blog.fallleaf.net/p/from-pol-to-dc-pol-pon-entering-dc-infrastructure-architecture-migration/</link><pubDate>Tue, 01 Sep 2026 08:23:00 +0800</pubDate><guid>https://blog.fallleaf.net/p/from-pol-to-dc-pol-pon-entering-dc-infrastructure-architecture-migration/</guid><description>&lt;img src="https://blog.fallleaf.net/p/from-pol-to-dc-pol-pon-entering-dc-infrastructure-architecture-migration/cover.webp" alt="Featured image of post 从 POL 到 DC-POL：PON 正在进入数据中心基础设施网络——从 Hyperscale OOBM 到 Infrastructure Connectivity 的一次架构迁移" /&gt;&lt;h2 id="引言"&gt;引言
&lt;/h2&gt;&lt;p&gt;PON（Passive Optical Network，无源光网络）通常被认为是典型的&amp;quot;接入网技术&amp;quot;。过去二十多年，它最主要的应用场景是 FTTH、企业接入以及后来逐渐发展的 POL（Passive Optical LAN，无源光局域网）。在传统认知中，数据中心则属于完全不同的世界：服务器、交换机、GPU、RoCE、400G、800G 乃至 1.6T，构成了一个追求极致带宽和低时延的高速网络体系。PON 似乎与这样的环境格格不入。&lt;/p&gt;
&lt;p&gt;但这种认知正在发生变化。2026 年 8 月，Dell&amp;rsquo;Oro Group 首次针对数据中心和企业场景中的 PON 建立独立市场研究，并预计 2026 年 Data Center PON 设备收入同比增长 844%，2026—2030 年累计设备支出超过 30 亿美元，年复合增长率达到 52%。 Dell&amp;rsquo;Oro 明确指出，这一增长主要来自 Hyperscaler 利用 PON 降低数据中心 OOBM（Out-of-Band Management，带外管理）网络的布线和功耗需求。 需要说明的是，844% 的同比增长反映的是一个新兴市场从很小基数快速形成的过程，而非 PON 已经大规模替代传统 OOB 网络。52% 的 CAGR 意味着这一市场正在快速扩张，但当前规模仍远小于传统数据中心网络设备市场。&lt;/p&gt;
&lt;p&gt;这意味着，一个过去主要服务于家庭和企业及园区接入的技术，正处在进入数据中心的早期产业化阶段。问题随之而来：为什么是 PON？答案并不是 PON 突然拥有了比 400G、800G Ethernet 更高的性能，也不是 PON 准备进入 GPU 之间的高速计算网络。恰恰相反，PON 进入数据中心，是因为它解决的是一个完全不同的问题。&lt;/p&gt;
&lt;p&gt;AI 数据中心正在产生一个不同于 计算互联矩阵Compute Fabric 的基础设施互通Infrastructure Connectivity 问题，而 PON 可能成为解决这一问题的一种新型底层连接架构。目前最明确的应用是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。&lt;/p&gt;
&lt;p&gt;因此，PON 进入 IDC 并不是&amp;quot;接入网技术入侵数据中心&amp;quot;，而更像是一次架构上的自然迁移：过去 PON 通过 POL 解决建筑和园区中的海量低速终端连接，如今它开始尝试解决数据中心中海量 Rack 基础设施设备的连接问题。从这个角度看，Data Center PON 并不是一个突然出现的新技术，而可能是 POL 从 Building/Campus 向 AIDC Infrastructure Connectivity 的一次延伸。&lt;/p&gt;
&lt;h2 id="从-meta-到-dellorodata-center-pon-正在形成新的产业赛道"&gt;从 Meta 到 Dell&amp;rsquo;Oro：Data Center PON 正在形成新的产业赛道
&lt;/h2&gt;&lt;p&gt;Data Center PON 最值得关注的地方，不是某一家设备商突然推出了一个新产品，而是过去两年产业链已经出现了一条相对完整的演进路径：Hyperscaler 验证 → 设备商跟进 → 产品化 → 市场机构建立独立市场统计。这条路径意味着，PON 在数据中心已经开始从技术探索走向产业化早期。&lt;/p&gt;
&lt;h3 id="meta从概念走向实际工程架构"&gt;Meta：从概念走向实际工程架构
&lt;/h3&gt;&lt;p&gt;2025 年，Meta 在 NANOG 94 公开介绍了其 PON-based Data Center Management/Console 架构和工程实践。 其基础出发点非常明确：Meta 基础设施网络团队负责全球数据中心每个 Rack 的网络设备管理连接，包括 Ethernet、Serial、OOB 以及灾备网络。传统架构主要依靠部署在每个 Row 末端的 Ethernet Switch 和 Terminal Server，为 Rack 提供管理连接。&lt;/p&gt;
&lt;p&gt;随着数据中心规模扩大，这种架构开始暴露出明显问题：每个 Rack 的 Ethernet 和 Serial 连接数量受到固定设备限制；不同 Rack 类型需要进行 Row 级协调；需要维护大量 Row 级网络设备；同时还需要在 Goalpost 与 Rack 之间铺设大量铜缆。Meta 给出的解决方案不是继续增加管理交换机，而是引入 PON。&lt;/p&gt;
&lt;p&gt;其架构可以简单概括为：中心 OLT → ODN → Splitter → Rack ONU → Ethernet/Console。PON 由此承担数据中心 Management 和 Console 连接。Meta 公开的数据尤其值得关注。在其当前方案中，一个 Rack 可以提供最多 20 个 Ethernet 和 20 个 Console 连接，或者 32 个 Ethernet 和 8 个 Console 连接；一个 Row 可以提供最多 1280 个 Ethernet 连接和 800 个 Console 连接，而 12 个 Row 可以由两个集中式路由设备承担 OLT 聚合功能。&lt;/p&gt;
&lt;p&gt;更重要的是，Meta 并没有把 PON 简单理解成&amp;quot;用光纤替换铜缆&amp;quot;。它利用 PON 的集中式管理和无状态 ONU 设计，将 Rack 与数据中心 PON 拓扑解耦。ONU 部署到 Rack 之后，可以通过自动化资产管理系统进行识别和配置；当 ONU 发生故障时，只需要扫描新的设备即可完成替换。在布线方面，Meta 甚至表示，其 PON 方案使数据机房内部的网线走线架和网线分配单元得以完全取消，Rack 只需要标准化的 2 芯或 4 芯光纤连接，Rack 内部的网线则被限制在机架内部。&lt;/p&gt;
&lt;p&gt;这已经不是简单的技术验证，而是一种针对 Hyperscale 数据中心运行方式重新设计的网络架构。&lt;/p&gt;
&lt;h3 id="ciena从-hyperscaler-实践走向产业方案"&gt;Ciena：从 Hyperscaler 实践走向产业方案
&lt;/h3&gt;&lt;p&gt;Meta 之后，Ciena 已经将 PON 用于 Data Center Out-of-Band Management，并形成面向客户的解决方案。 Ciena 目前已经将 Data Center Out-of-Band Management（DCOM）定义为一种基于 PON 的解决方案，明确是解决针对传统 OOB 网络中存在的铜缆、设备数量、机架空间以及功耗和散热问题。其方案采用 XGS-PON 相关产品，并结合路由平台、PON 系统、控制软件、ONU 和 Console Server 构建数据中心 OOB 网络。&lt;/p&gt;
&lt;p&gt;Ciena 特别强调，AI 和云计算驱动的数据中心规模扩张正在使传统 OOB 架构越来越难以扩展，而 PON 能够通过集中式架构降低设备数量和布线复杂度。这说明 PON 已经不再只是 Hyperscaler 内部的一项架构创新，而开始形成可以向其他数据中心客户提供的产业解决方案。&lt;/p&gt;
&lt;h3 id="nokiapon-开始成为正式的数据中心产品"&gt;Nokia：PON 开始成为正式的数据中心产品
&lt;/h3&gt;&lt;p&gt;2026 年 3 月，Nokia 正式推出 Aurelis for Data Centers，将 PON 明确用于数据中心 OOBM。 Nokia 表示，其 Aurelis 方案在特定数据中心 OOBM 架构中可以减少最多 90% 的交换机、节省 50% 以上功耗，并将运维工作量降低最多 80%。 需要说明的是，这些数字是 Nokia 对其特定 PON-based OOBM 方案与传统架构进行比较后给出的目标性指标，而非行业普遍规律。&lt;/p&gt;
&lt;p&gt;但从产业角度看，数字本身并不是最重要的。真正重要的是：传统数据中心 OOB 网络已经开始被设备厂商视为一个可以由 PON 重新架构的独立市场。Nokia 甚至进一步把 PON 描述为一种面向 AI 和云数据中心的高效、可扩展、低功耗 OOBM 基础设施。&lt;/p&gt;
&lt;h3 id="delloro从产品市场进入产业市场"&gt;Dell&amp;rsquo;Oro：从产品市场进入产业市场
&lt;/h3&gt;&lt;p&gt;如果说 Meta 解决的是&amp;quot;能不能做&amp;quot;，Ciena 和 Nokia 解决的是&amp;quot;能不能产品化&amp;quot;，那么 Dell&amp;rsquo;Oro 在 2026 年的动作则解决了第三个问题：这个市场是否足够大，值得单独研究？答案已经非常明确。Dell&amp;rsquo;Oro 预计 2026 年 Data Center PON 设备收入同比增长 844%，2026—2030 年累计设备支出超过 30 亿美元，年复合增长率达到 52%。 同时，其市场定义已经明确覆盖 Data Center OOBM 以及 DCIM（Data Center Infrastructure Management）相关 PON 设备。&lt;/p&gt;
&lt;p&gt;因此，从产业生命周期来看，Data Center PON 已经完成了最初的几个关键阶段：Hyperscaler 工程验证 → 设备商产品化 → 产业方案形成 → 市场研究机构独立统计。这意味着 Data Center PON 已经进入产业化早期。但必须注意，这仍然是一个新兴市场。52% 的 CAGR 并不意味着 PON 已经大规模替代传统 OOB 网络，而是意味着一个此前规模很小甚至没有被单独统计的市场正在快速形成。&lt;/p&gt;
&lt;h2 id="aidc-真正改变的不是网络速度而是连接结构"&gt;AIDC 真正改变的不是网络速度，而是连接结构
&lt;/h2&gt;&lt;p&gt;理解 PON 为什么进入数据中心，不能只看 PON 本身，而必须重新观察 AI 数据中心的网络结构。过去谈数据中心网络，人们最容易想到的是交换机、服务器、GPU 和高速互联。AI 出现之后，这部分网络确实发生了剧烈变化。GPU 集群推动网络从 100G、200G 快速走向 400G、800G，并继续向 1.6T 演进。对于大规模 AI 训练而言，网络的核心指标是吞吐、时延、拥塞控制、无损传输以及集合通信效率。这构成了典型的 Compute Fabric。它解决的是 GPU 之间如何尽可能快地交换数据。在这个网络中，PON 几乎没有竞争优势。&lt;/p&gt;
&lt;p&gt;但是，如果把视野从 GPU 之间拉开，就会发现 AIDC 还有另外一个正在快速膨胀的网络。AI 数据中心不只有 GPU，还有大量&amp;quot;基础设施设备&amp;quot;。每一个 GPU 服务器都需要被管理。每一个 Rack 都需要电源管理。越来越复杂的液冷系统需要 CDU、泵、阀门和传感器。数据中心还存在大量 BMC、Console、PDU、UPS、CDU、HVAC、温湿度传感器、环境监测设备、安防与门禁设备以及其他 DCIM 基础设施。这些设备有一个共同特点：它们绝大多数并不需要 400G、800G 甚至 10G 网络。它们真正需要的是足够的带宽、可靠的连接、较低的成本、较低的功耗，以及能够支撑数万甚至数十万设备的统一运维体系。这与 GPU 网络形成鲜明对比。&lt;/p&gt;
&lt;p&gt;需要区分的是，BMC 和 Console 属于非常典型的 OOBM 网络，PDU 可以接入管理网络，而 CDU、HVAC 通常属于 BMS/DCIM/Facility Management 体系，Sensor 可能使用完全不同的协议和网络。因此，本文使用 Infrastructure Connectivity 这一更宽泛的概念来描述这些设备的连接需求，而非声称它们属于同一个网络域。&lt;/p&gt;
&lt;p&gt;从功能和工程需求看，AIDC 可以抽象为两个具有不同优化目标的网络域。本文将其分别称为 Compute Fabric 和 Infrastructure Fabric。需要说明的是，这一划分是本文的分析模型，而非行业已统一定义的标准架构。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;表 1：AIDC 二元网络结构对比&lt;/strong&gt;&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;网络类型&lt;/th&gt;
&lt;th&gt;主要连接对象&lt;/th&gt;
&lt;th&gt;核心需求&lt;/th&gt;
&lt;th&gt;典型技术&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Compute Fabric&lt;/td&gt;
&lt;td&gt;GPU、CPU、NIC、DPU&lt;/td&gt;
&lt;td&gt;极高带宽、极低时延&lt;/td&gt;
&lt;td&gt;Ethernet/RoCE/InfiniBand&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Infrastructure Fabric&lt;/td&gt;
&lt;td&gt;BMC、Console、PDU、CDU、Sensor 等&lt;/td&gt;
&lt;td&gt;海量连接、低成本、低功耗、易运维&lt;/td&gt;
&lt;td&gt;Ethernet / PON 等&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;从&amp;quot;高速网络&amp;quot;转向&amp;quot;海量连接&amp;quot;，传统数据中心网络的核心问题可以概括为&amp;quot;如何让每一条连接越来越快&amp;quot;，而 AI 数据中心越来越需要回答另一个问题：&amp;ldquo;如何用更低的成本连接越来越多的设备&amp;rdquo;。这两个问题并不矛盾。恰恰相反，它们构成了 AIDC 网络结构的两个不同维度。Compute Fabric 负责&amp;quot;高速计算&amp;quot;，Infrastructure Fabric 负责&amp;quot;海量基础设施连接&amp;quot;。这正是理解 Data Center PON 的关键。&lt;/p&gt;
&lt;p&gt;从架构上看，AIDC 的网络需求可以抽象为：&lt;/p&gt;
&lt;p&gt;&lt;svg width="621" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;font-size: 16px;fill: currentColor;max-width: 620.9708251953125px;" viewBox="0 0 620.9708251953125 1142" aria-roledescription="flowchart-v2" overflow="visible" height="1142" preserveAspectRatio="xMidYMid meet" role="img" aria-label="插图"&gt;&lt;g&gt;&lt;marker viewBox="0 0 10 10" refX="5" refY="5" markerUnits="userSpaceOnUse" markerWidth="8" markerHeight="8" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 0 0 L 10 5 L 0 10 z" style="stroke-width: 1px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 10 10" refX="4.5" refY="5" markerUnits="userSpaceOnUse" markerWidth="8" markerHeight="8" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 0 5 L 10 10 L 10 0 z" style="stroke-width: 1px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 11.5 14" refX="11.5" refY="7" markerUnits="userSpaceOnUse" markerWidth="10.5" markerHeight="14" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 0 0 L 11.5 7 L 0 14 z" style="stroke-width: 0px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="0px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 11.5 14" refX="1" refY="7" markerUnits="userSpaceOnUse" markerWidth="11.5" markerHeight="14" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;polygon points="0,7 11.5,14 11.5,0" style="stroke-width: 0px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="0px"&gt;&lt;/polygon&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 10 10" refX="11" refY="5" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;circle cx="5" cy="5" r="5" style="stroke-width: 1px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="1px"&gt;&lt;/circle&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 10 10" refX="-1" refY="5" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;circle cx="5" cy="5" r="5" style="stroke-width: 1px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="1px"&gt;&lt;/circle&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 10 10" refY="5" refX="12.25" markerUnits="userSpaceOnUse" markerWidth="14" markerHeight="14" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;circle cx="5" cy="5" r="5" style="stroke-width: 0px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="0px"&gt;&lt;/circle&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 10 10" refX="-2" refY="5" markerUnits="userSpaceOnUse" markerWidth="14" markerHeight="14" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;circle cx="5" cy="5" r="5" style="stroke-width: 0px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="0px"&gt;&lt;/circle&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 11 11" refX="12" refY="5.2" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 1,1 l 9,9 M 10,1 l -9,9" style="stroke-width: 2px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="2px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 11 11" refX="-1" refY="5.2" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 1,1 l 9,9 M 10,1 l -9,9" style="stroke-width: 2px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="2px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 15 15" refX="17.7" refY="7.5" markerUnits="userSpaceOnUse" markerWidth="12" markerHeight="12" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 1,1 L 14,14 M 1,14 L 14,1" style="stroke-width: 2.5px;" fill="currentColor" stroke="currentColor" stroke-width="2.5px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;marker viewBox="0 0 15 15" refX="-3.5" refY="7.5" markerUnits="userSpaceOnUse" markerWidth="12" markerHeight="12" orient="auto" style="fill: currentColor;stroke: currentColor;"&gt;&lt;path d="M 1,1 L 14,14 M 1,14 L 14,1" style="stroke-width: 2.5px;stroke-dasharray: 1px, 0px;" fill="currentColor" stroke="currentColor" stroke-width="2.5px"&gt;&lt;/path&gt;&lt;/marker&gt;&lt;g&gt;&lt;g&gt;&lt;/g&gt;&lt;g&gt;&lt;path d="M190.661,86L181.884,90.167C173.107,94.333,155.554,102.667,146.777,110.333C138,118,138,125,138,128.5L138,132" data-edge="true" data-et="edge" data-id="L_AIDC_COMPUTE_0" data-points="W3sieCI6MTkwLjY2MTEzMjgxMjUsInkiOjg2fSx7IngiOjEzOCwieSI6MTExfSx7IngiOjEzOCwieSI6MTM2fV0=" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="138,132 135.01887496600438,126.79299572386535 141.01883546374899,126.81476785063471" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M354.964,86L363.741,90.167C372.518,94.333,390.071,102.667,398.848,110.333C407.625,118,407.625,125,407.625,128.5L407.625,132" data-edge="true" data-et="edge" data-id="L_AIDC_INFRA_0" data-points="W3sieCI6MzU0Ljk2Mzg2NzE4NzUsInkiOjg2fSx7IngiOjQwNy42MjUsInkiOjExMX0seyJ4Ijo0MDcuNjI1LCJ5IjoxMzZ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="407.625,132 404.60618047562696,126.8147585707834 410.6061410402706,126.7930048878442" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M138,214L138,218.167C138,222.333,138,230.667,138,242.333C138,254,138,269,138,276.5L138,284" data-edge="true" data-et="edge" data-id="L_COMPUTE_COMPUTE_DEV_0" data-points="W3sieCI6MTM4LCJ5IjoyMTR9LHsieCI6MTM4LCJ5IjoyMzl9LHsieCI6MTM4LCJ5IjoyODh9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="138,284 135,278.80384757729337 141,278.80384757729337" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M138,342L138,350.167C138,358.333,138,374.667,138,390.333C138,406,138,421,138,428.5L138,436" data-edge="true" data-et="edge" data-id="L_COMPUTE_DEV_HIGH_BW_0" data-points="W3sieCI6MTM4LCJ5IjozNDJ9LHsieCI6MTM4LCJ5IjozOTF9LHsieCI6MTM4LCJ5Ijo0NDB9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="138,436 135,430.80384757729337 141,430.80384757729337" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M138,494L138,502.167C138,510.333,138,526.667,138,538.333C138,550,138,557,138,560.5L138,564" data-edge="true" data-et="edge" data-id="L_HIGH_BW_COMPUTE_NET_0" data-points="W3sieCI6MTM4LCJ5Ijo0OTR9LHsieCI6MTM4LCJ5Ijo1NDN9LHsieCI6MTM4LCJ5Ijo1Njh9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="138,564 135,558.8038475772934 141,558.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M407.625,214L407.625,218.167C407.625,222.333,407.625,230.667,407.625,238.333C407.625,246,407.625,253,407.625,256.5L407.625,260" data-edge="true" data-et="edge" data-id="L_INFRA_INFRA_DEV_0" data-points="W3sieCI6NDA3LjYyNSwieSI6MjE0fSx7IngiOjQwNy42MjUsInkiOjIzOX0seyJ4Ijo0MDcuNjI1LCJ5IjoyNjR9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="407.625,260 404.625,254.80384757729337 410.625,254.80384757729337" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M407.625,366L407.625,370.167C407.625,374.333,407.625,382.667,407.625,390.333C407.625,398,407.625,405,407.625,408.5L407.625,412" data-edge="true" data-et="edge" data-id="L_INFRA_DEV_CHARACTER_0" data-points="W3sieCI6NDA3LjYyNSwieSI6MzY2fSx7IngiOjQwNy42MjUsInkiOjM5MX0seyJ4Ijo0MDcuNjI1LCJ5Ijo0MTZ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="407.625,412 404.625,406.80384757729337 410.625,406.80384757729337" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M407.625,518L407.625,522.167C407.625,526.333,407.625,534.667,407.625,544.333C407.625,554,407.625,565,407.625,570.5L407.625,576" data-edge="true" data-et="edge" data-id="L_CHARACTER_ACCESS_0" data-points="W3sieCI6NDA3LjYyNSwieSI6NTE4fSx7IngiOjQwNy42MjUsInkiOjU0M30seyJ4Ijo0MDcuNjI1LCJ5Ijo1ODB9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="407.625,576 404.625,570.8038475772934 410.625,570.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M359.593,634L348.622,640.167C337.652,646.333,315.711,658.667,304.741,668.333C293.771,678,293.771,685,293.771,688.5L293.771,692" data-edge="true" data-et="edge" data-id="L_ACCESS_TRAD_0" data-points="W3sieCI6MzU5LjU5Mjc3MjkwMTA1ODIsInkiOjYzNH0seyJ4IjoyOTMuNzcwODMyMDYxNzY3NiwieSI6NjcxfSx7IngiOjI5My43NzA4MzIwNjE3Njc2LCJ5Ijo2OTZ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="293.77099609375,692 290.79430576601504,686.7904592627787 296.79424555036616,686.8173401883714" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M455.657,634L466.628,640.167C477.598,646.333,499.539,658.667,510.509,668.333C521.479,678,521.479,685,521.479,688.5L521.479,692" data-edge="true" data-et="edge" data-id="L_ACCESS_PON_0" data-points="W3sieCI6NDU1LjY1NzIyNzA5ODk0MTgsInkiOjYzNH0seyJ4Ijo1MjEuNDc5MTY3OTM4MjMyNCwieSI6NjcxfSx7IngiOjUyMS40NzkxNjc5MzgyMzI0LCJ5Ijo2OTZ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="521.47900390625,692 518.4556911831529,686.8173770947175 524.4556306389113,686.790422925572" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M293.771,774L293.771,778.167C293.771,782.333,293.771,790.667,293.771,798.333C293.771,806,293.771,813,293.771,816.5L293.771,820" data-edge="true" data-et="edge" data-id="L_TRAD_ACTIVE_0" data-points="W3sieCI6MjkzLjc3MDgzMjA2MTc2NzYsInkiOjc3NH0seyJ4IjoyOTMuNzcwODMyMDYxNzY3NiwieSI6Nzk5fSx7IngiOjI5My43NzA4MzIwNjE3Njc2LCJ5Ijo4MjR9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="293.77099609375,820 290.77099609375,814.8038475772934 296.77099609375,814.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M293.771,902L293.771,906.167C293.771,910.333,293.771,918.667,293.771,926.333C293.771,934,293.771,941,293.771,944.5L293.771,948" data-edge="true" data-et="edge" data-id="L_ACTIVE_COPPER_0" data-points="W3sieCI6MjkzLjc3MDgzMjA2MTc2NzYsInkiOjkwMn0seyJ4IjoyOTMuNzcwODMyMDYxNzY3NiwieSI6OTI3fSx7IngiOjI5My43NzA4MzIwNjE3Njc2LCJ5Ijo5NTJ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="293.77099609375,948 290.77099609375,942.8038475772934 296.77099609375,942.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M521.479,774L521.479,778.167C521.479,782.333,521.479,790.667,521.479,800.333C521.479,810,521.479,821,521.479,826.5L521.479,832" data-edge="true" data-et="edge" data-id="L_PON_OLT_0" data-points="W3sieCI6NTIxLjQ3OTE2NzkzODIzMjQsInkiOjc3NH0seyJ4Ijo1MjEuNDc5MTY3OTM4MjMyNCwieSI6Nzk5fSx7IngiOjUyMS40NzkxNjc5MzgyMzI0LCJ5Ijo4MzZ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="521.47900390625,832 518.47900390625,826.8038475772934 524.47900390625,826.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M521.479,890L521.479,896.167C521.479,902.333,521.479,914.667,521.479,924.333C521.479,934,521.479,941,521.479,944.5L521.479,948" data-edge="true" data-et="edge" data-id="L_OLT_ODN_0" data-points="W3sieCI6NTIxLjQ3OTE2NzkzODIzMjQsInkiOjg5MH0seyJ4Ijo1MjEuNDc5MTY3OTM4MjMyNCwieSI6OTI3fSx7IngiOjUyMS40NzkxNjc5MzgyMzI0LCJ5Ijo5NTJ9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="521.47900390625,948 518.47900390625,942.8038475772934 524.47900390625,942.8038475772934" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;path d="M521.479,1030L521.479,1034.167C521.479,1038.333,521.479,1046.667,521.479,1054.333C521.479,1062,521.479,1069,521.479,1072.5L521.479,1076" data-edge="true" data-et="edge" data-id="L_ODN_ONU_0" data-points="W3sieCI6NTIxLjQ3OTE2NzkzODIzMjQsInkiOjEwMzB9LHsieCI6NTIxLjQ3OTE2NzkzODIzMjQsInkiOjEwNTV9LHsieCI6NTIxLjQ3OTE2NzkzODIzMjQsInkiOjEwODB9XQ==" data-look="classic" style="stroke-width: 1px;stroke-dasharray: 0;" fill="none" stroke="currentColor" stroke-width="1px"&gt;&lt;/path&gt;&lt;polygon points="521.47900390625,1076 518.47900390625,1070.8038475772933 524.47900390625,1070.8038475772933" fill="currentColor" stroke="none" stroke-width="1px"&gt;&lt;/polygon&gt;&lt;/g&gt;&lt;g&gt;&lt;g transform="translate(-46.3, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_AIDC_COMPUTE_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(8.6, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_AIDC_INFRA_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(4.5, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_COMPUTE_COMPUTE_DEV_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(49.5, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_COMPUTE_DEV_HIGH_BW_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(-45.2, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_HIGH_BW_COMPUTE_NET_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(3.3, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_INFRA_INFRA_DEV_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(2.3, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_INFRA_DEV_CHARACTER_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(49.2, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_CHARACTER_ACCESS_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(-44, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_ACCESS_TRAD_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(5.9, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_ACCESS_PON_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(-0.1, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_TRAD_ACTIVE_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(44.2, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_ACTIVE_COPPER_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(-38.1, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_PON_OLT_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(20.2, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_OLT_ODN_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;g transform="translate(-14.1, 0)" style="background-color: rgba(232,232,232, 0.8);text-align: center;"&gt;&lt;g data-id="L_ODN_ONU_0" transform="translate(0, 0)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;"&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;g&gt;&lt;g data-look="classic" transform="translate(272.8125, 47)"&gt;&lt;rect x="-82.41666412353516" y="-39" width="164.8333282470703" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-52.416664123535156, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="52.416664123535156" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="52.416664123535156" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;AIDC&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="52.416664123535156" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;AI Data Center&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(138, 175)"&gt;&lt;rect x="-86.70833587646484" y="-39" width="173.4166717529297" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-56.708335876464844, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="56.708335876464844" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="56.708335876464844" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;Compute Fabric&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="56.708335876464844" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;计算网络&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(407.625, 175)"&gt;&lt;rect x="-127.08333587646484" y="-39" width="254.1666717529297" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-97.08333587646484, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="97.08333587646484" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="97.08333587646484" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;Infrastructure Connectivity&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="97.08333587646484" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;基础设施连接网络&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(138, 315)"&gt;&lt;rect x="-89.625" y="-27" width="179.25" height="54" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-59.625, -12)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="59.625" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;GPU / CPU / NIC&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(138, 467)"&gt;&lt;rect x="-99.94999694824219" y="-27" width="199.89999389648438" height="54" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-69.94999694824219, -12)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="69.94999694824219" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;400G / 800G / 1.6T&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(138, 607)"&gt;&lt;rect x="-130" y="-39" width="260" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-100, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="100" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;Ethernet / RoCE / InfiniBand&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(407.625, 315)"&gt;&lt;rect x="-130" y="-51" width="260" height="102" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-100, -36)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="100" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="100" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;BMC / Console / PDU&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="100" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;CDU / Sensor / Management Devices&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(407.625, 467)"&gt;&lt;rect x="-62" y="-51" width="124" height="102" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-32, -36)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="32" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="32" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;低带宽&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="32" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;+&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="32" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;海量连接&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(407.625, 607)"&gt;&lt;rect x="-85.19166564941406" y="-27" width="170.38333129882812" height="54" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-55.19166564941406, -12)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="55.19166564941406" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;Ethernet / PON&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(293.7708320617676, 735)"&gt;&lt;rect x="-86.21666717529297" y="-39" width="172.43333435058594" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-56.21666717529297, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="56.21666717529297" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="56.21666717529297" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;Traditional OOB&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="56.21666717529297" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;传统 OOB 网络&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(521.4791679382324, 735)"&gt;&lt;rect x="-91.49166870117188" y="-39" width="182.98333740234375" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-61.491668701171875, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="61.491668701171875" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="61.491668701171875" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;PON OOB&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="61.491668701171875" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;PON 化 OOB 网络&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(293.7708320617676, 863)"&gt;&lt;rect x="-78.41666412353516" y="-39" width="156.8333282470703" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-48.416664123535156, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="48.416664123535156" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="48.416664123535156" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;Active Switch&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="48.416664123535156" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;有源交换机&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(293.7708320617676, 991)"&gt;&lt;rect x="-55.46666717529297" y="-39" width="110.93333435058594" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-25.46666717529297, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="25.46666717529297" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="25.46666717529297" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;Copper&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="25.46666717529297" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;铜缆&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(521.4791679382324, 863)"&gt;&lt;rect x="-43.26667022705078" y="-27" width="86.53334045410156" height="54" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-13.266670227050781, -12)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="13.266670227050781" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;OLT&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(521.4791679382324, 991)"&gt;&lt;rect x="-70" y="-39" width="140" height="78" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-40, -24)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="40" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan x="40" dy="0" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;ODN&lt;/tspan&gt;&lt;/tspan&gt; &lt;tspan x="40" dy="1.2em" fill="rgb(51, 51, 51)" stroke="none" stroke-width="1px" font-size="16px"&gt;&lt;tspan leaf=""&gt;无源光网络&lt;/tspan&gt;&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt; &lt;g data-look="classic" transform="translate(521.4791679382324, 1107)"&gt;&lt;rect x="-45.69166564941406" y="-27" width="91.38333129882812" height="54" style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;g transform="translate(-15.691665649414062, -12)" style="font-family: 'trebuchet ms', verdana, arial, sans-serif;color: #333;text-align: center;"&gt;&lt;rect style="stroke-width: 1px;" fill="#ECECFF" stroke="#9370DB" stroke-width="1px"&gt;&lt;/rect&gt;&lt;text x="15.691665649414062" y="16" fill="rgb(51, 51, 51)" stroke="none" font-size="16" text-anchor="middle" style="color: #333;text-anchor: middle;" stroke-width="1px"&gt;&lt;tspan leaf=""&gt;ONU&lt;/tspan&gt;&lt;/text&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/g&gt;&lt;/svg&gt;&lt;/p&gt;
&lt;p&gt;这一模型有助于理解 PON 在 AIDC 中的定位：它不是要替代 Compute Fabric，而是为 Infrastructure Connectivity 提供一种新的架构选择。&lt;/p&gt;
&lt;p&gt;传统 OOB 网络的问题正在被 AIDC 放大。传统 OOB 网络通常以 Ethernet Management Switch 和 Console Server 为基础。当 Rack 数量较少时，这种架构非常合理。问题出现在规模。当一个数据中心从几百个 Rack 扩展到数千、数万 Rack 时，OOB 网络本身也需要大量交换机、Console 设备、铜缆、配线和电源。网络设备数量增加，又意味着更多机架空间、更多电源、更多散热、更多线缆、更多故障点和更多运维对象。Meta 在公开材料中描述的正是这个问题：传统架构存在大量 Row 级设备和铜缆分配，同时 Rack 连接能力受到固定设备限制。&lt;/p&gt;
&lt;p&gt;因此，AIDC 带来的真正变化不是&amp;quot;管理网络也需要更高带宽&amp;quot;，而是管理网络本身开始成为一个需要重新架构的超大规模基础设施网络。这恰好为 PON 创造了机会。&lt;/p&gt;
&lt;h2 id="pon-进入-idc其实是-pol-的一次自然延伸"&gt;PON 进入 IDC：其实是 POL 的一次自然延伸
&lt;/h2&gt;&lt;p&gt;如果把 PON 放回它过去二十年的发展历史，会发现 Data Center PON 并没有那么&amp;quot;离经叛道&amp;quot;。事实上，它与 POL 存在非常明显的架构同构。POL 解决的本来就是&amp;quot;海量低速连接&amp;quot;问题。Passive Optical LAN 的基本思想，是把传统企业 LAN 中的大量主动交换节点替换为 OLT + Passive Optical Distribution Network + Splitter + ONU/ONT。TIA Fiber Optics Technology Consortium 对 POL 的定义，本身就是将 GPON 等 PON 技术适配到企业 LAN 环境中，其主要特点包括更少的设备和布线、集中式管理以及较低的能源需求。&lt;/p&gt;
&lt;p&gt;传统企业 LAN 通常是 Core → Aggregation → Access Switch → Copper → Terminal，而 POL 则变成 OLT → Passive ODN → Splitter → ONU → Terminal。PON 最重要的价值并不是&amp;quot;光纤比铜缆快&amp;quot;。真正的价值在于：把大量终端的接入复杂度，从分布式主动交换设备重新集中到网络中心。这正是 Data Center OOBM 现在面临的问题。&lt;/p&gt;
&lt;p&gt;需要特别说明的是，PON 的价值并不只是把铜缆换成光纤。如果只是传输介质由铜缆改为光纤，仍然可以保留大量交换机，只不过是将互联口改为光模块。PON 真正改变的是网络的主动/被动分工以及设备部署方式：将大量中间连接变成无源光网络，把网络智能集中到 OLT，从而减少有源设备数量、降低功耗和运维复杂度。&lt;/p&gt;
&lt;p&gt;从 Building 到 Rack，POL 架构发生了一次空间映射。传统 POL 的连接对象是 Building/Floor/Room/Terminal，而 Data Center PON 的连接对象变成 Data Hall/Row/Rack/Infrastructure Device。两者的逻辑关系高度相似。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;表 2：传统 POL 与 Data Center PON 架构对比&lt;/strong&gt;&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;传统 POL 元素&lt;/th&gt;
&lt;th&gt;Data Center PON 对应物&lt;/th&gt;
&lt;th&gt;功能说明&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Building/Campus&lt;/td&gt;
&lt;td&gt;Data Center&lt;/td&gt;
&lt;td&gt;物理空间范围&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Floor/Room&lt;/td&gt;
&lt;td&gt;Row/Rack&lt;/td&gt;
&lt;td&gt;细分连接单元&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;OLT&lt;/td&gt;
&lt;td&gt;OLT&lt;/td&gt;
&lt;td&gt;核心控制设备&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;ODN&lt;/td&gt;
&lt;td&gt;DC Optical Distribution Network&lt;/td&gt;
&lt;td&gt;光纤分配网络&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Passive Splitter&lt;/td&gt;
&lt;td&gt;Passive Splitter&lt;/td&gt;
&lt;td&gt;光信号分配&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;ONU/ONT&lt;/td&gt;
&lt;td&gt;Rack ONU&lt;/td&gt;
&lt;td&gt;终端设备&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;PC/AP/Phone/Camera&lt;/td&gt;
&lt;td&gt;BMC/Console/PDU 等&lt;/td&gt;
&lt;td&gt;被连接设备&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Enterprise LAN&lt;/td&gt;
&lt;td&gt;OOBM/Infrastructure Management&lt;/td&gt;
&lt;td&gt;网络类型&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Copper LAN&lt;/td&gt;
&lt;td&gt;Rack 内部铜缆&lt;/td&gt;
&lt;td&gt;末端连接&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Fiber backbone&lt;/td&gt;
&lt;td&gt;Fiber-to-Rack&lt;/td&gt;
&lt;td&gt;主干连接&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;因此，与其说 PON 进入了一个完全陌生的数据中心领域，不如说 POL 已经证明了 PON 在建筑和园区中进行大规模终端连接的可行性，而 Data Center PON 只是把&amp;quot;终端&amp;quot;从办公室设备变成了 Rack 基础设施设备。本文将这种从 POL 向数据中心基础设施连接延伸的架构思路称为&amp;quot;DC-POL&amp;quot;（Data Center Passive Optical LAN）。需要说明的是，DC-POL 并非行业已统一定义的标准术语，而是本文用于理解 POL 架构向数据中心延伸的分析框架。它描述的是将 POL 的被动光接入架构思想延伸到数据中心 Rack 级 Infrastructure Connectivity。&lt;/p&gt;
&lt;p&gt;PON 真正改变的是&amp;quot;主动设备的位置&amp;quot;。传统 OOB 网络的核心逻辑是在距离被管理设备较近的位置部署主动交换设备。而 PON 的逻辑恰好相反：尽可能把网络智能集中到 OLT，将中间大量连接变成无源光网络。这也是为什么 PON 能够产生明显的规模效应。在传统架构中，Rack 数量增加意味着 Rack 增加 → Switch 增加 → 铜缆增加 → 电源增加 → 运维对象增加。而 PON 架构更接近 Rack 增加 → ONU 增加 → ODN 扩展。大量中间连接本身不再需要主动电子设备。这也是 PON 最核心的经济学基础。&lt;/p&gt;
&lt;p&gt;经济性并不来自&amp;quot;单端口更便宜&amp;quot;，而来自网络结构变化。Nokia 表示，其 Aurelis 方案在特定数据中心 OOBM 架构中可以减少最多 90% 的主动交换设备、节省 50% 以上功耗，并将运维工作量降低最多 80%。 这些数字的真正含义，不应该简单理解为&amp;quot;PON 设备比交换机便宜&amp;quot;。更准确的理解是：PON 改变了数据中心基础设施网络中有源设备与无源基础设施的比例。传统网络需要在大量位置布置有源设备。PON 则把大量复杂度集中到少数 OLT，同时使用无源 ODN 完成大规模分配。于是，成本结构发生变化：有源设备 CAPEX 下降；设备功耗下降；散热需求下降；铜缆与配线复杂度下降；网络设备数量下降；维护对象数量下降。这才是 PON 进入 AIDC 最值得关注的地方。&lt;/p&gt;
&lt;p&gt;Meta 案例进一步说明了这种结构性变化。Meta 公开资料显示，其 PON 架构不仅减少铜缆，而且通过标准化 Rack 光纤 Handoff，将 Rack 本身与数据中心 PON 拓扑解耦。 每个 Rack 只需要标准化的 2 芯或 4 芯光纤连接，而 Rack 内部的 ONU、Splitter 和 Console 组件则封装在 Rack 级 Canopy 中。这种设计带来一个非常重要的工程价值：数据中心网络拓扑不再需要随着 Rack 类型变化而频繁变化。对于 AI 数据中心而言，这一点尤其重要。因为 AI 基础设施正在快速变化：GPU 服务器不断更新；Rack 功率不断变化；液冷方案不断变化；Server SKU 不断变化；Rack 密度不断变化。如果基础设施网络能够与 Rack 内部设备解耦，那么数据中心的网络拓扑就不必跟随每一次硬件迭代重新设计。因此，PON 的价值最终不仅是少几台交换机，而是建立一种更加稳定的基础设施连接底座。这正是 POL 架构进入 AIDC 之后可能产生的更深层价值。&lt;/p&gt;
&lt;p&gt;在工程落地层面，将 PON 引入数据中心也带来了物理层与运维特性的变革。将铜缆替换为光纤虽然大幅简化了机柜间布线，但光纤对弯折半径的敏感性以及光接口的防尘防污染要求，对高频插拔维护提出了新挑战，通常需要依赖标准化 Canopy 与预连接光缆来降低现场损伤率。同时，PON 网络改变了故障隔离边界（Blast Radius）——传统以太网交换机故障通常仅影响单个端口或特定设备，而无源光分配网（ODN）主干光纤或关键分光器的物理损坏可能导致整个机架排（Row）甚至整个数据中心的带外管理瞬间失联，这对 OLT 的冗余保护机制（如 Type B/Type C ）提出了极高的工程可靠性要求。&lt;/p&gt;
&lt;h2 id="pon-在-aidc-还能走多远"&gt;PON 在 AIDC 还能走多远？
&lt;/h2&gt;&lt;p&gt;如果 Data Center PON 已经能够承担 OOBM 和 Console，那么下一个问题自然是：它能不能继续向 AIDC 其他基础设施扩展？这里需要保持克制。目前最明确、最成熟的应用仍然是 OOBM、Management 和 Console。Dell&amp;rsquo;Oro 目前对 Data Center PON 的市场定义也主要覆盖 OOBM 和 DCIM。 因此，可以把潜在应用划分为不同层次。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;表 3：PON 在 AIDC 中的应用场景与适配度&lt;/strong&gt;&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;应用场景&lt;/th&gt;
&lt;th&gt;PON 适配度&lt;/th&gt;
&lt;th&gt;当前状态&lt;/th&gt;
&lt;th&gt;说明&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;OOBM&lt;/td&gt;
&lt;td&gt;★★★★★&lt;/td&gt;
&lt;td&gt;已验证&lt;/td&gt;
&lt;td&gt;已经出现明确产业实践&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Console&lt;/td&gt;
&lt;td&gt;★★★★★&lt;/td&gt;
&lt;td&gt;已验证&lt;/td&gt;
&lt;td&gt;已经验证&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;BMC/设备管理&lt;/td&gt;
&lt;td&gt;★★★★☆&lt;/td&gt;
&lt;td&gt;潜在&lt;/td&gt;
&lt;td&gt;与 OOBM 高度相关&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;PDU/电源管理&lt;/td&gt;
&lt;td&gt;★★★★☆&lt;/td&gt;
&lt;td&gt;潜在&lt;/td&gt;
&lt;td&gt;具有扩展潜力&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;CDU/HVAC/环境监控&lt;/td&gt;
&lt;td&gt;★★★☆☆&lt;/td&gt;
&lt;td&gt;潜在&lt;/td&gt;
&lt;td&gt;潜在 Infrastructure Connectivity&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Sensor/IoT&lt;/td&gt;
&lt;td&gt;★★★☆☆&lt;/td&gt;
&lt;td&gt;潜在&lt;/td&gt;
&lt;td&gt;需要结合具体设备模型&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Facility Management&lt;/td&gt;
&lt;td&gt;★★★☆☆&lt;/td&gt;
&lt;td&gt;潜在&lt;/td&gt;
&lt;td&gt;更长期的扩展方向&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;GPU Compute Fabric&lt;/td&gt;
&lt;td&gt;★☆☆☆☆&lt;/td&gt;
&lt;td&gt;不适合&lt;/td&gt;
&lt;td&gt;不属于 PON 优势领域&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;高速 Storage Fabric&lt;/td&gt;
&lt;td&gt;★☆☆☆☆&lt;/td&gt;
&lt;td&gt;不适合&lt;/td&gt;
&lt;td&gt;不属于 PON 优势领域&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;OOBM 和 Console 是目前 PON 最明确的切入点，BMC/设备管理和 PDU/电源管理与 OOBM 高度相关，具有扩展潜力。CDU/HVAC/环境监控、Sensor/IoT 以及 Facility Management 属于潜在 Infrastructure Connectivity，是更长期的扩展方向，但需要结合具体设备模型和网络协议进一步验证。因此，PON 未来在 AIDC 中的合理演进路径，并不是 OOBM → 取代整个 Data Center Network，而更可能是 OOBM → Infrastructure Management → 更广泛的 Infrastructure Connectivity。这是一条完全不同的路线。&lt;/p&gt;
&lt;p&gt;PON 不会进入 Compute Fabric。这是理解整个产业趋势时必须划出的边界。GPU 之间的网络追求的是极高吞吐、极低时延、高带宽密度、高性能拥塞控制以及大规模集合通信效率。PON 的点到多点共享介质架构并不是为这个问题设计的。因此，没有必要把 Data Center PON 理解成&amp;quot;PON 挑战 800G Ethernet&amp;quot;。这其实是一个错误的问题。真正的问题应该是：当 GPU 网络越来越快、AI 数据中心越来越大之后，管理和基础设施网络是否仍然需要沿用传统的逐级 Ethernet 交换架构？如果答案是否定的，那么 PON 就有了自己的位置。&lt;/p&gt;
&lt;p&gt;对于这一架构何时能跨越经济临界点，取决于几个核心要素的挤压：首先是机房的物理密度与节点规模，只有当单个 Data Hall 内的带外管理节点与基础设施连接数达到特定阈值（如千级以上连接点）时，OLT 的集中式端口 CAPEX 优势才能完全抵消 ODN 的首次铺设成本；其次是自动化与无状态运维（Stateless Operation）能力，PON 架构依赖“即插即用、扫码替换”的自动化控制器与 IPAM 体系来释放 OPEX 优势，若缺乏强有力的软件支撑，其初始配置门槛反而高于传统以太网交换机。&lt;/p&gt;
&lt;h2 id="结语"&gt;结语
&lt;/h2&gt;&lt;p&gt;过去，人们很容易把 PON 理解成一种&amp;quot;接入网技术&amp;quot;。因为它诞生于运营商网络，长期服务于家庭和企业接入，因此形成了一个根深蒂固的认知：PON 属于接入网，Ethernet 属于数据中心。但技术的边界从来不是由历史决定的，而是由问题决定的。工业PON，POL以及定义的DC-PON，也就反映了这种边界的调整。当数据中心只有几百个 Rack 时，传统 OOB Ethernet 可能已经足够简单。当数据中心进入 Hyperscale 和 AI 时代，Rack 数量不断增加，管理设备、基础设施设备和传感器数量不断增长，传统 OOB 网络本身也开始成为一个需要优化的基础设施。这时，PON 所擅长的事情突然变得重要：集中式管理、点到多点连接、无源光分配、较少主动设备、较低功耗，以及面向海量终端的规模化接入。&lt;/p&gt;
&lt;p&gt;所以，PON 进入 IDC 并不是&amp;quot;接入网技术入侵数据中心&amp;quot;。它更像是 POL 的一次自然延伸：从连接 Building 中的大量终端，走向连接 Data Center 中的大量 Rack 基础设施。AIDC 正在产生一个不同于 Compute Fabric 的 Infrastructure Connectivity 问题，而 PON 可能成为解决这一问题的一种新型底层连接架构。目前最明确的应用是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;综合来看，本文的核心判断可以概括为三句话：&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第一，事实判断：&lt;/strong&gt; PON-based OOBM 已经从 Hyperscaler 的工程实践进入设备商产品化和产业研究阶段，Data Center PON 正在成为一个新兴市场。这对目前运营商大量的PON网络技术人员是一个利好的信息。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第二，产业判断：&lt;/strong&gt; 其核心驱动力并不是数据中心对更高速网络的需求，而是 AI 数据中心规模扩大后，对海量低带宽基础设施设备进行低成本连接和运维的需求。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第三，前瞻判断：&lt;/strong&gt; 从架构上看，这可以视为 POL 从 Building/Campus Connectivity 向 Data Center Infrastructure Connectivity 的一次延伸；但目前最明确的应用仍是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。&lt;/p&gt;
&lt;p&gt;而一个更值得继续研究的问题是：究竟从多大规模开始，AIDC 的 Infrastructure Connectivity 会出现采用 DC-POL 的经济临界点？这可能决定 PON 究竟只是数据中心 OOBM 领域的一项优化技术，还是会进一步成为 AIDC 基础设施网络的一种新型基础架构。&lt;/p&gt;
&lt;h2 id="参考资料"&gt;参考资料
&lt;/h2&gt;&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Dell&amp;rsquo;Oro Group.&lt;/strong&gt; (2026, August). &lt;em&gt;Data Center and Enterprise PON Equipment 5-Year Forecast Report&lt;/em&gt;.&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Dell&amp;rsquo;Oro Group Official Market Research
&lt;ul&gt;
&lt;li&gt;引用说明：提供 2026 年 Data Center PON 设备收入同比增长 844%、2026—2030 年累计支出 30 亿美元及 52% CAGR 的市场预测数据与 DCIM/OOBM 场景定义。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;ol start="2"&gt;
&lt;li&gt;&lt;strong&gt;Meta Infrastructure Networking Team / Bhatia, Anurag.&lt;/strong&gt; (2025). &lt;em&gt;PON-based Data Center Management &amp;amp; Console Architecture in Hyperscale Environments&lt;/em&gt;. Presented at &lt;strong&gt;NANOG 94&lt;/strong&gt; (North American Network Operators&amp;rsquo; Group).&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;[NANOG 94 Presentation Archives]
&lt;ul&gt;
&lt;li&gt;引用说明：提供 Meta 在数据中心引入 PON 替换 Row 级交换机/铜缆的工程实践，包括 Canopy 机柜顶端封装、无状态 ONU 以及每个 Row/Rack 的连接密度数据。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;ol start="3"&gt;
&lt;li&gt;&lt;strong&gt;Ciena Corporation.&lt;/strong&gt; (2025/2026). &lt;em&gt;Data Center Out-of-Band Management (DCOM) Solution Brief&lt;/em&gt;.&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;引用说明：出处文中“Ciena 实践”，提供基于 XGS-PON 的数据中心带外管理与路由平台整合商业解决方案。&lt;/li&gt;
&lt;/ul&gt;
&lt;ol start="4"&gt;
&lt;li&gt;&lt;strong&gt;Nokia Solutions and Networks.&lt;/strong&gt; (2026, March). &lt;em&gt;Nokia Aurelis for Data Centers: Reimagining Infrastructure Out-of-Band Management with Passive Optical Networks&lt;/em&gt;.&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;引用说明：出处文中“Nokia 2026 年 3 月发布”，提供 Aurelis 方案在有源设备减少率（最多 90%）、功耗降低（50% 以上）及运维优化（最多 80%）的特定对比指标。&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>AI时代运营商光缆基础设施商业模式重构——从光传输服务到光纤资源与网络控制权开放</title><link>https://blog.fallleaf.net/p/ai-era-fiber-infrastructure-business-model-shift/</link><pubDate>Mon, 31 Aug 2026 07:45:00 +0800</pubDate><guid>https://blog.fallleaf.net/p/ai-era-fiber-infrastructure-business-model-shift/</guid><description>&lt;img src="https://blog.fallleaf.net/p/ai-era-fiber-infrastructure-business-model-shift/cover.webp" alt="Featured image of post AI时代运营商光缆基础设施商业模式重构——从光传输服务到光纤资源与网络控制权开放" /&gt;&lt;p&gt;&lt;strong&gt;摘要&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;人工智能大模型的发展对数据中心互联（Data Center Interconnect，DCI）的传输容量、时延、可靠性和扩展能力提出了更高的要求。与传统企业专线和云连接业务相比，AI 训练、推理以及多数据中心协同对高通量的传输带宽持续占用程度更高，网络成本在整体基础设施成本中的重要性也随之上升。在这一背景下，当长期稳定的 DCI 容量需求达到一定规模后，持续向运营商租用高速电路的经济性可能下降，而租用暗光纤、采用托管光网络（MOFN）、长期 IRU，乃至参与建设专用光网络的经济性则可能逐渐显现。&lt;/p&gt;
&lt;p&gt;因此，AI 对运营商网络商业模式产生的真正影响，并不是简单地把市场从&amp;quot;电路出租&amp;quot;推向&amp;quot;光纤出租&amp;quot;，而是使 &lt;strong&gt;网络基础设施的控制权开始具有独立的商业价值&lt;/strong&gt; 。客户可以根据自身的规模和技术能力，在电路、波长、托管光网络、暗光纤、长期使用权以及联合建设等不同层级之间进行选择。运营商则需要从单纯销售带宽，转向对光纤、光层、路由、机房、电力以及运维能力等基础设施资源进行分层产品化和定价。&lt;/p&gt;
&lt;p&gt;值得注意的是，光缆租用模式的成功不仅取决于&amp;quot;是否率先推出&amp;quot;，更取决于 &lt;strong&gt;运营商自身的光缆资源禀赋&lt;/strong&gt; 。资源占优的运营商可能通过光缆租用进一步巩固市场地位，而资源薄弱的运营商可能面临&amp;quot;起个大早，干个晚集&amp;quot;的风险。&lt;/p&gt;
&lt;p&gt;同时，结合三大运营商当前均具备自研模块化波分（电信叫DCI-BOX，移动叫极简OTN）设备的软硬件能力，运营商完全可以将“自研波分硬件 + 物理纤芯”进行深度打包。这种“软硬一体”的组合模式，既为客户大幅降低了自建光网络的设备采购门槛与技术对接成本，又避免了运营商陷入纯纤芯出租的“管道化”陷阱，为网络控制权分层开放探索出一条兼具毛利与粘性的中国特色演进路径。&lt;/p&gt;
&lt;p&gt;国际市场已经出现这一趋势的不同形态。Verizon 与 Google 的大额暗光纤协议、Zayo 与 NVIDIA 以锚定客户推动长途光纤建设，以及香港电讯提供的 3.2Tbps AI DCI Superhighway，分别代表了物理光纤开放、基础设施投资前置以及高等级托管网络三种不同路径。与此同时，2026 年 ACG Research 对 Wavelength、MOFN 和 Dark Fiber 的 TCO 比较进一步表明，在较低带宽水平下波长服务具有成本优势，而进入多 Tbps 规模后，MOFN 和 Dark Fiber 的经济性开始增强。&lt;/p&gt;
&lt;p&gt;由此可以认为，AI 时代运营商面临的核心问题并非是否放弃电路业务，而是如何识别不同客户的经济性拐点，并将网络控制权设计为具有不同价格、责任和服务边界的产品体系。运营商未来的角色，也可能由传统的&amp;quot;网络服务提供者&amp;quot;进一步演变为&amp;quot;网络基础设施资产运营者&amp;quot;。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;关键词：&lt;/strong&gt; 人工智能；数据中心互联；DCI；暗光纤；MOFN；光网络；TCO；网络控制权；电信运营商；基础设施资产&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="问题的提出ai-正在改变-dci-的价值结构"&gt;问题的提出：AI 正在改变 DCI 的价值结构
&lt;/h2&gt;&lt;p&gt;人工智能基础设施的发展正在使数据中心从相互独立的计算设施逐步演变为由高速网络连接起来的分布式计算系统。大模型训练需要在多个计算节点之间持续交换模型参数、梯度和中间状态；训练数据集、检查点以及模型副本也可能在不同数据中心之间进行传输；在推理阶段，模型部署又可能从单一数据中心扩展到多个区域和多个计算资源池。因此，AI 基础设施的计算能力与网络连接能力正在形成越来越紧密的耦合关系。&lt;/p&gt;
&lt;p&gt;需要指出的是，AI 对网络的要求并不能简单概括为&amp;quot;必须使用微秒级网络&amp;quot;或者&amp;quot;必须实现绝对无损传输&amp;quot;。不同 AI 工作负载、不同网络架构以及不同训练并行方式对网络的要求存在明显差异。更准确的说法是，AI 集群通常更加敏感于网络吞吐、尾部时延、抖动、丢包以及拥塞，并且在大规模分布式训练中，网络性能下降可能转化为 GPU 利用率下降。因此，当计算集群规模不断扩大以后，网络已经从传统意义上的连接资源逐渐成为影响算力利用率的重要基础设施。&lt;/p&gt;
&lt;p&gt;传统运营商提供的电路、专线和波长服务，本质上是将复杂的网络基础设施封装成一种标准化服务。客户购买的是一定的带宽、时延和可用性，而无需承担光纤、传输设备、线路维护以及光层故障处理等责任。这种商业模式的优势在于简单、稳定和可管理，也使运营商能够持续通过带宽升级获取增量收入。&lt;/p&gt;
&lt;p&gt;然而，随着单个客户长期占用的 DCI 容量不断提高，这种模式可能出现一个重要的经济性变化。客户如果长期购买大量固定带宽，其累计支付的服务费用可能逐渐接近甚至超过直接控制底层光网络所需要承担的光纤租金、传输设备、运维以及冗余成本。在这种情况下，客户就有动力把网络控制边界向下移动，从购买&amp;quot;网络服务&amp;quot;转向购买&amp;quot;网络资源&amp;quot;。&lt;/p&gt;
&lt;p&gt;这就是本文所讨论的 &lt;strong&gt;DCI 经济性拐点&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;因此，本文的核心问题不是&amp;quot;AI 是否需要更多光纤&amp;quot;，而是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;当 DCI 容量达到什么规模以后，客户购买运营商封装好的带宽服务将不再是最优解？&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;进一步的问题则是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;当客户开始愿意承担部分光层和网络运维责任以后，运营商应该开放多少控制权，以及如何对不同层级的控制权进行定价？&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;以及：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;在三大运营商具备自研模块化波分设备的前提下，“自研硬件 + 纤芯”打包的融合模式如何重构 DCI 的商业边界与价值分配？&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="dci-的经济性拐点从带宽价格到基础设施-tco"&gt;DCI 的经济性拐点：从&amp;quot;带宽价格&amp;quot;到&amp;quot;基础设施 TCO&amp;quot;
&lt;/h2&gt;&lt;p&gt;在传统网络业务中，客户通常根据所需带宽直接购买电路。例如企业需要 10G、100G 或 400G 连接，其主要决策变量是带宽价格、SLA 和服务商覆盖范围。对于一般企业而言，网络设备和光纤基础设施的规模相对有限，因此自行建设光传输系统所增加的资本开支和运维复杂度往往无法通过节省电路费用得到补偿。&lt;/p&gt;
&lt;p&gt;但是，AI DCI 的经济性具有明显不同的特征。&lt;/p&gt;
&lt;p&gt;假设客户需要长期维持一条高容量 DCI，传统电路模式的总拥有成本可以近似表示为：&lt;/p&gt;
&lt;p&gt;电路 TCO = 带宽单价 × 带宽 × 租期 + 初装成本 + 其他服务成本&lt;/p&gt;
&lt;p&gt;而暗光纤模式则可以近似表示为：&lt;/p&gt;
&lt;p&gt;暗光纤 TCO = 光纤租金 + DWDM/相干光设备 + 光模块 + 机房及配套 + 运维成本 + 冗余成本 + 设备折旧&lt;/p&gt;
&lt;p&gt;当 &lt;strong&gt;暗光纤 TCO &amp;lt; 电路 TCO&lt;/strong&gt; ，并且这种成本优势能够持续覆盖客户承担的技术风险和资本成本时，客户才具有从电路转向暗光纤的经济动力。&lt;/p&gt;
&lt;p&gt;因此，决定产品选择的并不是&amp;quot;AI&amp;quot;这个标签本身，而是几个更加具体的变量：长期带宽规模、线路距离、容量利用率、租期、设备成本、线路冗余要求、运维能力以及资本成本。&lt;/p&gt;
&lt;p&gt;2026 年 ACG Research 对 AI DCI 光传输方案进行的 TCO 分析正是沿着这一逻辑展开。该研究比较了 Wavelength、Dark Fiber 和 MOFN 三种模式，认为较低带宽水平下 Wavelength 的 TCO 更具优势，而在多 Tbps 规模下，MOFN 和 Dark Fiber 的经济性开始增强；具体选择则受到带宽、距离、运营能力和增长需求等因素共同影响。&lt;/p&gt;
&lt;p&gt;这意味着不存在一个适用于所有客户的&amp;quot;暗光纤拐点&amp;quot;。对于一条较短距离、长期高利用率的超大容量 DCI，客户自行建设光传输系统可能很快形成成本优势；对于距离较长、利用率较低或者需求存在较大不确定性的线路，即使带宽较高，运营商提供的托管服务仍可能具有更好的 TCO。&lt;/p&gt;
&lt;p&gt;因此，所谓&amp;quot;AI 时代从电路转向光纤&amp;quot;，准确地说应该是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;当客户的长期容量需求、利用率和持续时间使底层基础设施的固定成本能够被充分摊薄时，网络控制权开始具有独立的经济价值。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这也是本文最重要的经济学基础。&lt;/p&gt;
&lt;h2 id="技术推手模块化波分加速拐点到来"&gt;技术推手：模块化波分加速拐点到来
&lt;/h2&gt;&lt;p&gt;传统的 DWDM（密集波分复用）系统通常是高度封闭、一体化的黑盒系统。电信运营商与企业客户必须绑定单一厂商的“WDM + OTN + 统一网管”。这种封闭体系不仅设备 CapEx 高昂、机房占用大、功耗高，且扩容与软件定义能力极差。如果客户在传统架构下尝试自建光网络或选择暗光纤模式，必须配备极其专业且庞大的光通信运维团队，成本与技术门槛极高。&lt;/p&gt;
&lt;p&gt;然而， &lt;strong&gt;模块化波分（Compact Modular Boxes）&lt;/strong&gt; 的成熟，彻底打破了这一壁垒：&lt;/p&gt;
&lt;h3 id="1-软硬件解耦与开放光线路系统ools"&gt;1. 软硬件解耦与开放光线路系统（OOLS）
&lt;/h3&gt;&lt;p&gt;解耦架构将“物理光缆+放大器/复用器（光层）”与“终端相干光模块/业务板卡（电层）”剥离。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;业务层（Transponder）&lt;/strong&gt; ：超大规模 AI 客户或云厂商可以直接在自研路由器/交换机上插拔标准的 &lt;strong&gt;800G/1.6T ZR+ 相干光模块&lt;/strong&gt; ，或者采购第三方白盒转接设备。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;线路层（Line System）&lt;/strong&gt; ：仅需租用运营商的物理光纤或点对点 OOLS 线路。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;商业意义&lt;/strong&gt; ：客户不再需要为了升级带宽而整体更换昂贵的传统 DWDM 传输子架，从而 &lt;strong&gt;大幅降低了暗光纤模式下的 DWDM 设备 CapEx 与后续折旧成本&lt;/strong&gt; 。&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="2自研波分--纤芯打包运营商提效防管道化的杀手锏"&gt;2.“自研波分 + 纤芯打包”：运营商提效防管道化的杀手锏
&lt;/h3&gt;&lt;p&gt;三大运营商当前在自研模块化波分/开放光传输设备上已具备成熟的技术沉淀（如自主定义的 Open-OTN 架构、DCI 盒式白盒设备与管控 API）。将“自研模块化波分硬件”与“暗光纤/专有光路”打包销售给 AI 客户，带来了三重商业赋能：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;对客户：免去了向异构设备商采购昂贵传输子架的 CapEx，实现“开箱即用”；同时获得对外开放的自研 API（如 RESTconf/OpenCONFIG），可灵活进行光层监控与自配自调。&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;对运营商：摆脱了传统暗光纤出租“卖哑管道、低毛利”的困局，通过硬件销售/租赁+光路托管软件服务（SaaS/PaaS）提升了产品附加值，锁定了客户的生命周期价值（LTV）。&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;对生态：将原本黑盒的 DWDM 简化为标准化“网络基础设施积木”，降低了多 Tbps 规模下 DCI 基础设施的部署门槛。&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="3-模块化波分compact-modular降低运维与空间门槛"&gt;3. 模块化波分（Compact Modular）降低运维与空间门槛
&lt;/h3&gt;&lt;p&gt;面向数据中心场景设计的模块化波分设备（如 1U/2U 盒式 DCI 设备）具备高密度、低功耗、标准 API（如 OpenCONFIG、NETCONF/YANG）以及“即插即用”的特点。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;传统的波分系统需要复杂的人工光路调试与调纤，而模块化波分支持全自动的光层自适应调整与端到端可视化。&lt;/li&gt;
&lt;li&gt;这使得 AI 企业的软件工程师能够像管理 IP 路由器或服务器一样，通过软件代码（NetOps/DevOps）直接调度光层波长与参数， &lt;strong&gt;极大降低了客户接管光网络控制权所需的运维成本（OpEx）&lt;/strong&gt; 。&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="4-对-dci-经济性拐点的直接影响"&gt;4. 对 DCI 经济性拐点的直接影响
&lt;/h3&gt;&lt;p&gt;DWDM 解耦与模块化波分直接改变了暗光纤与托管网络（MOFN）的 TCO 计算公式：&lt;/p&gt;
&lt;p&gt;由于设备资本开支（CapEx）与专业光网络运维门槛（OpEx）的双重下降， &lt;strong&gt;的交叉点（拐点）被大幅左移&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;传统的 DCI 经济性拐点：&lt;/p&gt;
&lt;p&gt;100G/400G 级 &amp;mdash;&amp;mdash;&amp;mdash;&amp;mdash;&amp;mdash;&amp;mdash;&amp;ndash;&amp;gt; 多 Tbps 级 (拐点) &amp;mdash;&amp;gt; 客户转向暗光纤&lt;/p&gt;
&lt;p&gt;设备解耦与模块化波分普及后：
100G/400G 级 &amp;mdash;-&amp;gt; 800G/1.6T 级 (拐点提前) &amp;mdash;&amp;mdash;&amp;mdash;&amp;mdash;&amp;mdash;&amp;ndash;&amp;gt; 客户转向暗光纤/MOFN&lt;/p&gt;
&lt;p&gt;这解释了为什么超大规模 AI 客户不仅“想”要底层网络控制权，而且“能够”以极高的 ROI（投资回报率）接管光层。模块化波分使“控制权开放”从一种理论上的商业假设，变成了技术上高可行、经济上极具吸引力的现实选择。&lt;/p&gt;
&lt;h2 id="为什么-sla-保障服务不够"&gt;为什么 SLA 保障服务不够？
&lt;/h2&gt;&lt;p&gt;一个不可避免的反驳是：如果运营商提供严格的 SLA 保障服务（如 99.999% 可用性、低时延、快速故障恢复），客户还有必要自建光网络吗？&lt;/p&gt;
&lt;p&gt;对于大多数客户而言，运营商的 SLA 保障服务确实能够满足需求。但对于部分超大规模客户，即使运营商提供严格的 SLA 保障，其长期 TCO 仍可能高于自建光网络。此时， &lt;strong&gt;网络控制权本身的经济价值开始显现&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;具体而言，超大规模客户自建光网络的额外收益包括：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;自定义调制格式和 FEC&lt;/strong&gt; ：根据训练任务特点优化光层参数；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;快速扩容&lt;/strong&gt; ：无需等待运营商审批，自行增加波长或升级设备；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;光层可观测性&lt;/strong&gt; ：实时监控光层性能，快速定位故障；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;路由灵活性&lt;/strong&gt; ：根据计算拓扑优化光路选择。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;而额外成本包括：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;DWDM 设备投资&lt;/strong&gt; ：一次性资本开支；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;运维团队建设&lt;/strong&gt; ：需要专业光网络工程师；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;故障处理责任&lt;/strong&gt; ：需要自行承担光层故障修复。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;当客户规模足够大、长期容量需求足够高时，自建光网络的额外收益可能超过额外成本，此时网络控制权开始具有独立的经济价值。&lt;/p&gt;
&lt;p&gt;因此， &lt;strong&gt;SLA 保障服务与自建光网络并非简单的替代关系，而是适用于不同客户规模和经济性的两种模式&lt;/strong&gt; 。&lt;/p&gt;
&lt;h2 id="网络控制权分层产品体系"&gt;网络控制权分层产品体系
&lt;/h2&gt;&lt;p&gt;如果将网络控制权作为商业产品，可以构建一个从服务控制到基础设施控制逐步下沉的产品体系。&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;层级&lt;/th&gt;
&lt;th&gt;产品&lt;/th&gt;
&lt;th&gt;客户控制程度&lt;/th&gt;
&lt;th&gt;典型客户&lt;/th&gt;
&lt;th&gt;商业逻辑&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;L1&lt;/td&gt;
&lt;td&gt;电路/OTN 专线&lt;/td&gt;
&lt;td&gt;低&lt;/td&gt;
&lt;td&gt;普通企业&lt;/td&gt;
&lt;td&gt;购买封装后的网络服务&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L2&lt;/td&gt;
&lt;td&gt;波长服务&lt;/td&gt;
&lt;td&gt;较低&lt;/td&gt;
&lt;td&gt;中型云/AI 客户&lt;/td&gt;
&lt;td&gt;购买独立波长容量&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L3&lt;/td&gt;
&lt;td&gt;自研波分 + 纤芯打包/托管光网络（MOFN）&lt;/td&gt;
&lt;td&gt;中高&lt;/td&gt;
&lt;td&gt;大型 /大中型AI 客户&lt;/td&gt;
&lt;td&gt;租/购运营商自研波分（DCI-BOX/极简OTN）+纤芯，获得开放 API 控制权，运维双方分担/获得专用光网络能力，同时减少运维负担&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L4&lt;/td&gt;
&lt;td&gt;暗光纤&lt;/td&gt;
&lt;td&gt;高&lt;/td&gt;
&lt;td&gt;超大 AI 客户&lt;/td&gt;
&lt;td&gt;客户自行建设光传输系统&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L5&lt;/td&gt;
&lt;td&gt;IRU/私有光网络&lt;/td&gt;
&lt;td&gt;很高&lt;/td&gt;
&lt;td&gt;超大规模云厂商&lt;/td&gt;
&lt;td&gt;长期锁定物理网络资源&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L6&lt;/td&gt;
&lt;td&gt;联合建设/锚定客户&lt;/td&gt;
&lt;td&gt;共同参与&lt;/td&gt;
&lt;td&gt;超大 AI 基础设施客户&lt;/td&gt;
&lt;td&gt;以长期需求支撑新增网络投资&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;&lt;strong&gt;第一层仍然是传统电路/OTN 专线&lt;/strong&gt; 。客户购买的是封装后的网络容量和 SLA，运营商承担全部网络建设、设备配置和运维责任。这一模式最适合普通企业以及没有专业网络团队的客户。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第二层是波长服务&lt;/strong&gt; 。运营商仍然负责光网络，但客户获得更加明确的独立波长资源。对于中型云客户和 AI 客户而言，这一模式能够在不增加大量运维负担的情况下提供较高的带宽扩展能力。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第三层是托管光网络（MOFN）&lt;/strong&gt; 。客户开始获得一定的光层控制能力，而运营商继续承担相当部分的光传输运维责任。这一层适合已经具有较强网络能力，但又不希望完全承担光网络建设和运维责任的大型 AI 客户。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;关于自研波分打包模式（L3）的商业定位与实践优势：在实际商业实践中，“自研波分 + 纤芯打包”填补了 L2（波长）与 L4（纯暗光纤）之间的巨大断层：&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;定位优势&lt;/strong&gt; ：相比纯暗光纤（L4），客户无需组建庞大的光传输硬件运维团队，也无需支付异构厂商的高昂设备溢价；相比纯波长（L2），客户获得了基于运营商自研设备开放 API 的“分钟级自动化开通”与“高精细度光层自观测”能力。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;财务灵活性&lt;/strong&gt; ：可灵活采用“硬件一次性销售 + 纤芯月租”或“硬件与纤芯按月全打包（As-a-Service）”模式，极大适应了 AI 创业公司或中型算力集群的财务偏好。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;责任边界清晰&lt;/strong&gt; ：运营商保障物理光纤与自研硬件底座的物理可用性，客户掌控业务调度与波长分配，实现了软硬件解耦下的最佳 SLA 平衡。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;第四层是暗光纤&lt;/strong&gt; 。客户租用物理光纤，自行部署 DWDM 或相干光传输系统。此时运营商的收入主要来自物理基础设施资源，而客户承担设备投资和光层运维责任。L4 与 L5 的区别在于租期和合同性质：暗光纤通常为短期或中期租赁（1-5 年），客户可提前终止；IRU 为长期不可撤销使用权（10-30 年），合同期内不可单方面终止，具有更强的资产属性。在实际商业实践中， &lt;strong&gt;合同期限（如 5 年 vs 15 年）已不再是区分两者的绝对标准&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第五层是 IRU 或私有光网络&lt;/strong&gt; 。客户通过长期不可撤销使用权锁定物理网络资源，网络控制权进一步向客户侧转移。这种模式更加适合长期容量需求确定、网络价值较高的超大规模云厂商或超大规模 AI 基础设施客户。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;第六层则是联合建设或锚定客户建设&lt;/strong&gt; 。客户的长期容量需求成为网络建设的投资依据，运营商负责建设和运营网络，客户通过长期承诺获得容量保障，同时运营商可以利用剩余资源服务其他客户。&lt;/p&gt;
&lt;p&gt;由此可以形成如下关系：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;控制权越高，客户承担的 CapEx 和运维责任越大；控制权越低，运营商承担的基础设施成本越高，但可以获得持续性的网络服务收入。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;因此，网络控制权本身实际上可以成为一种定价变量。&lt;/p&gt;
&lt;h2 id="国际市场已经出现不同层级的商业实践"&gt;国际市场已经出现不同层级的商业实践
&lt;/h2&gt;&lt;p&gt;国际市场目前并没有形成&amp;quot;电路最终必然被暗光纤取代&amp;quot;的单一路线，而是正在形成包括 Wavelength、MOFN、Dark Fiber、IRU 以及 Anchor Build 在内的多层次商业实践。&lt;/p&gt;
&lt;p&gt;2026 年 7 月，Verizon 宣布与 Google 达成价值超过 10 亿美元的多年期协议，为 Google 数据中心提供 Dark Fiber 连接。Reuters 报道称，Verizon CEO Dan Schulman 在公司业绩发布相关会议中表示，公司正在看到更多类似机会，并预计未来可能形成数十亿美元规模的相关业务。&lt;/p&gt;
&lt;p&gt;这一案例的价值不在于合同金额本身，而在于运营商向超大规模客户开放了比传统电路更底层的物理网络资源。对于具有强大网络技术能力的 Hyperscaler 而言，Dark Fiber 允许其自行决定光传输设备和容量演进方式，从而将网络控制边界从运营商提供的&amp;quot;电路层&amp;quot;进一步下移到光层。&lt;/p&gt;
&lt;p&gt;Verizon—Google 因而代表了一种典型的 &lt;strong&gt;Dark Fiber + 客户光层控制&lt;/strong&gt; 模式。&lt;/p&gt;
&lt;p&gt;与此同时，Zayo 的实践进一步体现了网络基础设施商业模式的变化。2026 年 4 月，Zayo 宣布已经获得一个 Anchor Customer，并据此推动超过 8,000 route miles 的新建和 Overbuild 网络。Zayo 当时明确表示，这些线路将由其建设、拥有和运营，而锚定客户的长期承诺为基础设施投资提供了需求支撑。&lt;/p&gt;
&lt;p&gt;2026 年 8 月 6 日，Zayo 进一步宣布与 NVIDIA 合作建设超过 8,000 英里的新长途光纤，并扩展现有网络容量。Zayo 同时表示，其过去 18 个月已经推动超过 15,000 route miles 的 AI 相关建设和扩容。8 月 20 日，Zayo 又宣布扩大与 Corning 的长期光纤供应协议，以支持到 2030 年增加约 15,000 route miles 的网络建设计划，其中超过 8,000 英里的新长途光纤与 NVIDIA 的合作直接相关。&lt;/p&gt;
&lt;p&gt;Zayo 的案例与 Dark Fiber 存在明显区别。Dark Fiber 主要解决的是&amp;quot;客户是否应该控制已有物理资源&amp;quot;的问题，而 Anchor Build 解决的是&amp;quot;当客户需求足够大时，谁来承担新增网络建设投资&amp;quot;的问题。&lt;/p&gt;
&lt;p&gt;其商业逻辑可以概括为：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;客户长期需求锁定 → 运营商获得投资确定性 → 运营商建设并拥有网络 → 客户获得长期容量保障 → 剩余资源继续服务其他客户。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;因此，AI 客户不一定需要成为光纤资产所有者，也可以通过成为锚定客户影响运营商的网络建设方向。&lt;/p&gt;
&lt;p&gt;香港电讯则代表了第三种路径。2026 年 7 月，HKT 宣布计划推出 3.2Tbps AI Data Centre Inter-connect Superhighway，用于连接香港多个数据中心，使 AI 基础设施提供商、大学和科研机构能够共享分布式计算资源。HKT 表示，该服务针对 AI 训练和推理等下一代工作负载，并采用面向 AI 的网络技术。&lt;/p&gt;
&lt;p&gt;HKT 的模式并不是向客户出售 Dark Fiber，而是由运营商继续承担网络建设和运维责任，通过高容量光网络、低时延能力以及面向 AI 的网络技术，把复杂的底层基础设施重新封装成高等级 DCI 服务。&lt;/p&gt;
&lt;p&gt;因此，HKT 所代表的并不是&amp;quot;客户控制权下沉&amp;quot;，而是另一种竞争策略：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;如果客户愿意为高性能、低运维负担的网络服务付费，运营商仍然可以通过技术升级维持网络控制权，并提高托管网络的价值。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;在 Verizon—Google、Zayo—NVIDIA 和 HKT 三个案例之外，MOFN 则构成了传统波长与 Dark Fiber 之间的重要中间层。2026 年 ACG Research 对 Wavelength、MOFN 和 Dark Fiber 的 TCO 分析显示，低带宽水平下 Wavelength 具有成本优势，而随着带宽进入多 Tbps 规模，MOFN 和 Dark Fiber 的经济性逐渐增强。&lt;/p&gt;
&lt;p&gt;MOFN 的价值恰恰在于把&amp;quot;网络控制权&amp;quot;和&amp;quot;运维责任&amp;quot;拆分开来。客户可以获得专用光网络所带来的容量、隔离和一定程度的灵活性，但不需要承担完整 Dark Fiber 模式下的光传输设备建设和运维责任。&lt;/p&gt;
&lt;p&gt;因此，国际市场实际上已经出现一个连续的商业体系：&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;产品形态&lt;/th&gt;
&lt;th&gt;客户控制程度&lt;/th&gt;
&lt;th&gt;典型经济逻辑&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Circuit / OTN&lt;/td&gt;
&lt;td&gt;低&lt;/td&gt;
&lt;td&gt;购买封装后的网络服务&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Wavelength&lt;/td&gt;
&lt;td&gt;较低&lt;/td&gt;
&lt;td&gt;购买独立波长容量&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;模块化波分+光纤/MOFN / Managed Optical&lt;/td&gt;
&lt;td&gt;中等&lt;/td&gt;
&lt;td&gt;获得专用光网络能力，同时减少运维负担&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Dark Fiber&lt;/td&gt;
&lt;td&gt;高&lt;/td&gt;
&lt;td&gt;客户自行建设光传输系统&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;IRU / Private Optical Network&lt;/td&gt;
&lt;td&gt;很高&lt;/td&gt;
&lt;td&gt;长期锁定物理网络资源&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Anchor Build / Joint Build&lt;/td&gt;
&lt;td&gt;共同参与&lt;/td&gt;
&lt;td&gt;以长期需求支撑新增网络投资&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;因此，国际市场真正出现的变化并不是&amp;quot;Dark Fiber 取代 Circuit&amp;quot;，而是网络控制权正在形成连续谱，并逐渐成为可以被单独定价的商业资源。&lt;/p&gt;
&lt;h2 id="中国三大运营商所处的阶段网络资源仍然高度封装"&gt;中国三大运营商所处的阶段：网络资源仍然高度封装
&lt;/h2&gt;&lt;p&gt;与美国等市场相比，中国基础电信运营商拥有更加庞大的光纤、管道、机房和传送网络基础设施，同时也拥有大量政企客户、云客户和移动用户。因此，中国运营商并不存在网络资源不足的问题，其核心问题更多是如何将庞大的基础设施资产转化为适应 AI 时代需求的新型商业模式。&lt;/p&gt;
&lt;p&gt;尽管光纤出租是运营商一项常规业务，但运营商从商业本能出发， &lt;strong&gt;更倾向于通过租用电路、专线等“主动服务”来获取更高利润、维持客户关系并避免自身被“管道化”&lt;/strong&gt; 。目前，中国运营商仍然主要通过 OTN、专线、SD-WAN、算力网络和全光网络等方式向客户提供网络服务。也就是说，底层光纤和光传输能力仍然高度封装在运营商自己的网络体系之中。&lt;/p&gt;
&lt;p&gt;这种模式在过去具有充分合理性。运营商承担网络建设和运维成本，同时通过专线、带宽升级和网络增值服务持续回收投资。客户则避免了自行建设光传输系统的资本开支和运维复杂性。&lt;/p&gt;
&lt;p&gt;但是，AI 的发展可能改变这种平衡。&lt;/p&gt;
&lt;p&gt;随着单个 AI 客户的 DCI 容量从数百 Gbps 向 Tbps 甚至更高水平发展，客户对网络的长期支付能力和对底层网络资源的控制需求都可能提高。对于部分超大客户而言，运营商继续按照传统带宽方式销售网络，可能使双方都无法获得最优的经济结果。&lt;/p&gt;
&lt;p&gt;运营商需要面对的因此不是&amp;quot;是否出租光纤&amp;quot;这一单一问题，而是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;哪些客户已经跨过 TCO 拐点？哪些客户仍然适合购买托管网络？哪些客户应该获得更底层的物理资源控制权？&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这实际上要求运营商从过去以产品为中心的销售方式，转向以客户 TCO 为中心的产品设计方式。&lt;/p&gt;
&lt;h2 id="运营商的博弈处境为什么必须开放控制权"&gt;运营商的博弈处境：为什么必须开放控制权？
&lt;/h2&gt;&lt;p&gt;一个关键问题是：卖电路通常比租光纤更赚钱，运营商为何要主动开放导致自身收入摊薄的产品？&lt;/p&gt;
&lt;p&gt;答案在于 &lt;strong&gt;客户自建光缆的外部选择&lt;/strong&gt; 和 &lt;strong&gt;同业竞争压力&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;如果运营商坚持将所有网络资源封装成电路，而客户已经跨过 TCO 拐点，那么客户可能选择：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;自建光缆&lt;/strong&gt; ：超大规模客户（如 Meta、Google 等）已有自建长距离光缆的实践；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;第三方光纤提供商&lt;/strong&gt; ：如 Zayo、Lumen、Crown Castle 等专业光纤基础设施公司；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;其他运营商&lt;/strong&gt; ：如果竞争对手提供更底层的光纤资源，客户可能转向竞争对手。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;因此，运营商面临的选择不是&amp;quot;是否放弃电路收入&amp;quot;，而是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;在客户已经跨过 TCO 拐点后，如何避免将长期基础设施价值让渡给客户自建网络？&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;如果客户可以通过自建光缆、第三方光纤提供商或其他运营商获得更底层的资源，那么坚持将所有网络资源封装成电路，反而可能导致长期收入流失。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;这也意味着，光缆租用模式的成功不仅取决于&amp;quot;是否率先推出&amp;quot;，更取决于运营商自身的光缆资源禀赋。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;在电信市场，当某一运营商率先提出光缆租用业务时，其他运营商往往会迅速跟进。但这种&amp;quot;跟随策略&amp;quot;能否成功，取决于以下关键因素：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;1. 光缆资源的数量和质量&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;如果运营商拥有更丰富的骨干光缆、城域光缆和本地接入光缆资源，特别是覆盖重要 AI 数据中心集群、算力枢纽节点的光缆路由，那么即使竞争对手后来跟进，客户在比较可用纤芯数量、路由多样性、物理隔离程度后，仍可能选择该运营商；&lt;/li&gt;
&lt;li&gt;反之，如果运营商的光缆资源并不占优，即使率先推出光缆租用业务，客户在比较后仍可能选择资源更丰富的竞争对手，或者转向第三方光纤提供商。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;2. 响应速度和交付能力&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;光缆租用业务对运营商的响应速度提出了更高要求。客户可能需要快速勘查路由、确认纤芯可用性、完成光纤跳接等；&lt;/li&gt;
&lt;li&gt;如果运营商的资源管理系统（如 GIS 系统、纤芯资源管理系统）不够完善，导致响应速度慢、交付周期长，即使率先推出业务，也可能在客户体验上落后于竞争对手。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;3. 维护质量和故障处理能力&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;光缆租用模式下，运营商仍需负责物理光纤的维护（如光缆故障修复、路由保护等）；&lt;/li&gt;
&lt;li&gt;如果运营商的维护团队响应慢、故障修复时间长、路由保护能力弱，客户即使选择了光缆租用，也可能在后续使用中体验不佳，转而选择其他运营商或自建光缆。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;4. 网络覆盖的地理优势&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;对于 AI 数据中心而言，光缆的价值不仅在于&amp;quot;有没有&amp;quot;，更在于&amp;quot;在哪里&amp;quot;；&lt;/li&gt;
&lt;li&gt;如果运营商的光缆经过重要 AI 数据中心集群、算力枢纽节点、电力充裕区域，那么其光缆资源的战略价值会显著提升；&lt;/li&gt;
&lt;li&gt;反之，如果光缆路由远离 AI 数据中心集中区域，即使价格便宜，客户也可能因为需要额外建设&amp;quot;最后一公里&amp;quot;而放弃选择。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;因此，运营商在决定是否推出光缆租用业务时，需要首先评估自身的光缆资源禀赋：&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;如果自身光缆资源在数量、质量、覆盖范围上具有明显优势，那么率先推出光缆租用业务可能形成&amp;quot;先发优势 + 资源优势&amp;quot;的双重壁垒；&lt;/li&gt;
&lt;li&gt;如果自身光缆资源并不占优，那么盲目跟进可能导致&amp;quot;起个大早，干个晚集&amp;quot;——率先推出业务，但客户在比较后仍选择竞争对手。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;这也意味着，光缆租用模式可能加速运营商之间的分化：&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;光缆资源丰富的运营商（如拥有&amp;quot;新八纵八横&amp;quot;骨干网、城域光缆覆盖广、接入能力强的运营商）可能通过光缆租用业务进一步巩固市场地位；&lt;/li&gt;
&lt;li&gt;光缆资源相对薄弱的运营商可能面临两难选择：不推出光缆租用可能流失超大客户，推出后可能因资源劣势而难以形成竞争力。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;对于中国运营商而言，这一竞争动态尤为重要。三大运营商均拥有庞大的光缆网络，但在具体区域、具体路由上的资源禀赋可能存在差异。未来，运营商可能需要：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;首先盘点自身的光缆资源禀赋，识别具有竞争优势的路由和区域；&lt;/li&gt;
&lt;li&gt;在资源占优的区域率先推出光缆租用业务，形成局部优势；&lt;/li&gt;
&lt;li&gt;在资源不占优的区域，谨慎评估是否跟进，避免&amp;quot;起个大早，干个晚集&amp;quot;。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;对于弱势运营商，在光纤租用领域的最大困境并非创新不足，而是同质化竞争下的护城河缺失。&lt;/p&gt;
&lt;p&gt;由于干线光缆通过共建共享实现了高度同质化，物理网络资源本身难以构成壁垒。弱势运营商若率先推出创新的商业模式，极易被拥有更强规模优势和政企关系的强势跟随者快速模仿，并可能通过价格战或捆绑策略实现“后发先至”式的反噬。因此，弱势运营商不缺创新的点子，缺的是 &lt;strong&gt;将创新根植于自身不可复制的资源禀赋之中&lt;/strong&gt; 。弱势运营商应放弃纯纤芯价格战，转向“自研模块化波分（DCI-BOX/极简OTN）+ 纤芯 + 算力 + 安全”深度捆绑方案。通过提供贴合 AI 客户需求的标准化盒式设备与开放 API 服务，将安全增值与自研开放设备融合，向“智能基础设施资产运营商”演进。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;真正的护城河不在于“租光纤”这一动作本身，而在于“光纤+算力+安全”的深度捆绑能力。&lt;/strong&gt; 弱势运营商可以效仿Zayo与NVIDIA的“锚定客户”模式，为头部AI客户提供定制化的“光纤+算力”一体化方案，而非简单的纤芯出租。可以考虑将“安全”等其他增值服务作为核心卖点嵌入光纤服务，提供对手难以在短期内复制的增值体验。此外，还可探索与行业外企业合作获取优势路由，以较低成本扩充资源池，构建差异化的网络覆盖。弱势运营商而应致力于成为“智能基础设施资产运营商”。 唯有将光纤资源与算力、安全、定制化服务等能力融合，提供高价值的整体解决方案，才能在同质化的竞争中，真正构筑起一道让对手难以逾越的护城河。&lt;/p&gt;
&lt;h2 id="监管边界网络控制权开放的约束条件"&gt;监管边界：网络控制权开放的约束条件
&lt;/h2&gt;&lt;p&gt;在中国市场，网络控制权向客户开放还需要考虑电信业务、网络安全、数据安全以及跨境数据等监管要求。&lt;/p&gt;
&lt;p&gt;需要特别区分的是，AI 企业租用暗光纤并自行部署 DWDM，本身并不当然构成电信业务经营行为。是否涉及电信业务经营许可，关键仍在于实际业务模式以及是否利用相关网络向第三方提供属于电信业务范畴的服务。因此，不能简单地因为企业&amp;quot;拥有光纤&amp;quot;或者&amp;quot;自行建设 DCI&amp;quot;就认定其需要取得 IDC 或 ISP 许可证。&lt;/p&gt;
&lt;p&gt;如果 AI 企业仅连接自有数据中心，网络主要用于自身业务，并不向公众或者第三方提供电信连接服务，其法律性质与利用网络开展对外经营性电信业务存在明显区别。&lt;/p&gt;
&lt;p&gt;与此同时，如果相关数据中心或网络设施涉及关键信息基础设施、重要数据处理、数据跨境等场景，则需要根据实际主体、数据类别和业务性质适用相应的网络安全和数据安全监管要求。&lt;/p&gt;
&lt;p&gt;因此，监管因素更适合被视为网络控制权商业模式的 &lt;strong&gt;边界条件&lt;/strong&gt; ，而不是决定商业模式经济性的核心变量。&lt;/p&gt;
&lt;p&gt;对于运营商而言，未来如果开放 Dark Fiber、Spectrum 或 Private Optical Network，需要通过合同明确资源使用范围、设备责任、故障责任、网络安全责任和禁止转售等事项，但也应避免把普通的企业自用网络建设简单等同于电信业务经营。&lt;/p&gt;
&lt;h2 id="从网络服务商到网络基础设施资产运营商"&gt;从&amp;quot;网络服务商&amp;quot;到&amp;quot;网络基础设施资产运营商&amp;quot;
&lt;/h2&gt;&lt;p&gt;AI 对运营商最大的影响，并不是使网络价值下降，而是使网络价值的构成发生变化。&lt;/p&gt;
&lt;p&gt;过去，运营商主要通过带宽、专线、OTN 和 IP 网络向客户出售连接服务。网络的价值主要体现在&amp;quot;能够提供多少带宽&amp;quot;和&amp;quot;能够提供什么 SLA&amp;quot;。&lt;/p&gt;
&lt;p&gt;未来，网络价值可能进一步向更加底层的基础设施迁移，包括光纤资源、物理路由、光层资源、机房、电力以及跨数据中心的地理位置关系。&lt;/p&gt;
&lt;p&gt;特别是在 AI 基础设施时代，网络的价值越来越与&amp;quot;在哪里拥有网络&amp;quot;联系在一起。&lt;/p&gt;
&lt;p&gt;一条经过重要 AI 数据中心集群、拥有多条物理路由、具备充足纤芯资源并连接多个电力和算力节点的光纤基础设施，其价值已经不再只是传统意义上的&amp;quot;传输管道&amp;quot;。它实际上成为 AI 基础设施体系的一部分。&lt;/p&gt;
&lt;p&gt;因此，运营商未来可能形成一种新的商业逻辑：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;机房 + 电力 + 光纤 + 路由 + 光传输 + 网络运维 → AI Infrastructure Connectivity（AI 基础设施连接服务）。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;这种产品不再简单出售某一条 100G 或 400G 电路，而是向 AI 数据中心提供一套能够长期支撑算力部署的基础设施连接能力。&lt;/p&gt;
&lt;p&gt;在这一模式下，运营商最大的竞争优势恰恰不是某一项单独技术，而是其同时拥有光纤、管道、机房、电力接入、网络运营和全国性基础设施组织能力。&lt;/p&gt;
&lt;h2 id="结论ai-改变的不是网络需求而是网络价值的分配方式"&gt;结论：AI 改变的不是网络需求，而是网络价值的分配方式
&lt;/h2&gt;&lt;p&gt;AI 时代，运营商面对的并不是一个简单的&amp;quot;电路出租还是光纤出租&amp;quot;的二选一问题。&lt;/p&gt;
&lt;p&gt;真正发生变化的是，当 DCI 的容量规模、利用率和持续时间达到一定水平以后，客户开始发现：继续购买运营商封装好的带宽服务，未必是长期 TCO 最优方案。此时，物理光纤、光层、频谱、路由以及长期使用权本身开始具有独立的经济价值。&lt;/p&gt;
&lt;p&gt;国际市场已经出现这一变化的不同表现。Verizon 与 Google 的 Dark Fiber 合作表明，超大规模客户正在直接购买更底层的物理网络资源；Zayo 与 NVIDIA 的合作表明，AI 客户的长期需求甚至可以成为运营商新建网络的投资锚点；HKT 的 3.2Tbps AI DCI Superhighway 则说明，运营商仍然可以通过提高托管网络的技术能力，在不开放底层物理控制权的情况下满足 AI 客户需求。&lt;/p&gt;
&lt;p&gt;因此，未来网络商业模式更可能表现为一种连续演进，而不是简单替代：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Circuit → Wavelength → MOFN → Dark Fiber → IRU / Private Optical Network → Anchor Build。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;其中不存在一个对所有客户都适用的最优模式。真正决定产品选择的是客户的长期容量、线路距离、利用率、租期、资本成本、技术能力和运维能力。&lt;/p&gt;
&lt;p&gt;由此可以形成全文最核心的判断：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;AI 并不会简单地把运营商从&amp;quot;卖带宽&amp;quot;推向&amp;quot;卖光纤&amp;quot;；真正发生的变化，是当 DCI 长期容量需求跨过经济性拐点后，客户开始有动力购买更底层的物理资源和网络控制权。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;三大运营商自研模块化波分（DCI-BOX / 极简 OTN）设备的成熟，为这种控制权转移提供了一种理想的中间态——“设备 + 纤芯”打包模式。它既让客户享受到了接近暗光纤的自主性与低成本，又让运营商保留了硬件与服务价值链。&lt;/p&gt;
&lt;p&gt;对于运营商而言，正确的战略并不是拒绝这种变化，也不是简单地把光纤租出去，而是 &lt;strong&gt;把网络控制权本身产品化、分层化和定价化&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;在这一过程中，运营商的角色并非由&amp;quot;网络服务商&amp;quot;退化为&amp;quot;光纤出租商&amp;quot;，而是进一步向 &lt;strong&gt;网络基础设施资产运营商&lt;/strong&gt; 演进。其核心资产也将从单纯的带宽能力，扩展为光纤、路由、光层、机房、电力以及跨数据中心的基础设施连接能力。&lt;/p&gt;
&lt;p&gt;从这个意义上说，AI 对运营商网络商业模式最深刻的影响，不是让运营商卖更多带宽，也不是简单地让运营商出租更多光纤，而是 &lt;strong&gt;推动网络价值从&amp;quot;服务层&amp;quot;向&amp;quot;基础设施层&amp;quot;重新分配&lt;/strong&gt; 。&lt;/p&gt;
&lt;p&gt;运营商真正需要出售的，最终不是某一个固定的网络产品，而是 &lt;strong&gt;不同等级的网络控制权&lt;/strong&gt; 。&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;strong&gt;中英文对照&lt;/strong&gt;&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;英文&lt;/th&gt;
&lt;th&gt;中文&lt;/th&gt;
&lt;th&gt;说明&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Circuit / OTN&lt;/td&gt;
&lt;td&gt;电路/OTN 专线&lt;/td&gt;
&lt;td&gt;传统封装好的网络服务&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Wavelength&lt;/td&gt;
&lt;td&gt;波长服务&lt;/td&gt;
&lt;td&gt;独立波长资源&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;MOFN / Managed Optical&lt;/td&gt;
&lt;td&gt;托管光网络&lt;/td&gt;
&lt;td&gt;专用光网络 + 运营商托管运维&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Dark Fiber&lt;/td&gt;
&lt;td&gt;暗光纤&lt;/td&gt;
&lt;td&gt;客户租用物理光纤，自行部署设备&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;IRU&lt;/td&gt;
&lt;td&gt;长期不可撤销使用权&lt;/td&gt;
&lt;td&gt;10-20 年长期锁定物理资源&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Private Optical Network&lt;/td&gt;
&lt;td&gt;私有光网络&lt;/td&gt;
&lt;td&gt;客户专属的光网络&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Joint Build / Anchor Build&lt;/td&gt;
&lt;td&gt;联合建设/锚定客户建设&lt;/td&gt;
&lt;td&gt;客户长期需求支撑网络投资&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Hyperscaler&lt;/td&gt;
&lt;td&gt;超大规模云厂商&lt;/td&gt;
&lt;td&gt;AWS、Google、Microsoft、Meta 等&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;hr&gt;
&lt;p&gt;&lt;strong&gt;参考资料&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Reuters, Verizon lifts annual forecasts, signs $1 billion fiber deal with Google, 24 July 2026.&lt;/li&gt;
&lt;li&gt;Zayo, Zayo Secures Anchor Customer to Accelerate Network Expansion Across Critical AI Corridors, 16 April 2026.&lt;/li&gt;
&lt;li&gt;Zayo, Zayo Teams with NVIDIA to Scale Critical Network Capacity for AI Factories, 6 August 2026.&lt;/li&gt;
&lt;li&gt;Zayo, Zayo Stays Ahead of AI Infrastructure Demand Through Long-Term Fiber Supply Agreement with Corning, 20 August 2026.&lt;/li&gt;
&lt;li&gt;HKT, HKT to launch ultra-low latency 3.2Tbps AI Data Centre Inter-connect Superhighway to support Hong Kong&amp;rsquo;s AI development, 17 July 2026.&lt;/li&gt;
&lt;li&gt;ACG Research, Choosing the Right Optical Transport for the AI Era: A TCO-driven decision framework for AI Data Center Interconnect, 12 June 2026.&lt;/li&gt;
&lt;li&gt;Zayo, The 2026 Bandwidth Report.&lt;/li&gt;
&lt;/ul&gt;</description></item><item><title>C-FOL论坛上一个关于MSTP的讨论</title><link>https://blog.fallleaf.net/p/tech-discuss-mstp-cfol/</link><pubDate>Mon, 07 Nov 2005 09:11:59 +0800</pubDate><guid>https://blog.fallleaf.net/p/tech-discuss-mstp-cfol/</guid><description>&lt;p&gt;晚上和同事用IM讨论一个软课题，顺便到[[C-FOL论坛]]上查找资料，ASON的一个“MSTP上提供三层路由的功能有用吗？ “的帖子引起了长达一年的讨 论，开始于2004年1月，目前截至于2005年月。这个帖子的讨论对我帮助很大，今天凑空把讨论的内容整理一下，留做纪念。&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;问题:MSTP上提供三层路由的功能有用吗？&lt;/p&gt;
&lt;p&gt;有的厂家在MSTP上提供三层的处理能力，有的厂家说没有需要，有的厂家在开发，大家讨论讨论，在MSTP上如果提供路由功能，可以带来什么好处呢？&lt;/p&gt;
&lt;p&gt;fol:&lt;/p&gt;
&lt;p&gt;目前我的理解，没有太多好处，反而使网络层次复杂了。这是厂家的一个热点&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;我提出这个问题来，其实自己的心中早就有了答案：那就是，随着MSTP技术的不断完善，MSTP不光会提供三层路由功能，其实更多的数据处理功能会不断的引入到MSTP上的。毕竟SDH的在那摆着，数据业务发展迅猛，MSTP一定会不断适应市场的需要，满足市场的需要的。 适者生存啊。&lt;/p&gt;
&lt;p&gt;yxy791106：&lt;/p&gt;
&lt;p&gt;好久没来灌水了，实在忙的慌～&lt;/p&gt;
&lt;p&gt;首先要对MSTP做一个定义，中国的MSTP是基于SDH的，如果把SDH作为主流技术使用，任何在MSTP上叠加的其他技术都是不可能完善的。L3是肯 定的，因为ONS15454就已经在试验了，但是如果把一个多层交换机完完全全摆上去，路由条目该做多少？用NPU还是ASIC？AAA作不作？牵涉的问 题一大堆了。&lt;/p&gt;
&lt;p&gt;从目前来看，MSTP应该继续进化，变成所谓的ISN。即Intergrate Service Node，综合服务节点，对基于SDH主流的MSTP做完全的改进，形成一个新的系统模型，完成G.709上完全的PACKET OVER FIBER。在未来的网络种，叠加传输和数据是不现实的，只有在容量上分层，技术上不可能分割。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;MSTP应用之一：以太网点到点的透明传送 SDH设备原来纯粹是用来传送TDM业务的。直到几年前，1999年左右开始有厂家把以太网的业务放到SDH的设备上去传送。这时候的SDH设备只是在物 理层上面对以太网业务做处理，起到以太网桥的作用。在以太网数据的源点，SDH设备把以太网的数据帧映射到VC里，然后在整个SDH网络上传送，在以太网 数据的目的点，SDH设备把VC里的以太网数据解出来，通过以太网的支路接口把以太网送出去。 因为这种方法比较简单，以太网的传送和普通话音业务没有什么区别，还是电路模式，所以传输部门的运维人员不需要太多的培训就可以理解，并能很快的开业务了。 这个阶段的SDH设备基本是把10M业务放到一个VC或多个的VC里进行传送的。封装的方式是八仙过海，各显神通。厂家和厂家之间以太网板卡完全无法互连 互通。直到出现了GFP，在实际测试时才有了互连互通的实例。（我个人认为，也就是在这种应用上，GFP还算是有用的。） 在点到点的传送工程中，有两种特例，值得一提。 一种是点到多点的应用， 由于话务矩阵在许多小的接入环上往往是一个中心点A，多个接入点B,C,D…，BCD等只有和A通信的交叉连接，而BCD等点之间的通信基本没有。针 对这种集中式的业务模式，有的公司开发出了一种特别的以太网板卡，用于中心节点。这个中心节点的以太网板卡可以实现点到多点的以太网终结，号称点到多点的 方向可以有16个节点之多，刚好和MSSPRING的SDH节点数量保持一致。这个中心板卡把多个BCD等点送来以太网的业务汇聚到一个以太网接口送出。 这种应用特别普遍，SDH的运维人员也好理解。我无法确认的是，这种板卡是否支持真正的L2交换的功能，很可能只是简单的电路复用/解复用。如果是真正的 L2交换的话，我觉得似乎是不用强调自己的多方向性。 一种是IP层的映射和封装 由于以太网业务里主要是IP的应用比较多，所以有的厂家干脆就提供一种额外的封装方式。这种方式的应用是这样的：在SDH网络的两端A/B，A节点上接以 太网端口，B节点上接路由器的POS接口。在B节点上，SDH设备不用做任何特别的处理，直接把POS接口来的数据业务（这些业务是封装在VC里的）放到 相应的STM-N的VC上，然后传送到A节点。A节点上，SDH设备需要做两个工作。一个工作是将从接入口来的以太网数据帧拆开，取出IP包，将IP包放 （封装，映射）到VC上传送到B点。一个工作是将从B节点来的IP包从VC中取出，然后打上以太网二层的封装，从以太网支路接口送出去。 这种方法针对IP的应用，传输时不用传送L2的开销，传输的效率比较高。针对数据应用非常方便，也绕开了SDH设备在数据上互连互通的问题。不过我好像没有听说哪里有这样的应用。&lt;/p&gt;
&lt;p&gt;tianzd：&lt;/p&gt;
&lt;p&gt;反向思维：MSTP是近两年厂家、专家炒作的热点，对新兴运营商新建数据类网络是十分有利，但对传统运营商存在很多问题，传送层面从道理上应是开放的， MSTP设备结构中ＳＤH核心部分（光、交叉）都没有实质性变化，只是各种不同的业务叠加在SDH上，变化仅在低端接口，各厂家相关协议、接口又不统一， 所以MSTP只是让人感觉不错，能支持各种业务需求，但真正在网络组网应用时觉得存在这样那样的不便。再加上目前厂家主要以透传版本为主，设备价格居高不 下，原有网络投资如何才能得到保护？目前光纤比麻绳便宜，传统SDH设备价格继续走低，只要有管线资源，带宽浪费点又有多大关系？MSTP要大量应用，个 人认为一是价格，二是标准化问题。目前MSTP上提供路由功能只是厂家的试验田，没多大意义。&lt;/p&gt;
&lt;p&gt;yxy791106：&lt;/p&gt;
&lt;p&gt;第二种特例中对L2的处理欠妥，MAC直接映射完全能做到，不必非要拆到L3。 所谓“传输时不用传送L2的开销”，纯属扯淡。没有任何一种技术能够脱离开OSI七层协议～ 综合看来，tianzd的话很有道理，基本赞同。但对于最后一句觉得值得商榷，“没有多大意义”很难讲，至少我认为，这代表了ISN的发展方向。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;首先澄清yxy791106的指出的一个错误， 我指的“传输时不用传送L2的开销”，有问题，应该是更正为：传输时，省略了MAC的源地址/目的地址，以及相应的一些以太网的L2开销。&lt;/p&gt;
&lt;p&gt;因为原来的点到点封装是IP－－》以太网帧－－》ppp－－》VC，现在的变成了IP–&amp;gt;ppp–&amp;gt;VC&lt;/p&gt;
&lt;p&gt;to tianzd：你这样想法，在搞传输的人中间十分有代表性，我原来也是这样想的。呵呵，不过希望你看完我的长篇小论后，会有一些改变。如果你能自己看看数 据 网络方面的书，估计会给我上上课呢。MSTP的物理层处理，即对SDH信号的处理肯定是100年不动摇的，但数据处理能力，如果不能做到与时俱进的话， MSTP就不叫MSTP了，那该叫SDH。&lt;/p&gt;
&lt;p&gt;yxy791106：&lt;/p&gt;
&lt;p&gt;IP–&amp;gt;ppp–&amp;gt;VC中间少了HDLC啊，HDLC是L2的，它带开销的。呵呵，估计想完全避开做不到。&lt;/p&gt;
&lt;p&gt;ASON的想法挺有意思的，当年我在CISCO培训的时候，老师的一句话给我留下至深的印象：未来的世界是IP的。这句话现在听起来或许很普通，但是当时在我这么一个刚出茅庐的学生而言，给我留下了不可磨灭的印象。&lt;/p&gt;
&lt;p&gt;现在虽然从事传输的工作，但始终没有忘记老师的话，什么东西都想往数据上靠，呵呵，结果在众传输人的口水中，我撑伞奋勇向前。&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;是啊，要在传输人的思想中灌进一点data的水，可不容易啊。&lt;/p&gt;
&lt;p&gt;bigtaildog：&lt;/p&gt;
&lt;p&gt;SON谈到的是 MSTP和数据层面的融合，MSTP和 WDM的融合，你是怎样看的呢? 如果以后，城域网都是DWDM,是不是G.709的OTN信号格式处理更加好些呢。 燕子所谈到的ISN概念，说的应是设备对多层协议融合的概念? 印象中看过Bellcore公司的一个ppt, 谈到现在的网络设备，大部分比较分离的处在各层之内，如MSPP涵盖了L1/L2层，大部分DWDM算是L1层.一些ATM/FR交换设备算是L2层，还 有路由器涵盖的是L3以上层.它们对未来设备的发展的预测是，未来的设备将体现多个层面的融合，如对应着optical packet node的设备将会出现，涵盖L3到L1层(ISN算不算)，mspp与上层和DWDM更多的融合，IP路由器与WDM的融合等等。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;MSTP的以太网交换功能 当SDH设备的提供以太网接口不再是什么新鲜的事情以后，开始有厂家玩起了新噱头，开吹MSTP，号称多业务传送平台。结果所有的传输设备厂家一起起哄， 都说自己的设备是MSTP。还有所谓新一代的MSTP之说，搞得大家一头的烟。原来信奉ITU-T标准的传输人，视韦大师的SDH著作为圣经的我等，目瞪 口呆了好一阵之后，终于只好跟上潮流，好好琢磨这个数据产品的东东了。 其实所谓的MSTP，或多或少的有以下的特点： 1) 支持以太网接口，包括E,FE,GE 2) 支持ATM接口，主要是155M速率接口，也有34M的，在电信ADSL飞速发展的背景下，这个东东或得了广泛的应用。将来在3G的网络中，数据的应用也会用到ATM接口的。 3) 支持L2的以太网交换 4) 支持一定的流控和QoS处理能力 5) 支持RPR 6) 支持L3路由和交换功能 7) 支持MPLS，或者其他更“数据”的处理功能 个人认为，如果一个SDH设备只是支持以太网业务的透明传送，叫MSTP好像是夸张了一点，怎么都在这上面的功能里选多几项啊。&lt;/p&gt;
&lt;p&gt;fallleaf：&lt;/p&gt;
&lt;p&gt;好热闹呀。我也凑个热闹。 我到觉得之所以强调MSTP，主要看中了他的保护功能。如果在IP层面的保护功能做的好，抛开SDH这层，直接IP–&amp;gt;FIBER上不就行了？&lt;/p&gt;
&lt;p&gt;ASON： 关 于MSTP和DWDM的融合，其实早在多年前，刚刚出现DWDM的时候，许多的SDH厂家提供的集成式DWDM系统，其实就是在SDH设备上改进而成 的。把光接口盘（好不容易用了传输的术语呵呵，现在我都叫光接口卡，光接口板了）换成了彩色光口的，配上无源的合波器、分波器，加上OA，一个融合的 SDH，DWDM平台就诞生了，呵呵。 这些设备在公务的处理方面可能有一些问题（无单独的OSC，或者OSC直接利用STM-N的光盘处理)，加上不够开放的缘故，所以最后电信上的基本都是开放式的DWDM了。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;如 果在城域网中，DWDM和MSTP融合的话，我觉得初步的融合技术上不是太难的事情，例如采用WDM器件和彩色光口的配合，许多厂家现在就可以提供。这 种方式也就是在点到点或链形网络上使用比较合适。如果真的要实现环形组网，让光信号在环上自由（reconfigurable或not reconfigurable）的上下，做成这样的设备，各光信号的功率需要自动，半自动的均衡，可就不那么容易了，关键是设备的价钱贵啊。&lt;/p&gt;
&lt;p&gt;tianzd：&lt;/p&gt;
&lt;p&gt;ASON 就知道你挺新潮，你发的帖子有关内容早就读过，我是最近才有时间来光世纪论坛与各位讨教。一是觉得论坛较闷，二来觉得大家技术上跟潮，于是到处点 点火。MSTP融合了数据和传输，从技术上无可厚非，只是提醒大家技术不能决定一切，运营商更关注投资效益与发展，另一方面目前的MSTP设备技术层面有 太多软肋，不成熟。ASON，不知道你有没有去了解运营商对已建SDH进行MSTP功能升级的情况。我个人认为所有的新技术运营商都跟踪关注，并不放弃应 用，但规模应用它们都很谨慎，尤其是几大运营商都已上市，要对股东负责。事实上，目前传统运营商MSTP的网络应用处于数量少、技术层次低的状态，相当一 部分应用都属于实验性的，所以，说句“目前MSTP上提供路由功能只是厂家的试验田，没多大意义”，只是反映一下目前MSTP在国内传统网络内的尴尬状 态。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;当SDH设备能够透传以太网业务以后，紧接着大家就会发现，哎呀，L2交换的功能好方便 啊，我们需要在透传的基础上把以太网二层交换的功能做到设备里去。 二层交换的原理想必大家都已经清楚了，如果不清楚的话，随便上街买本CCNA的教材读读就明白了，只要搞清楚access port，trunk port， vlan，802.1Q，spanning－tree就够用了（这些个名词的中文翻译，我也搞不好，只好用E文了，唯一知道spanning-tree的 中文名字在数学里叫最小支撑树，现在IT人都叫生成树了，呵呵）。L2交换在MSTP上的实现可以带来以下的一些好处：（未能一一尽录，恳请原谅，排名不 分先后） 1) 统计复用，可以更好地享受高带宽 以太网业务不再需要象电路模式的开通方式，不需要独占传输的带宽。现在，我们只需要利用VC构成的一个以太网的传输管道。这个传输的管道就象总线一样，所 有挂在以太网传输管道上的MSTP节点都可以互相自由的交换以太网数据帧，不需要人工的干预。在这个管道内，带宽是共享的，MSTP节点在需要传送数据的 时候才会去占用带宽，所以带宽的利用率是比较高的。（在此和tianzd讨论一下：只要有管线资源，带宽浪费一点问题有多大？ 有管线资源并不能表明就可以开业务，还需要传输设备吧，传输设备对带宽的利用率越高，相对的设备的费用不就降低了？现在运营商有丰富的传输资源，如果能够把相对富裕的传输资源提供给增长的数据业务，不是很好吗？这时候就需要MSTP啦） 2) 组网更方便 象上面提到的，点到多点的应用，如果中心点有两个点A和A’，BCD等各点需要将以太网业务传到A和A’时，透传的方式实现起来就很难看了。用二层交换的 功能，只要在A，A’，BCD等节点之间开一条VC的通道就轻易实现了。呵呵，而且A和A’点也不需要支持多个方向了，两个方向的WAN就可以把环上其他 的节点都接起来了。 3) 利用spanning－tree带来的保护功能。 有了SDH的50ms保护倒换，还需要L2的保护吗？这个东东又慢，又需要占用带宽和cpu资源。嗯，问题分成两个方面来看，如果SDH设备的带宽充足， 可以对以太网业务实现保护，那L2的以太网根本还没有发觉网络有个中断，SDH的保护都已经完成了。这种情况下，spanning－tree只是起到防止 环路发生的作用。但如果，以太网业务需要自己实现保护的时候，spanning－tree还是有用的。记得曾经某知名公司的技术人员要提出ITU-T的新 建议时，有一个草案就是和spanning－tree有关的。记得好像是说有两个交换机通过两条DWDM链路连接起来，如果中间的一条DWDM链路中断 了，这两个数据设备都无法知道中间链路出了问题（因为和交换机连的端口还是up的），那交换机就无法实现保护了，所以要提出改进建议。其实如果交换机支持 spanning－tree，并且能够正常工作的情况下，即使中间的DWDM链路断了一条，交换机是可以自己实现倒换的。时间长短决定于spanning －tree的协议和定时器。可能几秒到几十秒。&lt;/p&gt;
&lt;p&gt;提出了L2交换的好处，当然L2的坏处也要说说&lt;/p&gt;
&lt;p&gt;事实上，目前传统运营商MSTP的网络应用处于数量少、技术层次低的状态，相当一部分应用都属于实验性的，所以，说句“目前MSTP上提供路由功能只是厂家的试验田，没多大意义” 呵呵，我同意你的前半句话，后面的半句话则有保留意见。 我觉得目前MSTP网络应用少的关键原因不是技术上的，在与数据部门和传输部门的相对独立。现在很明显的是，数据业务的市场在发展，数据部门的人还倾向于 用数据设备组网，和传输部门的接口就是STM-1，如果这种情况持续下去，MSTP始终不会有大的发展。传输部门的人，因为始终没有接触数据设备或者推广 数据业务，对使用和推广数据业务的兴趣自然是不高了。 MSTP上的路由功能确实是试验田，但也可以看出是黄浦军校，是培养传输人学习和应用数据业务的好机会，从这方面说，我觉得意义很大。 如果以后成立了基础网络部，统一放号和开通业务的时候，MSTP就会大有作为了。&lt;/p&gt;
&lt;p&gt;tianzd：&lt;/p&gt;
&lt;p&gt;事实上，目前数据部门与传输部门在业务发展、网络组织上并不是相互独立，在面对客户为中心的今天，运营商各部门对综合业务的解决方案始终是有共同的兴趣。&lt;/p&gt;
&lt;p&gt;fallleaf：&lt;/p&gt;
&lt;p&gt;关键是怎么用MSTP，现在厂家总是炒概念。不如踏踏实实帮助运营商提出一个实实在在的网络方案。 现在的应用不能不让人怀疑MSTP的作用。&lt;/p&gt;
&lt;p&gt;bigtaildog：&lt;/p&gt;
&lt;p&gt;AOLS: MSTP再发展向什么方向？再测测什么东西&lt;/p&gt;
&lt;p&gt;aols 修 行: 版主&lt;/p&gt;
&lt;p&gt;MSTP再发展向什么方向？再测测什么东西 实际上是想接着ASON的东西灌水，结果总是进不了页面，只能另开了，不好意思&lt;/p&gt;
&lt;p&gt;2002年，传输所受中国移动委托测试了城域网设备：MSTP和OADM，共有17家厂商参加了测试，初步验证了SDH上支持以太网的数据能力（透传、二 层交换、环网等）；2003年中国电信北京研究院组织了16家厂商进行了长达3个多月的MSTP测试，根据SDH性能、以太网、ATM、网管、互联互通 （VCAT/GFP和LCAS）等几方面的结果，做了综合的排名，实现了多个厂家基于GFP映射的虚级联互通、LCAS互通；最近又听说传输所又在测试 MSTP，不知会测出什么新的结果？内嵌RPR，还是Martini MPLS功能？进行了这么多的测试，也有很多专家预言了其发展方向，可现在省内城域网的建设MSTP真的发挥了多少其多业务节点的特性，建设中MSTP在 网络的运营维护中是如何管理的？（数据网管还是传输网管）应用的问题还没有呈现的特别明显&lt;/p&gt;
&lt;p&gt;fallleaf：&lt;/p&gt;
&lt;p&gt;年初是中国移动搞测试，现在还没完。到月底会有一个测试结果。传输网的建设思路也会出来。&lt;/p&gt;
&lt;p&gt;ASON：&lt;/p&gt;
&lt;p&gt;有了L2的交换功能，我认为MSTP还不具备开展大规模以太网业务的能力，其原因当然是受到了L2交换的一些限制，其具体表现在： 1) VLAN的数目限制 根据802.1Q的标准，VLAN最大的数量是4096个。这个数量完全无法满足运营商运营的要求。所以许多的厂家提出了改进的方法，主要的思想就是在 802.1q的以太网帧上面加多一个标签。增加了一个标签，VLAN的数量可以大大的增加，运营商使用起来也更加的方便。而且原来的VLAN标签可以让给 最终用户使用。但标签的加法，各厂家又不一样了。有的厂家直接在802.1Q的帧上再打一个802.1Q的标签，简称QinQ，或标签堆栈。有的厂家自己 开发一个标签。有的厂家号称采用MPLS的方法来解决，因为MPLS的标签也是放在二层的帧里的。（呵呵，大家看到了吧，到了这一步，GFP的用处还有多 大呢？因为各厂家的二层处理完全不同，GFP也只能是在透传的时候保证互连互通。另外我对某些厂家号称的MPLS持保留态度。我怀疑他们所谓MPLS只不 过是QinQ的一个变种。真正的MPLS是基于标签做转发的，并且转发的时候目的mac地址是会变的。QinQ是基于Mac地址做转发的，转发的时候目的 mac是不变的。呵呵） 2) MAC地址表的容量限制 这个不用多说了，张成良大师的ppt里已经讲得很清楚了。L2交换是通过交换机（或者说是MSTP里的L2交换模块）里的一个MAC寻址表工作的。维护这 个表需要经常发广播包，转发以太网帧，也需要这个表去对应目的mac地址和转发的端口。一个交换机的典型MAC寻址容量是几k到几十k，纯L2交换并不能 完全满足大规模部署以太网业务的需要。 3) 网络组网没有层次，不具备可扩展性 L2的交换是一个非常扁平的网络，在大规模使用时，如果不与路由设备相结合，会遇到较多的困难。 4) 共享带宽不均衡的限制 在L2的交换过程中，如果没有QoS的保障，会出现离目的地远的交换机所能占用的带宽会被较近的交换机挤占的现象。这时，网络的规划显得非常重要。一个是 利用不同的VLAN和spanning－tree，尽量将业务分流。在VC传输管道上也需要考虑是安排多一点的带宽，还是干脆就将以太网业务放到不同的管 道里去传。或者通过QoS策略，保证每个节点的应有带宽。 fallleaf：&lt;/p&gt;
&lt;p&gt;ASON所说的总感觉是就技术谈技术，没有结合实际情况。有些一厢情愿&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;当年搞载波机的人对搞PDH的人说：“一根光纤传这么多路电话，如果断了怎么办。” 当年搞PDH的人对搞SDH的人说：“你这155M还没有我140M传的话路多，我用不着交叉连接，有DDF，调电路更方便。” 当年搞SDH的人对搞MSTP的人说：“。。。。。。” 让不远的将来来说吧，呵呵&lt;/p&gt;
&lt;p&gt;fallleaf，呵呵，如果真有实际的情况，你不妨放一个上来，让大家都讨论讨论吧。这里高手如云，大家没准各出奇招呢。&lt;/p&gt;
&lt;p&gt;fallleaf:&lt;/p&gt;
&lt;p&gt;问题就在于没有多少实例验证MSTP的组网功能。用的上的最多是透传。其他功能还有什么用。&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;呵呵，其实好多中小城市的数据网其实是可以以MSTP为主，构成数据城域网的。关键是这些MSTP需要解决纯L2交换的一些局限，如我上文所说。在城域网的接入和汇聚层，MSTP有许多应用的机会。&lt;/p&gt;
&lt;p&gt;关键是，现在负责建设数据城域网的是数据部门，不是传输部门，所以MSTP没有用武之地啊。从这个方面讲，设计部门更应该及早了解MSTP的数据处理能力，在设计网络的时候能够统一考虑，提出综合的网络设计方案。&lt;/p&gt;
&lt;p&gt;问题就在于没有多少实例验证MSTP的组网功能。用的上的最多是透传。&lt;/p&gt;
&lt;p&gt;透传的以太网业务是干什么用的？MSTP可以凭借自己强大的数据处理功能，在需要处理以太网业务的地方发挥自己应有的作用的。&lt;/p&gt;
&lt;p&gt;另外，透传也要好好研究，有在物理层的映射，这叫透传。还有二层的QinQ，以太网业务也可以透传，甚至在三层的Ethernet over MPLS，也是透传。呵呵，如果MSTP能够做到Ethernet over MPLS，那用它来组数据城域网还有什么不可以的？&lt;/p&gt;
&lt;p&gt;tianzd:&lt;/p&gt;
&lt;p&gt;问题就在于没有多少实例验证MSTP的组网功能。用的上的最多是透传。&lt;/p&gt;
&lt;p&gt;这句话很对。目前大多数厂家MSTP设备没有解决以太网保护方式和保护倒换准则如二层交换保护（STP保护）、以太环网保护、ATM VP RING支持等等，二层交换实际处于研发或试用状态。为什么会主要使用路由器＋E1/POS接入、路由器＋光纤直连等方式（自然是MSTP、SDH、PDH、微波、光纤直连、光纤拉远等手段都使用）进行数据业务接入，不是传输或数据部门的技术观念问题，你说谁愿意用落后的技术？在用网络改造可比新建困难的多，除 了投资汇报等因素外，应该说现阶段MSTP设备在标准、产品上都与实际应用有差距，希望MSTP研发人员转换观念，深入实际应用，作为厂家、专家不要为MSTP而MSTP，光顾着炒作，要充分理解实际网络所需要的解决方案，理解MSTP STM－64、MSTP－16、STM－4/1实现的功能要求也是不一样的，需要它们的系统性（希望对此有高见：核心、汇聚、接入是不同的要求），以便充分利用MSTP强大的数据功能组网处理数据业务。&lt;/p&gt;
&lt;p&gt;关于传输所MSTP测试问题：应该是验证各厂家设备数据功能的实际所用技术、能力，并没有综合排名之说。 按MSTP设备目前状态，数据与传送网管只能各管各的。 所有运营商当然希望原有SDH进行MSTP功能升级后就能解决所有数据业务问题。只是目前设备性能不怎么样，价格却不低。&lt;/p&gt;
&lt;p&gt;谢fallleaf！！！个人认为新建的小网络使用MSTP无可厚非，希望能有大网络特别是综合网络实例验证MSTP的组网功能。咱们关注新技术，不迷信新技术。 回头看：朗讯94—96力推DXC，从中国电信捞了不少票子，可实际上DDF一个也不少，更可怜的是连千年虫问题时也需付美金请老外站在DXC旁来软件升级。&lt;/p&gt;
&lt;p&gt;ASON:&lt;/p&gt;
&lt;p&gt;只是目前设备性能不怎么样，价格却不低。&lt;/p&gt;
&lt;p&gt;呵呵，我觉得这句话也许道出了MSTP目前所面临的问题。另外，对于数据应用来说，我觉得MSTP也就是应用在接入层和汇聚层，核心层的数据设备还是需要 专门的交换机和路由器的。如果定位在接入和汇聚层，MSTP的接口速率应该是622M，2.5G这个水平。如果是局间的数据业务高速透传，可能需要用到 10G的SDH设备来传送高速的数据业务，但不需要MSTP来处理了。155M级别的SDH设备，传传低速的以太网业务就可以了，哈哈，没必要再搞什么特 别的东东在上面了。&lt;/p&gt;
&lt;p&gt;yxy791106:&lt;/p&gt;
&lt;p&gt;注意看，首先，VPN之间的互通的MPLS-VPN可以由MSTP完成，但在目前，注意！是目前！对于MPLS-VPN的实现不可能单独依赖MSTP，毕竟，MSTP的能力没有这么强。&lt;/p&gt;
&lt;p&gt;但是，假如个别的专网用户，要求大带宽，但是它们的路由策略又非常简单（比如仅仅若干条静态路由即可解决问题），比如这个例子里面的VPNA和B，这时在MSTP上叠加L3就是件好事情。我1个MSTP就OK了。而且直接纳入了电信的传输网，管理非常方便。&lt;/p&gt;
&lt;p&gt;另外更正一些基本错误，ASON说的：“EthernetoverMPLS”，通常认为是L2的MPLS-VPN，挂不上L3。CISCO官方的标准说法是：EOM为L2，ATOM是L3。&lt;/p&gt;
&lt;p&gt;非常欣赏ASON兄弟的言论，希望进一步深入讨论。我前面说过了，我是个数据爱好者，什么东西都往那里想，不妨交个朋友，可以短消息给我，呵呵。&lt;/p&gt;
&lt;p&gt;fallleaf:&lt;/p&gt;
&lt;p&gt;呵呵，外出一天，回来一看很热闹。 我站在tianzd一边，不过好像这边的人少了些。&lt;/p&gt;
&lt;p&gt;我提个另外的建议，既然这么看重数据功能，不如在数据设备上增加传输的功能，这样不比在传输设备上增加数据功能更简单些？呵呵，纯属玩笑。&lt;/p&gt;
&lt;p&gt;yxy791106:&lt;/p&gt;
&lt;p&gt;原因有2。&lt;/p&gt;
&lt;p&gt;1是在数据设备上做传输口比传输上做数据口贵多了，比较一下ROUTER上的E1和POS，和SDH上的ETHERNET口，你就会得出结论。&lt;/p&gt;
&lt;p&gt;2是处理能力。相对于数据设备，SDH内部结构简单，芯片的功能比较单一。而ROUTER里面数据的策略太对，常常要通过ASIC阵列和NPU来进行处理，这对于SDH来说太昂贵而且不合算。这个问题以前ZTE的总工陈伟专门做过澄清。&lt;/p&gt;
&lt;p&gt;tianzd:&lt;/p&gt;
&lt;p&gt;下午3点出差回来，发现这里很冷清。数据设备不做传输口主要是设备供应商传输、数据研发是两条线，单纯从技术面在数据侧提供传输口并不复杂，数据侧要不就 不愿做或提供则价格很高，主要是传输价格低。分析传输价格低的原因首先传输技术这些年进展快，设备是一波推一波，其次传输属于基础网，运营商随时可以更换 传输厂家，而数据、移动通信等属于一旦上了贼船就只能跟船走。&lt;/p&gt;
&lt;p&gt;bigtaildog:&lt;/p&gt;
&lt;p&gt;tianzd,ASON,fallleaf,燕子都是实际经验丰富的人，而且不吝笔墨，奉献了这么一场精彩的讨论，上次类似这么好的讨论好象是关于FTTH的。&lt;/p&gt;
&lt;p&gt;做为听众，我受益很多。讨论一方面涉及到MSTP的数据业务功能的走向，一方面涉及到MSTP如何引入，最后的话题似乎与传输设备和数据设备的定位有些关系。&lt;/p&gt;
&lt;p&gt;摘录网通的唐雄燕的一些观点，和讨论中一些观点很切合。&lt;/p&gt;
&lt;p&gt;关于MSTP的定位:&lt;/p&gt;
&lt;p&gt;1)MSTP技术主要定位在城域网的汇聚层与接入层，利用MSTP实现城域网接入层和汇聚层实现传送网与业务网的“合网建设”，这种方式特别适合应用在以TDM业务为主、同时需要提供以太网业务及ATM业务的网络环境中。&lt;/p&gt;
&lt;p&gt;2)要正确处理传送网与业务网的关系。MSTP主要是为业务网提供接入与延伸手段，而不是完全替代业务网. 3)MSTP技术虽然实现了多种接入方式的综合，能够完成TDM业务、以太网业务和ATM业务等多种业务的综合接入和传送，但是对于单一业务，例如以太网业务，其性价比显然不如专用的以太网交换机，MSTP并非某单个业务接入的最佳解决方案。&lt;/p&gt;
&lt;p&gt;MSTP的引入:&lt;/p&gt;
&lt;p&gt;1)对于MSTP技术的引入，关键问题是如何处理好传送网与业务网的关系。从本质上讲，MSTP定位于城域传送网范畴，主要目的是实现多业务的综合传送，其较完善的二层交换等数据链路层功能也仅仅是为了提高数据业务的传送效率&lt;/p&gt;
&lt;p&gt;2)引入MSTP与现行网络维护和业务管理体制存在矛盾。传统的网络运行维护和业务管理是按专业划分的，数据网络和传输网络通常由不同的部门管理，各个网络也有自己相对独立的网管系统，这种管理模式会对MSTP的引入产生一定的障碍。&lt;/p&gt;
&lt;p&gt;3)引入时应充分考虑与城域IP网、本地SDH网的统筹规划,&lt;/p&gt;
&lt;p&gt;tianzd:&lt;/p&gt;
&lt;p&gt;MSTP现象：&lt;/p&gt;
&lt;p&gt;1、专家、厂家推动多，运营商应用少。特别是试用多，规模商用少。 2、新兴运营商的网络应用多，主流运营商网络应用少。因为业务总量、种类需求不一样。 3、专家、厂家倡导技术走向，文章多（大同小异），运营商只是关注技术走向，注重网络综合效果、设备性价比、投资回报等等，文章自然少。 4、运营商传输的希望多应用（如我等），数据的说用MSTP投资高，网络的业务管理等功能、可维护性还不如数据设备。 各位大侠，能否提供各主流厂商MSTP规模应用的实例（网络的网元数量超100，设备具备主要的MSTP功能，最好有RPR、MPLS）&lt;/p&gt;</description></item></channel></rss>