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示例	动手学习的起点

数据来源说明

本页中：

技术原理部分基于业界公开的架构设计范式，具体实现细节以各厂商文档为准
市场数据部分因缺乏公开来源，采用定性判