《中興：2024年IP網絡未來演進技術白皮書4.0——服務感知網絡（SAN）（64頁）.pdf》由會員分享，可在線閱讀，更多相關《中興：2024年IP網絡未來演進技術白皮書4.0——服務感知網絡（SAN）（64頁）.pdf（64頁珍藏版）》請在三個皮匠報告上搜索。

1、IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）第 1 頁I IP P網絡未來演進技術白皮網絡未來演進技術白皮書書4.04.0服務感知網絡（服務感知網絡（SANSAN）中興通訊股份有限公司中興通訊股份有限公司IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）IP 網絡未來演進技術白皮書 4.0 服務感知網絡(SAN)中國信息通信研究院中國電信研究院中國聯通研究院北京交通大學版本日期作者備注V1.02021/05/22ZTE新建V2.02022/08/28ZTE更新：提出開放服務互聯網絡解決方案和三大關鍵技術：服務感知網絡（SAN）、增強確定性網絡（EDN）、網絡內生安全

2、V3.02023/08/22ZTE更新：提出增強確定性網絡（EDN）架構及其關鍵技術V4.02024/09/27ZTE更新：提出服務感知網絡（SAN）架構及其關鍵技術2024 ZTE Corporation.All rights reserved.2024 版權所有中興通訊股份有限公司保留所有權利版權聲明：本文檔著作權由中興通訊股份有限公司享有。文中涉及中興通訊股份有限公司的專有信息，未經中興通訊股份有限公司書面許可，任何單位和個人不得使用和泄漏該文檔以及該文檔包含的任何圖片、表格、數據及其他信息。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散目

3、錄目錄1 前言.12 IP 網絡未來演進趨勢.13 SAN 關鍵場景及需求.23.1 算網融合.23.1.1 算網融合下的廣域服務部署與協同場景.23.1.2 算網融合下廣域服務協同的需求與挑戰.83.2 算網一體調度和運維.93.2.1OTT 和智能邊緣服務調度主要問題和痛點.93.2.2算網一體調度和運維場景和需求.103.2.3算網一體調度和運維主要挑戰.113.3 網絡能力和業務需求協同.133.3.1 未來 IP 網絡中業務和網絡協同.133.3.2 業網協同應用場景.163.3.3 業網協同功能的設計需求.173.4 智算網絡端網協同.193.4.1 網絡多路徑控制問題及需求.19

4、3.4.2 擁塞控制問題及需求.204 SAN 整體架構及設計理念.214.1 算網一體流量工程.214.1.1 算網一體 TE 三要素.224.1.2 算網一體 TE 轉控分離技術架構.23IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）4.1.3 算網一體 TE 部署和應用演進.244.2 SAN 核心設計理念.254.2.1 獨立語義服務標識.264.2.2 位置和歸屬無關.284.2.3 端到端服務.294.2.4 數據面輕量化.294.2.5 控制面極簡化.304.3 SAN 參考架構.314.4 SAN 與現有技術的 GAP 分析.324.4.1 基于 DNS 和 GS

5、LB（全局負載均衡）服務調度模式.324.4.2 基于 ICN 的服務調度.335 SAN 關鍵技術.345.1 HFC（Hybrid Function Chain）混合功能鏈.345.1.1 HFC 技術特征與內涵.345.1.2 HFC 系統架構.355.1.3 基于 SRv6 的 HFC 技術.365.2 FSP(Flexible Scheduling Policy)靈活調度策略.365.2.1 支持多種約束條件的 TE 計算.365.2.2 業務調度和負載均衡技術.375.3 FS-OAM(Full-Stack OAM)全棧算網 OAM.395.3.1 網絡和計算可觀測現狀.395.3

6、.2 FS-OAM 關鍵目標和技術.39IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散5.4 端到端網絡業務協同服務系統.435.4.1 基于 SAN 的增強型業務控制層.435.4.2 業網協同功能層的接口需求.445.5 基于統一標識的智算端網協同.455.5.1 基于統一標識的智算端網協同架構.455.5.2 基于統一標識的多路徑控制.465.5.3 基于統一標識的擁塞控制參數適配.466 SAN 樣機及測試總結.476.1 SAN 算力路由樣機試點.476.2 SAN 服務治理測試驗證.507 技術及產業展望.548 參考文獻.56IP

7、網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散圖圖圖 1異構服務集群的互聯.4圖 2多邊緣多實例的服務路由.6圖 3處在不同請求與調用鏈路的服務實例.7圖 4算力網絡 TE 和運維示意圖.11圖 5傳統互聯網基于“盡力而為”的無差別傳輸服務.13圖 6overlay 應用層和專線提供差異化內容交付服務.14圖 7業網協同功能協同模式為應用層提供匹配業務特征和傳輸需求的差異化網絡服務 15圖 8算網 TE 計算模型.21圖 9網絡流量工程和算網流量工程.22圖 10集中式算力采集+分布式/集中式計算架構.24圖 11分布式算力采集+分布式/集中式計算架構

8、.24圖 12服務感知網絡關鍵設計理念.26圖 13服務感知網絡參考架構.32圖 14DNS+GSLB 的算力服務調度.33圖 15混合功能鏈（HFC，Hybrid Function Chain）架構.35圖 16算網 OAM 需求和目標.40圖 17融合 SAN 的業網協同層的功能框架.43圖 18業網協同功能層和 SAN 網絡的系統工作模式.44圖 19基于統一標識的智算端網協同總體架構.46圖 20SAN 樣機實踐歷程.47圖 21SAN2.0 樣機試點組網和目標.49IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）圖 22集成 SAN 的服務互聯測試方案.52圖 23Ist

9、io 的 Ambient 模式服務互聯測試方案.52圖 24Istio 的 Sidecar 模式服務互聯測試方案.53圖 25不同方案服務完成時延分布.53圖 26不同方案平均服務完成時延.54IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 1 頁1 前言云計算、大數據、AI 訓練等新型業務驅動下，算網融合成為新型數字基礎設施的典型場景和核心需求。算網融合在資源協同調度效率、業務性能優化等方面的需求和收益，近年來已經成為行業初步共識。隨著云原生、AI 訓練等新型業務的飛速發展，對基礎網絡增量需求的內涵和外延，均出現了全新的變化。本文延續此前系列

10、白皮書，聚焦算網融合場景的技術和架構演進視角，并就數據中心內及數據中心間東西向業務流量場景進行延伸覆蓋，同時擴展了算網層次化性能檢測、業網協同、獨立語義服務標識等方向的架構和方案闡述。從服務感知網絡整體架構視角來看，本文將繼承基于服務標識索引的算力路由和精細化網絡連接這兩大基礎功能。其中，服務標識的獨立語義將會得到強化表述，即基于服務標識構建覆蓋多場景的統一技術架構。服務標識是算力與網絡、業務與網絡、端側與網絡融合的關鍵功能單元和架構接口。2 IP 網絡未來演進趨勢從分組網絡的業務承載類型來看，純話音業務模式下，業務和網絡一體化融合，網絡內生支撐話音業務，業務得到確定性保障，業務就是網絡，網絡

11、就是業務?；ヂ摼W數據業務模式下，業務和網絡在架構和協議層面分離，多種業務流量在承載網絡之上混合共存，網絡不再感知和識別業務，而是對所有業務流量進行基于統計復用的“盡力而為”轉發，網絡成為純粹中立的承載基礎設施，這種簡明清晰的架構和部署模式，憑借其優異的可擴展性和成本優勢，助推了互聯網業務的爆發式增長。云計算的興起和廣泛部署，改變了業務數據的流量模型和算網交互模式，并對網絡提出了延伸感知算力和業務的新型需求。網絡、算力和業務從彼此獨立割裂到適度融合以因應新型應用場景，遂成為新型數字基礎設施模式下的演進趨勢。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴

12、散第 2 頁盡管過去 20 年以來，業界涌現出多種試圖替代 IP 網絡的技術架構（如 NDN/ICN 等），但由于牽涉海量的網絡基礎設施存量投資，顛覆性替代方案很難被廣泛接受并部署。更重要的是，IP 網絡架構并非封閉和一成不變，IPv6 提供了豐富的擴展機制，支持平滑演進的功能增強，SRv6、BIER（新型組播）等即為經典案例。同時，IETF 也已經正式啟動 MPLS 2.0（又稱 MNA）的標準推進工作，基于 MPLS 的擴展和增強也將成為現實可能。因此，基于輕量級數據面和智能控制面的功能增強和擴展，將是 IP 網絡技術平滑演進的主流趨勢。本白皮書在IP 網絡未來演進技術白皮書 2.0 提出

13、的開放服務互聯網絡及其關鍵技術的基礎上，詳細闡述服務感知網絡（SAN）的場景需求、架構理念、關鍵技術、測試驗證、技術及產業展望等內容。3 SAN 關鍵場景及需求3.1 算網融合3.1.1 算網融合下的廣域服務部署與協同場景當前，構成互聯網的兩大基礎設施IT 基礎設施和 CT 基礎設施都在經歷重大的融合演進變化，即“云化”和“網絡化”?！霸苹笔侵赴☉?、網絡和云設施等都在虛擬化，通過虛擬化實現應用、云和網共享基礎資源池，如計算、存儲、轉發等，實現一體化編排和調度。而“網絡化”可以理解為去中心化、分布式計算、邊緣計算等。網絡化主要是應對廣泛部署的無線網絡和 IoT 設施，原來基于集中式架構的云

14、化模型無法滿足泛在的應用需求和分布式的云資源部署，從而向由網絡連接的分布式算力和存儲等虛擬化云資源提供模式演進。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 3 頁一方面，云原生作為一種面向云計算時代的軟件架構和開發理念，旨在充分利用云服務的彈性、可伸縮性和高可用性，為應對云計算環境下的復雜性和需求提供全新的解決方案和開發范式，其自身具備豐富、鮮明和獨特的特性，如容器化，微服務架構，自動化部署與調度，彈性資源伸縮，故障隔離及高可用性，服務網格等。隨著云原生應用開發和運維模式的成熟，未來上云的應用將可以分解為更細顆粒度的原子服務，通過調用分布式

15、的原子服務，或者原子服務的組合，從而可以支持更復雜的應用場景，如元宇宙等。因此，以原子服務為顆粒度的服務和感知技術，將能夠在精確服務能力和分布式資源調度方面滿足未來云原生應用發展的需要。另一方面，邊緣計算作為一種分布式計算范式，其核心思想是將計算、存儲和應用程序的處理能力盡可能靠近數據源和最終用戶，以降低延遲、提高響應速度和數據安全性。其特征與優勢包括分布式部署，低時延，高資源利用率，帶寬成本優勢等。應用的原子化解構與基于廣域的服務與算力部署、連接和協同，共同組成了新時代下的算網融合新場景。3.1.1.1 廣域跨邊緣的服務連接場景子場景子場景 1 1：跨集群服務連接的邊車與代理攔截：跨集群服務

16、連接的邊車與代理攔截以 Istio 為例，其作為一種服務網格架構，使用 Envoy 代理服務網格中的所有服務協調入站和出站流量。Istio 使用 Envoy 的各種特性，如動態服務發現、負載均衡、TLS 終止、HTTP/2 和 gRPC 遠程過程調用（gRPC）代理、熔斷、健康檢查、分階段推出基于百分比的流量劃分等。當存在流量流入或從應用和服務容器流出時，流量總是會被邊車和代理攔截，進而由邊車和代理根據控制面管理的路由和路由規則引導流量?？梢灶A料到，當部署在多個邊緣云和集群中的服務需要連接和通信時，服務的攔截和引導將會變得更加復雜。數次的邊車與代理攔截也將使得服務的連接能力下降。IP 網絡未來

17、演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 4 頁子場景子場景 2 2：異構集群的部署與廣域協同：異構集群的部署與廣域協同當處在不同連接域的資源和服務之間存在連接和協同的需要時，如圖 1 所示，數個 K8S集群中和另一個虛機集群中部署的服務存在連接需要，如何適應性地管理多種連接域的資源和服務實例成為了亟待解決的問題，其中包括但不限于：數個集群中的部分實例存在連接需要，但另一部分實例不被允許通信時，如何能夠更高效地為每個集群配置規則；當處在 K8S連接域的服務實例希望訪問處在一個虛機集群中的實例中，如何統一服務語義。圖 1 異構服務集群的互聯3.1.1.2

18、廣域多邊緣的服務調度場景子場景子場景 1 1：管理大量、動態的遠端服務實例：管理大量、動態的遠端服務實例在云原生的背景下，應用程序往往通過名稱（例如 Service IP）對服務進行尋址，來避免直接通過 IP 地址對服務進行尋址的脆弱性。以集群 1 訪問集群 2 中的服務為例，需要在集群 1 中配置集群 2 中的服務名以及其所對應的的 endpoints 中，如集群 2 的 IngressGateway 地址。即，該將集群 1 訪問該服務名的流量路由到集群 2 的 Ingress Gateway。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第

19、5 頁而 Serverless 技術是一種云計算服務模型，其核心理念是開發者無需關心服務器的管理和維護，可以專注于編寫和部署代碼。其中，云服務提供商會根據負載自動擴展和收縮函數實例，以滿足當前的服務請求量，而開發者則無需手動干預。當請求進入 FaaS 平臺后，請求處理模塊會在實例管理模塊中查詢是否有可用（空閑）狀態的實例，如有空閑實例，則將對應的請求調度到該實例中，相應的加載和運行業務代碼，并返回結果。當業務請求激增時，資源池中無可用實例，則去資源調度模塊中申請擴容，資源調度模塊相應創建新的實例加入資源池。因此，在算網融合的背景下，網絡連接的多邊緣系統中可能存在著大量的、動態喚起或釋放的遠端服

20、務實例。由于本集群訪問遠端集群實例的前提是遠端服務實例在本端 API 中的注冊和配置，而遠端服務往往是大量的和動態的，這意味著本端集群需要動態地處理大量的遠端服務實例在本端的配置，相應的，這會對本端集群的管理和運維造成極大的負擔和困難。子場景子場景 2 2：算網一體調度：算網一體調度以 Istio 為例，Istio 中的流量操縱和路由的實踐主要包括 API 的方式影響部署中的流量。如通過 DestinationRule 配置根據標簽將單個服務拆分為子集。并為每個子集分別配置特性。常用的負載均衡方式包括：Round Robin（輪詢）、Least Request（最小請求數）、Weighted

21、Round Robin（加權輪詢）等?？梢园l現，服務路由的決策發生和執行在服務端側，由集群的網絡 API 配置指導執行，然而服務端側的業務流量調度往往不具備網絡側傳輸能力的信息。如圖 2，遠端服務Service B 部署在兩個邊緣，Service B 的多實例在本地集群的 ServiceEntry 中注冊。Service B 的多實例之間在本地集群配置為 Round Robin 或 Weighted Round Robin 等可行的負載方法。然而，可以注意到，負載均衡方式的配置往往是靜態的，當連接 Service BIP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未

22、經許可不得擴散第 6 頁的多實例的網絡路徑具備不同能力時，如圖 2 中，兩條網絡傳輸路徑的基本能力為（30ms，100M）和（60ms，400M），靜態配置的負載均衡方式往往很難為用戶提供極致的服務體驗。圖 2 多邊緣多實例的服務路由子場景子場景 3 3：多原子服務和功能的協同調度：多原子服務和功能的協同調度在云原生應用的大背景下，應用程序往往不再以單體服務的形式存在，而是被分解為一系列云原生服務部署在 Kubernetes 集群中，服務之間存在調用鏈路、共同對外提供服務。如流量泳道技術應運而生，用于在灰度發布的場景下，對服務的整條請求鏈路進行環境隔離與流量控制。而事實上，流量泳道的創建依然由

23、集群的各種網絡 API 配置執行。配置于集群和服務端側的服務路由標識了在一個服務名下的 endpoints 和在這些可選實例之間的調度策略和負載均衡方法。然而，在服務之間存在多跳的請求與調用鏈路的場景下，服務端側的下一跳服務路由和該跳服務請求或調用在請求與調用鏈路中的相對位置和對應需求無法建立關聯關系。如圖 3 多邊緣之間部署了 Service A-D 的四種服務，它們之間存在著兩種請求與調用鏈路，分別是 Service A-Service B-Service C 和 Service A-Service B-Service D。針對每種調用鏈路，其中的服務相互協同，共同提供對外服務，其中前者組

24、成了一種端到端的IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 7 頁時延敏感型服務，而后者組成了一種對端到端傳輸帶寬具有較高需求的服務。此時，對于配置在 Service A 所在集群的服務路由策略和規則，無法區分出這兩種服務請求和調用鏈路，因為對于 Service A 的服務實例而言，這兩種服務請求與調用鏈路所對應的對外服務具有著一個相同的服務的 endpoint。圖 3 處在不同請求與調用鏈路的服務實例3.1.1.3 廣域多邊緣的服務可觀測場景當應用和服務被分解為由多個分布式部署的服務實例協同和組合對外提供時，如何跨越多個服務端點和連接服務

25、端點的傳輸網絡提供端到端服務流量的可觀測和保護特性成為了新的亟待解決的問題。在網絡中，已經具備了基本成熟的 OAM 技術實現傳輸網絡和鏈路的檢測。其中，如STAMP（Simple Two-way Active Measurement Protocol，簡單雙向主動測量協議）可以通過配置實現 Session-Sender 和 Session-Reflector 之間 STAMP 會話的建立。STAMP 會話由（源端 IP、目的端 IP、源端 UDP 端口、目的端 UDP 端口）四元組組成一個 STAMP session。STAMP Session-Sender 向 STAMP Session-R

26、eflector 周期性發送測量報文，STAMP Session-Reflector 針對每個接收到的測量報文回送響應測量報文，STAMP Session-Sender 根據接收到的響應測量報文計算出丟包率、時延和抖動等 SLAIP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 8 頁性能參數值。在應用側，如 eBPF（Extended Berkeley Packet Filter）技術可以在 Linux 內核中動態注入代碼，從而實現高效的系統監測和調試。它可以使用鉤子和事件觸發器，如通過在關鍵位置（例如系統調用、網絡數據包處理、內核事件等）安裝鉤子

27、（hooks），以及定義事件觸發器（event triggers），來捕獲特定的系統活動。如可以在進程創建、調度、終止等關鍵事件時設置鉤子，從而記錄或者分析這些事件的發生情況。eBPF 可以分析進程或線程的運行時行為，例如測量系統調用的響應時間、資源使用情況等，以幫助識別性能瓶頸或優化潛力。其他的，如 APM 技術（Application Performance Management，應用性能管理），提供了監控與數據采集、性能分析與診斷、實時監控與報警和可視化與報告特性與能力。APM 通常提供直觀的儀表板和報告，用于展示應用程序的性能指標和趨勢，有助于運維人員和開發團隊快速了解應用程序的健康狀

28、況和潛在問題。網絡側的 OAM 技術提供了對傳輸網絡的監測和可觀測手段，但是缺乏網絡基礎設施關聯的服務與應用的信息；eBPF 通過在內核中動態注入代碼，利用系統調用和內核事件的鉤子機制，實現了對 Linux 系統中線程和進程活動的細粒度監測，但是這些線程與進程活動如何與服務邏輯關聯仍然是缺失的一環；APM 提供了應用的儀表與大盤，卻沒有手段采集和獲知跨廣域網絡的連接情況與能力。3.1.2 算網融合下廣域服務協同的需求與挑戰算網融合下的廣域服務部署域協同場景下的需求與問題，對新時代下的算網基礎設施與系統提出了新的需求和挑戰：一致和高效的服務連接能力：實現同或異服務提供和運營商的跨集群、單或多網絡

29、、可能不同運行態和連接域場景下的服務實例間高性能和一致性連接。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 9 頁有效和智能的服務調度能力：實現有效和高效的廣域多邊緣、多集群的分布式服務實例的系統性管理和運營；實現多樣化管理和調度策略下，結合算網資源能力并滿足服務SLA 需求服務流量調度和負載均衡；實現跨越多邊緣、多服務端點的全程服務的差異化服務提供與一致性服務能力保障。端到端的全程服務可觀測能力：實現跨越多邊緣、多服務端點的全程服務的可觀測能力，提供包括服務粒度的多層次可觀測與劣化、失能定位與維護手段，進而實現端到端全程服務的調優和失能保護

30、。3.2 算網一體調度和運維3.2.1OTT 和智能邊緣服務調度主要問題和痛點在算網一體服務模式下，確保端到端協同是維持高質量與穩定性的核心。然而，在傳統OTT 業務中，基于 DNS+GSLB 的傳統算力服務模式與網絡狀態分離，難以滿足全面的服務需求。隨著 AI 大模型的發展，受限于單芯片算力提升速度（摩爾定律），未來算力供給將更多依賴于集群計算。入算推理結合邊緣計算與 AI 技術以提升用戶體驗、優化資源分配并增強數據安全性。在這種背景下，算網分離的調度模式將面臨以下關鍵問題和痛點：性能短板：算力服務與網絡狀態不匹配時，可能導致數據傳輸延遲或失敗，影響系統性能和效率。例如，在算力資源充足的情況

31、下，網絡擁堵仍會導致數據處理速度變慢。資源浪費：算網分離狀態下資源分配不合理，可能導致在網絡負載較低時未能充分利用算力資源，或在網絡擁堵時過度分配算力資源。服務質量下降：高延遲或數據包丟失等現象可能影響用戶體驗，如視頻流不流暢、在線游戲體驗差或文件傳輸失敗。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 10 頁成本增加：資源使用效率低下可能導致成本上升，例如過度使用云服務資源或產生不必要的數據傳輸費用。安全風險：算網狀態分離可能導致安全策略執行不一致，從而增加數據泄露和其他安全威脅的風險。管理復雜性增加：需要分別監控和優化算力服務及網絡狀態，增

32、加了管理復雜性和工作量。3.2.2算網一體調度和運維場景和需求針對 OTT 和智能邊緣服務調度的問題，算力網絡提出了一體化調度策略，以網為中心感知網絡和算力狀態，拉通算網資源運營和調度體系。這一策略旨在獲取面向服務訪問的最優解，并重點滿足以下關鍵場景需求：一致最優體驗：端到端算網調度過程中，全面考慮網絡延遲、服務器響應時間等關鍵因素。高延遲會使得頁面加載遲緩、視頻播放不流暢；低速網絡則顯著降低數據傳輸效率。因此，在算網聯合決策時，必須重視這些因素以確保用戶獲得流暢、高效的使用體驗。算網負載均衡：作為復雜的系統工程，實現計算和網絡資源的有效利用需要綜合考量資源狀態（計算節點和網絡鏈路的負載、可用

33、性和健康狀態）、任務特性、負載均衡策略與算法、動態調整機制、故障恢復能力以及預測優化技術，以提高系統整體性能和響應速度，增強系統穩定性和可靠性。一體化運維：打破算和網信息孤島的關鍵，在于構建統一的監控平臺以實時監測計算、存儲與網絡資源狀態；利用自動化工具和流程提高運維效率；建立快速響應機制確保故障迅速定位與服務恢復；通過動態資源調整和優化調度策略避免資源浪費并提升利用率。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 11 頁3.2.3算網一體調度和運維主要挑戰傳 統 網 絡 的 Traffic Engineering(TE)、運 維(Oper

34、ations)與Operations,Administration,and Maintenance(OAM)三者在現代網絡體系中扮演著至關重要的角色。TE 致力于優化網絡資源分配和提升傳輸效率，運維負責日常操作與管理，確保服務連續性，而 OAM 則專注于網絡監控、故障檢測與性能管理。這三個方面相互依存，協同作業：TE 為運維和 OAM 提供基礎網絡優化策略；運維通過執行 TE 策略并利用 OAM 工具監控網絡狀態；OAM 反饋的實時信息支持 TE 和運維做出進一步優化決策。這種協同模式保障了網絡資源的有效利用和持續的高服務質量。圖 4 算力網絡 TE 和運維示意圖如圖 4 所示，在算力網絡環境

35、下，網絡設備需感知算力資源狀態，并結合網絡資源狀態進行智能決策，選擇最佳計算實例和路徑。為了提供更優質的服務，一方面要基于網絡和算力資源實時狀態進行聯合計算；另一方面需快速檢測算網服務質量是否達標，以觸發業務動態調整。此外，故障根因分析對于提升運維效率至關重要。在分布式場景中，IGW（InternetGateway）需綜合考慮網絡與算力狀態，精準計算最優路徑及資源分配。傳統 TE 技術通過鏈路 OAM 收集信息，并經 IGP-TE 擴展至 IGW 以滿足網絡 SLA 需求。然而，在算網融合場景下，TE 機制必須處理網絡與算力數據，在周期性調度、逐流分配及負載均衡等場景IP 網絡未來演進技術白皮

36、書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 12 頁下優化資源分配，但目前的 TE 技術尚不具備算力感知能力。此外，實現基礎算力網絡功能尚面臨四大挑戰：DCN 網絡與計算實例性能波動：DCN 網絡劣化或中斷以及計算實例負載上升均會影響連接質量。雖然算力上報機制可以監控實例狀態，但慢周期上報機制在 DCN 網絡故障或性能下降時會導致算力重路由延遲，形成路由黑洞。算網 SLA 一致性驗證缺失：IGW 基于服務標識的算力路由表難以確保算網聯合服務達到 SLA 要求。為解決此問題，需要實時 OAM 檢測以動態調整路由策略，但現有電信級 OAM 技術無法直接支持算力路由級別的監

37、測。用戶體驗保障難題：算力服務訪問依賴流親和表轉發至計算實例。流量增加會使實例處理延遲加劇，影響用戶體驗?，F有電信級 OAM 技術缺乏針對流級別的精準監測與動態路徑優化能力，難以保證終端用戶的一致體驗。故障排查困難：當業務端到端業務會話質量下降時，需要從運維層面判斷問題源自網絡還是計算資源。如果問題是計算資源導致的，需進一步定位具體環節。盡管當前網絡側 OAM 技術已相對成熟，但尚未延伸至計算實例節點監控，加之算力領域缺乏統一的 OAM 標準，在構建以網為中心的算力網絡時，確保算網服務質量和實現高效運維成為兩大關鍵挑戰。為應對這些挑戰，需要將網絡域 OAM 的專業知識擴展至計算資源狀態分析，同

38、時優化資源分配與應用部署，并從用戶角度出發確保服務健康及性能。通過AI-OPS 和大數據分析等先進技術的融合，可以提升 IT 服務的可靠性、性能及用戶體驗，實現基礎架構健康監控與問題的快速定位。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 13 頁3.3 網絡能力和業務需求協同3.3.1 未來 IP 網絡中業務和網絡協同第一階段第一階段無無 QoSQoS 保障的業網分離工作模式：保障的業網分離工作模式：在過去 10 多年中，互聯網業務的快速發展主要歸功于“以業務為中心”的網絡設計理念，業務開發和設計不用過多考慮底層承載網絡的約束條件。因而互聯

39、網業務發展的第一階段，以 IP 為中心的網絡架構便設計成業務層邏輯和網絡層傳輸是解耦的，因此各種業務數據流得以無差別的在一個標準的底層網絡通道中進行傳輸，如圖 5 所示：圖 5 傳統互聯網基于“盡力而為”的無差別傳輸服務大多數業務都是以 OTT（over-the-top）形式運行，OTT+互聯網的組合推動了互聯網電子業務的初期的蓬勃發展。第二階段第二階段-OverlayOverlay 網絡支持基于內容的差異化傳輸工作模式：網絡支持基于內容的差異化傳輸工作模式：在互聯網業務發展的第一階段中，IP 承載網雖然支持多樣化的業務數據傳輸，但是無法提供針對特定 QoS 業務和用戶分類的數據傳輸保障。因此

40、，在互聯網業務發展的第二階段，對于傳統業務 QoS/QoE 的保障，一般使用應用層優化冗余機制，如傳輸協議的優化，或者疊加應用層網絡（overlay），以及專線等方式來進行業務支撐（CDN,RTN,QUIC 是overlay 解決方案的經典代表），如圖 6 所示。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 14 頁圖 6 overlay 應用層和專線提供差異化內容交付服務但從 underlay 承載網絡方面來看，當前流量輕載的現狀和專線業務，均意味著存量資源和服務成本還存在較大的挖掘空間。第三階段第三階段-基于業務感知的業網協同差異化網絡傳輸

41、工作模式：基于業務感知的業網協同差異化網絡傳輸工作模式：隨著未來更多類型業務的發展，一些應用服務都出現了基于業務特性的數據精細化傳輸需求。然而在目前的互聯網盡力而為的模式下，僅僅依靠應用層的各種補償方案，沒有相關的網絡資源的配合，是無法徹底的解決差異化服務問題的。因此在互聯網業務第三階段的發展方向上，這類有別于傳統意義上的非 OTT 業務則是對于業務和網絡的協同工作提出了需求。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 15 頁圖 7 業網協同功能協同模式為應用層提供匹配業務特征和傳輸需求的差異化網絡服務如圖 7 所示，支持非 OTT 業務

42、的業網協同控制層架構在核心設計上包含了一個能夠感知用戶業務需求，同時能感知網絡資源狀態的可運營的中間層設計。此中間層可以為上層的應用層提供可運營的網絡層的業務，同時也能為網絡層傳遞提供符合用戶業務需求特征的業務控制指令，以便網絡層能夠理解并轉化為控制網絡資源和傳輸策略的傳輸控制指令，實現對業務的精細化控制，從而將傳統的“盡力而為”的管道型互聯網轉變為“智能化”的業務感知型傳輸網絡。因此，具有業網協同功能的增強性業務控制層可以更好的服務于多種對于端到端的網絡連接和內容傳輸具有定制化要求的應用場景，例如要求極低延時的工業控制服務場景，要求帶寬保障的全息通信服務場景，以及要求具有即時性，安全性和零丟

43、包的數據快遞服務場景等等。同時，業網協同在應用于上述場景也催生出了應用和業務需求感知，具有增值服務的網絡連接控制，業網一體化的安全保障等等新的網絡能力演進需求。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 16 頁3.3.2 業網協同應用場景3.3.2.1 支持確定性業務的業網協同應用場景確定性的業務由于自身業務的特性需求對于數據傳輸的 QoS/QoE 都有一些定制化的SLA 等級保障。例如，在面向全景高清音視頻媒體流傳輸的場景下對于帶寬保障的需求，對于一些實時雙向互動要求比較高的業務場景，例如云游戲，則是對時延有限制需求。而在實時的工業控制上

44、，則對于時延和丟包都有著極度嚴格的上下邊界閾值要求。因此，確定性的業務的核心訴求是需要網絡在傳輸此類業務流數據時嚴格遵守業務提出的定制化約束條件。業網協同功能在這一場景中需要實現的能力至少應包括業務的感知能力，其中業務感知包括了能夠感知業務流的類型，具體的 SLA 約束參數以及現有網絡能夠提供服務的能力、資源的匹配等。3 3.3.2.2 支持增值型連接業務的業網應用場景除了應用于數據傳輸上的確定性業務場景之外，為了保障業務的質量，業務運營方對于業務的連接管控也存在一些差異化的需求。例如一些對于特定業務的訪問需要提供業務隔離的 VPN 隧道服務，對業務覆蓋區域不同的場景可以提供具有地域廣度的單播

45、/組播切換服務，一些特殊應用可以提供固移融合的雙通道接入服務，對于服務連續性要求比較高的場景可以提供具有故障秒級切換的自愈網絡保障服務，以及能夠針對有計算能力要求較高的服務場景提供計算服務的算力網絡資源使用服務。因此，業網協同功能在這一場景中需要能夠為不同應用和用戶的業務連接提供增值性的連接服務，即同一對節點間不僅僅為寬帶用戶提供基礎的“盡力而為”網絡連接能力，還可提供可運營的低延時、大帶寬、確定性、安全加密、VPN 連通等不同特性的增值性業務連接和管控能力，從而支撐可運營的多種連接業務模式，并能夠對應用層業務進行能力開放和IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊

46、版權所有未經許可不得擴散第 17 頁使用。業網協同增強層的設計在這一場景中至少需要實現對于網絡資源的按需編排以及對于定制化業務連接需求在網絡層面上的調度和控制能力，以便將業務數據按需引導入不同的轉發通道中。3.3.2.3 網絡支持業務安全的業網協同應用場景在傳統的互聯網服務形態上，對于業務的安全保障，由于存在業務和網絡解耦的現狀，因此對于業務的安全保障和網絡的安全保障也是相對解耦的狀態。業務層的安全保障機制無法確保在數據傳輸過程中得到相應的保障，也無法直接控制網絡層的安全策略。業網協同在這一場景中需要能夠將業務層的安全認證機制和安全需求結合網絡層的安全保障機制進行協同，可以將網絡安全服務能力和

47、業務安全服務能力結合后為上層應用提供一個 E2E 的網絡連接安全服務，在諸如智能電網，智能遠程醫療的應用場景下，構筑業務和網絡的協同的安全鏈接，利用網絡的內生安全機制，形成單點登錄，零信任安全架構體系，數據加密等綜合安全保護方案等。業網協同功能這一場景中至少需要實現對于業務層安全需求的感知和網絡層安全機制的匹配，并能夠將安全保障策略在業務層和網絡層實現一體化的配置，減少冗余安全處理流程。3.3.3 業網協同功能的設計需求上一章節描述了應用業網協同增強能力層的三個應用場景，根據對于應用場景中的需求總結，可以將具體的需求細化如下：1 1、網絡感知業務需求、網絡感知業務需求業務感知是業務和網絡協同工

48、作的關鍵能力之一，它包含了業務類型感知和業務需求感IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 18 頁知兩個方面。在業務類型感知方面，業網協同功能需要能夠按業務應用分類分級的要求，精確識別不同應用產生的不同類別特征的流量數據，并能夠對于不同的流量進行標識化的管理。在業務需求感知方面，業網協同功能需要能夠深入理解不同業務對網絡承載的具體需求，如確定性傳輸需求、低時延傳輸需求和大帶寬傳輸需求等。這些需求可以通過時延、帶寬、抖動、丟包、亂序等指標的上下界來量化描述。業網協同功能應該能夠根據這些需求指標，動態、智能地適配業務需求和網絡資源，通過全程全

49、網統一的標識體系和規劃，使用統一的精細化標記來攜帶應用信息、租戶信息和業務意圖信息等。通過貫穿終端、網絡、應用的算力資源和存儲資源以及各類操作系統的端到端資源配合，實現算網業務端、網、算、存的一體化調度和確定性和差異化保障。2 2、網絡、網絡資源匹配資源匹配業務需求業務需求業網協同功能需要能夠通過與 Underlay 承載網絡之間的交互可以獲得資源感知或預占能力。通過獲取承載網的性能和資源情況從而提供業務需求和網絡資源的精確匹配，并且根據用戶的業務狀態和當前網絡狀態按需實時為需要通訊的終端建立連接會話，生成網絡能力組合和業務能力組合，對滿足 SLA 要求所需要的網絡資源量進行系統性的編排。3

50、3、業務協同的運營調度和管理需求、業務協同的運營調度和管理需求業網協同功能需要提供標準業務承載模型，將具有相同需求屬性的業務統一納入管理，統一調配，并將業務流引導入相應的承載平面，確保業務的快速部署和高效運行。同時，并將業務流引導可以進行多維度的精細化計費，并需要在連接會話終止后，實時回收所分配的Underlay 資源。此外，業網協同功能可以實例化成一種具有網絡和業務協同工作能力的業務層，實現對網絡業務的開通、管控和精細調度能力，能夠提供對網絡業務的生命周期管理，對傳統網絡IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 19 頁連接的管理進行自

51、動化、智能化的升級和改造。4 4、業務層與傳輸層可信安全業務層與傳輸層可信安全協同需求協同需求業網協同功能需把業務應用的認證、信任關系傳遞到網絡傳輸層，實現業務與網絡安全互信。需提供靈活的用戶和業務策略管理功能，根據強大的準入機制，通過身份驗證、許可證管理和訪問控制等機制,確保只有經許可的業務和用戶能夠訪問到網絡。需要注意的是，不同的應用場景可能實現一個或者多個功能需求的組合。3.4 智算網絡端網協同3.4.1 網絡多路徑控制問題及需求隨著分布式存儲、高性能計算以及 AI 分布式機器學習場景的興起，這些新型業務場景對網絡時延、抖動以及吞吐性能極其敏感。為了盡量避免擁塞并優化流量轉發性能，由發送

52、端主導進行網絡路徑控制為業界的主流技術路線之一。網絡多路徑控制要求端側為業務流量選定滿足業務要求的路徑，并且在業務流量質量劣化時，需要及時對路徑進行切換?，F有現有方案存在如下問題：由端側探測路徑，進行路徑的精確發現和信息維護的方案中，通常由發送端主動發送探測報文，通過改變報文 TTL 值以及流量特征值（如源端口號等）實現網絡路徑的發現，形成發送端的路徑數據庫。但由于哈希沖突的存在，該種方式有可能導致對網絡路徑探測不全，此外當出現網絡鏈路變更時，無法及時獲取變更后的路徑信息?；诹髁刻卣髦岛途W絡側流量負載分擔算法，由端側對網絡上各設備選路進行模擬計算，從而得出相應流量的網絡路徑信息。該方案效率更

53、高，也能夠對網絡事件更快速的做出反應。但需要端側提前預知網絡設備轉發邏輯，并預置算法，端網耦合較緊密，且增加了端側計算資源的開銷和實現的復雜性。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 20 頁發揮端側和網絡側原生優勢，簡化路徑控制方案，是實現高效、低成本的網絡多路徑控制方案的可能路線之一，主要需求如下：明確端和網的能力邊界，利用網絡側較強的路徑探測和控制能力，滿足端側業務路徑需求，降低端側實現復雜度；提供端網交互標準接口，實現端網解耦，端網相對獨立，提升方案兼容性。3.4.2 擁塞控制問題及需求在 AI 網絡中，需要把網絡擁塞控制在一個極

54、低的水平，以最大程度降低端到端的時延和抖動，同時避免由于擁塞引發的丟包，以滿足極致性能和超高穩定的需求。擁塞控制技術由擁塞控制算法和擁塞信令機制兩部分組成。當前擁塞控制機制的問題在于：不同的擁塞控制算法一般需要不同類型的網絡擁塞指標信息，通常要求相應的擁塞信令機制進行匹配；不同算法對于網絡側需要反饋的擁塞指標信息的需求不一，也需要網絡支持不同檢測參數的組合。為了盡量避免定制化的解決方案，一方面部分的擁塞控制算法在設計之初就考慮對于支持多種擁塞信令，另一方面，網絡側的改進需求如下：擁塞信令支持的參數覆蓋主流擁塞控制算法的需求；網絡修改范圍盡可能小，避免整網的改動或升級。IP 網絡未來演進技術白皮

55、書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 21 頁4 SAN 整體架構及設計理念4.1 算網一體流量工程傳統網絡流量工程（Traffic Engineering,TE）旨在通過智能路由、負載均衡、延遲控制、擁塞預防、冗余設計、成本控制、安全增強及動態適應等策略，實現流量和路徑調優。其核心目標是優化網絡資源利用率與服務質量，以緩堵保暢，滿足不斷增長的網絡性能需求。圖 8 算網 TE 計算模型算網一體調度是將用戶業務請求匹配到合適的網絡路徑和計算實例，確保用戶體驗的同時，提升算網資源利用率，算網一體調度并提供服務的過程即為算網流量工程，如圖 8 所示，計算 IGW 到

56、服務標識 SID1 的最佳路徑和計算實例并執行業務請求引流即為算網 TE過程，算網一體 TE（Integrated Computing and Networking Traffic Engineering）進一步提升了網絡 TE 的能力，實現 TE 能力升維（圖 9）。它通過感知網絡和計算資源的狀態，實現計算和網絡資源以及業務請求的一體化控制與編排。這種集成化的方法能夠實現算力實例的優選，以及流量和路徑的精細調優，從而構建出高效、靈活且可擴展的算力網絡環境。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 22 頁圖 9 網絡流量工程和算網流量工程

57、4.1.1 算網一體 TE 三要素算網一體算網一體 TETE 通過擴展網絡 TE 的三要素，實現算網統一調度：資源管理：網絡 TE 的核心在于確保網絡符合業務需求的同時，實現網絡資源的有效利用。其中，關鍵在于資源策略需適應網絡的動態變化，如流量波動和資源可用性。算網TE 通過感知計算資源狀態，與網絡 TE 管理的資源相結合，綜合考量網絡帶寬、緩沖區和隊列狀態、丟包率和延遲等網絡參數，同時考慮處理時延和資源占用等計算度量，形成 TE-DB（Traffic Engineering Database）和 CA-DB（Compute AwarenessDatabase）兩大數據庫。這些數據庫為算網 T

58、E 決策提供關鍵感知數據集合和決策依據。路徑和實例計算：基于 TE-DB 和 CA-DB 的數據，算網 TE 能夠根據算網 SLA 要求，計算出當前網絡和計算資源狀態下滿足需求的網絡路徑和實例。這一過程充分考慮了計算和網絡資源的狀態信息，有效避免了算力網絡一體化服務中的性能反轉問題，確保滿足特定的服務訪問網絡質量（QoS）需求和帶寬要求。值得注意的是，所選路徑和實例不一定是網絡中的最短路徑。為了簡化算網一體計算的復雜度，計算度量信息可被折算成網絡同量綱，但這可能會帶來一定程度的信息失真，在某些特定場景下，這種模型IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經

59、許可不得擴散第 23 頁的選擇是必要的。路徑和實例引流：當前，以 SR-Policy 路徑為基礎，疊加切片（帶寬劃分）、確定性資源預留（確保抖動上界），并提供多種引流方式，是網絡基于 SR 體系提供服務（含算網）的主要方式。在傳統的 BSID、Color、DSCP 三種基本引流方式基礎上，算網一體 TE 還擴展了服務標識引流機制。利用服務標識，可以將業務精準引入對應的SR-Policy 和計算實例，實現算網需求的精準匹配?？偨Y而言，服務連接路徑和實例的計算和生成僅與感知到的網絡和計算狀態以及 SLA目標相關。通過引流機制，則解決了“誰”（即特定的目的 IP、路由前綴、包含 Service-ID

60、的 ANYCAST IP、五元組流或聚合流如 Service-ID）將使用這些路徑和實例的問題，實現路徑和實例生成與使用對象的完全解耦。4.1.2 算網一體 TE 轉控分離技術架構算網一體架構主要新增了算網計算組件(C-PS)、服務度量代理組件(C-SMA)、算力感知數據庫(CA-DB)，實現 IP 網絡從一維升級到二維的算力路由，并利用 SDN 轉控分離和可編程優勢，通過擴展 BGP 協議，融入算力信息，并支持算網計算組、服務度量代理組件、算力感知數據庫靈活部署，可以靈活適應感知方式和計算方式多種組合，實現集中式、分布式、混合式算力路由，根據業務和部署特點靈活選擇。IP 網絡未來演進技術白皮

61、書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 24 頁圖 10 集中式算力采集+分布式/集中式計算架構圖 11 分布式算力采集+分布式/集中式計算架構4.1.3 算網一體 TE 部署和應用演進算網一體 TE 部署和應用遵循循序漸進的原則，以降低對現有網絡的影響和侵入性?？傮w而言，可分為兩個演進階段：階段一：IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 25 頁面向尚未全面部署 SRv6（Segment Routing over IPv6）的網絡環境。在這一階段，通過在網絡的兩端增加算力路由網關，可以在不大幅改變現有網絡

62、架構的前提下，預先配置滿足特定需求的 SR-Policy?；谶@一策略，結合算力實例的狀態信息，進行聯合調度與計算，以確定符合要求的網絡路徑與計算資源。這種部署方式能夠初步構建算力網絡的原型，雖然在支持網絡路徑的粒度和差異化服務方面存在一定的局限性，但仍能滿足基礎的算力網絡需求。階段二：面向未來全面部署 SRv6 的網絡基礎設施。隨著網絡能力的顯著增強，特別是可編程性的大幅提升，算網 TE 將能夠基于逐跳（per-hop）和鏈路級別的信息，結合實時的算力實例狀態，進行更為精細的聯合計算。這一階段的目標是實現一次性計算出最優的計算實例，并創建相應的 Policy 以滿足特定的服務質量要求。這不僅

63、能夠提供高度靈活的差異化網絡路徑選擇，還能夠實現算力與網絡資源的深度融合與開放共享，為未來 6G 時代算網一體化的愿景奠定堅實的基礎。需要說明的是，無論是在階段一還是階段二中，變化僅體現在 TE（流量工程）計算模型上。服務標識作為引流的錨點，在轉發層面依舊沿用 Policy 的轉發模型進行引流與轉發操作?？傊?，在算網一體 TE 的演進過程中，從初步適應現有網絡環境到全面擁抱未來網絡技術的發展趨勢，每個階段都旨在逐步提升網絡的服務質量和資源利用效率，以滿足不斷變化的業務需求。4.2 SAN 核心設計理念基于算網一體流量工程的新型算網協同場景，服務感知網絡（service awarenessnet

64、work，SAN）采用基于服務標識的算網一體架構（見圖 12），將服務標識引入算網融IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 26 頁合與路由系統，構建了面向業務和算力的 IP 網絡新接口。該接口通過服務標識驅動，數據層面細化尋址與流量管理，控制層面關聯動態分配的算力資源與業務 SLA，形成了基于 IP分組網絡的服務感知子層（Overlay）。圖 12 服務感知網絡關鍵設計理念傳統分組數據網作為底層連接，為服務子層提供連接保障。服務子層與基礎架構的交互依賴于服務標識的控制面索引，以實現終端用戶與服務提供商的端到端高效交互。為了兼容現有設備并

65、處理數據傳輸，SAN 在網絡邊界引入服務感知網關。4.2.1 獨立語義服務標識SAN 引入獨立語義服務標識，其在用戶、業務、算力和網絡系統中扮演接口角色，對資源提供者和算網服務運營方而言，它是算網一體能力的承諾接口。服務標識由智能管控系統統一納管（含注冊/鑒權/校驗/發布/訂閱/策略配置），其生命周期涉及注冊、發布、策略下發、訂閱、服務請求（封裝）、服務路由、服務分發、服務更新、服務撤銷，這些流程都在運營系統的閉環治理流程中執行。服務標識擁有終端、網絡、云算全局語義，所有接口均以服務標識為中心索引。在不同算網管理區域間，服務標識的互操作可經過協商、映射，IP 網絡未來演進技術白皮書 4.0 _

66、服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 27 頁或標準化，取決于具體的部署和運營模式?；A服務通常會尋求跨域的標準化，而大部分服務標識治理則局限于單一管理域，則可以遵守服務標識企業標準。獨立語義服務標識有助于實現服務的發現、組合與重用，是構建可擴展、可互操作微服務架構的重要組成部分。(1)(1)服務標識在端、網、云的語義服務標識在端、網、云的語義在終端，服務標識是用戶對服務的請求接口。對用戶而言，無需關心服務提供方及其位置，甚至無需關心服務參數，訂閱服務并獲取服務標識，向 SAN 發起業務請求。在 SAN 網絡域，服務標識是算網 SLA 策略的唯一索引，也是網絡 UnderL

67、ay服務策略的映射標識。在云端，服務標識是云側服務調度和路由的對象。(2)(2)服務標識的設計原則：服務標識的設計原則：服務標識在終端、網絡、云端具有全局語義，以服務標識為中心無縫拉通業務、網絡和云算系統，實現算網深度融合；服務標識僅適用于基礎通用的服務類型。服務標識的語義空間不是全覆蓋，僅涵蓋復用率較高的共性服務類型；服務標識主要適用于對算網資源有高于“盡力而為”和“一般性計算處理”的服務類型，即 SAN 在 L3 層提供一體化算網統一服務；服務標識支持類型聚合。聚合式標識結構有利于索引和查表效率提升；服務標識可選支持同一應用下多種子業務的關聯和同步，以及同一子業務會話的上下行數據流；服務標

68、識可選支持業務功能鏈的語義設計；IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 28 頁服務標識可選支持用戶語義設計，以實現具體業務流量的精細化識別。(3)(3)服務標識的封裝：服務標識的封裝：主機側方案下的服務標識封裝。服務標識在 IPv6 擴展頭或 SAN 專用轉發頭中封裝，為兼容主流硬件的轉發架構，推薦標識長度為 32，64，128 比特；網絡側方案下的服務標識封裝。服務標識重用目的地址字段，即使用 IPv6 地址結構標識服務語義，通過特定前綴唯一表征服務標識并區別于普通 IPv6 地址。4.2.2 位置和歸屬無關通過歸屬無關協議接口和統一

69、服務命名體系實現泛在服務感知 IP 網絡的演進。這一設計理念的核心在于對于網和業務，解耦應用與服務的物理位置綁定，確保用戶能夠隨時隨地請求并獲取所需服務，服務標識語義本身無需關注服務提供者或其地理位置，后者將以服務標識關聯屬性和狀態的模式在網絡系統中運轉和維護。SAN 提出的泛在服務感知 IP 演進路徑包括以下關鍵要素：統一服務命名體系：引入邏輯標識符來表示服務，而非依賴于特定的 IP 地址或地理位置。這一命名體系允許智能控制面根據邏輯標識符自動解析服務的實際位置，并將請求導向正確的服務節點。歸屬無關協議：負責建立服務連接，并管理和維護基于服務的連接狀態。它提供面向服務的擁塞控制、移動性管理、

70、保序、多路徑/多歸屬以及內生安全等增強傳輸功能，使應用能夠直接調用協議接口請求服務。這一設計理念的核心優勢在于它提升了服務的可訪問性和移動性，優化了網絡資源的利用，并簡化了服務管理和運維，實現了無論服務提供者位置如何變化，用戶都能無縫訪問所需服務，資源分配根據實時需求動態調整，且通過邏輯標識符管理服務降低了管理復雜度。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 29 頁4.2.3 端到端服務基于服務標識的端到端設計理念通過解耦服務邏輯與實現細節，利用唯一標識符實現從用戶到服務源頭的無縫連接，極大提升了網絡架構的靈活性、可管理和可擴展性，使用

71、戶無需關注服務位置或網絡拓撲即可享受高效通信。服務標識在端到端服務和調度上呈現如下增強功能：打破網與云界限：通過服務標識作為統一索引，無縫連接網絡域與計算域，使網絡感知與調度超越傳統維度，不僅優化南北向用戶上云體驗，實現東西向 AI 訓練負載均衡調優，還能直連云內各子服務，強化 ServiceMesh 互聯下的服務通信安全與控制力，此舉簡化服務治理與運維，提升微服務架構的靈活性和可擴展性，提供全面可觀測性及追蹤能力，加速 DevOps 與 CI/CD 流程優化，顯著提高分布式系統的管理與運維效率。實現端與網絡協同：服務標識賦能網絡感知端側應用需求，確保精準匹配；同時，通過標識擴展網絡節點信息（

72、如出口隊列深度、端口狀態），反饋網絡擁塞情況至端側，實現動態調速與精準擁塞控制。4.2.4 數據面輕量化網絡提供面向服務標識的路由和尋址功能。在數據面上，服務使用方攜帶服務標識發起服務連接請求，服務提供方則基于服務標識進行服務的請求偵聽。網絡邊緣節點根據服務標識選擇最優服務目的節點，以及對網絡資源的編排，并執行對應的 SLA 策略。服務感知網關通過簡化的標識在報文中的傳遞，感知應用需求并為業務應用提供差異化的集成服務，減資源消耗，減輕數據處理壓力，節省網絡資源。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 30 頁SAN 提供兩種封裝服務標識的

73、方法：一是無主機變更的 Anycast IP，支持算網一體化，這種方法降低了對現有 IP 網絡和主機協議棧侵入性；二是 IP 擴展頭，支持算網一體化或差異化連接服務，該方法擴展性較好，可進一步支持端網協同能力。整體來說，SAN 通過智能化管理和靈活的標識策略，優化了服務交付和資源利用。服務標識在數據面的主要功能：應用及服務接入：攜帶服務標識的業務流量從服務終端傳輸到網絡中，完成應用及服務的接入的端網控制。服務層轉發路由：服務標識為索引進行標識路由調度，將業務流量調度到云算資源池或其他標識路由網關，以實現服務的轉發和交付。連接層 Underlay 路由：服務標識算力路由與傳統 underlay

74、路由解耦，是服務層與連接層交互的接口?；谶B接子層的路由功能，可在算力路由中實現各種增強型內生路由功能。4.2.5 控制面極簡化基于 IP 網絡的算力路由本質上是從一維升級到二維路由，理論上將導致乘數效應。SAN采用 SDN 的控制分離和可編程優勢，通過擴展 BGP 協議，在控制面融入算力信息，并擴展傳統 TE（traffic engineering）到算網 TE 以支持多種靈活的調度策略（算力優先、資源優先、體驗優先），支持分布式、集中式、混合式等算力路由方案，實現靈活的算力路由方案。服務標識在控制面的主要功能：服務注冊：應用和服務通過此接口向網絡或云計算資源池注冊，傳遞服務屬性，資源池據此

75、生成基于服務標識的注冊信息。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 31 頁服務訂閱/發布：連接控制管理單元與用戶終端，終端通過此接口發送服務訂閱請求。管理單元據此分配服務標識并回傳給終端，終端將其嵌入業務流量報文中。服務感知：1)控制管理單元與算網管理面間傳遞服務 SLA 需求，將需求與資源狀態映射至服務標識;2)算網管理面反饋服務屬性給控制管理單元，生成調度策略并與服務標識關聯;3)算網管理面與控制面（或網關）間傳遞匹配 SLA 需求的調度策略;4)在集中式架構中直接從云資源池獲取算力信息；分布式架構下，則通過出口網關獲取算力信息。

76、4.3 SAN 參考架構服務感知網絡架構的核心要素是引入了網絡層獨立語義服務標識，并以此為接口感知算力和業務，即網絡通過服務標識感知對應業務的算力狀態，同時通過服務標識感知業務類型及其算網需求，基于面向服務標識的多維感知，由指定網絡節點（如網絡入口節點和出口節點）執行相應的路由和引流。服務感知網絡僅需在特定網絡節點維護服務標識轉發表項，其他路徑節點可按普通流量轉發，無需識別服務標識，也無需維護狀態。因此，服務感知網絡是一種 OverLay 架構方案。相對此前系列白皮書，本文在經典南北向業務流量場景的基礎上，延伸覆蓋了數據中心內和數據中心間的東西向業務流量場景。相應的，服務感知網絡架構做了部分擴

77、展和增強。如圖 13 所示，服務標識依然是參考架構的核心功能要件，由于服務標識語義獨立于 IP 網絡既有的標識，如 IP 地址，端口號等，由擴展的服務標識轉發面和控制面構成了邏輯上的服務標識子層。南北向業務流量場景下，業務節點分別為客戶端設備和服務端設備，東西向業務流量場景下，業務節點延伸包含數據中心內的接入網關和代理網關。特別的，不同網絡管理域之間，可以通過統一的服務標識進行一致性互通，也可以是獨立標識體系，在域間執IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 32 頁行無損語義映射。圖 13 服務感知網絡參考架構4.4 SAN 與現有技術的

78、 GAP 分析4.4.1 基于 DNS 和 GSLB（全局負載均衡）服務調度模式當前云服務產商對于算力資源的調度，大都采用 overlay 方案，如圖 14 所示，通過服務域名(DNS)服務器解析為算力資源的 VIP 地址，同時采用統計學的方法對不同的 VIP進行網絡質量評估，選擇出一個滿足用戶需求的 IP 地址反饋給用戶，來實現算力服務資源池的選擇，這種方式存在如下幾方面的不足：DNS 地址在本地有緩存，當對應算力資源池或者網絡存在故障時，本地緩存來不及及時更新，導致流量丟失。服務首包通過 HTTP 連接到 DNS 服務器，當返回真實的算力資源 VIP 后，HTTP 重定向到真實的 IP 地

79、址，存在一定的首包時延，對于時延敏感性的業務，滿足不了客戶的要求。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 33 頁當前基于 DNS+GSLB 方式的調度，沒有充分考慮網絡和算力實時質量，當網絡質量或者算力質量出現劣化時，整體業務體驗出現明顯下滑，但是服務的資源池未能及時切換。圖 14 DNS+GSLB 的算力服務調度4.4.2 基于 ICN 的服務調度信息中心網絡（Information-Centric Networking,ICN）是一種創新的網絡架構，它將 網 絡 的 焦 點 從 傳 統 的 主 機 中 心（Host-Centric

80、）轉 移 到 了 信 息 中 心（Information-Centric）。這種轉變意味著網絡通信不再依賴于數據源或目的地的位置，而是依賴于數據內容本身。ICN 的設計理念主要是為了解決當前 TCP/IP 網絡面臨的一些挑戰，如路由可擴展性、數據動態性、信息安全可控性等。ICN 的關鍵特點包括內容與位置分離，發布/訂閱范式，內容命名與路由，內置緩存等。ICN 從架構上解決了移動性，服務調IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 34 頁度的失效性等問題，但是與 IP 網絡存在諸多不兼容。5 SAN 關鍵技術基于 SAN 設計理念和參考架構，

81、SAN 擴展增強網絡技術，研究了 HFC 混合功能鏈、FSP 靈活調度策略、FS-OAM 全棧算網 OAM、端到端網絡業務協同及基于統一標識的智能端網協同等關鍵技術，構建了 SAN 技術體系并研制了 SAN 樣機。5.1 HFC（Hybrid Function Chain）混合功能鏈5.1.1 HFC 技術特征與內涵伴隨著應用和服務愈來愈復雜和多樣化，一種對外服務中往往包含多個子服務協同及鏈式調度關系，而服務間互聯意味著業務流量將經由網絡通過多個服務端點。旨在為跨越多個服務端點和相應連接網絡的對外服務提供全程與端到端的一致性服務需求保障能力，本文定義了一種混合功能鏈（HFC，Hybrid Fu

82、nction Chain）技術架構?；旌瞎δ苕湥℉FC，Hybrid Function Chain）的特性主要包含：混合的服務功能類型與部署方式：基于部署態，服務與應用功能可以通過容器的形式部署在一個或多個集群，也可以基于虛機部署；服務與功能實例可以多實例部署，也可以基于 Serverless 架構動態申請與釋放?；谶\行態，微服務與單功能組成了多樣化的對外服務，相應的，微服務與單功能對資源側和網絡側也往往不同的需求。不同于傳統網絡領域服務功能鏈（SFC，Service Function Chain）中的服務都是是網絡服務功能，HFC 中面向的服務功能也包括應用服務?；旌系姆展δ荛g關系：服務

83、與應用功能之間連接、請求、交互與協同方法往往呈現出多種形態，上下游服務與應用功能或微服務之間的協同與連接方式是多樣化的，如單向IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 35 頁Notification 模式、雙向 Request-Response 模式，并且單個上游服務可能請求單個下游服務，也可能同時需要調用多個下游服務?；旌系乃憔W技術的應用：跨越多段連接網絡，經歷多個應用服務端點的 HFC 需要資源側和網絡側高度協同，技術?？缭綉煤途W絡層。5.1.2 HFC 系統架構如圖 15 所示，HFC 架構層次包括管理面、控制面和數據面。在以

84、Istio 系統層次和當前網絡業務組件為例的當前云網控制面基礎上，HFC 系統架構設計相應的補充與增量特性。在管理面中新增了服務分析和運營、服務和資源建模和服務編排和調度策略管理功能；在控制面中新增了服務注冊和注入、服務發現和發布、服務路由生成和服務基礎互聯功能；在數據面中新增了服務標識管理、服務感知的轉發和服務觀測和保障功能。圖 15 混合功能鏈（HFC，Hybrid Function Chain）架構IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 36 頁5.1.3 基于 SRv6 的 HFC 技術SRv6 技術作為新一代 IP 承載協議，基

85、于現有的 IPv6 轉發能力，通過靈活的 IPv6 擴展頭，實現網絡可編程。而基于 SRv6 的能力擴展，可以將 HFC 的端到端服務路徑信息、各服務感知網關 SID 信息或連接上下游服務的轉發路徑信息編碼在報文中，從而實現跨越多個服務端點和相應連接網絡的對外服務提供全程與端到端的一致性需求保障，并提供對應的算網流量工程與智能調度能力。根據在始發服務感知網關處直接封裝端到端服務路徑或僅封裝下一跳服務轉發路徑，可以將基于 SRv6 的 HFC 技術更具體地以緊耦合和松耦合的技術特征進行分類。5.2 FSP(Flexible Scheduling Policy)靈活調度策略5.2.1 支持多種約束

86、條件的 TE 計算基于 SAN-TE 統一算網調度架構，允許實現調度策略靈活選擇和部署，兼顧集中全局優化（跨越多個區域、連結算力與網絡）與快速收斂的分布式計算。SAN-TE 計算約束條件分為體驗優先（如延遲、抖動和丟包）、成本優先（資源消耗和能耗）和效率優先（如資源利用率、均衡性）三類，各自在系統設計和運營中發揮著關鍵作用：體驗優先：這類約束確保服務質量（QoS），重點關注用戶體驗的關鍵指標，如延遲、抖動和丟包率。在算網一體化環境中，延遲是指數據從源到目的地所需的時間；抖動關注延遲變化的穩定性；丟包則反映網絡傳輸的可靠性。通過優化這些指標，算網SAN-TE 致力于提供流暢、無中斷的服務體驗。成

87、本優先：成本優先約束關注資源消耗和能耗的最小化。在資源有限的情況下，高效利用計算和網絡資源對降低運營成本至關重要。此外，隨著綠色計算和可持續發展目標的IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 37 頁日益重要，能耗成為 SAN-TE 設計中的另一個重要考量。通過智能化調度和優化策略，SAN-TE 致力于在滿足服務需求的同時減少能源消耗和環境影響。效率優先：這一約束集中在提高資源利用率和系統均衡性上。資源利用率高意味著系統能夠更充分地利用現有資源，避免浪費；而均衡性則確保了系統負載分布均勻，防止局部過載導致的性能瓶頸。通過動態調整資源分配策

88、略和優化網絡流量管理，SAN-TE力求實現整體系統效率的最大化。綜上所述，體驗優先、成本優先和效率優先三類約束在 SAN-TE 中扮演著不可或缺的角色。它們不僅指導著系統的設計和優化方向，還直接關系到最終用戶的服務質量和運營商的經濟效益。在實際部署中，平衡這些約束之間的關系是一項挑戰，需要綜合考量業務需求、技術可行性和經濟成本等因素。5.2.2 業務調度和負載均衡技術從業務視角出發，根據調度觸發機制的不同，SAN-TE（SAN Traffic Engineering）的應用模型存在以下三種，其特點如下：周期調度：該調度方式并不依賴于實時的業務流請求來觸發。相反，它遵循預設的時間周期或特定事件（

89、例如算力狀態超出預設閾值）來自動執行。在這一機制下，算網 TE會定期或在事件觸發時計算面向特定服務標識的最優網絡路徑與計算實例，并將計算結果直接下發至轉發平面。當業務請求首次抵達入口算力網關時，系統會根據服務標識進行匹配。一旦匹配成功，將進一步觸發生成流親和表，確保后續所有相關報文能夠準確無誤地被路由至同一計算實例，從而實現高效的數據處理與資源利用。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 38 頁逐流調度：在逐流調度模式中，控制平面并不直接向轉發平面推送詳細的算網調度結果。相反，它僅下發服務標識表以識別特定的算力請求報文。當帶有服務標識的

90、業務請求進入算力網關時，報文會被上送至控制平面。隨后，控制平面會基于當前的算力狀態與網絡狀況，動態計算出最合適的路由路徑或匹配已有的、符合需求的算力資源分配方案。計算完成后，相應的流親和表將被生成并下發至轉發平面，確保后續同一業務流的所有報文都能被導向至同一計算實例進行處理，以實現精準的業務流親和與資源優化分配?；旌险{度：在同一個支持多種服務的算網調度系統中，根據業務特點不同，基于服務標識定制調度方式，根據調度方式配置來靈活選擇周期調度或逐流調度。通過智能化的路徑計算與資源分配策略，提升算力網絡的服務質量和效率?；谝陨先N調度策略，SAN 汲取了多種模式的優勢，還創新性地引入了一種全新的負載

91、均衡機制。這一機制旨在緩解 TE 計算帶來的局限性。其主要特點包括：控制面 TE 計算：通過一次 TE 計算，系統能夠自入口網關至所有滿足算網 SLA（服務等級協議）要求的服務實例及其可達路徑進行編排，并計算出相應的分擔比例。這些信息被整合進算力路由表中，形成了一系列可行的下一跳選項。轉發面 TE 轉發：利用首包報文中的五元組或三元組 HASH 值確定多下下一跳路由表中唯一下一跳并引流和轉發。這一過程同時確保了同一會話流中所有后續報文的連續性和一致性，實現了算力網絡服務請求在會話級別上的精準負載均衡并大大降低控制面負載。通過結合這一負載均衡機制與多種調度模式靈活組合，SAN 不僅保障了用戶會話

92、質量達到算網 SLA 的要求，還實現了算網資源的細粒度均衡利用。具體而言，在連續兩次更新算力路由表的時間周期內，它有效避免了單一計算或網絡資源因過度占用而導致的“極化”IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 39 頁現象。同時，該機制顯著減少了因算力實例狀態頻繁變動對控制面造成的額外壓力，從而確保了系統的穩定性和效率?？傊?，在提升用戶體驗的同時優化資源分配是 SAN 的核心目標之一。通過智能調度策略和負載均衡技術的應用，SAN 有效地避免了資源過度集中或分散所帶來的問題，在算網環境中展現出強大的適應性和高效性。5.3 FS-OAM(Fu

93、ll-Stack OAM)全棧算網 OAM5.3.1 網絡和計算可觀測現狀可觀測性是指對監控對象的狀態、性能指標和事件的監控、測量、追蹤和分析的能力。隨著云計算、大數據以及 AI 技術和應用的迅猛發展，數據中心作為支撐各類關鍵業務運行的基礎設施，其規模的快速發展帶來了網絡規模的顯著擴大，網絡架構日趨復雜。在這種背景下，可觀測性變得尤為重要，它不僅關系到故障的快速發現、定位、和修復，也關系到性能優化，更直接影響到業務的連續性和服務質量。5.3.2 FS-OAM 關鍵目標和技術傳統的網絡側與計算側可觀測性技術長期以來獨立發展，互不兼容，缺乏必要的互操作性。面對日益顯著的算力與網絡融合趨勢，構建一個

94、全面覆蓋、端到端的監測體系成為迫切需求。為此，整合網絡域和計算域的運維管理（OAM）能力顯得至關重要。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 40 頁圖 16 算網 OAM 需求和目標SAN 提出 FS-OAM(Full-Stack OAM)全棧算網 OAM,主要包括檢測連通性故障、丟包、時延等指標，還包括新定義的算側指標（連接數、資源占用等），并可以逐段、逐層覆蓋，特別關注從算力網關到計算實例的性能監測與優化，支持快速的路由收斂機制和業務質量保障。同時，它還具備強大的故障定位能力，以及高度的實用性和可擴展性。如圖16 所示，當前算網一體

95、存在四類關鍵需求：需求 1-加速算網控制面收斂：為快速響應計算實例狀態的變化，當前控制面感知機制在處理速度上存在局限，難以跟上算力實例狀態的迅速變動。因此，亟需在數據平面實現快速監測功能，對出口算力網關到算力實例端到端狀態進行實時監控。一旦檢測到故障或性能劣化，將立即觸發算網流量工程（TE）的計算收斂機制，采取行動避免服務黑洞現象，確保資源的有效利用與快速恢復。需求 2-算網 SLA 評估閉環保障：為了確保服務等級協議（SLA）得到持續滿足，有必要從算力路由表中提取與網絡到計算實例路徑相關的測量數據。通過 TE 計算得出的算力路由信息需經過驗證，確認其是否符合既定的算網 SLA 標準。IP 網

96、絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 41 頁需求 3-業務流 SLA 閉環保障：服務訪問激活后，后續數據包通過流親和表轉發至同一計算實例，期間計算與網絡性能可能波動。為確保穩定高質量的用戶體驗，需持續監控從網關到實例的業務流性能。依據算網 SLA 要求，在網絡層適時進行修復或調整，以維持服務穩定可靠。需求 4-業務故障定界和排障：當用戶體驗下降時，迅速準確定位問題是關鍵。這需要快速識別從用戶終端到計算實例全路徑上的故障點。傳統 OAM 技術僅限于傳輸層監控，應擴展至應用層以實現全面監控，并據此進行端到端的故障定位與排除。增強的OAM 機制能

97、更精準地識別故障源頭，縮短恢復時間并提升服務質量。FS-OAM 面向算網一體四大類需求提出綜合解決方案，主要包括以下三個技術層面：1.針對需求 1 和 2，FS-OAM 分別提出算網實例 OAM 和算力路由級 OAM，相應的技術考慮如下：檢測協議的選擇與應用檢測協議的選擇與應用：可選用 PING、TWAMP、OWAMP、STAMP 等協議或其組合進行網絡到計算節點健康狀況檢測，建議優先采用反射型策略以提高檢測效率和準確性。檢測協議部署檢測協議部署：除了支持網絡側部署，在算側支持上述檢測協議的部署與運行，確保能夠實時監測并及時響應各種變化和需求。檢測新能力拓展檢測新能力拓展：為了全面覆蓋算力網絡

98、的獨特指標，應積極探索并引入新型檢測協議，確保能夠準確評估計算資源的狀態和性能。2.針對需求 3，FS-OAM 提出算力會話級 OAM，相應的技術考慮如下：IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 42 頁檢測協議的選擇與應用檢測協議的選擇與應用：為確保全面覆蓋真實的業務流并獲取精確的數據分析，我們應充分考慮采用隨流檢測技術，如 IOAM、IFA 等。檢測協議部署檢測協議部署：在算力網絡中，從網關入口至計算實例的整個傳輸路徑上，推薦網絡節點和計算實例部署。檢測新能力拓展檢測新能力拓展：擴展覆蓋算力網絡的獨特指標，比如計算時延、負載等增量信息

99、。3.針對需求 4，FS-OAM 提出應用級 OAM，相應的技術考慮如下：檢測協議的選擇與應用檢測協議的選擇與應用：存在兩種路線（1）為了實現高效且低開銷的端到端業務性能監測，可基于創新的輕量級端側協議棧利用探針機制，確保對業務流程進行全面而精準的追蹤與分析；（2）在跨端、網、云的環境中，采用隨流檢測技術延伸到算側，實現對傳輸業務的更加精細化監控定界。檢測新能力拓展檢測新能力拓展：將云內可觀測性與網絡隨流檢測緊密結合，具體措施是在隨流檢測頭部攜帶 TraceID 和 SPAN ID,結合 eBPF 將助力我們實現從用戶終端到云端應用層的全程性能評估與故障定位，有效提升運維效率及用戶體驗?？傊?，

100、FS-OAM 延伸到算側并定義的四個層次（實例級、表項級、業務流級、應用級）和關鍵技術，特別說明的是，應用級 OAM 不僅打通了網絡和算側，還實現網絡 OAM 和eBPF、分布式追蹤技術結合，實現端到端業務故障快速定界，實現算力網絡“懸絲診脈”，解決未來算網一體化運維的關鍵痛點。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 43 頁5.4 端到端網絡業務協同服務系統5.4.1 基于 SAN 的增強型業務控制層具有業網協同能力的業務控制層是一種具能感知應用需求并針對現有網絡資源進行資源編排的增強性業務控制中間層系統，基于此層能實現多種網絡服務能

101、力對上層應用的開放。在本文中，基于業網協同工作域中最核心的業務感知能力，本章節通過綜合上述業網協同功能層的核心能力與上下游系統的關系，展示了一種融合了 SAN 功能組件的增強型業務控制功能系統框架方案，如圖 17 所示：圖 17 融合 SAN 的業網協同層的功能框架如圖所示，整個業網協同功能層的邏輯功能架構需要有兩個子功能單元合作完成，包括了應用支持和業務使能功能（服務使能層），以及業務控制功能（業務控制層），并配合底層 SAN 網絡通過統一的服務標識完成端到端的差異化數據轉發保障服務。如圖 18 所示：IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴

102、散第 44 頁圖 18 業網協同功能層和 SAN 網絡的系統工作模式業網協同功能層和 SAN 網絡的協同過程中，SAN 網絡系統需要將其服務能力通過業務控制組件的方式注冊到業網協同功能層的業務控制單元中，并通過業網協同功能層的南向接口提供其可以調用的 SAN 服務標識（統一服務標識）。對于具有不同傳輸需求的業務流分類分級，通過對于需求的感知來確定需要提供 SAN 服務的業務流，并調用 SAN 服務組件來提供傳輸的保障服務。業網協同功能根據用戶的簽約信息和 SLA 需求來為用戶匹配合適的接入節點，在建立業務控制會話的過程中維護用戶信息，并提供增強性的傳輸協議，利用SAN 網絡的服務標識來確保數據

103、傳輸過程中對應業務流的數據包的轉發可以按照既定的轉發策略來進行轉發控制，為用戶提供差異化的數據傳輸服務。5.4.2 業網協同功能層的接口需求業網協同功能層需要實現兩類外部接口：與業務應用的接口-北向接口北向接口是網絡提供商提供給上層業務應用的一種網絡服務能力感知和調用的網絡業務 API 接口。通過該接口，上層應用可以發現并選擇訂購某一類網絡服務，并且可以通過IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 45 頁該接口將業務所需的網絡連接和數據傳輸需求通知到業網協同功能，進而可以對可用的網絡資源和能力進行調用或者預留。業網協同功能需用能夠提供一

104、些屬性來描述業務，定義業務的具體性能和參數。這些參數主要包括諸如業務類型，業務狀態，業務問題等等可以對業務進行分類分級的因素。該接口需要針對業網協同增強控制層設計新的應用接口 API，并需要提供通用化的業務描述信息格式。與傳輸層的接口-南向接口南向接口是用于業網協同功能層將業務需求對應的控制信息，通過相應的業務控制組件調用并下發給下層的承載網絡，包括網絡資源調用策略，業務流傳輸策略，安全管控策略等，完成對于業務邏輯控制和傳輸資源匹配調用的功能。該接口可以通過擴展現有的業務控制功能和網絡傳輸控制功能之間的接口實現。5.5 基于統一標識的智算端網協同5.5.1 基于統一標識的智算端網協同架構基于統

105、一標識的智算端網協同總體架構如圖 19，其中：IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 46 頁圖 19 基于統一標識的智算端網協同總體架構服務管理平臺服務管理平臺：維護業務流量特征和服務需求信息，在引入新的業務流量或服務需求后，需要向服務管理平臺進行注冊。管控系統管控系統：納管服務器和網絡設備，感知網絡側服務提供能力。通過北向接口從服務管理平臺獲取業務流量特征和相應服務需求，并為服務需求分配服務標識。通過南向接口基于服務標識進行分別在端網進行規劃配置，以滿足相應的服務需求。網絡設備網絡設備：網絡接入設備接收管控系統下發的基于服務標識的報文

106、處理策略，識別服務標識對于業務報文進行處理。服務器：服務器：服務器網卡根據管控系統配置，在發出業務報文時，攜帶相應服務標識。5.5.2 基于統一標識的多路徑控制管控系統根據不同的路徑質量需求，在網絡側基于不同服務標識進行具體的路徑規劃和控制策略下發。網卡根據業務對于質量保障需求，在資源池中選擇相應服務標識進行封裝。網絡接入側設備識別接收報文中的服務標識，將業務流量引入到相應路徑。網絡側包括負載均衡方式，精確轉發路徑等詳細內部信息，均對端側屏蔽。在網絡拓撲、鏈路、配置等發生改變后，管控系統基于最新的網絡狀態，對各服務標識對應的路徑進行重新調整和規劃，在端側不感知的前提下，維持網絡對外的服務保障能

107、力。通過統一標識傳遞端側路徑控制需求，滿足了端網解耦需求，由網絡側基于需求標識進行路徑控制，發揮網絡側原生優勢，也降低了端側的復雜度和方案部署成本。5.5.3 基于統一標識的擁塞控制參數適配面對端側不同的擁塞控制算法的需要網絡反饋的擁塞指標參數需求，管控系統基于端側需求和網絡側的對于各擁塞指標的檢測能力進行提前匹配，為不同的參數組合需求分配服務IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 47 頁標識。網卡根據自身對于擁塞指標參數的需求，選擇服務標識，封裝在用于擁塞檢測的報文中。網絡接入側設備負責識別標識，并根據管控系統預先下發的服務標識與網

108、絡參數需求的映射關系，將網絡實際需反饋的相應字段寫入擁塞檢測信令中傳遞，以完成擁塞指標的收集。通過統一標識在網絡接入側設備完成參數轉換的方式，提升了網絡側對不同擁塞控制算法的兼容性，也滿足了控制網側關聯設備范圍的需求。6 SAN 樣機及測試總結6.1 SAN 算力路由樣機試點圖 20 SAN 樣機實踐歷程圍繞 SAN 的關鍵理念和技術，中興通訊展開了一系列樣機開發和試點測試項目。如圖20 所示，宏觀來看，分為三個階段：第一階段（2021 年）：這是 SAN 技術旅程的起點，我們主要專注于算力路由領域的關鍵技術原始積累，成功地實現了算力路由行業的早期原型開發與驗證工作。這一階段標志著 SAN 技

109、術的萌芽。第二階段（20222023 年）：基于 SAN 的核心原則獨立語義服務標識，我們深入探索并構建了集中式算力路由樣機。在這一階段的技術演進中，“算網聯合感知”、“算網一體資源效率提升”成為 SAN 1.0 的關鍵標簽；而 SAN 2.0 則進一步拓展至“算網端到IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 48 頁端 SLA 保障”、“算網資源均衡”、“層次化路由”與“多種調度策略”（涵蓋體驗類與資源類調度）。我們的努力獲得了業界的高度認可，在 2022 年 8 月 1 日的首屆算力大會上榮獲“創新先鋒”獎，并在 2023 年 5 月的

110、云網智聯大會上摘得“最佳實踐案例”獎。此外，在 2024 年 2 月 26 日的世界移動通信大會（巴塞羅那展）上，中國移動與中興通訊聯合發布了全球首臺算力路由器。第三階段（自 2024 年起）：遵循 SAN 的全量設計原則，我們正致力于研發集成了集中式、分布式與混合式架構的算力路由樣機。一方面，我們積極參與由中國移動牽頭制定的互通標準，旨在促進不同網絡之間的協作與融合；另一方面，我們也在積極拓展業務場景，探索算力路由技術在更廣泛領域的應用潛力，以期最大化其商業價值。未來的發展令人期待，我們相信這一領域的創新將不斷推動行業向前發展。中興通訊與中國移動攜手，在算力網絡領域開展深度合作。通過創新的算

111、力路由機制和隨流調度算法，實現了服務標識驅動的資源優化配置，顯著提高了業務響應速度與轉發效率。引入資源動態感知機制與多策略協同框架，有效提升了算網資源利用率和業務承載能力。借助 SAN1.0 與 SAN2.0 樣機，雙方成功將現網設備升級為算力路由網關。特別是在 2024年 8 月江蘇的 CDN+算力路由試點項目中，基于獨立現網 CDN 資源的 SAN2.0 驗證了集中式算力路由方案的關鍵技術和預期效果。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 49 頁圖 21 SAN2.0 樣機試點組網和目標測試環境介紹：本次測試方案及環境部署如圖 2

112、1 所示，在無錫、蘇州、徐州三地協同，其中無錫到蘇州和徐州兩個方向，分別部署 2 條 10GE 傳輸專線，蘇州和無錫分別對接獨立的 CDN 資源服務器，用戶從無錫發起 CDN 業務訪問。測試結論：業務自愈能力：在網絡質量下降的情況下，系統自動觸發自愈機制。具體表現為：當檢測到網絡劣化時，用戶的操作將重新發起鏈路建立請求。此時，新會話會被智能調度至其他可用的 CDN 節點，確保視頻播放過程不受影響，維持流暢體驗。資源利用效率顯著提升：通過優化調度策略和資源分配算法，實現了對更多用戶訪問需求的有效保障，尤其是在保證用戶體驗的前提下。直接促進了 CDN 資源利用率的躍升，相較于無算力路由提升了 35

113、%以上。DNS 解析效率優化：針對 DNS 解析這一關鍵環節進行了深度優化，成功將平均解析時間縮短約 30 毫秒，大幅減少了用戶等待時間。綜上所述，本次試點項目的結果完全符合預期目標：不僅顯著降低了廣域網服務響應時延，極大改善了終端用戶的實際體驗；同時，在算網感知技術的有力支撐下，實現了算網資IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 50 頁源利用率、利用率均衡度以及業務承載量的顯著提升。這些成果充分驗證了方案的有效性和先進性。6.2 SAN 服務治理測試驗證如果說在以 Kubernetes 為基礎構建起的云原生世界里，哪種設計模式最為經典

114、，Sidecar 模式無疑是其中最有力的競爭者。當需要為應用提供與自身邏輯無關的輔助功能時，在應用 Pod 內注入對應功能的 Sidecar 顯然是最 Kubernetes Native 的方式，主要實現手段則是通過在應用旁部署一個 Proxy，在 Kubernetes 場景下則為應用 Pod 注入Sidecar，攔截應用流量至 Sidecar。Sidecar 根據獲取的用戶配置對應用流量進行處理，以一種對應用代碼幾乎無侵入的方式實現了服務治理。而隨著 Service Mesh 的落地規模不斷擴大，傳統 Sidecar 模式在云原生環境中的諸多挑戰，如侵入性、資源利用率低及生命周期綁定等問題。

115、針對以上缺陷，Sidecar-less 成為業界關注的焦點，而在其中 Ambient Mesh 已成為一個重要的方向，Ambient Mesh 實現了對應用的零侵入和獨立演進，同時優化了資源占用，提高了整體性能。隨著 Istio 社區對 Ambient Mesh 的持續投入和實驗特性的逐步穩定，這一模式有望在未來成為云原生服務治理的重要選擇，推動大規模生產環境的網格技術落地。然而，值得注意的是，盡管 Ambient Mesh 在性能上有所突破，但它目前仍然依賴于基于 L4/L7 的代理機制來實現多級服務之間的互聯。在跨域多級服務互聯的場景中，這種機制可能會暴露出性能上的局限性。具體來說，隨著服

116、務層級的增加和跨域通信的復雜化，基于 L4/L7 的代理機制在處理多級服務互聯時，每一級的代理都會引入額外的開銷，這些開銷會累積并呈現倍數增長的關系。這不僅會增加網絡延遲，還可能對整體服務的性能和穩定性產生不利影響。IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 51 頁SAN 不僅能實時根據算力（服務負荷、算力資源利用等）和網絡（網絡拓撲、鏈路狀態、帶寬使用情況等）關鍵信息進行綜合調度，實現高效、穩定地連接不同資源池的云網絡。同時與 Ambient Mesh 模式相比，SAN 在跨資源池服務互聯時，減少了兩次 Socket 連接和兩次 L7

117、代理處理，直接提升了服務請求的響應速度，使網絡運行更加高效。這一改進不僅增強了云網絡服務的靈活性，還提高了系統的穩定性，為用戶提供了更加可靠的服務體驗?；谝陨纤悸?，對集成 SAN 的云網絡跨資源池服務互聯方案進行了評估，并與 Istio的 Ambient 模式和 Sidecar 模式進行比較，具體說明如下：對于集成 SAN 的云網絡跨資源池服務互聯方案測試，測試環境包含三個云集群，其中每個云集群由一個主節點和三個工作節點組成，每個節點都運行著 Ubuntu 20.04 系統，并配置了 8 核 CPU、16GB 內存以及 30GB 硬盤存儲資源。對于 Istio 的 Ambient 模式的測試

118、，測試環境同樣包含三個云集群，其中每個云集群由一個主節點和三個工作節點組成，每個節點都運行著 Ubuntu 20.04 系統，并配置了 8 核CPU、16GB 內存以及 30GB 硬盤存儲資源。同時，云集群還配置了 Istio 的 Ambient 模式。Isito 的 Sidecar 模式測試環境與 Ambient 模式測試環境類似，區別是云集群配置的是Istio 的 Sidecar 模式。在 SAN 集成方案測試過程中，我們在 SAN 方案測試每個集群的其中一個節點中部署了具有明確順序依賴關系的子服務，每個子服務在任務完成后會將結果返回至子服務請求方，服務時間不計入統計。在 Cloud A

119、中，我們還部署了入口網關用于傳遞用戶請求，其中入口網關與子服務部署在不同節點上。測試的請求傳遞與結果返回過程如圖 22 所示。測試節點（User）首先借助 Cloud A 中 Node A 的 Ztunnel 代理向 Cloud A 的入口網關發起請求。隨后，請求根據路由規則按照既定的順序經過 SAN 網關和其他 Ztunnel 代理依次傳遞給 Cloud A 的 Service1、Cloud B 的 Service2 和 Cloud C 的 Service3。每個服務在接IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 52 頁收到請求后，都會完

120、成其分配的任務，并將請求結果按原路徑返回。圖 22 集成 SAN 的服務互聯測試方案在 Istio 的 Ambient 模式測試過程中，我們在三個云集群中分別部署了入口網關、出口網關與 SAN 測試過程中相同的子服務，同樣對服務時間不計入統計，其中子服務被部署到與入口網關和出口網關不同的節點上。測試的請求傳遞與結果返回過程如圖 23 所示，用戶測試節點（User）通過 Cloud A 中 Node A 的 Ztunnel 代理向該云集群的入口網關發出請求。隨后，根據預先配置好的路由規則依次經過其他節點的服務和代理與各個云集群的入口網關和出口網關最終完成用戶的服務請求，并將請求結果按原路徑返回。

121、Istio 的 Sidecar模式測試如圖 24 所示，其過程與 Ambient 模式的測試相似，這里不再贅述。圖 23 Istio 的 Ambient 模式服務互聯測試方案IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 53 頁圖 24 Istio 的 Sidecar 模式服務互聯測試方案我們在每次測試過程中通過用戶節點順序發送了 5000 次的服務請求。圖 25 為各方案中測試過程服務完成時延分布圖?？梢钥闯?，集成 SAN 方案的整體性能要明顯高于 Istio的 Ambient 模式和 Sidecar 模式。如圖 26 所示的平均服務完成時

122、延圖，集成 SAN 方案的平均服務完成時延較 Istio 的 Ambient 模式和 Sidecar 模式分別提高了 29.5%和 37.1%。圖 25 不同方案服務完成時延分布IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 54 頁圖 26 不同方案平均服務完成時延7 技術及產業展望隨著國內外算力路由標準的陸續落地，以及國內運營商的積極試點探索，算力路由已經進入產業規模落地的前夜。算網資源利用率在算力路由方案智能調度的支撐下得以大幅提升，已經得到初步試點驗證。對業務而言，算力路由的內生功能優勢在于服務會話發現的數量級時延改進，以及網絡層業務的無

123、縫熱遷移，這都是現有網絡架構完全無力支持的。隨著高效交互型業務（如云游戲）及無狀態云原生業務的逐步部署，傳統應用層的部分功能下沉至網絡由算力路由執行硬件級轉發，勢必將釋放出巨大的功能和性能紅利，從而使能更多新型業務。網絡對精選業務定向感知，并據此提供精細化網絡連接服務，已成為行業初步共識。由于涉及應用、業務和網絡的復雜生態，行業中涌現出多樣化技術解決方案，其共性特征和需求是在網絡中引入業務標識，使能網絡對業務的精細化感知和連接服務。從互聯互通的視角看，進一步凝聚需求和方案共識，推動行業統一標準方案的收斂，符合產業的共同利益，勢必成為行業共同努力和推進的方向。HFC 有望使能云原生規?；渴鸷腿?/p>

124、新業務體驗和業務模式。HFC 技術為跨越多個服務端點和相應連接網絡的對外服務提供了微服務解構背景下的全程與端到端的一致性需求IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 55 頁保障，并提供對應的算網流量工程與智能調度能力，有望使能云原生規?；渴鸷腿聵I務體驗和業務模式。云上部署應用將可以分解為更細顆粒度的原子服務，原子服務與功能可以進一步地以按需的方式就近在邊緣精細化和智能化部署。通過動態喚起和調用就近的邊緣服務，進而利用 HFC 的穿越算網基礎設施的服務保障與調度能力，更加有可能為用戶提供有保障的極致服務體驗；另一方面，動態的實例管理可

125、以更好地提供算網一體基礎設施的資源利用率。HFC 的算網一體可視也將為應用與服務提供更加全面和客觀的管理視角?；诙司W一體的服務標識在支持未來高性能智算 DC 網絡的基礎服務能力-AI 大模型的訓練和推理部署的不同過程中都能夠發揮重要作用。大型語言模型(LLM)如 ChatGPT、SORA 等需要很多的 GPU 卡(萬卡或 10 萬卡級別)，建設和運營成本很高，通常由大型數據中心進行訓練任務。而且很多小型模型，如科學領域和專業領域，由于數據的規模、類型以及模型中高質量數據的版權和隱私性等，通常不需要很多的 GPU(如百卡級別)，可以被部署到更靠近用戶的邊緣側。大語言模型能夠返回更多通用類型的答

126、案，而小語言模型通常返回特定領域內的答案。因此，在滿足復雜 AI 訓練和推理任務的場景下，需要采用分布式模型并行加速訓練、推理互聯模式。分布式大模型的核心本質在于通過開放泛在的算力資源，分擔巨大的算力成本和功耗的開銷。而基于端網一體的服務標識互聯網絡則能夠提供這樣靈活的分布式模型部署，通過網絡互聯完成更大模型的訓練。不同的模型服務實例根據需求可以部署在不同的云服務節點，并且能夠保證模型實例間的算網一體資源保證，保證應用的可靠性和高性能。IP 網絡未來演進技術白皮書 4.0_服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 56 頁8 參考文獻1 中興通訊股份有限公司.IP 網絡未來演進

127、技術白皮書.2021.062 中興通訊股份有限公司.IP 網絡未來演進技術白皮書 2.0開放服務互聯網絡.2022.093 譚斌，黃兵，黃光平.面向算網一體的服務感知網絡.中興通訊技術(簡訊),2022,094 黃光平，譚斌，吉曉威.一種面向服務的算網路由架構方案J.中興通訊技術,2023,29(4)5 陳曉,黃光平.微服務架構下的算力路由技術J.中興通訊技術,2022,28(1)6 吉曉威.邊緣算力網絡架構及實踐.中興通訊技術(簡訊),2022,077 段曉東，程偉強，王瑞雪，王雯萱.面向新型智算中心的全調度以太網技術J.中興通訊技術,2023,29(4)8 付華楷，黃光平.服務感知網絡技術

128、和演進探討.中興通訊技術(簡訊),2024,069 郭勝楠，雅承，龐冉等.IP 承載網絡技術演進方向研究J.郵電設計技術,2024(4)10 雷波，趙倩穎，凌澤軍.算力網絡實現一體化服務的探索與實踐J.中興通訊技術,2021,27(3)11 N Katta，A Ghag.Clove:Congestion-Aware Load Balancing at the Virtual Edge.ACM,201712 雷波，陳運清等.邊緣計算與算力網絡5G+AI 時代的新型算力平臺與網絡連接.電子工業出版社,2020.1113 曹暢,唐雄燕.算力網絡云網融合 2.0 時代的網絡架構與關鍵技術.電子工業出版

129、社,2021.0914 羅峰，張東飛，高智芳.算力網絡詳解卷 3 算網大數據.清華大學出版社,2023.01IP 網絡未來演進技術白皮書 4.0 _服務感知網絡（SAN）中興通訊版權所有未經許可不得擴散第 57 頁15 中國電信研究院.云網一體信息基礎設施云網融合下的算力網絡技術與實踐白皮書.2023.0816 中國電信研究院.云網一體信息基礎設施IP 網絡 3.0 技術白皮書.2023.0817 中國移動研究院.面向 AI 大模型的智算中心網絡演進白皮書.2023.0418 中國移動.“九州”算力互聯網（MATRIXES）目標架構白皮書.2024.0419 中國聯通研究院.2024 算力網絡

130、智能運營白皮書.2024.0820 中國電信研究院.分布式智算中心無損網絡技術白皮書.2024.0821 安捷諾.2024 面向未來的算力網絡連接-中國算力網絡市場發展白皮書.2024.0622 IETF.Computing-Aware Traffic Steering(cats).https:/datatracker.ietf.org/doc/charter-ietf-cats/,2023.0323 IETF.L3 Standalone Service ID Framework.https:/datatracker.ietf.org/doc/draft-huang-rtgwg-standalone-sid-framework/,2024.0724 IETF.HPCC+:Enhanced High Precision Congestion Control.https:/datatracker.ietf.org/doc/html/draft-miao-ccwg-hpcc-02/,2024.0225 中國通信標準化協會 CCSA.算力網絡 總體技術要求S.2023.0726 中國通信標準化協會 CCSA.算力網絡 算力路由協議技術要求S.2024.0527 黃光平，史偉強，譚斌.基于 SRv6 的算力網絡資源和服務編排調度J.中興通訊技術,2021,27(3)