1. 程式人生 > >帶狀態論文粗讀(二)

帶狀態論文粗讀(二)

  • 文章名稱:Network Function Virtualization Enablement Within SDN Data Plane
  • 發表時間:2017
  • 期刊來源:IEEE INFOCOM 2017 - IEEE Conference on Computer Communications
  • 解決問題:

NFV藉助SDN架構來實現,有以下問題:

  • 一、流必須通過連線的NF實體,路由策略將變得不靈活,網路中將產生阻塞點,這是有害並且沒有必要的。
  • 二、控制器對於NFs沒有完全的視覺化,比如,有多少例項存在,例項放在哪,特定例項可以處理的流量。同樣的,NFs的控制器僅能得知有限的網路資訊。這樣的隔離系統結構導致NFs和網路利用不是最優的。
  • 三、NF趨向於改變資料包的狀態,這樣的改變對於控制器是不可見的。
  • 所做貢獻:
    • 一、提出NEWS(NFV Enablement Within SDN Data Plane),這個方法將網路狀態維護在中央控制器,同時有機地高效地可擴充套件地支援NF功能。NEWS擴充套件當前的SDN架構使NFs作為SDN的一部分。這意味著NF實體和控制協議與SDN是一體的。
  • 實驗對比:
    • 三個帶狀態防火牆攜帶小檔案(1k到9k)下端到端的效能服務。
    • 攜帶大檔案(10M)的三個帶狀態防火牆端到端的效能服務。
    • 對比NEWS和OVS的連線跟蹤實現。
    • 對比NEWS 伺服器選擇和HAProxy。
    • 評估可載入應用程式模組的開銷,以檢查載入應用程式的延遲,以及可載入應用程式是否會影響資料路徑效能。

  • 文章名稱:In-band Network Function Telemetry
  • 文章名稱:帶內網路功能遙測
  • 發表時間:2018
  • 期刊來源:SIGCOMM
  • 解決問題:
    • 一、在設計用於有效測量VNF執行時效能的綜合架構方面尚未做過任何工作,如何有效地監控NFs執行時效能?
  • 所做貢獻:
    • 一、設計了通用的架構,可以用於測量中間盒的效能而且不導致任何負載。
    • 二、為帶內遙測報告和postcard-like 報告提出了頭部格式。
    • 三、進行初步的評估,證明設計引起的微小負載。
  • 實驗對比:
    基於BESS實現了這個框架,在資料平面,對比不同模組處理資料包的速率。
    ------

  • 文章名稱:OpenNF: Enabling Innovation in Network Function Control
  • 發表時間:2014
  • 期刊來源:ACM SIGCOMM Computer Commuication Review
  • 解決問題:
    • 一、一些應用依賴於動態重新分配資料包進行處理(比如NF升級和資料包處理的動態重新分配),但是當應用(NF)過載,SDN會產生一個新的NF例項,遷移流進行平衡,平衡過程中,新的NF例項對流的處理由於沒有必要的NF內部state,可能導致無法檢測攻擊。雖然SDN可以通過等待當前的流處理完之後再遷移流,但這將導致過載減緩的延遲並且增加SLA懲罰的可能性。(論文中是用IDSs的例子進行說明的)
  • 所做貢獻:
    • 一、提出OenNF,一種控制層架構,提供高效、協調控制內部NF state和網路轉發state ,以允許根據NF例項快速安全,細粒度的流重新分配。
  • 不足之處:
    • 不明
  • 實驗對比:圍繞以下問題進行試驗

    • 即使在應用程式請求保證狀態或狀態操作時,是否可以有效地移動,複製和共享狀態? 應用程式從以不同粒度移動,複製或共享狀態的能力中看到了哪些好處?
    • NF如何高效的匯入匯出狀態,並且這些操作影響NF的效能嗎?NFs應該修改多少以支援南向API?
    • NF部署的規模是如何影響OpenNF的效率的?
    • 現有NF控制平面在多大程度上阻礙了滿足高水平目標組合的能力?
    • 現有NF控制平面在多大程度上阻礙了滿足高水平目標組合的能力?

  • 文章名稱:Fast Failure Detection and Recovery in SDN with Stateful Data Plane

  • 發表時間:2017
  • 期刊來源: COMMUNICATIONS SURVEYS AND TUTORIALS
  • 解決問題:
    • 一、當前SDN對於故障恢復的支援非常的弱,而傳統技術,例如 多協議標籤交換(MPLS)快速重路由通常被認為對於運營商網路更可靠。
    • 二、一些流量工程應用,比如故障恢復,挑戰著資料平面概念的限制,就拿代表性資料平面的技術來說,一些OpenFlow的缺陷不利於流實現高效的重新路由方案。OpenFlow配置和重配置轉發規則都是通過控制器進行執行,由於過載和延遲的要求,限制了對流的監視和控制。
    • 三、 對於故障情況,OpenFlow快速故障轉移組僅在檢測到故障的交換機提供本地備用路徑時才有效。遺憾的是,這種替代路徑可能不可用,在這種情況下,需要控制器的干預,其不能保證可達性,以便在網路中的另一點建立重新路由。
  • 所做貢獻:
    • 一、為帶狀態SDN資料平面提出了SPIDER,一種資料包處理的管道設計,允許直接通過交換機快速路徑,用完全可程式設計監測和重路由機制實現故障恢復策略。
  • 不足之處:
    • 一、安全
    • 二、誤報
    • 三、下行狀態同步
    • 四、管理許可權下發
  • 實驗對比:
    • 與BFD對比
    • 與MPLS Fast Reroute對比
    • 資料平面協調

  • 文章名稱:A Zero Flow Entry Expiration Timeout P4 Switch
  • 發表時間:2018
  • 期刊來源:SOSR
  • 解決問題:
    • 一、現在的OpenFlow基於流期滿的機制,這個機制依賴於固定的超時時間,在期滿之後交換機動態的將流表項從流表中移除。分配合適的超時時間值是在高效的流表利用和控制器過載之間的一個折中。
    • 二、為建立巨大可擴充套件網路,OpenFlow交換機不得不支援大量同時的流,這些流依賴於流表的表項。然而,由於TCAM(Ternary Content Addressable Memory)的限制,流表是有限的。控制器根據hard timeout 和 idle timeout新增和移除流表項。為了減少不必要的TCAM佔用,交換機在timeout期滿時進行移除對應的表項而不匹配流量。timeout太大導致流表利用率低,太小導致控制器過載(負荷)。
    • 三、解決方案,提出檢測TCP流的FIN和RST包,當檢測到時,移除流表中對應的表項。目的在於實現最佳的流表利用並且不需要控制器額外的工作負載。
  • 所做貢獻:
    • 一、實現了一個簡單的0流表項超時期滿方案,利用了潛在的基於P4的交換機檢測TCP流的FIN和RST資料包,並且移除表中對應的流表項,以減小不必要的流表佔用實現0流表項超時期滿方案,同時不導致控制器過載。
  • 不足之處:
    • 一 、無
  • 實驗對比:
    • 提出的方案與 idle timeout 和hard timeout對比流表使用量(TCAM的佔用)
    • 提出的方案與idle timeout 和hard timeout對比packet-in events