以 OpenFlow 技術為核心的軟體定義網路（SDN）框架具有集中控制的功能能夠自己感知網路拓撲的變化，在細粒度的路徑選擇、接入控制、負載均衡方面有著天然的優勢，為 IPv6 組播功能的實現提供了好的解決方案。

一、背景

隨著網際網路的迅猛發展，諸如影片直播、網路教學等實時業務的廣泛應用，多個接收者需要同時從一個或多個源節點接收相同的流媒體資料，網路傳輸的資訊容量大大增加，佔用大量的網路頻寬。對這些應用需求，傳統的點播技術，不僅對源節點資源和網路頻寬的消耗很大，同時使用者數量的擴充套件受到限制。比較而言，組播是一個很好的傳輸方案。由於傳統網路中路由器需要預先配置，然後才可以動態支援組播訂閱者的加入、離開操作和組播樹的生成操作，並且傳統網路中的路由器沒有針對使用者對頻寬的大需求來動態選擇傳輸路徑，很容易造成鏈路擁塞，不能夠為使用者提供較好的服務質量，難以在傳統網路中大規模部署。

以 OpenFlow 技術為核心的軟體定義網路（SDN）框架具有集中控制的功能，能夠自己感知網路拓撲的變化，在細粒度的路徑選擇、接入控制、負載均衡方面有著天然的優勢，為 IPv6 組播功能的實現提供了好的解決方案。為了解決 SDN 網路下的 IPv6 組播問題，提出了在 SDN 控制器中設計組成員管理、頻寬拓撲維護、組播樹的構建三個功能模組，不再需要部署分散式的組播路由協議。

二、SDN簡介

SDN 是來源於史丹佛大學的 Clean Slate 專案組，他們有一個宏偉的目標，就是要重造因特網，改變現有的僵化的網路架構模式，以求建立一個可擴充套件的高效能的現代化網路架構。2009年，SDN 概念入圍 Technology Review 年度十大前沿技術。 2012 年 4 月，ONF組織釋出了 SDN 白皮書，提出了一種類似於作業系統的思想:把網路中的所有網路裝置當成被管理的資源，控制器相當於一個作業系統，管理這些資源。這個控制器抽象網路裝置，對網路裝置進行維護，並把這些網路裝置資訊提供給上層應用。上層應用透過統一的可程式設計的介面來對這些網路裝置進行配置和管理，實現相關的網路應用功能，不用再去關心底層的網路拓撲的變動。提出了 SDN三層模型(物理裝置層、控制層、應用層)獲得了業界廣泛認同。

在 SDN 網路的實踐方面，OFELIA、Internet2、FIRE和 GENI等科研組織在真實環境中部署了 SDN 網路。華為、銳捷、思科、Pica8 等廠商積極投入人力、物力進行研究，研發出支援 OpenFlow 協議的 SDN 控制器或 SDN 交換機。在 SDN 網路的企業部署方面，Google 把基於 OpenFlow 技術的 SDN 網路大規模部署在資料中心，使網路資源利用率得到了顯著提高並且降低了網路運維的複雜度。

SDN的網路架構圖如下所示：應用層主要是完成使用者意圖的各種上層應用程式，對網路資源的統一管理。控制層的核心功能是實現網路內部交換路徑計算和邊界業務路由計算、流表控制和下發等功能。轉發層主要由交換機之間的鏈路構成基礎轉發網路。轉發過程中所需要的轉發表項是控制器下發的流表，交換機依據流錶轉發，本身不具有邏輯判斷功能。

(SDN網路架構圖)

三、ONOS控制器

SDN 控制器對整個 SDN 網路架構的效能有著決定性的作用。目前，已經有二十多種由不同語言、不同機構研發的控制器，特別是開源社群提供了很多的控制器，如Nox,RYU,Floodlight,OpendayLight,ONOS等。其中，ONOS控制器是第一款面向運營商的商業級別控制器。支援多種南向介面協議，抽象遮蔽了協議差異性，以高可靠性和高可用性著稱，更適合運營商場景。ONOS的設計高度層次化、模組化、抽象化。ONOS的核心是由很多遵循同一架構設計的子系統組成的，核心層在設計上遵循“針對介面程式設計，不針對具體實現程式設計”的物件導向設計原則，將子系統提供的服務功能抽象成介面，呈現給頂層的應用和底層的協議外掛。子系統的結構如下圖所示。

(ONOS控制器子系統結構)

• App Component：應用程式透過AdminService和其他服務介面聚合訊息，被Manager Component使用和操作。  

• Manager Component：對網路的抽象，是協議無關的，對上提供統一的北向介面。主要包括Manager和Store，Store則負責資料的儲存，查詢，更新以及東西向同步等，所有來自Manager中與資料相關的操作都會透過Store來完成。Manager也會將Store中的事件丟擲並實現ListenerService介面，其它應用透過ListenerService介面即可實現事件的監聽。

• Provider Component：Provider是協議相關的，主要為核心層提供抽象的資料型別，Provider透過核心層提供的ProviderService介面向核心層注入網路資訊，Provider也會暴露Provider介面給核心層，接收來自核心層的command訊息。每個Provider需要在ProviderRegistry進行註冊，才能被ProviderService識別。

四、架構實現

在ONOS控制器的適配層、核心層和應用層開發實現IPv6組播功能。包括適配層對交換機埠狀態的維護；核心層對訂閱者資訊和訂閱者直連交換機資訊的維護；應用層對組播路徑選擇的維護。架構實現圖如下圖所示。  

(實現架構圖)

頻寬拓撲介面卡元件實現對交換機及其埠狀態的維護，OpenFlowDeviceProvider類是ONOS控制器中已經存在的交換裝置抽象類，但沒有提供獲取實時埠頻寬的方式。為了獲得實時的埠可用頻寬資訊，在OpenFlowDeviceProvider類中設計了PortStatsCollector類。

組成員管理元件需要實現對組播訂閱者的維護和訂閱者端交換機資訊的維護，並通知組播選路模組給組播訂閱者選擇路徑。組成員管理元件的實現依賴裝置管理子系統、資料包管理子系統、主機管理子系統，該元件由組播訂閱者資訊維護和訂閱者端交換機維護兩部分組成。

組播選路元件，當有組播訂閱者加入組播組時，組播選路元件要依據當前的網路拓撲和鏈路頻寬資訊為組播訂閱者選擇傳輸路徑，並且要考慮組播訂閱者是新加入一個組播組還是加入一個已經存在的組播組，針對兩種這兩種情況有不同的選路演算法。如果是新加入一個組播組，則組播流量是從組播傳送端傳送給接收者的；如果是加入已經存在的組播組，則組播流量是從轉發組播流量的交換機多埠複製轉發過來的。

五、實驗結果

資料平面用Mininet模擬器模擬6臺交換機，Mininet在Mininet模擬器中透過xterm命令開啟三個主機是一個能夠建立包含虛擬主機、交換機、控制器和鏈路的網路平臺模擬器，Mininet主機執行的是標準的Linux網路軟體，Mininet的虛擬主機、交換機、鏈路和控制器是由軟體建立，使之看起來像一個完整的網路。在Mininet模擬器中透過xterm命令開啟三個主機，給組播傳送端配置的IPv6地址為fc00::1/64，兩個訂閱者配置的IPv6地址為fc00::2/64和fc00::3/4。三個主機分別執行各自的接收組播流量的程式，輸出接收組播流量的來源和接收時間。實驗結果如下圖，兩個訂閱者可以同一時刻能收到相同的資料。

作者：李丹

來源：宜信技術學院