《云数据中心网络与SDN：技术架构与实现》——1.12.4　Geneve

1.12.4　Geneve

Geneve（Generic Network Virtualization Encapsulation，RFC Draft）是NVo3工作组对VxLAN、NvGRE和STT进行总结后提出的一种网络虚拟化技术，希望形成一种通用的封装格式，以便支持数据中心中隧道机制的后续演化。Geneve是于2015年提出的，仍处于草案阶段，不过从Draft中的设计来看，确实是博采众长，具备相当的潜力。目前，很多的vSwitch已经对Geneve提供了支持，一些SmartNIC也能够实现Geneve的硬件卸载。

Geneve采用了VxLAN的思路，是一种MACinUDP的隧道，其封装格式如图1-39所示。之所以没用MACinGRE或者MACinTCP，估计是工作组考虑到GRE头部的可扩展性比较差，不具备可演进的能力。而用TCP头的话，如果仍保持TCP的特性，则维护有连接的隧道开销过大；如果像STT一样处理为无状态的，那么又会存在Middle Box的穿越问题。相比之下，UDP头就没有那么多问题，Geneve作为一种应用层协议不存在可扩展性的问题，而UDP本身的无连接特性又不会带来开销和兼容的问题。至于分片，Geneve建议使用Path MTU Discovery（RFC 1191）来探测传输路径上的MTU。

图1-39　Geneve封装格式

Geneve封装的是以太网帧，外层的报头可以为IPv4也可以为IPv6。UDP Src Port常通过哈希获得，可用于ECMP；Dst Port为IANA分配给Geneve的6081。对于UDP Checksum，Geneve与VxLAN的处理办法相同，并建议使用NIC去做卸载。Geneve Header中的O位为OAM标识，当O位置1的时候，Geneve携带的为控制信令而非Ethernet payload，VNI为24位的租户标识。Geneve Header还提供了TLV格式的Options，以支持后续的功能扩展。

下面再来谈一些Geneve草案中除了封装格式以外的内容，借以简单地分析一下端到端NVo3隧道未来的演进思路。Geneve可采用头端复制的伪广播，不再要求IP Fabric具备组播的能力，降低要求的同时简化了运维的配置工作。Geneve希望底层IP Fabric的传输能够考虑到隧道传输的需求，这在NvGRE和STT的草案中也都提到过，Overlay应该映射出一些字段给Underlay做参考，而不是死守着对传输透明的原则不放。参考NvGRE的设计，Geneve希望可以将VNI作为ECMP的一个参考字段，未来TLV中的一些Option也可能会被用来细粒度地标识流量，以支持精细化的业务定制。参考STT的设计，Geneve讨论了NIC Offload问题，以提升传输性能。