任 歡，周杭霞

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

SDN環(huán)境下網(wǎng)絡路由的設計與實現(xiàn)

任 歡，周杭霞

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

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

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

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

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

1 OpenFlow與SDN

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

1.1 OpenFlow技術

OpenFlow包括三個方面的技術:OpenFlow交換機(OF交換機)、OpenFlow協(xié)議和OpenFlow控制器.在OpenFlow v1.0中，OF交換機則主要包含流表(Flow Table)和安全通道(Secure Channel)這兩個部分.流表是指針對特定的“流”的策略表項的一種抽象集合，負責OF交換機上的數(shù)據(jù)的查詢與轉發(fā).安全通道承載著OpenFlow協(xié)議消息，負責傳遞OF交換機與控制器的之間所有的管理與控制信息[7]，其重要性不言而喻.隨著OpenFlow版本的不斷更迭，OF交換機內部結構也在不停地變化,見圖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交換機中，增加了“流水線+組表”這樣的體系架構[8].這樣的改進主要是為解決流表的轉發(fā)性能，于是該架構在后續(xù)OpenFlow協(xié)議的版本中一直得到沿用.在v1.5中OF交換機又增加了“計量表+端口”這樣的架構[9]，可實現(xiàn)各種簡單的QoS功能，比如限制速率等.若再結合每個“端口”的“隊列”，還可以實現(xiàn)更加復雜的QoS框架.

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

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

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

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

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

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

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

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

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

?Flags:表示改變流表項被管理的方式.

圖2 OpenFlow各版本中流表的結構變化Figure 2 Change of the flow table in various OpenFlow edition

2 系統(tǒng)設計

2.1 路由與RouteFlow

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

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

2.2 系統(tǒng)設計實現(xiàn)過程

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

圖3 RouteFlow結構概念圖Figure 3 Architecture concept of the RouteFlow

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

圖5 實驗拓撲圖Figure 5 Experiment topology

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

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

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

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

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

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

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

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

3.1 流表的方向

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

1)在OF交換機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ā)出，最終達到H4.

3.2 路由表與路由路徑

由圖7可以分析出路由條目24.2.2.0/24、34.3.3.0/24、172.16.4.0/24等都是虛擬路由器rfvmA通過OSPF路由協(xié)議學習得到，表明虛擬路由器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交換機的流表方向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ù)據(jù)表明，數(shù)據(jù)平面中的OF交換機的流表項走向與其對應的虛擬路由器中的路由走向是完全一致，都是沿著H1→S1→S2→S4→H4或者H1→S1→S3→S4→H4.說明數(shù)據(jù)平面通過來自POX控制器下發(fā)的路由策略來對流量進行處理，使OF交換機擁有了路由轉發(fā)的能力.

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

在兩臺系統(tǒng)為Ubuntu 12.04的虛擬機中安裝流量監(jiān)測工具sFlow，該工具由sFlow Agent和sFlow Collector兩部分組成.Agent作為客戶端，將獲取到的接口統(tǒng)計信息和數(shù)據(jù)信息封裝成sFlow報文，發(fā)送到指定的Collector中，由Collector負責對sFlow報文的分析和匯總，生成流量報告.分別在已部署RouteFlow平臺的虛擬機VM1中安裝sFlow Collector，在已安裝Mininet(支持OpenFlow1.0協(xié)議)的虛擬機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)絡的吞吐量狀況.由圖10可看到，當OpenFlow網(wǎng)絡開啟路由功能時，系統(tǒng)的吞吐量會有一定的影響，但是影響是有限的，所以總體來說系統(tǒng)性能較為穩(wěn)定.

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

4 結 語

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

[1] 左青云，陳鳴，趙廣松，等.基于OpenFlow的SDN技術研究[J].軟件學報，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)絡體系架構研究綜述[J].通信學報,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)絡軟件路由研究[J].蘭州大學學報(自然科學版)，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].計算機應用研究，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)絡(SDN)研究進展[J].軟件學報，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)絡平臺的研究與實踐[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)絡性能研究[J].計算機科學,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交換機流表轉發(fā)設計與實現(xiàn)[J].中國計量學院學報,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平臺的路由實驗研究與實現(xiàn)[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 《中國計量大學學報》網(wǎng)址：zgjl.cbpt.cnki.net

任歡(1989-)，男，安徽省六安人，碩士研究生，主要研究方向為軟件定義網(wǎng)絡、網(wǎng)絡虛擬化. E-mail: nokia_hp@163.com 通信聯(lián)系人：周杭霞，女，教授.E-mail:zhx@cjlu.edu.cn

TP393

A