张卫峰：从SDN=OpenFlow回到软件定义网络

本文转载自：http://network.51cto.com/art/201402/429513.htm

SDN的概念从提出到现在已经过了4年多了，但是关于SDN最基本的问题，“什么是SDN”的争论和探讨从来都没停止过，就像一些哲学家经常思考的“我是谁”，“我从哪里来”，“我要去哪里”一样。有人跟我说，越讨论越迷糊，有时候觉得清楚了，再跟不同的人讨论，又迷糊了。因为工作的关系，在过去一年的时间内，我到处去跟各个运营商，互联网公司，电商，设备商，普通企业，高校，研究所的不同人进行交流，曾经跟一个朋友自嘲说除了ONF的执行总裁Dan Pitt，可能我是世界上跟别人讲SDN讲得最多的了。在这个过程中我不断反思，不断归纳总结，现在我当然不敢说我的想法就一定是对的，但是我认为我有必要把我的看法分享出来，供大家参考，是否认同不要紧，但是希望能对大家所有启发。

我对SDN的认识可以分为四个阶段，最后一个阶段是在第三个阶段基础上的顿悟。

第一阶段：SDN=OpenFlow?

跟很多其他人一样，我最初接触SDN是从OpenFlow开始的，那个时候甚至都没去思考什么是SDN的问题，本能的就认为OpenFlow就是SDN，SDN就是Openflow，其实潜意识中，就是把SDN看作是一个具体的技术和协议，在将近有半年的时间里，都处于这种认识，因为那个时候还没有接触实际案例，也没有广泛去网上了解关于SDN的技术文章，这是最原始的第一阶段。实际上，就算是现在很多人嘴里面说SDN不等于Openflow，但是潜意识里面还会自觉不自觉地将SDN往Openflow靠拢。为什么呢?因为Openflow是大多数人唯一看得到的具体化的SDN的实现形式(实际上当然还有别的实现形式，但是很多人并没有看到或者看到了也没意识到)。

第二阶段：SDN的三个本质属性

后来随着对各种SDN产品了解和网上诸多技术文章的阅读，逐渐意识到，SDN只是一种架构，一种思想，具体的实现多种多样，OpenFlow只是其中一种。我自己总结出SDN的三个本质属性，认为只要符合控制跟转发分离、有开放的编程接口、集中式的控制就可以认为是SDN。基于这样一种理念，某个产品或者方案，哪怕没有使用Openflow，只要它符合这三个原则，也可以认为是SDN。比如Juniper的Open Contrail，不支持Openflow，但是也是SDN。在很长一段时间内，我都坚定不移地认为这是最符合SDN思想的定义。包括我开始写《深度解析SDN》那本书的期间，也是这样认为。

第三阶段：狭义SDN、广义SDN、超广义SDN

后来突然看到阿里巴巴推出了自己的SDN方案，在2013 GITC会议期间，我详细听了阿里巴巴专家的介绍，发现他们这种SDN跟我理解中的控制跟转发分离并不相同，他们自己也说他们的SDN不是大家一般所理解中的SDN，他们的SDN是通过软件控制脚本，让这些脚本向远程的交换机发送命令(不清楚是NetConf还是直接的命令行)来控制交换机，交换机上仍然运行了传统的二三层协议，控制跟转发并没有分离，分离的是管理和控制。刚看到这个方案的时候，我马上就问自己，这算不算SDN?我反复思考了这个问题，他们为什么要这么做，而不是使用更彻底的控制跟转发分离?我个人理解是他们网络中已经有了大量传统的交换机，他们不可能把这些交换机都替换掉，但是又想通过软件自动化来代替手动操作，所以就采取了这样一种折衷的做法。这种做法有没有价值?肯定是有，否则他们不会这么干。那算不算SDN?我一时陷入了迷茫。几经思考之后，我认为，其实SDN并没有确切的定义，只要能实现网络自动化，能够满足特定场景的需求，哪怕这种做法对别的用户没有意义，它也应该算SDN。只是从通用的角度来看，这种SDN灵活性比不上控制与转发分离的那种架构，但是不可否认的是，它能解决特定客户特定场景的需求。认识到这一点之后，我在对外宣讲的PPT中，将SDN定义归为三类，第一类是狭义SDN(等同于Openflow)，第二类是广义SDN(控制与转发分离)，第三类是超广义SDN(管理与控制分离)。而且我认为，第二类定义中的SDN，是最通用，最有价值的一种。

第四阶段：返璞归真，回到软件定义网络

在跟中国电信研究院的专家们一次交流中，我讲了我对SDN的看法之后，研究院的王老师向我提出了一个问题：从SDN的字面意思来看，根本看不出控制与转发分离的意思，你怎么看这个问题?虽然我当时噼里啪啦讲了一堆，回答了这个问题。但是回来之后，我又深入的思考了一下王老师的这个问题，很惭愧，这么一个明显的问题，我之前居然都没去思考过。思考的过程中，我突然有种醍醐灌顶的感觉，就像佛语经常说的那样：看山是山->看山不是山->看山还是山。无论是控制与转发分离，还是管理与控制分离其实都不是SDN的本质定义，SDN的本质定义就是软件定义网络，也就是说希望应用软件可以参与对网络的控制管理，满足上层业务需求，通过自动化业务部署简化网络运维，这是SDN的核心诉求，控制与转发分离不是。但为了满足这种核心诉求，不分离控制与转发，比较难以做到，至少是不灵活。换句话说，控制与转发分离只是为了满足SDN的核心诉求的一种手段，如果某些场景中有别的手段可以满足，那也可以，比如管理与控制分离。