软件定义网络(SDN)无疑是目前最热门的事物。然而，从术语的定义，到不同的架构，再到各家技术供应商所提供的产品等方方面面都存在着相当的混乱。
这些混乱导致部分企业的IT部门可能更愿意持观望态度。这种做法虽然可以理解，但却并不适当。尽管没有哪位高人敢于声称他们知道未来几年SDN和网络虚拟化会如何演进，但大家也都清楚，这些新兴技术无疑将会对网络行业产生重大影响。
企业现在就需要制订规划，对SDN技术进行评估，并考虑如何将这些新的解决方案应用到网络中。我们在这里列出了一些制订规划过程中需要重视的宏观因素，以及某些微观问题。但首先还是让我们从SDN的定义开始。
开放网络基金会(ONF)是一个与SDN的发展和标准化联系最为紧密的团体。在ONF看来，SDN并不是一种技术而是一种架构。据ONF称，SDN将网络控制与转发功能解耦，网络控制可直接编程实现，而底层基础设施对于应用和网络服务来说则被抽象化。OpenFlow协议成为构建SDN解决方案的基本要素。
导致SDN出现混乱的部分原因是许多厂商根本不认可ONF对SDN的定义。举例来说，尽管绝大多数厂商都在其SDN定义中包含了集中控制的概念，但它们对于应该集中多少控制权却并未达成共识。此外，尽管有不少厂商已将OpenFlow协议视为其SDN解决方案的基本要素，但仍有部分厂商对OpenFlow采取了十分谨慎的态度，同时选择采纳XMPP等协议。
产生混乱的另一个原因是网络虚拟化与SDN的关系。用户可能会部署类似ONF定义的SDN，并使用这样的SDN来实施网络虚拟化。例如，OpenDayLight基金会前不久就接受了NEC贡献的虚拟租户网络(VTN)。这一虚拟租户网络能够让SDN实施网络虚拟化。
然而，不必部署SDN也可以实现网络虚拟化。例如，Nuage Networks和VMware/Nicira就都是利用叠加方式来实施网络虚拟化的。让人更加感觉混乱的是，Nuage Networks将其解决方案称之为SDN，而VMware则认为它的解决方案是网络虚拟化，而非SDN。
IT组织显然不能坐等围绕SDN定义和网络虚拟化关系的混乱状况自然平息。在制订SDN规划时，IT组织需要确定一种可以很好理解的SDN定义，并让这一定义在组织内能被接受。
SDN的实现目标
在尚未确认到底希望用SDN解决什么样的问题或它能提供什么样的功能之前，对SDN解决方案架构和所包含协议进行分析根本没有意义。这是因为对架构和协议的分析只有在IT组织确定了需要完成的目标后才有意义。
一般来说，与SDN有关的主要实现目标包括：
支持虚拟化工作负载的动态迁移、复制和分配。
减轻配置和预配置各网元的管理负担。
让流量工程拥有端到端的网络视图
更容易实施服务质量(QoS)
让应用能够动态地申请网络服务
举例来说，如果企业的目标是支持虚拟化工作负载的动态迁移、复制和分配，那么Nuage Networks或VMware的叠加解决方案便可供选择，同样的，NEC的SDN解决方案也是可行的。不过叠加解决方案不易实现QoS，也不能让应用动态地申请网络服务。
SDN目前尚处于发展初期并在迅速演进中。因此为了创建和升级SDN规划，IT组织需要持续地让自己了解在SDN生态系统中正在发生什么。这其中包括要分析相关的SDN使用案例，以及能够验证SDN部署合理的技术。此外，还应评估各种产品发布、评估各种新的SDN技术或演进技术、测试SDN解决方案互操作性的plugfest测试结果，以及OpenDaylight等组织的工作进展情况。
这方面的培训可以通过阅读相关文章和白皮书，参加研讨会和讲习班的形式完成。IT组织还应当考虑下载一些现成的开源产品，熟悉这些解决方案以便能够深度洞察它们的功能与弱点。
作为SDN规划的一部分，企业需要确定将评估哪些厂商的SDN解决方案。评估的标准将在下面讨论。在启动评估SDN工具的流程时，企业需要确定是从单一厂商那里获得完整的SDN解决方案，还是从多个厂商那里采购各个组件。
从单一厂商获得完整的SDN解决方案虽然可以排除互操作性问题，但是仍然需要询问厂商自己对其进行测试的细节，以及第三方对其测试的结果，如果有的话。
#p#
SDN评估
对SDN解决方案的评估流程是循环的。首先需要对众多厂商进行一个粗略的评估，以查看哪些解决方案能够符合你的独特需求，要让IT部门意识到各个厂商提供的SDN解决方案彼此之间有很大的区别，每一种解决方案都有自己的特色和附加价值。这一阶段有助于排除掉部分厂商，只对一小部分供应商做更为详细的分析。而详细分析的结果可作为下一步进行概念验证(POC)的依据。
在评估SDN解决方案时，企业需要考虑以下因素：
■ 解决方案的架构
这其中包括审查由厂商与合作伙伴提供的解决方案组件;SDN控制器集中了多少控制权;解决方案使用了哪些协议;解决方案如何支持高可用性;控制器的北向API所提供的抽象水平等。
此外，还要根据已经确认的实现目标来评估SDN解决方案的相应能力。例如，如果目标是减轻配置和预配置网元的管理负担，那么就需要确定每个解决方案是如何实现这一目标的。
■ SDN控制器
还需要评估各种SDN控制器架构。例如，控制器是否采用了能够随时增加新功能的模块化架构?IT组织还需要搞清楚控制器架构是如何实现可扩展性、高可靠性和出色性能的。
■ SDN交换机
IT组织需要了解哪些厂商的交换机支持SDN，以及它们是如何实现这种支持的。例如，厂商的交换机是否支持OpenFlow协议?如果支持，那么支持的是哪个版本的协议，支持哪些可选功能?交换机是纯SDN交换机还是混合交换机，如果是混合交换机，那么SDN部分是如何与交换机的传统部分进行交互的?
■ 管理
SDN管理有两个方面需要加以评估。一个方面是厂商的解决方案能否缓解SDN所带来的管理上的挑战。这包括要监控SDN控制器的性能;是否提供了虚拟网络的端到端可视化;配置SDN交换机，监控交换机之间的物理与逻辑网络。第二个方面是将SDN管理集成到范围更大的管理解决方案之中。两个目标分别是最小化对新的SDN专用管理工具的需求，将现有FCAP(ISO的标准管理框架)流程扩展至整个网络的SDN部分。
■ 安全
需要进行的安全评估也有两个方面。一个方面是解决方案所提供的哪些功能可以确保SDN的安全。这一点非常关键，如果黑客获得了访问SDN控制器的权力，他们就可以访问所有的网元。安全性评估的另一个方面是解决方案提高IT基础设施整体安全的能力。例如，Radware近期向OpenDaylight的SDN控制器贡献了一套工具集。该工具集可用于探测和缓解分布式拒绝服务(DoS)攻击。
■ 网络功能
有两个办法可以帮助IT组织获得基于SDN控制器的网络功能。一个办法是从厂商那里获得网络功能(如Radware的分布式DoS应用和NEC的虚拟租户网络功能)。由于大多数IT组织是从厂商那里获得网络功能的，因此对厂商提供的网络功能进行评估是SDN解决方案评估流程中的关键一环。第二个办法是让IT部门开发部分或是全部所需的网络功能。这个办法的主要优势是IT部门可以定制功能，以满足组织的特定需求。不利之处是IT部门必须拥有开发和维护这些功能的技术基础。
■ 测试与认证
如前文所述，即便SDN解决方案的所有组件都来自同一家厂商，组织仍需要了解之前已做过的确保平稳运行的测试。如果SDN组件来自多家厂商，那就需要了解各个解决方案是否已经过了认证，以及在后续遇到问题时是否有一个单独的联系点。IT部门可能需要自己进行测试，或是委托第三方代为测试。举例说，如果企业开发了一个或多个网络功能，就需要在特定的SDN控制器上测试这些功能;在部署新版本控制器之前也需要重新测试。如果面对的是这样的环境，那么作为SDN评估流程的一部分，企业就需要评估测试工具能否让企业自行测试，以及评估外部评测实验室提供的测试结果。
■ 与现有环境进行整合
对SDN解决方案的评估可能是在独立于现有环境外进行的，如果要把SDN部署到生产网络中，评估流程还需要测试SDN在多大程度上可适应现有基础设施。例如，现有的哪些机制能够让流量在SDN和传统网络之间流动?是否能够对SDN进行扩展，让它们能够在数据中心和分支办公室中同时运行?如何横跨多个数据中心?还应当检查如何将SDN管理和安全组件集成到现有的管理与安全框架内。
■ 专业支持服务
实际上，所有的IT组织在使用SDN方面都缺乏经验，因此一些IT组织选择了由一家或是多家第三方提供的专业服务。可以使用这些服务来辅助评估SDN解决方案，创建和执行POC(概念验证)，或是创建并维护一个或多个网络功能。还可以使用这些服务执行许多功能，例如将SDN集成到现有基础设施内，将SDN管理和安全组件集成到现有管理与安全框架内。
#p#
管理层认同
在规划SDN的不同阶段，需要不同层级的管理层认同。没必要要求管理层必须参加各种研讨会、讲习班或是去下载开源解决方案，而是要他们多花时间去理解这些解决方案的功能，以及存在的限制。
要想获得不同级别管理层的认同，就需要与厂商详细讨论SDN，实施POC或是部署SDN。如果预先知道管理层的顾虑在哪儿，并在SDN规划周期内解决这些顾虑，就更有可能获得管理层的认同。例如，一些组织在安全顾虑没有彻底消除的情况下一般不会愿意部署任何新技术。
IT组织最终需要总结出某种形式的业务案例，以证明部署SDN的明智性。这一业务案例可以包含许多因素，如与管理任务自动化相关的成本节约以及SDN所带来的灵活性。业务案例或许还能让我们找到SDN支持其他核心IT创新的方式，诸如向云计算迁移等。
在未来几年，SDN毫无疑问将对企业网络和网络专业人员的作用产生重大影响。正因如此，企业需要制订一个计划，以便全面评估SDN及其可能的部署前景。
在规划SDN时，需要关注行业中的新进展，如成立了哪些新公司，推出了哪些新产品、新标准，哪些SDN提供商被并购等。同时还要排除行业中的一些噪音，如对SDN准确定义的争论等。
既然SDN目前仅处于起步阶段且正在迅速发展中，因此SDN规划就应当随时调整。我们应当首先确定SDN可帮助实现哪些目标，然后在整个规划过程中使用这一SDN定义。
不要忘记规划流程中必须要包括持续不断的教育。我们目前仍处于软件定义网络的初级阶段，所做的规划必须要切实可行。
