《SDN技術及應用》課件-第3章

第3章SDN南向接口協(xié)議3.1OpenFlow協(xié)議概述

3.2OpenFlow交換機3.3OpenFlow端口

3.4OpenFlow流表與組表3.5OpenFlow通道

3.6OpenFlow消息3.7OFCONFIG協(xié)議3.8其他SDN南向接口協(xié)議3.9小結復習思考題

SDN控制器對網(wǎng)絡的控制主要通過南向接口協(xié)議實現(xiàn),包括鏈路發(fā)現(xiàn)、拓撲管理、策略制定、表項下發(fā)等,其中鏈路發(fā)現(xiàn)和拓撲管理主要是利用南向接口的上行通道對底層交換設備上報的信息進行統(tǒng)一監(jiān)控和統(tǒng)計,而策略制定和表項下發(fā)則是控制器利用南向接口的下行通道對網(wǎng)絡設備進行統(tǒng)一控制。

最知名的南向接口莫過于ONF倡導的OpenFlow協(xié)議。作為一個開放的協(xié)議,OpenFlow突破了傳統(tǒng)網(wǎng)絡設備廠商對設備能力接口的壁壘,經(jīng)過多年的發(fā)展,在業(yè)界的共同努力下,已經(jīng)日臻完善,能夠全面解決SDN中面臨的各種問題。OpenFlow在SDN領域中的重要地位不言而喻,甚至大家一度產(chǎn)生過OpenFlow就等同于SDN的誤解。實際上,OpenFlow只是基于開放協(xié)議的SDN中可使用的南向接口之一,還有很多的南向接口(如XMPP、PCEP等)被陸續(xù)應用和推廣。本章將對OpenFlow1.3版本進行深入解析,對其他南向接口協(xié)議也將進行介紹。

3.1OpenFlow協(xié)議概述

傳統(tǒng)網(wǎng)絡架構由單獨運行的、封閉的設備連接構成,每臺設備都有單獨的操作系統(tǒng),數(shù)據(jù)的轉發(fā)和控制都由交換機和路由器完成,這會造成網(wǎng)絡的管控細節(jié)不是特別到位。各種設備以及其相對孤立的操作系統(tǒng)在網(wǎng)絡中零散分布,也使網(wǎng)絡變得復雜且封閉。此外,由于設備異構,網(wǎng)絡管理的兼容性也很難做到極致。

如果所有的設備提供商公開他們提供的交換機和路由器的內(nèi)部編程接口API,或者提供他們產(chǎn)品的開放的、虛擬化的編程平臺,這樣,研究人員就可以在現(xiàn)有的網(wǎng)絡上進行二次開發(fā),部署創(chuàng)新的想法、協(xié)議或算法,網(wǎng)絡管理也將因此得到改進。但是,由于商業(yè)原因上的考慮,設備提供商不可能公開他們交換機、路由器的編程接口,且不同的設備商的產(chǎn)品內(nèi)部實現(xiàn)也相差很大,不可能提供一個統(tǒng)一的接口。

為了在高性能和低費用兩方面有一個折中,能快速大范圍地進行部署,實驗流量和商用業(yè)務流量共存同一個網(wǎng)絡中且互不干擾,滿足保護網(wǎng)絡平臺封閉性的要求,OpenFlow技術應運而生。

2008年4月,斯坦福大學的NickMcKeown教授在ACMCommunicationsReview上發(fā)表了論文《OpenFlow:enablinginnovationincampusnetworks》,首次詳細地論述了

OpenFlow的原理,明確地提出了OpenFlow的現(xiàn)實意義——在不改動網(wǎng)絡物理設備的前提下,在生產(chǎn)網(wǎng)絡上安全地進行新型網(wǎng)絡的實驗而不影響正常的業(yè)務流量。2009年發(fā)布了OenFlow協(xié)議的第一個正式版本1.0。OpenFlow1.0版本的優(yōu)勢是它可以與現(xiàn)有的商業(yè)交換機芯片兼容,通過在傳統(tǒng)交換機

上升級固件就可以支持OpenFlow1.0版本,因此,OpenFlow1.0是目前使用和支持最廣泛的協(xié)議版本。2011年2月,OpenF發(fā)布了OpenFlow1.1版本。

2011年3月,德國電信、Facebook、谷歌、微軟、NTT、Verizon和Yahoo聯(lián)合成立了ONF,同年3月,ONF接管了標準的后續(xù)開發(fā)和維護。ONF成立之后,OpenFlow的發(fā)展明顯加快。2011年,ONF批準了OpenFlow1.2版,并于2012年2月正式發(fā)布。ONF目前已經(jīng)推出了兩個可商用化的版本:OpenFlow1.0和OpenFlow1.3。2012年4月發(fā)布了OpenFlow1.3版本,成為長期支持的穩(wěn)定版本。1.3版中增加了Meter表,用于控制關聯(lián)流表的數(shù)據(jù)包的傳送速率,但控制方式目前還相對簡單。2013年最新發(fā)布的OpenFlow1.4版本仍然是基于1.3的改進版本,數(shù)據(jù)轉發(fā)層面沒有太大變化,主要是增加了一種流表同步機制。隨著ONF組織的成立,OpenFlow協(xié)議得到了更快的發(fā)

展,目前版本已經(jīng)發(fā)展到1.5版。

與當今IT界追捧的“軟硬件一體化”不同,SDN試圖用軟硬件分離的理念顛覆現(xiàn)有的網(wǎng)絡架構。OpenFlow作為新一代網(wǎng)絡的核心技術,在分離軟硬件方面肩負重任。OpenFlow的交換機以流表的方式進行數(shù)據(jù)的轉發(fā),FlowVisor負責對網(wǎng)絡進行虛擬化,控制器負責網(wǎng)絡控制,三者各司其職,分工明確而又相互配合,構成了OpenFlow的網(wǎng)絡架構。其中,控制器的引入是SDN架構與傳統(tǒng)網(wǎng)絡架構最大的不同。通過OpenFlow協(xié)議這個標準接口對交換機的流表進行控制,

控制器能夠實現(xiàn)對整個網(wǎng)絡的集中控制。在控制器上加載的應用允許用戶按照自身業(yè)務需求對網(wǎng)絡進行編程,實現(xiàn)網(wǎng)絡控制的靈活可編程性。

作為斯坦福大學網(wǎng)絡研究構想和實施的一部分,OpenFlow的最初目標是在校園網(wǎng)絡中創(chuàng)建一個可供實驗協(xié)議運行的環(huán)境用于研究和實驗。在這之前,大學必須親自創(chuàng)建他們自己的實驗平臺。從其最初的核心思想來看,OpenFlow完全可以代替商業(yè)交換機和路由器的二層和三層協(xié)議。

OpenFlow是一個開放的協(xié)議,它定義了控制器如何對控制平面進行配置和管理。通過使用OpenFlow,控制器可以管理數(shù)據(jù)包在網(wǎng)絡中的傳輸。在傳統(tǒng)網(wǎng)絡中,交換機和路由器的信息以不同的形式(路由表、MAC表等)進行儲存,需要在整個網(wǎng)絡或一組網(wǎng)絡中通過復雜的交換和路由協(xié)議進行計算才能得到。OpenFlow規(guī)范并集中了協(xié)議,通過創(chuàng)建和管理流信息表來代替其他所有的轉發(fā)表,數(shù)據(jù)平面就是根據(jù)這些流信息表生成的。

OpenFlow屬于SDN中的南向接口,如圖3－1所示,主要組件有OpenFlow控制器、OpenFlow交換機和OpenFlow協(xié)議,其特點有:

·控制面和數(shù)據(jù)面分離;

·采用標準化協(xié)議描述控制器與網(wǎng)絡組件代理之間的狀態(tài);

·通過可擴展的API來建立集中式視圖,并基于此實現(xiàn)網(wǎng)絡的可編程性。圖3－1OpenFlow架構

OpenFlow控制器類似于大腦,用于制定所有基于業(yè)務流的智能決策,并將這些決策發(fā)送給OpenFlow交換機。這些決策以指令的形式存在于流表中,典型的流信息決策的形式包括:添加、刪除及修改OpenFlow交換機中的流表。通過配置OpenFlow交換機,將所有未知數(shù)據(jù)包轉發(fā)給控制器,也可以在OpenFlow流表中下發(fā)其他一些指令。

OpenFlow交換機類似于現(xiàn)在網(wǎng)絡中使用的典型的交換機,但不包含智能軟件。OpenFlow交換機可以分為如下兩類:

(1)純OpenFlow交換機:這種交換機只支持OpenFlow協(xié)議。

(2)混合OpenFlow交換機:這種交換機同時支持傳統(tǒng)以太網(wǎng)協(xié)議和OpenFlow協(xié)議。

不考慮交換機的類型,任何OpenFlow交換機都有模塊用來負責與OpenFlow控制器進行SSH或TCP連接。

在OpenFlow交換機中,OpenFlow控制器管理硬件的流表,交換機主要用于數(shù)據(jù)平面上的轉發(fā)。控制通路由OpenFlow控制器管理,而數(shù)據(jù)通路則建立在由OpenFlow控制器編制的ASIC指令的基礎上。

OpenFlow協(xié)議的最終目標是實現(xiàn)對數(shù)據(jù)通路的程序指令,但是OpenFlow實現(xiàn)數(shù)據(jù)通路指令的方法卻有所不同。OpenFlow是客戶端服務器技術和各種網(wǎng)絡協(xié)議的融合。OpenFlow協(xié)議集目前被分為以下兩部分:

(1)線路協(xié)議。用于建立控制會話,定義一個用于交換流量變動信息和收集統(tǒng)計信息的消息結構以及交換機的基本結構(端口和表)。1.1版本增加了對多重表、存儲動作執(zhí)行和元數(shù)據(jù)傳輸(MetadataPassing)的支持,最終在交換機中創(chuàng)建用于處理控制流的邏輯管道。

(2)配置管理協(xié)議。采用基于NETCONFIG的模型(使用Yang數(shù)據(jù)模型)的OFCONFIG協(xié)議,為特定控制器分配物理交換機端口,定義高可靠性(主用/備用)和當控制器連接失敗時的行為。雖然OpenFlow可以使用OpenFlow命令/控制進行基本的配置操作,但它目前還不能啟動或者維護一個網(wǎng)絡組件。

3.2OpenFlow交換機

OpenFlow交換機包括一個或多個流表和一個組表,用于執(zhí)行分組查找和轉發(fā),以及一個與外部控制器相連的OpenFlow通道(如圖3－2所示)。該交換機利用OpenFlow通道與控制器進行通信,控制器通過OpenFlow協(xié)議來管理交換機。圖32OpenFlow交換機

控制器使用OpenFlow協(xié)議,可以主動或者被動(響應于數(shù)據(jù)包)地對流表中的表項進行添加、更新和刪除。交換機中的每個流表包含一組流表項,每個流表項包含匹配字段、計數(shù)器和一組指令,用來匹配數(shù)據(jù)包。

匹配從第一個流表開始,并可能會繼續(xù)匹配其他流表。流表項匹配數(shù)據(jù)包按照優(yōu)先級的順序,從每個表的第一個匹配項開始。如果找到一個匹配項,那么與流表項相關的指令就會去執(zhí)行;如果未找到匹配項,結果則取決于漏表的流表項配置。例如,數(shù)據(jù)包可通過OpenFlow信道被轉發(fā)到控制器、丟棄,或者可以繼續(xù)到下一個流表。

與流表項相關聯(lián)的指令包含動作或修改流水線處理的流程。指令中包含的動作描述了數(shù)據(jù)包轉發(fā)、數(shù)據(jù)包修改和組表處理。流水線處理指令允許數(shù)據(jù)包被發(fā)送到后面的表進行進一步的處理,并允許信息以元數(shù)據(jù)的形式在表之間進行通信。當與一個匹配的流表項相關聯(lián)的指令集沒有指向下一個表的時候,表的流水線處理將停止,這時該數(shù)據(jù)包通常會被修改和轉發(fā)。

流表項可能把數(shù)據(jù)包轉發(fā)到某個端口,這通常是一個物理端口,但也可能是由交換機定義的一個邏輯端口或通過本規(guī)范定義的一個保留端口。保留端口的處理與普通交換機的轉發(fā)處理相類似,可以指定通用的轉發(fā)行為,如發(fā)送到控制器、泛洪,或使用非OpenFlow的方法轉發(fā),而由交換機定義的邏輯端口可以是指定的鏈路聚合組、隧道或環(huán)回接口。

3.3OpenFlow端口

OpenFlow端口是OpenFlow進程和網(wǎng)絡之間傳遞數(shù)據(jù)包的網(wǎng)絡接口,OpenFlow交換機之間通過OpenFlow端口在邏輯上進行相互連接。OpenFlow交換機提供一定數(shù)量的OpenFlow端口給OpenFlow進程使用。OpenFlow端口組不等同于交換機硬件中提供的網(wǎng)絡端口組,因為有些硬件網(wǎng)絡接口可能被OpenFlow禁用,OpenFlow交換機可能定義額外的端口。

OpenFlow的數(shù)據(jù)包從入端口接收,經(jīng)過OpenFlow的流水線處理,可將它們轉發(fā)到一個輸出端口。入端口是數(shù)據(jù)包的屬性,它貫穿整個OpenFlow流水線,表明數(shù)據(jù)包是從哪個OpenFlow交換機的端口上接收的。匹配數(shù)據(jù)包的時候會用到入端口。OpenFlow流水線可以決定數(shù)據(jù)包通過輸出動作發(fā)送到輸出端口,還定義了數(shù)據(jù)包怎樣傳回到網(wǎng)絡中。

一個OpenFlow交換機的標準端口包括物理端口、邏輯端口、保留端口。標準端口可以用作入端口和出端口,它們可在組里使用,而且都有端口計數(shù)器。

(1)物理端口。OpenFlow的物理端口是為交換機定義的端口,對應于一個交換機的硬件接口。例如,以太網(wǎng)交換機上的物理端口與以太網(wǎng)接口一一對應。

在有些應用中,OpenFlow交換機可以實現(xiàn)交換機的硬件虛擬化。在這些情況下,一個OpenFlow物理端口可以代表一個與交換機硬件接口對應的虛擬接口。

(2)邏輯端口。OpenFlow的邏輯端口也是為交換機定義的端口,但并不直接對應一個交換機的硬件接口。邏輯端口是更高層次的抽象概念,可以是交換機中非OpenFlow方式的端口(如鏈路聚合組、隧道、環(huán)回接口等)。

邏輯端口可能包括數(shù)據(jù)包封裝,可以映射到不同的物理端口。這些邏輯端口的處理動作相對于OpenFlow交換機來說必須是透明的,而且這些端口必須能與OpenFlow進程互通。

物理端口和邏輯端口之間的唯一區(qū)別是:一個邏輯端口的數(shù)據(jù)包可能有一個叫做隧道ID的額外元數(shù)據(jù)字段與它相關聯(lián),而當一個邏輯端口上接收到的分組被發(fā)送到控制器時,其邏輯端口和底層的物理端口都要報告給控制器。

(3)保留端口。OpenFlow的保留端口由相應規(guī)范定義。它們指定通用的轉發(fā)動作,如發(fā)送到控制器、泛洪,或使用非OpenFlow的方法轉發(fā)。

3.4OpenFlow流表與組表

支持OpenFlow協(xié)議的交換機有兩種類型:純OpenFlow交換機和OpenFlow混合交換機。3.4.1流水線處理純OpenFlow交換機只支持OpenFlow操作,在這些交換機中的所有數(shù)據(jù)包都由OpenFlow流水線處理,否則不能被處理。

OpenFlow混合交換機支持OpenFlow的操作和普通的以太網(wǎng)交換操作,即傳統(tǒng)的L2以太網(wǎng)交換、VLAN隔離、L3路由(IPv4路由、IPv6路由)、ACL(訪問控制列表)和QoS處理。這種交換機必須提供一個非OpenFlow的分類機制,使流量路由到OpenFlow流水線或傳統(tǒng)流水線。例如,某個交換機可以使用VLAN標記或數(shù)據(jù)包的輸入端口來決定是否使用一個流水線或其他方式,或者它可引導所有數(shù)據(jù)包都到OpenFlow流水線進行處理。一個OpenFlow混合交換機也允許數(shù)據(jù)包通過NORMAL和FLOOD保留端口從OpenFlow流水線轉移到傳統(tǒng)流水線處理。

每個OpenFlow交換機的流水線包含多個流表,每個流表包含多個流表項。OpenFlow的流水線處理定義了數(shù)據(jù)包如何與那些流表進行交互(如圖3－3所示)。每個OpenFlow交換機至少需要一個流表,也可以有多個流表。只有單一流表的OpenFlow交換機是有效的,而且在這種情況下流水線處理進程可以大大簡化。

OpenFlow交換機的流表從0開始按順序編號。流水線處理總是從第一個流表開始,數(shù)據(jù)包首先與流表0的流表項匹配,后續(xù)流表的使用依賴于第一個流表的匹配結果。圖3－3流水線處理的數(shù)據(jù)包流

數(shù)據(jù)包被一個流表處理,即與流表中的流表項進行匹配,從而選擇一個流表項。如果匹配了流表項,則執(zhí)行在該流表項里的指令。這些指令可將數(shù)據(jù)包轉移到另一個流表,在此同樣的處理被重復執(zhí)行。一個流表項只能將數(shù)據(jù)包轉到大于自己表號的流表,換句話說,流水線處理只能前進而不能后退。顯然,流水線的最后一個表項可以不包括GOTO指令。如果匹配的流表項并沒有將數(shù)據(jù)包轉到另一個流表,流水線進程將在該表中停止。當流水線進程停止后,數(shù)據(jù)包被與之相關的動作集處理,這種處理通常是被轉發(fā)。

如果數(shù)據(jù)包在流表中沒有匹配到流表項,則這是一個漏表。漏表行為取決于表的配置。一個流表中的漏表項可以指定如何處理無法匹配的數(shù)據(jù)包:丟棄、傳遞到另一個表,或利用packet_in消息通過控制信道發(fā)送到控制器去。

OpenFlow流水線和各種OpenFlow操作用到的數(shù)據(jù)包類型應與規(guī)范定義的類型一致,除非目前的規(guī)范或OpenFlow配置有特殊的指定。例如,OpenFlow定義的以太頭部必須與IEEE規(guī)范一致,OpenFlow使用的TCP/IP頭部定義必須與RFC規(guī)范一致。另外,OpenFlow交換機的包重排必須與IEEE規(guī)范的要求一致,保證數(shù)據(jù)包能被相同的流表項、組表和計量帶處理。

3.4.2流表及刪除

1.流表

一個流表中包含多個流表項。流表項的組成如下所示:

每個流表項包含的內(nèi)容如下:

(1)匹配域:用于對數(shù)據(jù)包的匹配,包括入端口和數(shù)據(jù)包頭以及由前一個表指定的可選的元數(shù)據(jù)。

(2)優(yōu)先級:流表項的匹配次序。

(3)計數(shù)器:用于當數(shù)據(jù)包匹配時更新計數(shù)。

(4)指令:用于修改動作集或流水線處理。

(5)超時:計數(shù)值的最大時間或流在交換機中失效之前的剩余時間。

(6)cookie:由控制器選擇的不透明的數(shù)據(jù)值?？刂破骺捎脕磉^濾流統(tǒng)計數(shù)據(jù)、流修改和流刪除,但在處理數(shù)據(jù)包時不能使用。

流表項通過匹配字段和優(yōu)先級進行標識。在一個流表中匹配字段和優(yōu)先級共同標識唯一的流表項。使用通配符的域(所有域被省略)和優(yōu)先級等于0的流表項被稱為tablemiss流表項。

2.刪除

流表項可以通過兩種方式在流表中刪除:一種方式是通過控制器的請求;另一種方式是利用交換機的流超時機制。

交換機的流超時機制獨立于控制器,由交換機根據(jù)流表項的狀態(tài)和配置來運行。每個流表項具有一個和它相關的idle_timeout和hard_timeout值。如果hard_timeout值不為零,交換機必須注意流表項的老化時間,因為交換機可能刪除該流表項,無論有多少數(shù)據(jù)包與之匹配。

如果給定非零的idle_timeout值,交換機必須注意流的最后一個數(shù)據(jù)包到達的時間,后面可能需要刪除這個流表項,若在規(guī)定數(shù)秒內(nèi)沒有匹配數(shù)據(jù)包時,一個非零idle_timeout字段將引起流表項被刪除。交換機必須實現(xiàn)流表項超時就會從流表中刪除的功能。

控制器可以主動發(fā)送DELETE流表修改消息(OFPFC_DELETE或OFPFC_DELETE_STRICT),從流表中刪除流表項。

當流表項被刪除時,不管是由于控制器還是流表項超時引起的,交換機都必須檢查流表項的OFPFF_SEND_FLOW_REM標志。如果該標志被設置,該交換機必須將流刪除消息發(fā)送到控制器。每個流刪除消息中包含一個完整的流表項描述、清除的原因(超時或刪除)、在清除時流表項的持續(xù)時間、在清除時流的統(tǒng)計數(shù)據(jù)等。

3.4.3匹配

當OpenFlow交換機接收一個數(shù)據(jù)包時,就執(zhí)行圖3－4所示的功能。交換機對第一個流表進行查找,并基于流水線進程開始處理,也可能在其他流表中執(zhí)行表查找。圖3－4數(shù)據(jù)包流過OpenFlow交換機的流程圖

數(shù)據(jù)包匹配域是從數(shù)據(jù)包中提取的。用于表查找的數(shù)據(jù)包匹配域依賴于數(shù)據(jù)包的類型,也就是各種數(shù)據(jù)包的頭部域,如以太網(wǎng)源地址或IPv4目的地址,如表3－1所示。除了通過在數(shù)據(jù)包的包頭中進行匹配外,也可以通過入端口和元數(shù)據(jù)域進行匹配外。元數(shù)據(jù)可以用來在一個交換機的不同表里面?zhèn)鬟f信息。數(shù)據(jù)包匹配域表示數(shù)據(jù)包的當前狀態(tài),如果在前一個表中使用apply_actions改變了數(shù)據(jù)包的包頭,那么域的這些變化也會在當前數(shù)據(jù)包匹配域中反映出來。

如果數(shù)據(jù)包中用于查找的匹配域值匹配了流表項定義的域,就表示這個數(shù)據(jù)包匹配了此流表項。如果流表項字段的值是ANY(字段省略),它就可以匹配數(shù)據(jù)包頭部的所有可能的值。如果交換機支持對指定的匹配域進行任意的位掩碼,那么這些掩碼可以更精確地進行匹配。

當數(shù)據(jù)包與表進行匹配時,必須選擇匹配數(shù)據(jù)包的最高優(yōu)先級的表項,此時與所選流表項相關聯(lián)的計數(shù)器會被更新,指令集也會被執(zhí)行。如果多個匹配的流表項具有相同的最高優(yōu)先級,所選流表項則被確定為未定義表項。只有控制器的記錄器在流信息中沒有設置OFPFF_CHECK_OVERLAP位并且增加了重復的表項的時候,這種情況才可能出現(xiàn)。

如果交換機配置中包含OFPC_FRAG_REASM標志,則在流水線處理前IP碎片必須被重新組裝。

當交換機接收到一個格式不正確或損壞的數(shù)據(jù)包時,OpenFow1.3規(guī)范沒有定義預期的行為。

3.4.4漏表

每一個流表必須支持漏表流表項來處理表失配。漏表流表項指定如何處理在流表中與其他流表項未匹配的數(shù)據(jù)包。比如,把數(shù)據(jù)包發(fā)送給控制器、丟棄數(shù)據(jù)包或直接將包扔到后續(xù)的表。

漏表流表項也有它的匹配字段和優(yōu)先級,它通配所有匹配字段,并具有最低的優(yōu)先級(0)。漏表流表項的匹配可能不屬于正常范圍內(nèi)流表支持的匹配,例如,精確匹配表在其他流表項中可能不支持使用通配符,但漏表流表項必須支持通配符。

漏表流表項可能不具備正常流表項相同的能力,但漏表流表項必須支持利用CONTROLLER保留端口將數(shù)據(jù)包發(fā)送到控制器,以及使用clear_actions指令丟棄數(shù)據(jù)包。為了和早期版本的規(guī)范一致,在實現(xiàn)中鼓勵支持引導包給后續(xù)的流表。

漏表流表項的行為在許多方面像任何其他流表項,控制器可以在任何時候添加或刪除它,而且它可能會超時失效。漏表流表項利用它的匹配字段和優(yōu)先級匹配表中的數(shù)據(jù)包,它可以匹配流表中其他表項中不能匹配的數(shù)據(jù)。當數(shù)據(jù)包與漏表流表項匹配時,漏表流表項指令就會執(zhí)行。如果該漏表流表項直接將數(shù)據(jù)包通過CONTROLLER保留端口發(fā)送到控制器,那么packet_in消息的原因必須標識出漏表流表項。

如果該漏表流表項不存在,默認情況下流表項無法匹配的數(shù)據(jù)包將被放棄(丟棄)。使用OpenFlow配置協(xié)議配置交換機時,可以覆蓋此默認值,并指定其他行為。

3.4.5組表

一個組表包括若干組表項。組表項的組成如下所示:

一個組表項指向一個組的能力使得OpenFlow可以實現(xiàn)另外的轉發(fā)方法(例如選擇部分或所有)。

每個組表項由組編號標識,具體包含以下內(nèi)容:

(1)組編號:一個32位的無符號整數(shù)作為該組的唯一標識。

(2)組類型:用于確定組語義。

(3)計數(shù)器:當數(shù)據(jù)包被組處理時更新。

(4)動作桶:是有序的,包含了一組要執(zhí)行的動作和相關參數(shù)。

交換機不需要支持所有的組類型,只需要支持那些標記為“Required”的組類型,控制器可以查詢交換機支持哪些“Optional”的組類型。組類型包括:

(1)Required:all:執(zhí)行組中的所有桶。這個組用于多播或廣播的轉發(fā)。數(shù)據(jù)包為每個桶都有效地復制了一份,然后被每個桶處理。如果某個桶中明確地指導數(shù)據(jù)包發(fā)往入端口,那么這個復制的包將被丟棄。如果控制器記錄器希望數(shù)據(jù)包從入端口轉發(fā)出去,那么這個組必須包含一個額外的桶,這個桶包含到OFPP_IN_PORT保留端口的輸出動作。

(2)Optional:select:執(zhí)行組中的一個桶?；诮粨Q機的選擇算法(如利用用戶配置的元組/數(shù)組的哈希算法或簡單的循環(huán)算法),數(shù)據(jù)包被組中的一個桶處理。選擇算法的所有配置和狀態(tài)都在OpenFlow規(guī)定之外。選擇算法可以使用等負荷分配實現(xiàn),也可以根據(jù)桶權重進行。當組中桶所指定的端口出現(xiàn)故障時,交換機可在剩余部分(具有轉發(fā)到有效端口行為的限制)選擇桶,而不是丟棄數(shù)據(jù)包。此行為可能會減少數(shù)據(jù)包在鏈路或交換機的中斷。

(3)Required:indirect:執(zhí)行此組中定義的一個桶。這個組只支持單一的桶。允許多個組表項或者組指向一個共同的組編號,這樣可以使轉發(fā)更快、更高效地匯聚(如下一跳IP轉發(fā))。對于只有一個桶的所有組,組類型應該是相同的。

(4)Optional:fastfailover:執(zhí)行第一個活躍的桶。每一個動作桶與控制其活躍的一個指定端口或組相關。組定義的桶是有序的,首先選擇與活躍的端口或者組相關的第一個桶。這個組類型可以使交換機改變轉發(fā)而無需通知控制器。如果沒有活躍的桶,數(shù)據(jù)包將被丟棄,所以組類型必須實行活躍機制。

3.4.6計量表

為了實現(xiàn)數(shù)據(jù)流的統(tǒng)計,OpenFlow1.3增加了計量表。一個計量表包含若干計量表項來確定每個流的計量。每個流的計量可以使OpenFlow實現(xiàn)各種簡單的QoS操作(如限速),并且可以結合每個端口隊列來實現(xiàn)復雜的QoS構架(如DiffServ)。

計量表可以測試數(shù)據(jù)包分配的速率,并可以控制數(shù)據(jù)包的速率。計量表直接連接到流表項,而不是連接到端口的隊列。任意的流表項可以在它的指令集中定義一個計量表,計量表測量并控制和它有關的所有流表項的總速率。在同一個表中可以使用多個計量表,但必須使用專用的流表項分開設置方式。在連續(xù)的流表中,對于同樣的數(shù)據(jù)包集合,可以使用多個計量表。

計量表項的組成如下所示:

每個計量表項由其計量表標識符來區(qū)分,其中包含:

(1)計量器標識符:一個32位的無符號整數(shù)作為該計量表的唯一識別符。

(2)計量帶:是一個無序列表,每個計量帶指定帶速和處理數(shù)據(jù)包的方式。

(3)計數(shù)器:用于計量表處理數(shù)據(jù)包時進行更新計數(shù)。

每個計量表可能有一個或多個計量帶,計量帶的組成如下所示:

每個帶指定所用的速率和數(shù)據(jù)包的處理方式。單個計量帶以當前測量的計量速率處理數(shù)據(jù)包。當測量速率超過最高配置速率的時候,計量表就啟用計量帶。若當前的速率比任何指定的計量帶速率低,就沒有計量帶需要工作。

每個計量帶用速率來識別,包括:

(1)帶類型:定義了數(shù)據(jù)包的處理方式。

(2)速率:用于計量器選擇計量帶,也就是計量帶可以啟用的最低速率。

(3)計數(shù)器:用于當計量帶處理數(shù)據(jù)包時更新計數(shù)。

(4)類型的特定參數(shù):帶類型的可選參數(shù)。

在OpenFlow1.3規(guī)范里帶類型沒有“Required”,控制器可以查詢交換機支持的計量帶類型“Optional”。帶類型包括:

(1)Optional:drop:丟棄數(shù)據(jù)包?？梢杂脕矶x速率限制帶。

(2)Optional:dscpremark:增加數(shù)據(jù)包的IP頭部DSCP字段丟棄的優(yōu)先級?？捎糜诙x一個簡單的DiffServ策略。

3.4.7計數(shù)器

每一個流表、流表項、端口、隊列、組、組桶、計量表和計量帶都會修改計數(shù)器。OpenFlowcompliant計數(shù)器可以在軟件中實現(xiàn),也可以通過查詢硬件計數(shù)器獲取計數(shù),并進行有限范圍的修改。

計數(shù)器都是無符號的值,可以環(huán)回且沒有溢出指示。如果交換機里沒有指定值的計數(shù)器,則其值必須設置成字段的最大值(無符號數(shù)就是1)。

3.4.8指令

每個流表項中包含一組指令集,當一個數(shù)據(jù)包匹配表項時指令就會被執(zhí)行,這些指令可導致數(shù)據(jù)包、動作集合和/或流水線處理發(fā)生改變。

流表項所屬的指令集中每個類型的指令最多有一個,按照列表中指定的順序來執(zhí)行。實際上有如下的限定:meter指令在apply_actions指令前執(zhí)行,clear_actions指令在write_actions指令前執(zhí)行,goto_table最后執(zhí)行。

如果流表項不能執(zhí)行相關指令,交換機必須拒絕這個流表項。在這種情況下,交換機必須返回一個不支持的流錯誤信息。流表不一定支持每個匹配、每個指令或每個動作。

3.4.9動作集

動作集與每個數(shù)據(jù)包相關,默認情況下是空的。一個流表項可以使用write_action指令或者與特殊匹配有關的clear_action指令來修改動作集。動作集在表間被傳遞。當一個流表項的指令集沒有包含goto_table指令時,流水線處理就停止了,然后數(shù)據(jù)包的動作集執(zhí)行其動作。

動作集中每個類型的動作最多有一個。set_field動作用字段類型來標識,因此,動作集對每個字段類型的set_field動作最多有一個。當同一個類型需要多個動作時,例如,壓入多個MPLS標簽或彈出多個MPLS標簽時,應使用apply_actions指令。

動作集中所有的動作,不管它們以什么順序添加到動作集中,動作的順序均按照下列順序執(zhí)行。如果動作集包含組動作,那么組動作桶中的動作也按照下列順序執(zhí)行。當然,交換機也可以支持通過apply_actions指令任意修改動作執(zhí)行順序。動作執(zhí)行順序為:

(1)copyTTLinwards:向數(shù)據(jù)包內(nèi)復制TTL的動作。

(2)pop:從數(shù)據(jù)包彈出所有標記的動作。

(3)push_MPLS:向數(shù)據(jù)包壓入MPLS標記的動作。

(4)push_PBB:向數(shù)據(jù)包壓入PBB標記的動作。

(5)push_VLAN:向數(shù)據(jù)包壓入VLAN標記的動作。

(6)copyTTLoutwards:向數(shù)據(jù)包外復制TTL的動作。

(7)decrementTTL:將數(shù)據(jù)包的TTL字段減1。

(8)set:數(shù)據(jù)包使用所有的set_field動作。

(9)qos:使用所有的QoS動作,如對數(shù)據(jù)包排隊。

(10)group:如果指定了組動作,那么按順序執(zhí)行組動作桶里的動作。

(11)output:如果沒有指定組動作,數(shù)據(jù)包就會按照output動作中指定的端口轉發(fā)。

動作集中的output動作是最后執(zhí)行的。如果在一個動作集里組動作和輸出動作都存在,則組動作優(yōu)先;如果兩者均不存在,則數(shù)據(jù)包被丟棄。如果交換機支持的話,組的執(zhí)行將返回,組動作桶可指定另外一個組,在這種情況下,動作將在組配置中指定的所有組中執(zhí)行。

3.4.10動作列表

動作列表的含義與OpenFlow1.0規(guī)范中的相同,動作列表中的動作按照列表中的次序執(zhí)行,并立即作用到數(shù)據(jù)包。

列表中的動作從第一個動作開始按次序執(zhí)行,動作的結果是累積的,比如動作列表中有兩個pushVLAN動作,數(shù)據(jù)包就會被加上兩個VLAN頭部。如果動作列表有一個輸出動作,一個當前狀態(tài)下的包復制后就轉發(fā)給所需端口。如果列表中包含組的動作,則當前狀態(tài)下的包復制給相關組動作桶去處理。

一個apply_actions指令執(zhí)行完一個動作列表后,流水線繼續(xù)處理已修改的數(shù)據(jù)包。數(shù)據(jù)包的動作集本身在動作列表執(zhí)行的時候沒有改變。

3.4.11動作

交換機不要求支持所有類型的動作,只需支持下列標記為“RequiredAction”的動作?？刂破饕部刹樵兘粨Q機所支持的“OptionalAction”。動作類型包括:

(1)RequiredAction:output:數(shù)據(jù)包輸出到指定的OpenFlow端口。OpenFlow交換機必須支持轉發(fā)到物理端口、交換機定義的邏輯端口和所需的保留端口。

(2)OptionalAction:st_queue:設置數(shù)據(jù)包的隊列ID。當數(shù)據(jù)包使用輸出動作轉發(fā)到一個端口時,隊列ID決定了數(shù)據(jù)包在此端口所屬的隊列并轉發(fā)。轉發(fā)行為受隊列配置控制,并用來提供QoS支持。

(3)RequiredAction:drop:沒有明確的動作來表示丟棄。相反,那些動作集中沒有輸出動作的數(shù)據(jù)包應該被丟棄。當流水線處理時或執(zhí)行clear_actions指令后,空指令集或空指令動作桶會導致丟棄這個結果。

(4)RequiredAction:group:通過指定的組處理數(shù)據(jù)包,依靠組類型準確地解析。

(5)OptionalAction:push_tag/pop_tag:交換機具有壓入/彈出標記的能力。為了更好地和已有網(wǎng)絡結合,建議支持壓入/彈出VLAN標記的能力。

最新的壓入標記應插入到最外側的有效位置,作為最外側的標記。當壓入一個新VLAN標記時,應作為最外側的標記來插入,位于以太頭部后面、其他標記前面。同樣的,當壓入一個新MPLS標記時,也應作為最外側標記來插入,位于以太頭部后面、其他標記前面。

當多個壓入動作添加到數(shù)據(jù)包動作集時,按照動作集定義的規(guī)則依次作用到數(shù)據(jù)包,開始時是MPLS,接著是PBB,后面是VLAN。

(6)OptionalAction:set_field:不同的set_field動作由它們的字段類型來標識,并對數(shù)據(jù)包中頭部字段分別修改數(shù)值。當要求不太嚴格時,支持使用set_field動作進行重寫頭部各字段將非常有益于OpenFlow的實現(xiàn)。為了更好地和已有網(wǎng)絡結合,建議支持VLAN修改動作。set_field動作應一直作用到頭部可能的最外側(例如,“setVLANID”動作一直設置VLAN標記的最外側ID),除非該字段類型指定了其他值。

(7)OptionalAction:change_TTL:不同的change_TTL動作修改數(shù)據(jù)包中的IPv4TTL、IPv6HopLimit或MPLSTTL。

OpenFlow交換機檢查出攜帶無效IPTTL或MPLSTTL的數(shù)據(jù)包并拒絕接收。不是每個數(shù)據(jù)包都需要檢查TTL是否有效,但是在每次數(shù)據(jù)包完成TTL減1動作后應在最短時間內(nèi)檢查。交換機可能會改變其異步配置,利用輸入包消息通過控制信道發(fā)送攜帶無效TTL的數(shù)據(jù)包給控制器。

3.5OpenFlow通道

OpenFlow通道是每個交換機連接控制器的接口,通過這個接口,控制器配置和管理交換機,接收來自交換機的事件,將包從交換機轉發(fā)出去。盡管所有OpenFlow通道消息必須遵守OpenFlow協(xié)議格式,但在數(shù)據(jù)通路和OpenFlow通道之間,接口是具體實施者。OpenFlow通道通常使用TLS(安全傳輸協(xié)議)加密,但也可以直接在TCP上運行。

OpenFlow通道用來在控制器和交換機之間交換OpenFlow消息?？刂破鞴芾矶鄠€OpenFlow通道,每個通道連接到一個不同的交換機。一個交換機可能有一個通道連到控制器,或者有多個通道連接到不同的控制器。

控制器可以通過一個或者多個網(wǎng)絡來遠程管理交換機,這種方法是不在OpenFlow1.3規(guī)范之內(nèi)的,可能是在一個獨立的專用網(wǎng)絡,或者由交換機管理的網(wǎng)絡(帶內(nèi)控制器連接)中使用,唯一的要求就是應提供TCP/IP連接。

作為交換機和控制器之間的單一的網(wǎng)絡連接,OpenFlow通道使用TLS或TCP協(xié)議。另外,為了具有并行性,通道可以由多個網(wǎng)絡連接組成。

1.連接建立

交換機必須能夠與一個用戶可配置IP地址(否則是固定的)的控制器建立連接,連接使用用戶指定的一個端口或是默認端口。如果交換機與控制器的IP地址進行配置連接,那么交換機就啟動了一個標準的TLS或TCP連接,此時OpenFlow通道的流量不通過OpenFlow流水線。因此,交換機在流表檢查之前就必須區(qū)分輸入流量。

當OpenFlow連接初次建立之時,連接的每一方必須立即發(fā)送攜帶版本字段的OFPT_HELLO消息,版本指的是發(fā)送者支持的最高的OpenFlow協(xié)議版本。這個HELLO消息可能含有一些可選內(nèi)容來幫助建立連接。一旦接收到消息,接收方須立即計算出使用的協(xié)議版本。如果發(fā)送和接收的HELLO消息都包含OFPHET_VERSIONBITMAP的HELLO元素,并且這些位圖有一些共同的位設置,那雙方的協(xié)商版本就是最高版本。否則,協(xié)商版本是接收到的版本字段中較低的一個。

如果接收方支持協(xié)商版本,那么連接可行。否則,接收方必須回應一個OFPT_ERROR消息,此消息帶有OFPET_HELLO_FAILED的類型字段、OFPHFC_INCOMPATIBLE的字段以及一個解釋數(shù)據(jù)狀態(tài)的隨機ASCII字符串,然后終止連接。在交換機和控制器交換過OFPT_HELLO消息并且有共同的版本之后,連接就完成了,標準的OpenFlow消息就能夠在連接上交換,首先由控制器發(fā)送一個OFPT_FEATURES_REQUEST消息來取得交換機的數(shù)據(jù)路徑ID。

2.連接中斷

當交換機與所有的控制器中斷連接后,會導致echo請求超時,TLS握手超時,或者其他的連接失敗,交換機根據(jù)當前的運行狀態(tài)和配置,必須立即進入“失敗安全模式”或者“失敗獨立模式”。在“失敗安全模式”下,交換機行為唯一的改變就是丟棄發(fā)向控制器的包和消息。流表項在“失敗安全模式”下依據(jù)定時設置會繼續(xù)發(fā)生超時現(xiàn)象。在“失敗獨立模式”下,交換機使用OFPP_NORMAL保留端口處理所有的包,換句話說,就是交換機作為傳統(tǒng)以太網(wǎng)的交換機和路由器?！笆—毩⒛Ｊ健币话阒辉诨旌辖粨Q機上存在。

當再一次連接控制器時,已有的流表項將保留。如果有必要的話,控制器可刪除所有的流表項。

當交換機第一次啟動時,它會運行在“失敗安全模式”或者“失敗獨立模式”下,直到它成功地連接到控制器。啟動時流表項的默認設置內(nèi)容不在OpenFlow1.3協(xié)議之內(nèi)。

3.加密

交換機和控制器可通過TLS連接通信。當交換機啟動時,初始化TLS來連接控制器,TLS連接默認的TCP端口是6633。交換機和控制器通過交換由位置專一的密鑰簽名的證書來相互鑒權。每個交換機必須是用戶可配置的,并攜帶控制器鑒權的證書(控制器證書)和另一個向控制器鑒權的證書(交換機證書)。

交換機和控制器可選擇用普通TCP來互通,此TCP連接默認位于端口6633,由交換機發(fā)起并初始化。當使用默認的普通TCP連接時,推薦使用其他安全措施來防止竊聽、偽裝控制器以及其他OpenFlow通道上的攻擊。

4.多控制器

交換機可能與一個或多個控制器建立通信。多控制器模式的可靠性更高,如果一個控制器連接失敗,交換機還是能夠繼續(xù)運行在OpenFlow模式中?？刂破鞯那袚Q機制由控制器自己管理,這能使其從失敗中快速恢復或者使其負載平衡?？刂破魍ㄟ^現(xiàn)有規(guī)范之外的模式對交換機進行管理。多控制器的目的是幫助同步控制器的傳輸。多控制器的功能是基于控制器容錯和負載平衡,而不是基于OpenFlow協(xié)議之外的虛擬化。

當OpenFlow操作啟動時,交換機必須連接到所有與其配置相關的控制器,并且盡量保持與它們的連接。許多控制器發(fā)送controllertoswitch命令到交換機,有關此命令的回復消息或錯誤消息必須被返回,并通過相關的控制器連接。異步消息可能發(fā)送給多個控制器,為每一個OpenFlow通道復制一個消息,當控制器允許時就發(fā)出去。

控制器默認的身份是OFPCR_ROLE_EQUAL。以這種身份控制器能夠完全訪問交換機,這對其他控制器是一樣的。控制器默認接收交換機所有的異步消息(比如包輸入消息、流刪除)?？刂破靼l(fā)送controllertoswitch命令來改變交換機的狀態(tài)。交換機與眾控制器之間互不干涉,也不進行資源共享。

控制器可要求更換身份為OFPCR_ROLE_SLAVE,控制器也可更換身份為OFPCR_ROLE_MASTER,這個角色與OFPCR_ROLE_EQUAL相似,可完全訪問交換機,不同的是,控制器要確保它的角色是唯一的。

每個控制器會發(fā)送OFPT_ROLE_REQUEST消息給交換機,讓其知道自己的身份,交換機必須記住每個連接控制器的身份。只要在當前消息中提供generation_id,控制器可能隨時改變身份。

為了檢測主控制器切換時產(chǎn)生的無序消息,OFPT_ROLE_REQUEST消息包含了一個64位序列字段generation_id來標識主控身份。作為主控選舉機制的一部分,控制器(或者第三方)協(xié)調(diào)generation_id的分配。generation_id是單調(diào)遞增的計數(shù)器,每次當主控關系改變時,會分配一個新的(更大的)generation_id。例如,每當指定一個新的主控制器時,generation_id會增加。

當接收到OFPCR_ROLE_MASTER和OFPCR_ROLE_SLAVE身份的控制器發(fā)來的OFPT_ROLE_REQUEST消息時,交換機必須將其包含的generation_id消息與之前最大的generation_id比較,若較小的話,就丟棄。

5.輔助連接

默認情況下,OpenFlow通道是一個獨立的網(wǎng)絡連接。通道可能由一個主連接和多個輔助連接組成。輔助連接由交換機創(chuàng)建,有利于改善交換機的性能和充分利用交換機的并行性。

交換機到控制器的每個連接都由DatapathID和AuxiliaryID來確認。主連接必須設置AuxiliaryID為0,而輔助連接須有一個非零的AuxiliaryID和相同的DatapathID。

輔助連接必須使用和主連接相同的IP地址,但是可以使用不同的傳輸方式,如TLS、TCP、DTLS或者UDP,這取決于交換機的配置。輔助連接應該有和主連接相同的目標IP地址及相同的傳輸目的端口(除非交換機配置了指定值)?？刂破鞅仨氉R別帶有非零AuxiliaryID的連接,并綁定到具有

相同DatapathID的主連接。

3.6OpenFlow消息

3.6.1OpenFlow消息簡介OpenFlow協(xié)議支持三種消息:controllertoswitch消息、asynchronous(異步)消息和symmetric(對稱)消息,每個消息都有多個子消息類型。controllertoswitch消息由控制器發(fā)起,用來直接管理、檢查交換機的狀態(tài);異步消息由交換機發(fā)起,用于控制器更新網(wǎng)絡事件和交換機狀態(tài)變化;對稱消息由交換機或者控制器發(fā)起,無需請求。表3－2列舉了OpenFlow使用的消息類型。

3.6.2消息處理

OpenFlow協(xié)議提供可靠的消息傳遞和處理,但是不自動提供確認和保證消息的有序化處理。這一節(jié)所說的OpenFlow消息處理行為是在可靠傳輸?shù)闹?、輔連接上完成的。消息處理行為包括:

(1)MessageDelivery:消息可靠傳輸,除非OpenFlow通道完全失敗,控制器不了解交換機的任何狀態(tài)(如交換機可能已經(jīng)進入了“失敗獨立模式”)。

(2)MessageProcessing:交換機必須完全處理從控制器接收的每個消息,并可能生成一個回復。如果交換機不能完全處理來自控制器的消息,那么它必須返回一個error消息。

此外,交換機必須發(fā)送所有OpenFlow狀態(tài)改變時產(chǎn)生的異步消息,如流刪除、端口狀態(tài)或者packet_in消息,這樣控制器就可以與交換機的實際情況同步。

控制器可以自由忽略它們接收的消息,但是必須響應應答消息來防止交換機中斷連接。

(3)MessageOrdering:通過使用barrier消息來保證排序。在缺少屏障消息時,交換機可以任意重新排序消息來達到最佳性能。因此,交換機不應該依賴一個特定的處理順序。消息跨越一個屏障消息就不需要重新排序,只有在前面所有的消息都被處理后屏障消息才被處理。具體地說,即

·屏障消息前面的消息必須先被處理,包括發(fā)送任何產(chǎn)生的錯誤和回復;

·屏障必須被處理,而后發(fā)送一個響應;

·屏障消息后面的消息可繼續(xù)處理。

如果從控制器接收到的兩個消息是相互依賴的,那它們必須通過屏蔽消息來分離。

3.6.3消息事件

假設有一臺OpenFlow交換機和一臺OpenFlow控制器,在消息交換過程中有不同種類的事件產(chǎn)生,通過理解控制器和交換機之間的消息傳遞過程,可以清楚地認識OpenFlow的工作原理。

下面就對控制器和交換機之間主要的事件進行描述。

1.連接事件

連接事件的消息傳遞過程如圖3－5所示。圖3－5連接事件

工作過程描述如下:

最初在OpenFlow交換機與OpenFlow控制器之間通過TCP三次握手過程建立連接,使用的TCP端口號為6633。

TCP連接建立后,交換機和控制器就會互相發(fā)送hello報文。hello報文是使用OpenFlow協(xié)議的一個對稱的數(shù)據(jù)包。

當hello報文在交換機和控制器相互交換后,OpenFlow控制器與交換機之間就建立了連接?？刂破靼l(fā)向交換機的一條feature_request消息,目的是為了獲取交換機性能、功能以及一些系統(tǒng)參數(shù),交換機則通過feature_reply消息進行響應。

echo請求(echo_request)和echo響應(echo_reply)屬于OpenFlow中的對稱型報文,通常作為在OpenFlow交換機和OpenFlow控制器之間保持連接的消息來使用。

2.packet_in事件

packet_in事件的消息傳遞過程如圖3－6所示。

packet_in事件發(fā)生的前提是控制器和交換機之間經(jīng)過

TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。圖3－6packet_in事件

當OpenFlow交換機收到數(shù)據(jù)包后,若流表中與數(shù)據(jù)包沒有任何匹配的條目,packet_in事件就將被觸發(fā),交換機會將這個數(shù)據(jù)包封裝在OpenFlow協(xié)議報文中發(fā)送給控制器。

控制器收到packet_in報文后,提取OpenFlow數(shù)據(jù)包包頭。packet_in提供數(shù)據(jù)包的信息,得到packet_in信息后,控制器根據(jù)需要對原始數(shù)據(jù)包做出處理,如轉發(fā)或者丟棄。

3.packet_out事件

packet_out事件的消息傳遞過程如圖3－7所示。

packet_out事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當控制器發(fā)送數(shù)據(jù)包至交換機時,就會觸發(fā)packet_out事件,這一事件的觸發(fā)可以看做是控制器主動向交換機發(fā)送一些數(shù)據(jù)包的操作。圖3－7packet_out事件

4.端口狀態(tài)(port_status)事件

端口狀態(tài)事件的消息傳遞過程如圖38所示。

port_status事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當交換機端口狀態(tài)發(fā)生改變(端口up/down、增加或移除)或者端口配置發(fā)生改變時,就會觸發(fā)端口狀態(tài)(port_status)消息事件的發(fā)生。端口狀態(tài)(port_status)消息由OpenFlow交換機發(fā)往控制器,用于告知交換機端口狀態(tài)的改變。圖3－8port_status事件

5.get_configuration事件

get_configuration事件的消息傳遞過程如圖3－9所示。

get_configuration事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當控制器想要獲取交換機中的配置信息時,就會發(fā)送get_config_request消息,交換機發(fā)出get_config_reply消息作為反饋,該消息包含了交換機的所有配置信息。圖3－9get_configuration事件

6.flow_removed事件

flow_removed事件的消息傳遞過程如圖3－10所示。

flow_removed事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當控制器試圖刪除交換機中流表的時候,就會觸發(fā)該事件形成數(shù)據(jù)包。如果流的刪除是因為硬件超時(Hardtime-out)或者空閑超時(Idletime-out),也會觸發(fā)該事件。

flow_removed消息是否被發(fā)送至控制器取決于交換機中發(fā)送flow_removed消息的標識是否被設置。如果被設置,交換機就會發(fā)送flow_removed消息給控制器,用來通知流表的刪除。圖3－10flow_removed事件

7.statistics事件

statistics事件的消息傳遞過程如圖3－11所示。

statistics事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當控制器試圖從交換機處獲得不同類型的統(tǒng)計數(shù)據(jù)信息時,就會觸發(fā)該事件。統(tǒng)計數(shù)據(jù)包包括:單個流消息、聚合流消息、流表統(tǒng)計信息、端口統(tǒng)計信息、隊列統(tǒng)計信息等。圖3－11statistics事件

8.barrier事件

barrier事件的消息傳遞過程如圖3－12所示。

barrier事件發(fā)生的前提是控制器和交換機之間經(jīng)過TCP建立、發(fā)送hello報文、功能請求與響應環(huán)節(jié)后建立連接。

當控制器試圖了解其分配給OpenFlow交換機的任務是否完成或將在何時完成時,該事件將被觸發(fā)。

收到請求消息的交換機在完成控制器分配的任務后,會發(fā)送響應消息至控制器。圖3－12barrier事件

9.queue_get_configuration事件

queue_get_configuration事件的消息傳遞過程如圖3－13所示。

當控制器試圖問詢OpenFlow交換機端口的隊列配置時,就會觸發(fā)該事件。

隊列請求包括所請求隊列信息的端口號、隊列配置響應消息包括端口號和該端口的隊列配置信息。圖3－13queue_get_configuration事件

10.error事件

error事件的消息傳遞過程如圖3－14所示。

如果OpenFlow交換機不能讀出、支持或者執(zhí)行控制器發(fā)出的OpenFlow控制數(shù)據(jù)包,就會發(fā)送錯誤數(shù)據(jù)包至控制器,說明錯誤原因。數(shù)據(jù)包中包含說明錯誤信息的類型值或者是代碼值。圖3－14error事件

11.port_modify/flow_modification/set_configuration事件

port_modify/flow_modification/set_configuration事件的消息傳遞過程如圖3－15所示。

這幾個事件在控制器和交換機之間的交互情況類似,分別由下列條件觸發(fā):

(1)當控制器試圖修改端口配置標志時,觸發(fā)port_modify事件;

(2)當需要增添、修改或刪除交換機中流表的時候,觸發(fā)flow_modification事件;

(3)當控制器設置OpenFlow交換機的配置時,觸發(fā)set_configuration事件。圖3－15port_modify/flow_modification/set_configuration事件

3.7OFCONFIG協(xié)議

在ONF制定的SDN標準體系中,除了OpenFlow交換機規(guī)范之外,還有一個名為OFCONFIG(OpenFlowConfigurationandManagementProtocol)的協(xié)議也需要了解,它是OpenFlow的伙伴協(xié)議。OpenFlow定義的是SDN架構中的一種南向接口,提出了由控制器向OpenFlow交換機發(fā)送流表用來控制數(shù)據(jù)流在網(wǎng)絡中傳輸?shù)姆绞?側重點是數(shù)據(jù)轉發(fā)。OFCONFIG的職責是規(guī)定如何管理和配置這些網(wǎng)絡設備,針對的是網(wǎng)絡設備。

OFCONFIG提供一個開放接口用于遠程配置和控制OpenFlow交換機,對實時性的要求不高。具體地說,構建流表和確定數(shù)據(jù)流向等事項將由OpenFlow規(guī)范規(guī)定,而如何在控制器上進行OpenFlow交換機的配置、如何對交換機的各個端口進行enable/disable操作則由OFCONFIG協(xié)議完成。

OpenFlow交換機上所有參與數(shù)據(jù)轉發(fā)的軟硬件(如端口、隊列等)都可被視為網(wǎng)絡資源,而OFCONFIG的作用就是對這些資源進行管理。OFCONFIG與OpenFlow的關系如圖3－16所示。圖3－16OFCONFIG協(xié)議的位置

如圖3－16所示,OFCONFIG在OpenFlow架構上增加了一個被稱作OpenFlowConfigurationPoint的配置節(jié)點。這個節(jié)點既可以是控制器上的一個軟件進程,也可以是傳統(tǒng)的網(wǎng)管設備,它通過OFCONFIG協(xié)議對OpenFlow交換機進行管理,因此OFCONFIG協(xié)議也屬于一種南向接口。

OFCONFIG1.2版本中把OpenFlow交換機進行了抽象,叫做OpenFlow邏輯交換機,控制器通過OpenFlow協(xié)議與OpenFlow邏輯交換機進行通信和控制。一個或多個OpenFlow邏輯交換機運行的環(huán)境叫做OpenFlow使能交換機,一個OpenFlow使能交換機等效于一個物理的或虛擬的網(wǎng)絡單元,可運行一個或多個OpenFlow邏輯交換機。OFCONFIG協(xié)議動態(tài)分配OpenFlow使能交換機的相關資源給其所屬的邏輯交換機,每個邏輯交換機可控制所分配的端口、隊列等資源。圖3－17表示了OpenFlow業(yè)務配置點、OpenFlow使能交換機和邏輯交換機之間的連接。圖3－17OpenFlow使能交換機和邏輯交換機之間關系

3.7.1OFCONFIG1.2版本概述

OFCONFIG由ONF組織中的Configuration&Management工作組負責維護,于2014年發(fā)布1.2版本。OFCONFIG最主要的目標是在支持OpenFlow1.3版本邏輯交換機上實現(xiàn)以下功能配置:

(1)對OpenFlow數(shù)據(jù)平面分配一個或多個控制器;

(2)配置設備的隊列、端口等資源;

(3)支持遠程修改設備的端口狀態(tài)(如up/down);

(4)在控制器和邏輯交換機之間使用認證的配置來保證通信安全;

(5)發(fā)現(xiàn)OpenFlow邏輯交換機的能力;

(6)配置一組指定隧道類型,如IPinGRE、NVGRE、VxLAN。

對OpenFlow交換機的配置有OpenFlow協(xié)議和非OpenFlow協(xié)議兩種方式。OFCONFIG1.2版本中提出了具體的針對OpenFlow1.3版本的功能配置需求,如表3－3所示。

除了針對OpenFlow的功能配置外,OFCONFIG還根據(jù)自身的需要制定了運維需求和管理協(xié)議需求。其中在運維需求方面主要包括以下內(nèi)容:

(1)支持從多個配置點對OpenFlow使能交換機進行配置操作;

(2)支持一個配置點配置和管理多臺OpenFlow使能交換機;

(3)支持由多臺控制器控制同一臺邏輯交換機;

(4)支持對已分配給邏輯交換機的端口和隊列的配置;

(

5)支持發(fā)現(xiàn)邏輯交換機的能力;

(6)支持對邏輯交換機端口進行隧道配置,如IPinGRE、NVGRE、VxLAN。

在管理協(xié)議的需求方面,OFCONFIG則做出了更詳細的規(guī)定。例如,協(xié)議必須是安全的,能夠確保完整性和私密性,并提供雙向身份認證;協(xié)議需要支持由交換機或者配置點發(fā)起的連接,支持對部分交換機的配置;協(xié)議必須具有良好的擴展性,能夠提供協(xié)議能力報告等等。

3.7.2數(shù)據(jù)模型

OFCONFIG的數(shù)據(jù)模型由XML語言定義,OFCONFIG的數(shù)據(jù)模型主要由類和類屬性構成。

1.Yang模型

OFCONFIG1.2版本有一個伙伴是Yang模型,對實現(xiàn)OFCONFIG數(shù)據(jù)模型有所幫助。它吸收了XML語法規(guī)則作為標準約束,開發(fā)者使用Yang模型的NETCONF工具來減少開發(fā)時間,但要確保遵守所有的標準約束。

2.核心數(shù)據(jù)模型

OFCONFIG數(shù)據(jù)模型的核心是由OpenFlow配置點對OpenFlow交換機的資源進行配置。在OF－CONFIG1.2版本的模型中,交換機包含了不同類型的資源,如OpenFlow端口、OpenFlow隊列、外部認證、內(nèi)部認證和流表等。每個OpenFlow使能交換機中包含多個邏輯交換機的實例,每個邏輯交換機可以對應一組控制器,同時也可以擁有相應的資源。另外,數(shù)據(jù)模型中還包含一些標識符,這些標識符多數(shù)由XMLID標識。當前,這些ID都是一個字符串定義的唯一標識,以后有可能使用統(tǒng)一資源名稱(UniversalResourceNames,URN)作為標識。

OFCONFIG1.2版本對各個數(shù)據(jù)模型類進行了詳盡描述,具體細節(jié)在本書中不再做更多介紹,感興趣的讀者可以參考相關的協(xié)議規(guī)范。

3.8其他SDN南向接口協(xié)議

3.8.1XMPP可擴展消息處理現(xiàn)場協(xié)議(TheExtensibleMessagingandPresenceProtocol,XMPP)是基于可擴展標記語言(XML)的協(xié)議,它用于即時消息(IM)以及在線現(xiàn)場探測,用來促進服務器之間的準即時操作。這個協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何用戶發(fā)送即時消息,即使其操作系統(tǒng)和瀏覽器不同。

XMPP的前身是Jabber,它是一個開源形式組織產(chǎn)生的網(wǎng)絡即時通信協(xié)議。目前,國際互聯(lián)網(wǎng)工程任務組(IETF)已經(jīng)完成了XMPP的標準化工作。

XMPP是一個典型的C/S架構,而不是像大多數(shù)即時通信軟件一樣使用P2P(客戶端到客戶端)的架構。也就是說,在大多數(shù)情況下,當兩個客戶端進行通信時,他們的消息都是通過服務器傳遞的(也有例外,如在兩個客戶端傳輸文件時)。采用C/S架構主要是為了簡化客戶端,將大多數(shù)工作放在服務器端進行,這樣客戶端的工作就比較簡單,而且當增加功能時,多數(shù)是在服務器端進行。

XMPP服務的框架結構如圖3－18所示。XMPP中定義了三個角色,即XMPP客戶端、XMPP服務器、網(wǎng)關,通信能夠在這三者的任意兩個之間雙向發(fā)生。服務器同時承擔了客戶端信息記錄、連接管理和信息的路由功能。網(wǎng)關承擔著與異構即時通信系統(tǒng)的互聯(lián)互通,異構系統(tǒng)可以包括SMS(短信)、MSN、ICQ等。圖3－18XMPP的網(wǎng)絡結構

XMPP協(xié)議的傳輸是通過XML文件來實現(xiàn)的,與QQ的點對點通信不同,XMPP采用的是從客戶端到服務器、再到客戶端的方式來實現(xiàn)。一個簡單的XMPP通信流程如下:

(1)首先由客戶端連接到服務器,客戶端通過IO流發(fā)送一段XML文件,在文件中包含了自身的用戶名和密碼。

(2)服務器端接收到客戶端的XML文件,從中獲取用戶名和密碼進行驗證,如果驗證成功,服務器會發(fā)送一個XML文件給客戶端表明已經(jīng)登錄成功。

(3)登錄成功后,客戶端可以發(fā)送一個獲取好友名單的XML文件,服務器會將當前用戶的好友以XML文件傳到客戶端。

(4)客戶端選擇一個好友,向其發(fā)送信息(其實是向服務器發(fā)送,服務器收到后會轉發(fā)給對應的好友),好友收到。

1)XMPP客戶端

XMPP系統(tǒng)的一個設計標準是必須支持簡單的客戶端。事實上,XMPP系統(tǒng)架構對客戶端的限制很少,一個XMPP客戶端必須支持的功能有:

·通過TCP套接字與XMPP服務器進行通信;

·解析組織好的XML信息包;

·理解消息數(shù)據(jù)類型。

XMPP將復雜性從客戶端轉移到服務器端,這使得客戶端編程變得非常容易,更新系統(tǒng)功能也同樣變得容易。XMPP客戶端與服務端通過XML在TCP套接字的5222端口進行通信,而不需要客戶端之間直接進行通信。

2)XMPP服務器

XMPP服務器主要遵循以下兩個法則:

·監(jiān)聽客戶端連接,并直接與客戶端應用程序通信;

·與其他XMPP服務器通信。

XMPP開源服務器一般被設計成模塊,由各個不同的代碼包構成,這些代碼包分別處理Session管理、用戶和服務器之間的通信、服務器之間的通信、DNS(DomainNameSystem)轉換、存儲用戶的個人信息和朋友名單、保留用戶在下線時收到的信息、用戶注冊、用戶的身份和權限認證、根據(jù)用戶的要求過濾信息和系統(tǒng)記錄等。另外,服務器可以通過附加服務來進行擴展,如制定完整的安全策略、允許服務器組件的連接或客戶端選擇、設置通向其他消息系統(tǒng)的網(wǎng)關等。

3)XMPP網(wǎng)關

XMPP突出的特點是可以和其他即時通信系統(tǒng)交換信息和用戶在線狀況。由于協(xié)議不同,XMPP和其他系統(tǒng)交換信息必須通過協(xié)議的轉換來實現(xiàn)。目前,幾種主流即時通信協(xié)議都沒有公開,所以XMPP服務器本身并沒有實現(xiàn)和其他協(xié)議的轉換,但它的架構允許轉換的實現(xiàn)。在XMPP架構里,實現(xiàn)這個特殊功能的服務端叫做網(wǎng)關(gateway)。目前,XMPP實現(xiàn)了和AIM、ICQ、IRC