可編程數據平面的業務相關路由方法

吳 博，吳 靜，羅 威，朱 劼

1.武漢大學 電子信息學院，武漢430072

2.中國艦船研究設計中心，武漢430064

1 引言

面對越來越豐富的網絡業務，人們對于網絡服務質量的要求也不斷提高。如何靈活調度網絡資源，實現特定業務流量的路徑規劃成為一個問題。軟件定義網絡中將交換機的控制和轉發解耦，形成一種由數據面、控制面和應用面組成的三層架構。控制器具有全局邏輯視圖，交換機成為簡單的轉發設備，實現了對網絡進行集中式的管理。

在SDN框架下，控制器對網絡節點進行全局的控制，通過對網絡狀態的收集，實現了對數據流的全局調度。文獻[1]提出一種方法，根據鏈路間的距離、帶寬等因素周期性地更新網絡狀態，計算出多條路徑，然后在其中選出一條鏈路利用率最小的路徑進行流量傳輸，即使網絡出現故障也可以動態調節，但是該方法沒有考慮業務的屬性；文獻[2]通過SDN控制器對數據層的網絡節點進行探測，根據鏈路帶寬，應用ECMP實現路由選路，提高了網絡的負載均衡度；文獻[3]使用鏈路的時延帶寬作為選路約束，將問題抽象為多約束問題，對于優先級別高的數據進行優先路由，但是這種方法只保證了一種數據流的屬性；文獻[4]通過在控制器中實行基于DPI的流量分類技術，根據流的需求，動態分配帶寬給流，從而提高流的QoS，但是控制器運行dpi引擎需要較高CPU資源，當網絡繁忙或網絡規模大時，控制器負荷較大。文獻[5]通過控制器向交換機發起packet_in指令獲取流的ToS字段，以此判斷業務類型并利用K最短路徑算法為該業務進行路由，但是此方法需要控制器對于每條流都發起詢問，效率很慢。以上方法普遍通過控制器的全局視野，利用獲取到的網絡參數，在算法上進行改進實現路由規劃，數據平面只是作為單純的轉發設備進行轉發操作，在處理流量時，并沒有為流量業務屬性進行快速的劃分。

可編程數據平面[6]拓寬了對網絡自定義的能力。通過改進可編程數據平面的處理流水線，對解析器、匹配器和處理器進行編程，可以實現對業務的識別；同時，可編程數據平面支持對TCP/IP協議外的新型網絡協議數據包的處理，可以實現數據包本身對網絡狀態進行采集。這為網絡帶來了巨大的靈活性。

根據3GPP對網絡中數據流的分類，可分為：信息會話類業務、數據傳輸類業務、流媒體業務、網絡交互類業務[7]。根據業務類型的不同，數據在網絡傳輸中會有不同的傳輸需求。例如，對于會話類型的業務，此類業務數據量一般較小，但是需要保證業務數據及時的交付，因此此類業務要求傳輸延時一定要小，而對帶寬沒有特殊的要求；而對于類似文件傳輸、視頻點播這種業務，由于其傳輸的數據量大，因此對網絡的帶寬有較高的要求，而對時延并不敏感。

本文在SDN的框架下，結合可編程數據平面的特性，通過重新定義交換機處理數據包的流程，提出一種基于業務屬性的路由方法，可以在數據平面上實現業務的自動區分和網絡鏈路狀態的收集，并在控制面上為不同業務選路。最后通過搭建實驗平臺驗證了本文所提方法的可行性和有效性。

2 方案分析與設計

為了實現一種業務相關的路由選路，需要考慮以下問題。

（1）首先，為了分擔控制面上的處理壓力，應該如何在數據面上協助實現業務流量的自動識別。

在SDN架構下，數據面上的交換機是一種白盒設備，往往僅做匹配轉發動作，自身并沒有決策能力，所有分析決策能力被集中在控制器上，這就導致了控制器的處理壓力巨大。并且交換機將功能固化在芯片中，嚴重依賴于廠商，在協議擴展上不具有靈活性且更新周期長。而在可編程數據平面上，由于不再受限于傳統的TCP/IP協議棧的束縛，可以自定義數據包的結構，通過改變交換機處理數據包的業務邏輯，識別包頭中的特定字段，就可以實現數據面對于流量的自動識別，分擔了控制面的處理壓力。

（2）其次，在獲取網絡鏈路參數時，應該如何確保信息的時效性。

為了能夠保證業務傳輸的需求，只有獲取了網絡的狀態參數，才能以此作為依據為業務數據選擇一條符合傳輸要求的路徑。對于網絡鏈路參數的采集[8]，大多普遍采用南向接口，例如通過OpenFlow輪詢獲取交換機的信息推算出鏈路的狀態[9]；或者通過在交換機上安放sflow周期性采樣[10]；或者通過額外流量探針探測網絡的狀態[11]。這些方法收集的數據細粒度大，準確度低，不能很好地反映當前的網絡狀態。而在可編程交換機上，可以在數據包上嵌入所需要的交換機內部信息，例如時間信息、隊列信息、出口計數器的信息等[12]，這樣每當數據包流經交換機，測量信息隨著業務流量進行傳輸。由于測量數據為傳輸過程中交換機本身的數據，細粒度高，可以很好地反映網絡的狀態。

（3）最后，如何針對特定業務，規劃出適合不同業務的路徑。

不同業務在傳輸中對網絡狀態的要求不同，為了能夠實現在全網中根據業務的要求進行選路，需要針對性地改進選路算法。在算法中，面對不同業務類型的流量，特定的改變算法中的約束條件，使之規劃出的路徑能夠滿足傳輸要求，保證業務質量。

基于上述問題，在數據面上采用可編程交換機，發揮可編程交換機的可自定義的優勢，利用P4[13]（Programming Protocol-Independent Packet Processors）語言對其進行編程，改變數據轉發流水線的邏輯，實現業務流量的自動劃分，分擔控制器的處理壓力，同時對網絡鏈路的狀態參數進行采集；在控制器上根據收集到的鏈路狀態信息，由選路應用為不同業務規劃路徑。因此本文提出的基于可編程數據平面的業務路由（Business Routing Based on Programmable DataPlane，BR-DP）總體框架如圖1所示。

圖1 總體架構圖

3 方案實現

3.1 業務分類與識別

在數據包的IP包頭中存在6個比特的DSCP字段，用于區分服務代碼。利用這6個比特可以將業務分為4個類型[14]，如圖2所示，分別是類選擇器CS、加速轉發EF、確保轉發AF和默認BE。典型的DSCP值有流式視頻CS4（100000）、交互式語音EF（101110）、大塊數據AF11（001010）等。

圖2 DSCP分類圖

為了能夠在交換機內實現對業務種類的識別并進行相應的操作，需要在原有轉發基礎上改進交換機對于數據包的處理流水線，增加對特定字段的匹配操作實現對業務的識別，在識別到業務屬性后將流分配到不同流表中執行對應的轉發規則，整個處理流程如圖3所示。在整個流水線中，可編程交換機對數據的處理基于“匹配-動作”模式。

首先，進入“匹配”階段，為了能夠自動識別流量的業務類型，在匹配過程中，包頭解析器不僅需要提取數據包的源地址、目的地址、源端口和目的端口用于基本的轉發，而且要添加對DSCP字段的獲取。通過對DSCP字段進行匹配，交換機可以實現對業務種類的自動識別。當識別到流量所屬業務類型后，就要進入“動作”階段。

圖3 業務處理流程圖

在動作階段中，要在交換機中定義不同的流表，如類選擇器型業務流表、加速轉發型業務流表、確保轉發型業務流表和默認流表。每個流表對應著不同DSCP類型的業務。上層控制器上的選路應用會為不同屬性的業務規劃出相應合適的路徑，并以流規則的形式通過南向接口分發至對應的流表中，指導數據包的轉發規則。數據包在匹配階段中識別到流量業務屬性后，根據業務的屬性，由交換機將數據流分配到不同的流表，并按照流表中的轉發規則進行相應的轉發。

3.2 鏈路狀態信息收集

為了給接下來的選路應用提供選路依據，需要對網絡的鏈路狀態信息進行采集。在可編程數據平面上，可以通過數據包本身攜帶測量信息的方式或者控制器通過南向接口采集的方式，得到多種網絡狀態參數，例如時間、隊列、端口信息等。本文選取時間敏感的語音業務和帶寬敏感的視頻業務為例進行說明，對網絡的鏈路延時和剩余帶寬容量進行采集。

3.2.1時延測量

時延在為對時間敏感型的業務路由規劃時是一項重要的參照指標。本文對于每跳鏈路的時延采集采用帶內測量的方式。首先，利用P4語言編寫可編程交換機處理數據包流程，根據需求，可以指定需要測量的具體指標，每個交換機根據指令會將相應的指標嵌入到數據包中。編譯好的文件經由控制器通過南向接口部署到每臺交換機上。其次，控制器具有全局視圖，可以獲知交換機是否處于數據包傳輸路徑上的邊緣節點。當正常的數據包進入到網絡中，在開始的邊緣節點交換機上會被打入帶內測量指令標簽。然后，數據包流經每臺交換機，交換機根據指令，將自己的內部信息封裝到每個包頭里。最后，在最后一跳交換機上，控制器識別并指導交換機彈出帶內測量信息報告，剩余部分恢復為正常數據包交付到目的主機，流程如圖4所示。

當數據包通過每個交換機時，交換機在每個數據包頭上嵌入此數據包從入口進入交換機的時間戳，那么數據包從這一跳的i交換機到下一跳的j交換機的鏈路延時dij如公式（1）所示，其中包括了這一跳鏈路的處理延時、排隊延時、傳輸延時和傳播延時。

圖4 帶內測量示意圖

3.2.2 剩余帶寬測量

每條鏈路的剩余帶寬對于帶寬敏感型的業務流量有重要意義。在可編程交換機中，通過編程在每個表項添加一個計數器counter。每完成一次流表項匹配操作后對計數器進行更新，這樣就可以記錄每個端口流經的包的個數和比特大小。在每一個測量周期Δt內，通過南向接口命令來獲取counter的值，在每次獲取到值后再將counter清零，以此來記錄這段測量周期內流經的數據信息。

對于交換機Si的i端口，在一個測量周期內發送的數據包字節數為tx_bytes，接收到的數據包字節數為rx_bytes，則鏈路的輸入吞吐率和輸出吞吐量分別如公式（2）和（3）所示：

那么數據占用的帶寬B(Sii)和剩余帶寬B_available(Sii)如公式（4）和（5）所示：

3.3 選路實現

3.3.1 算法基礎

蟻群算法[15]是一種受啟于蟻群覓食行為的算法。相比于傳統路由算法，蟻群算法簡單，收斂速度快，可以動態地適應網絡拓撲的變化，具有極高的適應性和擴展性，且是一種全局搜索算法，能夠有效地避免局部最優。

獲取到了每段鏈路的延時和剩余帶寬后，就可以構建網絡的延時矩陣和剩余帶寬矩陣，用延時和剩余帶寬取代路徑長短的概念，將問題抽象為網絡模型如公式（6）描述：

網絡中有i個節點，j條邊，用圖G(N,E)表示，其中節點n1,n2,…,ni的集合為N，表示每個交換機代表一個節點；邊e1,e2,…,ej的集合為E，表示每兩個節點間的鏈路。

基本的蟻群算法描述如下，螞蟻k從i節點到j節點的跳轉概率如公式（7）：

其中，τij(t)為在時間t時刻鏈路eij殘留的信息素；ηij(t)為選擇下一跳為新路徑的啟發函數；α作為信息素函數的作用系數，表示在螞蟻選路的過程中信息素的影響能力；β為啟發函數的作用系數，表示選路過程中受啟發函數的影響能力。對于作用系數來說，如果α越大，信息素的影響力就越強，會造成局部最優的狀況，而β越大，啟發函數的影響能力越強，選擇路徑時更加隨機，會造成收斂慢的狀況。nodesk為螞蟻下一跳可選的路徑節點集合，為了防止螞蟻走回路狀況的出現，每當走過一個節點，就從nodesk集合中剔除這個節點。

在尋路過程中，螞蟻走過的路徑會留下信息素，而信息素也在不停的揮發，因此，網絡中路徑的信息素會不停的更新。因此信息素按照公式（8）和（9）進行更新。

其中，ρ為揮發系數，(1-ρ)為信息素剩余系數，因此下一時刻的信息素濃度為上一時刻剩余信息素濃度與信息素濃度增量的和。其中Q為信息素濃度強度，Lk表示螞蟻k所經過的路徑長度。

3.3.2 參數重定義

在經典蟻群算法中，路徑長短作為影響因子。為了適應對于不同業務傳輸過程中的不同的需求，引入獲取得到的鏈路指標作為選路的參考信息。在判定業務類型后，將對應的網絡性能參數運用在啟發函數和信息素更新的計算中，實現對不同業務的路由。

針對不同業務在網絡傳輸中的需求不同，對應改變算法中的參數設置。當業務判定為時延敏感的語音業務時，令啟發函數ηij(t)=1/dij(t)，信息素更新函數中的Lk為所經過路徑的延遲之和，表示延時越低，留下的信息素越多；當業務判定為帶寬敏感的視頻業務時，令啟發函數ηij(t)=B_availableij(t)，信息素更新函數中的Lk為所經過路徑的剩余帶寬之和的倒數，表示剩余帶寬越多，留下的信息素就越多。

3.3.3算法流程

基于業務性質的選路步驟如圖5所示。

圖5 算法流程圖

根據不同的啟發函數，分別為時延和帶寬生成兩條最優路徑，通過控制器分別下發到路徑上的交換機的對應的流表中。當數據經過交換機時，交換機會匹配包頭中的DSCP字段，判斷數據包所屬的業務類型，然后執行對應流表中的轉發規則，以此實現流量的業務屬性自動識別和轉發。

4 實驗與評估

4.1 仿真平臺搭建

園區網中承載著文件傳輸，視頻點播，語音聊天等各種業務，為了模擬這一場景，驗證本文方法的可行性，利用mininet搭建小型網絡拓撲，其中使用的交換機是支持P4語言的bmv2交換機，拓撲如圖6所示。

圖6 實驗拓撲圖

圖中包含8臺bmv2交換機，設定每條鏈路帶寬為80 Mb/s，延遲3 ms。同時為了模擬真實的網絡場景，讓H1用iperf分別向H2～H5主機打UDP流量作為背景流量。實驗過程中，以H1為發送端，H6為接受端，以5 Mb/s的增幅分別傳輸DSCP為101110和100000的流量，以此模擬語音業務和視頻業務。

配合網絡節點的數量，設置蟻群的參數初始值，其中螞蟻數量為30，迭代50次，信息素和啟發函數的啟發因子分別為1和5，揮發系數0.5，總量Q為10。根據獲得的延時拓撲和剩余帶寬拓撲，分別為不同業務生成相關路由規劃策略，以流表項的形式下發至交換機中。

4.2 性能比較

對比實驗中，數據平面向控制平面發送OpenFlow信息，控制器通過解析ToS字段判定業務屬性；并通過對OpenFlow攜帶的信息進行處理，獲取到鏈路的狀態，而控制器的選路采用蟻群算法，稱這種基于OpenFlow的方法為BR-OF。另一個對比實驗中，業務的判斷以及網絡狀態的采集同樣采用OpenFlow信息獲取，而控制器的選路應用采用K最短路徑算法，利用多元素的路徑權值進行路由規劃，簡稱為BR-K。本文設置四個對比實驗，分別從端到端響應時間、時延和吞吐量比較三種方法在業務識別時的響應速度和最終的選路效果以及在本文方法下不同業務的表現。

（1）端到端響應時間比較

首先觀察端到端響應時間的表現，即從源主機發送數據到目的主機接收所經過的時間。為了盡量減少鏈路時延對于結果的影響，讓三種方法下路由算法輸入的鏈路參數一致，并采用視頻流量進行實驗。實驗中，對業務流量處理方法不同，導致對業務流量響應的時間也不相同。在BR-OF、BR-K方法中，當數據包輸入網絡后，控制器會發起OpenFlow請求，通過OpenFlow詢問數據流量所屬的業務，在判斷業務屬性后，為該流進行路由計算，在整個過程中，OpenFlow信息的傳輸和路由計算都會產生額外時間；而本文的BR-PD方法，業務屬性的判斷發生在交換機解析數據包的過程中，節約了控制器詢問的時間；在判別數據所屬業務后，數據會執行對應流表中的表項，進行相應的轉發，而流表中的轉發規則是控制器周期性獲取鏈路狀態后預先下放的，這也節約了一部分路由計算的時間。因此由圖7可知，在同樣的場景設定下，BR-PD的端到端響應時間要明顯低于BR-OF和BR-K，同時，隨著源主機發送業務速率的提高，響應時間呈上升趨勢，這可能由于隨著負載的加重，擁塞導致的延時變大。由此可以說明，BR-PD在自動識別業務響應速度方面有一定優勢。

（2）延時比較

圖7 端到端響應時間

在另一組實驗中，觀察語音流在不同方法下的延時情況。如圖8所示，可以看到BR-PD下的延時明顯低于BR-OF和BR-K。這是因為，在BR-OF和BR-K中，鏈路延時的采集是通過在兩個節點間反復發送OpenFlow信息，然后整合這些信息推算出測量時刻的鏈路延時，推算過程中包含控制器到交換機間的rtt；另外，測量的延時反映的僅僅是測量那一時刻的鏈路狀態，而鏈路的延時是一個時變的參數，因此BR-OF和BR-K方法獲取的鏈路延時不夠準確。并且，BR-K是將多個鏈路參數加權進行選路的，因此對于只單純從延時角度看不占優勢。而BR-PD方法采用帶內測量的方式，延時信息是交換機嵌入的自身實時信息，通過收集測量周期內所有的鏈路延時并取平均值，可以反映這段時間該鏈路的延時平均水平，相較于另外兩種方法，獲得的延時信息比較準確。準確的鏈路狀態信息可以為后續的選路提供準確的參考，因此BR-PD方法可以為時間敏感的語音流提供一條延時較小的路徑。

圖8 時延

（3）吞吐量比較

在H1向H6持續10 s發送80 Mb/s的視頻流量，吞吐量結果如圖9所示，可以看到三者的差異并不是很大。這是因為，在獲取鏈路的可用帶寬時，BR-OF、BR-K是通過OpenFlow獲取交換機端口計數器的數據，而BR-PD是通過可編程交換機的P4Runtime接口獲取交換機計數器的數據。三者都是通過南向接口訪問交換機獲取到鏈路端口的使用狀態，因此三者獲取的鏈路可用帶寬信息大同小異，總體上為視頻流規劃的路徑所表現的性能相當，但BR-K是由多參數進行加權選路，單從吞吐量來看結果略遜。

圖9 吞吐量

（4）不同業務比較

在BR-PD方法下，對比語音流和視頻流兩種業務的延時和吞吐量，結果如圖10和圖11所示。可以得知，該方法可以對不同業務進行相應的路由規劃，對于時間敏感的業務，語音流的延時要小于視頻流的；而對于帶寬敏感的業務，視頻流的吞吐量要略大于語音流。

圖10 不同業務時延

圖11 不同業務吞吐量

根據以上的對比結果可以得出，BR-PD方法可以在數據面上快速地自動識別業務流量的屬性，并能為選路應用提供時效性網絡參數，根據不同業務對于網絡的不同需求，可以規劃出合適的路徑進行傳輸，滿足業務的傳輸要求。

5 結束語

本文在SDN的網絡框架下，發揮可編程數據平面的特性，提出了一種數據面與控制面協作的選路方法。在可編程數據面上，通過對字段進行解析，匹配不同的流表，實現了在交換機上快速自動判別數據的業務屬性并進行相應轉發；同時通過帶內測量的方法，在不引入額外網絡負擔的前提下，可以統計到網絡中各個節點的時效性參數。在控制面上，將網絡的實時性能參數應用到蟻群算法中，生成匹配的路由規則并下發至數據面。下一步，將對流量的業務類型做出更細致的區分，并對控制器中的算法進一步優化，使其成為一種更優的路由方案。