淺談OpenFlow標準的演進

【摘 要】本文綜述了的OPENFLOW技術(shù)的研發(fā)背景，介紹了目前其標準的研究進展，分析了該技術(shù)目前存在的問題。

【關(guān)鍵詞】OpenFlow；SDN；流表；安全通道；控制器

Abstract：This paper summarizes the OpenFlow technology development background，the current research progress in its version， analyzed the problems of this technology.

Keywords： OpenFlow；SDN；Flow Table；Safety Channel；Controller

SDN（Software Defined Networking，軟件定義網(wǎng)絡(luò)）的概念從出現(xiàn)到現(xiàn)在已經(jīng)越來越受到各方面人士的關(guān)注，逐漸成為了當前網(wǎng)絡(luò)領(lǐng)域的熱點。但其實SDN的一些核心理念，比如分離網(wǎng)絡(luò)的控制平面與轉(zhuǎn)發(fā)平面、實現(xiàn)網(wǎng)絡(luò)狀態(tài)的集中控制等，早在好多年前就已經(jīng)被提出并研究，那為何直到最近才漸漸成為熱點呢？原因很簡單，有新的應(yīng)用被提出，而老的網(wǎng)絡(luò)技術(shù)無法滿足應(yīng)用需求，而云計算、大數(shù)據(jù)中心就是這些新應(yīng)用的典型代表。在一個現(xiàn)代化的數(shù)據(jù)中心，虛擬化技術(shù)已經(jīng)日漸成為主流，當客戶要求提交后，管理員可以簡單在資源池中劃分相應(yīng)的資源分配給客戶虛擬機，實現(xiàn)很多靈活的操作。但同時這也造成了對相應(yīng)網(wǎng)絡(luò)配置的巨大壓力。相對于服務(wù)器資源的靈活分配，傳統(tǒng)網(wǎng)絡(luò)是相對靜態(tài)的，無法滿足虛擬化技術(shù)對網(wǎng)絡(luò)快速、頻繁的實時配置、按需調(diào)用網(wǎng)絡(luò)資源的需求。由此，需求推動技術(shù)發(fā)展，SDN的概念才被大家廣泛的接受和認同。SDN具有北向和南向兩類接口技術(shù)，而OPENFLOW是標準化組織ONF目前唯一確定的控制器南向接口。南向接口技術(shù)能夠?qū)崿F(xiàn)控制器對底層交換機的轉(zhuǎn)發(fā)決策管理，并且實現(xiàn)不同網(wǎng)絡(luò)設(shè)備的虛擬透明。

本文第一節(jié)概述OPENFLOW技術(shù)的發(fā)展背景，第二節(jié)基于OPENFLOW V1.0介紹其基本架構(gòu)。第三節(jié)介紹后續(xù)版本中研究進展。第四節(jié)分析目前存在問題。第五節(jié)總結(jié)全文并探討未來的研究趨勢。

一、OPENFLOW技術(shù)的發(fā)展背景

2006年，斯坦福大學(xué)的Clean Slate研究組提出了一種新型網(wǎng)絡(luò)架構(gòu)，希望通過一個集中控制器，使網(wǎng)絡(luò)管理員能夠方便的實現(xiàn)對網(wǎng)絡(luò)流量的靈活控制，為核心網(wǎng)絡(luò)及應(yīng)用的多樣化提供了良好的平臺。受此啟發(fā)，該項目的Faculty Director Nick McKeown教授發(fā)現(xiàn)，如果將此架構(gòu)的設(shè)計進一步推進，將傳統(tǒng)網(wǎng)絡(luò)的控制平面和控制平面分離，通過集中式的控制器以標準化的接口對網(wǎng)絡(luò)設(shè)備進行邏輯上統(tǒng)一的管理，這樣將對目前傳統(tǒng)網(wǎng)絡(luò)的發(fā)展帶來新的發(fā)展甚至是革新。從2009年到2013年，已經(jīng)有數(shù)個版本的OpenFlow標準被陸續(xù)推出，如v1.0、v1.1、v1.2、v1.3、v1.4等，這些版本均在前一版本標準的基礎(chǔ)上進行了完善。其中OpenFlow1.0和1.3已可商用。

二、基于OPENFLOW V1.0介紹其基本架構(gòu)

2009年12月31日，OpenFlow標準的1.0版本被發(fā)布，它是該標準的第一個商業(yè)化版本，是后續(xù)版本的重要基礎(chǔ)。

OpenFlow v1.0中已經(jīng)充分體現(xiàn)了通過OpenFlow控制器、OpenFlow交換機以及OpenFlow協(xié)議搭建sdn的設(shè)計思想，如上圖：OpenFlow交換機有兩個關(guān)鍵組件：流表和安全通道，其中流表負責數(shù)據(jù)包的高速轉(zhuǎn)發(fā)和查詢，安全通道負責傳遞交換機和控制器之間的管理和控制信息，傳遞采用OpenFlow協(xié)議進行。因此OpenFlow v1.0的核心組成部分就是流表、安全通道及OpenFlow協(xié)議。

（一）流表

如前文所述，流表的作用是負責數(shù)據(jù)包的高速轉(zhuǎn)發(fā)和查詢，它可被視作是OpenFlow對網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)功能的一種集合。在它的表項目中整合了網(wǎng)絡(luò)中各個層次的網(wǎng)絡(luò)配置信息，在進行數(shù)據(jù)轉(zhuǎn)發(fā)時能夠使用相比傳統(tǒng)的交換機和路由器更豐富的規(guī)則。OpenFlow流表的每個流表項都是由3部分組成：用于數(shù)據(jù)包匹配的包頭域（header fields），用于統(tǒng)計匹配數(shù)據(jù)包個數(shù)的計數(shù)器（counters），用于展示匹配的數(shù)據(jù)包如何處理的動作（action）。

（二）安全通道

安全通道是負責傳遞交換機和控制器之間的管理和控制信息，信息傳遞的安全性是必須要考慮的內(nèi)容。目前在OpenFlow1.0中，規(guī)定安全通道需要采用TLS（transport layer security，安全傳輸層協(xié)議）技術(shù)，該技術(shù)用于在兩個通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。

（三） OpenFlow協(xié)議

OpenFlow協(xié)議是用來描述控制器和OpenFlow交換機之間數(shù)據(jù)傳輸?shù)慕涌跇藴?。OpenFlow協(xié)議支持三種消息類型：controller-to-switch、asynchronous和symmetric，而每一類消息又包含多個子消息類型。

三、OpenFlow后續(xù)版本的研究進展

網(wǎng)絡(luò)技術(shù)這幾年一直在飛速發(fā)展，OpenFlow技術(shù)也不例外，在其幾個后續(xù)版本中，對1.0版本做了很多的完善工作，接下來，我們簡單介紹下到目前為止在OpenFlow版本演進中的發(fā)展幾個關(guān)鍵變化和發(fā)展。

（一）OpenFlow交換機架構(gòu)

在OpenFlow1.1及之后的幾個版本中，OpenFlow交換機的架構(gòu)發(fā)生了變化，新的架構(gòu)示意圖如下：

如上圖所示，與原架構(gòu)相比，新架構(gòu)有了兩個主要變化：第一就是單一的流表變成了多流表。第二就是增加了組表。根據(jù)ONF發(fā)布的官方文檔，這兩個變化都是為了解決交換機的轉(zhuǎn)發(fā)性能而做的改進。

（二）OpenFlow的流表結(jié)構(gòu)

首先OpenFlow的流表結(jié)構(gòu)在1.1版本、1.2版本和1.3版本中發(fā)生了比較大的變化，目前在1.3版本中，匹配域、計數(shù)器、指令分別對應(yīng)1.0版本中流表的包頭域、計數(shù)器和動作，同時增加了優(yōu)先級、超時定時器、cookie三個部分，它們的作用如下：優(yōu)先級：流表項的匹配次序，決定有限匹配什么樣的flow entry。超時計時器：用于配置flow entry的實效時間。Cookie：由controller指定的非透明數(shù)值，controller可用此field來過濾流統(tǒng)計，流的修改以及流的刪除。

（三）OpenFlow多流表

由于1.0版本中流表的匹配字段長度達到了252位，而傳統(tǒng)的TCAM（ternary content addressable memory，三態(tài)內(nèi)容尋址存儲器）的匹配字段處理長度只有60到80位，無法承擔OpenFlow的開銷，因此OpenFlow必須面對如何減少流表尺寸的問題。為了解決該問題，1.1版本設(shè)計了多級流表來減少開銷，將流表的匹配過程分解成多個步驟，形成流水線的處理形式，減少總的流表記錄條數(shù)。1.3版本對多流表做了進一步的完善，類似于傳統(tǒng)網(wǎng)絡(luò)中ACL表末尾默認deny的配置，它在多流表每個表的最后添加了一個table-miss項目，一個table-miss的流表中的表項可以指定如何處理無法匹配的數(shù)據(jù)包：包括丟棄，傳遞到另一個表中，或憑借數(shù)據(jù)包中的信息通過控制通道發(fā)送到控制器。

（四）組表

組表包括若干組表項。這是另外的OpenFlow轉(zhuǎn)發(fā)方法，就是若干流表項指向一組。每個組表項由組編號確定，具體內(nèi)容包含：組編號：一個32位的無符號整數(shù)，唯一標識該組；組類型：規(guī)定了是否所有的動作桶中的指令都會被執(zhí)行；計數(shù)器：更新數(shù)據(jù)當報文被組表項處理時；動作桶：一系列有序的行動存儲段，其中的每個動作存儲段包含了一組要執(zhí)行的動作和相關(guān)參數(shù)

（五）匹配域

隨著OpenFlow版本的更新，匹配域的數(shù)量也越來越多，能夠滿足更多的轉(zhuǎn)發(fā)策略。匹配元組數(shù)量從最開始的12個變成了39個，增加了對MPLS、IPv6、PBB、TUNNEL-ID等特性的支持。

（六）計數(shù)器變化

計數(shù)器隨著OpenFlow標準的演進也進一步的完善了，具體如下：根據(jù)組表，增加了對每組、每個動作桶的相關(guān)統(tǒng)計；在1.3版本中增加了對數(shù)據(jù)流計量表的統(tǒng)計

（七）指令

如前所述，新版本流表中的指令對應(yīng)的是1.0版本中的動作，每個流表項中都會包含一組指令，當一個數(shù)據(jù)包與流表項匹配時，相應(yīng)的指令就會被執(zhí)行。OpenFlow指令的執(zhí)行可能會導(dǎo)致數(shù)據(jù)包在多流表之間的轉(zhuǎn)移，也可能會指示交換機對數(shù)據(jù)包采取真正的動作（Action）。OpenFlow v1.0中定義了必備的轉(zhuǎn)發(fā)（Forward）、丟棄（Drop）等動作，以及可選的轉(zhuǎn)發(fā)、排隊（Enqueue）、修改域（Modify-Field）等動作。在此基礎(chǔ)上，后續(xù)版本的OpenFlow對其進行了完善。

（八）安全通道

在OpenFlow1.0版本中要求安全通道使用TLS安全隧道。但是后續(xù)的版本都可以使用普通的TCP連接，不再強制要求安全隧道，但從安全的角度考慮，筆者還是建議使用TLS安全隧道。

（九）OpenFlow協(xié)議

OpenFlow協(xié)議的修改相對較少，大致包括將一些消息名字進行修改，如send-packet消息改名為packet-out消息等。還有則是在1.3版本中增加了兩個controller-to-switch消息：role-request和asynchronous-configuration，分別用于控制器向安全通道設(shè)置或查詢role及多控制器連接建立過程。

（十）多控制器

眾所周知，OpenFlow采用集中化的控制方式，那么為了避免出現(xiàn)核心節(jié)點故障而造成全網(wǎng)癱瘓的問題，就必須引入多核心的概念。為此，在1.2版本中提出了多控制器的工作模式，多個核心節(jié)點主從協(xié)同，互為備份，提高OpenFlow網(wǎng)絡(luò)的安全性。

（十一）其他變化

其實每個版本的OpenFlow在前版本的基礎(chǔ)上都做了大大小小各種完善和更新，有些變化非常具體且細小，限于篇幅所限，就不在這里過多贅述了，有興趣的讀者可以訪問https：//www.opennetworking.org/自行查閱官方文檔。

四、OpenFlow目前存在的問題

OpenFlow技術(shù)從出現(xiàn)到現(xiàn)在已經(jīng)經(jīng)過了5，6年的發(fā)展，雖然版本一直在不斷更新，但還是存在很多問題，簡單概括如下：

（一）多控制器技術(shù)進展較慢

為了保證OpenFlow網(wǎng)絡(luò)的穩(wěn)定性和安全性，多控制器技術(shù)是難以回避的問題，但目前OpenFlow的相關(guān)文檔對于多臺控制器之間如何通訊，如何協(xié)同工作，在具體實施過程中還是存在諸多問題需要進行深入研究。

（二）版本兼容性問題

通過前文，我們發(fā)現(xiàn)，OpenFlow技術(shù)在快速的發(fā)展過程中，每個版本的相對于之前的版本都有些重大的變動，這樣就造成了不同版本之間的兼容性問題。如何保證新版本對舊版本的向下兼容，是實際網(wǎng)絡(luò)運維時無法回避的問題。

（三）流表問題

通過前文，我們發(fā)現(xiàn)，在OpenFlow不同版本的演進中，流表的規(guī)模在逐步擴大，如它的匹配元組數(shù)量從最早的12項擴展到了39項，這樣會大大提高系統(tǒng)開銷，造成系統(tǒng)瓶頸。目前的多流表技術(shù)雖然從一定程度上緩解了該問題，但是也造成了流表的邏輯架構(gòu)越來越復(fù)雜，不利于未來的發(fā)展。

（四）轉(zhuǎn)發(fā)性能問題

傳統(tǒng)網(wǎng)絡(luò)交換機是采用基于硬件的ASIC芯片實現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)性能較高，但目前的OpenFlow交換機主要是基于軟件的軟交換，其轉(zhuǎn)發(fā)性能低于硬交換。在接入層的網(wǎng)絡(luò)中可能有大的問題，但在核心層網(wǎng)絡(luò)交換中就會出現(xiàn)問題。

（五）標準化問題

傳統(tǒng)交換機中有很多不產(chǎn)生直接轉(zhuǎn)發(fā)意義或動作方面的功能（如QOS），不同的廠商采用不同的芯片實現(xiàn)，而OpenFlow是很難對各個廠家通過標準而統(tǒng)一的，所以O(shè)penFlow標準化方面還有很多的工作要做。

五、總結(jié)

正如筆者在前文描述的那樣，OpenFlow僅僅是SDN的南向接口技術(shù)之一，兩者是不能劃等號的。從OpenFlow出現(xiàn)到目前短短的5，6年時間里，它在技術(shù)方面有了很大的完善，也出現(xiàn)了一些成功案例，如谷歌的B4網(wǎng)絡(luò)。這些都證明OpenFlow將是未來網(wǎng)絡(luò)發(fā)展的一個方向，尤其是在數(shù)據(jù)中心、核心網(wǎng)絡(luò)方面，OpenFlow技術(shù)正是目前資源虛擬化所需要的配套的技術(shù)。從另一個角度，我們也能發(fā)現(xiàn)，OpenFlow技術(shù)同樣面臨挑戰(zhàn)，作為一個新技術(shù)，它仍然不夠成熟，如流表的硬件開銷、多控制器選舉問題等。但我相信隨著SDN的進一步推廣，這些問題都能在工程項目中、在用戶越來越急迫的需求中，被一一克服，谷歌公司已經(jīng)為我們開了一個好頭。

參考文獻（References）：

[1]Open Networking Foundation. OpenFlow Switch Specification 1.1.0 Feb. 28， 2011

[2]彭陽 基于OpenFlow的網(wǎng)絡(luò)安全技術(shù)研究 物聯(lián)網(wǎng)技術(shù)，2013年/第九期三