SDN中的LLDP和Openflow協議

 

OpenFlow交換機把傳統網絡中,完全由交換機/路由器控制的報文轉換爲由交換機和控制器來共同完成數據的轉發操作,從而實現數據的轉發與路由控制的分離。控制器則通過事先規定好的接口操作OpenFlow交換機中的流表,從而達到數據轉發的目的。

SDN鏈路發現和拓撲管理主要是控制其利用南向接口的上行通道對底層交換設備上報信息進行統一監控和統計;而策略制定和表項下發則是控制器利用南向接口的下行通道對網絡設備進行統一控制。

SDN控制器通過LLDP(Link Layer Discovery Protocol,鏈路發現協議)協議進行鏈路發現,然後根據發現協議蒐集的信息來識別和管理網絡拓撲結構。

LLDP協議格式:

OpenFlow協議的思路,即使網絡設備維護一個FlowTable,並且只通過FlowTable對報文進行處理,FlowTable本身的生成、維護和下發完全由外置的控制器Controller來實現,從而實現Controller的全局控制。

OPENFLOW協議

在OpenFlow交換機中,包含安全通道,多級流表和組表。通過安全通道,OpenFlow交換機可以和控制器建立基於OpenFlow協議的連接;而流表則用來匹配OpenFlow交換機收到的報文;組表用來定義流表需要執行的動作。

                                                                      SDN控制器與Openflow交換機通信

1、流表:

      流表包括包頭域(header fileds,匹配包頭多個域)、活動計數器(counters)、0 個或多個執行行動(actions)。對每一個包進行查找,如果匹配則執行相關策略,否則通過安全通道將包轉發到控制器,控制器來決策相關行爲。流表項可以將包轉發一個或者多個接口。

                                                                      OpenFlow協議所支持的三種消息類型

openflow協議格式

(1)匹配域:

  • 一層:交換機入端口(Ingress Port)
  • 二層:源MAC地址(Ether src)、目的MAC地址(Ether dst)、以太網類型(EtherType)、VLAN標籤(VLAN id)、VLAN優先級(VLAN priority)
  • 三層:源IP(IP src)、目的IP(IP dst)、IP協議字段(IP proto)、IP服務類型(IP ToS bits)
  • 四層:TCP/UDP源端口號(TCP/UDP src port)、TCP/UDP目的端口號(TCP/UDPdst port)OpenFlow協議所支持的三種消息類型
  • (2)計數器(counter)

  •          計數器可以針對每張表、每個流、每個端口、每個隊列來維護。用來統計流量的一些信息,例如活動表項、查找次數、發送包數等。

  • (3)行動(actions)

            Openflow1.0提供兩種數據包的處理方法:
               • 轉發(Forward)
               • 修改包頭(Modify field)

                其中修改包頭包括:
             SET_VLAN_VID      //修改VLAN標籤
             SET_VLAN_PCP     //修改VLAN優先級
             STRIP_VLAN          //彈出VLAN標籤
             SET_DL_SRC          //修改源MAC地址
             SET_DL_DST          // 修改目的MAC地址
             SET_NW_SRC          // 修改源IP地址
             SET_NW_DST            //  修改目的IP地址
             SET_NW_TOS           //修改IP服務類型字段
             SET_TP_SRC             //修改源端口號
             SET_TP_DST          // 修改目的端口號

  •  以上每一種操作稱爲一個動作(Action),流表中的數據包處理方法是一個動作列表(Action List),動作列表由以上各種動作組合合成。

  在Actions頭,包括Type和len字段:(數據結構如下)

 由output類型的數據結構可以看出Port選項:

           ALL:將數據包從除入端口以 外其他所有端口發出
           CONTROLLER:將數據包發送給控制器
           LOCAL:將數據包發送給交換機本地端口
           TABLE:將數據包按照流表匹配條目處理
           IN_PORT:將數據包從入端口發出
           NORMAL:按照普通二層交換機流程處理數據包
           FLOOD:將數據包從最小生成樹使能端口轉發(不包括入端口)

OpenFlow的建立:

  • OpenFlow連接建立後,控制器最需要獲得交換機的特性信息,交換機的特性信息包括交換機的ID(DPID),交換機緩衝區數量,交換機端口及端口屬性等等。控制器向交換機發送Features Request消息查詢交換機特性,Features Request消息只包OpenFlow Header。交換機在收到Features Request消息後返回Features Reply消息, Features Reply消息包括Openflow Header 和Features Reply Message。

  • 以下爲Request和Reply報文:

  • Packet‐in事件(交換機接收數據包)
             Packet‐in消息觸發情況1:
            當交換機收到一個數據包後,會查找流表,找出與數據包包頭相匹配的條目。如果流表中有匹配條目,則交換機按照流表所指示的action列表處理數據包。如果流表中沒有匹配條目,則交換機會將數據包封裝在Packet‐in消息中發送給控制器處理。此時數據包會被緩存在交換機中等待處理。

  •   Packet‐in消息觸發情況2:
            交換機流表所指示的action列表中包含轉發給控制器的動作(Output=CONTROLLER)。此時數據包不會被緩存在交換機中。

  • Reason爲packet‐in事件產生的原因

  • 以下爲Packet-in報文:

  •  

  • 以下爲packet-out報文:

  • 並不是所有的數據包都需要向交換機中添加一條流表項來匹配處理,網絡中還存在多種數據包,它出現的數量很少(如ARP、IGMP等),以至於沒有必要通過流表項來指定這一類數據包的處理方法。此時,控制器可以使用PacketOut消息,告訴交換機某一個數據包如何處理。

  • 控制器配置流表(Flow‐Mod消息)

  • 當交換機收到一個數據包並且交換機中沒有與該數據包匹配的流表項時,交換機將此數據包封裝到Packet‐in消息中發送給控制器,並且交換機會將該數據包緩存。
    控制器收到Packet‐in消息後,可以發送flow‐mod消向交換機寫一個流表項。並且將flow‐mod消息中的buffer_id字段設置爲packet‐in消息中的buffer_id值。從而控制器向交換機寫入了一條與數據包相關的流表項,並且指定該數據包按照此流表項的aciton列表處理。

  •  

  •  

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章