技術探索

以應用代理技術實現支援軟體定義網路之解決方案

中文摘要

  軟體定義網路(SDN)技術藉由集中式管理與控制架構, 可提供應用服務可程式化之管控彈性,以及網路資源使用效率之提升,目前已成為網路產業公認之技術發展趨勢。然而現今之接取網路(Access Network)設備仍然是傳統的分散式管理架構, 因應如何協助接取網路支援SDN之議題,本文中提出一個代理技術架構 (Proxy-based)方案,並以接取網路技術中的GPON 網路系統為例,說明其在支援SDN管控時會遭遇的議題,以及如何實現支援SDN之解決方案。

Abstract

  The software-defined network (SDN) technology, by the centralized management architecture of the network, would allow networks to be run in a more flexible and efficient manner, e.g., by increasing network resource utilization. In recent years, SDN is well recognized as the network technology trend. Besides, the legacy access network devices were still managed by the distributed management architecture. In this paper, we proposes a proxy-based solution for the access network to support SDN, and choose the GPON network systems to illustrate their SDN supporting problems,and also describe how to implement the solution.

關鍵詞(Key Words)

軟體定義網路(Software Define Network;SDN)
被動式光纖網路(Passive Optical Network;PON)
光纖網路終端管理控制介面(ONT Management Control Interface;OMCI)

1. 前言

  近年軟體定義網路技術(Software Defined Network)蓬勃發展,並隨著Google、Verizon、AT&T和NTT等網路巨擘發表各式成功案例,引發網路產業掀起SDN討論熱潮,根據國際市調機構IDC (International Data Corporation)分析[1]預測指出:全球之SDN的市場規模將從2014年的9.6億美元迅速成長,到2018年將超過80億美元,其複合年成長率(CAGR)為89.4%,顯示SDN 技術如今已成為網路產業普遍接受的重要趨勢。

  SDN 網路技術[2] 為藉由集中式控制器(SDN Controller)將傳統分散式的網路控制架構轉為集中式控管架構,可有效提升網路使用效率以及具備靈活管控之彈性,其核心精神為提供整體網路之虛擬抽象化、與應用服務可程式化,並由應用程式提供更多的網路服務與管理。然而目前主要佈建之接取網路(Access Network) 設(e.g. GPON 、xDSL & Legacy Ethernet Switch),仍然是以傳統的分散式管理架構為主,因此如何將現今接取網路設備導入SDN化管理,以獲得應用服務與網路資源可程式化管控之優點,將會是各網路營運商將面臨之實際難題。

  由於GPON網路架構為現今最普遍之光纖到府(Fiber to The Home)接取網路架構技術,在本文中將以GPON網路系統為例,就如何將傳統接取網路設備導入SDN管理之議題,提出以代理技術(Proxy-based Solution)實現SDN化之解決方案。以下第二章節將說明GPON 網路系統在進行SDN化可能遭遇到之問題,隨後第三章節將說明實現SDN化之主要Openflow Proxy模組架構、運作模式以及內部設計方式,文末將說明本架構實際驗證測試之結果。

2. 接取網路SDN化之問題與作法

2.1 傳統網路設備SDN化的作法

  支援SDN Openflow標準規格[3~5]之交換器IC主要架構如( 圖1)所示,其中有別於傳統交換器架構之處主要為晶片當中新增許多資料流表(Flow /Group /Meter Table),資料流表由SDN Controller[6]管理,流經交換器之各資料流將藉由查詢相關表單以決定資料流封包之流出埠或因應處置方式。

圖1 Openflow Switch 晶片功能架構示意圖圖1 Openflow Switch 晶片功能架構示意圖

  因此,若傳統網路設備要進行SDN化及支援Openflow 協定,若可變更硬體設計的話,可將系統中的交換晶片換成Openflow Switch 晶片。但若不希望變更硬體架構時,則必須在系統軟體中加入處理關於資料流表(Flow/Group/Meter Table)以及Packet-In等功能,例如:市面部分廠家之Wifi AP或傳統交換機,可藉由加入OpenWRT韌體或移植Open vSwitch軟體套件以支援Openflow協定成為SDN交換設備。

2.2 GPON網路SDN化之問題與解決方案

  在GPON 網路管理標準ITU-T G.984.4/G.988 中定義了OMCI (ONT Management Control Interface)協定, 其中規範可由GPONOLT(Optical Line Terminal)主動以OMCI協定ONU(Optical Network Unit)發起下列的服務管理配置:

  1. 建立/ 釋放OLT 與ONU 間的GEM(GPON Encapsulation Method)連接。
  2. 配置應用服務之VLAN組態[7]及UNI(User–Network Interface) 的管理。
  3. 收集效能統計值。

然而,在SDN相關標準中並未有相對應之管理做法,因此若要將GPON納入SDN管理必須再行設法加入相關功能以利管理。


  此外,由於本計畫使用之GPON OLT平台為使用傳統交換器晶片,並無支援Flow資料流表,且無法由硬體支援Openflow的匹配欄位(Match Field),因此若要於GPON OLT平台上實做Packet-in以及相關資料流表,則需將所有進入OLT系統的封包皆轉送給OLT平台上之CPU來處理,此方法將造成CPU負荷大量的運算,也會造成大幅降低GPON傳輸效能。

  在此本文將提出一種Openflow代理架構方案(Openflow Proxy),能在不更動設備的硬體架構下,將傳統的GPON設備納入SDN管理,且此架構並不需要額外的修改SDN Controller管理模組,即可將傳統GPON網路虛擬為一台SDN交換機便於接受SDN Controller管控, 使GPON網路能夠得到SDN網路高彈性與自由化管理的好處,並可將Network Slicing等SDN應用服務延伸至接取網路(Access Network)。

3. Openflow Proxy架構與運作流程

3.1 Openflow Proxy 架構

  若要將GPON網路納入SDN管控,可進行硬體更新,將GPON OLT的傳統交換晶片更換為支援SDN Openflow的交換晶片即可,但如此一來將大幅增加營運成本。在此本文提出Openflow Proxy之方法,在不更動GPON硬體的前提下,僅利用GPON的管理介面,來達成將GPON納入SDN管理的目的。   在此GPON Openflow Proxy 為將原有GPON OLT-ONU 網路,再加上其前級支援SDN 之Openflow Switch之架構,共同虛擬化為一台支援SDN 之Virtual Switch如(圖2),利用前級SDN Switch來達成Packet-In Event回報與接受資料流表設定,使GPON網路系統能夠納入SDN Controller管理,讓GPON網路系統加入軟體定義網路中。

圖2 GPON SDN Virtual Switch架構示意圖 圖2 GPON SDN Virtual Switch架構示意圖

  Openflow Proxy模組為在GPON OLT系統軟體的Linux Operating System上開啟一個Socket Daemon,負責轉送SDN Controller 與Openflow Switch之間的控制命令,主要需求的功能為:

  1. 收送OpenFlow Switch與SDN Controller間的控制訊息,並修改欄位資料使得Virtual Ports訊息能正確傳送至SDN Controller與OpenFlow Switch。
  2. 利用OLT Management API 將PON-Port Status轉換為Virtual Port Status並傳送至SDN Controller。
  3. Openflow Proxy亦負責處理Controller發出的Statistic Request控制命令,透過OLT管理系統取得虛擬埠的封包遞送數據資料,傳送回Controller以提供各種管理演算法(e.g. Load Balancing、QoS)計算使用。

  Openflow Proxy軟體模組的設計主要分為三個部份(圖3),其中Control Channel模組(包含Command Parser & Dispatcher) 之功能為依照OpenFlow Specification 的規定,處理OpenFlow Ports ,OpenFlow Control Channel 與OpenFlowSwitch Protocol所規範的控制訊息交換,並且改寫相關訊息欄位資料,以達成ONU Ports虛擬化。

  Virtual Port模組為用於溝通資料庫系統,在Control Channel 模組接收或需要發送控制訊息時,能夠轉譯、改寫埠號欄位資料,使得ONU Ports能夠正確匹配VLAN Tag[8]達成Virtual Ports的效果。

  Traffic Manage 模組則是用來溝通ONU Management API,透過模組間溝通即時傳遞虛擬埠的連線狀態,並進行GPON網路相關管理設定。

圖3 GPON OLT OpenFlow Proxy模組圖圖3 GPON OLT OpenFlow Proxy模組圖

3.2 Control Channel模組

  本模組主要功能為維護與轉送OpenFlow Control Message,並解析封包控制訊息種類,以呼叫對應的Management API進行處理。( 圖4)為Control Channel 操作Switch 與Controller連線之狀態圖, 當Proxy 啟動後,連線狀態為Not Ready,此時在作業系統核心開啟端口準備接受OpenFlow Switch發起的連線。當收到Switch傳來的連線封包後,Proxy會改寫控制訊息的目的欄位,將控制訊息轉送給SDN Controller。當成功完成OpenFlow Hello訊息交換後,模組進入Proxy Ready狀態,開始偵測端口接收的控制訊息並解析訊息種類,處理並更改欄位資料後,轉送資料訊息完成一個處理循環。

圖4 Control Channel模組狀態圖圖4 Control Channel模組狀態圖

3.3 Virtual Port模組

  GPON SDN Virtual Switch的目標是將各個ONU虛擬化為一般交換器之埠口,在不影響GPON的功能下,讓SDN Controller能夠直接將GPON 系統視為單一OpenFlow Switch 納入控制器管理中。本模組依照不同的控制訊息修改所傳送的控制訊息欄位,將Virtual Port對應到正確的VALN Tag使SDN Controller 與OpenFlow Switch能在不做任何修改的狀態下完成虛擬化的功能。(圖5)為Virtual Port模組流程圖,依照OpenFlow Protocol所定義的控制訊息分別處理封包欄位。   原本OpenFlow Switch送往SDN Controller的封包中,埠號必定為連接GPON OLT的埠,且會帶有OMCI規範所需求的VLAN Tag,為了達成GPON SDN Virtual Switch的目標,本模組將封包內的埠號欄位修改為VLAN Tag所代表的虛擬埠號,使得SDN Controller能夠忽略此機制,直接將GPON視為普通OpenFlow Switch,反之亦然。另外,須額外處理的是Port Modify與Multipart相關Openflow指令中的Port States控制訊息,SDN Controller所設定與查詢的埠應為ONU 的實體埠,因此必須改為向OLT Management 模組查詢OMCI 實體埠之相關設定,並將結果送回SDN Controller。

圖5 Virtual Port模組流程圖圖5 Virtual Port模組流程圖

3.3 Traffic Manage模組

  當GPON SDN Virtual Switch啟動時,本模組會溝通ONU Management API,監控ONU設備啟用與脫離狀態,用以發送OpenFlow Port Status Message。本模組會為已完成Ranging的ONU建立Traffic通道,並且自動尋找VLAN Tag做為虛擬埠號,另外,在收到ONU Deactivate或Disable訊號時釋放VLAN Tag。(圖6)為本模組運作時序圖,在ControlChannel管理模組收到ONU 設備變動訊息後,便會呼叫本模組,進行VLAN Tag管理與Traffic通道啟用。

圖6 Traffic Manage模組時序圖圖6 Traffic Manage模組時序圖

4. Openflow Proxy 實作與測試驗證

  在此實作上乃採用符合ITU-T G.984規格之GPON OLT與GPON ONU設備,並以OLT網管系統軟體進行GPON OLT與GPON ONU的配置和啟動,提供GPON網路服務( 圖7)。在此前級所使用的OpenFlow Switch型號為Pica8 P-3290,PicOS版本為2.0.4,內含Open vSwitch 1.10.0版本。所使用的SDN Controller為OpenDaylight Hydrogen 1.0,作業系統版本為Ubuntu 12.04。

  Openflow Proxy執行後,會接受前置的Openflow Switch連線,並依照第三節敘述修改相關資料欄位並傳送至SDN Controller,且在ONU 向OLT 註冊完成後配置應VLAN 完成GEM連結,並向SDN Controller發送Port_status控制訊息通知Controller虛擬埠開啟。當ONU端傳送的封包首次送到Openflow Switch時,Openflow Proxy可藉由L2封包標頭中的VLAN Tag,將Packet-in控制命令中的來源埠( Source Port) 轉換為GPON虛擬交換機的虛擬埠號,並轉送給SDN Controller,以提供GPON Virtual Switch的Packet-in控制命令。相同的當SDN Controller的演算法決定出路由規則後,Proxy也可將資料流(Flow Entry)中的虛擬埠號轉換為Openflow Switch能夠處理的實體埠號並貼上正確的VLAN 標籤, 成為符合GPON Virtual Switch的資料流,藉此資料流設定管控GPON 傳遞或棄置封包。藉由Port_status 、Packet-in與Flow Entry實現可把整個GPON網路系統納入SDN控制器管理。

  當完成架設設定GPON OLT/ONU 、OF Proxy 與Pica8 SDN Switch 所組成之SDN-Enabled Virtual Switch ,並與SDN Controller 完成連線後,可由OpenDaylight Controller之GUI呈現Virtual Switch 相關Network Topology(圖8),並且可由OpenDaylightController介面下達Add flow-entry控制指令,即可看到客戶端影片播放進行,稍後可下達Delete flow-entry指令,即可看到客戶端影片播34 ICT Journal No.161放中斷,由此可展現本GPON SDN Virtual Switch 可由SDN Controller 所控管。

5. 結論

  在本文中說明了傳統接取網路(以GPON網路系統為例)要支援SDN管控時會遭遇的問題,並提出Openflow Proxy之解決方案,達成在不更動傳統GPON硬體,僅藉由Openflow Proxy模組與OLT管理介面互動取得ONU資訊與相關VLAN設定,即可將傳統GPON網路納入SDN管控。

  由於Openflow Proxy僅需利用傳統網路設備的管理介面( e.g. OMCI、SNMP、CLI)取得交換埠資訊,並且利用VLAN做虛擬與實體埠號映射,即可將傳統網路設備納入SDN之管控。因此,Openflow Proxy如何更進一步整合傳統接取網路設備(如:xDSL,Legacy Ethernet Switch),以及處理較為複雜之網路拓譜情境,將是未來可繼續研究的課題。

計畫相關資訊

本文係工研院資通所執行經濟部FY103「智慧化光纖寬頻網路技術」計畫之分項計畫「SDN-Enable接取網路管理技術」成果之一。

參考文獻

  1. International Data Corporation (IDC),http://www.idc.com/getdoc.jsp?containerId=prUS25052314
  2. Open Networking Foundation (ONF),https://www.opennetworking.org/
  3. ONF Specification, “OpenFlow Switch Specification 1.0.0,” Dec 2009.
  4. ONF Spec., “OpenFlow Configuration and Management Protocol 1.1.1,” Mar 2013
  5. ONF Specification, “OpenFlow Switch Specification 1.3.3,” Oct 2013.
  6. Opendaylight Controller,https://wiki.opendaylight.org/view/OpenDaylight_Controller:Overview
  7. IEEE Std. 802.1D-2004 Media Access Control (MAC) Bridges
  8. IEEE Std. 802.1Q-2011 Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks

作者簡介

洪一夫

現任工業技術研究院資訊與通訊研究所寬頻網路與系統整合技術組副工程師,國立中正大學通訊工程研究所碩士,研究專長領域為:通訊系統軟體技術、網路最佳化、SDN相關議題等。 E-mail: oliverhef@itri.org.tw

楊明曉

現任工業技術研究院資訊與通訊研究所寬頻網路與系統整合技術組工程師,國立成功大學機研所控制組碩士,研究專長領域為:通訊系統軟體技術、嵌入式系統軟體整合術、系統控制技術等。 E-mail: yangmh@itri.org.tw