SDN控制平面功能模塊化研究

侯 文，陳 佳，王洪超

(北京交通大學 電子信息工程學院 下一代互聯網互聯設備國家工程實驗室，北京 100044)

SDN控制平面功能模塊化研究

侯 文，陳 佳，王洪超

(北京交通大學 電子信息工程學院 下一代互聯網互聯設備國家工程實驗室，北京 100044)

隨著網絡規模的加大，網絡節點不斷增多，網絡中需要進行管控和處理的數據也就越多，因此對控制平面的數據處理能力的要求也越來越高。如果控制平面只有一個集中的控制器來完成工作，其處理能力有限，在面對大規模復雜網絡時，必將產生系統性能瓶頸。為了解決這一問題，提出了一種新的控制平面設計方案，即功能模塊化控制平面。功能模塊化控制平面將控制器內部按照功能劃分成不同的子功能模塊，各子功能模塊能夠獨立部署，統一進行調度，對外實現邏輯集中化，內部又可以實現靈活擴展，進一步提高控制器的靈活性、可靠性以及整體性能。研究了功能模塊化控制平面的總體模型設計和通信機制，最終通過搭建拓撲對功能模塊化控制器進行測試，驗證了該方案的可行性和有效性。

軟件定義網絡；控制平面；功能模塊化；靈活部署

0 引 言

隨著網絡的不斷發展，傳統網絡的體系架構已經越來越難以滿足對通信的“高速”、“高效”、“海量”的迫切需求，并且在可擴展性、安全性、移動性等方面暴露出嚴重不足。面臨這一現狀，對現有網絡進行微小的改變已經不足以解決所有問題，因此需要一種全新的網絡架構來綜合解決當前網絡中的眾多弊端[1]。2008年，斯坦福大學的Nick McKeown教授提出了OpenFlow[2]，并逐漸推廣到SDN概念。SDN網絡架構[3]將路由決策控制功能從原有傳統網絡中解耦出來，即實現網絡中控制平面與數據平面的分離，由控制平面掌控網絡的全局信息，實現對網絡的控制，數據平面提供簡單的數據轉發功能。

在網絡規模不龐大時，控制平面所需處理的請求量少，單一集中的控制器可以管理當前網絡。單一控制器的代表有NOX[4]、Beacon[5]等。然而當網絡的規模不斷加大，網絡節點不斷增多，發往控制器的流量也在不斷加大，控制器所需處理和存儲的數據量也就越來越大，而單一集中的控制器處理能力有限，部署不夠靈活，擴展性差，無法管控越來越復雜的網絡。文獻[6-9]介紹了SDN控制器的發展現狀，以及為了解決單一集中控制器所帶來的眾多問題，當前學術界提出的多種SDN控制平面的解決方案，例如采用多控制器架構。多控制器方案代表有如下幾種：一種為去中心化結構，每個控制器的地位相等，如HyperFlow[10]、Onix[11]；一種為分層結構，將控制器分為不同等級，等級越高監控的范圍越大，如Kandoo[12]。采用多控制器方案解決了單一控制器的性能瓶頸問題，但又帶來了新的問題，其中主要包括控制器區域部署問題[13]。例如對于給定的網絡拓撲，如何進行分區，控制器該如何放置，每個控制器管理哪些交換機，等等。除了多控制器部署問題，多控制器方案面臨的主要問題還涉及多個控制器之間該如何通信[14]，以及如何保持全局狀態一致性等[15]。

文中提出了一種新的控制器架構模型，即功能模塊化的控制平面，用于解決單一集中的控制器所面臨的問題。功能模塊化的控制平面將原控制器中的不同功能抽象化，形成單獨的功能模塊，各功能模塊能在不同的網絡組件上進行靈活的部署和擴展，進一步提高控制器功能部署的靈活性和可擴展性。

1 控制平面功能模塊化整體設計

為了提高控制平面部署的靈活性和可擴展性，功能模塊化控制平面架構將原控制器中的不同功能模塊進行抽象化處理，形成單獨的功能模塊，并且部署在不同的網絡組件上。功能模塊化的控制平面主要由以下幾部分組成，其中包括一個控制器主控單元模塊，多個子功能模塊，如網絡拓撲信息模塊、路由計算模塊、轉發組件狀態信息模塊、用戶信息模塊和服務信息模塊。

主控單元模塊主要負責對各個功能模塊的管理和控制，并且主控單元模塊是控制平面和轉發平面之間的接口。主控單元模塊能夠檢測到有哪些功能模塊完成注冊，是否可以正常工作，并能夠協調各子功能模塊之間的工作。同時主控單元模塊能夠負責接收來自轉發平面的消息，并根據消息類型，將不同的消息分配給相應的子功能模塊進行處理。其他各個子功能模塊可以部署在不同的組件上，完成各自的功能，并且各功能模塊擁有自己的計算和存儲資源，實現了控制平面的解耦合。

根據不同需求，實現同一功能的模塊根據需要可能有多個，由主控單元模塊完成任務的分配，共同完成某一任務，減輕單一子功能模塊的處理壓力，使部署更靈活，并且提升了控制平面的整體性能。最終實現控制器主控單元和各子功能模塊之間的協同工作，完成對整個網絡的管控，解決原有單一集中控制器的性能瓶頸和擴展性差的問題。控制平面的功能模塊化設計如圖1所示。

圖1 控制平面總體模型設計

2 控制平面各功能模塊間的通信機制

2.1 控制器內部架構模型

控制器內部主要由主控單元模塊、網絡拓撲信息單元模塊、路徑計算單元模塊、轉發組件狀態信息單元模塊、用戶信息模塊和服務資源信息模塊組成。控制器主控單元主要負責與各個功能模塊間的信息交互，協調各功能模塊的工作，以及與轉發組件之間的通信。控制器主控單元是控制器內部的核心模塊，也是控制器與外部的通信接口。網絡拓撲信息模塊負責實時保存網絡中的拓撲信息，當網絡中有服務請求時，路由計算模塊會根據拓撲信息進行路徑計算，完成資源的適配過程。轉發組件狀態信息模塊負責存儲各個轉發組件的性能狀態信息。用戶信息模塊負責存儲網絡中注冊用戶的信息，包括用戶ID、用戶名稱及用戶權限等。服務資源模塊負責存儲網絡中服務提供者可以提供的服務資源，包括服務ID、域名、服務所需帶寬、權限、類型等。

控制器的主控單元模塊可以抽象為如下模型。主控單元由內部通信接口、外部通信接口、消息處理三部分組成。內部通信接口負責控制器內部主控單元與各功能模塊的消息交互。外部通信接口負責與轉發組件之間的消息交互。消息處理部分會根據內部通信接口與外部通信接口收到消息的類型進行相應處理，是主控單元模塊的核心部分。

每個子功能模塊可以抽象成如下模型。各子功能模塊均由通信接口、消息處理及處理結果反饋幾部分構成。

由通信接口負責接收與發送消息，消息處理部分負責根據不同的消息類型對消息進行相應的處理，如果需要發送消息反饋，則產生相應的反饋消息，由通信接口發送出去。

2.2 控制器內部通信流程

控制器內部通信涉及的消息類型包括功能模塊注冊消息fun_hello，信息查詢與反饋消息feature，鏈路狀態檢測消息echo。消息包格式的設計采用TLV形式，用以區分消息類型和統一消息的格式。TLV:Type類型,Length長度,Value值。類型部分采用主類型和子類型。

控制器內部通信過程如圖2所示。

圖2 控制器內部通信流程

主控單元模塊首先啟動，負責監聽其他功能模塊的連接。當有其他子功能模塊發起連接請求時，主控單元接受連接，與子功能模塊建立通信通道，完成信息的交互。子功能模塊與主控單元模塊建立連接后，子功能模塊主動向主控單元模塊進行注冊，實現功能模塊的靈活加載。子功能模塊發送注冊消息hello_fun給主控單元模塊，hello_fun攜帶功能標識fid，包長度。主控單元模塊可根據hello_fun消息中的功能標識來統計各個類型的功能模塊分別有多少個，并根據鏈路是否通暢來動態維護這一信息，用于實現網絡中有請求時任務的調度和分配。

控制器主控單元模塊收到hello_fun消息后，會向子功能模塊發送信息查詢消息，即feature_request消息，用于查詢子功能模塊的一些基本信息。子功能模塊收到feature_request消息后，向主控單元模塊回應feature_reply消息，用于報告自己的基本信息。feature_reply消息中包含的內容有：功能模塊標識fun_id、模塊名稱fun_name、ip地址、mac地址、port信息、工作狀態信息等。

當主控單元模塊與子功能模塊間的連接建立、注冊等一系列初步工作完成后，控制器整體處于可以工作的待命狀態。當網絡中轉發組件有消息發送給控制器時，控制器會根據消息類型進行相應的處理，實現主控單元模塊和各子功能模塊間的協同工作。當控制器主控單元與子功能模塊的連接通道內沒有消息發送時，主控單元將向子功能模塊定時發送echo請求消息，子功能模塊收到后給主控單元發送echo回復消息，用于檢測二者之間的通信是否通暢。如果在規定時間和echo請求次數內，主控單元模塊沒有收到子功能模塊的echo回復消息，則認為通信鏈路中斷，并將此類功能模塊的個數減一。

2.3 控制器收到不同消息的處理過程

控制器主控單元模塊負責接收由轉發組件轉發來的消息，對接收的消息進行判斷，根據消息類型發送給相應的子功能模塊，由各子功能模塊進行相應的處理。當主控單元收到轉發組件的狀態信息時，將其存入轉發組件狀態信息模塊。當主控單元模塊收到用戶的注冊、注銷或更新消息時，將其發送給用戶信息模塊進行處理。當主控單元模塊收到服務注冊、服務注銷或服務更新消息時，將其交給服務資源信息模塊進行相應的處理。當主控單元模塊收到轉發組件報告的拓撲信息時，將其存入網絡拓撲信息模塊。當主控單元模塊收到服務請求消息時，首先在服務信息模塊中查詢是否有這一服務，如果沒有則返回該服務未提供，服務請求失敗；如果存在這一服務，服務信息模塊向主控單元模塊返回服務查詢成功消息。主控單元模塊向拓撲信息模塊進行查詢，將拓撲信息和服務請求消息發送給路徑計算模塊，由路由計算模塊為該請求計算出一條合理可達的路徑，最終由主控單元模塊下發給轉發組件。

在各子功能模塊注冊階段和鏈路探測階段，控制器主控單元模塊動態感知每類功能模塊的個數，用于實現后續任務的分配。在適當的情況下，通過對多個實現同種功能的模塊的部署，以提高控制平面的整體處理能力，同時也增加了控制平面部署的靈活性。圖3以控制器內部有兩個路徑計算功能模塊為例，展示了控制器收到網絡中的服務請求消息時的工作過程。

圖3 控制器內部處理流程

當網絡中有多個服務請求時，轉發組件把服務請求信息發送給控制器。控制器主控單元模塊接收到服務請求信息，向服務信息模塊進行服務信息查詢，若該服務不存在，返回服務查詢失敗消息；若存在該服務，則服務資源信息模塊返回服務查詢成功消息。

當服務查詢成功時，主控單元模塊查詢拓撲信息，并將拓撲信息和服務請求消息發送給路徑計算模塊。由于控制器內部有兩個路徑計算模塊，主控單元模塊將多個服務請求消息分別發送給路徑計算模塊1和2。兩個路徑計算模塊同時工作，進行路徑的計算，并將計算結果返回給主控單元模塊，由主控單元模塊將路徑下發給轉發組件。若網絡中存在到達該服務的路徑，轉發組件將此請求轉發到對應的服務提供者，并將相應的服務返回給請求的主機。

3 實驗測試

3.1 測試環境

測試過程在圖4所示的拓撲中完成。測試環境包括一臺控制器，三個轉發組件，一臺主機和一臺服務器。

圖4 測試拓撲圖

首先完成對控制器內部通信流程的功能性測試，其次對控制器內部結構的兩種不同情況進行對比測試。第一種情況：控制器內部由一個主控單元模塊、一個拓撲信息模塊、一個路徑計算模塊、一個用戶信息模塊和一個服務信息模塊組成。第二種情況：控制器由一個主控單元模塊、一個拓撲信息模塊、兩個路徑計算模塊、一個用戶信息模塊和一個服務信息模塊組成。

3.2 測試結果

針對圖4所示的拓撲環境，通過wireshark抓包分析結果。抓包結果表明，控制器內部通信過程如下：控制器主控單元模塊首先啟動，各子功能模塊向主控單元注冊，發送注冊消息即hello_fun。主控單元模塊收到注冊消息后，向相應的功能模塊發送狀態信息查詢消息feature_request，子功能模塊收到查詢消息后，向主控單元模塊回復feature_reply，報告自己的相關信息。通過這種機制，實現控制器對其子功能模塊的靈活加載。

當測試拓撲中有多個網絡請求時，轉發平面的交換機將多個服務請求消息發送給控制器的主控單元模塊。主控單元模塊進行服務查詢得到結果服務存在，然后查詢拓撲信息。保持每秒發送的服務請求消息數量相同，對兩種情況的控制器進行對比測試。當控制器內部只有一個路徑計算模塊時，主控單元模塊將全部服務請求信息和拓撲信息發送給路徑計算模塊進行計算。當控制器內部有兩個路徑計算模塊時，主控單元模塊將服務請求消息近似平均分配給這兩個子功能模塊，子功能模塊完成計算后將路徑返回，并由主控單元模塊將路徑下發給轉發組件。對比測試的結果如圖5所示。

圖5 不同控制器的測試結果

從圖5可以看出，當控制器內部只有一個路徑計算模塊時，該模塊要全部完成對服務請求消息的路徑計算，面臨的壓力也相對較大。當控制器內部有兩個路徑計算模塊時，主控單元模塊將服務請求消息進行分流，由兩個路徑計算模塊分別進行計算。每個路徑計算模塊上承擔的壓力更小，能夠更好地完成任務。

圖6表明，當網絡中發送服務請求消息速率相同時，兩種情況下控制器路徑下發的時延是存在差異的。當控制器中只有一個路徑計算模塊時，其路徑下發時延要略大于控制器中有兩個路徑計算模塊的下發時延。以上結果表明，當控制器中有多個相同功能的模塊時，主控單元模塊將任務進行分散，每個子功能模塊的處理壓力會相對減小，控制器的整體性能將會提高。

圖6 不同控制器的路徑下發時延

4 結束語

分析了現有互聯網面臨的問題，以及目前SDN網絡架構中控制平面所面臨的壓力。對學術界目前提出的SDN控制器解決方案的優缺點做了簡要介紹。同時提出了一種SDN控制器的優化解決方案，即功能模塊化的控制平面架構。闡明了SDN控制平面功能模塊化的設計思路，其中包括功能模塊化控制平面的整體架構，控制器內部各部分組成，控制器內部通信流程，以及采用這種架構下的控制器在接收不同消息時的處理流程。最后通過搭建拓撲環境對控制器進行測試。結果表明，在這種架構下的控制平面能夠對網絡進行有效的管控，同時功能模塊的部署也更靈活，提高了控制器的可擴展性。

[1] Feamster N,Rexford J,Zegura E.The road to SDN:an intellectual history of programmable networks[J].ACM SIGCOMM Computer Communication Review,2014,44(2):87-98.

[2] McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow:enabling innovation in campus networks[J].ACM SIGCOMM Computer Communication Review,2008,38(2):69-74.

[3] 張順淼,鄒復民.軟件定義網絡研究綜述[J].計算機應用研究,2013,30(8):2246-2251.

[4] Gude N,Koponen T,Pettit J,et al.NOX:towards an operating system for networks[J].ACM SIGCOMM Computer Communication Review,2008,38(3):105-110.

[5] 江國龍.SDN控制器:Beacon核心技術分析[J].程序員,2014(2):107-111.

[6] 李立龍,呂光宏,董永彬.基于OpenFlow的SDN控制平面可擴展性綜述[J].電子科技,2015,28(1):171-175.

[7] 房秉毅,張 歌,張云勇,等.開源SDN控制器發展現狀研究[J].郵電設計技術,2014(7):29-36.

[8] Dixit A,Hao F,Mukherjee S,et al.Towards an elastic distributed SDN controller[J].ACM SIGCOMM Computer Communication Review,2013,43(4):7-12.

[9] Jimenez Y,Cervello-Pastor C,Garcia A J.On the controller placement for designing a distributed SDN control layer[C]//Networking conference.[s.l.]:IEEE,2014:1-9.

[10] Tootoonchian A,Ganjali Y.HyperFlow:a distributed control plane for OpenFlow[C]//Internet network management conference on research on enterprise networking.[s.l.]:USENIX Association,2010:3.

[11] Koponen T,Casado M,Gude N,et al.Onix:a distributed control platform for large-scale production networks[C]//USENIX symposium on operating systems design and implementation.Vancouver,BC,Canada:USENIX,2010:351-364.

[12] Yeganeh S H,Ganjali Y.Kandoo:a framework for efficient and scalable offloading of control applications[C]//Workshop on hot topics in software defined networks.[s.l.]:ACM,2012:19-24.

[13] 鮮永菊,朱 佳,魯昭男.基于SDN的多控制器部署策略的研究[J].電視技術,2016,40(6):78-84.

[14] Lin P,Bi J,Chen Z,et al.WE-bridge:west-east bridge for SDN inter-domain network peering[C]//IEEE conference on computer communications workshops.[s.l.]:IEEE,2014:111-112.

[15] 李軍飛,蘭巨龍,胡宇翔,等.SDN多控制器一致性的量化研究[J].通信學報,2016,37(6):86-93.

ResearchonModularandFunctionalSDNControlPlane

HOU Wen，CHEN Jia，WANG Hong-chao

(National Engineering Laboratory for NGI Interconnection Devices,School of Electronics and Information Engineering,Beijing Jiaotong University,Beijing 100044,China)

With the increase of the network scale and the increasing number of network nodes,the data to be controlled and processed in the network is increased,so the requirement for the data processing of the control plane is also higher and higher.If the control plane only has one single centralized controller to complete the work,its processing capacity is limited.When facing large-scale complex network,it will produce a systematic bottleneck.In order to solve this problem,a design scheme for new control plane,a functional and modularized control plane is proposed,which is divided into different sub function modules.Each one can be deployed independently and unified scheduling.The external logic can be centralized and the internal modules can be flexibly loaded.The ultimate goal is to improve the flexibility and reliability of the controller.The overall model design and communication mechanism of the modular control plane are studied.Finally,the functional modular controller is tested by constructing the topology and the feasibility and effectiveness of the proposed scheme is verified.

Software-Defined Network(SDN);control plane;functional modularity;flexible deployment

TP31

A

1673-629X(2017)12-0023-05

10.3969/j.issn.1673-629X.2017.12.006

2016-11-24

2017-03-27 < class="emphasis_bold">網絡出版時間

時間：2017-08-01

國家“973”重點基礎研究發展計劃項目(2013CB329100)；國家自然科學基金重點項目(61232017)

侯 文(1991-)，女，碩士研究生，研究方向為下一代互聯網理論與技術；陳 佳，博士，副教授，研究方向為下一代互聯網理論與技術；王洪超，博士，講師，研究方向為下一代互聯網理論與技術。

http://kns.cnki.net/kcms/detail/61.1450.TP.20170801.1552.044.html