INT (In-band Network Telemetry)

3 秒看懂

維度	一句話
是什麼	資料包”自帶簡歷”穿越網路，沿途交換器即時”蓋章”記錄狀態資訊的遙測技術
解決什麼	傳統帶外監控（sFlow/NetFlow）取樣率低、延遲大，無法精確定位微秒級故障
為什麼現在火	AI訓練叢集萬卡聯網，微秒級擁塞可導致數千美元GPU算力浪費，精準遙測成剛需

3 分鐘產業解釋

核心痛點

傳統網路監控如同”交警只在路口隨機抽查”——NetFlow/sFlow典型取樣率1:1000甚至更低，丟掉99.9%的流量細節。當AI訓練叢集中一條鏈路出現微秒級抖動導致AllReduce超時，傳統方案根本”看不見”。

INT的解決思路

傳統方案（帶外）：            INT方案（帶內）：

資料包 ──→ 交換器A ──→ B ──→ C    資料包 ──→ [A蓋章] ──→ [B蓋章] ──→ [C蓋章]
              ↓                           ↓
         取樣映象(延遲大)              包頭攜帶完整路徑記錄
              ↓                           ↓
         分析系統(事後)               可即時解析、亞微秒級

關鍵改變：將遙測資料”注入”資料包本身，而非旁路抽樣。每個交換器在轉發前，將自己的狀態（裝置ID、佇列深度、時間戳等）寫入包頭後設資料，最終由接收端提取。

產業價值鏈條

上游（晶片/P4）           中游（裝置/軟體）           下游（應用場景）
┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ P4可程式設計晶片  │      │ 白盒交換器   │      │ AI訓練叢集   │
│ Tofino等架構  │ ──→ │ 網路作業系統  │ ──→ │ 資料中心運營  │
│ PISA流水線   │      │ 遙測平台     │      │ 5G核心網     │
└──────────────┘      └──────────────┘      └──────────────┘

15 分鐘專家深入

技術架構詳解

INT採用端到端三段式架構：

角色	功能	典型位置
INT Source	插入INT頭部，指定需要收集的後設資料型別	源主機NIC/ToR交換器
INT Transit	按指令追加後設資料，逐跳”蓋章”	中間所有交換器
INT Sink	提取INT資料，生成遙測報告，剝離/保留INT頭	目的主機/出口交換器

後設資料型別（按OCP INT規範）

INT規範定義了可選後設資料欄位，裝置可按需組合：

興趣型別（Metadata Type）	內容	說明
Switch ID	交換器唯一標識	必選，用於路徑回溯
Hop Latency	本跳處理延遲	核心效能指標
Queue Occupancy	出口佇列深度	擁塞預警
Ingress/Egress Timestamp	進出時間戳	精確測距
Egress Port TX Utilization	埠利用率	負載均衡依據
Queue Congestion Status	佇列擁塞狀態	簡化版擁塞標記

與P4的關係

INT與P4程式語言有深厚淵源——早期由Barefoot Networks在推動P4生態時提出並開源推廣[業界共識]。P4提供的協議無關、目標無關特性使得INT可被靈活實現：

// P4虛擬碼示意：INT Transit處理邏輯（Ingress階段）
action int_transit_ingress() {
    // 1. 讀取本機Switch ID
    hdr.int_switch_id.setValid();
    hdr.int_switch_id.switch_id = my_switch_id;

    // 2. 記錄Ingress時間戳，用於後續Hop Latency計算
    hdr.int_metadata.ingress_tstamp = standard_metadata.ingress_global_timestamp;

    // 3. 讀取佇列狀態
    hdr.int_queue.setValid();
    hdr.int_queue.q_id = standard_metadata.egress_spec;
    hdr.int_queue.q_depth = standard_metadata.enq_qdepth;

    // 4. 更新INT指令點陣圖（標記已收集欄位）
    hdr.int_header.ins_cnt = hdr.int_header.ins_cnt + N;
    hdr.int_data_length = hdr.int_data_length + N * 4;
}

// Egress階段：計算Hop Latency並寫入INT棧
action int_transit_egress() {
    bit&lt;48> hop_latency = standard_metadata.egress_global_timestamp - hdr.int_metadata.ingress_tstamp;
    hdr.int_hop_latency.setValid();
    hdr.int_hop_latency.latency = hop_latency;
}

說明：以上為教學性虛擬碼，實際P4實現需遵循目標晶片約束。正確做法是在Egress階段計算Hop Latency，因egress_global_timestamp僅在Egress處理時有效[定性表述]

協議頭部設計

INT頭部結構按規範通常包含[業界通用設計範式]：

┌─────────────────────────────────────────────────────────────────────┐
│                      原始L2/L3/L4頭部                        │
├─────────────────────────────────────────────────────────────────────┤
│ INT-MD Header (固定長度)                                     │
│  ├─ Ver (版本)                                              │
│  ├─ Instruction Bitmap (需要收集的後設資料型別)                  │
│  ├─ Domain ID / Flags                                       │
│  └─ Total Length / Hop Count                                │
├─────────────────────────────────────────────────────────────────────┤
│ INT Stack (變長，每跳4位元組倍數)                                │
│  ├─ Switch 1 Metadata: [SwitchID | HopLat | QDepth | ...]    │
│  ├─ Switch 2 Metadata: [SwitchID | HopLat | QDepth | ...]    │
│  └─ ...                                                      │
└─────────────────────────────────────────────────────────────────────┘

關鍵設計考量：

後設資料採用順序追加，解析時按跳順序讀取（先進先出）
頭部膨脹（header overhead）是主要限制因素：6跳×8位元組後設資料 = 48位元組額外開銷
需要關注MTU限制與Fragmentation問題

技術原理（最深）

資料平面處理流水線

以支援P4的交換晶片架構為例，INT在資料平面的處理邏輯：

入埠
   │
   ▼
┌──────────────────────────────────────────────────────────────────┐
│                    解析器 (Parser)                                │
│  識別內層包頭 → 判斷是否有INT-MD頭部 → 解析指令點陣圖                │
└──────────────────────────────────────────────────────────────────┘
   │
   ▼
┌──────────────────────────────────────────────────────────────────┐
│                    入埠處理                                     │
│  記錄ingress_port、ingress_timestamp                             │
└──────────────────────────────────────────────────────────────────┘
   │
   ▼
┌──────────────────────────────────────────────────────────────────┐
│                    路由/交換查表                                  │
│  決定egress_port                                                  │
└──────────────────────────────────────────────────────────────────┘
   │
   ▼
┌──────────────────────────────────────────────────────────────────┐
│                    INT處理引擎 (核心)                             │
│  ┌─────────────────────────────────────────────────────────┐     │
│  │ 檢查報文是否有INT頭部？                                    │     │
│  │   ├─ YES → 當前角色？                                     │     │
│  │   │         ├─ SOURCE → 插入INT-MD頭部 + 首跳後設資料        │     │
│  │   │         ├─ TRANSIT → 追加本跳後設資料到棧頂              │     │
│   │   │         └─ SINK → 提取後設資料→映象到監控埠/生成報告   │     │
│  │   │             (可選：剝離INT頭或保留轉發)                 │     │
│  │   └─ NO → 正常轉發                                        │     │
│  └─────────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────────┘
   │
   ▼
┌──────────────────────────────────────────────────────────────────┐
│                    出埠處理                                     │
│  記錄egress_timestamp，計算hop_latency = egress - ingress        │
│  寫入INT棧                                                        │
└──────────────────────────────────────────────────────────────────┘
   │
   ▼
出埠 ──→ 物理傳送

效能與資源約束

約束維度	說明
頭部膨脹	每跳4-16位元組追加，6-10跳後額外開銷50-150位元組；需考慮封裝場景下MTU
片上SRAM	後設資料需在pipeline內完成讀寫，受限於晶片TCAM/SRAM容量
時間戳精度	取決於晶片時脈頻率，典型為納秒級
CPU解除安裝	高速場景下解析INT報告通常需要智慧網絡卡(NIC)或DPU協助

控制平面互動

┌─────────────────────────────────────────────────────────┐
│                   控制平面                                │
│  ┌───────────────────────────────────────────────────┐  │
│  │ INT Manager (編排器)                               │  │
│  │  - 配置哪些流需要INT                                │  │
│  │  - 指定後設資料型別和採集深度                          │  │
│  │  - 管理Source/Transit/Sink角色                      │  │
│  └───────────────────────────────────────────────────┘  │
│           ↓ 配置下發 (P4Runtime/gNMI)                    │
│           ↓                                              │
│  ┌───────────────────────────────────────────────────┐  │
│  │ INT Collector (採集器)                             │  │
│  │  - 接收Sink端的INT報告                              │  │
│  │  - 解析路徑/延遲/擁塞資訊                            │  │
│  │  - 上送時序資料庫/視覺化平台                         │  │
│  └───────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

技術演進史

時間節點	事件	意義
~2016	Barefoot Networks開源INT參考實現	INT概念首次大規模進入業界視野[業界共識]
2017-2018	OCP（Open Compute Project）成立INT工作組	邁向開放標準
~2019	P4可程式設計交換晶片（如Tofino）量產	INT有了硬體載體
~2020	IETF在ippm等工作組推進INT相關標準草案（如IOAM），併產生了一系列網際網路草案（I-D）	進入標準化快車道
~2021-2022	INT 2.0規範演進，支援更多封裝格式	適用範圍擴大
~2023-2024	AI訓練叢集對網路遙測需求爆發	INT從”實驗性”轉向”生產性”

注：以上時間線基於公開資料整理，具體版本號和日期以OCP/IETF官方釋出為準[定性表述]

技術路線對比

網路遙測方案全景

維度	NetFlow/sFlow	INT (帶內)	Ping/Traceroute	映象埠
採集方式	取樣（典型1:1000+）	逐包/逐流	主動探測	全量映象
時效性	分鐘級	亞秒級/逐包	秒級	即時
粒度	流聚合	單包逐跳	端到端	全量但無路徑
部署複雜度	低（成熟）	中-高（需P4支援）	低	低
頭部開銷	無（帶外）	有（4-16位元組/跳）	額外包	無
適用場景	流量統計/計費	微故障定位/擁塞分析	基礎連通性	深度包檢測
AI訓練叢集適用	差（取樣丟細節）	優	差	中（無路徑資訊）

INT與其他帶內遙測方案

方案	主導方	特點
INT	OCP/Barefoot	最廣泛討論，與P4生態深度繫結
iOAM (In-situ OAM)	IETF	更注重標準化和RFC推進
AM-PM	運營商	側重行動網路

三者在技術原理上有共通之處，主要差異在標準化路徑和生態繫結[定性表述]

上下游

產業鏈圖譜

┌─────────────────────────────────────────────────────────────────────────┐
│                           上游：基礎能力層                               │
├─────────────────────────────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  │
│  │ 可程式設計晶片    │  │ P4編譯器     │  │ 作業系統      │                  │
│  │ (交換ASIC    │  │ (P4C等      │  │ (SONiC等     │                  │
│  │  支援INT)    │  │  開源工具)   │  │  整合INT)    │                  │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘                  │
└─────────┼──────────────────┼──────────────────┼─────────────────────────┘
          │                  │                  │
          ▼                  ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                           中游：裝置與平台層                             │
├─────────────────────────────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  │
│  │ 白盒交換器    │  │ 遙測採集器   │  │ 視覺化平台    │                  │
│  │ (OCP相容     │  │ (解析INT     │  │ (路徑回溯    │                  │
│  │  裝置)       │  │  報告)       │  │  延遲熱力圖)  │                  │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘                  │
└─────────┼──────────────────┼──────────────────┼─────────────────────────┘
          │                  │                  │
          ▼                  ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                           下游：應用層                                   │
├─────────────────────────────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  │
│  │ AI訓練叢集   │  │ 5G UPF      │  │ 金融低延遲   │                  │
│  │ (GPU互聯     │  │ (使用者面     │  │ 交易網路     │                  │
│  │  擁塞診斷)   │  │  功能)      │  │              │                  │
│  └──────────────┘  └──────────────┘  └──────────────┘                  │
└─────────────────────────────────────────────────────────────────────────┘

關鍵指標

指標	說明	重要性
後設資料型別覆蓋率	支援的Metadata Type數量	決定診斷能力深度
最大跳數	單個數據包可承載的INT資訊跳數	受頭部空間和MTU限制
時間戳精度	納秒級 vs 微秒級	高頻交易/AI訓練的關鍵
報告採集速率	每秒可處理的INT報告數量	控制平面瓶頸
頭部膨脹比	INT頭佔總包長比例	影響有效頻寬
晶片覆蓋率	現網裝置中支援INT的比例	部署成本
整合成熟度	與現有NMS/SDN控制器的整合	運維成本

供需與市場資料

市場規模（估算）

細分市場	INT相關需求驅動力	增長階段
AI資料中心交換器	GPU訓練叢集網路遙測成剛需	早期高速增長
可程式設計交換晶片	INT需要PISA等可程式設計流水線支援	技術驗證期
網路可觀測性平台	從傳統sFlow向INT演進	滲透期

具體市場規模資料缺乏公開來源，以定性判斷為主[未充分揭露]

需求側變化

AI訓練叢集規模演進：
100卡  →  千卡  →  萬卡  →  十萬卡(未來)
  │        │        │         │
  ▼        ▼        ▼         ▼
故障容忍   網路成為   毫秒級    INT從
相對寬鬆   瓶頸開始   故障可    "可選"
           顯現     浪費百萬  →"必須"
                    級算力

代表公司與資本對映

產業鏈玩家圖譜

層級	玩家型別	代表公司/專案	INT相關性
晶片	交換ASIC	Intel (原Barefoot/Tofino)、博通[定性]	高（需硬體支援）
晶片	智慧網絡卡/DPU	輝達、AMD/Xilinx[定性]	中（Sink端解除安裝）
作業系統	網路OS	SONiC (微軟開源)[定性]	中（軟體整合）
平台	遙測採集	多為初創/開源專案[定性]	核心
整合	裝置商	思科、Arista、華為[定性]	中（高階產品線）
應用	超大規模使用者	雲端廠商（自研方案為主）[定性]	最終需求方

投資對映思路

直接標的少（多為大廠內部能力）  →  間接受益邏輯：

[晶片層]  可程式設計交換晶片滲透率提升
     ↓
[裝置層]  白盒交換器在AI叢集佔比提升
     ↓
[軟體層]  網路可觀測性平台功能升級
     ↓
[應用層]  AI訓練效率提升（降低網路瓶頸導致的算力浪費）

投資邏輯

核心假設

AI訓練叢集規模擴張 → 網路成為核心瓶頸 → 精準遙測從”錦上添花”變為”生產必需”
可程式設計晶片滲透 → INT硬體基礎成熟 → 部署成本下降
開源生態完善 → 降低整合門檻 → 加速從實驗到生產

關鍵觀察點

觀察維度	看什麼	訊號
晶片廠商	新一代交換晶片是否預設支援INT	能力平民化
超大規模使用者	公開論文/部落格提及INT部署經驗	需求驗證
標準組織	IETF/OCP規範更新頻率	生態健康度
初創融資	網路可觀測性賽道融資事件	資本認可

風險提示

碎片化風險：INT規範仍在演進，存在互操作性隱患
替代方案：eBPF-based方案可能在主機側分流部分需求
部署慣性：傳統sFlow方案足夠”夠用”，升級動力不足

常見誤讀糾偏

誤讀一：“INT可以替代傳統網路監控”

糾偏：INT是補充而非替代。NetFlow/sFlow在宏觀流量統計、計費、安全審計等場景仍有不可替代的價值。INT的優勢在於微秒級故障定位和逐跳路徑可見性，但其頭部開銷和部署門檻限制了大規模全量部署。實際生產中，INT通常用於關鍵業務流（如AI訓練的NCCL通訊），而非所有流量[定性表述]。

誤讀二：“任何交換器都能支援INT”

糾偏：INT需要資料平面支援可程式設計處理，即交換晶片需具備在轉發流水線中插入/追加後設資料的能力。傳統固定功能ASIC（Fixed-function ASIC）無法原生支援INT。INT的硬體基礎通常是支援P4或類似可程式設計架構的晶片（如Intel Tofino系列，或其他支援PISA架構的晶片）[定性表述]。

誤讀三：“INT的主要價值是流量視覺化”

糾偏：視覺化只是表層價值。INT的核心價值在於：

閉環反饋：基於即時遙測資料，觸發負載均衡策略動態調整（如將流量從擁塞路徑遷移）
根因定位：在萬卡叢集中，快速定位是哪一跳、哪一佇列導致尾延遲飆升
SLA保障：提供逐包級的網路效能證據鏈

學習路徑

入門階段（0-1周）

閱讀OCP INT規範概述（官方文件，連結需自行檢索確認可訪問性）
理解傳統網路監控（sFlow/NetFlow）的侷限性
觀看P4語言官方教程中的INT示例

進階階段（1-4周）

搭建P4+BMv2（行為模型虛擬交換器）環境，動手實現簡化版INT
閱讀IETF iOAM草案，對比INT與iOAM的設計差異
研究Barefoot/Intel Tofino架構白皮書，理解硬體流水線

實戰階段（1-3月）

在Mininet/FABRIC等網路模擬環境中部署INT採集系統
分析真實AI訓練流量（如NCCL AllReduce），識別網路瓶頸模式
探索INT與SONiC、P4Runtime的整合

一句話總結

INT是資料包級別的”飛行記錄儀”——它讓網路中每一個數據包都能”講述自己穿越的每一跳發生了什麼”，是萬卡AI訓練叢集從”看不見網路”到”看見每一微秒”的關鍵基礎設施。

延伸閱讀與來源

來源型別	推薦內容	說明
規範文件	OCP INT Specification	最權威的INT規範，建議直接查閱OCP官網最新版本[需自行確認連結有效性]
標準草案	IETF In-situ OAM (iOAM)	IETF的帶內遙測標準化工作，與INT有技術交集
學術論文	搜尋”In-band Network Telemetry”相關ACM/IEEE論文	技術深度研究
廠商文件	Intel/Barefoot P4 INT Tutorial	實操性強，但需注意廠商立場
開源專案	p4lang/p4app INT示例	動手學習的起點

資料來源說明

本頁中：

技術原理部分基於業界公開的架構設計範式，具體實現細節以各廠商文件為準
市場資料部分因缺乏公開來源，採用定性判