虚拟网络中的虚拟机与外部网络通信的需求催生了网络虚拟化中网关（Gateway）技术的出现。现有虚拟化平台网关产品有：IBM SDN VE Gateway[1]（VE，表示for Virtual Environment，SDN VE是IBM为虚拟化环境提出的SDN解决方案，该方案基于IBM商用版本DOVE），Microsoft Hyper-V Network Virtualization Gateway[2]，以及F5和Iron Networks分别为Hyper-V Network Virtualization平台提供的第三方硬件网关等。

1.1 网关基本结构
图1为一个Gateway的基本结构。首先，Gateway在网络虚拟化环境中的位置是介于多个网络之间，Gateway需要连接3个网络，管理网络、内部虚拟网络、外部网络。需要连接管理网络的原因是由于Gateway本身作为网络虚拟化环境中的一个组件，其本身一样需要接受虚拟化网络平台中央控制器的管理。内部虚拟网络，即指需要与外部网络进行通信的虚拟Overlay网络。外部网络，指本虚拟网络之外的网络，可能是该虚拟网络所在云中的其他虚拟网络，也可能是该虚拟网络所在云中的物理网络（如打印机、存储服务器（storage server）等本地资源）[3]，还可能是在混合云方案下的远程网络（访问远程资源，及一个常用的应用场景：将私有云中的一些服务向公有云迁移），当然同样可能是Internet。

图1 网关（Gateway）结构图

网关是介于多个网络之间的，因为虚拟网络是采用封装协议使虚拟网络间相互隔离的，那么要实现虚拟网络间的通信就得解封装，故而网关中两大基本组件之一的转发部件中就需包含隧道端点（TEP，Tunnel End-Point），负责封装和解封装。另一基本部件是地址转换部件，包含地址转换模块（NAT，Network Address Translation），负责内部地址和外部地址的相互转换。具体步骤如下：

从内部虚拟Overlay网络向外部网络发送数据包：

1）每个虚拟网络有自己的网关地址（与虚拟网络在同一网段），如虚拟网络在10.30.1.x网段，则当其需要与外部IP通信时会首先将包发给该虚拟网络的网关地址（如10.30.1.100）所在物理机（即我们这里所说的Gateway，其物理地址如172.16.1.100），注意，此处的Gateway对应的物理机并不一定是整个物理网络的网关，我们可以认为是虚拟网络的网关在这台物理机上。

2）由图一可知虚拟网络是与网关的“转发模块”相接，也就是说数据包到此处后先进行解封装，去掉封装的物理网络头。

3）然后数据包进入“地址转换模块”，查找NAT地址转换表，将内部IP转换为外部IP（若进入外部网络之后仍然需要保持虚拟网络间的相互隔离，那么每个虚拟网络的ID会与外网中的一个VLAN ID相对应，除转换为外部IP外还需给数据包打上相应的VLAN tag），NAT转换表的生成和维护需依靠管理网络。

从外部网络向内部Overlay网络发包：

该过程与虚拟网络到外部网络是相反的过程，外部网络是与NAT模块相接的，发送数据包首先到达NAT模块。经过地址转换后进入转发模块封装之后发送给虚拟网络。

由上可知在网络虚拟化环境中的网关（Gateway）技术的关键在于解决虚拟网络与非虚拟网络间的通信问题。

在定义服务边缘之前，首先介绍一下策略（policy）的概念。策略指一对通信实体间的连接特征，这些特征指定ACL，QoS，安全，性能等。以图2为例[7]，它展示了一个三层应用，图中的三层服务器分别是：负载均衡器，应用服务器和数据库。在Internet的流量进入应用前先经过了一个防火墙，负载均衡器与应用服务器间经过一个SSL加速器，用来加速HTTPS通信；应用服务器的数据要有效的存到数据库中，所以经过了一个压缩引擎。这里的防火墙，SSL和压缩引擎即分别为三对通信服务器间的连接的特征，即所谓策略（Policy）。每个策略有它相应的策略动作（Policy Action），如防火墙隔离特定的流量，这些动作由网络服务设备（Network Service Appliance），即我们常说的MiddleBox，来执行。

服务边缘（Service Edge），指为虚拟化网络所提供的网络服务（如防火墙、负载均衡、DHCP、域名服务（DNS）、网络地址转换（NAT）等）的统称。网络服务由网络服务设备（即MiddleBox）提供，旨在提供保护、管理、提高应用及服务性能。网络服务设备包括专用的网络设备（Dedicated Network Appliance）及虚拟的网络设备（NFV，Network Function Virtualization，网络功能虚拟化），使以前在专用硬件中实现的网络功能在软件中实现，从而可以在标准的x86平台上运行[ Linux Foundation于2014年10月推出一个新的开源项目OPNFV，旨在建立一个NFV平台。]。多个网络服务设备可以按一定顺序（由Policy指定）组成服务链（Service Chain）。

图2 一个典型三层应用[7]

这里所说的服务边缘接入方式指网络虚拟化平台如何与服务边缘相连接，即网络虚拟化平台采用何种方式使网络中的流量按照租户的配置经过相应的网络服务设备。理想的网络服务接入应包括以下特性：

1）正确性：流量要以租户指定的顺序正确地经过各网络服务设备

2）灵活性：经过各网络服务设备的顺序应该要易于配置（configure）并易于重配置 （reconfigure）

3）高效性：流量不应该经过非必需（unnecessary）的网络服务设备。

下面介绍两种服务边缘的接入方式。一种是Cisco的vPath解决方案，在“连载-2”中介绍Cisco虚拟化平台时有简单涉及，此处进行详细介绍。另一种是IBM的Dove虚拟化平台（商业版，非Open Dove）所采用的Policy-aware Switching方案。

Cisco使用GRE隧道技术或VXLAN-GPE隧道技术（相较VXLAN协议只能封装以太网帧，VXLAN-GPE对内部包类型进行了扩充，在“连载-3”中进行过详细介绍，此处利用了其可封装NSH（Network Service Header）包的特点而采用了此隧道协议），通过在原始数据包之前封装NSH头[5]，将与服务相关的信息置于此额外添加的包头中。Cisco并不要求所有的网络服务设备都支持NSH协议，对不支持NSH协议的网络设备，Cisco提供了NSH代理协助处理，在经过该设备前由它去掉NSH头，经过该设备后，又由NSH代理插入NSH头。Overlay网络添加NSH头后的数据包格式如下：

外部包头（Outer Header）|封装头（Encapsulation Header） | NSH头 | 原始包（Original Packet）

NSH中的信息包括以下两部分：

1）途径的网络节点或网络服务设备添加的或它们需要的元数据
2）指定经过网络服务设备的路径信息

NSH头是变长的，见图3，包括4部分：基本头（Base Header）、服务路径头（Service Path Header）、必需内容头（Mandatory Header），可选变长内容头（Optional Variable Length Context Headers）。

图3 NSH头格式

基本头：提供关于整个NSH头和原始数据包的一些信息，格式如下：

图4 基本头（Base Header）

Ver：2位的版本号；O：指明负载（被封装的原始数据包）为OAM包；C：指明NSH中是否有关键元数据TLV（TLV为可选变长内容头中的基本单位，具体介绍见后面）；Length：NSH头的长度（6位，以4字节的字为单位），由此可见NSH头最长为26X4=256字节，NSH要求此域必须大于等于6，即NSH最少为24字节（意为不包含可选可变长内容头）；MD Type：元数据类型，指基本头之后的NSH头的格式，目前只定义了一种类型0x1，即图3中所示格式；后续Next Protocol：指负载的类型，目前支持如下3种：

0x1 : IPv4
0x2 : IPv6
0x3 : Ethernet
服务路径头：提供路径相关信息，格式入下：

图5 服务路径头

由两部分构成：3字节的服务路径ID（Service Path ID）、1字节的服务下标（Service Index）。服务路径ID用来表示一条服务路径，参与的节点必须使用此标识符进行路径选择。服务下标用来表示在一条服务路径中的位置，当经过一个服务节点或代理节点时由这些节点对其值进行减1操作，类似于TTL，可用于检测服务路径中是否有环路。它协同服务路径ID进行路径选择。

必需内容头：携带元数据。由图3可以看到共有4X4=16字节的必须内容头。NSH协议的IETF草稿对必须内容头的分配方式给出了如下的一个指导性质的例子（guidelines）（并不是说一定要按这样的顺序，携带这些类型元数据）：

图6 必需内容头分配格式

网络平台内容（Network platform context）: 提供了网络节点共享的与网络平台相关的一些元数据信息，如入端口信息、封装类型。

网络共享内容（Network Shared Context）：和任何网络节点相关的元数据，如应用信息、租户信息。

服务平台内容（Service Platform Context）：提供服务节点共享的服务平台相关的元数据，如用于负载均衡决定的标识符。

服务共享内容（Service Shared Context）：提供与服务节点相关的及服务节点间共享的一些元数据，如应用分类相关的一些信息如应用的类型。

可选变长内容头：携带元数据，此部分为变长。可变长的内容头的基本单位是TLV。其中，一个TLV Class一般对应一个供应商（vender），Type指此内容域中携带的信息类型，为TLV Class规定的类型范畴中的某一个，Len为可变长元数据的长度，以4字节的字为单位。

图7 TLV格式

NSH协议支持以下动作：
1）插入/去除NSH头。这一动作在一条服务路径的起点和终点被分别执行；或者某些服务节点根据本地policy，确定此数据包必须改变服务路径时；在NSH代理处也会执行这一操作。

源主机发出的数据包首先经过一个服务分类器（Service Classifier，具有服务分类功能的设备或软件），由此分类器确定该数据包是否需要服务，为其插入NSH头。在一条服务链的末端，最后一个节点会去除NSH头。当一个中间节点对数据包进行重分类而导致其更换服务路径时，必须在此处去掉旧的NSH头，为其加入新的NSH头。

2）选择服务路径。整个服务路径上的节点使用NSH头来选择其服务路径上的下一个服务节点。

3）NSH头更新。途径的服务节点，必须对Service Index进行减1操作，若Service Index为0时，必须丢弃此数据包。

4）服务策略（policy）选择。根据NSH头的内容域提供的元数据（如流量分类信息等）在服务节点确定具体的策略内容。

总结：NSH要求服务节点可以识别NSH协议，即对服务节点（或称Middlebox）进行修改使其可识别NSH协议，对不支持NSH协议的服务节点，由NSH代理协助处理。且由服务节点根据服务路径ID进行路径选择。

以IBM DOVE（商用版）接入网络服务边缘的方式[6]为例。此部署由两部分构成：中央Policy（策略）控制器和Policy-aware Switches（简称pSwitch）。中央Policy控制器下发相应Policy给对应pSwitch，pSwitch收到Policy后将它转化为规则（Rule），规则的格式是[上一跳，流选择符]：下一跳，其中流选择符即流的一些特征，可以是完整的五元组，也可以其中的一部分，当流到来时，以流选择符和上一跳进行规则匹配。本部署与NSH方式不同，不对服务节点（或称Middlebox）修改，而对Switch进行修改。对服务节点的部署采用Off-path的方式，将服务节点挂载在pSwitch上。Off-path与On-path如下图8所示。On-path表示该网络服务设备位于数据通路上，即一旦网络服务设备发生故障，网络路径会断掉，如图8中两个紫色的服务节点任一坏掉，两个黄色的主机节点就无法通信。而Off-path方式，服务节点不在数据路径上，服务节点的故障不会影响网络的可达性。

图8 On-path和Off-path

pSwitch包含两大部分：Switch Core和Policy Core，如图9所示，前者为正常以太网交换机的功能，后者作用是将帧重定向到服务节点上。pSwitch分的两大类：无状态的pSwitch（stateless pSwitch）和含状态的pSwitch（stateful pSwitch）区别即在于两者Policy Core的构成不同。

其中，无状态pSwitch的Policy Core包含4个模块：

1)RuleTable（存储rules）
2)inP模块（帧进入pSwitch时进行处理，作用是识别前一跳、查找RuleTable、对帧进行封装、将帧发往Switch Core）
3)outP模块（帧离开pSwitch时进行处理，因为服务节点是未经修改的，所以在此处要对帧进行解封装成普通以太网帧，然后将帧发送出去）
4)FailDetect模块（检测挂载在该pSwitch上的服务节点是否在运行）。

其中，pSwitch的每个端口上都有InP、OutP、FailDetect三个模块。pSwitch的基本思路是数据包从一个端口进入pSwitch后，由Policy Core中在此端口上的Inp模块确定下一跳服务节点，并以上一跳服务节点的和下一跳服务节点的MAC地址封装数据包。如图11所示，其中的Type（以太网帧类型），由IEEE以太网帧类型字段注册机构为pSwitch分配了特定的帧类型，Info为一字节的Policy版本信息（用于同步相关节点上的Policy）。Policy Core将封装好的数据包发给Switch Core（正常以太网交换功能），进行以太网交换。Switch Core将封装帧发往与下一跳服务节点相连的端口，经过该端口上的OutP模块，去掉外层封装变为正常的以太网帧发给下一跳服务节点。当一个服务节点有多个实例（instance）时，（为了增加系统的可用性，如一个pSwitch上挂载几个防火墙），这时，pSwitch采用一致性哈希的方法进行实例选择（详见[6]）。

含状态的pSwitch在此基础上又添加了一个NextHopDb（下一跳数据库），其中包含两个表FwdTable和RevTable。只需对每个流的第一个帧进行服务节点的实例选择，然后将选择的结果加入FwdTable表，后续帧直接查找这个表而不再查找RuleTable，即不再需要做实例的选择。RevTable由OutP模块构建，提供了缺省的相反方向的用于InP模块查找的表项，如OutP在该端口上收到一个帧：(IPA ortA ->IPB : PortB)，其中IPA为防火墙的IP，IPB为服务器B的IP，则其会在RevTable中添加 (IPB : PortB ->IPA ortA, prevHop=server B, nextHop=firewall )。三种表的查表顺序是先查FwdTable，如果查表不命中，再查RuleTable，如果查表不命中，再查RevTable。

图9无状态pSwitch

图10 含状态pSwitch

图11 Policy Core封装后的帧格式

因为Policy是由中央策略控制器集中分发，故存在多台pSwitch上的policy同步问题。为此，pSwitch采用了松同步机制（Loose Synchronization）：

1）策略控制器通过TCP连接分发policy给每个pSwitch

2）所有pSwitch收到完整的policy信息

3）由控制器发送一个信号触发所有pSwitch采用最新版的policy。这里的信号是一个数据包，采用此种同步机制的原因是，相对于较长的policy信息(由多个数据包组成),单个数据包同时到达各交换机的几率更高。因为依然不能确保所有信号包绝对同时到达，故称之为松同步机制。

综上所述，pSwitch采用中央策略控制器进行集中的策略分发，并通过对与服务节点相连的交换机进行配置，使得流量灵活地经过租户指定的服务节点。缺点就是需要修改交换机。

参考文献
[1] Implementing IBM Software Defined Network for Virtual Environments：http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg248203.html?Open
[2] Hyper-V Network Virtualization Gateway Architectural Guide：https://technet.microsoft.com/en-us/library/jj618319.aspx
[3]Hyper-V Network Virtualization Gateways - Fundamental Building
Blocks of the Private Cloud：[url=http://www.nappliance.com/mnv/mnvgateway.pdf%20[4]%20OPNFV]http://www.nappliance.com/mnv/mnvgateway.pdf[/url]
[4] OPNFV：https://www.opnfv.org/
[5] Network Service Header：http://tools.ietf.org/html/draft-quinn-nsh-00#section-2
[6] A Policy-aware Switching Layer for Data Centers：http://ccr.sigcomm.org/online/files/p51-josephA.pdf
[7] DOVE: Distributed Overlay Virtual nEtwork Architecture：http://domino.research.ibm.com/library/cyberdig.nsf/papers/D7D93A33CF54F46585257A4C004947BD/$File/H-0315.pdf

作者简介：
付斌章（博士），男，中国科学院计算技术研究所副研究员，主要研究方向为大规模计算机系统高性能互连网络，包括数据中心网络和片上网络等。

吴洁,女,中国科学院计算技术研究所,硕士研究生,主要研究方向为数据中心网络虚拟化.

刘静一,女,华中科技大学,硕士研究生,主要研究方向为数据中心网络虚拟化.注: 该文为其在中科院计算所实习期间工作.

• 本站声明：本站原创文章可以转载，请注明来自 SDNLAB
• 本文链接：http://www.sdnlab.com/12079.html