1. 程式人生 > >第二章-SDN南向協議

第二章-SDN南向協議

第二章–SDN南向協議

SDN 網路體系結構: SDN網路應用, 北向介面, SDN控制器, 南向介面, SDN資料平面

網路應用: 對網路資料平面的配置,管理,控制

北向介面: 將資料平面資源和狀態抽象成統一的開放程式設計介面

SDN控制器:重要,也稱為網路作業系統,向北提供可程式設計能力,向南對資料平面統一配置,管理控制

南向介面: 對資料平面程式設計控制,實現資料平面的轉發等網路行為(openflow在此)

思想:通用硬體底層,軟體定義功能,開源

現有的分層協議可以看做是資料平面的抽象模型,但是控制平面只是網路功能和網路協議的堆砌

改進: 控制平面抽象後通過程式設計去控制網路,資料平面將不同協議的匹配表整合起來,形成多欄位匹配表

SDN 南向協議

openflow協議是一個狹義的南向協議,他通過下發流表項對資料平面裝置的網路資料處理邏輯進行程式設計

狹義的SDN南向協議判斷依據就是是否有確切的資料平面程式設計能力

廣義的SDN含有三種

  1. 傳統的,僅能進行網路配置的(無法指導資料交換)
  2. 狹義的SDN,指導資料交換
  3. 完全可程式設計:本來就存在,但不是為SDN設計,只是被應用在SDN上

openflow

設計動機 通過修改流表規則來指導交換機對網路資料包進行轉發和修改

通過TCP,TSL或者SSL傳輸openflow報文

openflow交換機

分成流表和安全通道兩部分

控制器和交換機通過安全通道進行連線,控制器下發流表給交換機來匹配流表中的資料包

怎麼通訊? 連線初始化階段:將自身的特性等上報給控制器. 資料包匹配流表失敗,吧資料包放在Packet-in報文中上報給控制器

openflow的表

  1. 流表

將資料包的處理變成了一條"流水線",每一個流表由匹配與,指令集和計數器構成

匹配域區分不同的資料流

計數器記錄匹配流表的資料包的數目,位元組數等相關數目

流表的結構:

匹配域 優先順序 計數器 指令 計數器 cookie

  1. 組表

定義了一組動作,正則主動做可以被多條流表項共同使用,實現組播,負載均衡,容災備份和聚合的功能

組表的結構

組表號 型別 計數器 動作桶

  1. Meter表

用於計量和限速

結構

計量表號 計量帶 計數器

openflow通道

控制器和交換機相互通訊的通道

  1. controller-to-switch

控制器初始化,要求交換機回覆

  1. 非同步報文

用於上報不能匹配流表的資料包

  1. 任意報文

誰都可以發起,表達各種要求和狀態

####openflow通訊流程

  1. 互相傳送hello報文,寫上版本

  2. 控制器下發feature request,交換機回覆feature reply,完成相關配置,可以正常通訊

  3. 當資料包匹配流表失敗的時候,控制器根據控制邏輯指導交換機處理資料流

  4. 為了保持openflow的活性,控制器週期性地向交換機發送echo報文

2.3 廣義的SDN南向協議

of-config

作用:對openflow交換機進行各種配置

  • 配置控制器
  • 配置交換機埠佇列
  • 改變埠狀態和特性
  • 完成交換機和控制器的安全連線證書問題
  • 發現邏輯交換機
  • 配置隧道協議

和openflow相伴相生(但是還可以協助其他的南向協議,所以彷彿比openflow更有生命力)

OVSDB(The Open vSwitch Database Management Protocol)OVS(虛擬交換機)的資料庫管理協議

也是openflow的交換機配置協議,但是隻用於OVS

  • 增刪改網橋(datapath)
  • 配置網橋所需要的控制器資訊
  • 配置管理端
  • 增刪改埠,隧道,佇列
  • 配置QOS
  • 收集統計

NETCONF

特性:可用於openflow也可用於傳統裝置

XMPP

基於XML,不是專門為openflow打造

2.4完全可程式設計南向協議

POF(protocol oblivious forwarding)

特性:僅含有{offset,length}來定位資料,匹配操作=>支援新協議時無需對交換機升級,僅需要升級控制平面

協議功能也就是增加修改刪除對應的欄位/標籤,所以支援新協議時,只需要在控制器增加對應邏輯,交換機不用動,如同處理器只進行簡單運算,不關心這是圖形還是語音

為什麼需要POF

  • openflow在不停地擴充支援的協議,所以越來越複雜
  • 現在openflow無法對交換機的轉發邏輯程式設計和修改,只能通過新增流表來指導資料包轉發
  • openflow是無狀態的,無法維護網路狀態並主動做出動作
  • 資料平面和控制平面分離不徹底:交換機必須掌握協議的語義等控制資訊才能完成資料匹配=>協議增多,特定指令增多
  • 只能按照固定的協議邏輯處理資料,不能增加一些輔助資訊
  • 給openflow增加新特性時,需要重寫控制器和交換機兩端的協議棧
  • 交換機無法描述現有狀態並主動採取動作,一切皆靠控制器

POF可以使交換機在特定條件下主動建立修改刪除流表

雖然資料操作靈活,但是控制流程複雜的多,所以還在初期探索階段

P4 programming protocol-independent packet processors協議無關資料包處理程式語言

他和openflow關注點不一樣----資料平面的可程式設計,也是為了解決openflow程式設計能力不足和擴充套件性差的問題

特性:

  1. 有對交換機協議解析流程和資料處理流程進行程式設計的能力
  2. 交換裝置無需關注協議的語法
  3. 無需關注底層裝置的具體資訊
  4. 支援並行和序列執行Match-Action

交換機執行邏輯

入埠->解析器->匹配+動作(入埠流水線,執行操作為包修改和出埠選擇)->快取->匹配+動作(出埠流水線,執行操作為包修改->出埠

包解析+資料包轉發

例子:從解析器出來的資料西線經過虛擬路由標識,再經過路由表再根據匹配的結果(0?1?)處理後交給交換表介面表村距離 在這裡插入圖片描述

每一個P4程式包含的元件

  • Header報頭

資料包的處理都看其報頭決定,所以P4也要定義對應的報頭(本質就是有序排列的協議欄位序列)

  • Parser解析器

定義報頭協議之間的關係,以及資料包解析的流程(解析到第一行的結果,決定下一個該解析第五行內容)

  • Table表

格式:Match-Action 匹配域和對應動作

看似和openflow差不多哦,但關鍵是協議無關

  • Control Program控制程式

決定了資料包的處理流程(先進誰的表)