中文版Geneve02

中文版Geneve02

译者声明： 本文是Geneve02（http://tools.ietf.org/html/draft-gross-geneve-02）的中文版；译者经过与各位Geneve原作者邮件沟通，Geneve作者之一的Jesse Gross认为对Geneve的中文翻译版本，适用于http://trustee.ietf.org/license-info中section 3(c)ii 的如下条款："to translate IETF Contributions and IETF Documents into languages other than English, and to copy, publish, display and distribute such translated IETF Contributions and IETF Documents in full and without modification”，并且中文翻译版本遵循与原文档同样的版权要求。在此对Geneve的各位作者的支持表示衷心感谢。

网络工作组互联网草案通告状态：Standards Track 

 过期时间：2015年4月28号草案

原作者：J. Gross ，T. Sridhar VMware P. Garg MicrosoftC. Wright Red HatI. Ganga IntelP. Agarwal BroadcomK. Duda AristaD. Dutt CumulusJ. Hudson Brocade发布日期：2014年10月25号

中文译者：北京-小武 （E_mail：night_elf1020@163.com）

通用网络虚拟封装Geneve: Generic Network Virtualization Encapsulation draft-gross-geneve-02

 摘要：网络虚拟化（Network Virtualization）涉及了大量功能之间的协作，这些功能的提供者包括软件或硬件等形式的隧道终端、传输用途的Fabrics和集中控制集群等在内的设备。这些隧道试图集合不同元素来组成完整的系统，导致了所有这些组件对隧道的需求都产生了影响。如果一个隧道协议能跟上系统演进的步伐，那么其灵活性就是最为重要的方面。本草案描述了Geneve机制，一种被设计用于对这些功能和需求变化来识别与调整的协议。备案录现状：本互联网草案的提交严格遵守BCP 78和BCP 79的所有条款。互联网草案是IETF（Internet Engineering Task Force）的工作文档（working documents）。需要注意的是其他工作组也有可能对此草案有所贡献。至今的互联网草案可参见http://datatracker.ietf.org/drafts/current/。互联网草案文档有效期是6个月，并且这期间可能随时会被其他文档更新、替换甚至废弃。将还处于完善中的互联网草案作为参考材料或者不作为“进行中工作”的引用是不合适的。本草案将在2015年4月28号过期。版权须知 2014年版权属于IETF Trust机构和该文档的作者们。所有权利保留。自从该文档发布的当天起，文档遵守BCP 78约定和IETF 的《Trust’s Legal Provisions》 相关的IETF文档规则(http://trustee.ietf.org/license-info)。请仔细参阅这些文档条款，因为它们描述了你对本文档的权利和限制。从文档提取的代码构成部分必须包含《Trust Legal Provisions》第四章所描述的简化版BSD许可证文本，并且不提供简化版BSD许可证里所描述的任何担保。目录通用网络虚拟封装 21.介绍 41.1用语约定 51.2 术语 52.设计要求 72.1 控制平面独立性 82.2 数据平面扩展 92.2.1 高效的实现 92.3 使用标准的IP Fabrics 103 Geneve封装细节 113.1 IPv4 Geneve帧格式 113.2 IPv6 Geneve帧格式 143.3 UDP头部 173.4 隧道头部字段 183.5 隧道选项字段 203.5.1 选项处理 214 实现和部署方面的考虑 224.1 Geneve在IP中的封装 224.1.1 IP分片 224.1.2 DSCP 和 ECN 234.1.3 广播和组播 234.2 网卡Offloads 244.3 内部VLAN处理 255 互操作性问题 266 安全考虑 267 IANA考虑 278 致谢 289 参考文献 289.1 引用标准 289.2 参考目录 28作者信息 311.介绍网络长期以来就有包括隧道、Tagging和其他等各种各样的封装机制。然而网络虚拟化功能的兴起为其带来了一股新的吸引力，并随着新协议的引入封装机制的种类在数量上有了一定的增幅。在这个领域的大量协议涌现，包括从VLANs [IEEE.802.1Q-2011] 和MPLS [RFC3031]到最近的VXLAN [RFC7348]、NVGRE [I-D.sridharan-virtualization-NVGRE] 和STT [I-D.davie-stt]等，经常导致人们对新的封装格式需求的思考和引发其对新出现的网络虚拟化是什么的疑问。大量的封装协议企图用承载网络或网桥将相连的两个区域进行简单隔离，然而网络虚拟化将传输网络视作在集成系统中为多个组件之间提供了互联的功能。在很多方面，这个系统类似于机架交换机：IP底层承载网络起到背板（backplane）功能，而边缘的隧道终端则对应的是线卡的作用。依据这个观点来来看，从元素据必要性的数量和传输节点方面来讲，隧道协议的需求有着显著的不同。现在正进行的某些工作，比如VL2和NVO3工作组[I-D.ietf-nvo3-dataplane-requirements]已经描述了一些关于数据平面须支持的网络虚拟化的特性。然而另外一种定义需求的方式，则是需要依据数据报文来传递系统的状态信息。确定的说，对于元数据的使用不再是一个陌生的概念——几乎被用于虚拟化技术的所有协议里，都使用至少24bits的空间标记码（identifier space），来用于隔离不同租户的一种方式。这一点经常被用来描述解决VLAN仅有12bits大小的限制问题；并且当在上述场景下甚至任何场景下，确切来说作为一个租户的标记，1600万的空间已经是一个非常大的范围。然而实际情况是元素据并不是仅仅用于标识租户，而是对其他信息进行的编码将非常快的填满这个空间范围。事实上，与机架交换机的线卡之间交换元素据的标记（Tags）比起来，24bits范围的标识符用起来也是相当少的。这类元数据（metadata）有几乎数不尽的用途，涉及领域从存储简单安全策略的入端口信息，到为插入高级中间件的基于内容的服务。现有的隧道协议每一次尝试去满足新需求的各个方面，都仅是通过改变控制平面的实现和发展来快速呈现相关数据。另外，一些软件及硬件的组件和控制器都有不同的优势和演化速度，这一点实际上应该被看做一个优点而不是阻碍或限制。本草案描述了Geneve机制，就是想一种通过提供一个对于隧道封装框架来避免上述问题，而不是指定整个系统。1.1用语约定关键词"MUST"， "MUST NOT"， "REQUIRED"， "SHALL"， "SHALL NOT"，"SHOULD"， "SHOULD NOT"， "RECOMMENDED"， "MAY"， and "OPTIONAL"在本文档中用法的解释如同RFC 2119中的描述。在本文档中，这些词语仅仅被全大写的时候才如此被解释。这些单词小写的情况下并不适用于在RFC-2119标准的描述。1.2 术语NVO3框架[RFC7365]里规定了网络虚拟化里常用的很多概念。另外，在本文档里如下的几项有其特定的含义：Checksum Offload：通过网卡实现的一种优化技术，这项技术能够在硬件网卡发送和接收报文时，分别实现对于上层协议校验和的计算和检验。如果没有该项功能，通常包括IP和TCP/UDP校验和的这些工作，需要在软件协议栈中进行计算。Clos Network：一种将网络Fabrics组合成比单个交换机容量大很多，且能保持无阻塞带宽的一种多点互连技术。ECMP被用于将数据流分载到多条链路和由Fabric组成的交换机上。可能是“leaf and spine”结构也可能是“fat tree”拓扑。ECMP：Equal Cost Multipath，一种通过对报文头部字段哈希计算后，从多条等价最优路由中选择其中一跳的一种路由机制，用来在避免单条流被重排序的同时，达到对带宽的较大利用的目的。Geneve：Generic Network Virtualization Encapsulation，本文档描述的隧道协议草案。LRO：Large Receive Offload，在接收端对应于LSO的功能，表示该处能将多个协议分段报文（主要是TCP）合并成的较大的数据单元。NIC：Network Interface Card，网卡可以是隧道终端或传输设备的一部分，能够处理Geneve报文或者有助于Geneve报文处理过程的设备。OAM：Operations，Administrationand Management，一系列用于监视网络并排查问题的工具。Transit Device：属于承载网络组成部分中隧道路径的一个转发单元。一个传输设备可能有能力解析Geneve数据帧格式，但并不封装或终结Geneve报文。LSO：Large Segmentation Offload，在很多商用网卡上提供了这种功能，该功能允许传给网卡的数据单元字节数比网卡MTU大一些的，这样可以提高性能，并且网卡要负责将数据单元分成多份并附带有正确的协议头部。对应到TCP/IP具体的功能，这个特性就是众所周知的TSO（TCP Segmentation Offload）。Tunnel Endpoint：将以太网帧或IP数据报文封装到Geneve头部里的一个组件，反之亦可。作为最终的隧道元素据的处理者，终端对隧道报文头部的解析和解释能力，有最高级别的需求。隧道终端可由软件实现或是靠硬件实现，甚至是软硬件结合来实现。终端大多数是一个NVE的某个组件，但也有可能位于中间件里，或一个NVO3网络中其他的组成元素。VM：Virtual Machine，虚拟机器。2.设计要求Geneve 被设计用于支持网络虚拟化的使用场景，在这些场景里一种通常的做法，是利用隧道起到背板的作用，将这些设备之间建立互联，互联的设备包括虚拟监视器（hypervisors）里的虚拟交换机、物理交换机、中间件或其他器件设备上。通过CLOS网络构成的任何一个IP网络均可被用作一种承载方式，并且使用ECMP链路是一种通常的选择，用于在所有连接点之间提供持续服务的对分带宽（Bisectional Bandwidth）。如图1所示，例中包括了一个虚拟监控器，用以连接物理服务器的TOR，和一个WAN上行端口. 该上行端口以一个简化的Clos网络作为承载网，于其上使用Geneve隧道与另外一端相连。这些隧道被用于封装和转发来自于相连组件, 例如虚拟机或物理链路的数据帧。 图1 Geneve部署示例为了可以满足网络虚拟化的需求，在承载网络和重叠（Overlay）网络中，隧道协议应该有能力使用每一种网络设备上差异（和演进）的功能。这就导致了对数据平面隧道协议的如下需求被提出：●数据平面应具有足够的通用性和可扩展性，满足对现在和将来控制平面的支撑；●隧道组件必须都能在软件和硬件的上有高效的实现，这些设备只要满足最低的共同特性，在最低要求的共同功能方面，则没有任何约束性限制(restricting capabilities)；●在已有的IP Fabric上有很高的性能;这些要求将在后续章节有更进一步的详细描述。2.1 控制平面独立性尽管一些网络虚拟化的协议已经包含了一个控制平面作为隧道格式标准的一部分（最著名的例子是在VXLAN的原始标准中描述了一个基于控制平面的组播学习），这些标准大多被认为是数据报文格式的大量描述。然而在VXLAN数据帧格式的基础上，确实可以看到被创建的控制平面的多种多样性。数据格式的标准化有一个非常明显的优势：大多数的协议仅仅存在一些表面的区别，并且重复的工作几乎没有多少优点。但是相同的论断是不适用于控制平面的。因为对于控制平面，它们往往在很多基本的方面都有非常大的不同。不同的控制平面可以有各种各样的需求、目标和部署场景。应此很难将其标准化。面对这种现实情况下，Geneve旨在提供一种比较纯粹的隧道格式标准，以满足实现多种控制平面的需求，而实现方式是通过解析的手段而不是从众多隧道协议中选择其中的一种。本文同时还提出了一种共享的数据格式，以及增加其不过时的可能性，即使将来控制平面有所增强。2.2 数据平面扩展为有效地达到控制平面现在和将来所需要的这种级别的灵活性，需要一个选项基础结构，以允许新的元数据类型能被定义、部署以及终止或撤销。通过鼓励每一个设备商的核心领域的独立开发，来实现使用选项也允许不同的产品的差异性，从而加速在整个领域的快速发展的步伐。到现在为止实现选项最通常的机制是TLV格式（Type-Length-Value）。需要注意的是，选项不仅能用于支持数据帧的非线速转发，这和数据帧的隔离（Segregate）与直接转发一样的重要（对虚拟机来说，前面给出的在入端口的基于安全策略和插入（interposition）服务的例子，都需要在数据报文中添加Tag）。因此，从简化链路的角度出发，本可以对控制帧来做扩展性方面的限制，但是这将无法满足设计上的需求。2.2.1 高效的实现软件的灵活性和硬件的性能往往是冲突的，并且很难被解决。对于一系列给定的功能，很明显的需求是让性能方面可被最大化的使用。然而今天那些不能达到如此高性能速率的新特性，也并不意味着不被允许在这些设备上面运行。因此对一个协议来说的高效的实现，意味着一系列常规功能可以被跨平台来合理处理，这样在某些合适场景下的，更多高级特性通可以通过一种优雅的机制进行处理。在协议中可变头部长度和选项的使用，对该协议在硬件中是否真的能高效被实现的问题，会导致经常被质疑。针对于Geneve，为了回答这个问题，首先应将硬件分为两种类型：隧道终端和传输设备。终端必须能够解析可变头部，包括各种选项，并且实施相应动作。自从这些设备主动参与处理Geneve协议，它们也很大程度上受Geneve协议影响。然而隧道终端作为数据的最终处理者，传输设备可以根据它们的输出来调整设备的接收功能。随着设计被用于添加到终端的新功能变得足够的成熟后，在设计的时候，支持的选项可以用有序的限制和其他技术来减少解析工作。传输设备或许能够解析选项和参与Geneve报文处理。然而作为非终结设备，他们不用封装产生或终结Geneve的隧道报文。传输设备对Geneve报文的处理工作的参与是可选的项。另外，无论隧道终端还是传输设备都可能使用网卡的Offload功能，比如Offload的校验和功能，以提高Geneve报文的处理性能。Geneve可变长度头部的出现，不应影响隧道终端和传输设备对这些Offload功能的使用。2.3 使用标准的IP FabricsIP技术已经很牢固的占据了传输机制领域的地位，并且随着时间上多次的技术演进，使其更强壮、有效和成本低廉。所以使用IP Fabrics作为Geneve的传输网络是理所当然的。幸运的是IP封装和寻址的使用，有足够的能力通过在网络的交换和路由技术，来实现传输报文到正确终端的主要目标。另外，最近所有的承载Fabrics被设计成使用数据流的并行模式，这样在多个交叉链路之间，对每个单独的流的传输负载，并没有引入重新排序的问题。这些ECMP（Equal Cost MultiPathing）技术通常的做法，是通过解析报文字段和对报文的地址及端口号来做哈希计算，以选择具体的出口链接。然而如果没有额外的封装协议数据流信息的话，隧道的使用经常导致ECMP性能的降低的事实，就会被Fabric的设计所隐藏，并且仅仅终端地址能被用于此时的哈希计算。因为Geneve技术在这些现有Fabrics上能够良好的工作是有需求的，所以从封装报文中提取隧道头信息是非常有必要的。最常用的技术就是使用UDP的源端口，这点将在3.3章节讨论。3 Geneve封装细节Geneve帧格式是一个简化的封装在IPv4或IPv6的UDP里的隧道头部组成。一个固定的隧道头部提供了控制信息，以及基础级别的功能和关注简洁性方面的互协作能力。这个头部经常后面跟随着一系列可变选项，以便于将来进行创新。最后，内容包含了一个表征类型的协议报文数据字段，该字段作用类似于以太网帧类型。后续的章节，将提供传输在以太网上有以太网内容的Geneve帧格式示例。3.1 IPv4 Geneve帧格式 IPv4中Geneve报文头部格式如图2。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1Outer Ethernet Header:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Destination MAC Address | Outer Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ethertype=0x0800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Outer IPv4 Header:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |Flags| Fragment Offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time to Live |Protocol=17 UDP| Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Destination IPv4 Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Outer UDP Header:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port = xxxx | Dest Port = 6081 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| UDP Length | UDP Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver| Opt Len |O|C| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Virtual Network Identifier (VNI) | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Options |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inner Ethernet Header(example payload):+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Destination MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Destination MAC Address | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ethertype of Original Payload | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || Original Ethernet Payload || || (Note that the original Ethernet Frame’s FCS is not included) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Check Sequence:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| New FCS (Frame Check Sequence) for Outer Ethernet Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 图2 IPv4中Geneve报文头部格式3.2 IPv6 Geneve帧格式IPv6中Geneve报文头部格式如图3所示。0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1Outer Ethernet Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Destination MAC Address | Outer Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Outer Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ethertype=0x86DD |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Outer IPv6 Header:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Payload Length | NxtHdr=17 UDP | Hop Limit |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| | + Outer Source IPv6 Address + | |+ +| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| |+ Outer Destination IPv6 Address +| |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port = xxxx | Dest Port = 6081 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Geneve Header:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Ver| Opt Len |O|C| Rsvd. | Protocol Type |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Virtual Network Identifier (VNI) | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Variable Length Options |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Inner Ethernet Header(example payload): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Destination MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Destination MAC Address | Inner Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Inner Source MAC Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Ethertype of Original Payload | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || Original Ethernet Payload || || (Note that the original Ethernet Frame’s FCS is not included) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Check Sequence:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| New FCS (Frame Check Sequence) for Outer Ethernet Frame |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 图3 IPv6中Geneve报文头部格式3.3 UDP头部使用封装的UDP（RFC0768）头部，来沿用以太网和IP网络无连接网络的语义，并为路由器的沿用ECMP功能提供更多的信息。因此头部字段主要体现有以下几个：源端口：一个根据隧道终端的报文入方向选择的端口号。此源端口号应该对某个特定封装流的所有报文是一样的，以用来防止当使用不同的转发路径时的重排序现象。通过多条链路将流进行均匀分布，达到将封装报文头部的源端口号就应该被用于哈希计算的目的，比如传统的五元组方式等。因为一个端口号代表了一个流表识，而不仅仅是一个真正的UDP连接，因此整个16bits范围都可能被用于来扩大用于计算的信息量目的端口：IANA已经为Geneve草案分配了固定的知名目的端口号6081。这个端口号必须被双向流都能使用。虽然知名端口号应该被默认使用，但是实现中推荐的做法是采用可以配置的方式。UDP长度：整个UDP报文长度，包括UDP头部的长度。UDP校验和：无论是IPv4还是IPv6（RFC6935）的传输封装报文，其UDP校验和可能是全零。当一个校验和为全零的UDP报文到达时，其必须被接收和解封装。如果入方向的隧道终端选择用非零值来封装报文校验和，其必须是正确计算得到的UDP的校验和。这样一旦接收到这样的报文，出方向的终端必须检验其校验和的有效性。如果校验和是不正确的，那么报文必须被丢弃。反之，报文必须被接收并得到解封装。当在网络可靠性不高，或者报文没有被其他校验算法或循环冗余检验确保的情况下，推荐开启计算UDP报文的校验和的功能，以来保护Geneve报文头部与其可选项。3.4 隧道头部字段版本号(Ver，2 bits)：现在版本号是 0。终端对于接收到的未知版本号的报文必须丢弃。无隧道终结Geneve报文处理流程的设备，对于接收到的未知版本号的报Geneve文，必须将其作为带有未知Payload的UDP报文进行处理。可选项长度(Opt Len，6 bitsbits)：可选字段的长度，以4字节倍数计量，不包括8个字节的隧道固定头部的长度。所以这个长度对于Geneve头部来说，最小为8字节，最大为260字节。Payload头部的开始地址，可以通过使用Geneve头部末端作为基址进行偏移获得。O (1 bits): 代表该报文是OAM 帧，其包含了一些控制信息而不是数据内容。终端一定不能转发这些报文内容，并且传输节点一定不允许试图解析并处理它。因为这些控制信息帧是不定期的，所以建议终端用一个高优先级队列来传输这些报文（例如，将ASIC转发的这些报文有意的定向到特定的CPU，或者到一个网卡上单独处理这些控制流的报文）。传输设备也必须不改变这些依赖于报文比特级内容的转发行为，比如ECMP的链路选择等。C (1 bits): 关键选项标志，可以有一个或多个选项设置关键项的比特位。如果这个比特位被设置了，那么隧道终端必须解析这个选项列表，以来解析各个关键选项。在不支持选项解析的设备里，那么在基址头里基于C比特已经被设置了话，该数据帧就必须被丢弃。如果这个比特位没有被设置，隧道终端可能通过选项长度提取所有选项并且转发这个已被解封装的帧。传输设备不允许丢弃或修改这些报文的任何比特的内容。 保留位（Rsvd，6 bits）： 保留字段必须在传输过程中内容为全零，并且接收到时对该字段不关心。 协议类型（Protocol Type ，16 bits）：协议字段的类型出现在Geneve头部后面。这个遵循了EtherType在以太网中的惯例做法，其在以太网中的典型代表值是0x6558。 虚拟网络标识（VNI ：Virtual Network Identifier，24 bits）: 一个在虚拟网络中特定元素的标识，在很多情况下可能代表了L2层的分段，然而控制平面定义的是解封装报文在语义上的转发逻辑。VNI可能被用于当做ECMP转发决策的一部分，或者当通过多CPU进行负载均衡时，作为一种对包含在封装报文里重叠地址空间的区分机制。保留字段（Reserved，8 bits）：保留字段必须在传输过程中内容为全零，并且接收到时对该字段不关心。传输设备必须维持转发行为的一致性，且无须考虑选项长度（Opt Len）的值，包括ECMP链路选择等。这些设备，应能够在没有使用重排序引起的低速路径的方式下，来完成对包含选项报文的转发功能。3.5 隧道选项字段0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Option Class | Type |R|R|R| Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Variable Option Data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 图4Geneve 选项格式Geneve头部基址紧跟的是零个或多个以TLV（Type-Length-Value）格式的选项字段。每一个选项包含了一个4字节的可选头部长度和基于类型解析得到的一个不定长度的选项数据，如图4所示。可选类型（Option Class，16 bits）：类型字段的命名空间。IANA将被请求来创建一个“Geneve选项类”，来为那些对创建可选类型感兴趣的团体、技术专家和设备提供商等分配标识。每一个团体可能分配相互独立的类型来进行试验和快速创新。期待随着时间的推移，某几种特定的可选项被众人所熟知，并且一些给定的实现当中，也是使用从这些众多源中选择而来的选项类型。另外，IANA将被请求保留一个具体的特定范围，以用于标准化和试验的选项。类型（Type，8 bits）：类型表明了在这个选项中包含的数据格式。选项主要被设计用于未来的扩展和创新，因此这些选项的标准化形式将被在另外单独的文档中定义。如图5所示，显示了C比特位在类型字段里的位置0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |C| Type | +-+-+-+-+-+-+-+-+ 图5 C比特位位置选项类型的最高顺序比特位，表明了这是否是个关键选项。如果一个接收终端没有识别出这个选项并且这个比特被置位，那么这个数据帧必须被丢弃。如果任何选项的这个关键比特被置位，那么在Geneve报文头部的基址的C位也必须被置位。传输设备不能丢弃所有这些基于此比特的报文。对于丢弃所有未知关键选项的需求，适用于整个隧道终端系统，而不是某个特定的实现组件。例如，在一个由转发ASIC和通用CPU组成的系统里，这并不意味着整个报文必须在ASIC里丢弃。一种可能是实现是通过为慢速路径异常处理（slow-path exception handling）的限速控制通道将报文送上CPU。保留位（R，3 bit）：选项控制标记，保留备将来使用。保留字段必须在传输过程中内容为全零，并且接收到时对该字段不关心。长度（Length，5 bits）：选项的长度，指不包括选项头部的部分并且以4字节的整数倍来计量，所以每一个选项的全部长度在4和128字节之间。报文所含的所有选项的长度和，并不等于报文基础头部的选项长度（Opt Len）的时候，该报文是无效的并且必须被接收到的终端无任何动作的丢弃。可变选项数据（Variable Option Data）：通过类型来解析得到的选项数据。 3.5.1 选项处理Geneve选项的本应是在隧道终端设备里产生和处理。选项可能被传输设备随着隧道路径被处理。本文档仅仅是明细了隧道终端对选项的处理。文档将来版本将提供传输设备对选项的处理细节。不处理Geneve报文选项字段的传输设备，应该像其他UDP数据帧那样处理Geneve数据帧，并且维持转发行为的持续性。在隧道终端，对选项字段的产生和解析最终在控制平面，这点超出了本文档的讨论范围。但是为了确保各种设备的互操作性，终端设备上有两点需要确保： ◎接收终端必须丢弃包含选项类型中C比特被置位的未知选项的报文；◎发送终端不能假设选项可以按照传输路径中的接收者的顺序来被处理。4 实现和部署方面的考虑4.1 Geneve在IP中的封装作为一种基于IP的隧道协议，Geneve沿用了现有协议的很多属性和技术。对这些的应用将在后续详细描述，当然通常情况下，大多数常规能在IP层或IP隧道可以用的概念都能在Geneve的内容里继续起作用。4.1.1 IP分片为了防止报文分片并发挥最大性能，最好的方法是确保物理网络的MTU至少大于等于加上网络隧道头封装后的报文MTU。手工或者更上层的配置（比如TCP MSS 调整）可能被用于确保分片行为绝不会发生，然后在某些场合下这些配置可能是不可行的。Geneve协议的报文在IPv4环境中传输时，强烈推荐使用通过设置IP头部的DF位的路径MTU发现（[RFC1191]，[RFC1981]）的功能（这点在IPv6中是默认配置）。在传输网络上使用路径MTU发现，将为封装端提供关于链路的软件状态，这可能被用于来防止或减少在虚拟网络中的分片。注意，一些实现可能不能支持分片或者其他一些普通的IP头部功能，比如选项或扩展头部等。4.1.2 DSCP 和 ECN当使用Geneve封装IP报文（包括基于以太网的方式）时，有多个选项来描述DSCP和ECN从报文内部映射到传输的隧道中，并且在接收端进行反方向处理。RFC2983列出了把IP头部内部和外部的DSCP映射的一些考虑。网络虚拟化可以说是一种更加显著的贴近于所描述的管道模型，即隧道报文头部的DSCP值基于一个策略来设置（也可能是一个固定值，一种情况是基于内部流分类，或者是一些其他流分组的机制）。统一模型的各方面（其将内部和外部的DSCP看成一个字段，通过对报文头部出入方向的复制来实现）也可适用，比如具备基于传输标记的隧道出方向来重标记报文头部内部的DSCP的能力。然而这种统一模型不可能和网络虚拟化在概念上持续一致，其主要目的在于提供一种针对封装流量和物理网络之间的强隔离功能。文档RFC6040描述了这种基于IP隧道来显示使用ECN的机制，并且通过IP内部来传送拥塞标记。这种行为应当在Geneve封装在IP报文内部的时候亦可适用。4.1.3 广播和组播两个终端的Geneve 隧道可能是点对点的单播，也可能是使用广播或组播地址。但从某种意义上说并不需要内部和外部的地址都匹配。举例来说，在一个不支持组播的物理网络中，封装组播数据流可能要多个单播隧道或者基于策略的单播转发到本地来替代（可能这里需要被替代）。而对于支持组播的物理网络，可能使用其硬件复制报文的功能优势，来实现对报文的封装。这种情况下，组播地址在物理网络的分配就取决于相应的租户信息、封装组播组或其他因素。这些组播组的分配是控制平面的一个组件，并且超出本文档的讨论范围。当组播技术在实际环境中被使用时，Geneve 头部的C位可能被一组设备的复杂功能所使用，因为每一个设备可能仅仅关注那些，不是关键的但对其自身却具有重大含义的选项。4.2 网卡Offloads现代的网卡都能提供各样的Offloads功能，以便能提高报文的处理效率。很多种Offloads的实现，仅需要能够提供简易方式来对封装报文进行解析（例如校验和的Offloads等）。然而，优化技术比如LSO（TCP Segmentation Offload）和LRO（Large Receive Offload ）等引入了一些它们自身可以进行的选项处理工作，因为他们必须对多个报文之间进行复制或合并。这些情况下，就要求对Offloads逻辑不需要改变的前提下，能再处理新引进的选项。为了实现这个功能，并允许简单的处理规则，下面针对这些的选项在其定义上做了些限制：◎当使用LSO功能时，网卡必须复制整个Geneve报文头部和全部选项，包括这些设备未知部分在每一个相关部分的内容。然而，支持设备的一个给定的选项定义可能覆盖这条规则，并且导致在支持设备上可能有不同的行为。相反的，当开启LRO功能时，这个网卡可能假定对这些选项的二进制比较，足以确保相等结果的正确性，并且把相同Geneve头部的报文可能进行合并。◎选项的排序是无意义的，并且不同选项顺序但拥有相同选项的报文可能会被有相似的处理流程；◎网卡使能Offloads功能时决不能丢弃未知选项的报文，包括那些被标记的关键的报文。对一个已有的Geneve实现使用Offloads功能时，上面所列举的例子在实现中则没有任何要求。然而这些Offloads机制，现在正广泛地被部署到商用网卡里，这里所描述的规则，其目的也在于能够通过多种设备有效的处理现在和将来的所有选项。4.3 内部VLAN处理Geneve 机制可以封装大量范围的各种协议，并且一个现有的实现中可能仅对一个范围的常用协议的子集进行支持。然而因为以太网被期望能广泛部署，那么对于增加在以太网帧中封装内部的VLAN行为的描述，就是非常有用的。像任何一个其他协议一样，支持内部VLAN头是一个可选项。在很多情况下，封装VLAN的使用可能会因基于安全和实现的考虑可能被不允许。然而在其他情况下让VLAN在Geneve隧道中实现透传功能时，则会非常有用。最终导致对VLAN Tag无论是在隧道终端入方向还是在出方向的处理，都是基于终端或（和）控制平面的配置，并且这些是一类没有明确定义的数据格式部分。5 互操作性问题仅仅从数据平面来看，Geneve机制没有引入任何互操作性问题，因为大多数设备上其就是一些UDP数据帧。然而，现有的虚拟网络环境里已经有大量数目的隧道协议被部署，因此要对这些协议的传输和共存上有一些可用性的考虑。因为Geneve协议是网络虚拟化中最常用三种协议（VXLAN、NVGRE和STT）功能的一个超集，因此其应该有明确方向，以可以对现有控制平面，用最少的改进使其在Geneve协议上面能照常运行。无论新旧协议的数据帧格式只要支持相同的功能集，就没有需要再进行费力的转换——终端将直接与其他每一个使用任何常规协议的设备进行通信，即使这种协议可能与其他是不同的，甚至都在一个单一的整体系统里。作为传输设备主要功能是将数据帧基于IP头部进行转发，所有的协议是很类似的，并且这些设备不会引入额外的互操作性问题。为了对传输功能有所帮助，这里强烈建议实现里支持Geneve协议和现存隧道协议的同步操作，因为一个单一节点能与一个其他混合节点进行正常情况下的通信，是被期待的。最终，较早的协议可能因长久不被使用而被逐步淘汰。6 安全考虑作为一个UDP/IP报文，Geneve报文没有继承任何安全机制。最终当一个攻击者访问了传输IP报文的承载网络时，其已经有能力窃取和欺骗报文。合法但恶意的终端也可能被用来伪造隧道头部的标记，以来获取其他租户所属网络的访问权。在一个特定的安全领域，比如被单一服务提供者操作的一个数据中心，最普通和最高性能的安全机制是隔离受信任的组件。隧道流量只能在一个单独的VLAN里传播，并且在任何不被信任的边界处被过滤掉。另外，隧道终端的操作，应该在环境里只能被服务供应者控制，比如虚拟监视器自身而不是一个客户的VM。当Geneve报文穿越多个不被信任的链路时，比如公共因特网时，IPSec（RFC4301）可能被用于提供认证和（或）数据报文的加密处理。如果远端隧道终端不能被完全信任，例如其取决于客户的约定，那么审查所有的隧道元素据，来防止租户基于跳的攻击也可能是有必要的。7 IANA考虑IANA已经为Geneve分配了UDP的6081目的端口作为知名端口号。根据公布的相关内容，注册处应该更新，以能引用本文档。原始的请求是：服务名：geneve传输协议：UDP申请人：Jesse Gross 联系方式：Jesse Gross 描述：Generic Network Virtualization Encapsulation (Geneve)引用：本文档端口好：6081另外，IANA已被请求来创建“Geneve选项分类”的注册机构，以用来分配选项类型。这个应该是一个已登记的16进制数字以及用于描述的字符串。在标准选项被IETF审核[RFC5226]时，其中的标识符0x0-0xFF应该被保留用于标准化，并且0XFFFF用于实验用途。另外，标识符将被分给任何对创建Geneve选项感兴趣的机构，并且基于先到先得的原则。没有初始注册分配的。8 致谢笔者希望对Martin Casado、Bruce Davie和Dave Thaler等人的奉献、反馈和有用的建议等表示衷心的感谢。9 参考文献（译者注：为便于查阅，对参考文献部分未做中文翻译）9.1 引用标准 [RFC0768] Postel，J.，"User DaTagram Protocol"，STD 6， RFC 768，August 1980. [RFC2119] Bradner，S.，"Key words for use in RFCs to Indicate Requirement Levels"，BCP 14，RFC 2119，March 1997.[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.9.2 参考目录[ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2013,. [I-D.davie-stt] Davie, B. and J. Gross, "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", draft-davie- stt-06 (work in progress), April 2014.[I-D.ietf-nvo3-dataplane-requirements] Bitar, N., Lasserre,M.,Balus,F.,Morin,T.,Jin, L. and B. Khasnabish, "NVO3 Data Plane Requirements", draft-ietf-nvo3-dataplane-requirements-03 (work in progress), April 2014.[I-D.sridharan-virtualization-nvgre]Sridharan, M., Greenberg, A., Wang, Y., Garg, P., Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan-virtualization-nvgre-06 (work in progress), October 2014.[IEEE.802.1Q-2011]IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.[RFC1981] McCann, J. Deering, S. and J. Mogul, "Path MTU Discovery for IP versin 6", RFC 1981, August 1996.[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000.[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.[RFC4301] Kent, S. and K. Seo, "Security Architecture for theInternet Protocol", RFC 4301,December 2005.[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.[RFC6935] Eubanks, M.,Chimento, P. and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013.[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L.,Sridhar,T., Bursell,M., and C.Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014.[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center(DC) Network Virtualization", RFC 7365, October 2014.[VL2] Greenberg et al, , "VL2: A Scalable and Flexible Data Center Network", 2009. Proc. ACM SIGCOMM 2009作者信息 Jesse Gross VMware， Inc. 3401 Hillview Ave. Palo Alto， CA 94304 USA Email: jgross@vmware.com T. Sridhar VMware， Inc. 3401 Hillview Ave. Palo Alto， CA 94304 USA Email: tsridhar@vmware.com Pankaj Garg Microsoft Corporation 1 Microsoft Way Redmond， WA 98052 USA Email: pankajg@microsoft.com Chris Wright Red Hat Inc. 1801 Varsity Drive Raleigh， NC 27606 USA Email: chrisw@redhat.com Ilango Ganga Intel Corporation 2200 Mission College Blvd. Santa Clara， CA 95054 USA Email: ilango.s.ganga@intel.comPune Agarwal Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 USA Email: pagarwal@broadcom.com Kenneth Duda Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 USA Email: kduda@arista.com Dinesh G. Dutt Cumulus Networks 140C S. Whisman Road Mountain View, CA 94041 USA Email: ddutt@cumulusnetworks.comJon Hudson Brocade Communications Systems, Inc. 130 Holger Way San Jose, CA 95134 USA Email: jon.hudson@gmail.com