OpenFlow硬件的直接控制问题

　　许多供应商和网络从业者仍然希望通过开发OpenFlow硬件而在数据中心实现网络虚拟化。但是，Casado指出，有很多因素决定这是不可行的。第一个问题是网络供应商的生态系统。他说：“您要求交换机供应商在交换机上实现OpenFlow，而这样做又不会给他们带来好处，因为在一定程度上，这样做实际上在剥夺他们的价值。我在2007年编写了第一个OpenFlow协议，从那时开始人们开始发布相关产品，但是只有少量有用的OpenFlow交换机。任何有有用OpenFlow交换机的人都还会再购买一个控制器，而我可以肯定，他们会采用绑定使用他们的控制器和交换机，因为这样他们才能维持对客户环境的控制。至于创建活跃的社区，业务关系决定了这是非常困难的事情。”

　　许多网络供应商已经在交换机上实现了OpenFlow，那么Casado的“有用的OpenFlow交换机”是什么意思？他解释说，大多数供应商在开发交换机时并没有配备对数据中心真正有用的足够的通用转发表容量。在典型的交换机ASIC（专用集成电路）中，有一个ACL表、一个2层表和一个3层表，他说：“他们都是特殊用途的表。”这些表中没有一个能够支持数据中心级的OpenFlow。

　　Casado说：“在OpenFlow中：表中有11个元组查表，这是非常通用的东西，而且您拥有很多这样的表。为了OpenFlow，许多供应商会直接覆盖其中一个表（它可能包含5,000条实体），然后，他们会在这个表中硬塞入OpenFlow实现。但是，这个芯片实际上并不是为这个而造。OpenFlow仍然试图纠正这个问题，但是这非常困难。”

　　Casado指出，现在的大多数OpenFlow交换机流的转发表都非常适合用于研究和实验。他说：“但是，数据中心内的流与流量的数量决定了必须执行一些与3层网络类似的操作。OpenFlow并不适合用于创建数据中心交换机的转发结构。”

　　Nicira-VMware解决方案中是否存在适合OpenFlow硬件的空间？

　　这是否意味着Nicira及其父公司VMware愿意仅仅关注于软件层面？Casado说，他的技术需要在三个方面与硬件进行交互，而这要求在标准OpenFlow上增加其他功能。他说：“首先是QoS（服务质量），队列越多越好。您在硬件中部署得越多，您向客户提供的QoS层次就越多。如果我有8个队列，那么我只能提供8个SLA（服务水平协议）。如果我有一百万个队列，那么我可以为每一个租户签订一个SLA。”

　　QoS和类似的硬件特性需要更简单的以太网操作和控制与管理（或OAM）模型，好让Nicira及其他技术都可以在物理与虚拟负载上修复和调试这些功能。网络虚拟化技术还需要与未虚拟化的传统工作负载的顶级交换机进行交互。Casado说：“您需要控制顶级机架交换机，才能够让物理负载进入虚拟网络，这需要类OpenFlow接口。”

　　最后，网络虚拟化控制器需要与网络设备（防火墙、应用交付控制器等）进行交互，而这也需要“类OpenFlow”接口。Casado说：“我认为，OpenFlow太过于底层。所以，我们已经提出了一个新技术：OVSdb-config。我们将用它管理Open vSwitch和OpenFlow。它允许我们管理更上层的状态。这是我们期望人们使用的东西，但是它实际并不太重要。为什么呢？只要是开放、鼓励创新而且能够完成工作，任何协议都可以。”