OpenFlow協議超時機制簡介
一、背景
為支援大規模的SDN網路，OpenFlow交換機需要儲存大量的流表項來處理接收到的流量。然而，受限於交換機TCAM記憶體容量，流表所能儲存的流表項數目是有限的；同時，由於TCAM十分耗能且昂貴，為適應大規模流量場景而增加TCAM容量以容納更多的流表項是不現實的。
OpenFlow協議通過超時機制來緩解交換機流表容量有限的問題。該機制讓流表項只在一段時間內生效，並自動清理掉舊的、失效的流表項，騰出流表容量，以新增新的流表項。OpenFlow協議的流表項超時機制的核心是有效時間（timeout），使用者可以為每條流表項指定一個有效時間，在控制器向交換機下發流表項時設定。如果某條流表項存在的時間或未被匹配到的時間超過預設定的有效時間，OpenFlow交換機會主動移除該流表項。
有效時間又分為硬超時(hard timeout)和空閒超時（idle timeout）。
● 空閒超時（idle timeout），流表項的idle_timeout欄位非0。在空閒超時這段時間內，如果沒有任何資料報匹配到該流表項，則交換機會主動將該流表項從流表中移除。即流表項從交換機裝置移除的相對時間。
● 硬超時（hard timeout），流表項的hard_timeout欄位非0。當該流表項的存在時間超過了預設定的硬超時，流表項就會被交換機從流表中移除。即流表項從交換機移除的絕對時間。
● 在Ruckus生產的ICX 7250、ICX 7450、ICX 7750等系列裝置[1]中，當某條流表項兩者欄位為不同取值時，交換機的處理行為如表一所示。
表一[2]
二、現有超時機制存在的問題
問題1：控制器對流表項設定哪一型別的超時能更好地緩解交換機流表容量緊張的問題呢？ ● 硬超時 vs 空閒超時
因為硬超時不夠靈活，所以一般情況下控制器會為流表項設定空閒超時而非硬超時。例如，考慮以下場景，控制器為一條會被頻繁匹配的流表項設定硬超時，那麼該流表項新增到流表的時間超過硬超時後就會被移除；在該表項因超時被移除後，接下來本應匹配這條流表項的資料報到達交換機時就會觸發packet-in事件，增加控制器的負擔；相反，如果控制器設定的是空閒超時，那麼這條會被頻繁匹配的流表項就不會被移除。換句話說，硬超時無法區分流表項是否有效，導致交換機流表空間無法被有效利用。因此，控制器通常為流表項設定空閒超時，而非硬超時。
問題2：如何設定空閒超時的大小，以緩解交換機流表容量緊張？
● 過小的空閒超時 vs 過大的空閒超時
較小的空閒超時能儘快騰出流表空間以容納新的流表項，然而過小的空閒超時會導致額外的問題。
圖一：過小的空閒超時和過大的空閒超時[3]
如圖一所示，理想情況下，當流f1到達交換機時應該只觸發一次packet-in事件，即流f1的第一個資料報到達時觸發。
但是，當流f1的空閒有效時間T1小於相應的包到達的時間間隔I1時，控制器所下發的、匹配流f1的流表項總會在後續流f1的資料報到達之前刪除，由於沒有相應的流表項，流f1的每一個數據報到達時都會觸發 packet-in 事件，這些packet-in事件會消耗大量的控制器資源。
當流f2的空閒有效時間T2大於相應的包到達的時間間隔I2時，一條流表項失效之後會在流表中多停留 T2-I2的時間，造成不必要的冗餘和開銷。
因此，根據不同流量特性設定合適的有效時間是十分重要的。然而OpenFlow協議本身並沒有給出可行的解決方案來計算合適的有效時間。
三、現有超時機制緩解流表空間緊張問題效果不好的解決方案
當前，存在以下兩種緩解流表空間緊張的解決方案：
3.1通過啟發式演算法或基於歷史資訊的演算法計算得到針對不同的流量的流表項的有效時間
(1) Effective Switch Memory Management in OpenFlow Networks[4]
文章中提出一個控制器系統，該系統採用了一種自適應超時啟發式演算法（an adaptive timeout heuristic）來計算最合適的空閒超時，而不是將所有的有效時間都設定為相同的值。
(2) Intelligent Timeout Master: Dynamic Timeout for SDN-based Data Centers[3]
文章中提出在控制器中新增用來記錄上一次超時時間的cache模組，並且使用基於歷史資訊的演算法（history based algorithm）來預測得到合適的有效時間。同時利用流表負載作為來調節有效時間，避免流表空間溢位。
3.2提前刪除無效流表項，而非在超過有效時間之後才刪除
(1) FlowMaster: Early Eviction of Dead Flow on SDN
Switches[5]
文章中提出一個提前移除流表項的方法，該方法採用一種投機機制（a speculative mechanism），通過預測判斷某條流表項是否已經失效，並提前移除該流表項。
(2) A Zero Flow Entry Expiration Timeout P4 Switch[6]
文章中提出一種流表項移除技術，該技術是當交換機解析完TCP資料報的頭部之後檢視FIN或RST欄位的值，若FIN或RST位為1，則說明這個TCP連線即將關閉，交換機將會移除相應的流表項，並向控制器傳送一條訊息，該訊息包含了所刪除流表項的詳細資訊，包括被移除的原因、生存時間等。
四、總結
本文介紹OpenFlow協議中為提高流表空間利用率而採用的超時機制以及該機制存在的問題，並簡要介紹針對該問題的兩種解決方案。
原文釋出時間為：2018-10-31
本文作者：multhree
本文來自雲棲社群合作伙伴“SDNLAB”，瞭解相關資訊可以關注“SDNLAB”。