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

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

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

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

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

二、基于OPENFLOW V1.0介紹其基本架構

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

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

（一）流表

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

（二）安全通道

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

（三） OpenFlow協(xié)議

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

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

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

（一）OpenFlow交換機架構

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

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

（二）OpenFlow的流表結構

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

（三）OpenFlow多流表

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

（四）組表

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

（五）匹配域

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

（六）計數器變化

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

（七）指令

如前所述，新版本流表中的指令對應的是1.0版本中的動作，每個流表項中都會包含一組指令，當一個數據包與流表項匹配時，相應的指令就會被執(zhí)行。OpenFlow指令的執(zhí)行可能會導致數據包在多流表之間的轉移，也可能會指示交換機對數據包采取真正的動作（Action）。OpenFlow v1.0中定義了必備的轉發(fā)（Forward）、丟棄（Drop）等動作，以及可選的轉發(fā)、排隊（Enqueue）、修改域（Modify-Field）等動作。在此基礎上，后續(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，分別用于控制器向安全通道設置或查詢role及多控制器連接建立過程。

（十）多控制器

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

（十一）其他變化

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

四、OpenFlow目前存在的問題

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

（一）多控制器技術進展較慢

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

（二）版本兼容性問題

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

（三）流表問題

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

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

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

（五）標準化問題

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

五、總結

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

參考文獻（References）：

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

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