本文是《从 IP 到 SRv6 计算编排》新手教材第 8/13 编。 总目录 · 上一篇：第七编：SPP、图像 Tile 与部分成功 · 下一篇：第九编：HEFT 全链联合编排
55. 三级降档不是链路丢包，也不是控制命令
当AF_XDP fabric报告本地出端当前可用速率下降时，节点可对符合业务契约的SPP图像执行 自主降档。它不是控制器命令，也不是前端控制。
这里的**Degradation（降档）**是业务表示变换：同一Tile从信息更多的RGB变成Gray或Edge， 以减少后续链路字节。它不同于：
- connectivity drop：链路不通，包根本不能进入该边；
- congestion drop：有限出口队列已满；
- token wait：链路连通但包等待令牌；
- BNN DROP：模型判断该Tile不是火焰候选；
- 控制器重路由：控制面传播事实后节点重新计算FIB。
规则只读取包当前格式和即将使用的有向链路速率比例，不读取任务最终是否成功，也不
等待某个验收时刻。不同方向可以有不同队列和统计，因此A -> B的降档判断不能偷用
B -> A状态。
55.1 三种格式为什么恰好形成三级
一个16×16 Tile的当前payload大小为：
| 等级 | 格式 | 每像素信息 | Payload大小 |
|---|---|---|---|
| 0 | RGB24 | R、G、B各8 bit | 768 byte |
| 1 | GRAY8 | 一个8-bit亮度 | 256 byte |
| 2 | EDGE1 | 一个二值边缘bit | 32 byte |
RGB到Gray把payload缩小为三分之一；RGB到Edge缩小为二十四分之一。体积减少不是免费收益： Gray丢失颜色，Edge只保留二值结构。系统必须同时记录网络收益和业务信息损失。
55.2 当前阈值规则
当前阈值规则是：
current_rate/design_rate（当前速率/设计速率） | 目标格式 |
|---|---|
> 80% | RGB24 |
> 40%且<= 80% | GRAY8 |
<= 40% | EDGE1 |
边界必须精确：等于80%进入Gray，等于40%进入Edge。若包已经是更低格式，只能保持或继续 下降，不能升级。
这里的current_rate是当前环境作用后的速率，design_rate是链路基线。假设设计速率
1 Mbit/s：
900 kbit/s -> 90% -> 保持RGB
800 kbit/s -> 80% -> 降为Gray
400 kbit/s -> 40% -> 降为Edge
格式等级只能单调增加，即信息只能保持或继续减少：
RGB -> Gray -> Edge
RGB -------> Edge
Gray ------> Edge
已经成为Gray的包后来走到高速链路也不会恢复RGB，因为丢失的颜色信息已经不存在。fabric 更不能凭空“升档”制造原始像素。
55.3 为什么XDP程序本身仍然不做降档
挂在宿主veth上的XDP/eBPF程序仍然只验证Ethernet目的MAC并redirect到按source索引的 AF_XDP socket。它不解析IPv6、SRH或SPP，也不运行Gray/Edge算法。
唯一受限例外位于AF_XDP用户态fabric。link worker已经拥有当前source -> destination
链路的rate与design rate，因而可以在发送边界：
- 验证Ethernet、outer IPv6、SRH、inner IPv6、UDP和SPP边界；
- 读取当前SPP format，计算是否需要更低等级；
- 只构造一次本地SRv6 detour（绕行）；
- 把包回注source节点，让Linux和真实算子完成变换。
把最小解析放在用户态，不等于允许fabric直接处理图片。链路worker只决定“需要哪一级”， 实际pixel算法仍属于算子namespace。
55.4 本地算子detour怎样保持原路径
假设一个包正在节点17准备发往节点18，outer IPv6的当前active segment是S。链路要求
Gray时，fabric构造的逻辑执行顺序是：
Gray@node-17具体SID -> resume segment S -> 原有其余segment
实现必须保存当时真正的outer Destination Address，并在需要时移动当前uSID指令，形成
单调前进的SRH；不能回到最初静态列表猜当前位置。包被回注lfc017以后：
节点17 Linux命中本地Gray SID
→ End.X交给Gray namespace
→ Gray AF_XDP worker执行真实RGB24到GRAY8变换
→ 更新SPP format、payload length和UDP checksum
→ 回注并恢复resume segment S
→ 沿原物理路径继续到节点18
Edge同理。detour不改变原source、destination、task、object或Tile身份，也不保存另一套全网 路由；它只在当前节点插入一个已经存在的具体算子SID。
55.5 为什么每个网络节点都部署Gray和Edge
链路变差可能发生在任意一条有向边的source节点。如果只有少数节点具备Gray/Edge，其他 节点检测到降档需求时无法形成本地闭环。因此启用三级降档的场景把“每个网络节点都有本地 Gray和Edge”作为部署前提。
这是一条普适能力规则，不是按业务路径预先挑出几个正确节点。算子仍常驻运行，不能等包 到来再临时启动；其他五类算子继续按异构profile分布。
55.6 怎样证明一次降档真的完成
一次完整证据链至少包括：
AF_XDP观察到有向链路比例并决定target format
→ detour被构造并回注source节点
→ 本地Gray或Edge具体SID被执行
→ 算子记录输入/输出格式和同一task/object/tile
→ 包恢复原SRv6路径
→ 目的端收到相同身份且格式已降低的Tile
仅有前端显示Gray图、仅有fabric detour计数，或者仅有目的端某个GRAY8包，都不能单独证明 这条闭环。分析器必须按task身份区分三级降档业务与其他同样经过Gray/Edge的HEFT或Anycast 业务，避免把全局算子计数错误配对。
前端从真实事件显示RGB、Gray、Edge数量以及原图、中间图、目的图。它不能点击按钮触发 降档，也不能因为观察器失败而停止链路、算子或业务。
降档是业务行为。它可以降低带宽和增加信息损失，成功与否应由Tile格式、算子事件、目的端 接收和报告共同证明。
56. 第五至八编阶段自测
- 算子类型与实例有什么区别？
fd42:3:14::100和fd42:7::100各表示什么？- 为什么有状态算子的缓存键必须包含task、object和epoch？
- Morton码为6的示例坐标是什么？
- 100个Tile到达90个时，为什么不是任务0%？
- Anycast为什么可能让网络无丢包却产生不完整窗口？
- 三级降档为什么不能从EDGE1恢复到RGB24？