一種面向SDN 的傳統網絡功能集成方法設計與實現

鄭友偉，朱曉東，劉 磊，鄭 策

（1.中國科學院聲學研究所國家網絡新媒體工程技術研究中心，北京 100190；2.中國科學院大學，北京 100049）

軟件定義網絡(SDN)[1-3]通過實現控制平面和數據平面的分離推動了網絡業務和應用的部署和發展。在SDN 網絡中，開發人員調用控制器的北向API 開發網絡應用，實現相應的網絡功能或者業務需求。對于像DHCP 中繼[4]、動態路由[5]等傳統網絡功能，目前已經存在了非常成熟的第三方網絡組件，如果能夠設法借助這類第三方組件將網絡功能集成到控制器上，將會大大簡化傳統網絡應用的開發。

RouteFlow[6]項目為了能實現在二層交換機上完成三層路由的功能，采用了虛擬路由器與交換機一一映射的方式。Quagga[7-8]路由引擎運行在虛擬路由器上，完成路由的計算。B4 控制器[9]同樣集成了Quagga 實現了分布式路由；另一種方案提出在由多個ONOS 控制器[10]組成的集群中，使用SDN-IP 被動式路由，以提供高可用性服務。Click 項目[11]以類似運算集群的設計使得可操作性比較強。L3Routing[12]則將整個網絡拓撲抽象成一臺路由器，相當于對拓撲內部的特性進行了一定程度地封裝。

上述技術方案基本上都是針對某一特定網絡功能，如動態路由功能實現的集成方法，不能兼容其他傳統網絡功能。該文設計與實現了一種通用的傳統網絡功能集成方法，該方法的核心是創建了與交換機端口具有一一映射關系的TAP 虛擬設備[13]，TAP虛擬設備與交換機端口網絡配置完全相同。通過該方法可以便捷地將傳統網絡功能集成到網絡應用上，且適用于多種傳統網絡功能。該方法大大簡化了傳統網絡應用的開發，且該方法不拘泥于特定控制器，適用于多種類型的控制器。

1 通用集成方法設計與實現

該方法將底層網絡流量通過流量代理程序同步給服務器或虛擬化容器中的第三方網絡組件，由第三方網絡組件完成核心的網絡功能。流量代理程序將需要發送的流量發送回APP。流量代理程序是控制器APP 和第三方網絡組件之間的橋梁，負責在APP 和第三方網絡組件之間傳遞網絡流量。該方法的關鍵技術是創建了與真實交換機端口一一對應的TAP 虛擬設備，TAP 虛擬設備與交換機端口網絡配置完全相同。網絡流量代理程序讀寫TAP 虛擬設備。第三方組件工作于TAP 虛擬設備，通過該方式完成流量的同步與網絡功能的實現。可以通過虛擬化容器docker[14]承載該功能模塊，并在K8S[14]環境中部署，通過K8S 環境對第三方組件容器進行管理，其工作原理如圖1 所示。

圖1 第三方組件集成方法工作原理

網絡流量代理程序工作程序如算法1 所示，程序首先構建TAP 虛擬設備，用于映射真實交換機的端口，與真實交換機端口為一一對應關系。TAP 虛擬設備是相對獨立的虛擬網絡設備，其模擬了以太網設備，可以操作二層數據包（以太幀）。使用TAP虛擬設備的目的是把來自協議棧的數據包先交給某個打開了/dev/net/tun 字符設備的用戶程序進程處理，還可以選擇把數據包重新發回到鏈路中。可以將虛擬化網卡驅動理解為一端連接著網絡協議棧，另一端連接著用戶態程序，而普通的網卡驅動則是一端連接著網絡協議棧，另一端連接著真實物理網卡。

該文設計了一套基于UDP 的自定義協議，用于規范APP 與網絡流量代理之間的通信，自定義協議的報文結構如圖2 所示，自定義協議頭部包含三個字節：前兩個字節記錄device_id，第三個字節記錄port_id，該協議頭完成了TAP 虛擬設備與底層交換機端口的映射關系，該映射關系由APP 進行維護，網絡流量代理程序按照預設規則進行協議頭與TAP 虛擬設備的轉換，并完成對TAP 虛擬設備的讀寫。具體工作機制主要涉及pkt-in 數據包處理流程以及pkt-out數據包生成和發送流程。

圖2 自定義協議報文結構

pkt-in 數據包處理流程：交換機接口接收到網絡中的數據包，根據流表匹配結果將相關協議的數據包以pkt-in 消息上報到控制器，控制器按照訂閱匹配規則將數據包上送給對應的APP。APP 接收到數據包后，根據pkt-in 消息的交換機DPID 及接收端口來設置UDP 數據包的自定義協議頭，然后將數據包放入載荷，通過Socket 編程[15]，以UDP 通信的方式將數據包發送給網絡流量代理程序。網絡流量代理程序接收到數據包，根據數據包中自定義協議頭的device_id 和port_id 選取TAP 虛擬設備，將載荷寫入TAP 虛擬設備。第三方網絡組件通過TAP 虛擬設備接收到網絡數據包，并進行相應處理。

pkt-out 數據包處理流程：第三方網絡組件完成對數據包的處理需要發送網絡數據包，將數據包寫入TAP 虛擬設備。網絡流量代理程序通過TAP 虛擬設備接收到網絡數據包，將網絡數據包封裝成UDP 數據包發送給APP。APP 解析自定義協議報文頭部，根據所維護的映射狀態查找到對應的交換機DPID 及發送端口，依據這些信息封裝pkt-out 數據包，并將數據包載荷填入pkt-out 數據包中，將pkt-out 數據包下發給交換機。交換機依據pkt-out 數據包將對應數據包從指定網絡端口發送出去。

2 網絡應用設計與實現

基于ONOS 控制器，利用該集成方法編寫一款通用的傳統網絡應用，用于與交換機和第三方組件模塊的交互。代碼如算法2 所示：

APP 主要完成了以下工作：

1）給控制器所連設備下發對應應用的相關表項。

2）訂閱相關表項的pkt-in 消息。

3）處理pkt-in消息。根據pkt-in消息的device_id和port_id 將pkt-in 的數據部分封裝成自定義協議類型的數據包，然后發送給網絡流量代理程序。

4）監聽UDP4720 端口，接收從網絡流量代理模塊發來的數據包，解析數據包。根據device_id 和port_id 生成對應的pkt-out 數據包，并將其下發到對應的交換機，交換機依據pkt-out 數據包正確地轉發數據包。

3 功能性驗證

該文通過集成DHCP Relay 功能對該集成方法進行了功能性驗證。搭建了如圖3 所示的測試環境，測試拓撲由ONOS 開源控制器、基于DPDK[16]的POF 交換機[17]、DHCP 服務器和一臺測試主機構成。在ONOS 上部署使用了該集成方法的通用APP。主機連到交換機的0 號端口，DHCP 服務器連到交換機的1 號端口，控制器和交換機之間通過6643 端口進行通信。網絡流量代理程序也運行在交換機所在的服務器上。網絡流量代理程序和APP 采用基于UDP的自定義協議進行通信[18]。

圖3 測試環境

3.1 測試步驟

1）在一臺LINUX 服務器上安裝DHCP 軟件包用作DHCP 服務器。服務器地址為192.168.8.250。地址池分配如下：

2）將測試主機IP 地址獲取方式設置為DHCP獲取。

3）啟動控制器APP。

4）在192.168.200.2 服務器上啟動流量代理程序和DHCP Relay 功能。如圖4 所示，DHCP Relay 功能啟動后開始監聽tap0 和tap1 端口。

圖4 DHCP Relay啟動過程

3.2 測試結果

如圖5 所示，測試主機已經成功分配到了IP 地址。交換機抓取到的pkt-out數據包如圖6 所示。

圖5 測試主機分到的IP地址

圖6 交換機收到的pkt-out數據包

4 結束語

為了簡化SDN 控制器傳統網絡功能應用的開發過程，該文設計與實現了一種通用的傳統網絡功能集成方法，通過網絡流量代理程序將需要處理的流量同步到第三方網絡組件，第三方網絡組件工作在與交換機端口具有一一映射關系的TAP 虛擬設備上。該方法旨在借助第三方網絡組件實現傳統網絡功能，降低傳統網絡應用開發復雜度。文中基于ONOS 控制器，利用該集成方法開發了一款通用的傳統網絡應用。并通過集成DHCP Relay 功能對該方法進行了功能性驗證。不局限于某一特定網絡功能，該集成方法對于路由等其他傳統網絡功能同樣適用，且無關于控制器類型。未來將通過Docker 承載第三方組件模塊，并在K8S 環境中部署。