若是想要了解 SDN OpenFlow 以及　P4　請不要吝嗇點擊喜歡或是訂閱我喔！(訂閱又不收費XD)
未來有機會也可以跟大家分享我當網管的辛酸血淚史，可以讓人解決問題時可以參考我的文章。

話不多說，我們就累狗!!

What's link Monitor?
甚麼是流量監測?
A:流量監測就是 switch 與 switch 之間的 link 的 loading ， controller 需要時時刻刻去紀錄
該loading 才能計算出有效的 routing path，傳統 OpenFlow 的作法是 controller 下指令到 switch去要
該 switch 的流量資訊。

傳統 OpenFlow 的作法造成什麼問題，因為由 controller 下指令去跟 switch 拿資訊，那會造成 control plane以及 data plane 的大量溝通，這對於 controller來說，這是冗餘的。

若是採取 定期的 polling，則會有容易抓不準流量的問題，舉例來說: 這條流量有沒有被處理過?哪些流量是這次要被controller 所蒐集的? 這些都是常見的問題。那市面上有提出很多 polling 的方法，包含 polling single 、 polling some 、 polling all 。Polling 的週期則是根據你問題需要所訂。

今天要討論的是
Flow monitoring scheme design in SDN
這邊是採用 OpenFlow 的環境，使用到 polling some的技巧。

問題描述：
通常一個 flow 是通過許多的 switch ， 那 controller 對於這條 flow 在該 switch 是否需要做流量蒐集的動作？這個問題屬於 NP-hard 的問題。
那我們要如何去減低我們的 controller 的 overhead 並且有效且準確的分析出 網路的流量 是這篇的主旨。

使用到的方法 Critical Column First(CCF) 針對哪一個 flow 是重要的先進行 polling 的動作。
眾所皆知 controller 會擁有這個 topo 裡面所有 flows 的 ID， 根據 ID做二進位的編碼，我們可以使用到 Minimum Match Structure (MMS)， 找出符合這個格式且還沒有被處理的 flows，再進行 CCF 的演算法運算。

首先我們要針對我們的 Match Structure 做定義， 我們以下用 m 來表示

先去找尋 符合還沒被 covered 到的 flows 的 Match Structure 使用演算法

再來使用 CCF 找出那些 flows 需要被 polling 到 controller

在此付上我的 Reference，我將會以簡短白話的方式來講解 P4 這套語言，若是你/妳不嫌棄可以訂閱我的發文
每天就根據我自己了解的程度來做發文的動作，如果自己對於 P4也有興趣可以先來預習，那我們明天見！

Reference :
P4_turtorial
[(http://docs.google.com/presentation/d/1zliBqsS8IOD4nQUboRRmF_19poeLLDLadD5zLzrTkVc/edit#slide=id.g37fca2850e_6_1802)]
IEEE explore
https://ieeexplore.ieee.org/document/8761197/
Flow monitoring scheme design in SDN