轉自：https://www.cnblogs.com/cing/p/7678224.html
第一章
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總體架構和其七大核心組件之間的關係圖：
