• 文章名稱：OpenState: Programming Platform-independent Stateful OpenFlow Applications Inside the Switch
• OpenState：在交換機內部實現程式設計平臺無關的帶狀態OpenFlow應用程式
• 發表時間：2018
• 期刊來源：ACM SIGCOMM Computer Communication Review

ABSTRACT (摘要)

軟體定義網路設想由中央控制器管理dumb的廉價交換機。事實上，在交換機上新增某種級別的控制邏輯可能對於降低邏輯集中的中央控制器負載有很大幫助，這些控制邏輯可以在交換機內以線速進行解決。同樣的，它可以減少下發到特殊的中間盒裝置進行流處理的任務數量。潛在的挑戰是，我們是否可以設計一個帶狀態資料平面可程式設計概念（相對無狀態的OpenFlow match/action table 而言），它仍然需要高效能並且與服務商的偏好相一致。我們認為一個有希望的答案圍繞著擴充套件有限狀態機的使用，作為OpenFlow匹配/動作抽象的擴充套件（超集）。我們具體的將我們提出的概念變為一個實際的基於表的API，而且，或許令人驚訝的是，我們展示瞭如何（主要）重用已經在OpenFlow裝置中實現的核心原語來支援它。

1 INTRODUCTION(介紹)

OpenFlow的出現是為了改變配置不同服務商提供的裝置非常困難的情況，OpenFlow的方法是識別與供應商無關的程式設計抽象，以便配置交換結構的轉發行為。通過OpenFlow應用程式介面（API），網路管理員可以遠端配置執行狀態的轉發表，探測流量統計，並且將與本地流表項不匹配的資料包轉發到控制器，做進一步的處理以及做出相關的決定；OpenFlow將SDN帶入到現實世界。通過OpenFlow 的“match/action”概念，裝置程式設計人員可以通過首部匹配規則廣泛的指定一條流，對匹配的資料包關聯轉發/處理動作，並且訪問指定資料包的位元組/資料包資訊。

1.1 “dumb” switches: choice or compromise?

OpenFlow版本到2014已經發展到了1.4版本，但是和最初的簡單概念相比，複雜了很多，為了滿足現實世界的需求，OpenFlow協議不斷擴充套件，這可能最終威脅到OpenFlow發明者的原始供應商獨立目標。

結果，儘管OpenFlow裝置現在有許多功能和原語，但是它仍然顯得“dumb”，所有的“smartness”被放在控制器上。在最好的情況下，這會導致額外的信令負載和處理延遲，並要求對邏輯“中央化”控制器進行毛細管分散式實現。在最壞的情況下，先前非常慢的控制平面操作阻止了對網路控制演算法的支援，這需要在資料平面轉發行為中進行快速，實時的重新配置。

1.2 Contribution

如上所述，OpenFlow的主要的缺點是它沒有能力讓程式設計師在裝置本身部署狀態。僅僅為OpenFlow加上狀態是不夠的：程式設計師應該有能力規範狀態如何進行處理，並且這個配置應該在裝置之外執行，同時沒有控制器的參與。一個可行的解決方法必須有以下兩個基本特性。

• 1，必須適合高速實現
• 2，必須不違背服務商敏感原則，它應該是一個具體的可程式設計概念，而不是一個技術方法。

我們的工作主要在第二個方面：儘管在第3節關於我們提出的方法有一些提示，它可以被現在OpenFlow硬體高效地支援，我們並不認為它對這方面的問題已經完全解決。 ** 相反，我們主要的貢獻在於提出了一可行的個概念，這個概念正式地描述了在裝置內部進行期待的帶狀態流處理，同時不暴露裝置內部的設計實現。**

我們的概念依賴於eXtended Finite State Machines（XFSM），最近被認為在不同網路區域、平臺無關的無線媒體訪問控制程式設計性上具有高效性。 具體地說，本文將在section 2引入簡化的XFSM （我們稱之為Mealy Machine）以及相關的可程式設計介面，這可以解釋為OpenFlow匹配/動作抽象的一種自然概括。在section 3，我們將討論可行性和實現問題，展示XFSM支援可以大量的重用現在的OpenFlow特徵。最後，section 4討論了完全支援XFSMs和可能的益處。

1.3 Related work

需要擴張OpenFlow資料平面的概念最近才被研究社群意識到。在[15],作者指出現在硬體交換機古板的表結構限制了OpenFlow資料包匹配固定欄位以及動作集的處理，並且在現有的固定物理表和動作原語上介紹了一種邏輯表結構RMT(Reconfigurable Match Table)。顯然，提出的方案允許不僅考慮了首部向量任意匹配的寬度和深度，同時定義了可以作為輸入引數、修改首部欄位的動作（action）。在[16]中，這種方法更加激進，與早期的主動網路工作類似，允許資料包攜帶一個微小的程式碼，在交換機資料平面中進行精細處理。一個非常有趣的方面是有針對性的ASIC實現的提議，其中可以使用極小的指令集和儲存器空間來定義分組處理。OpenFlow擴充套件似乎為其增加更多的功能和能力，但是對於如何適當地在一個乾淨的API上適當的容納它們的關注卻非常有限。

最後，XFSMs的使用靈感來源於[8]，在[8]中，XFSMs被用於傳送期望的媒體訪問許可權控制操作到無限介面卡。儘管概念相似，但是背景，技術選擇和事件處理沒有可比性。

2 BASIC ABSTRACTION

2.1 An illustrate example

OpenFlow資料平面概念，在1.1版本基於單表的match/action規則，並且從1.1版本後是多表。除非遠端控制器通過flow-mod訊息明確更改，否則規則是靜態的，比如，一條流的所有的資料包經歷同樣的轉發行為。

然而，許多應用程式將受益於逐個分組地演進轉發行為的能力，即，取決於我們到目前為止已經接收到的資料包序列，比如，依賴於目前已經收到的資料包序列。一個很好的例子就是埠訪問，是防火牆開放埠的一種著名的方法。一個主機檢視建立一個連線（稱之為ssh會話，比如，埠22）傳送一些列資料包，傳送到預先指定的封閉埠有序列表，比如埠5123,6234,7354和8456。一旦接收到到資料包的精確序列，防火牆將為對應的主機開啟22埠。在開啟埠之前，收到的資料包都將被丟棄（drop）。

與其他帶狀態應用一樣，這樣的操作不能在OpenFlow交換機內進行配置，但是必須在外部控制器上實現。花費的代價是要將大量的信令資訊（原則上直到所有封閉埠的資料包）傳送給控制器。而且，一個及時的控制器flow-mod 命令需要在正確的訪問序列之後開啟22埠，防止合理序列之後的ssh資料包發現22埠仍然關閉。另一方面，在控制器上實現這樣的應用並未帶來利益：它不會受益於網路範圍的知識或高級別安全策略[17]，但只使用與特定流量相關的本地狀態。

無論如何，讓我們先推遲關於在哪裡實現這個操作的討論，並且集中於我們可以如何model這樣的期待的行為。按理說，最自然的方式是將每個主機與圖1中所示的有限狀態機相關聯。開始於DEFAULT狀態，每個正確的埠訪問會導致過渡到一系列三個中間狀態，直到到達最後的OPEN狀態。期間，任何一個不符合期望的埠訪問會導致埠狀態回到DEFAULT狀態。當再OPEN狀態時，資料包將傳送到22埠（並且只有在這個埠將被轉發），而所有其他的包將被丟棄，但是不會將狀態重置為DEFAULT。

2.2 Extended Finite State Machines

仔細檢視Figure 1，揭示了每個狀態遷移引起的事件（event），詳細的包含資料包匹配的給出埠。而且，event match 引發每個狀態遷移，引起相關的動作（轉發/丟棄）。因此，狀態轉換非常密切地提醒傳統的OpenFlow匹配/操作規則，但是放在一個更通用的框架中，其特徵在於以下兩個區別方面。

2.2.1 XFSM Abstraction

配置了event的匹配不僅依賴於資料包頭資訊，並且依賴於狀態（state）；用上述的埠訪問例子，當處於OPEN 狀態時，一個數據包攜帶了port =22，關聯一個轉發動作，但是在其他的狀態時，關聯的是丟棄動作。而且，事件（event）不僅導致action，同時引起狀態遷移到下一個狀態（包括狀態遷移到本身，狀態不變的情況）。

所有的這些可以通過簡化的eXtended Finite State Machine (XFSM)，即Mealy Machine，建模成一個抽象的形式。正規地，這樣簡化的抽象模型包含一個四元組（S，I，O，T），另加一個初始的開始狀態（default）S0，

• i)S 是一個有限狀態集；
• • ii） I是輸入訊號（events）的有限集合;
• • iii) O是輸出有限集（action）;
• • iv) T是S×I -> S×O ，是一個狀態遷移函式，對映<state,event>對 到<state,action>對。
• 類似於OpenFlow API，通過限制集合O為當前OpenFow支援的動作，以及限制event集合I為OpenFlow 匹配的首部欄位和元資料，使其在硬體平臺簡易地實現。，使概念變成具體的（保留平臺的獨立性）。有限的狀態集S（具體地，狀態標籤，比如bit 串），以及相關的狀態遷移，本質上，帶狀態應用的“behavior”，導致了程式設計師的自由。

2.2.2 State Management

OpenFlow中的匹配通常在流表中收集。到目前為止進行的討論建議明確區分定義事件的匹配（埠訪問示例中的埠匹配）與定義流的匹配，意味著歸屬於狀態的實體（主機IP地址）。 而event匹配對給出的流造成狀態遷移，並且被XFSM所配置，流匹配負責識別和管理到來的資料包所屬的流的相關狀態。不同的表（XFSM table 和State table)，以及三個邏輯步驟自然地出現以處理資料包（見Figure 2）。

• 1. State lookup: 使用表示一條流的資料包頭欄位（可以標識這條流），作為鍵查詢一個狀態表（State Table），比如源IP地址；如果為沒能對應的流查詢到一個狀態，我們可以將返回default狀態；
• 1. XFSM transition: 被檢測到的state標籤，作為元資料新增到包中，和首部區域一同用於XFSM表的匹配。返回相關的動作以及下一個狀態標記。
• 1. State update
     這包含使用重寫（或者增加）下一個標籤到state table中。

Figure 2中的例子展示了埠訪問例子是如何通過我們提出的方法進行支援的。包含在XFSM表中的程式（7個條目）實現了埠訪問狀態機。假設從1.2.3.4來了一個數據包，state lookup（圖頂端）允許檢測當前的狀態，是STAGE-3。通過XFSM表（圖中間），我們確定這個狀態，伴隨著的訪問埠號為8456，觸發了一個drop動作，並且狀態變化為OPEN（圖中間）。新的狀態為對應的主機表項寫回到狀態表（圖底部）。在XFSM表中，我們假設有序的匹配有限集，最後一行有著最低的優先順序。因此，對於與預期的已訪問埠不匹配的資料包，所有四個轉換到預設狀態都會在最後一個條目中合併。所提出的解決方案的一個顯著特徵是表的長度與流的數量（狀態表）和狀態數（XFSM表）成比例，但與其產品無關。

2.3 Flow identification

上述抽象仍然遺漏了一個基本的進一步的步驟，它允許對重要的帶狀態操作的子集建模，其中給定流的狀態由在不同流上發生的事件更新。一個重要的例子是MAC學習：資料包通過目的地址進行轉發，但是轉發的資料庫是使用源MAC地址進行更新。相似的，對於雙向流的處理可能有同樣的需要。比如，政策到一個返回的TCP SYNACK資料包可能會在相反的方向上觸發一個狀態遷移。另外像FTP協議，控制在21號埠上的改變，可能會用於在20號埠上的資料傳輸會話的狀態設定。

引起這個問題的根源是，到目前為止，我們仍沒能夠概念地將與狀態相關的流的標識與首部區域（在其中找到識別符號）實際位置分開。因此，在我們提出的概念中，流的識別是需要查詢和更新狀態表，我們只需要為程式設計師提供在狀態表的這兩次訪問中使用最終不同的頭欄位的能力。因此我們定義為“lookup-scope”和“update-scope” 首部區域序列順序，這將是用於產生訪問狀態表和執行查詢或更新操作的關鍵。

隨著這樣的特徵，程式設計MAC學習操作變成不重要了。我們首先定義與流標識（即MAC地址）關聯的狀態，當前交換機埠應該轉發資料包（如果尚未學習埠則為DEFAULT）。在狀態查詢時，lookup-scope 被指是為MAC目的地址。在狀態更新期間，我們將update-scope 為 MAC源地址。最終，我們將使用Table1的遷移填充XFSM表。由於update-scope，用於State Table 更新使用的<key,value>是<macsrc,next-state>。在這個樣例表中，我們有意假設與當前OpenFlow配置的相容性，並且N^2+N大小的表（N是交換機的埠）依賴於OpenFlow的限制，而不是我們的XFSM概念。實際上，我們注意到[15]中最近引入的可重配置匹配表所允許的引數的使用將產生僅包含兩個條目的XFSM表：定義一個加上條目狀態：port(i)×event : in port(j) ->action : output(i) × next state : in port(j)。

2.4 Application Programming Interface

作為總結，我們基本的資料平面程式設計概念以正式地配置帶狀態操作包括兩個表的規範。

• 一個 XFSM 表包括 i)state提供作為使用者定義的標籤，ii）event 表達為OpenFlow匹配,iii）一系列OpenFlow actions，以及iv）next-state標籤，每一行都是設計的狀態遷移。
• lookup-scope和update-scope分別用於訪問和更新狀
  態表。

現在仍不清楚，在此階段，對於產生允許在XFSM表中繫結不同 update-scope 表項的API是否會很方便；換句話說，將每個下一狀態條目與其更新範圍相關聯，然後根據所考慮的特定轉換而不同（XFSM表中的一行）。實際上，對於這個額外的靈活性，我們仍未找到一個明確的用例，將以額外的內部硬體複雜性作為代價。

3 IMPLEMENTATION ISSUES

3.1 Feasibility analysis

我們首先定義一個交換機架構應該如何概念地擴充套件以支援我們提出的帶狀態操作。我們具體集中注意力在，哪些OpenFlow原語可以被重用（如何重用），以及哪些新的原語需要新增。。

3.11 Architecture and primitives

我們方案的一個關鍵特性是使用state labels執行匹配並使用多個表。這些特徵實際上是可行的：因為OpenFlow1.1 引入了table管道處理和元資料支援。一個數據包進入OpenFLow交換機通過一些列相關聯的流表進行處理，關聯的流表提供匹配、轉發、和資料包修改。元資料用於擴充套件資料包頭，這是為了從一個表攜帶任意的資訊到另外一個表。控制器可以通過傳送flow-mod訊息安裝移除流表項。

我們用無狀態階段（stateless state）表示由單個流表操作的處理。反過來，我們定義
帶狀態階段（stateful stage）(Figure 3)為一個邏輯的塊，由State Table 和 XFSM Table組成，並且實現我們的概念。一個數據包首先通過鍵 提取器（extractor）進行處理，產生一個位元字串代表用於匹配狀態表中一行資料的鍵。鍵是通過把在lookup-scope定義的首部欄位聯絡起來得到的。匹配到的state label被當做元資料插入到資料包首部。為了防止匹配失敗（table-miss），DEFAULT狀態將插入到資料包頭。如果由lookup-scope配置的首部區域沒有找到（比如，當乙太網型別不是IP時，提取源IP地址，），那麼特殊的狀態值NULL將被返回。

XFSM table可以在OpenFLow1.1以上版本進行實現，因為標準的流表的表項是使用相關的首部欄位代表event和（元資料）state label進行匹配的。我們僅需要配置執行的動作集，作為OpenFlow指令開發的補充命令，特別地，新的SET_STATE指令將會立即觸發一個更新之前的狀態表的動作。一個指令的使用保證了狀態更新是在階段的最後執行的，即使配置了動作包，也允許使用補充階段（包括其他帶狀態階段）來管理我們的帶狀態階段。

通過鍵提取器對資料包首部進行處理，再重寫狀態資訊，將被定義為update-scope，獲得的鍵將被用於在state table重寫或者新增新的一行。狀態更新同樣可以通過控制器執行，類似於flow-mod，由於這個原因，我們將它們命名為state-mod 訊息。

3.1.2 Configuration

我們假設預設情況下，交換機為流水線處理提供的所有流表都是無狀態的（即標準Openflow）。控制器可以傳送控制資訊給交換機，從而可以支援一個或者更多流表的帶狀態處理。通過將帶狀態表（state table）與現在的流表和定義的lookup-scope和update-scope進行關聯，配置帶狀態階段。顯然，lookup-scope和update-scope必須提供一樣長度的鍵（keys），在同類的流集合上，XFSM的定義是一致的。

一旦帶狀態階段被配置，控制器可以在流表上執行安裝表項，這些表項將會匹配流的當前狀態。重點注意的是，XFSM的完整描述，可以把安裝在流表的流表項集合，看作是由event,state matching ,state transitions action的組合，進行理解。

3.1.3 Support for multiple XFSMs

執行在不同的scopes的多個XFSM專案可以使用多個帶狀態階段的流水線技術進行普通的配置。更有趣的不同的XFSMs必須在相同範圍進行配置。比如，在埠訪問中，我們希望擁有一個地址集合，表示來源於子網 131.175/16，對此，我們希望有一個不同的訪問序列，或者甚至是預設開啟22號埠，而不用通過訪問過程。這可以通過為State Table新增字首匹配的能力（比如，匹配IPsrc = 131.175..），並且使用優先順序排序（或者最長的匹配）確定用於檢索相關狀態的匹配，從而輕鬆實現。

3.2 Software datapath implementation(軟體資料通路實現)

更吸引人的硬體實現是一個更長遠的目標，我們嘗試通過發展原型軟體實現獲取更長遠的見解。我們利用提出的帶狀態操作擴充套件、支援了OpenFlow1.3軟體交換機。我們的實現是可行的，在[19]，因此我們限制於總結主要的修改（很少，作為我們提案影響較小的進一步證明）。

為了支援釋出和撇子和提出的狀態管理特點，新的交換機能力 OFPC_TABLE_STATEFUL 位被定義，另外還定義了新表配置位 OFPCT_TABLE_STATEFUL。 擴充套件了基本的流表資料結構，支援state table 和 鍵 提取器。通過新增新的OpenFlow指令----OFPIT_SET_STATE ，允許OpenFlow擴充套件datapath，以用next-state引數更新狀態表。已經定義一個名為OFP_STATE_MOD的新狀態修改訊息以及相關的訊息結構，以允許控制器分別的配置狀態表項和鍵（key）提取器（lookup-scope和update-scope）。正如簡要預料，實際的XFSM table配置和實現已經不要求對現在程式碼進行任何修改，因為它只是依賴於標準的OpenFlow match table 結構和flow-mod message（除了已經討論的對新OFPT_SET_STATE指令的支援）。

4 BEYOND THE BASIC ABSTR

雖然在前面的部分中概述了我們的基本思想，但我們試圖保持對當前OpenFlow功能的基礎，以便有希望讓讀者相信我們提出的建議不是未來主義，而是可以輕鬆部署。以下，我們拋棄謹慎，然後嘗試概括（沒有做任何堅定的主張，而是為了激發討論的目標）同樣的可程式設計模型如何沿著不同的複雜方向擴充套件，以提供裝置程式設計師更進一步的網路功能程式設計能力。

我們認同，我們提出的方法並不能實現所有現在中間盒裝置上支援的功能。但是，我們希望其中的一些不太複雜的功能可以轉移到交換機以支援更敏感的網路反應。

4.1 Improving state handling

• 軟狀態和事件計時器。
  在OpenFlow中為狀態表表項新增超時是直截了當的，另外API可以被擴充套件，以允許程式設計師為每一個狀態變換配置不同的超時（timeout）。管理超時過期也很簡單的，，但前提是我們假設所有狀態在超時到期時返回到DEFAULT狀態。實際上，超時可以通過假設狀態查詢，檢索一個到期狀態將會返回DEFAULT狀態，相比較，處理時間超時作為隱式的事件，這將觸發有意義的（非預設的）變換，可能開啟更有趣的場景（支援指數退避操作，根據ACK在時間視窗之前或之後返回等來強制執行不同的TCP轉發等），但是按理說，要求在實現上有一個意義重大的飛躍。

• 使用狀態標籤作為功能引數

• MAC學習例子如Table1所述，交換機每個可能的埠需要一個表項。通過允許轉發動作接收在與資料包相關聯的元資料中提供的引數作為輸入（在我們的特殊例子中，state label 作為交換機埠互動），這可能僅用兩個表項實現同樣的程式：一個用於default state （在轉發資料庫中無法找到MAC 目的地），另外一個將MAC幀轉發到狀態標籤找到的交換機埠。不同的技術方法通過將頭部引數傳給actions在[15]中有所討論。

• 標籤上的簡單算術運算
  狀態和簡單算術操作的組合允許多個又去的擴充套件。例如，我們可以通過轉發IP分段來嚴格程式設計狀態機來阻止一些IP分段攻擊，只要它們按嚴格順序接收即可。一個基本的IP分段攻擊包含傳送第一小的分片（分片 offset=0，更多分片=1），然後傳送第二個IP碎片聲稱是一個大的最後一個小碎片（ 64 KB）資料包。這些可以通過“計算”輕鬆地檢測，從第一個IP分片的length，第二個分片期望的偏移量（offset），用它作為臨時的狀態標籤（或者作為一個數字值與分片狀態相關），旨在匹配到這樣的一個計算的偏移量欄位時，轉發資料包。我們強調，雖然顯然引人注目並且可能激發廣泛的擴充套件，但這樣的“算術計算”可能在高速時變得至關重要，並且需要更仔細地研究它們的可行性。

4.2 Enforcing conditions： “full” XFSM

流資料可以被認為是流相關的記憶暫存器。相似地，裝置級別樁體，比如當前輸出佇列的佔用，或者裝置級別的資料，比如通過給出的交換機埠進行大量的位元傳輸，可以解釋為值儲存在每一個fow暫存器。存在這樣的暫存器中的值將被用於下一步的條件，觸發相關事件的動作。

相當有趣的是，XFSM的定義在[10]中給出，提供了正式地模型，可以長生Mealy Machines(section 2引入)。這可以清晰地解釋作為記錄值的條件。實際上，在XFSM表中設定條件的能力對於配置無線MAC協議在[8]中被證明是重要的。

從[10]中得出，XFSM是一個抽象的7元組（S,I,O,T,D,U,F），狀態S和輸入事件I以及輸出動作O與第二節定義的相同。

• D是n維線性空間，D1....Dn，其中描述了n個暫存器的所有可能配置;
• F 是支援網路功能fi的集合:D->{TRUE,FALSE}，模擬了驗證支援狀態變換暫存器配置的條件。
• U 是一個 update functions Ui 的集合：D->D，在部署的暫存器上允許模擬變化。
• T:S×I×F->S×U×O是一個變化功能，將當前的state,event,和條件作為輸入，並且輸出next_state,相關的action，以及相關的暫存器更新。

我們認為在之前定義的條件下，可行的"暫存器"，"支援的功能"，和"更新功能"，這些概念是當前的技術可以做到的，因此在將來必定可以更深入的探索。實際上，條件可以在很多場景下進行優化，比如QoS，負載均衡，監控等。

5 CONCLUSIONS

本文目的在於在封閉平臺上，為每個流支援帶狀態處理方向提出前進的第一步，在我們的提案中，並且完全遵守OpenFlow策略，我們採取了非常務實的方法：我們在一般性上妥協，並且我們“限制”對標準OpenFlow匹配/操作規則的狀態處理。這允許我們顯然地立即產生部署的可程式設計概念，依賴於大部分在OpenFllow中提供的核心原語和資料結構。我們的抽象概括了OpenFlow匹配/動作規則的可擴充套件有限狀態機，它們在交換裝置內直接執行，從而解除安裝控制器，或許更有趣的是，需要線速的資料包 - 資料包操作，即不能委託給慢（邏輯）集中控制平面操作。

對比SDPA和OpenState感覺表設計很類似。。。