凡是过往，皆为序章: 源路由路径感知转发

（以下内容已经申请专利，抄作业不好，当然.....）

同时还有一些借助INT进行快速拥塞控制的算法，例如阿里的HPCC：

例如阿里云需要SRv6和HPCC落地，这个场景就是一个不错的选择，既实施了SRv6又把HPCC的能力加入，而且不光是在两端的智能网卡上实施，中间的交换机也做了很好的协同。

由于每一跳转发的时候可以清楚的看到每个中继交换机(PSW/DSW/PSW)所经历队列深度和拥塞程度，那么对于收端可以很好的根据这个结果ECN通知发端是降速或者重路由。例如收到的队列拥塞程度全部为0-0-0，可以采用MI乘性增加的方式，2-2-2以上则采用AI加性增加，而任何一跳出现3时，采用MD的方式，最终有了一个AIMD和MIMD混合的方案，策略逻辑也非常简单，当出现多跳拥塞时重路由就可以实施了，当然针对MPTCP可能还需要一些魔改，所以另一个选择是采用SRoU with QUIC（鹅厂要不这么干干？）。

这种方案整合了SR和INT，事实上使得路径控制(Path Enforcement) 和路径遥测(Path Telemetry)可以完全的随路同步，因此各个TOR交换机就可以用非常小的代价来测量全网的性能并生成链路状态拓扑。这也是SRoU随路测量和链路状态随路通告功能的一部分，因为在传递的过程中，中间路由器或者交换机也能很好的感知链路上游的拥塞状态。我们会在下一版的RFC draft中添加上。

对于源路由可能比较担心的一个问题是路由黑洞，我们可以在报文因策略丢弃（Queue满了Taildrop，No Route， ACL Drop）时，反向传播到上游传播Drop Notification。

4.和以往实现的不同

看上去非常简单的整合了SR和INT，具体又有什么不同呢？传统的MPLS Performance Measurement，由于MPLS标签需要弹出，无法maintain路径信息而需要额外的字段来进行处理。当转发SRv6时，用过的SID并不会像MPLS那样弹出，但是似乎还是采用做加法的方式增加新的TLV，而INT本身就是做加法加Header的方式。实际上造成了测量值和转发实际值的细微的不一致（包size变化和处理时间的问题）。

本文所述的方法复用了处理完的SID，不影响下游转发，同时又增加了INT的功能，正好操作指针在完成Dst IP更新后，停留在需要overwrite的SID前，操作相对简单，进queue前本来就要读取queue depth来决定是否要taildrop，顺势把它更新到接下来的一些字段中就好了。

所以本文才有：“凡是过往（被处理完的SID），皆为序章（更新的INT）”，今日技术扶贫结束。

有高网和想做SRv6、HPCC的某云，啥都没有又想做高网的另一个动物云，还有凡事必谈IPv6+的某司，学习去吧：）