基于软件定义网络的多区域网络虚拟化模型

罗萱　马塞　金耀辉

摘要：提出了一种新的基于软件定义网络的多区域网络虚拟化模型。该模型引入了网络区域的逻辑概念，在同一个区域中使用某种网络虚拟化技术，在区域与区域的边界通过控制平面的统一控制实现不同虚拟网络标识符的转换，完成跨区域交互。该模型可以同时兼容多种网络虚拟化技术，实现高效率、可扩展、大规模的网络虚拟化。

关键词： 网络虚拟化；虚拟网络；软件定义网络；区域

网络虚拟化通过将逻辑网络功能和物理网络设备解耦合，使得网络资源可以方便地整合与扩展，可以大大地降低运营商的资本/运营支出[1-3]。在云计算环境中，网络虚拟化将物理网络划分成多个虚拟网络，在不同的虚拟网络之间进行隔离，以保证租户的隐私和安全。虚拟网络的隔离主要体现在两方面：第一，通过有效的封装技术区分不同的虚拟网络；第二，允许每个租户在自己的虚拟网络内自由定制地址空间。

为了实现网络虚拟化，工业界提出了不少协议标准。虚拟局域网（VLAN）[4]协议是最广泛使用的协议，操作需要较多的人工配置，最多支持4 096个虚拟网络，无法满足大规模数据中心的需求。虚拟可扩展局域网（VXLAN）[5]把二层以太网帧封装到数据报协议（UDP）报文中，通过24比特的VXLAN网络标签（VNI）来区分不同的虚拟网络。VXLAN依赖组播实现地址学习，需要通过VXLAN网关与物理设备（如防火墙/负载均衡器）相连。采用通用路由封装的网络虚拟化（NVGRE）[6]把二层以太网帧封装到通用路由封装协议（GRE）内，通过24比特的租户网络标识（TNI）租户网络。NVGRE需要在端到端之间建立隧道，隧道的数量随终端数量增加以平方速率上升。无状态传输隧道（STT）[7]使用64比特的内容标识虚拟网络，把数据帧先进行分割再封装到传输控制协议（TCP）报文中，利用网卡的硬件加速功能来提升效率。STT在TCP包头中没有维护TCP状态信息，故被称为无状态TCP，隧道模式接近UDP模式。

这些协议各有优缺点，运营商需要根据实际应用场景选择具体的技术路线。在选择过程中，除了技术特点，运营商还面临其他问题：

（1）设备支持

网络虚拟化标准之争愈演愈烈，交换机设备厂商或者支持VXLAN，或者支持NVGRE，很少有设备同时支持两种协议。STT则需要物理网卡支持TCP分段卸载（TSO）或者大段卸载（LSO）。运营商的硬件选择范围受到限制。

（2）技术锁定

现有的网络虚拟化方案不支持多种虚拟化技术并存。运营商一旦选择了某种虚拟化技术，就被锁定了，无法为新的应用需求针对性的选择虚拟化技术。

（3）原有设备兼容

运营商早期购买的交换机/网卡通常不支持VXLAN/NVGRE/STT等协议，如果没有合适的解决方案，只能全部替换，造成巨大浪费。

针对上述问题，我们设计了基于软件定义网络（SDN）[8]的多区域网络虚拟化模型，可以兼容多种网络虚拟化技术，实现高效率、可扩展、大规模的网络虚拟化。主要设计原理是利用SDN对网络物理设备可控制的优势，引入网络区域（Zone）的逻辑概念，在同一个区域中使用某种网络虚拟化技术，在区域与区域的边界通过控制平面实现不同虚拟网络标识符的转换，完成跨区域交互。

1 多区域模型

1.1 区域

区域是一个包含一定数量的服务器与交换机的物理设备集合。整个网络可以根据实际需求划分为若干个区域，不同的区域通过边界交换机互连。区域内的交换机（包括服务器上的虚拟交换机）和边界交换机需要能够支持同一种网络虚拟化技术，实现区域内的虚拟网络隔离。多区域网络虚拟化模型如图1所示。区域X采用VXLAN，区域Y采用NVGRE。每个区域拥有自己的控制平面，负责区域内的配置。

1.2 虚拟网络片段

虚拟网络可以在一个区域内，也可以跨多个区域。虚拟网络在每一个区域中被称为一个虚拟网络片段，多个虚拟网络片段通过域间的边界交换机级联成一个虚拟网络。如图1中，虚拟网络A仅分布在区域X中，拥有一个虚拟网络片段A1；虚拟网络B分布在区域X和区域Y中，拥有两个虚拟网络片段B1和B2。

1.3 虚拟网络标签

虚拟网络标签是实现虚拟网络隔离的关键。虚拟网络标签的格式为{区域：标识符，[区域：标识符]……}，利用每一个区域内所采用网络虚拟化技术的虚拟网络标识符唯一标识其对应的虚拟网络片段，从而在不增加任何封装开销的前提下唯一标识一个虚拟网络。

1.4 标识符转换

当虚拟网络有多个虚拟网络片段时，需要在边界交换机处对报文进行解封装和重新封装，更换标识符，使得两个虚拟网络片段可以互通。边界交换机为SDN交换机，需要同时支持所有相邻区域的网络虚拟化技术。边界交换机根据SDN控制器下发的配置，实现动态标识符转换，支持虚拟网络的动态修改。边界交换机标识符转换过程如图2所示。

1.5 虚拟网络管理者

虚拟网络管理者负责管理虚拟网络与虚拟网络片段之间的映射关系。虚拟网络管理者通常作为云计算平台的一部分，向用户/应用提供定义良好的应用编程接口（API），用于动态创建/删除/更新虚拟网络。当收到请求时，虚拟网络管理者根据虚拟机的分布、物理网络拓扑以及区域的划分，将虚拟网络嵌入到物理网络中，计算需要多少个虚拟网络片段以及每个虚拟网络片段的边缘交换机端口，分配虚拟网络标签，然后调用对应区域的控制平面，配置交换机建立区域内的虚拟网络连接。与此同时，虚拟网络管理者将虚拟网络片段之间的对应关系发送给SDN控制器，由SDN控制器负责下发配置给边界交换机，实现标识符转换。

2 实现

2.1 区域划分

除了同区域交换机必须支持相同的网络虚拟化技术，区域划分策略还可能受到其他因素影响：

（1）虚拟网络规模

VLAN最多支持4 096个虚拟网络。通过划分N个区域，将一个虚拟网络尽量嵌入到一个区域中，理想情况下可以将支持的虚拟网络数目扩大N倍。

（2）系统开销

GRE隧道的数目随着终端数目增加以平方速率增长。通过合理控制区域中的服务器/交换机数目，可以有效控制系统开销。

2.2 虚拟网络嵌入

虚拟网络嵌入是非线性编程-硬（NP-hard）问题，计算复杂度随物理网络资源规模增加而急剧增加[9]。在我们的模型中，虚拟网络嵌入分为两步：虚拟网络分解为若干个虚拟网络片段，区域内虚拟网络片段的嵌入。

为了实现简单，我们尽量将虚拟网络嵌入到一个区域内，降低跨区域引起的标识符转换开销。在某些情况下，虚拟网络会被分为多个片段：

（1）策略需要

当网络区域划分与其他策略（如灾备区域划分）结合起来时，将一个虚拟网络划分成多个虚拟网络片段，使得一个虚拟网络中的虚拟机能处于不同的区域中，实现灾备等功能。

（2）物理资源受限

一个区域的物理资源是有限的，包括服务器和交换机。当新增需求超过了区域内可用资源时，可以将需求分布在多个区域中。例如，某个用户需要150台2核CPU的虚拟机，连接在一个虚拟网络中，而每个区域可用CPU都只有200核。此时，虚拟网络将被迫分为多个片段，通过多个区域的物理资源提供用户所需要的150台2核CPU的虚拟机。

区域内虚拟网络片段的嵌入可以使用任意已有的嵌入算法。

2.3 区域内网络虚拟化

区域控制平面有很多现成的解决方案，可以集成到我们的模型中，只需要其能提供API供虚拟网络管理者调用，配置虚拟网络连接。

下面将介绍如何用SDN实现区域内网络虚拟化。

我们将区域内的交换机分为两种：边缘交换机和中间交换机。所有与虚机直接相连的交换机（即虚拟交换机）都是边缘交换机，其他交换机则是中间交换机。边缘交换机负责对数据包进行封装/解封装，支持开放流协议（OpenFlow）[10-11]，可以通过OpenFlow控制器进行管理。中间交换机只要能够支持隧道的建立，可以不用支持OpenFlow。为了更好地控制虚拟网络之间的安全隔离以及防止广播包的洪泛，所有边缘交换机上添加一条最低优先级的流表，默认丢弃所有的数据包。当有虚拟网连接需要建立时，通过添加更高级别的流表来允许此虚拟网的数据包通过。

控制平面主要包括3个模块：

（1）拓扑管理模块

控制器使用链路层发现协议（LLDP）[12]实现物理拓扑自动发现。对于支持OpenFlow协议的交换机，通过发送带LLDP数据包的Packet-out消息，触发相邻OpenFlow交换机发送Packet-in消息，从而获知两台交换机之间的连接情况。对于不支持OpenFlow协议的交换机，控制器通过简单网络管理协议从交换机的管理信息库读取相邻链路信息。

（2）路径计算模块

根据输入的虚机位置，调用路由算法寻找网络路径。模块与路由算法解耦和，可以根据需求动态调用不同的路由算法。

（3）虚拟网络服务模块

此模块负责维护虚拟网络片段与区域内物理网络之间的映射关系。当虚拟网络片段中有虚机加入/离开/迁移时，虚拟网络服务模块调用路径计算模块计算新的路径，下发配置给交换机，更新虚拟网络片段。

对于虚拟网络片段VN-X，当虚机VM-X被创建后，OpenFlow控制器在虚机VM-X所在的边缘交换机上创建一个端口P-X，并将端口P-X连接到虚机VM-X。如果虚机VM-X是虚拟网络片段VN-X在此边缘交换机上的第一台虚机，从此边缘交换机建立到其他拥有属于虚拟网络片段VN-X虚机的边缘交换机的隧道。

然后，控制器在边缘交换机上配置3条流表：

（1）给从端口P发出的报文加上对应的虚拟网络标识符I，并发送到对应的隧道中，使得虚机V发出的报文能够进入虚拟网络。

（2）将拥有相同虚拟网络标识符I的广播包去除标识符并发到端口P，使得虚机V能收到所属虚拟网络的广播包。

（3）将拥有相同虚拟网络标识符I且目的媒体访问控制（MAC）地址为虚机V的MAC地址的单播包去除标识符并发到端口P，确保虚机V只收到应该收到的报文。

2.4 边界交换机

边界交换机需要支持OpenFlow协议和相邻区域所采用的网络虚拟化技术。当虚拟网络VN-X仅在一个区域内时，边界交换机上无需做相应配置。如果虚拟网络VN-X分布在边界交换机相邻的M个区域时，OpenFlow控制器从边界交换机建立到这M个区域中所有拥有属于虚拟网络VN-X的虚机的边缘交换机的隧道，然后在边界交换机上配置流表：

（1）对于广播包，逐一更换相应的标识符，从接收到的隧道转发给所有其他虚拟网络VN-X的隧道。

（2）对于单播包，根据MAC地址，更换相应的标识符，转发到连接到目的虚机所在边缘交换机的隧道。

3 演示

我们搭建了一个演示环境，用于证明多种网络虚拟化技术可以共存在多区域网络虚拟化模型中。演示环境如图3所示。Floodlight[13]是一款基于Java开发的开源OpenFlow控制器，支持OpenFlow协议v1.0版本。我们在Floodlight基础上做了扩展实现SDN控制器。OpenStack[14]是开源云计算平台的领导者，其中的Neutron项目负责提供虚拟网络连接服务。Neutron采用可扩展的Plugin架构，支持使用不同的网络虚拟化技术。Floodligth为Neutron实现了一个Plugin架构[15]，我们在这个Plugin基础上，实现了虚拟网络管理者。虚拟网络管理者在启动的时候会载入一个配置文件。配置文件中记录了区域划分信息、每一个区域支持的网络虚拟化技术以及可用的标识符区间。在演示环境中，网络被划分为3个区域，其中区域1和区域2采用VLAN，区域3采用GRE。虚拟网络嵌入使用OpenStack默认的调度算法。

3.1 区域内连接与隔离

我们使用OpenStack控制节点创建两个虚拟网络A和B，使用相同的地址空间。区域2内创建了4台虚机，其中虚机2和虚机3属于虚拟网络A，分别分配地址10.0.0.3和10.0.0.4；虚机4和虚机5属于虚拟网络B，分别分配地址10.0.0.2和10.0.0.3。控制器在区域2内创建了2个虚拟网络片段A2和B1，分别分配标识符VLAN ID 10和VLAN ID 20。

我们使用Ping命令测试虚机之间的可达性，并使用Tcpdump工具进行抓包。测试结果显示，虚拟2和虚机3之间能够相互访问，但不能访问虚机4和虚机5，也侦听不到虚机4和虚机5发出的广播包；反之亦然。这说明虚拟网络A和B拥有独立的地址空间，并且相互隔离。

3.2 跨不同网络虚机化技术区域的

虚拟网络

区域2和区域3使用了不同的网络虚拟化技术。在3.1节基础上，我们使用OpenStack控制节点在区域3内创建虚机6，并加入虚拟网络B。控制器会在区域3内创建虚拟网络片段B2，分配标识符GRE key 100；然后配置边界交换机B，对区域2的标识符VLAN ID 20和区域3的标识符GRE key 100进行转换。测试结果显示虚机6能与虚机4和虚机5相互访问，不能访问虚机2和虚机3。这表明虚拟网络可以跨不同网络虚拟化技术区域实现。

3.3 跨相同网络虚机化技术区域的

虚拟网络

区域1和区域2使用了相同的网络虚拟化技术。在3.1节基础上，我们使用OpenStack控制节点在区域1内创建虚机1，并加入虚拟网络A。控制器会在区域1内创建虚拟网络片段A1，分配标识符VLAN ID 20；然后配置边界交换机A，对区域1的标识符VLAN ID 20和区域2的标识符VLAN ID 10进行转换。测试结果显示虚机1能与虚机2和虚机3相互访问；虽然虚机4和虚机5在区域2内使用的标识符也是VLAN ID 20，但不能与虚机1互相访问。这表明虚拟网络可以跨相同网络虚拟化技术区域实现，不同区域内的虚拟网络标识符空间独立。

4 结束语

本文提出了一种新型的多区域网络虚拟化模型，将物理网络划分为多个区域，可以同时兼容多种网络虚拟化技术，实现网络平滑升级。我们基于开源软件搭建了一个原型系统，验证了模型的可行性。

参考文献

[1] SHEN W， MINATO K， TSUKISHIMA Y， et al. Implementation of a novel management development [C]//Proceedings of the Network Operations and Management Symposium （APNOMS）， 2013 15th Asia-Pacific. 2013

[2] CHOWDHURY N M， BOUTABA R. Network virtualization： state of the art and research challenges [J]. Communications Magazine， IEEE， 2009， 47（7）： 20-26.

[3] CHOWDHURY N M， BOUTABA R. A survey of network virtualization [J]. Computer Networks， 2010， 54（5）： 862-876.

[4] IEEE 802.1q. VLAN [S]. IEEE， 2005.

[5] IETF drafts. VXLAN： A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks [S]. IETF， 2014.

[6] IETF drafts. NVGRE： Network Virtualization using Generic Routing Encapsulation [S]. IETF， 2014.

[7] IETF drafts. A Stateless Transport Tunneling Protocol for Network Virtualization （STT） [S]. IETF， 2013

[8] WIKIPEDIA. Software-defined networking [EB/OL]. （2014-02-28）. http：//en.wikipedia.org/wiki/Software-defined_networking.

[9] YU M， YI Y， REXFORD J， et al. Rethinking virtual network embedding： substrate support for path splitting and migration [J]. SIGCOMM Computer Communication Review， 2008，38（4）： 19-29.

[10] MCKEOWN N. OpenFlow： Enabling Innovation in Campus Networks [J]. SIGCOMM Computer Communication Review， 2008，38（4）： 69-74.

[11] OpenFlow specification v1.4.0. [EB/OL]. （2014-02-28）. https：//www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf.

[12] IEEE 802.1AB-2009. Station and Media Access Control Connectivity Discovery [S]. IEEE， 2009.

[13] Floodligth [EB/OL]. （2014-02-28）. http：//www.projectfloodlight.org/floodlight/.

[14] OpenStack： Open Source Cloud Computing Software [EB/OL]. （2014-02-28）. https：//www.openstack.org/.

[15] Floodlight plugin for neutron： [EB/OL]. （2014-02-28）. https：//github.com/openstack/neutron/tree/master/neutron/plugins/bigswitch.