图2.8 Geneve设想的报文结构
在将来，Geneve协议会非常适用于服务链的场景。例如，NSX可以创建一个服务的逻辑连接（如图2.9所示，它可以为VPN服务、防火墙服务、第三方服务之间的关系创建成一个逻辑关系），而这些逻辑链的节点之间需要传递元数据。有了Geneve协议，头部可以进行变更和扩展后，就可以指示报文的下一个链节点，并将报文分类（Classification）的结果传递到一个服务。
图2.9 服务链的逻辑关系
Geneve协议不仅支持将IPv4封装在UDP里，还支持IPv6。该研发项目已提交IETF。或许在不久的将来，我们就可以看到这种技术被标准化，并广泛用于数据中心内部。
3．各厂商的网络虚拟化解决方案
介绍完几种Overlay技术之后，我们就需要对比一下几大厂商基于Overlay技术的网络虚拟化解决方案了。各家厂商的解决方案各有千秋，各有利弊。在这里介绍它们的网络虚拟化解决方案，目的是让读者对整个行业的趋势有一个了解，也让读者了解VMwareNSX网络虚拟化解决方案在行业中所处的地位。
3.1 Cisco ACI解决方案
Cisco ACI是Cisco公司提出的SDN和网络虚拟化解决方案，它的主要组件有应用策略基础设施控制器（APIC）和ACI交换矩阵，其逻辑架构如图2.10所示。
图2.10 Cisco ACI解决方案逻辑架构
1．Cisco应用策略基础设施控制器（APIC）
APIC是Cisco ACI解决方案的主要组件。它是CiscoACI解决方案中实现交换矩阵、策略实施、健康状态监控、自动化和进行中央管理的统一平面。目前，APIC一般是以软件形式安装在Cisco UCS服务器中，一般建议购买3台以上从而实现集群和冗余。
Cisco APIC负责的任务包括交换矩阵激活、交换机固件维护、网络策略配置和实例化。CiscoAPIC完全与数据转发无关，对数据平面只有分发指令功能。这意味着即使与APIC的通信中断，交换矩阵也仍然可以转发流量。
Cisco APIC通过提供CLI和GUI来管理交换矩阵。APIC还提供开放的API，使得APIC可以管理其他厂家的设备。
2．CiscoACI交换矩阵
Cisco在推出ACI解决方案的同时，还推出了CiscoNexus 9000系列交换机。Nexus 9500为机箱式的核心交换机（骨干节点交换机），Nexus9300为2U或3U高度的非机箱式汇聚/接入交换机（枝叶节点交换机）。Cisco Nexus 9000系列交换机可以部署在ACI环境下，也可以独立部署。如果是独立部署，以后也可以升级到ACI环境，但需要其软件和板卡支持ACI才行。这些Nexus 9000系列交换机实现了ACI环境下的底层物理网络，在这套物理网络之上，可以非常便捷地通过VXLAN实现虚拟网络。
除了物理交换机外，ACI解决方案还可以在虚拟化环境中安装CiscoAVS（Cisco Application Virtual Switch），作为虚拟交换机。
Cisco在Nexus 9000交换机中混用了商用芯片和自主研发的芯片——商用芯片处理普通流量，而自主研发的芯片处理ACI流量，即SDN和网络虚拟化中的流量。APIC控制器直接将指令发布给Nexus 9000中的自主研发芯片，再由芯片分布式地处理数据流量。换言之，ACI环境中真正的控制平面是Nexus 9000交换机中的自主研发芯片。这样设计的好处是，数据控制和转发都与软件无关，而是听命于芯片，消除了软件控制可能带来的瓶颈。因此Cisco的ACI解决方案与SDN反其道而行之，其实是一种HDN（H为Hardware）。
对于传统SDN集中了网络复杂性的问题，CiscoACI解决方案中引入了一个完全与IP地址无关的策略模型。这个模型是一种基于承诺理论的面向对象的导向模型。承诺理论基于可扩展的智能对象控制，而不是那种管理系统中自上而下的传统命令式的模型。在这个管理系统中，控制平面必须知晓底层对象的配置命令及其当前状态。相反，承诺理论依赖于底层对象处理，由控制平面自身引发的配置状态变化作为“理想的状态变化”，然后对象作出响应，将异常或故障传递回控制平面。这种方法减少了控制平面的负担和复杂性，并可以实现更大规模的扩展。这套模型通过允许底层对象使用其他底层对象和较低级别对象的请求状态变化的方法来进行进一步扩展。
3.2 在MicrosoftHyper-V中实现网络虚拟化
Microsoft也提供了基于Hyper-V虚拟化平台的网络虚拟化产品，由于它不像NSX、ACI那样有完整的解决方案，因此目前还没有被正式命名，一般被称为HNV（Hyper-V Network Virtualization），它以WindowsServer 2012中的网络附加组件形式加载在Hyper-V的虚拟化平台之上。
Microsoft HNV的研发代码是通过Scratch编写的，且只支持Hyper-V一款Hypervisor，没有进行公开化。也就是说，这种网络虚拟化平台只能部署在纯Hyper-V环境。部署HNV所需的最低Hyper-V版本为3.0，它在WindowsServer 2012（包括R2）操作系统中以角色的方式提供给Hyper-V，作为服务模块加载。在HNV中，使用的是NVGRE协议实现Overlay（之前已阐述）。为了将流量从物理环境迁移到虚拟环境，或者将虚拟网段迁移到其他虚拟网段，需要部署WindowsServer 2012 R2 Inbox Gateway或者第三方网关设备。Microsoft使用Hyper-V可扩展交换API对HNV进行了扩展，我们可以使用PowerShell cmdlets对API进行再编程，最终实现网络虚拟化的自动化部署，进而实现整个数据中心的自动化。
HNV可以通过以下两种方式进行部署：System Center VirtualMmachine Manager（SCVMM）和
HNVPowerShell cmdlets。SCVMM其实也是在后台使用HNVPowerShell cmdlets，在Hyper-V平台上配置HNV组件，有一个统一的图形化界面。
在管理上，SCVMM提供了跨越部署Hyper-V的物理服务器之间的HNV配置管理。同时，SCVMM是一款服务器虚拟化与网络虚拟化一体化的管理工具。
但是，由于Microsoft的网络虚拟化平台并没有基于SDN的理论基础实现，且只能支持Hyper-V平台，很多高级的网络功能也是缺失的，因此它不能算完整的网络虚拟化解决方案。当然，当Hyper-V结合其System Center产品的时候，还是能达到较高的用户使用体验——SystemCenter可以为数据中心从基础架构到上层应用的绝大部分角色提供统一、便捷的管理。
3.3 JuniperContrail解决方案
2012年初，Cisco、Google、Juniper和Aruba公司的几名前高管创立了Contrail公司，专注于SDN解决方案。12月，这家公司以1.76亿美元被Juniper公司收购，其产品和解决方案融入Juniper，Contrail也成为Juniper的SDN和网络虚拟化解决方案的代名词。
Juniper认为，当今数据中心逐渐采用基于OpenFlow的SDN控制器来对物理交换机进行编程，以实现自动化。然而，这种方法具有与基于VLAN的多租户虚拟化方法相似的缺陷，即存在可扩展性、成本和可管理性的缺陷。OpenFlow是基于流表转发的，数据中心内存在数以千计的虚拟机，更有数百种数据流，因此在现今的低成本物理交换硬件中进行流编程是一项艰巨的任务和挑战，或是仅能通过支持流管理的昂贵交换设备加以缓解。此外，这种方法会降低管理基础结构的能力，因为租户/应用程序的状态编程在底层硬件之中，一个租户/应用程序的问题会影响到其他租户/应用程序。
Juniper认为它们的Contrail解决方案通过Overlay提供高级网络特性，从而解决了这些自动化、成本、扩展性和可管理性的问题。所有网络特性（包括交换、路由、安全和负载均衡）都可从物理硬件基础结构转移到Hyperisor中实现，并有统一的管理系统。它在支持系统扩展的同时，还降低了物理交换基础结构的成本，因为交换硬件不贮存虚拟机或租户/应用程序的状态，仅负责在服务器之间转发流量。此外，Contrail系统还解决了敏捷性问题，因为它提供了全部必要的自动化功能，支持配置虚拟化网络、联网服务。
Contrail是一种横向扩展的网络堆栈，支持创建虚拟网络，同时无缝集成现有物理路由器和交换机。它能支持跨公共云、私有云和混合云编排网络，同时提供有助自动化、可视化和诊断的高级分析功能。图2.11是Contrail解决方案的架构。可以看到，Contrail可以控制物理网络，还可以通过XMPP协议管理虚拟化环境中的逻辑网络，它支持的网络功能包括交换、路由、负载均衡、安全、VPN、网关服务和高可用性，此外，它还提供面向虚拟网络和物理网络的可视化和诊断功能，以及用于配置、操作和分析的REST API，并能够无缝集成到云编排系统（例如CloudStack或OpenStack）或服务提供商运营和业务支持系统（OSS/BSS）。