1 介紹

網絡功能（NFs），或中間件是以復雜方式檢測和更改數據包和流的系統。比如：入侵檢測系統（IDSs），負載均衡器，緩存代理等。NFs在確保安全性，提高性能和提供其他新網絡功能方面起著關鍵性的作用。

最近，我們發現利用運行在通用計算資源上的基于軟件的NFs來替代專用網絡功能硬件越來越引起人們的興趣，即被稱為網絡功能虛擬化（NFV）的趨勢。同時，SDN被用來通過適當的NFs引流，從而執行決策和共同管理網絡和網絡負載。

結合NFV和SDN可以實現一類重要的管理應用，這類應用需要在多個網絡功能實例（如網絡負載均衡，彈性網絡伸縮）之間進行動態分組包處理。在此類應用場景下，“NFV+SDN”可以幫助實現以下三個重要目標：（1）、在NF性能和可用性方面滿足嚴格的服務等級協議（SLAs）；（2）、精確地監控和處理網絡流，比如，對所有包含惡意軟件的網絡流，IDS都應該報警；（3）、最小化NF運營成本。然而，目前同時實現三個目標是不可能的，從根本上說需要比“NFV+SDN”能提供的更多的控制功能。

要知道為何？我們考慮這樣一個場景，一個IDS過載，為了在吞吐量上滿足SLAs，必須進行網絡擴展（圖1）。通過NFV，我們可以輕易地創建一個新的IDS實例，通過SDN，我們可以將一些正在進行的流網絡路由到新創建的實例。然而，由于內部NF狀態是不可見的，可能發現不了攻擊。為了解決這個問題，SDN控制應用可以等待現有流的終止，且只重新路由新的流，但這樣就延遲了過載的緩解，并且增加了破壞SLA的可能性。由于一些NF內部狀態的不可復制或共享性，NF精確度也可能被破壞。

?

圖1 需要擴展和負載均衡來滿足吞吐量的SLAs和最小化運營成本的場景

在這個例子中，為了避免NF精確度和性能之間的權衡，唯一的辦法就是允許一個控制應用能快速并且安全地對一些流的內部IDS狀態從原始實例轉移到新的實例，同時更新網絡轉發狀態。類似的需求也出現在其他依賴動態重分配和分組處理的應用場景中，比如，快速升級NF和遠程處理的動態調用。

在本文中，我們提出一種控制平面架構OpenNF，它提供內部NF狀態和網絡轉發狀態的高效、協作控制，使得NF實例之間的流能夠快速、安全和細粒度的重分配。采用OpenNF，運營商能夠創建豐富的重分配處理控制應用，這些應用能最佳地滿足性能、可用性、安全性和成本目標，這樣就避免了麻煩的權衡決策。

設計OpenNF的三個主要挑戰如下：
C1: 解決競爭條件。這是重分配在線流時產生的最基本問題：當一些內部NF狀態被轉移時，數據包可能在轉移開始后到達源實例，或者在狀態轉移完成之前到達目的源。除非特別小心，不然，基于這些可能丟失的或者亂序的數據包來更新NF狀態，破壞了轉移安全性。同樣地，當從NF實例間復制狀態時，同時發生的更新可能導致狀態不一致，這些問題都可能降低NF的精確度。

為了說明競爭條件，我們引入兩個新的結構：（1）、一個從外部觀察的抽象事件，防止內部NFs的本地狀態改變。（2）、一個用于更新網絡轉發狀態的兩階段方案。我們展示了如何將兩者結合起來以確保狀態更新不會丟失，或者在狀態轉移時重新排序和共享狀態保持一致。

C2：限制開銷。第二個問題是保證重分配是高效的。NF實例之間的狀態轉移和共享會消耗NF CPU和網絡資源。此外，為了避免丟失，重排和狀態不一致，需要數據包緩沖，這會引入延遲和內存消耗。如果這些性能和資源消耗是無限制的，就無法滿足嚴格的SLAs和有限的運營成本。

為了限制開銷，我們提出了一個靈活的北向接口，用于控制應用明確地指定哪些狀態進行轉移，復制和共享，以及哪些保證執行（例如，無損耗）。

C3：以最小變化適應各種NFs。最后一個問題是確保我們的架構能適應以大量非入侵方式的各種各樣的NFs。給NFs提供接口來創建/更新狀態是一種方法，但是這種方法限定了內部NFs轉態的結構，可能也不適合需要一些數據包處理邏輯的狀態分配/訪問。相反，我們為NFs設計了一種新的南向接口，允許控制器請求NF狀態的進出口，而不改變NFs內部是如何管理狀態的。

我們使用Floodlight實現了我們的北向接口API，利用這個API，我們開發了幾個控制應用。我們也增加了四個NFs—Bro, Squid, iptables, 和PRADS，用于支持南向接口API。
? ? ?

我們對OpenNF評估表明：（1）、OpenNF可以消除虛假警報，并且和使用電流控制框架需要的數十分鐘相比，我們能及時縮減NF規模；（2）、狀態可以高效地轉移，復制和共享，即使是需要一些特定的要求，比如：對于500規模的流進行無丟失狀態轉移，在這個操作過程中，只需要215ms加上50ms的包接收延遲；（3）、添加對OpenNF南向接口API的支持，最多只增加9.8%的代碼量，在NFs狀態進出的過程中，包處理時間增加將少于6%。

2 為何使用 OpenNF?

當分組處理是被一個NF的多個實例統一進行處理時，NF的部署通常需要滿足以下三個重要目標：（1）、在性能和可用性上滿足嚴格的SLAs——比如，大部分時間的總吞吐量應該超過1Gbps，用于處理流的宕機時間應該少于10分鐘/每年；（2）、精確地監控和處理網絡流量，比如，對所有包含惡意軟件包流的HTTP流，IDS應該發起警報，RE解碼器應該能夠正確地恢復由RE編碼器消除的冗余；（3）、最小化運營成本。例如，當不需要額外的容量時，資源應該關閉。

目前，同時實現這三個目標是不可能的，除了結合NFV和SDN能提供的功能之外，我們需要更多的控制機制。下面，我們描述若干個具體實例，并突出以上三大目標是如何轉化成控制平面需求的。我們也會討論當前的一些NFV和SDN控制框架，以及如何簡化和增加它們以滿足需求。

2.1 動機實例
總是選擇最新的NFs。為了最大程度的保證安全，移動手機用戶可能希望本次的數據能夠被最新的NF軟件處理。舉個例子說，SLA要求流量每年被過時的NF實例處理的時間不超過10分鐘。幸運的是，NFV允許在我們幾毫秒內使用更新的NF實例，同時SDN允許我們在相同的時間內重新路由到那個更新的NF實例。然而由于缺少新實例的內部NF狀態，這種簡單重路由流量可能會降低NF準確性：舉例來說，將一個活躍的HTTP流重新路由到一個新的IDS，由于缺少流中先前報文的原數據，會造成入侵檢測系統錯過對一些惡意軟件的檢測。為了克服這個問題，我們可以等到正在處理的流終止，只對新的流重新路由。然而，由于流的持續時間是不受控制的，這個方法不能保證滿足SLA，舉個例子，蜂窩網絡中超過40%的流的超過10分鐘。同時滿足SLA協議以及維持網路功能正確性的唯一方法就是控制面提供將NF狀態和它的更新轉化為網絡傳遞狀態的功能。此外，操作必須在限定的時間內完成。

為了保證NF在狀態傳輸期間以及狀態傳輸之后的正確(目標2)，沒有數據包或者更新在傳輸過程中丟失以及沒有重新排序的更新發生是很重要的兩點。舉個例子，IDS對一個復制的報文處理，此時如果一個復制的流量在狀態傳遞時丟失，IDS實例將沒有機會請求重傳該報文。這個可能會導致沒有進行安全報警，因為IDS在一個連接上僅僅收到部分用于惡意軟件檢測的數據。同樣的，IDS可能會錯誤報警如果它沒有按順序收到請求建立報文(SYN)和數據處理報文。因此，控制面必須提供對于諸如無損傳輸和順序保持傳輸的重要保證。（我們將在5.1節正式定義無損傳輸和保持順序）。

高效的網絡控制。移動電話用戶也很關心網絡的性能。舉個例子，SLA可能要求NF部署吞吐量在大多數時刻超過1Gbps。由于數據包處理的復雜性，僅僅依靠單一的NF實例去滿足SLA的要求困難太大。幸運的是， NFV允許NF在網絡負載增加的時候動態擴展，同時SDN允許流被重新路由到新的NF。然而，正如在第一個方案中說的那樣，流必須被快速重新路由—一直等到流的終止會導致網絡功能持續負載過重并且破壞SLA(目標1)，而關于安全性，不移動內部NF狀態的重新路由方式會降低NF的正確性(目標2).(以一種不丟失和不亂序的方式)。相似的，在事先考慮快速重路由和安全性的情況下，當網絡的負載降低時，網絡功能應該收縮來減少操作消耗(目的3)。為了達到這個目的，我們還是需要將NF狀態以及它的狀態更新轉化為網絡傳遞狀態，并且這種轉化必須在限定時間內完成并且有重要保證。

當重新平衡負載時，我們可能要考慮到NFs用于多個流的情況。舉個例子， IDS為每個終端主機保持連接計數器。如果以主機或者子網為粒度，網絡是平衡的，一個主機所有的流經過相同的IDS實例，計數器可以交給這個實例。然而，當主機上的流被平衡到不同的實例，所有的實例必須有該計數器。更進一步的說，如果一個處理流的實例終止了，主機的在該實例上的流被移動其它剩余的實例上，那么這兩個實例的計數器需要合并。因此，控制面必須提供轉移、復制或者共享、以及合并到多個流相關的NF狀態。

網絡功能故障只占用少量資源快速恢復。當一個NF實例發生故障時，我們可以通過重路由正在處理的流到一個正常的實例來減少故障時間。為了讓這些流能夠正確的被處理，被選中的實例必須能夠獲得關鍵的NF狀態。達到這個目的的方法之一就是為所有的NF實例周期性的備份；這對于在該NF實例的CPU和存儲帶寬的消耗不可忽略(目標3)，由于各個備份之間的延時會導致備份中有大量的過時狀態。第二種方法只備份NF狀態更新的部分。這種方法會消除過時狀態的問題，并且資源的占用和狀態更新的頻率以及被備份狀態的數量成比例增長。為了支持這種方式，我們需要能夠復制NF狀態，同時需要能夠跟蹤狀態何時以及如何更新。

基于對本地NF的前期觀察，一個企業可能想對當前正在處理的流的某個子集進行更深層次更高級的處理（目標2的變體）。舉個例子，當IDS檢測到內部的主機正在向一個被列入黑名單的域名發送HTTP請求，企業要啟用對惡意軟件的分析會進行回復的數據包處理功能。由于本地IDS的資源限制，企業可能會利用云端更加強大的遠程IDS.更進一步說，為了避免將所有流量重定向到云端的帶來的消耗（目標3），其它主機的流量必須在本地處理。這個需要在先前的例子強調的特性的支持（例如將特定流的狀態無損耗傳輸）。除此之外，更高級的處理實際上需要獲得更多的狀態細節：舉例來說，云端的IDS可能要為與一些已經眾所周知的攻擊庫比較簽名，為新的流創建額外的狀態。因此，網絡控制面不能限制NF創建額外狀態的能力。更進一步說，如果這個被處理的流之后會傳回到原來的NF實例，那么這個額外的狀態必須要能夠被自動捕獲。

2.2 相關工作
現有的控制平面，如PLayer, SIMPLE, Stratos, FlowTags, 和一些連接技巧，僅僅提供控制，協調和流量轉發。如已經討論過的，在不降低NF精度的條件下，單獨的轉發變化是不能滿足各種各樣需求目標的。

VM或者進程的復制只允許一整個地克隆NF實例。額外的，包含于克隆中的不需要的狀態不僅浪費內存，而且更為嚴重的是能導致不良的NF行為。比如，IDS可能產生錯誤的警報。此外，這種方法阻止了多種NF實例的狀態的轉移和合并，妨礙了快速彈性收縮。由于他們固有的限制，結合現有的控制平面和VM遷移/過程復制技術不能滿足上述的需求。

供應商提供的控制器在多個NF實例之間進行狀態轉移，復制和共享時，可能影響NFs的內部工作信息。但是，他們不能以一種方式控制網絡狀態來滿足所有的目標。例如，很難通過網絡鏈路提供優化的負載均衡。

拆分/合并和輕量復制是唯一提供一些對內部NF狀態和網絡狀態控制的系統。他們提供一個共享庫，NFs使用這個共享庫，可通過預先定義的API來創建，訪問，和更改內部狀態。編排器通過調用一個簡單的遷移操作（重新路由流f并轉移相應的NF狀態）來協調負載均衡。在輕量復制中，NF加進一些模塊來管理進出各個實例的分組流，并且根據預先定義的頻率進行狀態的克隆。

不幸的是，遷移操作可能會導致NF狀態更新的丟失和亂序，因為遷移之后到達NF實例的分組將被丟棄，應用網絡轉發狀態更新和重新恢復網絡流之間仍然存在競爭。此外，編排器和NF模塊式針對特定問題的，使得他們不能很好地支持復雜的控制應用。最后，NFs必須使用API來創建和訪問狀態，通過使用不是基于流狀態的秘鑰，使得當流被重新路由時，很難知道存在狀態的轉移和復制。API值允許每種流一種狀態分配，需要重建一些內部NF狀態和分組處理邏輯。我們在本文的后面章節更詳細地討論這些問題。

3 OpenNF概述

OpenNF是一種新的控制平面架構（圖2），這種架構滿足上述需求和挑戰。本節中，我們將列出關鍵思想，§4 和 §5中詳述細節。

?

圖2 OpenNF架構

OpenNF允許控制應用直接管理NFs的行為和性能，以滿足高標準的要求。基于NF輸出和外部輸入，控制應用：（1）、確定特定NF實例應該處理的流集，（2）、指示控制器提供每個實例所必須的狀態，包括流特定狀態和流之間的共享狀態，（3）、讓控制器提供狀態和狀態操作的特定保障。

相應地，OpenNF控制器封裝了分布式狀態控制的復雜性，當被請求的時候，為狀態和狀態操作保證不丟失、不亂序和一致性。我們設計了兩個新的方案來克服潛在的競爭條件：（1）、一個抽象的事件，控制器用來直接監視狀態的更新，或者阻止更新但是知道哪些更新是預期的，（2）、一個兩階段的轉發狀態更新方案。使用前者，控制器可以確保轉移操作部丟失，和狀態副本最終的一致性。通過利用方案2中的步驟，仔細測序狀態更新或更新一致性（方案1），控制器可以確保轉移操作的不丟失和不亂序；我們在技術報告中提供了正式的證明。最后，通過緩沖與預期更新相應的事件，并一次一個地處理狀態的副本，控制器可以確保狀態副本的嚴格一致性。

OpenNF的南向接口API為控制器定義了一個標準的NF接口，用于請求事件和內部NF狀態的進出。通過一個出口調用，NFs用它來完成所有狀態的過濾器匹配，和確定如何將現有狀態和進口調用提供的狀態合并。這需要對NFs進行適當的功能添加，關鍵的是不能限制，或者需要對NFs維持的狀態數據結構進行更改。此外，我們使用已定義好的流的概念（比如，TCP連接）作為基礎，來指定哪個狀態進和出。這就自然和NFs已經創建，讀取和更新的狀態保持一致了。