【IT168 评论】我认为SDN的定义还是很模糊，我也不是完全肯定到底什么是重要的，这是一个有意思的现象，而更好地了解SDN有助于教育进程。

     原则和协议阵营不同看待SDN

　　当大部分人在谈论什么是SDN时，他们大概可分为两种阵营：原则和协议，你会经常听到有人把SDN描述为控制和转发层的分离，你或许听到人们说SDN需要“开放”，这些人属于原则阵营，他们不太关注技术的实例化，更关心的是如何定义SDN。

　　另一个阵营则旨在探讨专用协议和技术，他们无疑是以OpenFlow为旗帜，但是他们或许还包括BGP-TE, PCE，ALTO和I2RS技术。他们视SDN为一种带有专门创建模块的架构，而这种创建模块的出现决定了一个方案是否能被称作是SDN。

　　我认为这两种定位都不正确。

　　上周争论过GMPLS是否是SDN,它确实是侧重控制层和转发层的分离,是一种开放的标准,它也绝对是用软件部署的,似乎它满足SDN的大部分架构标准,但GMPLS是否是SDN的讨论还不如其周围的讨论要精彩。

　　是以软件来定义SDN吗?如果只因为部署的时候依靠软件部署，就称某个东西为软件定义，或许也太糊弄人了。事实上，传统网络的主体特性都是用软件部署的,而主流厂商也把80%的研发投入在软件相关的工作上,如果仅以此来定义，那么一切都可谓之软件定义。

　　人们谈论软件部署的时候，真正用来区分的是看产品功能是寄居在联网设备上，还是在网络之上的其他地方。但是我们应该对此非常明了,不论无论某些应用是不是在机箱上运行，这都是封装的细节，而不是核心属性,网络设备都具备一些转发ASIC和通用的处理器,无论你是编写什么东西，还是在金属薄片中或服务器上本地运行，这些都不相关,如果厂商决定在他们的机箱里放入单独的中央处理卡，你会把这种方案标榜为软件定义吗?

　　控制和转发的分离是有意义的决定性因素吗?

　　网络设备行为都是状态驱动的,无论状态是由持久的配置来决定还是通过协议来学习,如果你通过一个CLI技术或控制器设置状态，这会让方案偏向SDN一点还是偏离一点呢?

　　大多数人谈论控制和转发的时候，其实是谈论管理层,基于控制器的方案肯定要分离管理层,但策略服务器，OSS/BSS方案和其他编写较好的Perl脚本也是如此，它们把从内容版本化的系统把信息作为设备管理的一部分推入。

　　开放就意味着SDN吗?没有人会说只要开放，就能成为SDN,真正的问题在于，是否有什么可以被称作SDN且不开放呢?答案很大程度上取决于人们如何定义SDN。你能创建一个由软件部署，基于控制器，且使用专属协议的方案吗?当然可以,如果这种方案的寿命是八年，而且IETF批准了用于基础协议的标准，那么你部署的方案有没有从非SDN转向SDN呢?