SDN核心技術剖析和實戰指南---讀書筆記

第一章

SDN定義以下：

SDN是一種新興的基於軟件的網絡架構及技術，其最大的特色在於具備鬆耦合的控制平面與數據平面、支持集中化的網絡狀態控制、實現底層網絡設施對上層應用的透明。

SDN和NFV：

ONF（開發網絡基金會）從用戶角度定義SDN架構，ETSI（歐洲電信標準化協會）從網絡運營商角度出發提出的NFV（網絡功能虛擬化）架構。

ONF提出的SDN架構圖以下：

分爲三層：

應用層---包括各類不一樣的業務和應用；

控制層---負責處理數據平面資源的編排，維護網絡拓撲、狀態信息等；

基礎設施層---負責數據處理、轉發和狀態收集。

應用層與控制層經過北向接口API鏈接，控制層與基礎設施層經過南向接口OpenFlow等鏈接。

 

ETSI提出的NFV網路架構草案圖以下：

NFV相對於SDN的比較：

相同點：都實現了轉發層面與控制層面的分離，並在控制層面上提出了相似SDN中應用層的虛擬化架構的管理和編排層。

不一樣點：NFV在南向接口上，除了ONF倡導的OpenFlow協議以外，還包含了ForCES、PCE-P等以前已經在IETF等傳統網絡標準化組織中得到承認的接口；NFV將控制層面進行了更細緻的劃分，提出了端到端的網絡控制層。

 

OpenDaylight開源項目架構圖以下：

OpenDaylight開源項目的主要內容包括SDN控制器開發、南北向接口API的擴展、用於多個控制器關聯的東西向協議實現等。

 

SDN三大基本特徵：

1.集中控制：邏輯上集中的控制能支持得到網絡資源的全局信息並根據業務需求進行資源的全局調配和優化，例如流量工程、負載均衡等。同時，集中控制還使得整個網絡可在邏輯上被視做是一臺設備進行運行和維護，無須對物理設備進行現場配置，從而提高了網絡控制的便捷性。

2.開放接口：經過開放的南向和北向接口，可以實現應用和網路的無縫集成，使得應用能告知網絡如何運行才能更好地知足應用的需求，好比業務的帶寬、時延需求，計費對路由的影響等。另外，支持用戶基於開放接口自行開發網絡業務並調用資源，加快新業務的上線週期。

3.網絡虛擬化：經過南向接口的統一和開放，屏蔽了底層物理轉發設備的差別，實現了底層網絡對上層應用的透明化。邏輯網絡和物理網絡分離後，邏輯網絡能夠根據業務須要進行配置、遷移，再也不受具體設備物理位置的限制。同時，邏輯網絡還支持多租戶共享，支持租戶網絡的定製需求。

總之：SDN支持控制平面與轉發平面的分離，使得對網絡設備的集中控制成爲可能。以OpenFlow爲表明的南向接口的提出使得底層的轉發設備能夠被統一控制和管理，而其具體的物理實現將被透明化，從而實現設備的虛擬化。

 

三種典型的SDN實現方案以下：

1.基於專用接口（硬件和軟件緊耦合）：不改變傳統網絡的實現機制和工做方式，經過對網絡設備的操做系統進行升級改造，在網絡設備上開發出專用的API接口，管理人員可經過API接口實現網絡設備的統一配置管理和下發，改變原先須要一臺臺設備登陸配置的手工操做方式，同時這些接口也可供用戶開發網絡應用，實現網絡設備的可編程。

2.基於疊加網絡的方案（邏輯/疊加網絡）：以現行的IP網絡爲基礎，在其上創建疊加的邏輯網絡，屏蔽掉底層物理網絡差別，實現網絡資源的虛擬化，使得多個邏輯上彼此隔離的網絡分區，以及多種異構的虛擬網絡能夠在同一共享網路基礎設施上共存。主要思想可歸結爲解耦、獨立、控制三個方面以下：

　　1）解耦---將網絡的控制從網絡物理硬件中脫離出來，交給虛擬化的網絡層處理。這個虛擬化的網絡層加載在物理網絡之上，屏蔽掉底層的物理差別，在虛擬的空間重建整個網絡。物理網絡資源被泛化成網絡能力池

　　2）獨立---只要IP可達，相應的虛擬化網絡就能夠被部署，而無需對原有物理網絡架構作出任何改變

　　3）控制---疊加的邏輯網絡將以軟件便可編程的方式被統一控制

ps:基於疊加網絡的方案並非最近才被提出，VLAN就是典型的表明。在當前的基於疊加網絡的SDN實現領域，隧道技術被普遍應用，它能夠基於現行的IP網絡進行疊加部署，消除傳統二層網絡的限制。不少新型的協議都採用了隧道的原理進行網絡通訊，例如VXLAN、NVGRE等，它們均利用疊加在三層網路之上的虛擬網絡傳遞二層數據包，實現了能夠跨越三層物理網路哦進行通訊的二層邏輯網絡，突破了傳統二層網路中存在的物理位置受限、VLAN數量有限等障礙，同時還使得網絡支持服務的可移動性，大幅度下降管理的成本和運營的風險。

3.基於開放協議（硬件和軟件鬆耦合）

 

SDN核心技術體系：

OpenFlow解決了如何由控制層把SDN交換所需的用於和數據流作匹配的表項下發給轉發層設備的問題，同時ONF還提出OF-CONFIG協議，用於對SDN交換機進行遠程配置和管理。

雲管理平臺案例：OpenStack是能夠工做在SDN應用層的雲管理平臺，經過在其網絡資源管理組件中增長SDN管理插件，管理者和使用者能夠利用SDN北向解耦便捷地調用SDN控制器對外開放的網絡能力。當有云主機組網需求被髮出時，相關的網絡策略和配置能夠在OpenStack管理平臺的界面上集中制定並進而驅動SDN控制器統一地自動下發到相關的網絡設備上。所以，網絡資源能夠和服務器資源、存儲資源同樣，以抽象的資源能力的面貌統一呈現給業務應用開發者，開發者無需針對底層網路設備的差別耗費大量開銷從事額外的適配工做。

 

第二章

傳統網絡交換設備的典型架構示意圖以下：

在傳統的網絡交換設備中，轉發平面和控制平面是緊密耦合的，被集成實如今單獨的設備箱中。

轉發平面：主要用於對每個數據報文進行處理，使得它可以經過網絡交換設備。這些操做大多采用專門的硬件實現，主要包括轉發決策、背板和輸出鏈路調度等功能。

控制平面：主要用於對交換機的轉發表或路由器的路由表進行管理，同時負責網絡配置、系統管理等方面的操做，與轉發平面相比，運行頻率較低，能夠採用軟件實現。

 

SDN定義了標準的南向接口，用於對網絡基礎設施層的交換機、路由器等設備進行抽象建模，從而把每臺單獨的網路設備中的控制平面集中抽取到控制層中，實現底層轉發設備的」去智能化「。在SDN網絡中，底層負責轉發的設備只須要按照基本地保存的轉發決策機制進行高速數據轉發，而轉發決策中的距離策略都由控制層經過南向接口協議統一下發。

 

交換機的三個基本功能：

1.轉發決策---當數據報文到達SDN交換機後 ，數據報頭中攜帶的信息會在交換機轉發表，即流表中被查找，若是地址找到，對應的下一跳MAC地址就會被掛接在數據報文的最前端，同時IP數據報文的TTL域遞減1，並計算出一個新的校驗和

2.背板---數據報文經過背板轉發到SDN交換機對應的設備出端口，數據報文須要被加入到一個隊列中等待，若是當前的等待隊列中沒有足夠的空間存在，那麼數據報文可能會被丟棄或替換掉其餘數據報文，佔據別的數據報文此前在隊列中的位置

3.輸出鏈路調度---當數據報文到達SDN交換機的設備出端口後，它須要按照必定的順序進行等待，直到它被髮出到相應的交換機輸出鏈路上

 

交換機的三種交換模式：

1.直通---交換機僅對數據幀的前6個字節的信息進行接收和分析，並將數據幀的其他部分直接剪切到出端口上。直通模式具備最小的轉發延遲，可是它並不檢查數據的完整性，所以可能會把可以致使以太網衝突的」壞包「轉發出去，從而產生網絡可靠性問題

2.零碎片---交換機首先對數據幀的前64個字節進行接收和解析，再進行轉發。這種模式雖然可能形成極少許的」壞包「漏檢，但它對網絡的總體性能影響不大，又被稱爲」快速轉發「

3.存儲轉發---交換機須要對整個數據幀的內容進行接收和解析，並開展數據幀的完整性檢驗等操做，以有效地避免出現錯誤

 

SDN交換機的背板：

做用：是數據幀在交換機內部傳輸的通訊通道，攜帶有轉發決策信息及中繼管理信息。

兩種方式：共享總線機制和交叉開關矩陣機制。

 

SDN交換機的兩種緩衝機制：

1.端口緩衝：每一個交換機上的以太網端口有必定數量的高速內存用於緩衝數據幀的到來與轉發。該方法的問題是當端口的緩衝被使用殆盡時，其後續接收到的數據幀將被丟棄

2.共享內存：爲全部端口提供能夠同時訪問的共享內存空間用於端口緩衝。該方法將全部接收到的數據幀都保存在共享的內存池中，直到設備出端口準備將其轉發到網絡中。使用這種方法，交換機能動態分配共享內存，可根據端口流量的大小設定相應的緩衝規模

 

OpenFlow標準的名稱是OpenFlow Switch Specification，所以它自己是一份設備規範，其中規定了做爲SDN基礎設施層轉發設備的OpenFlow交換機的基本組件和功能要求，以及用於由遠程控制器對交換機進行控制的OpenFlow協議。

 

OpenFlow交換機的總體架構圖以下：

設計思想：OpenFlow交換機利用基於安全鏈接的OpenFlow協議與遠程控制器相通訊。流表是OpenFlow交換機的關鍵組件，負責數據包的告訴查詢和轉發。OpenFlow交換機還需經過一個安全通道與外部的控制器進行通訊，這個安全通道上傳輸的是OpenFlow協議，它將負責傳遞控制器和交換機之間的管理和控制信息。

 

OpenFlow流表項結構以下：

組成以下：用於數據報匹配的包頭域、用於統計匹配數據報的計數器、用於展現匹配的數據包如何處理的動做

ps：OpenFlow交換機的每一個流表項能夠對應有零至多個動做，若是沒有定義轉發動做，那麼與流表項包頭域匹配的數據包將被默認丟棄。若是流表項中出現有OpenFlow交換機不支持的參數值，交換機將向控制器返回相應的出錯信息。

 

OpenFlow流表動做列表以下（分爲必備動做和可選動做）：

ps：根據交換機的應用場景及其所可以支持的流表動做類型，OpenFlow交換機可被分爲兩類：OpenFlow專用交換機（只支持OpenFlow協議）、OpenFlow使能交換機（支持OpenFlow協議和傳統的二層/三層協議棧）

 

OpenFlow交換機中的數據包處理流程以下：

流程：當OpenFlow交換機接收到一個數據包時，將按照優先級一次匹配基本地保存的流表中的表項，並以發生具備最高優先級的匹配表項做爲匹配結果，並根據相應的動做對數據包進行操做。一旦匹配成功，對應的計數器將更新；而若是沒能找到匹配的表項，則將數據包轉發給控制器。

 

OpenFlow交換機中的數據包頭解析和匹配流程以下：

匹配流程：交換機中每個表項的匹配首先按照接收到數據包的物理端口對入端口進行匹配，而後按照二層數據包頭進行比較。若是數據包是VLAN包，則繼續查詢VLAN ID和PCP域。若是是ARP包，繼續查詢IP地址和目的IP地址。若是是IP包，則繼續查詢IP包頭的相關域；若是IP包是TCP/UDP包，則須要繼續查詢傳輸層端口；若是IP包是ICMP包，則須要繼續拆線呢ICMP包中的Type和Code。對於分段數據包的後續包，則將傳輸層端口設爲0後繼續查詢。

 

OpenFlow協議：

支持三種消息類型：controller-to-switch、asynchronous、symmetric。具體以下：

 

OpenFlow標準版本演進示意圖：

OpenFlow v1.1交換機結構以下：

相對於v1.0變化：交換機中的流表由單一的流表演變爲由流水線串聯而成的多流表；增長了組表。

 

OpenFlow v1.1和v1.2的流表結構以下：

OpenFlow v1.3的流表結構以下：

v1.3的流表結構解釋以下：

匹配域---對數據包匹配。包括入端口和數據包報頭，以及由前一個表指定的可選的元數據

優先級---流表項的匹配次序

計數器---更新匹配數據包的計數

指令---修改動做集或流水線處理

超時定時器---一個流的最長有效時間或最大空閒時間

Cookie---由控制器選擇的不透明數據值。控制器用來過濾流統計數據、流改變和流刪除

 

OpenFlow多流表流水線處理流程以下：

流程：當數據包進入交換機後，將從流表0開始一次 匹配，在後續處理中流表能夠按次序從小到大越級跳轉，但不能從某一流表向前跳轉至編號更小的流表。流表項將以優先級高低的順序與數據包進行匹配，當數據包成功匹配到一條流表項後，會首先更新該流表項對應的計數器記錄的統計數據（如發生成功匹配的數據包數量和總字節數），而後根據流表項中的指令進行相應操做。當數據包已經處於最後一個流表時，其對應的動做集合中的全部動做指令將被執行。

 

OpenFlow組表結構以下：

ps：利用組表，每一個數據流能夠被劃分到相應的組中，動做指令的執行能夠針對屬於同一個組標識符的全部數據包，這很是適合於實現廣播或多播，或者規定只執行某些特定的操做集。組類型規定了是否全部的動做桶中的指令都會被執行，其定義了以下四種類型：

1）全部：執行全部動做桶中的動做，可用於組播或廣播。

2）選擇：執行該組中的一個動做桶中的動做，可用於多路徑。

3）間接：執行該組的一個肯定的動做桶中的動做。

4）快速故障恢復：執行第一個具備有效活動端口的動做桶中的指令。

 

OpenFlow v1.1多流表匹配流程以下：

OpenFlow v1.1單個數據包匹配流程以下：

ps：若是數據包在流表中沒有匹配到流表項，將被稱爲一個流表失配的行爲。在v1.3以前的版本會對沒有匹配的數據包作相應處理，而v1.3則專門增建了table-miss流表項，即將沒有發生匹配也做爲一個匹配表項，由此致使的相應的多流表匹配流程以下：

OpenFlow v1.3多流表匹配流程以下：

 

OpenFlow交換機之間經過端口在邏輯上相互鏈接，其支持三種類型的端口：

1.物理端口---與OpenFlow交換機上的硬件接口一一對應。一個OpenFlow物理端口能夠對應交換機硬件接口的一個虛擬接口

2.邏輯端口---不直接對應要給交換機的硬件接口。可能支持報文封裝並被映射到不一樣的物理端口上，但其處理動做必須是透明的，即OpenFlow在處理上並不能夠區分邏輯端口和物理端口的差別

3.保留端口---用於特定的轉發動做，如發送到控制器、洪泛，或使用非OpenFlow的方法轉發，如使用傳統交換機的處理過程

 

SDN控制器東西橫向擴展需求：

多控制器。多控制器之間爲主從關係，能夠提供負載均衡能力和快速故障倒換。增長一類角色消息用於控制器之間協商主從關係。控制器的角色在缺省狀況下是EQUAL，在此狀態下的控制器能夠響應來自OpenFlow交換機發來的請求。控制器角色也能夠設爲SLAVE，在此狀態下控制器只負責監聽，不響應交換機發送的消息。第三種控制器角色是MASTER，這種狀態下的控制器行爲與EQUAL相似，惟一的差別在於系統中只能有一臺MASTER。所以，一旦網絡中有一臺控制器的角色轉變爲MASTER，那麼原先處於MASTER角色的控制器就必須轉爲SLAVE角色，避免角色衝突。

 

計量器的做用：

計量器能夠用於測試數據包的速率並對其實現速率控制。計量器能夠直接鏈接到流表項（而不是鏈接到端口的隊列）上。任意的流表項能夠在它的指令集中定義一個計量器，進而由計量器測量和控制與它相連的全部數據流的速率。同一個表中可使用多個計量器，但必須使用獨佔方式（即流表項之間沒有交集）。經過將多個計量器部署在先後相連的流表上，使其能被用在統一數據集合的轉發中。

 

OpenFlow提出了由控制器向OpenFlow交換機發送流表以控制數據流經過網絡所通過的路徑的方式，OF-CONFIG規定怎樣管理和配置這些網絡設備。

 

OpenFlow與OF-CONFIG的關係以下：

關係：OF-CONFIG的本質是提供一個開放接口用於遠程配置和控制OpenFlow交換機，可是它並不會影響到流表的內容和數據轉發行爲，對實時性也沒有過高的要求。諸如構建流表和肯定數據流走向等事項將有OpenFlow規範進行規定，而諸如如何在OpenFlow交換機上配置控制器IP地址、如何對交換機的各個端口進行enable/disable操做則由OF-CONFIG協議完成。OpenFlow交換機上全部參與數據轉發的軟硬件（例如端口、隊列）均可被視爲網絡資源，而OF-CONFIG的做用就是對這些資源進行管理。

 

OF-CONFIG的目標是在支持OpenFlow v1.2的網絡設備上實現如下基本功能配置：

1）配置一至多個控制器的IP地址

2）配置設備的隊列、端口等資源

3）支持遠程修改設備的端口狀態

 

OF-CONFIG v1.0中定義的OpenFlow v1.2功能配置需求：

 

OF-CONFIG數據模型：

模型：OF-CONFIG的數據模型主要由類和類屬性構成，其核心由OpenFlow配置點對OpenFlow交換機的資源進行配置。在OF-CONFIG v1.0中，定義了OpenFlow端口和OpenFlow隊列等兩類資源，它們隸屬於各個OpenFlow交換機。每一個OpenFlow交換機中包含多個邏輯交換機的實例，每一個邏輯交換機能夠對應一組控制器，同時也可擁有相應的資源。

 

OVS（Open vSwitch）定義：

OVS是一款基於軟件實現的開源虛擬交換機。在虛擬交換機的實現中，其連孤單分別鏈接這物理網卡和多塊虛擬網卡，同時虛擬交換機內部會維護一張映射表，根據MAC地址尋找對應的虛擬機鏈路進而完成數據轉發。

 

虛擬交換機工做原理以下：

 工做原理：當數據包從虛擬機發出後，首先將經過虛擬機上配置的虛擬網卡。虛擬網卡會根據一些既定的規則決定如何處理數據包，例如放行、組個或修改。數據包在被網卡放行後將轉發至虛擬交換機，與其餘虛擬交換機不一樣的是，提供了OpenFlow支持能力的OVS將根據自身保存的流表對數據包進行匹配，若是匹配成功則按照相應的指令進行數據包操做，若是匹配未成功則將數據包發給控制器等待相關流表的指定和下發。當數據包須要經過物理網卡轉發時，它將會被髮送到與虛擬交換機相連的物理網卡上，進而被轉發給外部網絡設備。

 

OVS核心架構圖以下：

OVS核心架構：OpenFlow協議、數據轉發通路。OVS的數據轉發通路主要用於執行數據交換工做，即負責從設備入端口接收數據包並依據流表信息對其進行管理，例如將其轉發至出端口、丟棄或進行數據包修改。而OVS的OpenFlow協議支持則用於實現交換策略，即經過增長、刪除、修改流表項的方式告訴數據轉發通路針對不一樣的數據流採用不一樣的動做。另外，OVS提供了兩種數據轉發通路：工做在用戶態的慢速通道；利用專門的Linux內核模塊的快速通道。

 

OVS核心組件及其關聯關係：

用戶空間：擁有多個組件，主要負責用於實現數據交換和OpenFlow流表功能，是OVS的核心

核心組件：OVS提供一些工具用於交換機管理、數據庫搭建，以及和內核組件交互。

ovs-vswitchd：實現OpenFlow交換機的核心功能，並經過netlink協議直接和OVS的內核模塊進行通訊。交換機運行過程當中，ovs-vswitchd還會將交換機的配置、數據流信息及其變化保存到數據ovsdb中，由於這個數據庫由ovsdb-server直接管理，因此ovs-vswitchd須要和ovsdb-server經過UNIX socket機制進行通訊以得到或這保存配置信息。數據庫ovsdb的存在，使得OVS交換機的配置能被持久化存儲，即使設備被重啓後相關的OVS配置仍舊能存在。

ovs-vsctl：是一個用於交換機管理的基本工具，它須要直接和ovs-vswitchd通訊，能支持不少管理操做，用戶能夠登陸到交換機部署的服務器上經過ovs-vsctl管理OVS交換機。同時，ovs-appctl組件也是一個管理工具，經過發送一些內部命令給ovs-vswitchd組件以改變其配置。另外，在一些狀況下，用戶可能會須要自行管理運行在內核中的數據通路，那麼也能夠經過調用ovs-dpctl驅使ovs-vswitchd在不依賴於數據庫的狀況下去管理內核空間中的數據通路。

當用戶須要和ovsdb-server通訊以進行一些數據庫操做時，能夠經過運行ovsdb-client組件訪問ovsdb-server，或者直接使用ovsdb-tool而不經ovsdb-server就對ovsdb數據庫進行操做。

ovs-ofctl：在OVS實現中，OpenFlow是用於管理交換機流表的協議。經過使用ovs-ofctl，用戶可使用OpenFlow去鏈接交換機並在遠程開展監控和管理。

 

第三章

控制器的南向網絡控制技術：

包括經過南向接口協議進行鏈路發現、拓撲管理、策略制定、表項下發等。其中鏈路發現和拓撲管理主要是控制器利用南向接口的上行通道對底層交換設備上報信息進行統一監控和統計的技術，而策略制定和表項下發則是控制器利用南向接口的下行通道對網絡設備實施統一控制的技術。

 

鏈路發現技術：

SDN控制器主要使用LLDP（鏈路層發現協議）做爲鏈路發現協議，該協議提供了一種標準的鏈路發現方式，能夠將本端設備的主要能力、管理地址、設備標識、接口標識等信息組織成不一樣的TLV，並封裝在LLDPDU（鏈路層發現協議數據單元）中發佈給與本身直連的了鄰居，鄰居收到這些信息後將其以標準MIB（管理信息庫）的形式保存起來，以供網絡管理系統查詢及判斷鏈路的通訊情況。

SDN控制器的鏈路發現過程以下：

發現過程：控制器在執行鏈路發現過程時，會首先經過一個Packet_out消息向全部與之相鏈接的交換機發送LLDP數據包，該消息命令交換機將LLDP數據包發送給全部端口，一旦交換機收到Packet_out消息，它就會把LLDP數據包經過其全部的端口發送給其餘與之鏈接的設備。若是其鄰居交換機是一臺OpenFlow交換機，那麼該交換機將執行相應的流表查找操做。由於交換機中並無專門的流表項用於處理LLDP消息，因此它將經過一個Packet_in消息將數據包發送給控制器。而控制器在接收到Packet_in消息後，會對數據包進行分析並在其保存的鏈路發現表中建立兩臺交換機之間的額連接記錄。網絡中其餘交換機也都將採用與上述過程相同的方式向控制器發送Packet_in消息，所以控制器將可以建立出完備的網絡拓撲視圖。

判斷網絡中是否存在非OpenFlow域：

基於LLDP消息的方法只能對與控制器直連的OpenFlow交換機進行鏈路發現，若是網絡中還存在其餘的非OpenFlow域，即兩臺OpenFlow交換機之間可能會經過其餘的一臺或多臺非OpenFlow交換機相連。在這種狀況下，控制器會首先發送Packet_out消息給與之相連的OpenFlow交換機，但同時控制器會要求交換機發出廣播包，廣播包將被髮往除交換機與控制器相連的端口以外的其餘全部端口。廣播包從OpenFlow交換機發出後，若是網絡中存在非OpenFlow域，那麼廣播包將從這個網絡域的一端進入並穿越，進而到達與該非OpenFlow域鏈接的其餘OpenFlow交換機。由於在接收到廣播包的OpenFlow交換機中並無相應的流表項可供廣播包匹配，因此該廣播包將會被上傳給控制器，從而達到告知控制器在網絡中存在有非OpenFlow域的目的。若是控制器並無收到上傳的廣播包，那麼就能夠判斷出整個網絡都由OpenFlow交換機構成。

 

拓撲管理技術的做用：

1.隨時監控和採集網絡中SDN交換機的信息，及時反饋網絡的設備工做狀態和鏈路鏈接狀態。爲了實現這一目標，控制器須要經過定時地發送包含LLDP數據包的Packet_out消息給與其相鏈接的SDN交換機並根據反饋回來的Packet_in消息獲知交換機信息，在監測交換機工做狀態的同時完成網絡拓撲視圖的更新。

2.在隨時更新SDN交換機及其連接狀態的同時，對各類邏輯組網信息進行記錄，其中最典型的場景是雲計算環境下的多租戶共享網絡資源。在多租戶狀況下，網絡資源被虛擬化爲資源池，每一個租戶均可以按其實際需求得到設備、端口、帶寬等網絡資源，同時還能夠根據自身需求對其全部的資源進行靈活組網。這些與租戶網絡相關的資源信息都須要在拓撲管理中給與保存和展示，以反映真實的網絡利用狀況，實現優化的資源調度。

 

策略制定和表項下發技術：

SDN交換機中的流表機制打破了傳統網絡中的層次化概念，不管是源MAC、目的MAC、VLAN ID等傳統的二層網絡信息，仍是源IP、目的IP等傳統的三層網絡信息，抑或源TCP/UDP端口、目的TCP/UDP端口等傳統的四層網絡信息，都被統一封裝到一個流表項中。所以，控制器須要針對不一樣層次上的網絡傳輸需求，制定相應的轉發策略並生成對應的流表項下發給交換機。具體思路以下：

1）二層網路數據轉發：傳統設備的主要工做是MAC地址學習和基於MAC地址的數據包轉發。而在SDN網絡中，MAC地址學習已經在控制器的鏈路發現過程當中實現，而根據二層網路哦信息（如MAC地址）進行數據包轉發也比較容易實現，只須要控制器以目的MAC地址爲依據將對應的交換機轉發端口號寫入相應交換機的流表項中便可

2）三層網路數據轉發：傳統設備一般採用「一次路由屢次轉發」的機制，即交換設備在接收到來自源IP的數據包後，查詢路由表肯定到達目的IP的路由，並經過必定的識別觸發機制確立和記錄源MAC地址與目的MAC地址以及轉發端口的對應關係，後續在源和目的之間產生的通訊將由二層模塊直接處理。在SDN網絡中，其核心是控制器利用相關的路由算法計算出源和目的之間的路由信息，並以IP地址、MAC地址爲依據將對應的交換機轉發端口號寫入相應交換機的流表項中。

3）四層網絡數據轉發：傳統設備的實現一般須要維護一個鏈接表用於保存與業務應用服務器相對應的源IP、源TCP/UDP端口等信息。在SDN網路中，四層數據解析將在控制器中完成，並以TCP/UDP端口號、IP地址和MAC地址爲依據將對應的交換機轉發端口號寫入相應交換機的流表項中。

 

SDN控制器的流表下發的兩種模式：

1.主動：在數據包到達OpenFlow交換機以前就進行流表設置，當第一個數據包到達交換機後，交換機就已經直到該如何處理數據包了，這種方式有效消除了數據傳輸過程當中的流表項設置延遲。同時，不存在控制器每秒鐘可以處理的流數量的限制。在理想狀況下，控制器須要儘量地預擴散流表項。

2.被動：當OpenFlow交換機接收到一個數據包而且沒有發現與之匹配的流表項時，只能將其送給控制器處理。一旦控制器去欸的那個了相應的處理方式，那麼相關的信息就會返回並緩存在交換機上，同時控制器將肯定這些緩存信息的保存時限。

兩種下發模式的比較：主動的流表下發利用預先設定好的規則，避免每次針對各個數據流的流表項設置工做，但考慮到數據流的多樣性，爲了保證每一個流都被轉發，流表項的管理工做將變得複雜，例如須要合理設置通配符知足轉發要求。被動的流表下發可以更有效地利用交換機上的流表存儲資源，但在處理過程當中，會增長額外的流表設置時間，同時一旦控制器和交換機之間的鏈接被斷開，交換機將不能對後續到達的數據流進行轉發處理。

 

北向接口技術REST API的四個特徵：

1）可尋址性強：每一個片斷都應該有本身的URI，而且URI應具備良好的可讀性。

2）接口無狀態：服務器不會根據以前的訪問行爲來約束後續的動做，除非某些行爲已經影響到了服務器資源。

3）注重關聯性：應用應該可以根據用戶發來的請求，自動地在反饋的信息中儘量地包含與請求相關的所有資源連接，以容許用戶在無需理解全部URI對應的資源的前提下從應用反饋的信息中選取可用資源。

4）接口要統一：web服務應當擁有統一的資源編址及表述方案。其中，統一編址須要在對資源相關的URI進行準確描述的基礎上，使用標準的HTTP請求方法（GET、POST、PUT、DELETE）；統一表述須要利用標準化的編碼機制（如XML），同時，訪問錯誤處理也應當使用標準化的HTTP相應編碼。

 

東西向控制技術擴展：

基於控制器集羣的SDN架構：

ps：控制器的軟件化使得服務器能夠做爲控制器的載體，控制器能夠以服務器集羣爲基礎進行搭建。控制器集羣要能支持向正在運行的集羣中增長新的控制器以改善擴展性、保存失效控制器對應的交換狀態以保證可靠性。

保證控制器集羣對SDN網絡的控制的兩個設計點：

1.主控制器的選舉：主控制器主要負責生成和維護全網範圍內的控制器和交換機的狀態信息，一旦它出現失效，就須要從集羣中的副控制器中選舉一個新的主控制器以免單點失效。

2.控制器集羣對交換機的透明化：在SDN網絡的運行過程當中，交換機無需關心它當前接收的是哪臺控制器發來的控制指令，同時在其向控制器發送數據包時，能繼續保持以前單一控制器時的操做方式，從而保證控制器在邏輯上的集中。

 

SDN控制器的設計要素：

 

業界主要開源SDN控制器信息：

 

Floodlight軟件架構：

控制器模塊：用於實現SDN核心網絡服務

應用模塊：針對不一樣業務應用實現解決方案。

控制器模塊提供了Java API供應用模塊調用，同時兩類模塊還共同支持向上層開放REST API做爲北向接口。

Floodlight主要控制器模塊：

四類功能以下：

1）發現和揭示網絡狀態及相關事件（如拓撲、設備、流）

2）支持控制器和網絡交換機的通訊（如OpenFlow協議）

3）管理Floodlight模塊及模塊共享的資源（如存儲、線程、測試）

4）提供Web UI和調試服務（如提供Jython接口）

ps：FloodlightProvider將做爲核心模塊首先在Floodlight的啓動過程當中被運行，它將收到的OpenFlow數據包轉換爲一個個事件。同時，其餘的模塊將向FloodlightProvider進行註冊，進而稱爲一個服務，而後就能夠處理相應事件了。

Floodlight的部分應用模塊：

 

第四章

SDN應用分類及其與控制器的關係：

SDN中主要三類應用：

1）資源管理平臺：主要是面向雲計算資源統一管理和調配的平臺，其目標是實現池化的計算、存儲、網絡等資源的靈活交付，按需知足雲計算業務的資源需求。

2）軟件定義的應用交付：基於SDN理念改造負載均衡、訪問控制、應用加速等應用交付技術，使之能替換或擴展此前在傳統網絡中須要利用專用硬件實現的功能

3）創新網絡業務：在傳統的靜態化網絡中難以實現，但在SDN環境下能得到良好支持的新興業務，這類應用具備很是大的創新空間

 

典型的SDN資源管理平臺架構圖以下：

資源管理平臺的核心：基於SDN控制器北向接口編排資源管理流程，使得它能及時有效地將上層雲計算業務的資源需求反饋給控制器並對網絡設備和鏈路進行調配。考慮到雲計算等典型業務一般須要計算、存儲、網絡等多種類型資源的協同交付，所以對SDN控制能力的調用須要被封裝爲獨立的組件，並與相應計算資源空控件組件、存儲資源控制組件，以及其餘一些功能組件共同工做。當前雲計算也廣泛是以計算資源爲核心的服務，隨着網絡資源管理靈活性和便利性的提高，往後勢必會有愈來愈多以網絡資源爲核心的雲計算服務被提出和應用。

 

軟件定義應用交付與傳統網絡應用交付的比較：

ps：在傳統網絡中，相似防火牆、負載均衡、入侵檢測等網絡應用都是由專用的硬件設備實現的，在網絡運行過程當中，根據實際須要逐臺進行配置以知足數據傳輸要求。而在SDN網絡中，上述應用將以軟件程序的方式存在，它們能夠與控制器一塊兒部署在通用服務器上，經過調用控制器的北向接口得到其提供的流量模式、應用數據等信息並對其進行辨識和判斷，進而驅動控制器洗髮指令調整網絡配置。例如，當基於SDN的入侵監測應用在控制器監測的數據流中識別到惡意流量時，它就能夠自動驅動控制器設置相應的流表項將這些數據包導向網絡中部署的安全隔離設備，避免其對網絡的破壞。

面向SDN的網絡應用交付技術的改造從四個方面進行：

1）改寫傳統的硬件應用爲軟件實現

2）支持網絡應用的虛擬化實現和部署

3）基於控制器北向接口改造應用

4）開放編程接口支持創新業務開發

 

OpenStack整體架構和其七大核心組件之間的關係圖：