SDN： 对谷歌最近发布的基于open flow的内网的一些看法。

lingyang

在最近的ONS 2012 峰会上， 谷歌宣布了其几乎100%的inter-dc网络已经是基于openflow的（非面向客户的那张网，谷歌版本的SDN）。

SDN全称是software defined networking,即使分离路由器的control plane和data plane，由server来中央控制路由器的control plane，让路由器交换机只工作在data plane上，更像一个专职的数据包搬运工。

在Urs Hölzle，google高级副总裁的演讲中他说道” Soon we will able to get very close to 100 percent utilization of our network,” Hölzle says. In other words, all the lanes in Google’s humongous internal data highway can be occupied, with information moving at top speed. The industry considers thirty or forty percent utilization a reasonable payload — so this implementation is like boosting network capacity two or three times.“

疑问1：
如果让网络运行在100%的或者近乎于100%的capacity下，如果发生任何网络链路的问题那么不可避免的会有数据流量的丢失。怎么避免这个问题发生？难道整张网络都是100%的24x7x365？

疑问2:
SDN并不会产生更多的带宽，只是能更好的利用网络资源而已， 和MPLS-TE异曲同工，但是比其更简单，更灵活。所以“this implementation is like boosting network capacity two or three times.“很误导。

google的openflow网络可以说是一次SDN实施的试水，实事并不像其高级副总裁说的那样玄妙。


网络巨擎思科最近也提出了其SDN的策略，认为SDN最大的卖点是可以更具客户的商业规则定制网络。从大学，到企业，到运营商每种网络都尤其特定的属性。所以SDN不是仙丹妙药，也不会是一个one-size-fits-all的方案。

SDN概念和网络虚拟化概念一样听起来很酷，其实思科已经在DC的虚拟化的时候嵌入了SDN的理念。例如Nexus 1000v虚拟交换机，不但提供了虚拟网络到VMs的层面，同时这个1000v也是基于controller/agent架构的，是SDN理念的具体实现。

在接下来的6-12个月内思科会发布一套全新的包含SDN功能，可编程的产品。

google SDN新闻rul：
http://www.wired.com/wiredenterp ... th-the-flow-google/
http://www.networkworld.com/comm ... lt_cisco_2012-04-20

[ 本帖最后由 lingyang 于 2012-4-29 17:39 编辑 ]

墨市开心

server怎么可以做得到路由器的control plane，他们所处位置不同，不认同这个说法。

lingyang

Firmware of network switches and routers ("control plane") have traditionally remained proprietary, locked and under control of companies that manufactured the equipment. SDN seeks to change this disposition, and to make of firmware of the switches and routers ("control plane") remotely accessible and remotely modifiable via third-party software clients, using open protocols such as OpenFlow.

墨市开心

不太懂SDN的工作原理，但是被你一解释，大概猜到意思是说所有的control plane的工作移到DC那边，有几个疑问不太清楚SDN如何可以处理得好；
rib bgp路由表几十万条，远程做re-convergence负荷太重；还有很多各种路由协议，oam都需要实时的和data plane协同工作，如果远程，势必需要大带宽消耗这个NC class； 还有qos的scheduler是根据fc的变化实时在做计算调整，放到远端，响应时间令人担心；mpls-te frr要求50ms的响应，就是路由器的inet.3可以快速响应，放到server,如何保障50ms？通常一条链路的延时根据SAA计算，由于各种原因很容易几十到几百ms的延时。人为的制造一个由每台路由器到DC的新链路来维护这个SDN，如何保障这种链路的稳定呢？

希望看到SDN如何工作的详细资料。

[ 本帖最后由 墨市开心 于 2012-4-29 19:05 编辑 ]

lingyang

原帖由 墨市开心 于 2012-4-29 18:49 发表
不太懂SDN的工作原理，但是被你一解释，大概猜到意思是说所有的control plane的工作移到DC那边，有几个疑问不太清楚SDN如何可以处理得好；
rib bgp路由表几十万条，远程做re-convergence负荷太重；还有很多各种路由协议，oam都需要 ...

你说的这些都还会存在，并且是SDN的基础，但是MPLS-TE可能就会被取代，其实说简单点就是MPLS-TE的control plane变成一个或者一堆openflow的controller，好处就是不用一台一台设备来配置了， 方便了策略管理。google的版本就是基于open flow，其实没什么新鲜的东西:-), 在openflow的proection开启的情况下，在测试中SDN可以实现50ms的restoration，满足carrier grade网络的需求。





[ 本帖最后由 lingyang 于 2012-4-29 21:11 编辑 ]

lingyang

原帖由 墨市开心 于 2012-4-29 18:49 发表
不太懂SDN的工作原理，但是被你一解释，大概猜到意思是说所有的control plane的工作移到DC那边，有几个疑问不太清楚SDN如何可以处理得好；
rib bgp路由表几十万条，远程做re-convergence负荷太重；还有很多各种路由协议，oam都需要 ...

最终就是这个架构

墨市开心

原帖由 lingyang 于 2012-4-29 21:32 发表

最终就是这个架构
559519

谢谢，不过你的图比较high-level了。恕我愚钝，呵呵，有机会慢慢学习。刚才看了一个这个东西，看到这个组织是在开始搞了。。。http://www.networkworld.com/news/2012/041012-sdn-research-center-258126.html