侯 文,陳 佳,王洪超
(北京交通大學(xué) 電子信息工程學(xué)院 下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國家工程實驗室,北京 100044)
SDN控制平面功能模塊化研究
侯 文,陳 佳,王洪超
(北京交通大學(xué) 電子信息工程學(xué)院 下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國家工程實驗室,北京 100044)
隨著網(wǎng)絡(luò)規(guī)模的加大,網(wǎng)絡(luò)節(jié)點不斷增多,網(wǎng)絡(luò)中需要進行管控和處理的數(shù)據(jù)也就越多,因此對控制平面的數(shù)據(jù)處理能力的要求也越來越高。如果控制平面只有一個集中的控制器來完成工作,其處理能力有限,在面對大規(guī)模復(fù)雜網(wǎng)絡(luò)時,必將產(chǎn)生系統(tǒng)性能瓶頸。為了解決這一問題,提出了一種新的控制平面設(shè)計方案,即功能模塊化控制平面。功能模塊化控制平面將控制器內(nèi)部按照功能劃分成不同的子功能模塊,各子功能模塊能夠獨立部署,統(tǒng)一進行調(diào)度,對外實現(xiàn)邏輯集中化,內(nèi)部又可以實現(xiàn)靈活擴展,進一步提高控制器的靈活性、可靠性以及整體性能。研究了功能模塊化控制平面的總體模型設(shè)計和通信機制,最終通過搭建拓?fù)鋵δ苣K化控制器進行測試,驗證了該方案的可行性和有效性。
軟件定義網(wǎng)絡(luò);控制平面;功能模塊化;靈活部署
隨著網(wǎng)絡(luò)的不斷發(fā)展,傳統(tǒng)網(wǎng)絡(luò)的體系架構(gòu)已經(jīng)越來越難以滿足對通信的“高速”、“高效”、“海量”的迫切需求,并且在可擴展性、安全性、移動性等方面暴露出嚴(yán)重不足。面臨這一現(xiàn)狀,對現(xiàn)有網(wǎng)絡(luò)進行微小的改變已經(jīng)不足以解決所有問題,因此需要一種全新的網(wǎng)絡(luò)架構(gòu)來綜合解決當(dāng)前網(wǎng)絡(luò)中的眾多弊端[1]。2008年,斯坦福大學(xué)的Nick McKeown教授提出了OpenFlow[2],并逐漸推廣到SDN概念。SDN網(wǎng)絡(luò)架構(gòu)[3]將路由決策控制功能從原有傳統(tǒng)網(wǎng)絡(luò)中解耦出來,即實現(xiàn)網(wǎng)絡(luò)中控制平面與數(shù)據(jù)平面的分離,由控制平面掌控網(wǎng)絡(luò)的全局信息,實現(xiàn)對網(wǎng)絡(luò)的控制,數(shù)據(jù)平面提供簡單的數(shù)據(jù)轉(zhuǎn)發(fā)功能。
在網(wǎng)絡(luò)規(guī)模不龐大時,控制平面所需處理的請求量少,單一集中的控制器可以管理當(dāng)前網(wǎng)絡(luò)。單一控制器的代表有NOX[4]、Beacon[5]等。然而當(dāng)網(wǎng)絡(luò)的規(guī)模不斷加大,網(wǎng)絡(luò)節(jié)點不斷增多,發(fā)往控制器的流量也在不斷加大,控制器所需處理和存儲的數(shù)據(jù)量也就越來越大,而單一集中的控制器處理能力有限,部署不夠靈活,擴展性差,無法管控越來越復(fù)雜的網(wǎng)絡(luò)。文獻[6-9]介紹了SDN控制器的發(fā)展現(xiàn)狀,以及為了解決單一集中控制器所帶來的眾多問題,當(dāng)前學(xué)術(shù)界提出的多種SDN控制平面的解決方案,例如采用多控制器架構(gòu)。多控制器方案代表有如下幾種:一種為去中心化結(jié)構(gòu),每個控制器的地位相等,如HyperFlow[10]、Onix[11];一種為分層結(jié)構(gòu),將控制器分為不同等級,等級越高監(jiān)控的范圍越大,如Kandoo[12]。采用多控制器方案解決了單一控制器的性能瓶頸問題,但又帶來了新的問題,其中主要包括控制器區(qū)域部署問題[13]。例如對于給定的網(wǎng)絡(luò)拓?fù)?,如何進行分區(qū),控制器該如何放置,每個控制器管理哪些交換機,等等。除了多控制器部署問題,多控制器方案面臨的主要問題還涉及多個控制器之間該如何通信[14],以及如何保持全局狀態(tài)一致性等[15]。
文中提出了一種新的控制器架構(gòu)模型,即功能模塊化的控制平面,用于解決單一集中的控制器所面臨的問題。功能模塊化的控制平面將原控制器中的不同功能抽象化,形成單獨的功能模塊,各功能模塊能在不同的網(wǎng)絡(luò)組件上進行靈活的部署和擴展,進一步提高控制器功能部署的靈活性和可擴展性。
為了提高控制平面部署的靈活性和可擴展性,功能模塊化控制平面架構(gòu)將原控制器中的不同功能模塊進行抽象化處理,形成單獨的功能模塊,并且部署在不同的網(wǎng)絡(luò)組件上。功能模塊化的控制平面主要由以下幾部分組成,其中包括一個控制器主控單元模塊,多個子功能模塊,如網(wǎng)絡(luò)拓?fù)湫畔⒛K、路由計算模塊、轉(zhuǎn)發(fā)組件狀態(tài)信息模塊、用戶信息模塊和服務(wù)信息模塊。
主控單元模塊主要負(fù)責(zé)對各個功能模塊的管理和控制,并且主控單元模塊是控制平面和轉(zhuǎn)發(fā)平面之間的接口。主控單元模塊能夠檢測到有哪些功能模塊完成注冊,是否可以正常工作,并能夠協(xié)調(diào)各子功能模塊之間的工作。同時主控單元模塊能夠負(fù)責(zé)接收來自轉(zhuǎn)發(fā)平面的消息,并根據(jù)消息類型,將不同的消息分配給相應(yīng)的子功能模塊進行處理。其他各個子功能模塊可以部署在不同的組件上,完成各自的功能,并且各功能模塊擁有自己的計算和存儲資源,實現(xiàn)了控制平面的解耦合。
根據(jù)不同需求,實現(xiàn)同一功能的模塊根據(jù)需要可能有多個,由主控單元模塊完成任務(wù)的分配,共同完成某一任務(wù),減輕單一子功能模塊的處理壓力,使部署更靈活,并且提升了控制平面的整體性能。最終實現(xiàn)控制器主控單元和各子功能模塊之間的協(xié)同工作,完成對整個網(wǎng)絡(luò)的管控,解決原有單一集中控制器的性能瓶頸和擴展性差的問題。控制平面的功能模塊化設(shè)計如圖1所示。
圖1 控制平面總體模型設(shè)計
控制器內(nèi)部主要由主控單元模塊、網(wǎng)絡(luò)拓?fù)湫畔卧K、路徑計算單元模塊、轉(zhuǎn)發(fā)組件狀態(tài)信息單元模塊、用戶信息模塊和服務(wù)資源信息模塊組成??刂破髦骺貑卧饕?fù)責(zé)與各個功能模塊間的信息交互,協(xié)調(diào)各功能模塊的工作,以及與轉(zhuǎn)發(fā)組件之間的通信??刂破髦骺貑卧强刂破鲀?nèi)部的核心模塊,也是控制器與外部的通信接口。網(wǎng)絡(luò)拓?fù)湫畔⒛K負(fù)責(zé)實時保存網(wǎng)絡(luò)中的拓?fù)湫畔ⅲ?dāng)網(wǎng)絡(luò)中有服務(wù)請求時,路由計算模塊會根據(jù)拓?fù)湫畔⑦M行路徑計算,完成資源的適配過程。轉(zhuǎn)發(fā)組件狀態(tài)信息模塊負(fù)責(zé)存儲各個轉(zhuǎn)發(fā)組件的性能狀態(tài)信息。用戶信息模塊負(fù)責(zé)存儲網(wǎng)絡(luò)中注冊用戶的信息,包括用戶ID、用戶名稱及用戶權(quán)限等。服務(wù)資源模塊負(fù)責(zé)存儲網(wǎng)絡(luò)中服務(wù)提供者可以提供的服務(wù)資源,包括服務(wù)ID、域名、服務(wù)所需帶寬、權(quán)限、類型等。
控制器的主控單元模塊可以抽象為如下模型。主控單元由內(nèi)部通信接口、外部通信接口、消息處理三部分組成。內(nèi)部通信接口負(fù)責(zé)控制器內(nèi)部主控單元與各功能模塊的消息交互。外部通信接口負(fù)責(zé)與轉(zhuǎn)發(fā)組件之間的消息交互。消息處理部分會根據(jù)內(nèi)部通信接口與外部通信接口收到消息的類型進行相應(yīng)處理,是主控單元模塊的核心部分。
每個子功能模塊可以抽象成如下模型。各子功能模塊均由通信接口、消息處理及處理結(jié)果反饋幾部分構(gòu)成。
由通信接口負(fù)責(zé)接收與發(fā)送消息,消息處理部分負(fù)責(zé)根據(jù)不同的消息類型對消息進行相應(yīng)的處理,如果需要發(fā)送消息反饋,則產(chǎn)生相應(yīng)的反饋消息,由通信接口發(fā)送出去。
控制器內(nèi)部通信涉及的消息類型包括功能模塊注冊消息fun_hello,信息查詢與反饋消息feature,鏈路狀態(tài)檢測消息echo。消息包格式的設(shè)計采用TLV形式,用以區(qū)分消息類型和統(tǒng)一消息的格式。TLV:Type類型,Length長度,Value值。類型部分采用主類型和子類型。
控制器內(nèi)部通信過程如圖2所示。
圖2 控制器內(nèi)部通信流程
主控單元模塊首先啟動,負(fù)責(zé)監(jiān)聽其他功能模塊的連接。當(dāng)有其他子功能模塊發(fā)起連接請求時,主控單元接受連接,與子功能模塊建立通信通道,完成信息的交互。子功能模塊與主控單元模塊建立連接后,子功能模塊主動向主控單元模塊進行注冊,實現(xiàn)功能模塊的靈活加載。子功能模塊發(fā)送注冊消息hello_fun給主控單元模塊,hello_fun攜帶功能標(biāo)識fid,包長度。主控單元模塊可根據(jù)hello_fun消息中的功能標(biāo)識來統(tǒng)計各個類型的功能模塊分別有多少個,并根據(jù)鏈路是否通暢來動態(tài)維護這一信息,用于實現(xiàn)網(wǎng)絡(luò)中有請求時任務(wù)的調(diào)度和分配。
控制器主控單元模塊收到hello_fun消息后,會向子功能模塊發(fā)送信息查詢消息,即feature_request消息,用于查詢子功能模塊的一些基本信息。子功能模塊收到feature_request消息后,向主控單元模塊回應(yīng)feature_reply消息,用于報告自己的基本信息。feature_reply消息中包含的內(nèi)容有:功能模塊標(biāo)識fun_id、模塊名稱fun_name、ip地址、mac地址、port信息、工作狀態(tài)信息等。
當(dāng)主控單元模塊與子功能模塊間的連接建立、注冊等一系列初步工作完成后,控制器整體處于可以工作的待命狀態(tài)。當(dāng)網(wǎng)絡(luò)中轉(zhuǎn)發(fā)組件有消息發(fā)送給控制器時,控制器會根據(jù)消息類型進行相應(yīng)的處理,實現(xiàn)主控單元模塊和各子功能模塊間的協(xié)同工作。當(dāng)控制器主控單元與子功能模塊的連接通道內(nèi)沒有消息發(fā)送時,主控單元將向子功能模塊定時發(fā)送echo請求消息,子功能模塊收到后給主控單元發(fā)送echo回復(fù)消息,用于檢測二者之間的通信是否通暢。如果在規(guī)定時間和echo請求次數(shù)內(nèi),主控單元模塊沒有收到子功能模塊的echo回復(fù)消息,則認(rèn)為通信鏈路中斷,并將此類功能模塊的個數(shù)減一。
控制器主控單元模塊負(fù)責(zé)接收由轉(zhuǎn)發(fā)組件轉(zhuǎn)發(fā)來的消息,對接收的消息進行判斷,根據(jù)消息類型發(fā)送給相應(yīng)的子功能模塊,由各子功能模塊進行相應(yīng)的處理。當(dāng)主控單元收到轉(zhuǎn)發(fā)組件的狀態(tài)信息時,將其存入轉(zhuǎn)發(fā)組件狀態(tài)信息模塊。當(dāng)主控單元模塊收到用戶的注冊、注銷或更新消息時,將其發(fā)送給用戶信息模塊進行處理。當(dāng)主控單元模塊收到服務(wù)注冊、服務(wù)注銷或服務(wù)更新消息時,將其交給服務(wù)資源信息模塊進行相應(yīng)的處理。當(dāng)主控單元模塊收到轉(zhuǎn)發(fā)組件報告的拓?fù)湫畔r,將其存入網(wǎng)絡(luò)拓?fù)湫畔⒛K。當(dāng)主控單元模塊收到服務(wù)請求消息時,首先在服務(wù)信息模塊中查詢是否有這一服務(wù),如果沒有則返回該服務(wù)未提供,服務(wù)請求失??;如果存在這一服務(wù),服務(wù)信息模塊向主控單元模塊返回服務(wù)查詢成功消息。主控單元模塊向拓?fù)湫畔⒛K進行查詢,將拓?fù)湫畔⒑头?wù)請求消息發(fā)送給路徑計算模塊,由路由計算模塊為該請求計算出一條合理可達(dá)的路徑,最終由主控單元模塊下發(fā)給轉(zhuǎn)發(fā)組件。
在各子功能模塊注冊階段和鏈路探測階段,控制器主控單元模塊動態(tài)感知每類功能模塊的個數(shù),用于實現(xiàn)后續(xù)任務(wù)的分配。在適當(dāng)?shù)那闆r下,通過對多個實現(xiàn)同種功能的模塊的部署,以提高控制平面的整體處理能力,同時也增加了控制平面部署的靈活性。圖3以控制器內(nèi)部有兩個路徑計算功能模塊為例,展示了控制器收到網(wǎng)絡(luò)中的服務(wù)請求消息時的工作過程。
圖3 控制器內(nèi)部處理流程
當(dāng)網(wǎng)絡(luò)中有多個服務(wù)請求時,轉(zhuǎn)發(fā)組件把服務(wù)請求信息發(fā)送給控制器。控制器主控單元模塊接收到服務(wù)請求信息,向服務(wù)信息模塊進行服務(wù)信息查詢,若該服務(wù)不存在,返回服務(wù)查詢失敗消息;若存在該服務(wù),則服務(wù)資源信息模塊返回服務(wù)查詢成功消息。
當(dāng)服務(wù)查詢成功時,主控單元模塊查詢拓?fù)湫畔?,并將拓?fù)湫畔⒑头?wù)請求消息發(fā)送給路徑計算模塊。由于控制器內(nèi)部有兩個路徑計算模塊,主控單元模塊將多個服務(wù)請求消息分別發(fā)送給路徑計算模塊1和2。兩個路徑計算模塊同時工作,進行路徑的計算,并將計算結(jié)果返回給主控單元模塊,由主控單元模塊將路徑下發(fā)給轉(zhuǎn)發(fā)組件。若網(wǎng)絡(luò)中存在到達(dá)該服務(wù)的路徑,轉(zhuǎn)發(fā)組件將此請求轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)提供者,并將相應(yīng)的服務(wù)返回給請求的主機。
測試過程在圖4所示的拓?fù)渲型瓿?。測試環(huán)境包括一臺控制器,三個轉(zhuǎn)發(fā)組件,一臺主機和一臺服務(wù)器。
圖4 測試拓?fù)鋱D
首先完成對控制器內(nèi)部通信流程的功能性測試,其次對控制器內(nèi)部結(jié)構(gòu)的兩種不同情況進行對比測試。第一種情況:控制器內(nèi)部由一個主控單元模塊、一個拓?fù)湫畔⒛K、一個路徑計算模塊、一個用戶信息模塊和一個服務(wù)信息模塊組成。第二種情況:控制器由一個主控單元模塊、一個拓?fù)湫畔⒛K、兩個路徑計算模塊、一個用戶信息模塊和一個服務(wù)信息模塊組成。
針對圖4所示的拓?fù)洵h(huán)境,通過wireshark抓包分析結(jié)果。抓包結(jié)果表明,控制器內(nèi)部通信過程如下:控制器主控單元模塊首先啟動,各子功能模塊向主控單元注冊,發(fā)送注冊消息即hello_fun。主控單元模塊收到注冊消息后,向相應(yīng)的功能模塊發(fā)送狀態(tài)信息查詢消息feature_request,子功能模塊收到查詢消息后,向主控單元模塊回復(fù)feature_reply,報告自己的相關(guān)信息。通過這種機制,實現(xiàn)控制器對其子功能模塊的靈活加載。
當(dāng)測試拓?fù)渲杏卸鄠€網(wǎng)絡(luò)請求時,轉(zhuǎn)發(fā)平面的交換機將多個服務(wù)請求消息發(fā)送給控制器的主控單元模塊。主控單元模塊進行服務(wù)查詢得到結(jié)果服務(wù)存在,然后查詢拓?fù)湫畔ⅰ13置棵氚l(fā)送的服務(wù)請求消息數(shù)量相同,對兩種情況的控制器進行對比測試。當(dāng)控制器內(nèi)部只有一個路徑計算模塊時,主控單元模塊將全部服務(wù)請求信息和拓?fù)湫畔l(fā)送給路徑計算模塊進行計算。當(dāng)控制器內(nèi)部有兩個路徑計算模塊時,主控單元模塊將服務(wù)請求消息近似平均分配給這兩個子功能模塊,子功能模塊完成計算后將路徑返回,并由主控單元模塊將路徑下發(fā)給轉(zhuǎn)發(fā)組件。對比測試的結(jié)果如圖5所示。
圖5 不同控制器的測試結(jié)果
從圖5可以看出,當(dāng)控制器內(nèi)部只有一個路徑計算模塊時,該模塊要全部完成對服務(wù)請求消息的路徑計算,面臨的壓力也相對較大。當(dāng)控制器內(nèi)部有兩個路徑計算模塊時,主控單元模塊將服務(wù)請求消息進行分流,由兩個路徑計算模塊分別進行計算。每個路徑計算模塊上承擔(dān)的壓力更小,能夠更好地完成任務(wù)。
圖6表明,當(dāng)網(wǎng)絡(luò)中發(fā)送服務(wù)請求消息速率相同時,兩種情況下控制器路徑下發(fā)的時延是存在差異的。當(dāng)控制器中只有一個路徑計算模塊時,其路徑下發(fā)時延要略大于控制器中有兩個路徑計算模塊的下發(fā)時延。以上結(jié)果表明,當(dāng)控制器中有多個相同功能的模塊時,主控單元模塊將任務(wù)進行分散,每個子功能模塊的處理壓力會相對減小,控制器的整體性能將會提高。
圖6 不同控制器的路徑下發(fā)時延
分析了現(xiàn)有互聯(lián)網(wǎng)面臨的問題,以及目前SDN網(wǎng)絡(luò)架構(gòu)中控制平面所面臨的壓力。對學(xué)術(shù)界目前提出的SDN控制器解決方案的優(yōu)缺點做了簡要介紹。同時提出了一種SDN控制器的優(yōu)化解決方案,即功能模塊化的控制平面架構(gòu)。闡明了SDN控制平面功能模塊化的設(shè)計思路,其中包括功能模塊化控制平面的整體架構(gòu),控制器內(nèi)部各部分組成,控制器內(nèi)部通信流程,以及采用這種架構(gòu)下的控制器在接收不同消息時的處理流程。最后通過搭建拓?fù)洵h(huán)境對控制器進行測試。結(jié)果表明,在這種架構(gòu)下的控制平面能夠?qū)W(wǎng)絡(luò)進行有效的管控,同時功能模塊的部署也更靈活,提高了控制器的可擴展性。
[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] 張順淼,鄒復(fù)民.軟件定義網(wǎng)絡(luò)研究綜述[J].計算機應(yīng)用研究,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核心技術(shù)分析[J].程序員,2014(2):107-111.
[6] 李立龍,呂光宏,董永彬.基于OpenFlow的SDN控制平面可擴展性綜述[J].電子科技,2015,28(1):171-175.
[7] 房秉毅,張 歌,張云勇,等.開源SDN控制器發(fā)展現(xiàn)狀研究[J].郵電設(shè)計技術(shù),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].電視技術(shù),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].通信學(xué)報,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">網(wǎng)絡(luò)出版時間
時間:2017-08-01
國家“973”重點基礎(chǔ)研究發(fā)展計劃項目(2013CB329100);國家自然科學(xué)基金重點項目(61232017)
侯 文(1991-),女,碩士研究生,研究方向為下一代互聯(lián)網(wǎng)理論與技術(shù);陳 佳,博士,副教授,研究方向為下一代互聯(lián)網(wǎng)理論與技術(shù);王洪超,博士,講師,研究方向為下一代互聯(lián)網(wǎng)理論與技術(shù)。
http://kns.cnki.net/kcms/detail/61.1450.TP.20170801.1552.044.html