SDN協(xié)議接口

01南向接口協(xié)議02北向接口協(xié)議03

使用OpenFlow協(xié)議建立連接04

使用Postman下發(fā)流表南向接口協(xié)議概述SDN控制平面通過(guò)南向接口協(xié)議對(duì)數(shù)據(jù)平面進(jìn)行控制和管理，包括鏈路發(fā)現(xiàn)、拓?fù)涔芾?、策略制定、表?xiàng)下發(fā)等。南向接口協(xié)議在完成控制平面與數(shù)據(jù)平面間交互的同時(shí)，也需要完成部分管理配置功能。SDN南向接口協(xié)議有很多種，其中發(fā)展較為成熟、使用較為廣泛的交互協(xié)議是OpenFlow協(xié)議，較為典型的網(wǎng)絡(luò)設(shè)備管理協(xié)議是NETCONF協(xié)議，本節(jié)將分別對(duì)這兩種協(xié)議進(jìn)行詳細(xì)介紹。OpenFlow協(xié)議架構(gòu)OF交換機(jī)通過(guò)OpenFlow協(xié)議與控制器通信。流表、安全通道與OpenFlow協(xié)議是v1.0版本中最為核心的概念。流表是一些針對(duì)特定流的策略的集合，負(fù)責(zé)數(shù)據(jù)分組的查詢和轉(zhuǎn)發(fā)，主要包含數(shù)據(jù)分組的匹配特征和處理方法。OF交換機(jī)通過(guò)安全通道與控制器相連，安全通道上傳輸?shù)木褪荗penFlow協(xié)議消息，負(fù)責(zé)控制器與交換機(jī)間的交互。OpenFlow流表項(xiàng)結(jié)構(gòu)OpenFlowv1.0流表項(xiàng)結(jié)構(gòu)OpenFlow的流表項(xiàng)主要包括3個(gè)部分：分組頭域（HeadField）：用于數(shù)據(jù)分組匹配；計(jì)數(shù)器（Counter）：用于保存與條目相關(guān)的統(tǒng)計(jì)信息；動(dòng)作表：用于匹配表項(xiàng)后對(duì)數(shù)據(jù)分組執(zhí)行動(dòng)作。OpenFlow分組頭域分組頭域是數(shù)據(jù)分組匹配流表項(xiàng)時(shí)的參考依據(jù)，作用類似于傳統(tǒng)交換機(jī)進(jìn)行二層交換時(shí)匹配數(shù)據(jù)分組的MAC地址，也類似于路由器進(jìn)行三層路由時(shí)匹配的IP地址。如圖5-3所示，在OpenFlowv1.0中，流表項(xiàng)的分組頭域包括了12個(gè)字段，協(xié)議稱其為12元組（12-Tuple），它提供了1～4層的網(wǎng)絡(luò)控制信息。OpenFlow12元組字段字節(jié)數(shù)適用范圍說(shuō)明入端口未規(guī)定所有數(shù)據(jù)分組數(shù)據(jù)分組進(jìn)入交換機(jī)的端口號(hào)，從1開(kāi)始以太網(wǎng)源地址6B有效端口收到的數(shù)據(jù)分組無(wú)以太網(wǎng)目的地址6B有效端口收到的數(shù)據(jù)分組無(wú)以太網(wǎng)幀類型2B有效端口收到的數(shù)據(jù)分組OF交換機(jī)必須支持由IEEE802.2+SNAP或OUI規(guī)定的類型。使用IEEE802.3而非SNAP的幀類型為0x05FFVLAN標(biāo)識(shí)12bit幀類型為0x8100的數(shù)據(jù)分組VLANIDVLAN優(yōu)先級(jí)3bit幀類型為0x8100的數(shù)據(jù)分組VLANPCP字段源IP地址4BARP與IP數(shù)據(jù)分組可劃分子網(wǎng)目的IP地址4BARP與IP數(shù)據(jù)分組可劃分子網(wǎng)IP數(shù)據(jù)分組類型1BARP與IP數(shù)據(jù)分組對(duì)應(yīng)ARP中opcode字段的低字節(jié)服務(wù)類型ToS6bitIP數(shù)據(jù)分組高6bit為ToS傳輸層源端口號(hào)/ICMP類型2BTCP/UDP/ICMP分組當(dāng)數(shù)據(jù)分組類型是ICMP時(shí)，低8bit用于標(biāo)識(shí)ICMP類型傳輸層目的端口號(hào)/ICMP碼值2BTCP/UDP/ICMP分組當(dāng)數(shù)據(jù)分組類型是ICMP時(shí)，低8bit用于標(biāo)識(shí)ICMP碼值OpenFlowv1.0中12元組詳細(xì)信息：OpenFlow計(jì)數(shù)器類型計(jì)數(shù)器字節(jié)數(shù)/B每張表有效表項(xiàng)4查表的數(shù)據(jù)分組8匹配的數(shù)據(jù)分組8每條流表項(xiàng)接收數(shù)據(jù)分組8接收字節(jié)8生存時(shí)間（單位為s）4生存時(shí)間（單位為ns）4每個(gè)端口接收數(shù)據(jù)分組8傳送數(shù)據(jù)分組8接收字節(jié)8傳送字節(jié)8接收出現(xiàn)的錯(cuò)誤8傳送出現(xiàn)的錯(cuò)誤8接收后丟棄的分組8傳送時(shí)丟棄的分組8接收的幀排列錯(cuò)誤8溢出錯(cuò)誤8循環(huán)冗余校驗(yàn)（CRC）錯(cuò)誤8幀沖突8每個(gè)隊(duì)列傳送的數(shù)據(jù)分組8傳送的字節(jié)8溢出錯(cuò)誤8流表項(xiàng)中的計(jì)數(shù)器被用來(lái)統(tǒng)計(jì)流的一些信息，例如查找次數(shù)、收發(fā)分組數(shù)、生存時(shí)間等。OpenFlow針對(duì)每張表、每條流表項(xiàng)、每個(gè)端口、每個(gè)隊(duì)列也都會(huì)維護(hù)它們相應(yīng)的計(jì)數(shù)器。OpenFlow動(dòng)作表動(dòng)作表指定了OF交換機(jī)處理相應(yīng)流的行為。動(dòng)作表可以包含0個(gè)或多個(gè)動(dòng)作，交換機(jī)會(huì)按照這些動(dòng)作的先后順序依次執(zhí)行。如果其中不包含轉(zhuǎn)發(fā)（Forward）動(dòng)作，數(shù)據(jù)分組就會(huì)被丟棄掉；如果包含轉(zhuǎn)發(fā)動(dòng)作，數(shù)據(jù)分組會(huì)得到相應(yīng)的轉(zhuǎn)發(fā)處理。類型名稱說(shuō)明必選動(dòng)作轉(zhuǎn)發(fā)交換機(jī)必須支持將數(shù)據(jù)分組轉(zhuǎn)發(fā)給設(shè)備的物理端口及下面的虛擬端口。ALL：數(shù)據(jù)分組復(fù)制為多份轉(zhuǎn)發(fā)到所有端口（不包括入口，不考慮最小生成樹(shù)）。CONTROLLER：將數(shù)據(jù)分組封裝為Packet-in消息并轉(zhuǎn)發(fā)給控制器。LOCAL：轉(zhuǎn)發(fā)給本地網(wǎng)絡(luò)棧。TABLE：對(duì)控制器Packet-out數(shù)據(jù)分組執(zhí)行流表的匹配。IN_PORT：把數(shù)據(jù)分組從它的入端口發(fā)回去丟棄沒(méi)有明確指明處理行動(dòng)的表項(xiàng)，匹配的所有數(shù)據(jù)分組默認(rèn)被丟棄可選動(dòng)作轉(zhuǎn)發(fā)NORMAL：按照OF交換機(jī)所支持的傳統(tǒng)交換機(jī)的二層或三層策略進(jìn)行轉(zhuǎn)發(fā)。FLOOD：通過(guò)最小生成樹(shù)從出口泛洪發(fā)出，但不包括入口入隊(duì)將分組轉(zhuǎn)發(fā)到某個(gè)端口上已配置好的隊(duì)列中，隊(duì)列的配置OpenFlow無(wú)法實(shí)現(xiàn)修改域交換機(jī)將修改數(shù)據(jù)分組的分組頭，可以為12元組中的任意字段OpenFlow流表的匹配在OpenFlowv1.0中，數(shù)據(jù)分組是依照12元組進(jìn)行匹配的。當(dāng)數(shù)據(jù)分組進(jìn)入OF交換機(jī)后，就會(huì)將它的12元組解析出來(lái)，并將該12元組與流表中各個(gè)表項(xiàng)的分組頭域中的12元組對(duì)照，以決定后續(xù)的動(dòng)作，整個(gè)流程如下圖所示。OpenFlow安全通道OpenFlow安全通道負(fù)責(zé)承載OpenFlow協(xié)議的消息，不管是流表的下發(fā)還是其他的控制消息，都要經(jīng)過(guò)這條通道。這部分流量屬于OpenFlow網(wǎng)絡(luò)的控制信令，不同于數(shù)據(jù)平面的網(wǎng)絡(luò)流，它不需要經(jīng)過(guò)交換機(jī)流表的檢查。為了保證這部分流量安全可靠的傳輸，OpenFlowv1.0規(guī)定通道建立在TCP連接之上，采用安全傳輸層協(xié)議（TransportLayerSecurity，TLS）進(jìn)行加密。OpenFlow安全通道的建立OpenFlow安全通道的維護(hù)OpenFlow協(xié)議消息OpenFlow協(xié)議消息——Controller-to-Switch子類型功能描述Features安全通道建立以后，控制器會(huì)立即發(fā)送Features-Request消息給交換機(jī)，以獲取交換機(jī)支持的相關(guān)特性。Configuration控制器可以通過(guò)Set-Config消息設(shè)置交換機(jī)的配置信息，通過(guò)Get-Config消息查詢配置信息，交換機(jī)需要通過(guò)Config-Reply消息做出應(yīng)答。Modify-State控制器通過(guò)Port-mod消息管理交換機(jī)的端口狀態(tài)，通過(guò)Flow-mod消息增加或者刪除交換機(jī)的流表項(xiàng)。Read-StateOpenFlow會(huì)維護(hù)每張表、每個(gè)流表項(xiàng)、每個(gè)端口、每個(gè)隊(duì)列相應(yīng)的計(jì)數(shù)器，當(dāng)控制器需要統(tǒng)計(jì)信息時(shí)，還會(huì)向交換機(jī)發(fā)送相關(guān)的Request消息，請(qǐng)求相關(guān)信息。Send-Packet很多情況下，控制器需要發(fā)送消息到數(shù)據(jù)平面，這時(shí)可以通過(guò)Packet-out消息封裝好數(shù)據(jù)分組并傳給OF交換機(jī)，并在該消息中指定特定的動(dòng)作表，指導(dǎo)交換機(jī)如何處理這個(gè)數(shù)據(jù)分組，而不再進(jìn)行流表的匹配。Barrier控制器通過(guò)Barrier-Request消息確保之前下發(fā)的消息已經(jīng)被交換機(jī)執(zhí)行完。Controller-to-Switch（控制器—交換機(jī)）：這類消息由控制器發(fā)起。Asynchronous消息子類型功能描述Packet-in收到的數(shù)據(jù)分組如果在流表中沒(méi)有匹配的流表項(xiàng)，或者匹配的流表項(xiàng)中給出了轉(zhuǎn)發(fā)動(dòng)作，但動(dòng)作中指定端口為CONTROLLER時(shí)，OF交換機(jī)會(huì)封裝Packet-in消息，把這個(gè)數(shù)據(jù)分組上交給控制器。Flow-Removed交換機(jī)中的流表項(xiàng)因?yàn)槌瑫r(shí)或修改等原因被刪除掉時(shí)，會(huì)觸發(fā)Flow-Removed消息，觸發(fā)的前提是在下發(fā)這條流表項(xiàng)時(shí)flags字段置位了OFPFF_SEND_FLOW_REM。Port-Status交換機(jī)端口狀態(tài)發(fā)生變化時(shí)（如Up/Down），會(huì)觸發(fā)Port-Status消息報(bào)告端口的信息以及發(fā)生的狀態(tài)變化（如Add、Delete或者M(jìn)odify）。Error交換機(jī)通過(guò)Error消息來(lái)通知控制器發(fā)生錯(cuò)誤的信息。Asynchronous（異步）：這類消息由交換機(jī)主動(dòng)發(fā)起。用來(lái)將網(wǎng)絡(luò)事件或交換機(jī)狀態(tài)的變化更新到控制器。Symmetric消息子類型功能描述Hello認(rèn)證通過(guò)后，雙方通過(guò)握手消息（Hello）建立安全通道。Echo雙方均可以主動(dòng)向?qū)Ψ桨l(fā)出Echo-Request消息，接收者需要回復(fù)Echo-Reply。該消息用來(lái)“?；睢保部梢杂脕?lái)測(cè)量延遲。VendorVendor是為未來(lái)的協(xié)議版本預(yù)留的，以便允許OF交換機(jī)廠商提供額外的OpenFlow功能。Symmetric（對(duì)稱）：這類消息可由控制器發(fā)起，也可以由OF交換機(jī)發(fā)起。OpenFlow協(xié)議的演進(jìn)OpenFlow協(xié)議由開(kāi)放網(wǎng)絡(luò)基金會(huì)（ONF）負(fù)責(zé)維護(hù)，OpenFlowv1.0作為第一個(gè)較為成熟的版本，于2009年12月發(fā)布，隨后陸續(xù)地發(fā)布了幾個(gè)版本，協(xié)議仍在不斷地演進(jìn)。OpenFlow協(xié)議面臨的問(wèn)題使攻擊者非法獲取主機(jī)的系統(tǒng)級(jí)訪問(wèn)權(quán)限，執(zhí)行任意指令。使攻擊者非法獲取主機(jī)的系統(tǒng)級(jí)訪問(wèn)權(quán)限，執(zhí)行任意指令。協(xié)議消息類型尚不完善SDN是一種革命性的技術(shù)，雖然各個(gè)版本在不斷豐富消息類型，但整體來(lái)看OpenFlow在這方面仍然存在很多的缺陷，控制平面的安全性與擴(kuò)展性問(wèn)題SDN是集中式控制思想的產(chǎn)物。當(dāng)網(wǎng)絡(luò)規(guī)模超過(guò)一定限度時(shí)，單點(diǎn)控制會(huì)成為SDN中的瓶頸，而且其安全性也存在很大隱患。數(shù)據(jù)平面的設(shè)備性能問(wèn)題OpenFlow將網(wǎng)絡(luò)協(xié)議棧扁平化，對(duì)轉(zhuǎn)發(fā)設(shè)備而言，協(xié)議棧各層次不再具有明確的界限，各個(gè)網(wǎng)絡(luò)字段都可作為流表中的匹配域，還可以進(jìn)行任意字段的組合。硬件設(shè)備為了適應(yīng)這種通用的匹配方式，需要付出高昂的代價(jià)，這極大地限制了流表的規(guī)模，也就限制了SDN的規(guī)模。NETCONF協(xié)議概述NETCONF定義了一種簡(jiǎn)單的管理網(wǎng)絡(luò)設(shè)備的機(jī)制，通過(guò)該機(jī)制可以在設(shè)備中檢索配置數(shù)據(jù)信息，使用相應(yīng)的軟件向設(shè)備上傳新的配置數(shù)據(jù)。通過(guò)NETCONF協(xié)議，網(wǎng)絡(luò)設(shè)備可以提供規(guī)范的應(yīng)用程序接口（ApplicationProgrammingInterface，API），應(yīng)用程序可以使用這個(gè)簡(jiǎn)單的API來(lái)發(fā)送和接收完整或部分的配置數(shù)據(jù)。NETCONF使用遠(yuǎn)程過(guò)程調(diào)用（RemoteProcedureCall，RPC）方式促進(jìn)客戶端和服務(wù)器之間的通信?？蛻舳送ǔＷ鳛榫W(wǎng)絡(luò)管理器的一部分運(yùn)行腳本或應(yīng)用程序。服務(wù)器通常是網(wǎng)絡(luò)設(shè)備?？蛻舳耸褂每蓴U(kuò)展標(biāo)記語(yǔ)言（ExtensibleMarkupLanguage，XML）對(duì)RPC進(jìn)行編碼，并使用安全的、面向連接的會(huì)話將其發(fā)送到服務(wù)器。服務(wù)器以XML編碼的回復(fù)進(jìn)行響應(yīng)。請(qǐng)求和響應(yīng)的具體內(nèi)容在XMLDTDs或XML模式中進(jìn)行了詳細(xì)的描述。NETCONF協(xié)議分層架構(gòu)NETCONF協(xié)議采用了分層協(xié)議模型，初始的配置數(shù)據(jù)通過(guò)每一層對(duì)應(yīng)的協(xié)議進(jìn)行包裝，然后向下一層提供相關(guān)的服務(wù)。采用這種分層架構(gòu)能夠?qū)ETCONF復(fù)雜的整體拆分成相對(duì)獨(dú)立的幾層，讓每層都只專注于協(xié)議的某個(gè)方面，將各層內(nèi)部發(fā)生修改之后對(duì)其他層的影響降到最低，使得整個(gè)過(guò)程實(shí)現(xiàn)起來(lái)更加簡(jiǎn)單。NETCONF協(xié)議分層介紹NETCONF協(xié)議在邏輯上可以劃分為4層：層面說(shuō)明第一層：傳輸層面向連接；身份認(rèn)證、完整性和機(jī)密性；強(qiáng)制性運(yùn)輸協(xié)議。第二層：消息層NETCONF協(xié)議采用基于RPC的通信模式。NETCONF協(xié)議使用<rpc>和<rpc-reply>元素來(lái)提供與傳輸協(xié)議相獨(dú)立的NETCONF請(qǐng)求和響應(yīng)，來(lái)完成對(duì)網(wǎng)絡(luò)設(shè)備的配置管理工作。第三層：操作層NETCONF協(xié)議在操作層中提供了一系列低級(jí)別操作來(lái)管理設(shè)備配置和檢索設(shè)備狀態(tài)信息，而設(shè)備狀態(tài)信息一般存放在數(shù)據(jù)庫(kù)中，這些操作提供了檢索、配置、復(fù)制和刪除配置數(shù)據(jù)存儲(chǔ)的功能。第四層：內(nèi)容層內(nèi)容層由配置數(shù)據(jù)和通知數(shù)據(jù)組成。在NETCONF的標(biāo)準(zhǔn)規(guī)定中并沒(méi)有對(duì)內(nèi)容層進(jìn)行標(biāo)準(zhǔn)化，但是在RFC6020標(biāo)準(zhǔn)中提出的YANG數(shù)據(jù)建模語(yǔ)言被應(yīng)用于NETCONF數(shù)據(jù)模型和協(xié)議操作。01南向接口協(xié)議02北向接口協(xié)議03

使用OpenFlow協(xié)議建立連接04

使用Postman下發(fā)流表北向接口協(xié)議概述北向接口是提供給運(yùn)營(yíng)商或者用戶接入和管理的接口，用戶通過(guò)控制器提供的北向接口定義和開(kāi)發(fā)應(yīng)用層中的網(wǎng)絡(luò)管理應(yīng)用程序。與南向接口領(lǐng)域已經(jīng)有OpenFlow等多種國(guó)際標(biāo)準(zhǔn)不同，北向接口方面還缺少業(yè)界公認(rèn)的標(biāo)準(zhǔn)。其主要原因是北向接口直接為業(yè)務(wù)應(yīng)用服務(wù)，其設(shè)計(jì)需密切聯(lián)系業(yè)務(wù)應(yīng)用需求，具有多樣化的特征，很難統(tǒng)一。本節(jié)針對(duì)RESTfulAPI這一北向接口進(jìn)行介紹。RESTfulAPI簡(jiǎn)介RESTfulAPI指的就是REST風(fēng)格的應(yīng)用程序接口。最初是由RoyFielding（參與設(shè)計(jì)HTTP）在其博士畢業(yè)論文中提出。REST的全稱是RepresentationalStateTransfer，可以翻譯為“描述性狀態(tài)遷移”。REST主要有以下幾個(gè)特點(diǎn)：資源統(tǒng)一資源標(biāo)識(shí)符統(tǒng)一接口無(wú)狀態(tài)RESTfulAPI調(diào)測(cè)工具Postman介紹Postman是Google開(kāi)發(fā)的一款功能強(qiáng)大的網(wǎng)頁(yè)調(diào)試、發(fā)送網(wǎng)頁(yè)HTTP請(qǐng)求，并能運(yùn)行測(cè)試用例的Chrome插件。其主要功能：（1）模擬各種HTTP請(qǐng)求（2）Collection功能（測(cè)試集合）（3）人性化的Response整理（4）內(nèi)置測(cè)試腳本語(yǔ)言（5）設(shè)定變量與環(huán)境01南向接口協(xié)議02北向接口協(xié)議03使用OpenFlow協(xié)議建立連接04

使用Postman下發(fā)流表實(shí)驗(yàn)介紹實(shí)驗(yàn)內(nèi)容：學(xué)習(xí)OpenFlow交換機(jī)和控制器的配置方式。使用Wireshark抓包并進(jìn)行分析，學(xué)習(xí)OpenFlow交換機(jī)與控制器的消息交互過(guò)程。實(shí)驗(yàn)?zāi)康模毫私釵penFlow交換機(jī)與控制器建立TCP連接的過(guò)程。掌握配置安全通道中OpenFlow版本的方法。理解OpenFlow交換機(jī)和控制器的消息交互過(guò)程。實(shí)驗(yàn)拓?fù)鋵?shí)驗(yàn)拓?fù)浒ㄒ粋€(gè)控制器和一臺(tái)主機(jī)設(shè)備：OpenFlow連接建立交互流程1、控制器與OpenFlow交換機(jī)通過(guò)TCP“三次握手”，建立有效的連接。其中，控制器一端的端口號(hào)為6633。2、控制器與OpenFlow交換機(jī)之間相互發(fā)送Hello消息，用于協(xié)商雙方的OpenFlow版本號(hào)。在雙方支持的最高版本號(hào)不一致的情況下，協(xié)商的結(jié)果將以較低的OpenFlow版本為準(zhǔn)。如果雙方協(xié)商不一致，還會(huì)產(chǎn)生Error消息。OpenFlow連接建立交互流程3.控制器向OpenFlow交換機(jī)發(fā)送FeaturesRequest消息，請(qǐng)求OpenFlow交換機(jī)上傳自己的詳細(xì)參數(shù)。OpenFlow交換機(jī)收到請(qǐng)求后，向控制器發(fā)送FeaturesReply消息，詳細(xì)匯報(bào)自身參數(shù)，包括支持的buffer數(shù)目、流表數(shù)以及Actions等。4.控制器通過(guò)SetConfig消息下發(fā)配置參數(shù)，然后通過(guò)GetConfigRequest消息請(qǐng)求OpenFlow交換機(jī)上傳修改后的配置信息。OpenFlow交換機(jī)通過(guò)GetConfigReply消息向控制器發(fā)送當(dāng)前的配置信息。5.控制器與OpenFlow交換機(jī)之間發(fā)送Packet_out、Packet_in消