SDN環(huán)境下網(wǎng)絡(luò)路由的設(shè)計(jì)與實(shí)現(xiàn)

任 歡，周杭霞

(中國計(jì)量大學(xué) 信息工程學(xué)院，浙江 杭州 310018)

SDN環(huán)境下網(wǎng)絡(luò)路由的設(shè)計(jì)與實(shí)現(xiàn)

任 歡，周杭霞

(中國計(jì)量大學(xué) 信息工程學(xué)院，浙江 杭州 310018)

軟件定義網(wǎng)絡(luò)(SDN)將數(shù)據(jù)層與控制層相分離，是一種新型網(wǎng)絡(luò)體系架構(gòu).針對目前SDN網(wǎng)絡(luò)還不能提供路由服務(wù)問題，設(shè)計(jì)了一種基于OpenFlow技術(shù)，使得SDN網(wǎng)絡(luò)擁有路由轉(zhuǎn)發(fā)功能的方案.依托RouteFlow平臺，以內(nèi)核虛擬化技術(shù)為基礎(chǔ)，以Quagga軟件為路由引擎，通過OpenFlow控制器為數(shù)據(jù)平面提供路由邏輯控制策略.實(shí)驗(yàn)結(jié)果表明，該方案不僅讓SDN網(wǎng)絡(luò)具有了路由轉(zhuǎn)發(fā)功能，還能使系統(tǒng)保持較好的穩(wěn)定性.

軟件定義網(wǎng)絡(luò)；路由轉(zhuǎn)發(fā)；OpenFlow技術(shù)；RouteFlow平臺

隨著云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)等新技術(shù)新應(yīng)用的爆發(fā)式增長，導(dǎo)致傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)承載的功能不斷擴(kuò)大，也愈發(fā)復(fù)雜，變得越來越難以適應(yīng)當(dāng)前的網(wǎng)絡(luò)環(huán)境.為了解決這些問題，很多國家和地區(qū)都開展了下一代互聯(lián)網(wǎng)研究，例如美國GENI項(xiàng)目、日本JGN2plus項(xiàng)目、歐盟RIRE項(xiàng)目以及我國FINE項(xiàng)目等[1].誕生于美國GENI項(xiàng)目資助下的軟件定義網(wǎng)絡(luò)(SDN)架構(gòu)[2]就是其中的代表.與傳統(tǒng)網(wǎng)絡(luò)架構(gòu)相比，SDN架構(gòu)能提供一個(gè)更加靈活、可編程、與廠商無關(guān)的創(chuàng)新型網(wǎng)絡(luò)框架，其核心是OpenFlow技術(shù)[3].

但是，由于SDN技術(shù)目前正處于發(fā)展初期，現(xiàn)有的SDN路由機(jī)制主要是二層技術(shù).其不同子網(wǎng)之間的互聯(lián)，主要采用的是Vlan Translation技術(shù)、隧道技術(shù)等，不能很好的融合網(wǎng)絡(luò)層路由協(xié)議[4].本文針對SDN的路由問題，借助RouteFlow平臺，設(shè)計(jì)通過POX控制器根據(jù)路由組件提供的邏輯控制策略使得SDN網(wǎng)絡(luò)具有路由轉(zhuǎn)發(fā)功能.

1 OpenFlow與SDN

OpenFlow起源于美國斯坦福大學(xué)的Clean Slate項(xiàng)目組.2008年，該項(xiàng)目組的主要負(fù)責(zé)人Nick McKeown教授首次向人們詳細(xì)地介紹OpenFlow技術(shù)，引發(fā)學(xué)術(shù)界的廣泛關(guān)注[5].隨后，在2009年，McKeown等研究者又提出了SDN概念.到了2011年，Google、Facebook等業(yè)界巨頭推動成立了開放網(wǎng)絡(luò)基金會(Open Networking Foundation，ONF)組織[6]，正式提出軟件定義網(wǎng)絡(luò)的概念并制定SDN標(biāo)準(zhǔn)化工作，同時(shí)把OpenFlow技術(shù)列為唯一的南向接口協(xié)議.從此，SDN技術(shù)引發(fā)全球浪潮.

1.1 OpenFlow技術(shù)

OpenFlow包括三個(gè)方面的技術(shù):OpenFlow交換機(jī)(OF交換機(jī))、OpenFlow協(xié)議和OpenFlow控制器.在OpenFlow v1.0中，OF交換機(jī)則主要包含流表(Flow Table)和安全通道(Secure Channel)這兩個(gè)部分.流表是指針對特定的“流”的策略表項(xiàng)的一種抽象集合，負(fù)責(zé)OF交換機(jī)上的數(shù)據(jù)的查詢與轉(zhuǎn)發(fā).安全通道承載著OpenFlow協(xié)議消息，負(fù)責(zé)傳遞OF交換機(jī)與控制器的之間所有的管理與控制信息[7]，其重要性不言而喻.隨著OpenFlow版本的不斷更迭，OF交換機(jī)內(nèi)部結(jié)構(gòu)也在不停地變化,見圖1.

圖1 OpenFlow v1.0、v1.1和v1.5對比圖Figure 1 Comparison of OpenFlow v1.0,v1.1 and v1.5

從圖1中可以清晰地看出，在v1.1版的OF交換機(jī)中，增加了“流水線+組表”這樣的體系架構(gòu)[8].這樣的改進(jìn)主要是為解決流表的轉(zhuǎn)發(fā)性能，于是該架構(gòu)在后續(xù)OpenFlow協(xié)議的版本中一直得到沿用.在v1.5中OF交換機(jī)又增加了“計(jì)量表+端口”這樣的架構(gòu)[9]，可實(shí)現(xiàn)各種簡單的QoS功能，比如限制速率等.若再結(jié)合每個(gè)“端口”的“隊(duì)列”，還可以實(shí)現(xiàn)更加復(fù)雜的QoS框架.

流表的功能類似于傳統(tǒng)的MAC地址表或路由表，但還是和這些傳統(tǒng)的網(wǎng)絡(luò)設(shè)備有許多不同.流表具有各種層次的網(wǎng)絡(luò)特征，其轉(zhuǎn)發(fā)規(guī)則也有更多的形式，包含的信息量也更加復(fù)雜[10].流表是OF交換機(jī)的關(guān)鍵部分，OpenFlow控制器通過部署流表來指導(dǎo)數(shù)據(jù)平面.從2009年ONF組織發(fā)布的第一個(gè)正式版本OpenFlow v1.0，到2014年推出OpenFlow v1.5，流表組成部分的名稱以及內(nèi)容也在不斷地演變和完善，具體變化過程如圖2.

在2014年最新的OpenFlow v1.5版本中，流表項(xiàng)變成主要由以下七部分組成[9].

?匹配域:其功能主要是對數(shù)據(jù)包進(jìn)行匹配，它包含很多匹配項(xiàng)，包括數(shù)據(jù)鏈路層到傳輸層的大部分標(biāo)識.

?優(yōu)先級:表示當(dāng)流表在OF交換機(jī)中發(fā)生沖突時(shí)，流表項(xiàng)執(zhí)行的先后次序，優(yōu)先級高的先匹配，低的后匹配.它和匹配域聯(lián)合定義了一個(gè)唯一的流表項(xiàng).

?計(jì)數(shù)器:不斷更新需要匹配的數(shù)據(jù)包的計(jì)數(shù)，主要是用來統(tǒng)計(jì)OF交換機(jī)中的全部數(shù)據(jù)流量的相關(guān)信息.

?指令:用于指示OF交換機(jī)在收到匹配的數(shù)據(jù)包后應(yīng)該怎么樣處理這個(gè)數(shù)據(jù)包.

當(dāng)然，事實(shí)上，周小羽到了我們嶺北周村之后，麻糍基本上是天天有得吃的。也就是說麻糍不管有沒有被賣光，周麻糍總會留個(gè)一小塊麻糍回來。

?超時(shí)定時(shí)器:表示一個(gè)流在失效前最長的有效時(shí)間或最大的空閑時(shí)間.

?Cookie:其功能是被控制器用來過濾流統(tǒng)計(jì)數(shù)據(jù)、流改變或流刪除，但在處理數(shù)據(jù)包時(shí)不使用.

?Flags:表示改變流表項(xiàng)被管理的方式.

圖2 OpenFlow各版本中流表的結(jié)構(gòu)變化Figure 2 Change of the flow table in various OpenFlow edition

2 系統(tǒng)設(shè)計(jì)

2.1 路由與RouteFlow

路由作為網(wǎng)絡(luò)的基礎(chǔ)功能，是一個(gè)網(wǎng)絡(luò)所必備的.然而傳統(tǒng)網(wǎng)絡(luò)的路由技術(shù)并不能直接應(yīng)用于OpenFlow環(huán)境中.目前，在OpenFlow環(huán)境中最具有代表性的路由解決方案當(dāng)屬巴西RouteFlow項(xiàng)目[11].RouteFlow通過由一組虛擬機(jī)組成的虛擬網(wǎng)絡(luò)，利用虛擬機(jī)中運(yùn)行的現(xiàn)有路由協(xié)議產(chǎn)生路由表以及路由交互報(bào)文，最后通過POX控制器使用這些表項(xiàng)和報(bào)文控制OF交換機(jī)完成轉(zhuǎn)發(fā)功能.其結(jié)構(gòu)概念如圖3.

RouteFlow平臺的邏輯結(jié)構(gòu)主要由三大部分組成:虛擬路由，控制協(xié)調(diào)和控制器[12]，如圖4.RFServer是平臺的核心，主要用來動態(tài)維護(hù)整個(gè)系統(tǒng)的拓?fù)浣Y(jié)構(gòu)，以及處理來自RFProxy和RFClient的RouteFlow消息.數(shù)據(jù)庫(DB)是各組件之間進(jìn)程通信或遠(yuǎn)程過程調(diào)用的通道.虛擬路由部分是由內(nèi)核虛擬化技術(shù)(LXC)來實(shí)現(xiàn)，主要由Quagga和RFClient組成.RFProxy的主要功能是把RFServer發(fā)送的RouteFlow消息解析為OpenFlow命令，并通過控制器POX發(fā)送給數(shù)據(jù)平面的OF交換機(jī).

2.2 系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)過程

在OpenFlow環(huán)境中，當(dāng)數(shù)據(jù)包僅在同一網(wǎng)段內(nèi)進(jìn)行轉(zhuǎn)發(fā)時(shí)，只需要OF交換機(jī)組件對其進(jìn)行處理即可，遵循OpenFlow網(wǎng)絡(luò)現(xiàn)有的工作流程[5].但當(dāng)在OF交換機(jī)處理數(shù)據(jù)包跨網(wǎng)段時(shí)，則另需要OpenFlow路由組件提供路由計(jì)算功能，選出最佳路徑，然后通過控制器下發(fā)命令，才能完成流表的最終轉(zhuǎn)發(fā).針對這種相對復(fù)雜的狀況，本文基于RouteFlow平臺，搭建如圖5所示的跨網(wǎng)絡(luò)通信拓?fù)鋱D.設(shè)計(jì)實(shí)現(xiàn)主機(jī)H1(172.16.1.2/24)到H4(172.16.4.2/24)的跨網(wǎng)段通信.

圖3 RouteFlow結(jié)構(gòu)概念圖Figure 3 Architecture concept of the RouteFlow

圖4 RouteFlow平臺邏輯圖Figure 4 Logical diagram of the RouteFlow platform

圖5 實(shí)驗(yàn)拓?fù)鋱DFigure 5 Experiment topology

根據(jù)底層OF交換機(jī)接口的數(shù)量，對應(yīng)關(guān)系以及IP地址，打開并配置虛擬機(jī)相應(yīng)的接口MAC、虛擬機(jī)端口以及端口對應(yīng)的IP等，具體配置如下表1.主機(jī)H1到H4的跨網(wǎng)段具體通信過程如下:

1)對于主機(jī)H1到H4的ICMP數(shù)據(jù)包，OF交換機(jī)S1在收到后，首先進(jìn)行OpenFlow封裝，主要包含目的IP(172.16.4.2)和原IP(172.16.1.2)等信息，然后發(fā)送給POX控制器(10.132.100.16).

2)RFProxy收到該ICMP數(shù)據(jù)包，由于該報(bào)文中包含了dp_id=1和dp_port=1等信息，與本身維護(hù)的映射關(guān)系表進(jìn)行對比后通過OVS端口發(fā)送給虛擬路由器rfvmA.

3)rfvmA接收到來自O(shè)VS端口發(fā)送來的報(bào)文后，首先改變原先的路由表，然后將該ICMP數(shù)據(jù)包再發(fā)送出去.當(dāng)RFProxy收到發(fā)送來的ICMP報(bào)文后，再通過查找本身維護(hù)的映射關(guān)系表，重定向到對應(yīng)OF交換機(jī)S1的端口.

4)由于之前虛擬路由器rfvmA的路由表發(fā)生了更改，于是RFClient會監(jiān)聽到這些變化并翻譯成對應(yīng)的流表規(guī)則，構(gòu)造出RouteFlow消息并發(fā)送給RFServer.

5)RFServer收到該RouteFlow消息后，通過RFProxy發(fā)送給對應(yīng)的S1.此時(shí)S1中會出現(xiàn)一條新的流表，在該流表中，S1端口1的源mac地址被修改成S1端口2的mac地址，并增加下一跳S2端口2的mac地址，從S1出端口(output:2)發(fā)出.

6)在接下來的報(bào)文中，由于此時(shí)S1中已有重定向的流表，所以先匹配這些流表,然后發(fā)送到S2中，不需要再將協(xié)議包發(fā)送給控制器.S2到S4也是相同的道理，最終該ICMP報(bào)文到達(dá)H4.

3 系統(tǒng)實(shí)現(xiàn)與分析

3.1 流表的方向

在圖6可以看到，去往172.16.4.0/24有兩條鏈路，它們分別是:H1→S1→S2→S4→H4和H1→S1→S3→S4→H4.下面以第一條鏈路為例，分析其具體的通信過程:

1)在OF交換機(jī)S1上，將源mac地址dl_dst=08:11:11:11:11:11，修改成S1端口2的mac地址并增加下一跳S2端口2的mac地址，從S1出端口(output:2)發(fā)出.

2)接著在S2中，將從S1端口2接收的mac地址dl_dst=08:22:22:22:22:22，改為S2端口3的mac地址并增加下一跳S4端口2的mac地址，從S2的出端口(output:3)發(fā)出.

3)最后在S4上，將從S2端口3接收到的源mac地址dl_dst=08:08:42:42:42:42:42，修改成S4端口1的mac地址并增加下一跳h4的mac地址，從S4出端口(output:1)發(fā)出，最終達(dá)到H4.

3.2 路由表與路由路徑

由圖7可以分析出路由條目24.2.2.0/24、34.3.3.0/24、172.16.4.0/24等都是虛擬路由器rfvmA通過OSPF路由協(xié)議學(xué)習(xí)得到，表明虛擬路由器rfvmA已建立路由表，并能正常工作.另外，在圖7中，還可以看出rfvmA去往172.16.4.0/24網(wǎng)段需要經(jīng)過S1的eth2端口(12.1.1.2)或者eth3端口(13.1.1.3).

圖6 H1 ping H4 過程中OF交換機(jī)的流表方向Figure 6 Flow table of OpenFlow switches after H1 ping H4

圖7 虛擬路由器rfvmA中的路由條目Figure 7 Route table of virtual router rfvmA

圖8中可分析得到，數(shù)據(jù)包去往172.16.4.0/24一共有兩條路徑，分別是:12.1.1.2→24.2.2.4→172.16.4.2與13.1.1.3→34.3.3.4→172.16.4.2.

圖8 H1去往H4的路徑Figure 8 The path of H1 to go to H4

綜合以上實(shí)驗(yàn)數(shù)據(jù)表明，數(shù)據(jù)平面中的OF交換機(jī)的流表項(xiàng)走向與其對應(yīng)的虛擬路由器中的路由走向是完全一致，都是沿著H1→S1→S2→S4→H4或者H1→S1→S3→S4→H4.說明數(shù)據(jù)平面通過來自POX控制器下發(fā)的路由策略來對流量進(jìn)行處理，使OF交換機(jī)擁有了路由轉(zhuǎn)發(fā)的能力.

3.3 系統(tǒng)的整體性能

在兩臺系統(tǒng)為Ubuntu 12.04的虛擬機(jī)中安裝流量監(jiān)測工具sFlow，該工具由sFlow Agent和sFlow Collector兩部分組成.Agent作為客戶端，將獲取到的接口統(tǒng)計(jì)信息和數(shù)據(jù)信息封裝成sFlow報(bào)文，發(fā)送到指定的Collector中，由Collector負(fù)責(zé)對sFlow報(bào)文的分析和匯總，生成流量報(bào)告.分別在已部署RouteFlow平臺的虛擬機(jī)VM1中安裝sFlow Collector，在已安裝Mininet(支持OpenFlow1.0協(xié)議)的虛擬機(jī)VM2上安裝sFlow Agent.具體情況如圖9.

圖9 系統(tǒng)性能測試圖Figure 9 System performance test

依次選取8、64、128、256、512、1 024、2 048和4 096 字節(jié)大小的8種數(shù)據(jù)包來檢測網(wǎng)絡(luò)的吞吐量狀況.由圖10可看到，當(dāng)OpenFlow網(wǎng)絡(luò)開啟路由功能時(shí)，系統(tǒng)的吞吐量會有一定的影響，但是影響是有限的，所以總體來說系統(tǒng)性能較為穩(wěn)定.

圖10 系統(tǒng)的吞吐量測試Figure 10 System throughput test

4 結(jié) 語

軟件定義網(wǎng)絡(luò)技術(shù)具有廣闊的應(yīng)用前景，是下一代網(wǎng)絡(luò)技術(shù)發(fā)展的新方向.路由功能對一個(gè)網(wǎng)絡(luò)的運(yùn)行和擴(kuò)展都至關(guān)重要.鑒于目前SDN網(wǎng)絡(luò)實(shí)現(xiàn)路由功能不理想，本文通過設(shè)計(jì)，解決了在SDN環(huán)境下，不同網(wǎng)段間主機(jī)的通信問題，使SDN網(wǎng)絡(luò)實(shí)現(xiàn)路由轉(zhuǎn)發(fā)功能.實(shí)驗(yàn)結(jié)果表明，當(dāng)整個(gè)系統(tǒng)開啟路由功能時(shí)，不僅保證了流量可以在不同網(wǎng)段間成功轉(zhuǎn)發(fā)，而且還能保持較為穩(wěn)定的性能.

[1] 左青云，陳鳴，趙廣松，等.基于OpenFlow的SDN技術(shù)研究[J].軟件學(xué)報(bào)，2013，24(5):1078-1094. ZUO Q Y，CHENG M，ZHAO G S, et al.Research on OpenFlow-based SDN technologies [J].Journal of Software，2013，24(5):1078-1094.

[2] 黃韜,劉江,趙廣松，等.未來網(wǎng)絡(luò)體系架構(gòu)研究綜述[J].通信學(xué)報(bào),2014,35(8):184-197. HUANG T, LIU J, ZHAO G S, et al. Survey of research on future network architectures[J]. Journal on Communications，2014，35(8):184-197.

[3] MCKEOWN N， ANDERSON T，BALAKRISHNAN H，et al.OpenFlow: Enabling innovation in campus networks[J].ACM SIGCOMM Computer Communication Review,2008，38(2):69-75.

[4] 侯長逸.OpenFlow網(wǎng)絡(luò)軟件路由研究[J].蘭州大學(xué)學(xué)報(bào)(自然科學(xué)版)，2013，49(2):260-263. HOU C Y.Research on the routing mechanism in Open Flow networks[J].Journal of Lanzhou University (Natural Sciences)，2013，49(2):260-263.

[5] 鄧書華，盧澤斌，羅成程，等.SDN研究簡述[J].計(jì)算機(jī)應(yīng)用研究，2014，31(11):3208-3213. DENG S H，LU Z B，LUO C C，et al.Outline of software defined networking[J].Application Research of Computers，2014，31(11):3208-3213.

[6] 張朝昆，崔勇，唐翯祎，等.軟件定義網(wǎng)絡(luò)(SDN)研究進(jìn)展[J].軟件學(xué)報(bào)，2015，26(1):65-76. ZHANG C K，CUI Y，TANG H Y，et al.State-of-the art survey on software-defined networking(SDN)[J].Journal of Software，2015，26(1):65-76.

[7] 吳許俊，王永利.基于POX的軟件定義網(wǎng)絡(luò)平臺的研究與實(shí)踐[J].計(jì)算機(jī)測量與控制，2013，21(12):3414-3417. WU X J，WANG Y L. Research and practices of software defined network based on POX[J]. Computer Measurement & Control，2013，21(12):3414-3417.

[8] 曾珊，陳剛，齊法制.軟件定義網(wǎng)絡(luò)性能研究[J].計(jì)算機(jī)科學(xué),2015，42(6A):243-248. ZENG S，CHEN G, QI F Z. Survey on performance of software defined networking[J]. Computer Science，2015，42(6A):243-248.

[9] Open Networking Foundation(ONF).OpenFlow Switch Specification[EB/OL].(2017-03-02) [2014-12-19]. https://www.openetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.0.pdf.

[10] 張俊帥，楊昊.OpenFlow交換機(jī)流表轉(zhuǎn)發(fā)設(shè)計(jì)與實(shí)現(xiàn)[J].中國計(jì)量學(xué)院學(xué)報(bào),2015，26(3):316-323. ZHANG J S，YANG H.Design and implementation of OpenFlow switch flow table forwarding [J].Journal of China University of Metrology，2015，26(3):316-323.

[11] MARCELO R，CHRISTIAN E，MARCOS R，et al. Virtual routers as a service: the RouteFlow approach leveraging software-defined networks[C]//Proceedings of the 6th International Conference on Future Internet Technologies.Seoul:ACM，2011:34-37.

[12] 蔣浩海，黃小紅.基于OpenFlow平臺的路由實(shí)驗(yàn)研究與實(shí)現(xiàn)[J].小型微型計(jì)算機(jī)系統(tǒng)，2015，36(10):2300-2304. JIANG H H，HUANG X H.Research and implementation of network experiment based on OpenFlow platform[J].Journal of Chinese Computer Systems，2015，36(10):2300-2304.

Design and implementation of routing in SDN network environment

REN Huan, ZHOU Hangxia

(College of Information Engineering, China Jiliang University, Hangzhou 310018, China)

As a new type of network architecture, software defined network (SDN) can separate the data and control planes. Aiming at the problem that the SDN network can not provide the routing service, this paper proposed an openflow protocol-based method of implementing the routing and forwarding function for SDN. This solution relied on the RouteFlow platform. It was based on LXC and took Quagga as a routing engine. It provided the logic control strategy of routing by the OpenFlow controller. The experimental result shows that this solution can help the SDN network realize the function of routing forwarding and can also ensure the stable performance of the system.

software defined network; routing forwarding; OpenFlow; RouteFlow platform

2096-2835(2017)02-0219-07

10.3969/j.issn.2096-2835.2017.02.014

2017-03-02 《中國計(jì)量大學(xué)學(xué)報(bào)》網(wǎng)址：zgjl.cbpt.cnki.net

任歡(1989-)，男，安徽省六安人，碩士研究生，主要研究方向?yàn)檐浖x網(wǎng)絡(luò)、網(wǎng)絡(luò)虛擬化. E-mail: nokia_hp@163.com 通信聯(lián)系人：周杭霞，女，教授.E-mail:zhx@cjlu.edu.cn

TP393

A