作者：潘叡 / 計算機及資訊網路中心資訊網路組研發替代役
可程式網路的概念與其後提出的軟體定義網路(Software-defined networking, SDN)大幅地降低了網路維護、管理與更新的困難度，使得網管人員能夠以高階(軟體)的方式取代傳統低階(硬體)的方式調整網路的決策。近來，Google與許多學術及商業機構已經或投入研發或更新系統為SDN架構，顯示它降低維護與營運成本的潛力。
軟體定義網路的概念與重要性
電腦網路建立在許多例如路由器(router)、交換器(switch)以及許多在使用者與使用者之間或使用者與伺服器之間的中間裝置上(如圖一)，而在這些數以千萬計的裝置內又使用了許多複雜的通訊協定(protocol)以維持網路的正常運作；網路管理人員的主要任務便是設置適當的回應規則來回應網路中發生的事件，以期網路效能最佳化。
圖一：複雜的網路架構(臺灣大學, 2011年)
在目前大部分的網路系統中，當網路的狀態有所改變而必須調整事件回應規則時，網管人員通常必須手動地把網路中高階(high-level)的事件回應規則利用專業知識與經驗轉換為低階(low-level)的指令才能夠達成，而這通常是個能夠使用的工具非常有限的工作。所以如同大多數人經歷過的，網路系統不出事則已，一旦出現了網路事件的不尋常狀況(unusual condition)或是程式的未處理的例外情形(unmanaged exception)，系統的維護與調校(tuning)便是個經常很具有挑戰性且容易出錯的過程。這主要是由於網管人員擁有的只有硬體供應商提供的裝置與功能性通常不甚完備足以處理所有狀況的操作介面，使得這些裝置對網管人員而言只是一些串連起來發揮功能的「黑盒子」(black box)，只要一天無法完全明白其運作機制，要對於所有網路狀況應對如流便是一件幾乎不可能的任務。
網管與研究人員所面對的另外一個極難克服的問題是所謂的「網路骨化」(Internet ossification)，所指的是由於網路的迅速普及以及大量網路裝置的使用。網路已經被大部分的人視為如交通運輸系統、電力系統等公共基礎建設的一部分，無論是硬體的抽換或是通訊協定的演進，只要存在使網路服務中斷的可能性就幾乎不可能被認可。這使得我們不得不對於網路架構做一些根本的改進，使其能夠更容易地適應新的演進。
軟體定義網路(software defined networking, SDN)這種可程式網路(programmable network)便是發想於此。它將轉送封包的硬體(forwarding hardware)與控制封包轉送的決策單元分離開來，而使決策單元能夠以程式控制，大幅簡化網路事件回應規則與行為模式的管理，使得硬體與通訊協定的更新更加容易。在軟體定義網路中，由中央軟體控制封包傳輸的機制，封包轉送的元件僅負責資料傳輸，而軟體可藉由開放的介面(open interface)加以程式，目前最具影響力的主流介面有ForCES與OpenFlow二種。
軟體定義網路的架構
在網路中資料的傳輸由使用者對使用者或使用者對伺服器與網路基礎建設的連結所構成，而在連結上封包的傳送由路由器與交換器達成。這些路由器與交換器通常是「封閉」的系統，僅由網管人員借由一些由硬體供應商提供的控制介面來操作；因此這些設備一旦開始服役，要更新這些無論是硬體還是通訊協定(例如將IPv4更新為IPv6)，在不影響使用者正常使用的前提之下，就成為一項困難的工作，更不用說是將硬體或通訊協定徹底置換這樣的大工程了。
如前所述，「網路骨化」的現象意味著封包傳輸或轉送的決策在網路元件上完成，也就是說在這樣的環境中，任何新的網路應用程式(例如防火牆、入侵偵測系統等)或是功能性(functionality)(例如繞徑機制)有所改變時，網管人員便必須直接就基礎建設(也就是低階)層面去改變整個系統架構，這是個時間與人力成本都高的任務，SDN便是被提出試著解決這個現象進而促進網路系統的演進。
如圖二所示，將控制邏輯(control logic)從封包轉送硬體(forwarding hardware)中分離出來使得新的應用程式或通訊協定更容易而直接地施行，而管理網路架構也變得像維護普通的程式一樣直覺，一般的網路參數調整在網路元件之間有了一個共同的控制介面以後更是一件輕而易舉的事。
圖二：SDN將控制邏輯從封包轉送硬體中分離出來
SDN將網路架構簡化為封包轉送硬體與網路決策控制器(decision-making network controller)二個單元，其中封包轉送硬體由
(1) 包含了條目(entry)以及對於活躍的流程(active flows)所必須採取的行動的流程表(flow table)；
(2) 以及能夠與控制器經由安全的通道溝通對於尚未在流程表上的新條目所必須採取行動的階層(layer)所構成。
圖三：SDN的一般化架構示意圖
1. 現存的SDN架構(圖三) ForCES與OpenFlow為前最具影響力的主流SDN介面，二者皆遵守SDN的基本精神，也就是將資料傳輸與控制單元分離以及使得兩者經由安全通道交換訊息；但二者在架構、封包轉送模式與通訊協定介面上有顯著的不同。
2. ForCES 由IETF ForCES(Forwarding and Control Element Separation) Working Group所提出，將網路元件內部重新定義為控制單元以及封包轉送單元分離的架構，但網路元件依然被視為一個個體；如此一來不但網路元件巨觀上與傳統網路元件極為類似，控制單元的決策亦可由第三方軟體來控制。
ForCES定義了一個稱為稱為Forwarding Element(FE)，實施ForCES通訊協定的邏輯個體(logic entity)，負責利用其下層的硬體處理封包；一個負責執行控制訊號函數的邏輯個體稱為Control Element(CE)，告訴FE如何處理封包；另外一個在FE上、被CE根據ForCES通訊協定所控制的函數區塊稱為Logical Function Block(LFB)，允許CE控制FE的組態。
3. OpenFlow
在OpenFlow的架構(圖四)中，封包轉送裝置稱為OpenFlow Switch，包含了一個或多個流程表，流程表由流程條目(flow entry)所組成，由它們決定屬於一個流程的封包應該如何處理與轉送。流程條目由
(1) 配對區域(match fields)：配對流入封包位於標頭區(header)的資訊。
(2) 計數器(counters)：蒐集特定流程的數據，例如接收封包數、封包大小、流程持續時間等。
(3) 採取的動作：封包符合配對的話應該採取處理封包的動作所組成。
圖四：OpenFlow架構示意圖
當OpenFlow Switch接收到一個封包時，它會解開封包的標頭區並根據流程表進行配對，若配對未通過則進行至下一個流程表，直到通過配對並決定應該採取的動作為止；如果該封包沒有通過任何一個流程表的配對，所採取的動作將由表上無名流程條目(table-miss flow entry)決定，這個條目尚包含的動作可能是丟棄封包、將封包經由OpenFlow的頻道(channel)傳給控制元件等。
參考資料
[1] Marc Mendonca, Bruno Astuto A. Nunes, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti, "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks," in submission 2013.
[2] Sakir Sezer, Barbara Fraser, David Lake, Jim Finnegan, Niel viljoen, Marc Miller, and Navneet Rao, " Are We Ready for SDN? Implementation Challenges for Software-Defined Networks," on IEEE Communications Magazine, issue 7, vol.51, p.36-43, jul. 2013.
[3] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner, "OpenFlow: Enabling Innovation in Campus Networks," on ACM SIGCOMM Computer Communication Review, vol.38, issue 2, pp.69-74, apr. 2008.
[4] Boris Koldehofe, Frank Durr, Muhammad Adnan Tariq, and Kurt Rothermel, "The power of software-defined networking: line rate content-based routing using OpenFlow," on Proceedings of the 7th Workshop on Middleware for Next Generation Internet Computing, article no. 3, 2012.
[5] http://www.openfoundry.org/tw/foss-news/8692-google-openflow-sdn
[6] http://www.xinguard.com/content.aspx?id=34
[7] http://www.infostruction.com/2013/07/02/gns3-labs-ccna-ccnp-ccie-material/
[8] http://www.ithome.com.tw/itadm/article.php?c=77353