摘? 要
我們提出了OpenNetMon，這是一種方法和開源軟件實現(xiàn)，用于監(jiān)視OpenFlow網(wǎng)絡(luò)中的每個流量指標，特別是吞吐量、延遲和包丟失。目前，isp為了滿足客戶的QoS需求，過度提供容量。軟件定義的網(wǎng)絡(luò)和OpenFlow允許更好的網(wǎng)絡(luò)控制和靈活性，以盡可能高效地追求操作網(wǎng)絡(luò)。OpenFlow提供了實現(xiàn)細粒度流量工程(TE)的接口，OpenNetMon提供了必要的監(jiān)視，以確定是否實際滿足端到端QoS參數(shù)，并為TE方法提供輸入，以計算適當?shù)穆窂健penNetMon輪詢邊緣交換機，即帶有流端點的開關(guān)，其自適應(yīng)速率在樣本之間的流速率不同時增加，在流穩(wěn)定時減少，以最小化查詢的數(shù)量。自適應(yīng)速率降低了網(wǎng)絡(luò)和交換機CPU開銷，同時優(yōu)化了測量精度。我們證明，不僅本地鏈接服務(wù)于可變比特率視頻流，而且聚合的廣域網(wǎng)鏈接也受益于自適應(yīng)輪詢率，以獲得準確的測量結(jié)果。此外，我們驗證了吞吐量，延遲和包丟失的測量在我們的實驗試驗臺突發(fā)的場景。
為了達成QoS協(xié)議和流量工程，網(wǎng)絡(luò)管理的一個關(guān)鍵要求是準確的流量監(jiān)控。在過去的十年中，網(wǎng)絡(luò)監(jiān)控一直是一個活躍的研究領(lǐng)域，特別是由于IP網(wǎng)絡(luò)中流量的數(shù)量和數(shù)量龐大，以及部署測量基礎(chǔ)設(shè)施的復(fù)雜性，使得在線檢索和精確測量變得困[1]。
由于細粒度的監(jiān)視需求，許多基于流的度量技術(shù)消耗了太多的資源(帶寬、CPU)，而其他監(jiān)視解決方案需要在硬件部署和配置管理方面進行大量投資。相反，Internet服務(wù)提供商(ISP)過度提供網(wǎng)絡(luò)容量以滿足QoS約束[2]。
盡管如此，過度供應(yīng)與盡可能高效地運行網(wǎng)絡(luò)存在沖突，并且不利于細粒度流量工程(TE)。而TE則需要粒度實時監(jiān)控信息來計算最有效的路由決策。
最近的SDN提議——特別是OpenFlow[3]——引入了編程接口，使控制器能夠執(zhí)行細粒度TE，但是還沒有實現(xiàn)完整的基于OpenFlow的監(jiān)視提議。我們聲稱，由于缺乏在線和準確的監(jiān)控系統(tǒng)，因此無法開發(fā)預(yù)期的支持TE的OpenFlow控制器。鑒于OpenFlow提供的接口使控制器能夠查詢統(tǒng)計數(shù)據(jù)并將數(shù)據(jù)包注入網(wǎng)絡(luò)，我們設(shè)計并實現(xiàn)了這樣一個粒度監(jiān)控系統(tǒng)，該系統(tǒng)能夠為控制人員提供他們所需的在線監(jiān)控測量數(shù)據(jù)。在本文中，我們提出了OpenNetMon，這是一個POX OpenFlow控制器模塊，它可以精確地監(jiān)視每個流的吞吐量、包丟失和延遲指標。OpenNetMon能夠在線監(jiān)視每流吞吐量、延遲和數(shù)據(jù)包丟失，以幫助TE。
本文的其余部分結(jié)構(gòu)如下:在第二節(jié)中，我們首先討論ISP使用的現(xiàn)有測量方法和監(jiān)視技術(shù)。第三節(jié)總結(jié)了OpenFlow及其我們的實現(xiàn)使用的特定選項，以及在OpenFlow網(wǎng)絡(luò)中度量流量方面的先前工作。我們的OpenNetMon建議在第四節(jié)中給出，并在第五節(jié)中進行了實驗評估。最后，第七部分對本文進行了總結(jié)。
傳統(tǒng)上，在計算機網(wǎng)絡(luò)中使用許多不同的監(jiān)控技術(shù)。這些技術(shù)所依賴的主要度量方法類型及其帶來的權(quán)衡將在下面的兩個小節(jié)中進行討論。傳統(tǒng)上，每一種測量技術(shù)都需要單獨的硬件安裝或軟件配置，因此實現(xiàn)它是一項冗長且昂貴的任務(wù)。然而，OpenFlow提供了實現(xiàn)大多數(shù)討論的方法所必需的接口，而不需要定制。第三小節(jié)總結(jié)了isp用于監(jiān)視其網(wǎng)絡(luò)的幾種技術(shù)。
網(wǎng)絡(luò)測量方法大致分為兩大類，被動測量法和主動測量法。無源測量方法通過觀察來測量網(wǎng)絡(luò)流量，而不以探測包的形式注入額外的流量。被動測量的優(yōu)點是它們不會產(chǎn)生額外的網(wǎng)絡(luò)開銷，因此不會影響網(wǎng)絡(luò)性能。不幸的是，被動測量依賴于安裝網(wǎng)絡(luò)內(nèi)流量監(jiān)視器，這對所有網(wǎng)絡(luò)都是不可行的，并且需要大量的投資。
另一方面，活動度量向網(wǎng)絡(luò)注入額外的數(shù)據(jù)包，監(jiān)視它們的行為。例如，流行的應(yīng)用程序ping使用ICMP包可靠地確定端到端連接狀態(tài)并計算路徑的往返時間。
主動和被動測量方案都有助于監(jiān)測網(wǎng)絡(luò)流量和收集統(tǒng)計數(shù)據(jù)。然而，需要仔細決定使用哪種類型的度量。一方面，主動測量會引入額外的網(wǎng)絡(luò)負載，影響網(wǎng)絡(luò)，從而影響測量本身的準確性。另一方面，無源測量要求網(wǎng)絡(luò)中放置的觀測信標之間保持同步，從而使監(jiān)測過程復(fù)雜化。第三節(jié)討論了ISP通常使用的被動和主動測量技術(shù)。
2.2? 應(yīng)用層和網(wǎng)絡(luò)層測量
通常網(wǎng)絡(luò)測量是在不同的OSI層上執(zhí)行的。在應(yīng)用程序?qū)由系臏y量是準確測量應(yīng)用程序性能的首選，isp通常不能訪問終端用戶設(shè)備，因此使用網(wǎng)絡(luò)層測量。網(wǎng)絡(luò)層測量使用基礎(chǔ)設(shè)施組件(如路由器和交換機)來獲得統(tǒng)計數(shù)據(jù)。這種方法并不充分，因為度量粒度通常僅限于基于端口的計數(shù)器。它缺乏區(qū)分不同應(yīng)用程序和流量的能力。在第四節(jié)的建議中，我們使用啟用OpenFlow的交換機和路由器保存每個流的統(tǒng)計數(shù)據(jù)來確定端到端網(wǎng)絡(luò)性能。
2.3? 現(xiàn)有測量部署
簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)[5]是最常用的網(wǎng)絡(luò)狀態(tài)監(jiān)測協(xié)議之一。其中，SNMP可用于從交換機請求每個接口的端口計數(shù)器和整體節(jié)點統(tǒng)計信息。自1988年開發(fā)以來，它在大多數(shù)網(wǎng)絡(luò)設(shè)備中得到了應(yīng)用。使用SNMP進行監(jiān)視是通過定期輪詢交換機來實現(xiàn)的，但是由于CPU開銷，頻繁輪詢可能會降低交換機的效率。盡管供應(yīng)商可以自由地實現(xiàn)他們自己的SNMP計數(shù)器，但是大多數(shù)交換機僅限于為整個交換機及其每個接口聚合流量的計數(shù)器，從而禁用細粒度流量工程所需的流級統(tǒng)計信息。因此，我們認為SNMP不適合基于流的監(jiān)控。
NetFlow[6]提供了一個可伸縮的基于被動流的監(jiān)視示例。它收集交通樣本，并根據(jù)這些樣本估計總體流量統(tǒng)計數(shù)據(jù)，這些數(shù)據(jù)被認為對長期統(tǒng)計數(shù)據(jù)足夠準確。NetFlow使用1 / n隨機抽樣，這意味著它存儲每個n個數(shù)據(jù)包，并假設(shè)收集的數(shù)據(jù)包代表通過收集器的所有流量。每個可配置的時間間隔，路由器將收集到的流量統(tǒng)計信息發(fā)送到一個集中的單元，以便進一步聚合。包抽樣的主要問題之一是，如果注意到，小流量的代表性不足。此外，一個路徑上的多個監(jiān)控節(jié)點可能會采樣完全相同的數(shù)據(jù)包，從而過度表示某個流量組，降低了準確性。cSamp[7]通過使用流采樣代替包采樣來解決這些問題，并部署了基于哈希的協(xié)調(diào)來防止包的重復(fù)采樣。
Skitter[8]是一個CAIDA項目，它使用主動探測分析Internet拓撲結(jié)構(gòu)和性能，使用地理分布信標執(zhí)行大規(guī)模跟蹤。它的探測包包含計算RTT的時間戳和估計測量信標之間的延遲。當Skitter適合生成總體網(wǎng)絡(luò)延遲的粗略估計時，它不會計算每個流的延遲，因為除非安裝了非常高密度的信標，否則不會遍歷所有路徑。此外，該方法還引入了額外的不精確性，因為之前存在的不確定性邊際值的加減。
使用被動測量來測量數(shù)據(jù)包延遲稍微復(fù)雜一些。IPMON[9]提供了一種解決方案，它捕獲每個TCP/IP包的頭部，對其進行時間戳，并將其發(fā)送到中央服務(wù)器進行進一步分析。需要安裝多個監(jiān)視單元來檢索整個網(wǎng)絡(luò)的統(tǒng)計信息。如果技術(shù)非常精確(以微秒為單位)，則會由于與中央服務(wù)器進行必要的通信而產(chǎn)生額外的網(wǎng)絡(luò)開銷。此外，精度取決于監(jiān)測單元時鐘的精確同步。
?
雖然SDN并不局限于OpenFlow，但在OpenFlow之前就存在其他控制平面解耦機制，OpenFlow通常被認為是SDNs中配置和監(jiān)控交換機的標準通信協(xié)議。支持OpenFlow的開關(guān)連接到中央控制器，如POX[10]或Floodlight[11]?？刂破骷瓤梢杂棉D(zhuǎn)發(fā)規(guī)則預(yù)先配置交換機，也可以對交換機發(fā)出的請求做出響應(yīng)，當數(shù)據(jù)包與任何現(xiàn)有規(guī)則都不匹配時，交換機就會發(fā)送請求。除了管理轉(zhuǎn)發(fā)平面之外，OpenFlow協(xié)議還能夠請求每個流計數(shù)器的統(tǒng)計信息并向網(wǎng)絡(luò)注入數(shù)據(jù)包，這是我們在第四節(jié)中提出的建議中使用的功能。
更具體地說，當一個新的、當前不匹配的連接或包到達時，支持OpenFlow的交換機向控制器發(fā)送一個PacketIn消息。控制器響應(yīng)使用一個或多個流表修改消息(FlowMod)安裝路徑，并指示交換機使用PacketOut消息重新發(fā)送數(shù)據(jù)包。FlowMod消息指示空閑超時時間和硬超時時間，以及是否應(yīng)該用flowremove消息通知控制器這樣的刪除操作。圖1給出了流設(shè)置期間消息交換的示意圖。使用PacketIn和flowremove消息，控制器可以確定存在哪些活動流。此外，flowremove消息包含最近刪除的流的持續(xù)時間、包和字節(jié)數(shù)，使控制器能夠?qū)^去的流進行統(tǒng)計。我們在第四節(jié)中的建議將此信息與定期查詢的流統(tǒng)計請求(StatsRequest)消息結(jié)合使用，如圖2所示，以獲取正在運行的流的信息，并定期向網(wǎng)絡(luò)注入包，以監(jiān)視端到端路徑延遲。
OpenFlow對交換機和每條流統(tǒng)計數(shù)據(jù)的開放性已經(jīng)在最近的研究提議中得到了體現(xiàn)。例如，OpenTM[12]通過跟蹤每個流的統(tǒng)計信息來估計流量矩陣(TM)。應(yīng)用程序查詢按一定的間隔進行切換，并存儲統(tǒng)計信息，以便派生TM。本文對幾種輪詢算法進行了實驗，并對其精度進行了比較。當只輪詢所有路徑的最后一個開關(guān)時，會得到最準確的結(jié)果，而其他輪詢方案，例如選擇負載最少的開關(guān)輪詢，或(非)均勻隨機選擇，只會得到稍微不那么準確的結(jié)果，與最準確的最后一個開關(guān)選擇方案的偏差最多為2.3%。替代的輪詢方案、偏好的非均勻隨機選擇開關(guān)路徑的最后表現(xiàn)最精確而last-switch輪詢,緊隨其后的是統(tǒng)一的隨機選擇和循環(huán)的選擇開關(guān),當負載開關(guān)結(jié)束最后仍然有精度約在86 Mbps + 0.4 Mbps。但是，由于OpenTM僅限于生成供離線使用的TMs，并且不捕獲包丟失和延遲，因此我們認為它不適合在線監(jiān)視流。
OpenSAFE[13]側(cè)重于將流量分配給監(jiān)視應(yīng)用程序。它使用的事實是，每個新的流請求都通過網(wǎng)絡(luò)的OpenFlow控制器?？刂破鲗⑿铝髁康膭?chuàng)建轉(zhuǎn)發(fā)給多個流量監(jiān)控系統(tǒng)，該系統(tǒng)記錄流量并使用入侵檢測系統(tǒng)(IDS)進行分析。然而，OpenSAFE需要硬件投資來執(zhí)行實際的監(jiān)視，同時我們引入了一種機制，可以重用現(xiàn)有的OpenFlow命令來檢索上述指標。
其他人建議設(shè)計一種新的協(xié)議，并行于開放流，以實現(xiàn)SDNs中的監(jiān)控。例如，penSketch[14]提出了一種基于SDN的監(jiān)控體系結(jié)構(gòu)。然而，一個新的SDN協(xié)議需要升級或替換所有網(wǎng)絡(luò)節(jié)點，isp將不愿意進行大規(guī)模投資。此外，新協(xié)議的標準化已被證明是一項漫長而乏味的任務(wù)。由于OpenFlow已經(jīng)在數(shù)據(jù)中心環(huán)境中越來越受歡迎，并且越來越多地在commodity交換機中實現(xiàn)，所以使用OpenFlow的解決方案需要isp更少的投資來實現(xiàn)，并且不需要更大的社區(qū)進行標準化。因此，我們認為與OpenFlow兼容的監(jiān)視解決方案(比如我們的OpenNetMon解決方案)更有可能成功。
在本節(jié)中，我們將介紹我們的監(jiān)視解決方案OpenNetMon，它是作為OpenFlow控制器POX[10]的模塊編寫的。OpenNetMon不斷監(jiān)視預(yù)定義的鏈路-目標對之間的所有流量，包括吞吐量、數(shù)據(jù)包丟失和延遲。我們相信這樣一個顆粒狀的實時監(jiān)控系統(tǒng)對于交通工程(TE)來說是必不可少的。
在下面的小節(jié)中，我們將首先討論我們的實現(xiàn)如何監(jiān)視吞吐量，以及如何確定正確的輪詢算法和頻率，然后討論我們的實現(xiàn)如何度量包丟失和延遲。有人可能會說，在OpenFlow SDNs中測量吞吐量并不新鮮，盡管我們實現(xiàn)它是專門用于監(jiān)視的，而不是用于生成流量矩陣，但我們是第一個將它與針對數(shù)據(jù)包丟失和延遲的活動每流測量相結(jié)合的。
4.1? 輪詢吞吐量
為了確定每個流的吞吐量，OpenNetMon正則查詢切換到使用第三節(jié)中描述的消息檢索流統(tǒng)計信息。對于每個查詢，我們的模塊接收發(fā)送的字節(jié)數(shù)和每個流的持續(xù)時間，使它能夠計算每個流的有效吞吐量。由于任何節(jié)點對之間的每個流都可能得到控制器分配的不同路徑，所以O(shè)penNetMon會定期輪詢指定要監(jiān)視的每個節(jié)點對之間的每個不同分配路徑。
盡管隨機或輪詢每個路徑的開關(guān)被認為是最有效的，并且仍然足夠準確的[12]，我們輪詢每個路徑的最后一個開關(guān)。首先，在具有多個流的大型網(wǎng)絡(luò)中，輪詢交換機的選擇變得更加復(fù)雜。當存在更多的流時，非邊緣開關(guān)將更頻繁地輪詢，從而降低效率。此外，非邊緣開關(guān)通常需要維護更多的流，這使得流統(tǒng)計數(shù)據(jù)的查詢更加昂貴。其次，為了計算分段IV-B中的包丟失，我們周期性地查詢和比較每個路徑的第一個和最后一個交換機的包計數(shù)器。由于此查詢還返回吞吐量計算所需的字節(jié)和持續(xù)時間計數(shù)器，因此我們決定將這些查詢組合在一起，僅對每個路徑的最后一個開關(guān)進行采樣，以便進行吞吐量計算。
在大多數(shù)路由發(fā)現(xiàn)機制中，鏈路狀態(tài)信息在拓撲變化和保證同步的規(guī)則時間間隔內(nèi)交換，但是流的到達率可能會有很大的變化。正如我們將在下面簡要說明的，因此有必要自適應(yīng)地監(jiān)視流行為，方法是在流到達時增加輪詢間隔或更改它們的使用特性，并在流統(tǒng)計數(shù)據(jù)收斂到穩(wěn)定行為時減少輪詢間隔。
傳輸過程中信息的大量消耗以及內(nèi)容的編碼和壓縮導(dǎo)致流的流量需求高度波動，例如，HD視頻流所需的瞬時帶寬可以在1到9 Mbps之間變化。雖然通過多路復(fù)用抑制了這種行為，但是這種行為甚至在聚合鏈接上也是可見的，如圖3所示，在可用帶寬測量15分鐘包級跟蹤100 Mbps日本W(wǎng)AN鏈接時可以看到這一點。為了促進高效的流量工程，并在高利用率下運行網(wǎng)絡(luò)以節(jié)省第一節(jié)中討論的成本，需要關(guān)于每個鏈接和流的當前吞吐量的準確信息。
在許多不同的鏈路狀態(tài)更新政策提出了在過去幾十年[16],我們的實驗測量表明,基于絕對的還是相對的政策變化以及基于類或定時器策略不捕捉今天的網(wǎng)絡(luò)流量的動態(tài)在足夠詳細級別作為一個輸入流調(diào)度。圖4對比的區(qū)別實際帶寬10 Mbps的網(wǎng)絡(luò)鏈接和訪問帶寬估計的一個相對改變政策:隨著流迅速的變化要求,流的吞吐量是嚴重低估或高估的網(wǎng)絡(luò),從而超額認購和浪費資源,或潛在傷害流。這種行為是當前鏈路狀態(tài)更新策略根據(jù)最近但仍然是歷史的度量傳播信息的結(jié)果，目的是平衡過高的更新率或容忍過時的信息。雖然這個特定的跟蹤在原則上可以通過調(diào)優(yōu)更新速率或選擇不同的鏈接狀態(tài)更新策略來更好地逼近，但是所有現(xiàn)有方法都存在基本問題:圖5顯示了作為更新策略和更新頻率函數(shù)的平均相對估計誤差。
在減少過時性的同時，更定期的更新并不一定能提供更好的流信息，因為圖3或圖4所示的復(fù)雜流特性的動態(tài)特性如果不使用無窮小的時間間隔及其高昂的開銷，靜態(tài)報告間隔就不能很容易地接近它們。為了避免這個問題，我們提出的OpenNetMon使用了一個自適應(yīng)的流特性，當新流被接納或流統(tǒng)計數(shù)據(jù)發(fā)生變化時，它會提高采樣率，以便在靜態(tài)環(huán)境中，當獲得的新信息很少時提高分辨率和回退。
當基于網(wǎng)絡(luò)狀態(tài)的新細粒度視圖重新分配流時，OpenNetMon的自適應(yīng)特性在避免過多的路由抖動方面可能也很有用。對于動態(tài)網(wǎng)絡(luò)中路徑穩(wěn)定性的討論，我們參考[17]。
每個流的包丟失可以通過輪詢每個交換機的端口統(tǒng)計數(shù)據(jù)來估計，假設(shè)鏈路包丟失和每個流的吞吐率之間存在線性關(guān)系。然而，當流量根據(jù)QoS參數(shù)或優(yōu)先級進行排隊時，這種與流吞吐量的線性關(guān)系就不成立了。相反，我們通過輪詢每個路徑的第一個和最后一個交換機的流統(tǒng)計信息來計算每個流的數(shù)據(jù)包丟失。通過將源交換機包計數(shù)器的增量與目標交換機包計數(shù)器的增量相減，得到了對過去樣本包丟失的精確測量。
然而，路徑延遲更難測量。測量延遲不回避,被動的方式——這意味著沒有額外發(fā)送數(shù)據(jù)包通過網(wǎng)絡(luò)——OpenFlow由于不可行,不可能有開關(guān)標記樣品包的時間戳,也不太可能讓交換機復(fù)制和可預(yù)測的樣本數(shù)據(jù)包發(fā)送到控制器相比有其內(nèi)部到達的倍數(shù)。因此，我們使用OpenFlow的功能將數(shù)據(jù)包注入到網(wǎng)絡(luò)中。在每個被監(jiān)視的路徑上，我們定期在第一個交換機注入包，這樣探測包就會沿著完全相同的路徑運行，并讓最后一個交換機將它發(fā)送回控制器。控制器通過計算數(shù)據(jù)包離開和到達時間之間的差來估計整個路徑延遲，減去從切換到控制器延遲的估計延遲。通過將立即返回給控制器的包注入RTT來確定開關(guān)到控制器的延遲，并將RTT除以2來計算給出Tdelay = tarrival - Tsent - 12
(RT Ts1 + RT Ts2)的答案的雙向性，從而估計交換機到控制器的延遲。
第五部分的延遲實驗表明，使用控制平面注入和檢索探測數(shù)據(jù)包，使用OpenFlow PacketIn和PacketOut消息，會導(dǎo)致交換機控制平面的軟件調(diào)度產(chǎn)生不準確的結(jié)果。為了確保測量精度，我們連接一個單獨的VLAN，專門用于傳輸探頭數(shù)據(jù)包，從控制器直接到所有開關(guān)數(shù)據(jù)平面。該方法省去了開關(guān)的控制平面軟件，具有較高的精度。
為了使測量精度和包開銷與每個流的大小匹配，我們?yōu)槊總€路徑注入包，其速率相對于流吞吐量的底層和。也就是說，在某條路徑C上，從節(jié)點A到節(jié)點B的所有流量中，每秒的數(shù)據(jù)包數(shù)量越高，我們發(fā)送的數(shù)據(jù)包就越多，從而可以準確地判斷數(shù)據(jù)包丟失。平均每輪測量發(fā)送一個監(jiān)測包。雖然這乍一看會帶來開銷，但是監(jiān)視包是一個任意的72字節(jié)的小型以太網(wǎng)幀(包括序言在內(nèi)的最小幀大小)，它是基于一個MAC地址對沿著路徑轉(zhuǎn)發(fā)的，該地址對標識其路徑，并有一個包標識符作為有效負載。相對于默認的1500 MTU(在巨型幀中甚至更大)，導(dǎo)致沒有802.1Q VLAN標簽的幀數(shù)為1526字節(jié)，我們認為這么小的開銷是對所獲得的知識的合理懲罰。
在本節(jié)中，我們將通過物理測試平臺上的實驗來評估開放網(wǎng)絡(luò)mon的實現(xiàn)。我們的測試臺由兩臺運行庫存Ubuntu服務(wù)器12.04.2 LTS的Intel Xeon
Quad核心服務(wù)器組成，其中1 Gbps的nic連接到4臺運行庫存Ubuntu服務(wù)器13.04的Intel Xeon Quad核心服務(wù)器，使用Open
vSwitch作為兼容OpenFlow的交換機。網(wǎng)絡(luò)由運行POX OpenFlow控制器的相同服務(wù)器控制，如圖6所示。所有的主機都使用1gbps以太網(wǎng)連接到它們的交換機，因此我們假設(shè)本地有足夠的帶寬。然而，開關(guān)間的連接被限制在100mbps。開關(guān)1-2和3-4之間的延遲等于1毫秒，而開關(guān)2-3之間的延遲等于5毫秒，以模擬廣域網(wǎng)連接。此外，所有交換機之間的數(shù)據(jù)包丟失等于1%，導(dǎo)致平均數(shù)據(jù)包丟失略小于3%。使用NetEm[18]引入延遲和包丟失。使用這種拓撲，我們打算模擬一個小型的私有廣域網(wǎng)，由一個OpenFlow控制器控制。
在整個過程中，我們使用視頻流對流量進行建模。由于其突發(fā)性的流量，我們選擇了一個H.264編碼的電影，是流從服務(wù)器到客戶端。圖7顯示了通過實現(xiàn)OpenNetMon與Tcpstat比較，我們的服務(wù)器和客戶機之間的吞吐量。此外，圖8顯示了與配置的包丟失相比的包丟失情況。最后，圖9給出了在我們的網(wǎng)絡(luò)中測量到的延遲。
圖7中所示的度量代表了Tcpstat和OpenNetMon執(zhí)行的吞吐量度量，它們平均只相差16 KB/s(1.2%)，這表明大多數(shù)傳輸流量都被度量所考慮。然而，標準差為17.8%，乍一看，這似乎是一個相當大的誤差。這種誤差主要是由于兩個測量裝置之間缺乏同步造成的。由于我們無法同步最小1秒存儲段的開始時間，因此在一個度量中屬于一個存儲段的流量被歸入另一個度量中相鄰的兩個存儲段。再加上我們交通的高度緊張，這就導(dǎo)致了高度偏差。然而，從OpenNetMon的測量結(jié)果來看，平均值的高精度顯示了適當?shù)木_度。事實上，我們選擇了高度偏離的流量來證明我們在最壞情況下的測量場景中的實現(xiàn)，因此，我們聲稱我們的結(jié)果比流量不那么突發(fā)性的場景更可靠。
圖7中的吞吐量測量還顯示了偶然的峰值，隨后或之前出現(xiàn)了突然下降。由于開關(guān)的流計數(shù)器更新頻率和OpenNetMon的輪詢頻率匹配得太緊密，因此會出現(xiàn)綁定問題，所以引入了峰值。簡而言之，發(fā)生的情況是，我們的系統(tǒng)在第一輪更新計數(shù)器前不久請求計數(shù)器統(tǒng)計信息，而它已經(jīng)在相鄰的一輪更新了。雖然從長期來看，差異是平衡的，但兩個箱子的值都是相等的，但與期望值相反，導(dǎo)致標準差。
所述的邊值問題不能通過減少或增加輪詢頻率來解決，在最佳情況下，誤差幅度較小，但仍然存在。相反，兩端都需要根據(jù)系統(tǒng)時鐘實現(xiàn)更新和輪詢頻率，而不是使用流行的sleep函數(shù)，該函數(shù)由于操作系統(tǒng)調(diào)度器和輪詢和更新進程占用時間而引入了輕微的漂移。使用系統(tǒng)時鐘對更新和輪詢計時，確保兩個系統(tǒng)的采樣箱同步。此外，交換機需要實現(xiàn)一個系統(tǒng)來相互排斥對計數(shù)器的訪問，以確保流計數(shù)器在更新其所有屬性之前不能被讀取，反之亦然。另一個理想的解決方案是擴展OpenFlow，允許流計數(shù)器更新通過訂閱以可配置的間隔發(fā)送到控制器。但是，由于這需要同時更新OpenFlow規(guī)范和switch固件，所以我們不認為它在短時間內(nèi)是可行的。
由于一個時間樣本內(nèi)的丟包可能并不代表整個丟包行為，因此圖8顯示了通過計算路徑上第一個和最后一個交換機的包計數(shù)器之間的差異計算出的丟包平均運行時間。雖然運行中的數(shù)據(jù)包丟失不是很準確，但是這些測量數(shù)據(jù)提供了一個很好的估計來檢測服務(wù)退化。要獲得更準確的流包丟失估計，可以使用端口計數(shù)器統(tǒng)計數(shù)據(jù)中的插值。
圖10中的類別圖證實了這些經(jīng)驗，顯示基于控制平面的測量平均為4.91 ms, 95%的置信區(qū)間為11.0 ms。若平均值與期望值的差值已超過30%，則置信區(qū)間大于期望值的1.5倍，在實際應(yīng)用中不可行。然而，基于數(shù)據(jù)平面的測量確實顯示了7.16±0.104的準確估計值，這與稍微大一點的終端用戶應(yīng)用體驗(7.31±0.059 ms)非常接近。應(yīng)用程序延遲稍微大一些，因為從交換機到終端主機的鏈接延遲無法被OpenNetMon監(jiān)控。
這些結(jié)果表明，由于軟件引入的響應(yīng)時間波動過大，控制平面不適合作為精確時延測量的介質(zhì)。然而，我們能夠通過使用專門配置的VLAN將控制器連接到數(shù)據(jù)平面來獲得準確的結(jié)果，該VLAN用于將探測包從控制器轉(zhuǎn)發(fā)到網(wǎng)絡(luò)。
第六章?實現(xiàn)細節(jié)
OpenNetMon的實現(xiàn)是公開源碼的，可以在我們的GitHub web頁面[4]中找到。我們將其作為開源共享的主要意圖是使其他研究人員和業(yè)界能夠使用它進行實驗，將其用作獲取細粒度流量工程的輸入?yún)?shù)的方法，并在適用時將其擴展到它們的使用中。雖然OpenNetMon被認為是一個單獨的模塊，但在技術(shù)上它由POX OpenFlow控制器中實現(xiàn)的兩個模塊組件組成。轉(zhuǎn)發(fā)組件負責(zé)路徑的保留和安裝，而監(jiān)視組件負責(zé)實際的監(jiān)視。這兩個組件都依賴POX發(fā)現(xiàn)模塊來學(xué)習(xí)網(wǎng)絡(luò)拓撲結(jié)構(gòu)和更新。
與POX附帶的一些組件一樣，轉(zhuǎn)發(fā)組件了解網(wǎng)絡(luò)中節(jié)點的位置，并通過在交換機上安裝每流轉(zhuǎn)發(fā)規(guī)則來配置這些節(jié)點之間的路徑。但是，我們已經(jīng)實現(xiàn)了一些與我們將進一步闡述的其他POX轉(zhuǎn)發(fā)模塊不同的具體細節(jié)。您可以將此作為構(gòu)建自己的轉(zhuǎn)發(fā)模塊的小指南。
1) opennetmon不預(yù)先計算路徑，而是在需要時在線計算它們。在多路徑環(huán)境中(例如，請參閱[19])，并非從節(jié)點a到節(jié)點B的所有流都必須遵循相同的路徑，通過負載平衡或流量工程，任何兩個節(jié)點之間最好使用多個不同的路徑。為了支持監(jiān)控多徑網(wǎng)絡(luò)，我們決定實現(xiàn)一個轉(zhuǎn)發(fā)模塊，它可以計算任意節(jié)點a到b的多條路徑并從中進行選擇，特別是支持在線細粒度流量工程，它可以使用SAMCRA基于多個指標計算路徑
[20]路由算法，我們決定使用在線路徑計算來實現(xiàn)。我們立即在所有必需的交換機上安裝按流量轉(zhuǎn)發(fā)規(guī)則。我們發(fā)現(xiàn)，模塊附帶許多配置了路徑切換的控制器。這意味著一旦接收到不匹配的包，控制器就會在該交換機上配置特定的轉(zhuǎn)發(fā)規(guī)則，重新發(fā)送該包，然后從路徑上的下一個交換機接收到相同的包。此過程迭代，直到配置好所有開關(guān)。但是，我們的轉(zhuǎn)發(fā)模塊在從節(jié)點A到B的路徑上的所有交換機上安裝適當?shù)霓D(zhuǎn)發(fā)規(guī)則，然后將路徑上最后一個交換機的原始數(shù)據(jù)包重新發(fā)送到目的地。
3)在所有交換機的所有邊緣端口上，我們立即將目標未知的廣播消息和單播消息淹沒。我們發(fā)現(xiàn)被分類為被淹沒的包，或者由于它們的廣播或組播特性，或者由于它們的目標MAC地址位置仍然未知，被逐個開關(guān)淹沒的方法與前面提到的方法相同。最后，擴展樹中的每個交換機都用一個相同的包與控制器聯(lián)系，而該包的動作保持不變。此外，如果在此期間了解到以前未知的單播消息的目的地，則會導(dǎo)致轉(zhuǎn)發(fā)模塊安裝從該特定開關(guān)到目標開關(guān)的無效路徑。為了減少數(shù)據(jù)包到達時需要被淹沒的通信開銷，我們的實現(xiàn)將與所有交換機和所有邊緣端口上的洪泛連接。
4)我們只在邊緣端口上“學(xué)習(xí)”MAC地址，以防止學(xué)習(xí)主機無效的開關(guān)端口位置。
當安裝了可能具有不同路徑的新流時，轉(zhuǎn)發(fā)組件向監(jiān)視組件發(fā)送一個事件。執(zhí)行此操作后，監(jiān)視組件將把邊緣開關(guān)添加到自適應(yīng)計時器迭代的列表中。在每個定時器間隔，監(jiān)視組件從所有流目標和源開關(guān)請求流計數(shù)器。流計數(shù)器包含包計數(shù)器、字節(jié)計數(shù)器和每個流的持續(xù)時間。通過存儲上一輪的統(tǒng)計數(shù)據(jù)，可以確定這些計數(shù)器的增量來計算每流吞吐量和數(shù)據(jù)包丟失。
第七章?總結(jié)
在本文中，我們提出了OpenNetMon，這是一個POX OpenFlow控制器模塊，它監(jiān)視每個流的QoS指標，從而支持細粒度的流量工程。通過以自適應(yīng)速率輪詢流源和目標交換機，我們在最小化網(wǎng)絡(luò)和交換機CPU開銷的同時獲得了準確的結(jié)果。每個流的吞吐量和包丟失來自查詢的流計數(shù)器。相反，延遲是通過將探測包直接注入交換數(shù)據(jù)平面，沿著相同的路徑(即節(jié)點、鏈接和緩沖區(qū))移動，從而確定每個流的實際端到端延遲來測量的。我們已將建議的python實現(xiàn)代碼作為開放源碼發(fā)布，以支持在軟件定義的網(wǎng)絡(luò)中進行QoS領(lǐng)域的進一步研究和協(xié)作。
我們在一個模擬小型辦公室間網(wǎng)絡(luò)的硬件測試臺上進行了實驗，同時加載了具有高突發(fā)性能的流量。實驗測量結(jié)果驗證了所測吞吐量和監(jiān)測時延的準確性，而數(shù)據(jù)包丟失則較好地估計了可能的業(yè)務(wù)分解。
基于[21]中的工作，我們進一步建議將微流劃分為一個更大的流，直到識別為大象流，從而消除微流帶來的開銷。這可以防止控制器被無關(guān)緊要但可能數(shù)量眾多的流潛在地超載。在未來的工作中，我們打算使用OpenNetMon作為響應(yīng)式實時QoS控制器的輸入生成器，用于重新計算和重新分配路徑。
