翻譯的是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個目標：

運行真實的路由軟件：研究人員應該可以在他們的實驗中運行傳統的路由軟件來評估協議的擴展效果，在普通的網絡組件基礎上評估新的服務。
揭示真實的網絡狀態：研究人員應該可以在真實的網絡拓撲和路由配置環境下運行實驗。實驗應該能夠反映外來事件來檢查系統行爲，例如來自現實的Internet上的路由協議信息。
控制網絡事件：研究人員應該可以人工的注入現實中不常發生的網絡事件（例如鏈路失效和瞬時的網絡擁塞），來提高實驗可控性和準確測量這些事件。
承載真實的網絡流量：研究人員應該可以在真實的終端中傳輸應用數據，這樣可以測驗真實的端到端性能和接收終端系統的反饋。

滿足這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]：

爲覆蓋網絡的路由器服務的包轉發引擎；
一個設置包轉發引擎轉發表的方法（控制層面）；
這樣一種機制：允許用戶有選擇的進入覆蓋網絡並把用戶的真實流量注入，這樣就可以讓覆蓋網絡承載真實的流量（一個覆蓋網絡入口）；
一個與外部網絡交換數據包的方法，而讓外部網絡根本不知道這個覆蓋網絡的存在（一個覆蓋網絡的出口）；
部署覆蓋網絡需要一系列分佈式主機，這些主機要選擇好，這樣才能進行正確的評估和吸引真實用戶。

我們的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中的整個傳輸過程是這樣的：

Firefox發送一個數據包給CNN。客戶端的路由表把這個數據包發送到由OpenVPN創建的本地tap0接口。這個設備將數據包返回給同一主機上的OpenVPN客戶端。數據包有一個10.0.87.2（本地tap0的地址）的源地址和一個64.236.16.20（CNNweb服務器的IP地址）的目的地址。
OpenVPN客戶端通過VPN通道根據UDP協議將數據包發送到附近的IIAS節點的OpenVPN服務器上。這個數據包包含了IP協議，UDP協議和OpenVPN的頭部信息。OpenVPN服務器剝掉這些頭部信息後，將這個原始數據包通過本地Unix domain socket轉發給Click。
Click在它的轉發表中查詢64.236.16.20，匹配到鄰居節點的一個UML接口的IP地址。Click再查詢封裝表，然後匹配UML地址198.32.154.250，即爲下一跳節點的真實IP地址，並通過UDP通道將數據包發送到後面這個地址。下一個節點也是同樣的過程。
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將會非常有用。

vini:真實可控的網絡實驗