我對 OpenFlow APP 的看法
會寫這篇文章最主要的理由在於，我發現很多人（包含我自己的長官以及眾多的指導委員）對於 OpenFlow APP的看法和我不一樣（這是客氣的說法，其實是我認為他們的想法是錯誤的）。所以囉，我決定整理一下自己的想法並寫在這裡，希望有興趣的人可以一起參與討論（雖然沒多少人看吧），一方面可以檢討自己的想法；二方面可以宣傳自己的理念。在這邊要先說明一件事，SDN 是一個概念而非實作上的技術，因此幾乎所有的東西都可以套入 SDN 的概念，因此我在這裡不談 SDN APP，而只單單著重在 OpenFlow APP。
很多人都期待 OpenFlow 可以帶來新的網路應用服務，well ... 單單這件事就有點問題，OpenFlow 算是一種網路基礎建設的新型態架構，那麼我要問問，網路基礎建設所負責最主要的功能是什麼？答案很簡單，就是確保網路中的用戶端設備彼此之間能夠順利的連通，不管是 L2 switching 或是 L3 routing，那我們回到最基本的問題，請問目前的網路設備（我是指 L2/L3 的 switch 和 router）沒有辦法達成這一類的功能嗎？答案是，當然可以，不然我們現在用的網路是假的嗎？既然如此，那使用 OpenFlow 到底有什麼好處？使用 OpenFlow 最大的價值在於，我可以用新的想法來處理 L2 switching 和 L3 routing，藉由新的巧思，來達到比過去更好的網路效能或是使用率。有沒有例子？最簡單的一個例子就是 Broadcast 的封包處理概念，相關的細節可以參考下面的連結。
如何利用 OpenFlow 打造一個「無廣播」的網路環境
在這裡我可以斷言，如果使用了 OpenFlow 的架構卻在思考網路問題上停留在傳統網路的思維，下場是網路的效能只會變得比過去還差。
現在面對的問題是，很多人問說，我可以不可以用 OpenFlow 來做到一些網路應用服務功能，如 Firewall、IDS/IPS 等，然後說用 OpenFlow Switch 會比較便宜，他們的理由是硬體規統、功能統一化，而且不用被網路大廠所把持。事實上，我也看到有台灣廠商投入在這一塊的發展（如果他們問我的話，我一定會加以勸阻），為了不想惹麻煩上身，姑且保留公司名稱不提。我為什麼認為這種發展方向是有問題的呢？第一，你會期待網路基礎建設中每台設備都會有你說的這些網路應用功能嗎？不會！網路中這些功能應該有其他的設備負責，否則網路中所有的節點會貴的不像話，怎麼可能節省成本；第二，通常提出這種解決方案的廠商都會採用一種解決方案，那就是將封包導入 OpenFlow Controller，由 Controller 上的 OpenFlow APP 進行處理，這樣講的人完全沒有想到 Bottleneck 的問題，雖然他們會強辯說有 Multiple Controller 的技術，但當你這樣處理的時候，跟你直接買一台特殊設備然後將封包導過去有啥兩樣？所以我可以接受 Service Chain（或叫作 Forwarding Graph）的技術卻無法接受在 OpenFlow 上開發這一類型的 APP。
該下結論了，OpenFlow APP 應該著重在網路基礎建設傳送的處理機制，而不是那些和傳送無關的網路功能。
很多人都期待 OpenFlow 可以帶來新的網路應用服務，well ... 單單這件事就有點問題，OpenFlow 算是一種網路基礎建設的新型態架構，那麼我要問問，網路基礎建設所負責最主要的功能是什麼？答案很簡單，就是確保網路中的用戶端設備彼此之間能夠順利的連通，不管是 L2 switching 或是 L3 routing，那我們回到最基本的問題，請問目前的網路設備（我是指 L2/L3 的 switch 和 router）沒有辦法達成這一類的功能嗎？答案是，當然可以，不然我們現在用的網路是假的嗎？既然如此，那使用 OpenFlow 到底有什麼好處？使用 OpenFlow 最大的價值在於，我可以用新的想法來處理 L2 switching 和 L3 routing，藉由新的巧思，來達到比過去更好的網路效能或是使用率。有沒有例子？最簡單的一個例子就是 Broadcast 的封包處理概念，相關的細節可以參考下面的連結。
如何利用 OpenFlow 打造一個「無廣播」的網路環境
在這裡我可以斷言，如果使用了 OpenFlow 的架構卻在思考網路問題上停留在傳統網路的思維，下場是網路的效能只會變得比過去還差。
現在面對的問題是，很多人問說，我可以不可以用 OpenFlow 來做到一些網路應用服務功能，如 Firewall、IDS/IPS 等，然後說用 OpenFlow Switch 會比較便宜，他們的理由是硬體規統、功能統一化，而且不用被網路大廠所把持。事實上，我也看到有台灣廠商投入在這一塊的發展（如果他們問我的話，我一定會加以勸阻），為了不想惹麻煩上身，姑且保留公司名稱不提。我為什麼認為這種發展方向是有問題的呢？第一，你會期待網路基礎建設中每台設備都會有你說的這些網路應用功能嗎？不會！網路中這些功能應該有其他的設備負責，否則網路中所有的節點會貴的不像話，怎麼可能節省成本；第二，通常提出這種解決方案的廠商都會採用一種解決方案，那就是將封包導入 OpenFlow Controller，由 Controller 上的 OpenFlow APP 進行處理，這樣講的人完全沒有想到 Bottleneck 的問題，雖然他們會強辯說有 Multiple Controller 的技術，但當你這樣處理的時候，跟你直接買一台特殊設備然後將封包導過去有啥兩樣？所以我可以接受 Service Chain（或叫作 Forwarding Graph）的技術卻無法接受在 OpenFlow 上開發這一類型的 APP。
該下結論了，OpenFlow APP 應該著重在網路基礎建設傳送的處理機制，而不是那些和傳送無關的網路功能。
留言
張貼留言