vini:真实可控的网络实验

翻译的是VINI网站In VINI Veritas: Realistic and Controlled Network Experimentation 这篇文章

原文http://www.cs.princeton.edu/nsg/papers/vini_sigcomm_06/

VINI：真实且可控的网络实验

摘要：

这篇文章描述了VINI，一种虚拟化网络基础架构，这使网络研究人员可以在真实的环境下评估他们的协议和服务，并且提供了对网络状态的高度可控性。研究人员可以利用VINI来部署和评估他们的想法，采用真实的路由软件，真实的网络流量负载，真实网络事件。为了让研究人员更方便的设计他们的实验，VINI支持在同一物理基础设施上同时运行多个采用任意网络拓扑的实验。这篇文章解决了如下几个非常重要的设计问题：哪些概念和技术可以实现在同一固定的物理基础设施上的灵活性，真实性和可控性的实验（多种拓扑和在不同路由算法间切换的能力）？我们首先说明VINI的高层次上的设计思想，和虚拟化一网络的问题。然后介绍PL-VINI，一个在PlanetLab上的VINI实现，并运行了同一Slice上Internet实验。我们对PL-VINI的评估表明对于评估新协议和新服务，PL-VINI提供一个真实的可控的环境。

1．简介

研究人员不断的提出新的路由协议和服务来提高Internet的性能，可靠性和伸缩性。在最终把新协议或新服务部署到Internet上前，在真实的网络环境中测试其性能优点和可行性是一个非常重要的环节。然而，由于需要网络服务提供商提供的网络设备和授权的网络操作来部署新协议新服务测试，这些前提条件对于研究者评估新协议是难以满足的。因此，研究人员只能选择以模拟，仿真，或者设计人工的模型和拓扑来测试，由于没有真实的流量，不能满足真实性测试的需求。所以最理想的情况是，研究人员可以既能满足真实性，又能在可控的状态下运行实验。

如果对网络层或更低的层只有较低的可见度和控制能力，即使在网络层上层进行控制，也是很难达到较好的评估效果的。可伸缩覆盖网络（Resilient Overlay Network, RON）^[1]在基础网络设施基础上，围绕着性能和可达性问题通过中间宿主来控制数据传输，RON不需要改动下层基础网络设施，可以为真实用户提供服务来评估它的效率，然而系统设计者必须等待网络链路失效的发生。更糟糕的是它不能产生失效日志和注入这种链路失效——RON必须依靠不停地探测来检查断路，这样就引入了一种需要探测断路和测量准确性之间的权衡^[2]。所以最理想的情况是，研究人员可以在特定的时间注入链路失效，并在链路失效等类似网络事件中精确采集测量数据。

研究人员为了更好的评估新的网络协议和网络服务，就应该在真实性和可控性之间作出选择。研究机构需要这样一种实验平台，能够达到如下4个目标：

1. 运行真实的路由软件：研究人员应该可以在他们的实验中运行传统的路由软件来评估协议的扩展效果，在普通的网络组件基础上评估新的服务。

2. 揭示真实的网络状态：研究人员应该可以在真实的网络拓扑和路由配置环境下运行实验。实验应该能够反映外来事件来检查系统行为，例如来自现实的Internet上的路由协议信息。

3. 控制网络事件：研究人员应该可以人工的注入现实中不常发生的网络事件（例如链路失效和瞬时的网络拥塞），来提高实验可控性和准确测量这些事件。

4. 承载真实的网络流量：研究人员应该可以在真实的终端中传输应用数据，这样可以测验真实的端到端性能和接收终端系统的反馈。

满足这4个目标需要建立虚拟网络的工具和基础架构来部署他们

2．VINI的用户模型

研究人员在设计，实现和部署新的网络协议或网络结构的时候，不但需要依靠新协议或新网络结构在很多方面的支持，也需要网络允许在多种特性上提供不同程度的控制和实现——这些特性可以是拓扑结构（包括连接带宽），失效模型和传输负载。虽然现在有很多类似VINI这样的工具来评估网络协议和网络结构，但是我们相信VINI比其他工具更独到的一个优点是，它能给予实验者提供更大程度上的控制性和真实性。这样就是VINI成为了一种不但适合做可控实验，也适合部署长期运行服务的环境。

可控性就是研究人员把外来事件引入到系统的能力，包括传输失败，传输变化等等。研究人员或者协议开发者经常需要在不同的网络条件环境下控制实验来学习协议或者系统的行为。例如一个这样的实验，为了研究链路失效或节点失效在一个修改了的协议的上下文环境下是如何影响端到端性能的，这需要我们能够向路由系统中注入失效事件，而不是简单的等待链路失效或节点失效的发生。把VINI所提供的可控性和其他一些提供可控性的模拟工具（如ns-2^[13]或SSFNet^[14]）或者仿真平台（如Emulab^[15]，DETER^[16]，Moelnet^[17]，WAIL^[18]，和ONL^[19]）做比较，VINI能让研究人员在可控的环境下评估真实的网络协议或网络结构原型。

真实性是网络研究人员把网络协议和网络结构原型部署到一个与真实网络条件尽量相似的环境下的能力。尽管可以根据不同的真实模型，用一个人工的手段来生成模拟真实网络的各种特征，但是VINI的哲学就是提倡最好的提供真实性的方法就是把原型部署到真实的网络中去。例如，我们将要在第五部分看到的，VINI允许研究人员在Abilene网络的物理节点组成的虚拟网络上部署和测试协议，而不是由现有的模拟器或仿真平台提供的虚假真实性。

VINI对于那些最终同时需要真实性和可控性的实验是最有效的。这些实验可以被分为两类：可控实验和长期运行的服务。虽然VINI通过人工注入流量和网络事件，可以支持可控实验，但是这些实验在Emulab这样的测试床上却不能很好的运行。但是一个可控的实验需要一定程度的对流量，网络事件，或拓扑结构的可控，最终也是希望这种这种合并的真实特征能够从VINI中获得巨大的好处。

一旦一个可控的实验表明了新想法的价值，这个协议就可能被部署成为一个长期运行的服务。真实的终端——可以是用户机或者是服务器——可以根据自己的需要选择不同的原型系统来获得更好的性能，可靠性或者安全性，或者简单的说就是访问在其他原型系统下不可用的服务。事实上，VINI上运行的某一个原型系统甚至还可以为另一个原型系统提供服务，这样在VINI上就可以部署了一种全新的网络架构。例如，某个终端用户要求保证内容完整性，他就可以采用一个部署在安全路由架构上的可以保证内容传递完整的服务。

3． VINI 的设计需求

这部分简要介绍下设计一个虚拟化网络基础设施的必要条件。我们重点介绍这样一个基础设施的大体需要，和我们为什么认为这种基础设施应该提供这些需求，还有VINI的每一个特殊实例是如何满足这些需要的。

VINI的设计需求来源于对实验真实性（包括真实的网络流量，真实的路由软件和真实的网络状况）和实验可控性（对网络事件的控制）的需求，也是来源于在同一物理硬件基础设备上运行不同实验拓扑的这种灵活性的需求。总的来说，虚拟化提供解决此问题的众多机制；事实上，虚拟化也是解决计算机系统结构，操作系统，还有网络分布式系统等众多问题的通用解决方法。尽管在虚拟化提供的众多解决方案中，创建一个虚拟化通信系统并不是那么容易的。

设计需求

解决方法

章节

灵活的网络拓扑（3.1.1）

虚拟连接

UML中的虚拟网络设备

3.2.4

Click中的通道技术和封装技术

3.3.1

每个实验特有的网络接口

UML中的虚拟网络设备

3.3.5

暴露底层网络拓扑变化

第三层的向上调用报告给虚拟节点

－

灵活的路由和转发（3.1.2）

虚拟节点特有的转发表

每个虚拟节点上都分别拥有一个Click实例

3.3.1

虚拟节点特有的路由进程

每个虚拟节点上都分别拥有一个XORP实例

3.3.2

外部连通性（3.1.3）

终端主机可以通过该系统发送真实流量

终端主机连接一个OpenVPN服务器

3.3.3

确保返回的数据流能通过该系统

由Click进行网络地址转换

3.3.3

支持多个实验同时进行（3.1.4）

不同实验间的资源分配

OpenVZ的虚拟化技术和网络隔离技术

3.2.4

CPU资源预留和优先级策略

3.2.2

特有的外部路由邻接

BGP多路复用器来共享外部BGP会话

－

 

如表1所示，创建一个虚拟网络基础设施设计到解决四个主要的问题：第一，由于网络研究人员可能希望采用同一个网络实验平台来创建任意多个网络拓扑，所以底层物理基础设施必须提供对虚拟化网络设备和其他虚拟附属设备的支持。我们在第3.1.1节来讨论这个问题。第二，一旦基本的拓扑被创建之后，物理基础设施必须便于在虚拟拓扑上运行路由协议。这个目标很有挑战性，因为每一个虚拟节点可能都有与物理节点不同的特点；例如，多个虚拟接口可能被映射到一个物理接口上，在两个虚拟节点间的一条链路可能包含多个IP跳。在3.1.2节将详细讨论这些需求。第三，一旦虚拟网络上建立了它自己的路由协议和转发表，要求必须在真实网络上传输数据。使研究人员可以在真实的网络状况下做实验，这部分将在3.1.3节讨论。最后，VINI应该让网络研究人员们利用同一套物理设备来实验。虚拟网络节点实现复杂应用将在3.1.4节详细讨论。

3.1 灵活的网络拓扑

为了使研究人员可以平苦新的路由协议，网络结构和管理系统，VINI必须提供设置不同节点和连接的能力。使这种灵活的网络配置可行需要解决两个主要的难题：以任意数量的接口配置每个节点的能力（例如灵活给予每一个节点任意一个度），和在任意两个虚拟节点间提供物理连接的能力（例如在拓扑中确定边的灵活性）。这些问题都不是容易解决的：每个问题都包括在一定程度上，以新的方法来虚拟物理网络组件。

问题：为每个实验独有的接口。诸如OSPF，IS-IS这些路由协议在每个接口上都有可配置的参数（权重和地点）。为了运行这些协议，VINI必须在同一个实验中有多个接口，而我们日常所用的物理几点都只有固定数量的物理接口，而且这个数量很小。节点上物理接口配置的限制性是不能被接受的：因为不同的实验可能需要每个节点拥有不同数量的接口，可能很多，也可能很少，而通过给每个节点配置大量的物理接口是不现实的，因为这不仅很贵，而且物理上也是不可能的。

即使我们能够配置大量的物理网卡接口，我们最终是要VINI作为一个可以运行多个实验的共享的基础设施。不同的实验要求可能要求为每个节点配置不同数量的虚拟接口，这样可以通过共享固定数量的物理接口，而很可能是少量的物理接口来实现。

问题：虚拟的端到端连接。为了构建多种任意的网络拓扑，VINI必须也能方便的创建虚拟连接（两个虚拟节点之间的真实的物理连接）。提供这个功能看起来很简单：可以简单的通过创建各虚拟接口间的覆盖网络，这样在任意两个虚拟节点间就可以创建虚拟连接。原则上，这种方法是我们这种解决办法的本质，但是想要使VINI看起来像真实网络而不单单是覆盖网络，这就又产生了额外的复杂性。

每个虚拟连接必须建立在真实连接之上，因为不仅应该提供一种连接性（任何虚拟连接两端的终端物理节点必须知道沿着哪条路径来发送数据），也根据资源控制的立场（任何虚拟连接应该独立于同一物理连接上的其他虚拟连接，虚拟节点的性能不受同一物理节点上其他虚拟节点的影响）。一个需要考虑的问题是，在VINI中为实验建立起来的拓扑结构，应该能在一定程度上反映在底层网络上相关的真实物理连接的某些特征。在VINI实验中的虚拟连接，在很多情况下不包含简单的点到点物理连接，而是一系列物理连接的覆盖。

提供这种保证是很困难的。首先，这些“连接”不知道在第二层网络上是如何传输的，因为每一个IP连接包含一个虚拟连接，可能会毫无关联的遇到诸如网络拥塞和链路失效这种网络事件。我们将在3.1.4节讨论底层的物理连接可能会被多个虚拟拓扑所共用，并且一个网络实验的流量很可能会影响另一个实验的网络状态。

问题：暴露底层物理拓扑结构的变化。一个物理组件应该和和它相关联的虚拟组件共享同一状态。物理网络上拓扑的变化应该可以在虚拟网络拓扑上表现出来。例如，如果物理连接断开了，VINI应该保证使用那个物理连接的虚拟连接也断开。例如，VINI不应该通过动态的改变路由来掩饰这种链路失效。没有这一要求，在VINI上的实验将会受底层网络协议的支配（IP路由），而新协议，新网络结构或管理系统的设计者在区分新系统和旧系统上将会遇到困难。

3.2 灵活的转发和路由

实验平台不仅应该提供创建网络拓扑的灵活性，也应该允许在这些拓扑上承载真实的网络流量，这就需要VINI具有转发数据（在特殊的路径上传输数据）和路由（数据包应该被如何转发）的能力。VINI必须允许用户在虚拟拓扑上灵活地控制转发和路由，转发必须是灵活的，因为不同的实验可能需要不同的虚拟拓扑结构。路由必须是灵活的，因为每一个实验可能会实现完全不同的路由机制和路由协议。本节我们将描述如何设计满足这种灵活转发和灵活路由的实验平台。

问题：每个虚拟节点都有不同的转发表。正如我们在3.1.1中所说的，不同的实验可能会需要不同的拓扑结构：任一虚拟节点可能会连接到其他不同的一系列虚拟节点上。例如：一个实验可能有这样一个拓扑结构，每个节点都直接与其他节点连接，而另一个实验可能建立一个具有边界系统的拓扑结构。灵活的拓扑结构就是需要可变的网络接口配置，也就是说不同的拓扑结构采用不同的一系列转发表。除此之外，当今IPv4是根据终点转发的，VINI作为实验平台应该支持其他完全不同于IPv4的转发策略，也就是说VINI应该允许网络实验设置不同于传统网络的转发机制（如综合源和目的地的转发，或根据标签或平台标记的转发等）。

问题：每个虚拟节点上运行不同的路由进程。同样是为了提高实验的灵活性，VINI必须能让实验创建它自己的路由表和实现它自己的路由策略。因此，除了给予每个实验者配置自己网络拓扑和转发表的能力，VINI必须也允许让每个实验运行其自己的路由协议和路由进程。这些路由进程必须处理两种情况：（1）在VINI内部发现到目的地的路由；并且（2）发现到VINI之外目的地的路由。

3.3 外部连通性

为了让研究人员在真实的网络状态下评估他们自己的协议和服务，VINI的一个主要优点就是可以接收来自真实主机的数据，和向真实主机发送数据。这让实验可以观测到网络行为是如何影响端到端传输的性能的，并且可以知道终端系统的适应能力是如何影响网络传输的。支持真实网络流量需要VINI解决如下两个问题。

问题：允许终端主机发送的数据通过VINI。终端主机可以选择让他们网络流量通过运行在VINI上的网络系统。例如，终端用户可以连接就近的VINI节点把数据发送给VINI内部运行的服务，也能直接发送给外部Internet上现有的服务（如网站服务）。这就需要VINI在终端主机与VINI节点间提供一种访问网络的机制，并且保证所有进入和流出终端主机（或者是从终端主机上的某个特定应用）的数据包都能在某种合适的虚拟拓扑上到达这个虚拟节点。VINI内部的这些虚拟节点就可以利用实验的路由软件来转发这些数据包了。

问题：保证外部服务的响应数据包通过VINI。为了支持真实的实验，VINI应该负责转发从外部主机传送来的，和发往外部主机的数据流量来提供通信服务，即使这些外部主机不是在VINI中。例如，VINI的实验就像是连接到Internet上一个末梢网络一样，从更广大范围内的传统网络上获取服务（如网站服务）。把流量从VINI中引向外部Internet不是特别的困难。但是，确保响应的流量能够到达VINI节点，并且流经VINI转发给终端主机却是个大问题。

解决这两个问题可以在更大范围上运行实验，或者是模拟用户或者就是真实用户，可以在VINI中运行实验的新网络协议或新服务来测试新协议的性能。最终，如果某些服务需要网络提供比今天更好的性能，安全性和可靠性，我们预想这些服务可以在VINI上为终端用户或者某些应用长期运行。

3.4 支持多个实验同时运行

VINI应该让多个实验分别偿还用于部署和运行物理基础设施的代价。除此之外，运行实验的同时允许研究人员提供一些长期的服务会吸引一些真实用户，同时也允许其他的研究人员在上面运行新协议和新服务。在设计VINI时，支持多种虚拟拓扑结构的同时又引入了两个重要的技术难题。

问题：多个同时运行的实验之间的资源隔离问题。每个物理结点上存在多个虚拟节点，他们分别属于他们自己的虚拟网络拓扑中。虚拟节点在物理节点上需要独占属于他们自己的资源，每个物理节点负责分配和规化资源（CPU，带宽，内存和存储），这样同一物理节点上运行的一个的实验将不会影响同时运行的其他实验。更重要的是，资源要严格保护，也就是说为某个实验分配好了的资源，不能多也不能少，这样才能保证可重做这个实验。另外，每个虚拟节点都需要属于它自己的名字空间，IP地址和端口来与外部通信。

问题：虚拟节点上特有的外部路由邻接。多个虚拟节点可能需要和外部Internet上同一个路由器交换路由信息，例如BGP通告。这样，每个虚拟拓扑向外部Internel提供它自己的地址空间是非常重要的，它控制数据从哪进入或者从哪流出我们的虚拟网络。然而，运营中的网络不可能为每个虚拟拓扑网络中的某个虚拟节点创建路由邻接，主要由于两个原因。第一，运营中的网络可能会担心在运营路由器上运行的一个路由协议会话作为研究实验的一部分，如果会话失败或者是实现上出现了问题，将影响真实Internet上路由的稳定性。第二，为多个不同的虚拟节点维护多个路由协议会话将会造成运行中的路由器的内存，带宽或CPU资源过载。所以VINI必须考虑这些问题，合理的处理好实验要求的灵活多变性和外部运营中网络的健壮性之间的关系。

在下面的部分，我们将描述我们在Abilene backbone上以PlanetLab节点为基础设计的VINI原型是如何解决以上这些问题的。

4. 在PlanetLab上实现VINI的方法

实现VINI的第一步，我们在Abilene backbone的PlanetLab节点上创建最初的原型。虽然我们没有贡献节点，也没有为商业ISP提供连接，这个环境仍然允许我们在固定物理基础设施上解决许多虚拟网络的问题。为了保证原型的扩展性和简易性，我们仅仅对PlanetLab操作系统进行了很少的改动，在节点上的用户空间里面安置了一些重要的功能性软件，如路由和包转发软件。在这章中，我们介绍PL-VINI，扩展PlanetLab使它支持网络协议和网络服务的实验，和IIAS，一种在PL-VINI上运行良好的网络系统。

表1总结了PL-VINI原型是如何解决第三章指出的问题的。这张表强调了我们必须在用户空间安装一些软件（用来实现端到端连接和专有网络接口问题的）来解决这些问题，而在理想情况下这些软件是写入内核或嵌入到硬件设备里的。这就决定了我们把VINI原型安装在PlanetLab上；因为PlanetLab要继续让大量其他用户使用，我们不能改变内核。所以我们期待更多PlanetLab本身能够提供更多功能。

4.1 PL-VINI：为VINI扩展了的PlanetLab

我们对PlanetLab改造形成的VINI原型增加了对网络实验的支持。这个目标看起来在某种程度上背离了设计PlanetLab最初的任务，即是部署大范围的覆盖网络——它是一种像网络一样的分布式系统，可以路由数据包，但是是用sockets（如UDP通道）来进行通信。为了使新的网络协议和服务在覆盖网络上评估，PL-VINI保留了PlanetLab的特性；我们将在4.2节讨论这种网络的设计。

4.1.1 PlanetLab：Slice和资源划分

作为VINI的原型和部署，理论上PlanetLab是一个自然的选择，不仅仅因为它现有的大规模物理基础设施，也由于它已经提供了的虚拟化。虚拟化――分割真实的物理节点为多个虚拟节点，和把物理资源划分为资源池，这些是VINI的一个基本需求。PlanetLab用虚拟服务器（VServer）^[20]分离实验。每一个VServer是节点上的一个“slice”，拥有自己的名称空间。因为PlanetLab提供资源分离，多个VINI实验可以在同一个PlanetLab节点的不同slice上同时运行。

VServer可以严格控制每个slice拥有的资源，如CPU，网络带宽等。PlanetLab的CPU调度程序让节点上的每个slice公平的共享节点可用的CPU，并且支持暂时的增加（通过Sirius^[21]）。同样的，Linux的HTB^[22]调度程序也对网络带宽提供均匀的共享。在PlanetLab上网络部分的分离是由一个叫做VNET^[23]的模块提供的，它跟踪和分路进出流量。VNET允许每个slice使用者访问底层的网络设备虚拟出来的网络设备。每个slice仅仅可以访问它自己的网络流量或者预留指定的端口。

4.1.2 增强的CPU隔离

PlanetLab使每个slice对CPU资源公平分享，但是其他slice对CPU需求的不同使运行可再现实验非常困难。如果一个节点有大量的slice，运行在一个slice上的路由进程可能没有足够的资源来发送重要的消息或者反映事件，也有可能转发进程不能保持设定的吞吐量。多个slice同时要求CPU提供计算服务也会导致在转发进程调度中发生抖动，这就可能会增加某个覆盖网络的延时。

PL-VINI平衡了最近暴露出来的CPU调度问题：CPU预留和Linux实时优先级属性^[24]。如果预留给某个slice25％的CPU资源，在该slice活跃的时候就提供最小25％的CPU资源，如果其他分享CPU资源的slice没有运行，它就可以获得更多的CPU资源。在Linux上通过在运行进程和唤醒进程间切换来赋予一个进程以实时级。一个实时优先级的进程运行的时候会立即跳转到运行队列头，并且比其他非实时优先级进程有更高的优先级。注意即使是实时优先级进程仍然要遵从PlanetLab的CPU预留和分享协议，所以一个实时优先级进程不能毫无限制的使用一个CPU资源。这两个PlanetLab提供的隔离技术对运行在slice上的VINI实验是很好的支持。在3.4节我们介绍了一些额外的扩展，它提供给PL-VINI的slice更好的隔离。

4.1.3 虚拟网络设备

运行在一个slice上的网络实验，每一个虚拟节点需要在用户空间中都能访问一个或更多的网络设备。我们采用User-Mode Linux(UML)，一个完整的Linux内核，在它上面运行用户进程就能达到这个目的。在我们的覆盖网络拓扑上，对于每一个用户空间通道，PL-VINI在UML实例里的终端节点上，为通用子网都创建了一系列接口。运行在UML内的路由软件这样就知道了覆盖网络的结构。PL-VINI然后可以匹配发送到这些网络接口的数据包，发送到位于UML层下的适当的通道上。我们可以注意到Violin^[6]也是用一个覆盖网络连接UML实例的。但是，Violin的目的是隐藏网格应用的拓扑，而PL-VINI是为了用UML中的网络接口来暴露一个通道给运行在UML上的路由软件。

我们设计的原型也用到了修改版本的TUN/TAP设备驱动，这是为了在slice上运行的网络实验能在覆盖网络上接收和发送数据包。一个运行在用户空间的进程可以从/dev/net/tunX上接收由内核转发到TUN/TAP设备上的数据包；同样的，写入/dev/net/tunX的数据包会被送回内核的网络协议栈，就像是从网络设备上传送过来的一样来处理他们。我们对驱动程序的修改使它能区分PlanetLab上不同的slice：每一个slice看每一个TUN/TAP接口都是一个IP地址，但是我们的修改使不同slice上的不同进程可以同时从/dev/net/tunX上读取数据，并且他们只能看见属于他们自己slice的数据。

PL-VINI中我们在每一个PlanetLab节点上都创建一个虚拟的以太网设备叫tap0。给每个tap0设备一个特殊的IP，在10.0.0.0/8的私有地址空间内选择。这意味着每一个PlanetLab节点的内核将要路由所有匹配10.0.0.0/8的地址给tap0，这样就能到达它自己的覆盖网络上了。

4.2 IIAS：“一个slice上的Internet”的架构

一个slice上的Internet（IIAS）是运行在PL-VINI上的一个网络架构例子。研究人员可以通过用IIAS运行可控的实验，真实地评估现有IP路由协议和转发机制。当然也可以把IIAS看成是一个参考的实现，然后修改它扩展现有的协议或服务，这样就也可以评估这些扩展了。一个IIAS包括以下五个组件^[26]：

1. 为覆盖网络的路由器服务的包转发引擎；

2. 一个设置包转发引擎转发表的方法（控制层面）；

3. 这样一种机制：允许用户有选择的进入覆盖网络并把用户的真实流量注入，这样就可以让覆盖网络承载真实的流量（一个覆盖网络入口）；

4. 一个与外部网络交换数据包的方法，而让外部网络根本不知道这个覆盖网络的存在（一个覆盖网络的出口）；

5. 部署覆盖网络需要一系列分布式主机，这些主机要选择好，这样才能进行正确的评估和吸引真实用户。

我们的IIAS实现集成了许多由网络研究组织或开源社团开发的组件。IIAS用Click^[10]软件路由器模块作为转发引擎，XORP^[9]路由协议套件作为控制层面，OpenVPN^[11]作为入口机制，在出口实现NAT地址转换（在Click内实现）。在PL-VINI上运行IIAS意味着，IIAS同样也可以用PL-VINI的tap0设备作为在PL-VINI节点上运行应用的入口和出口机制。

 

 

图1显示了由PL-VINI支持的IIAS路由器。XORP实现了路由协议，它是一个未加修改的UML内核进程，构造了一个被虚拟网络接口暴露的覆盖网络拓扑。每个XORP实例设置一个转发表由一个在UML外部的Click进程实现。这就是说覆盖网络转发的数据包不进入UML，因为由UML内核转发数据包将导致15％的额外性能损耗^[6]。接下来我们讨论IIAS软件的每一个组件的主要特点。

4.2.1 Click：连接和包转发

IIAS用Click软件发送器作为他的虚拟数据层面。用Click创建到其他虚拟节点的点到点虚拟连接，每个虚拟节点都可以转发数据包，对Click的配置包括五个组成部分：

• UDP通道：UDP通道（如sockets）是IIAS覆盖网络的连接。在覆盖网络上的每个Click实例都配置了到其他每个邻居的通道。

• 本地接口：Click从PL-VINI的本地tap0接口读取或写入以太网数据包。由一个虚拟节点本地应用程序发送到10.0.0.0/8地址的数据包将被内核发送到该虚拟节点的tap0设备，然后被Click接收到，由Click转发。同样的，Click接收的数据包，首先向tap0设备写入以tap0的IP地址为目的地的数据包，然后把它传入到内核，并由内核将这些数据包分发到恰当的应用程序中。

• 转发表：Click的转发表匹配IP前缀（包括在IIAS私有地址空间内部的和外部的）到IIAS中的下一跳节点。转发表开始是空的，然后由XORP添加表项。注意由XORP添加的下一跳信息的IP地址是UML的接口地址。

• 封装表：Click的转发表匹配每个数据包的目的IP地址到下一跳的UML接口地址。按照预先设置好的封装表，查询某个PlanetLab节点的公共IP地址，匹配下一跳到某个UDP通道。

• UML转换：Click与本地UML实例通过一个虚拟转换器交换以太网数据包。

有两个关于IIAS数据层面的问题需要注意。第一，IIAS中的转发表控制IIAS节点间数据流量和控制流量是如何转发的，并且也控制流量是如何发送到外部目的地（真实的Internet）的。第二，虽然IIAS现在执行特定的IP转发机制，我们也可以支持新的转发范例——例如，可以通过简单的写新的转发表和封装表元素，来实现基于DHT的转发机制。为了避免对IP层的依赖，UML和本地接口之间交换的是以太网桢。

4.2.2 XORP：路由

IIAS采用XORP开源路由协议套件作为它的控制层面。XORP实现了很多路由协议，包括BGP，OSPF，RIP，PIM-SM，IGMP，和MLD。XORP通过一个转发引擎提取器（FEA）来控制数据层面的路由，它支持的转发引擎包括支持Linux的内核转发，也支持Click模块的转发（这就是IIAS为什么选择XORP）。

PlanetLab上运行XORP最主要的问题是在我们的设置中缺少物理接口来对应每一条虚拟链路。XORP总体上认为每一条连接邻居路由器的链路都是通过物理接口连接的；OSPF也指定了网络接口的代价。数据层面上，接口对应sockets和通道的连接。因此，为了让XORP看见多个物理接口，我们就在UML中运行它，并且匹配每一个UML的接口为对应Click中的UDP通道。

IIAS的一个重要特点就是，它把路由协议与转发引擎放在两个不同的虚拟环境中，分离了控制层面和数据层面。实际上，分离控制层面和数据层面的这种做法，意味着XORP可以运行在不同的slice上（Click不能），甚至运行在不同的节点上。

4.2.3 OpenVPN和NAT：对外部的连接

我们设计的网络实验平台追求真实的实验，IIAS承载外部主机生成的真实流量，也承载IIAS内部虚拟节点的某个应用生成真实流量，通过引入这些真实流量来实现真实性。OpenVPN[]在IIAS中被用作入口机制；IIAS在某些指定的内部节点上运行OpenVPN服务器，然后客户主机连接某一节点的OpenVPN服务器，运行OpenVPN客户端就可以把他们的真实流量转向到IIAS中了。OpenVPN是一个稳定的开源的VPN接入技术，它可以运行在多种操作系统上，有广大的用户群。

IIAS中的Click转发器实现了NAPT（网络地址转化和网络端口转换），它允许IIAS内部的主机与IIAS外部主机（WEB服务器）交换数据包。IIAS将目的地为一个外部主机的数据包转发到某个出口点，在这里数据包通过NAPT离开IIAS。这涉及到把要发送出去的数据包，要重写它的源IP地址，改成出口节点的公共IP地址，然后改写源端口为一个可用的本地端口。通过Click的NAPT后，数据包将被发送出去，并被通过真实的Internet转发到目的地点。请注意，因为发送到外部主机的数据包更改了源地址为IIAS出口节点的地址，返回的流量将被送回到那个节点，在这个节点上，IIAS得到数据包并转发回给发送它的客户机。

PL-VINI的tap0接口为在同一个slice上的其他应用提供了另一种入口和出口机制。例如，XORP用它来发送OSPF数据包到它的邻居节点，正如我们将要在第五章描述的，用tap0通过覆盖网络发送iperf数据包。

4.2.4 IIAS总结：数据包传输整个过程

 

图2配合对IIAS中各个部分的介绍，说明一个数据包在IIAS覆盖网络中传输的整个过程。在图2中，客户端主机的web浏览器Firefox正在发送数据包通过IIAS到www.cnn.com。数据包在IIAS中的整个传输过程是这样的：

1. Firefox发送一个数据包给CNN。客户端的路由表把这个数据包发送到由OpenVPN创建的本地tap0接口。这个设备将数据包返回给同一主机上的OpenVPN客户端。数据包有一个10.0.87.2（本地tap0的地址）的源地址和一个64.236.16.20（CNNweb服务器的IP地址）的目的地址。

2. OpenVPN客户端通过VPN通道根据UDP协议将数据包发送到附近的IIAS节点的OpenVPN服务器上。这个数据包包含了IP协议，UDP协议和OpenVPN的头部信息。OpenVPN服务器剥掉这些头部信息后，将这个原始数据包通过本地Unix domain socket转发给Click。

3. Click在它的转发表中查询64.236.16.20，匹配到邻居节点的一个UML接口的IP地址。Click再查询封装表，然后匹配UML地址198.32.154.250，即为下一跳节点的真实IP地址，并通过UDP通道将数据包发送到后面这个地址。下一个节点也是同样的过程。

4. 1982.32.154.225上运行的Click进程从UDP通道接收到原始数据包后，查询转发表，发现它自己就是对64.236.16.20地址的出口节点。Click通过NAPT元素发送数据包，NAPT重写数据包的源IP地址为本地eth0接口的地址，重写源端口为一个可用的本地端口（图2中没有显示出端口重写的过程）。Click然后就把数据包通过公共Internet发送给www.cnn.com。

这样，数据包之后就再Internet上传输，最后到达CNN的web服务器。CNN的应答包的IP地址为198.32.154.226，又确保了最终到达客户端主机的应答包也通过VINI节点。

5．初级实验

在这章中，我们描述了已经在PL-VINI的IIAS上运行的两个实验。这两个实验不是为了说明PL-VINI是一个最终的产品，而是为了强调VINI设计的高效性，正确性和可用性。基准实验表明了PL-VINI对网络实验提供一定级别的支持，它运行在捐赠的硬件上，通过对吞吐量和流量的检测，反映出底层网络的性能。然后，在Abilene拓扑上运行的域内路由实验，表明了采用PlanetLab上的PL-VINI观察到的一些有意义的结果。

5.1 基准实验

基准实验的目的就是为了证明PL-VINI可以支持网络实验。我们首先确定运行在资助的硬件节点上隔离出来的IIAS覆盖网络就像现在的真实网络一样，然后展示PL-VINI可以提供IIAS。

为了提供一个网络实验的真实环境，PL-VINI必须使IIAS包含以下两个方面：

性能：为了吸引真实用户和真实网络流量，IIAS必须能够以较高的速率转发数据包。如果IIAS的性能很差，没人会用它。

行为：观察到不规则的事件而不是人造的仿真事件，对于进行PL-VINI的环境是是很有意义的，IIAS应该粗略地展示与基础网络相同的行为特点。

我们运行两个实验来测量IIAS的性能和行为。第一个实验运行在DETER^[16]上资助的硬件机器上，DETER以Emulab^[15]为基础；通过评估DETER的仿真网络拓扑与运行在同样拓扑上的IIAS，在效率上经过量化后进行比较。第二个实验在PlanetLab上重复DETER的实验；在这里我们把IIAS从资助的硬件（DETER/Emulab）上移到共享的平台（PlanetLab）上，通过量化这个迁移的效果来比较，然后显示PL-VINI通过预留CPU资源和CPU实时优先级的，如何减少CPU竞争的。

基准实验运行iperf[27]。用iperf的TCP吞吐量测试性能，从客户端同时发送20个流通过基础网络和PL-VINI到服务器。我们用iperf的固定码率UDP测量行为，观察数据流（1430字节UDP载荷）的抖动和丢包率。每一个测试运行10次，报告方法和标准背离。当测量PL-VINI的性能时，我们同样报告由Click进程使用的CPU百分比（用ps命令报告中的TIME字段）。

5.1.1 基准实验#1：覆盖网络的效率

首先比较一下IIAS用户空间内的Click转发器与内核转发的性能与行为。实验运行在DETER测试平台上，研究人员可以为一个实验指定任意一种网络拓扑，包括用ns脚本模拟连接的特点，如延时和丢包率。实验用的机器是pc2800 2.8GHz Xeons，2GB内存和5个10/100/1000以太网接口，运行Linux 2.6.12。

 

实验运行的是图3所示的简单拓扑，包括三台由吉比以太网连接的主机，几乎没有延时和丢包。图中Fwdr被配置为一个IP路由器；一个数据包从Src发送到Sink，或者vice-versa，由Fwdr的内核转发。对比这个网络和同样使用这三个节点的IIAS的性能。我们在每个节点上配置一个Linux的TUN/TAP设备，然后用iperf产生数据包发送到本地Click进程。随后Click在图4所示的拓扑网络上传送这个数据包。IIAS和图3所示普通拓扑的主要区别是IIAS是在用户空间决定转发策略的，而不是在Linux的内核空间里。

 

表2显示了在IIAS覆盖网络上和基础网络上运行TCP吞吐量测试的对比。很明显IIAS的效率不如单独普通网络的效率好：同样的CPU占用率下它获得了10％左右的吞吐量提升。通过Linux内核的吞吐量940Mb/s，在这种配置下效果非常好，而且Fwdr机器上还有52％的空闲CPU资源。相比来说，Click的转发效果受到CPU的影响。在Click进程运行strace命令表明系统调用已经过载了：对于每一个转发的数据包，Click都要调用poll，recvfrom，和sendto各一次，调用gettimeofday三次，估计每次调用都会消耗5纳秒。Sendto和recvfrom命令消耗的代价与数据包大小无关。如何降低这种过载是将来的工作。回过头来看，200Mb/s的速度对于一个网络实验来说已经足够了，因为它远远超过了当今边界主机与Internet之间的可用带宽。

接下来我们仔细比较一下普通网络和IIAS的行为区别。表3显示了在覆盖网络和普通网络中测量延时的结果（用ping –f –c 10000命令）。IIAS平均增加了130纳秒的延时，但是多次ping的结果并没有太大的偏离。同样的，在传统网络上和IIAS上，以1Mb/s到100Mb/s的速率生成UDP恒定比特率流，结果显示在两种网络上都没有大的抖动。在所有的UDP恒定比特率测试中，iperf观察到小于0.1ms的抖动，并且没有数据包丢失。

5.1.2 基准实验#2：PlanetLab上的覆盖网络

下面的一组基准实验对比运行在DETER上，共享的平台上（PlanetLab）和PL-VINI上IIAS的行为。我们关心的是在像PlanetLab这样的共享系统上其他用户的动作会不会对IIAS的性能有负面影响。测试这点，可以重复5.1.1节的实验，在三个PlanetLab节点与Abilene PoPs做对比。图5显示了PlanetLab节点的拓扑和基础Abilene网络的拓扑，通过在这三个节点间运行traceroute可以知道。芝加哥和华盛顿特区的PlanetLab的节点是1.4GHz P-Ⅲ的处理器，纽约的节点是1.267GHz P-Ⅲ的处理器;所有节点都是1GB内存。一样的比较IIAS和基础网络的性能和行为。注意芝加哥和华盛顿之间的网络流量只经过三个路由器，但是IIAS的流量要经过四个路由器，因为它要被纽约节点的Click进程转发，并且两次访问了本地路由器。因为Abilene网络负载很轻，所以我们预期没有太大的由交叉流量带来的干扰。

PlanetLab上运行有意义的实验有一定困难，因为它被很多用户所共享，这样就有可能改变实验的结果。Emulab基准表明特殊情况下的CPU竞争可能是PlanetLab上PL-VINI的一个问题；但是，PL-VINI可以用CPU预留技术和实时优先级分配来调度CPU，使之稳定持续的工作。因此，在5.1.1节用PlanetLab的默认公平分享技术运行我们的实验，还有25％CPU预留资源加上IIASClick进程的优先级策略。CPU预留策略通过提供更多的CPU资源提升了IIAS的整体性能，而增加实时优先级减少了Click进程的调度延时，结果增加了覆盖网络的端到端延时。

表4显示了两组不同CPU调度策略下带宽测试的结果。我们注意到，通过观察吞吐量和结果可变性，采用PL-VINI，IIAS的性能已经很接近基础网络了。在PL-VINI上运行IIAS增加了4倍的吞吐量，并减少了超过80％的可变性。

针对PlanetLab上IIAS的行为，表5用ping命令呈现了结果。当运行默认的共享时，IIAS实验在测量延时实验的时候明显存在可变性：PL-VINI的ping命令次数已经偏离基础网络标准20倍了。PL-VINI有一次改变了IIAS的总体行为，减少了三分之二的最大延时，并且减少90％的标准偏离。在这种情况下IIAS引入了少量的额外延时，ping时间的可变性也增加到了两倍。

 

图6显示了PL－VINI在IIAS覆盖网络上抖动的效果。实验以恒定速率在普通网络和覆盖网络上分别发送1Mb/s的数据流和50Mb/s的数据流；抖动不受数据流大小的影响，所以我们可以在不同流速率下观察抖动的结果。

5.2 域内路由改变

为了证明IIAS和PL-VINI提供了一个合理的网络实验环境，我们在Abilene网络上的PlanetLab结点上部署11个路由器，做一个域内路由实验，如图7所示。通过配置IIAS的网络拓扑，使它与基础Abilence网络具有相同的OSPF连接代价，这些代价是从11个Abilene路由器上的设置状态提取出来的。也就是说，每个虚拟链路直接与Abilene间路由器单独的物理连接匹配。通过跟踪直接从Abilene路由器上收集来的路由，让我们可以确定在整个实验中，底层基础网络的路由根本没有变化。

通过向实验中Denver和Kansas间的连接注入一个链路失效，随后再一个恢复，观察对端到端流量的影响。在我们的实验中，就可以在Click中丢包，断开两个Abilene节点间的虚拟连接（UDP通道），来实现链路失效。用ping，iperf和tcpdump等工具来测量对流量的影响。这样的实验可以帮助研究人员研究路由的缺陷，这在真实的网络上很难观察到，因为研究人员在真实的网络上无法控制网络状态。

如图8所示的是整个实验中DC和Seattle之间的ping时间显示，首先断开Kansas和Denver之间的连接10秒钟，然后在34秒的时候恢复连接。最初，数据包是从DC到New York，Chicago，Indianapolis，Kansas City，和Denver最后到Seattle，平均RTT时间是76ms。在17秒，就是链路实效后的第7秒钟，OSPF发现了一个110msRTT的路径，然后又发现了一个新的路由，它的RTT时间更短，只有87ms，即从Atlanta，Houston，Los Angeles，和Sunnyvale。随后，链路又恢复到最开始的路由上了。

 

 

图9所示的是通过在同一个实验中从Washington DC到Seattle用iperf发送TCP数据包，来测量TCP性能。TCP窗口大小被设置为iperf的默认大小16KB，这样TCP的吞吐量被窗口大小限制到3Mb/s。图中画出了由tcpdump报告的接收端数据包的到达时间。图9（a）清楚的显示了在链路失效的第10秒钟就接收不到数据包了，而当第18秒钟当OSPF发现一个新路由后又开始接收数据包了。图9（b）更细致的显示了在18秒左右发生的具体事情；y轴是每一个到达的TCP数据包在字节流中的位置。图中清楚地显示了TCP在重新启动过后的慢启动动作，然后一个重传的数据包，接着又一个慢启动过程。图9（a）也显示了当OSPF路由恢复到原始路由上在38秒的时候的一些TCP吞吐量中断。

这些实验并不是为了说明OSPF或者TCP交互的新发现。而是为了说明我们可以用PL-VINI和IIAS来发现一些东西，因为PL-VINI使IIAS的行为就像一个真实的网络一样。

6．未来工作

在这部分中，我们讨论VINI的未来工作。从第3部分我们就讨论了一些VINI的设计目标，而且已经指出了一些可行的解决办法。首先，讨论了两种方法来提高VINI实验的真实性：通过暴露底层基础网络拓扑的变化并与邻域来交换路由协议信息。然后我们描述我们未来努力的方向，提供给研究人员更好的实验控制，比如从一些模拟工具（ns－2）等和仿真环境（Emulab）到VINI的迁移。最后，提出更好隔离实验的技术。

6.1 提高真实性

暴露网络故障和拓扑改变：这种物理组件的故障和恢复应该影响相关的每个虚拟组件。PL-VINI原型并没有达到这个目标，因为当拓扑改变的时候底层基础网络的两个IIAS节点自动重新路由流量。虽然大多数应用都希望标记故障，研究人员采用VINI也许希望他们的协议和服务能通过另一种办法来自适应这种故障；最起码知道这些故障发生了，因为它们将影响到实验的结果。当我们继续在NLR和Abilene上的工作时，我们将探索新的方法来真实地暴露VINI的拓扑变化，并且扩展软件功能，通过一个向上调用来通知上层相关的slice。

参与到邻居网络的路由中：正如在3.4部分讨论的，多个VINI实验可能希望与真实的Internet上的邻居网络交换可达性信息。让每个虚拟节点维持独立的BGP会话带来了测量问题（因为会话的数量可能随着实验的数量增多而增大），管理问题（因为BGP会话的两端必须都被设置），和稳定性问题（不稳定的实验软件可能会影响邻居网络或者Internet上其他网络的稳定性）。

为了避免这些潜在的问题，我们正在设计和实现一种多路复用器，它可以管理与邻居网络的BGP会话，并且虚拟节点的external speakers和BGP speakers之间转发和过滤路由协议信息。每个实验可能在VINI分配好的一个更大的地址空间中有它自己的一部分。多路复用器确保每个虚拟节点只能声明它自己的地址空间，并且可能影响到每个实验传播的BGP更新消息速率的限制。我们当前实现的BGP多路复用器，是XORP的多个实例，它们都运行在UML内并且与同一个的external speaker通信。XORP的每个实例维护与运行在虚拟节点上路由软件的BGP会话，这样我们的实验就可以与邻域交换BGP消息了。

6.2 提高可控性

更好的隔离：VINI应该保证多个同时运行的实验，对每个slice上的资源严格保护。增加对CPU预留资源和实时优先级的策略帮助把一个PL-VINI实验从其他slice中隔离出来，但是PL-VINI应该需要更好的隔离。第一步就是实现一个non-work-conserving的调度策略，来确保每个实验总能获得相同的CPU分配（既不多也不少），这点对可重做实验非常重要。为了让研究人员能够区分链路能力，我们同样计划增加设置链路带宽的支持，可以通过Click中的流量设置或者内核自己来实现。

实验规范：除了现有的对部署任意拓扑和链路失效的支持，VINI应该也提供规范实验的能力。在ns^[13]模拟中，实验者可以生成流量和路由信息流，指定某个链路失效的时间，定义需要跟踪的路径。VINI也应该提供相似的能力来创建实验。我们想象一下，VINI的实验用与创建ns或Emulab实验相同类型的语法，这样研究人员就可以把一个Emulab的实验轻松的转到VINI上来实现，这也是一个自然的进化。我们当前正在进行IIAS规范化方面的工作，实验人员已经可以指定底层基础网络，域内路由发现和域间BGP会话，并且连接和会话中断的时间。

想象一下一个VINI实验的某些方面，例如拓扑，路由设置和失效，可以被真实世界中的路由设置来驱动。PL-VINI当前反映Abilene拓扑的机制自动生成为VINI实验从实际的Abilene路由配置中取得的XORP和Click的配置信息（并且选择在Abilene PoPs上适当的协同节点），在以前路由器配置核对[12]工作的基础上开发配置过滤功能。最终，我们让VINI结合更多的路由配置信息到XORP和Click中，还要支持路由路径的重现。

7. 结论

这篇文章描述了VINI的设计，VINI是一个在真实网络环境中的支持网络协议和网络架构实验的虚拟网络架构。VINI是对当前网络模拟工具和仿真工具的补充，它提供一个真实的网络环境，在这个环境里运行真实的路由软件，并且可以在真实网络状态中和真实的流量负载中运行我们的实验来评估路由协议。我们首先强调了VINI的一些情况，给出了它的设计原则。基于这种VINI设计的高层原则，我们给出了在PlanetLab测试平台上搭建VINI的一个实例，PL-VINI。在第5部分介绍了我们的入门实验，表明PL-VINI不仅仅是有效的，而且也是对真实网络状况的真实反映。

如果VINI允许用户在同一个物理基础设施上运行多个虚拟实验，它也可以最终作为新协议和新服务的底层设施（使它不仅仅为研究所用而且也为实际操作所用）。因为VINI同样提供虚拟任何一个网络元素的能力，它可以减少网络层服务创新的障碍，并且便于实现现有协议的新的应用模型。我们现在简单的推测一下一些可行的应用模型。

第一，VINI允许网络为不同的网络服务同时运行多个不同的路由协议（甚至不同转发机制）。前面已经观察到偶尔路由会用内部路由协议（OSPF，IS-IS）来路由外部目的地，这样虽然路由的度量效果很差，但是收敛很快，特别使对一些需要快速收敛的应用（例如VOIP^[12]）。采用VINI，网络上可以在相同的物理基础设备上并行的运行多个路由协议，可以根据不同的应用运行不同的路由协议。

第二，VINI可以帮助网络操作者实现普通的管理功能。例如，操作人员日常对网络的维护操作可能包括多个网络元素间的配置（由于一个计划好的维护事件来改变IGP连接代价重定向流量）。同样的，偶尔有可能要部署新版本的路由软件，或者测试bleeding-edge代码。VINI可以使网络在同样的物理基础设施上运行多个路由协议（或者路由协议的不同版本），在指定的事件在一个虚拟网络中的某个网络元素控制转发表，并且提供不同虚拟网络之间的原子交换能力。

VINI的未来很广阔，不光作为一个实验平台也是为更多的网络协议和服务提供一个平台。这篇文章证明的VINI的可行性，和它实现可控的真实的路由实验的潜力。我们指出的设计需求和我们已经重最初的部署上学到的知识，随着部署VINI或以其他不同方式部署VINI将会非常有用。