SDN基础分析浅谈(1)

SDN基础分析浅谈(1)

SDN(Software Defined Network)是个有意思的概念。ONF(Open Network Foundation)这样定义SDN：

In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.

用普通话说就是软件独立于硬件，让硬件标准化，软件平台化，信息中心化。

硬件标准化/软件平台化

这概念说新颖不新颖，软件行业从OS诞生的那一天，就已经这么做了。Wintel主导的PC革命让整个行业围绕着一致的硬件体系，统一的，向后兼容的API(Windows SDK)开发硬件和软件的各种应用。用个不太恰当的类比：上图的infrastructure layer相当于PC的硬件，control layer相当于windows/SDK或*nix/POSIX，application layer相当于OS之上的各种软件。

可是网络设备行业却一直没有形成这样的生态圈。我觉得是两个方面的原因：

整个行业没有意识。网络设备的优劣基本上在performance上见分晓，上流的vendor各出奇招，在ASIC设计上绞尽脑汁，所以就一直没形成标准的硬件(使用标准硬件的基本上是下流的vendor)。各个vendor在推出自己的设备时，软硬件已经紧密绑定，一定程度上把这三个layer做在了一起。

大玩家没有意愿。即使有vendor意识到PC生态圈的好处，也没有驱动力这么做。你想啊，PC vendor的前车之鉴摆在那里，一旦decouple好了，自己若做不了control layer的leader，掌管着生态圈，岂不就沦为Compaq，Dell这样的纯硬件vendor，只能在供应链上比拼越来越低的行业利润。逮你你愿意吗?

所以CISCO/Juniper等一票vendor就这样软硬兼施地做了若干年，慢慢把市场培养成现在的样子：没有第三方，一切软件，从系统到应用，从package forwarding到VoIP，只能是我自己提供。所以当08年还是09年，Juniper依然壮士断腕，轰轰烈烈地推动One JUNOS，开放SDK，试图打造一个类似Windows的生态圈，似乎为时已晚，应者寥寥，因为愿意和有能力接盘的软件公司已经不多。

但是网络设备的发展的相对滞后，越来越赶不上mobile internet/cloud computing时代的步伐。成千上万的应用被不断地创造出来，就几个vendor的一帮苦逼程序猿咬牙应对，肯定是杯水车薪。

信息中心化

信息中心化是对传统网络的一大挑战。Internet的前身，ARPANET，在创建之初就有一个前提：这个网络是个自制的，无中心的系统，网络遭受任何局部损失都不会影响其他部分的正常通讯。所以，所有的RFC都围绕着这个前提来构建，所有的网络设备也遵循着这一前提来研发。

但是SDN将这一前提打破。所谓天下合久必分，分久必合。网络世界也不能免俗。Cloud computing引发的互联网革命新浪潮将计算和存储中心化，SDN顺应了这一趋势。通过硬件，软件平台的支持，信息(网络状态)被共享到一个逻辑上集中的中心。相对于去中心化的传统网络，SDN带来很多很多优势。本文将着重讨论信息中心化对网络设备的革命性意义。

温馨提示：作者对还未系统研读过关于SDN的ONF white paper，也没有实际研发过SDN相关的软件，所以本文中的一些想法均属臆测，既不完整，也不完备，可能经不起进一步的推敲，不当之处，还望指正。

转发

网络设备的核心是转发，即packet从接口X转发到接口Y。转发的依据是选路，路由协议会告诉系统如何选路。转发最头疼的问题是link down，无论是physcial还是logic link down，对于拓扑中的一台网络设备来说，link down意味着重新选路并通知其他网络设备。这直接导致一段时间的丢包。选路时间越长，丢包越多。

link down带来两个问题：

1、路由的收敛(convergence)。

2、重新选路的不确定性。

先看收敛问题。一台运行OSPF(其他协议大致如此)的网络设备的convergence time大概可以这样算出：

Convergence = 链路状态变化发现时间 + 协议消息传递时间 + SPF计算时间 + RIB/FIB更新时间

所需时间：

● 链路状态变化发现时间: ~5ms

● 协议消息传递时间: LSA生成时间 + LSA发送时间 + LSA接收时间 + LSA处理时间 + 网络传递时间，~20ms+log(N) N为邻居数量

● SPF计算时间: O(L+N*log(N))，L为受影响的链路数，N为拓扑中节点数

● RIB/FIB更新时间: ~5ms

由以上公式大概可以看出，convergence的瓶颈在SPF计算和协议消息传递上，网络越大，SPF和协议消息传递所需时间越长。此外，一般网络设备对计算量大的任务，如SPF，跑在相对低优先级的task上，无形中又降低了SPF的速度。

在众多路由协议中，OSPF和IS-IS这样的链路状态协议，由于每台设备都拥有局部甚至全局的网络拓扑信息，收敛速度已算上佳。

再看重新选路的不确定性。由于拓扑中其他设备的影响，某台设备的同一条链路先后几次link down的选路不一定相同。所以，每次link down发生，路由需要重新收敛，不能依照之前的历史来做出决定。

SDN的优势

如果能够将路由信息中心化，即一个云端计算中心实时掌握全网的拓扑状态，则可以做很多很有价值的处理。比如：

● 加快路由计算的速度。对于OSPF来说，如果SPF能过放在云端计算，计算性能将大有改观，能够支持比现有应用更大的网络。

● 预先做出某种判断。如果说加快路由计算的速度带来的好处可能被网络传输的延迟所抵消，那么，当云端拥有了整个拓扑状态时，可以预先计算出一些特定的解决方案并提前发送给设备。当符合解决方案的情况出现时，设备可以即刻应用解决方案选择特定的路由。