背景 #

文章的主要目的在于目前的数据中心网络(DCN, Data Center Network)中路由的一些问题。

分布式路由 #

在大规模的网络架构中网络状态改变而导致的收敛过程非常缓慢；还有就是计算整个巨大的网络的路由是非常困难的。

中心式路由 #

这里作者以Google的路由方案 Firepath作为对比，在Firepath中controller管理着所有链路状态(LS,link-state)的信息，并保存在一个数据库中(LSDB)，并且主controller和多个备份controller之间会同步该LSDB来保持一致。当LS发生变化的时候，controller会告诉每个switch这个信息，然后每个switch根据这一信息自己再计算一个最短路径(SPF)。但是在这样一个规模比较大的网络中(上万个switch),计算SPF也是需要好几秒中才能完成的。

解决方案 #

针对上述的问题和DCN的架构特点，作者提出了一些解决方案来让switch对LS变化得意快速响应。例如可以先实现计算出一些路径，然后LS变化的时候将相应的路径的状态进行设置即可，也就无需每次去计算SPF。这是文章的一个核心观点。

DCN架构 #

文章中使用和Firepath一样的网络架构，如下图所示：

控制上，网络中有多个Master用来管理链路信息，这些Master中有一个Lead和多个Backup，这些Master通过控制面网络(control-plan network)与DCN相连。

整个DCN网络被分为了三层，从上倒下依次是：

Core
Aggregation(Agg)
Top-of-Rack(ToR)

数个Agg和ToR一起构成了一个Pod，每个Pod内部的Agg和ToR完全相连，而每个Agg又会与数个Core相连，并且每个Core会与所有的Pod相连。可以看到整个DCN的架构是比较固定的，也有层次化的结构。因此可以不需要像一般的网络那样去计算SPF，因为SPF比较适合架构不一定的网络，面对那样的网络时SPF可以很灵活，但是在这种DCN里面是不需要这种灵活性的。

方案细节 #

Path Table #

由于DCN结构比较固定，每个switch可以事先计算出自己到其他所有switch的路径。

上表以switch1.1为例，使用上图架构。表中记录了从1.1到不同的switch的所有路径。

No. 代表的是该路径的编号，下个表中会使用到
Next 下一跳的节点
Dest 目的地switch
FL failure link 代表这个路径中有多少条link是失效的。

可以看到路径是比较固定的，遵循的是先上后下，先从switch到Core，再从Core到目的地。

也就不会出现1.1 -> 1.9801 -> 1.9901这样复杂的路径。

Link Table #

switch内部的第二个就是DCN中所有链路的状态表。

From
To
State
Type
First Entry

From 和 To 代表的链路的方向，之前说过路径是遵循的是先上后下的方式所以有方向。（此处仅对于switch 1.1而言，对于其他的switch，同一条链路可以是2.1 -> 1.1）

Type 代表的是链路的类型（例子中针对switch 1.1而言），由于是先上后下的方式，Type 1 就是 ToR -> Agg, Type 2是Agg -> Core, Type 3是Core -> Agg, Type 4是Agg -> ToR.记录Type的好处就是在链路失效的时候可以直接计算出来所影响的路径的数目。并且由于记录了First Entry，我们可以直接找到受影响的这些路径在 Path Table中的第一条的位置。由于DCN架构是固定的，这些可以在一开始的时候就计算出来。