一種基于SDN的多管理域路由機(jī)制

張 俊，沈蘇彬

(南京郵電大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 南京 210003)

1 概 述

互聯(lián)網(wǎng)的蓬勃發(fā)展，驅(qū)動(dòng)著網(wǎng)絡(luò)應(yīng)用的不斷創(chuàng)新與豐富，從高清視頻會(huì)議到健康監(jiān)測，以及一些遠(yuǎn)程控制系統(tǒng)，如森林防火系統(tǒng)等，對于網(wǎng)絡(luò)延遲、帶寬和可用性等方面都有著嚴(yán)格的要求。并且隨著互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大，在多數(shù)情況下，應(yīng)用流都需要進(jìn)行跨域傳輸，這將會(huì)給IP骨干網(wǎng)帶來艱巨的挑戰(zhàn)。然而，目前針對多管理域場景，域間路由信息交互的協(xié)議大多采用BGP[1]，該協(xié)議的分布式部署，雖然滿足了可擴(kuò)展性和可靠性，但是由于缺乏集中控制，使得策略表達(dá)及配置相對比較困難。同時(shí)，由于在選路過程中缺乏域間協(xié)商，各管理域域內(nèi)的局部最優(yōu)路由算法無法保證全局最優(yōu)，使得應(yīng)用流的QoS需求在目前這種“盡力而為”的網(wǎng)絡(luò)傳輸中難以得到保障，從而造成用戶的QoE下降。

為了改善網(wǎng)絡(luò)性能，以及保障應(yīng)用的QoS約束與終端用戶的QoE，學(xué)術(shù)界和工業(yè)界提出了一些解決方法。對于單個(gè)管理域，有IntServ[2]、DiffServ[3]、MPLS[4]等；對于多個(gè)管理域，有BandwidthBrokers[5]等?；ヂ?lián)網(wǎng)中對于服務(wù)質(zhì)量保證的問題，根據(jù)現(xiàn)有網(wǎng)絡(luò)狀態(tài)進(jìn)行約束路徑計(jì)算是一個(gè)關(guān)鍵組成部分，然而在當(dāng)今互聯(lián)網(wǎng)分布式體系中卻難以實(shí)現(xiàn)。并且，現(xiàn)有網(wǎng)絡(luò)協(xié)議的多樣化，以及每個(gè)路由器為了保證E2E流量工程和應(yīng)用業(yè)務(wù)QoS所需承載的計(jì)算量，使得當(dāng)前網(wǎng)絡(luò)中的路由器工作過于繁忙，不利于未來網(wǎng)絡(luò)的持續(xù)發(fā)展與創(chuàng)新。

針對傳統(tǒng)網(wǎng)絡(luò)所呈現(xiàn)的相關(guān)問題，SDN(software defined networking)[6-7]作為一種新型網(wǎng)架構(gòu)與技術(shù)應(yīng)運(yùn)而生。其突出特點(diǎn)包括：

(1)轉(zhuǎn)控分離：解耦傳統(tǒng)網(wǎng)絡(luò)設(shè)備的控制平面與轉(zhuǎn)發(fā)平面，轉(zhuǎn)發(fā)平面只具備數(shù)據(jù)流量轉(zhuǎn)發(fā)的能力，控制平面通過南向控制協(xié)議(如OpenFlow、NetConf、OVSDB等)控制轉(zhuǎn)發(fā)平面的流量行為。

(2)集中管控：控制器擁有全局網(wǎng)絡(luò)信息，如拓?fù)浜途W(wǎng)絡(luò)資源等。網(wǎng)絡(luò)管理員能夠根據(jù)這些信息完成資源的合理分配與調(diào)度，解決負(fù)載均衡、網(wǎng)絡(luò)資源分配不均等問題，簡化網(wǎng)絡(luò)管理。

(3)網(wǎng)絡(luò)可編程：通過控制器北向接口(如REST API)，應(yīng)用平面告知控制平面如何進(jìn)行網(wǎng)絡(luò)資源管理才能更好地滿足應(yīng)用約束。并且，因特網(wǎng)服務(wù)提供商能夠調(diào)用開放的北向接口，實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)的定制，加快業(yè)務(wù)的動(dòng)態(tài)部署。

OpenFlow[8-9]作為SDN網(wǎng)絡(luò)架構(gòu)的一種實(shí)現(xiàn)方式，由斯坦福大學(xué)提出，其規(guī)范由ONF(開放網(wǎng)絡(luò)基金會(huì))制定。其設(shè)計(jì)理念為：無需設(shè)計(jì)新的硬件，只對現(xiàn)有硬件更新其軟件。這在很大程度上降低了部署網(wǎng)絡(luò)應(yīng)用所需的成本。在傳統(tǒng)網(wǎng)絡(luò)中，二層交換機(jī)主要采用MAC地址和VLAN標(biāo)簽對數(shù)據(jù)包進(jìn)行處理與轉(zhuǎn)發(fā)，而在SDN網(wǎng)絡(luò)中，OpenFlow作為構(gòu)建網(wǎng)絡(luò)的一種標(biāo)準(zhǔn)南向協(xié)議與規(guī)范，通過解析數(shù)據(jù)包或幀的包頭域，將其MAC地址、VLAN標(biāo)簽、IP地址、TCP/UDP端口號等特征作為“Flow”進(jìn)行處理，通過在交換機(jī)中添加流表進(jìn)行匹配，就能夠靈活便捷地決定應(yīng)用流的轉(zhuǎn)發(fā)路徑。

針對大規(guī)模多管理域(SDN域)應(yīng)用場景，業(yè)界提出了一些解決方案，主要是對控制平面進(jìn)行了擴(kuò)展，大致分為兩類：分層分布式和完全分布式。

對于分層分布式控制平面(如圖1(a)所示)，其域內(nèi)控制器管控各個(gè)管理域域內(nèi)網(wǎng)絡(luò)，包括網(wǎng)絡(luò)抽象、鏈路發(fā)現(xiàn)等，負(fù)責(zé)域內(nèi)路由，并且向域間控制器上傳特定的拓?fù)湫畔⒑椭鳈C(jī)信息。域間控制器通過獲取來自域內(nèi)控制器的信息，計(jì)算域間路由。例如，OXP[10]針對異構(gòu)控制器間無法直接交互和目前接口協(xié)議效率較低的問題，設(shè)計(jì)了一種高效的、支持多種模式的東西向協(xié)議。OXP采用分層分布式的控制平面來解決SDN網(wǎng)絡(luò)中單一控制平面遇到瓶頸的問題，域間控制器負(fù)責(zé)域間路由，域內(nèi)控制器只負(fù)責(zé)域內(nèi)路由。當(dāng)發(fā)現(xiàn)應(yīng)用流的目的IP地址不屬于當(dāng)前管理域時(shí)，域內(nèi)控制器將數(shù)據(jù)包包頭轉(zhuǎn)發(fā)至域間控制器。域間控制器基于全局網(wǎng)絡(luò)信息計(jì)算跨域路徑，最后由各域內(nèi)控制器完成流表的下發(fā)。

圖1 控制平面架構(gòu)

對于完全分布式控制平面(如圖1(b)所示)，每個(gè)管理域的控制器同時(shí)負(fù)責(zé)其域內(nèi)路由，以及到下一管理域的域間路由，各管理域控制器之間進(jìn)行信息的交互與協(xié)商，從而進(jìn)行路由的決策。例如，HyperFlow[11]采用WheelFS實(shí)現(xiàn)分布式的發(fā)布/訂閱系統(tǒng)，該系統(tǒng)保證了發(fā)布事件的存儲(chǔ)是永久的，并且保證事件的觸發(fā)順序與源控制器一致，在網(wǎng)絡(luò)劃分時(shí)具備良好的可伸縮性。但是由于所有事件的處理都需要全局信息，造成控制器間交互的信息量巨大，此外，還會(huì)造成網(wǎng)絡(luò)狀態(tài)不一致等問題。因此，這種模式只能處理一些發(fā)生率較低的事件，而不適用于大規(guī)模多管理域網(wǎng)絡(luò)。WE-Bridge[12-13]，雖然可實(shí)現(xiàn)異構(gòu)控制器之間的協(xié)同工作，但是當(dāng)網(wǎng)絡(luò)視圖發(fā)生改變時(shí)，由于控制器間采用全連接的方式，需要在所有同類節(jié)點(diǎn)中同步數(shù)據(jù)，導(dǎo)致消耗大量帶寬，效率低下。SDNi雖然作為一種控制器間信息交互的協(xié)議，但是草案中并沒有對網(wǎng)絡(luò)如何存儲(chǔ)這些信息以及如何在多個(gè)域之間共享這些信息給出具體的描述。DISCO[14]采用基于消息導(dǎo)向的通信總線，提供一個(gè)分布式控制平面。DISCO將整個(gè)網(wǎng)絡(luò)分成多個(gè)域，用多個(gè)控制器進(jìn)行管理。每個(gè)控制器管理一個(gè)域，并提供唯一輕量級的可管理的控制通道，每個(gè)控制器上的代理動(dòng)態(tài)嵌入通道來獲取其他域的信息。代理間互相共享全網(wǎng)信息，因此可以為應(yīng)用提供端到端的網(wǎng)絡(luò)服務(wù)。其缺點(diǎn)在于全局事件的處理需要一致的全局信息，控制器之間交互的信息過多。

針對現(xiàn)有域間路由技術(shù)存在的相關(guān)問題及不足，文中提出一種基于SDN的多管理域路由機(jī)制(SDNMDR)，以及相關(guān)的實(shí)現(xiàn)和實(shí)驗(yàn)方案，并通過實(shí)驗(yàn)進(jìn)行驗(yàn)證。

2 基于SDN的多管理域路由機(jī)制

雖然現(xiàn)有SDN域間路由技術(shù)在一定程度上解決了網(wǎng)絡(luò)擴(kuò)展性的問題，但是大多數(shù)方案都只是針對單一網(wǎng)絡(luò)提供商實(shí)體而言的，并且域間交互的信息量過大，將會(huì)給網(wǎng)絡(luò)負(fù)載帶來巨大的壓力。此外，當(dāng)多個(gè)管理域由不同的網(wǎng)絡(luò)提供商實(shí)體進(jìn)行管控時(shí)，出于安全性考慮，大家都不愿公開其內(nèi)部網(wǎng)絡(luò)信息。因此，上文所列舉的現(xiàn)有SDN域間路由技術(shù)將不再適用。

針對BGP分布式部署存在的諸多問題，以及現(xiàn)有SDN域間路由技術(shù)的不足，結(jié)合SDN網(wǎng)絡(luò)可編程帶來的優(yōu)勢，設(shè)計(jì)了SDNMDR機(jī)制。該機(jī)制采用完全分布式控制平面，主要通過控制器上的三個(gè)模塊來實(shí)現(xiàn)，如圖2所示。

圖2 控制器功能模塊

(1)域內(nèi)監(jiān)控模塊(Intra_Monitor)。該模塊根據(jù)SDN域內(nèi)集中管控的思想，采用LLDP協(xié)議獲取域內(nèi)交換機(jī)信息，以及網(wǎng)絡(luò)的實(shí)時(shí)情況，包括網(wǎng)絡(luò)資源和網(wǎng)絡(luò)流量信息等，從而分別為域間交互模塊和路由模塊提供協(xié)商和選路依據(jù)。

(2)域間交互模塊(Inter_Negotiation)。對于網(wǎng)絡(luò)應(yīng)用流的傳輸，可達(dá)性是最基本的要求。首先，該模塊參照BGP[15]協(xié)議交互網(wǎng)絡(luò)可達(dá)性信息，在目的網(wǎng)絡(luò)可達(dá)的情況下，為了滿足應(yīng)用流的端到端需求約束，相鄰管理域再通過該模塊進(jìn)行應(yīng)用需求的請求與協(xié)商。

(3)路由模塊(Routing)。主要完成兩項(xiàng)工作：第一，對于跨域的應(yīng)用流，結(jié)合網(wǎng)絡(luò)可達(dá)性信息和域內(nèi)網(wǎng)絡(luò)資源信息，進(jìn)行域內(nèi)路徑以及到相鄰管理域的域間路徑的計(jì)算；第二，根據(jù)計(jì)算結(jié)果，通知域間交互模塊與相鄰管理域進(jìn)行協(xié)商，協(xié)商完成后再由該模塊完成流表的下發(fā)。

目前業(yè)界大多數(shù)開源控制器，如Ryu、OpenDaylight、Floodlight、ONOS等，都已經(jīng)實(shí)現(xiàn)域內(nèi)監(jiān)控和域內(nèi)路由。由于SDN的初衷在于單個(gè)管理域內(nèi)的集中控制，所以對于SDN域間如何交互與協(xié)商的問題，即東西向接口問題，仍是當(dāng)前將SDN應(yīng)用于大規(guī)模網(wǎng)絡(luò)中亟需解決的一個(gè)熱點(diǎn)問題。以下為文中提出的一種解決方案。

實(shí)現(xiàn)端到端服務(wù)質(zhì)量約束路由的基礎(chǔ)是多管理域間的互聯(lián)互通，在SDN網(wǎng)絡(luò)中，為了構(gòu)建跨域的流表，相鄰管理域控制器間需要進(jìn)行通信，交互網(wǎng)絡(luò)層可達(dá)性信息。文中控制器之間的交互參照了BGP，在域間交互模塊中實(shí)現(xiàn)，域間控制器的通信流程如圖3中①～④所示，具體過程如下：

(1)使控制器具備BGP speaker的能力，每個(gè)BGP speaker包含狀態(tài)機(jī)邏輯，并且當(dāng)控制器啟動(dòng)時(shí)，BGP功能體觸發(fā)連接事件。每個(gè)管理域的BGP信息由網(wǎng)絡(luò)管理員進(jìn)行配置，控制器與鄰居控制器建立TCP連接。

(2)BGP使用TCP作為其傳輸層協(xié)議，當(dāng)TCP連接建立后，BGP speaker將會(huì)互相發(fā)送OPEN消息，并且狀態(tài)將會(huì)變成OPEN。

(3)BGP speaker在OPEN狀態(tài)下協(xié)商會(huì)話能力，控制器通過OpenFlow南向協(xié)議獲取其管理域網(wǎng)絡(luò)能力信息。

(4)成為BGP Peers后，控制器進(jìn)入ESTABLISHED狀態(tài)，雙方在這個(gè)狀態(tài)下互換BGP UPDATE消息，如NLRI和帶寬等。

圖3 控制器建立連接及協(xié)商過程

為了給用戶帶來良好的網(wǎng)絡(luò)體驗(yàn)，應(yīng)用流在跨域傳輸?shù)倪^程中，需要加以服務(wù)質(zhì)量約束。由于各管理域只能夠決定其域內(nèi)路由，彼此間缺乏協(xié)商機(jī)制，使得業(yè)務(wù)的QoS約束難以得到保障。針對該問題，文中設(shè)計(jì)了一種域間協(xié)商協(xié)議，通過協(xié)商來實(shí)現(xiàn)應(yīng)用流的端到端QoS約束路由。協(xié)商協(xié)議交互過程如圖3中⑤～⑦所示。域間協(xié)商協(xié)議的消息如表1所示。

表1 域間協(xié)商消息

域間協(xié)商協(xié)議具體過程如下：

(1)控制器A發(fā)現(xiàn)應(yīng)用流的目的地址是在域外，基于BGP信息，選擇最佳下一域B，從本地?cái)?shù)據(jù)存儲(chǔ)中檢索邊界信息，并且發(fā)送一個(gè)包含端到端應(yīng)用約束的協(xié)商請求給控制器B。

(2)控制器B收到這樣的消息，與域內(nèi)策略作比較，如果符合域內(nèi)策略且有能夠滿足應(yīng)用需求的配置路徑，則更新這些路徑以滿足額外需求，否則將通過路由模塊計(jì)算新的路徑。此外，還會(huì)檢查域間鏈路的統(tǒng)計(jì)，如果有可用的資源，然后會(huì)回復(fù)控制器A一個(gè)包含相應(yīng)的代價(jià)ACCEPT協(xié)商響應(yīng)，否則回復(fù)REJECT。

(3)如果控制器A收到一個(gè)ACCEPT，則表示協(xié)商成功。

(4)如果目的IP不在B，則重復(fù)以上步驟，采用遞歸的方式。

根據(jù)協(xié)商結(jié)果，各管理域中的控制器根據(jù)路由模塊中計(jì)算好的路徑，采用OpenFlow協(xié)議對沿路的交換機(jī)通過下發(fā)流表進(jìn)行配置。

OpenFlow流表的匹配域能夠匹配數(shù)據(jù)包包頭的二層至四層地址信息。首先，分別對源主機(jī)和目的主機(jī)所連接的交換機(jī)配置，通過控制器中存儲(chǔ)的MAC-PORT映射表，采用匹配源目的MAC地址的方式構(gòu)建流表；對非源目主機(jī)所在管理域的邊界交換機(jī)配置，采用匹配目的IP地址的方式構(gòu)建流表，使得經(jīng)過該交換機(jī)的應(yīng)用流能夠轉(zhuǎn)發(fā)至協(xié)商好的下一管理域的入口交換機(jī)，如圖3中⑧～⑨所示。此外，各管理域還需周期性檢查域間鏈路狀態(tài)以及相關(guān)QoS參數(shù)，確保能滿足應(yīng)用流的服務(wù)質(zhì)量約束和管理域間所約定的SLA參數(shù)，當(dāng)不滿足時(shí)，重新進(jìn)行協(xié)商與配置。

3 多域路由機(jī)制的實(shí)驗(yàn)和測試

為了滿足應(yīng)用流的跨域傳輸，首先需要實(shí)現(xiàn)的是多管理域的互聯(lián)互通。實(shí)驗(yàn)選取Ryu開源控制器，通過Quagga使其具備BGP speaker的能力，采用Mininet仿真實(shí)驗(yàn)環(huán)境。實(shí)驗(yàn)拓?fù)淙鐖D4(a)所示，各管理域控制器采用BGP消息進(jìn)行交互，獲取NLRI后，通過OpenFlow配置交換機(jī)，執(zhí)行pingall命令，H1～H6主機(jī)間能夠互相ping通。通過測試，驗(yàn)證了該多SDN域?qū)嶒?yàn)平臺的可行性。

圖4 實(shí)驗(yàn)拓?fù)?/p>

當(dāng)源管理域控制器收到多條關(guān)于目的地址前綴的路由通告時(shí)(即在源節(jié)點(diǎn)與目的節(jié)點(diǎn)之間存在多條物理鏈路)，模擬抽象網(wǎng)絡(luò)拓?fù)淙鐖D4(b)所示。在該場景下，應(yīng)用流需要從D1中的主機(jī)s(172.16.1.1)傳輸至D6中的主機(jī)t(172.16.6.1)，此時(shí)存在多條域間鏈路(①D1-D2-D6；②D1-D3-D4-D6；③D1-D3-D4-D5-D6)。假設(shè)該應(yīng)用流的總時(shí)延約束為100 ms，為了保障端到端約束路由，控制器間需要進(jìn)行協(xié)商，并且根據(jù)協(xié)商的結(jié)果下發(fā)流表，配置各自域內(nèi)交換機(jī)和邊界交換機(jī)。

假設(shè)域間鏈路時(shí)延均為10 ms，代價(jià)均為10。各管理域域內(nèi)聚合鏈路(邊界路由器之間的鏈路)的時(shí)延及代價(jià)如圖5所示。

首先根據(jù)BGP交互的網(wǎng)絡(luò)層可達(dá)性信息以及從域內(nèi)監(jiān)控模塊獲取的域內(nèi)拓?fù)浜唾Y源信息，D1中控制器結(jié)合應(yīng)用流服務(wù)質(zhì)量約束與路由模塊中的路由算法(文中采用最小代價(jià)算法)，選擇可以到達(dá)目的IP地址的下一管理域，通過交互模塊發(fā)送協(xié)商請求，相鄰管理域根據(jù)請求消息返回請求結(jié)果和所需代價(jià)。測試結(jié)果如下：

(1)D1選擇時(shí)延20 ms，D1-D2時(shí)延為10 ms，D2選擇時(shí)延20 ms，D2-D6時(shí)延10 ms，D6選擇時(shí)延20 ms。共80 ms，滿足約束。遞歸返回代價(jià)70。

D110 ms(10) , 20 ms(5)10 ms(10) , 15 ms(5)D210 ms(35), 20 ms(30)D315 ms(15), 20 ms(10)D410 ms(15), 15 ms(8)10 ms(20), 30 ms(5)D520 ms(20), 30 ms(10)D610 ms(20), 20 ms(15)5 ms(20), 10 ms(15)10 ms(20), 20 ms(15)

圖5 域內(nèi)鏈路(時(shí)延(代價(jià)))

(2)D1選擇時(shí)延15 ms，D1-D3時(shí)延為10 ms，D3選擇時(shí)延20 ms，D3-D4時(shí)延10 ms，D4選擇時(shí)延30 ms，D4-D5時(shí)延10 ms，D5選擇時(shí)延30 ms和20 ms均不滿足約束。

(3)D1選擇時(shí)延15 ms，D1-D3時(shí)延為10 ms，D3選擇時(shí)延20 ms，D3-D4時(shí)延10 ms，D4選擇時(shí)延15 ms，D4-D6時(shí)延10 ms，D6時(shí)延10 ms，共90 ms，滿足約束。遞歸返回代價(jià)68。

(4)D1中控制器的交互模塊比較1和2中的代價(jià)，選擇D1-D3-D4-D6這條鏈路，并且發(fā)送確認(rèn)消息。

(5)各管理域根據(jù)協(xié)商結(jié)果，通知路由模塊下發(fā)流表配置交換機(jī)。

配置完成后，通過ovs-ofctl dump-flows命令查看D1與D3相連的邊界交換機(jī)流表，可以看到包含“ip, nw_dst=172.16.6.1, actions=output:4”字段信息的流表，查看D6中與主機(jī)t相連的交換機(jī)流表，可以看到包含“in_port=3, dl_dst=00:00:00:00:00:02,actions=output:3”字段信息的流表。

實(shí)驗(yàn)結(jié)果表明，SDNMDR能夠?qū)崿F(xiàn)多管理域間的互聯(lián)互通，并且當(dāng)源目的主機(jī)間存在多條可選域間路徑時(shí)，以及各管理域網(wǎng)絡(luò)資源允許的情況下，服務(wù)提供商能夠根據(jù)管理域間的協(xié)商，綜合考慮應(yīng)用需求與傳輸過程中所需代價(jià)，選擇滿足約束的端到端路由。

4 結(jié)束語

通過擴(kuò)展標(biāo)準(zhǔn)Ryu開源控制器的功能模塊，結(jié)合Mininet網(wǎng)絡(luò)仿真工具，實(shí)現(xiàn)了一種基于SDN的多管理域路由機(jī)制。通過模擬與測試，驗(yàn)證了該機(jī)制能夠在滿足應(yīng)用需求，為用戶提供良好體驗(yàn)的前提下，降低服務(wù)提供商的所需成本。并且該方案采用完全分布式控制平面，可縮放性較強(qiáng)，能夠適應(yīng)當(dāng)前互聯(lián)網(wǎng)快速發(fā)展的迫切需求。