張俊

中通服咨詢設計研究院有限公司

0 研究背景

隨著網(wǎng)絡應用的不斷創(chuàng)新與增量部署，運營商網(wǎng)絡需要承載的數(shù)據(jù)流量及業(yè)務信息呈“爆炸式”增長。同時，醫(yī)療、公安及無人駕駛等垂直行業(yè)也對網(wǎng)絡性能不斷提出新的需求，這將給傳統(tǒng)IP網(wǎng)絡帶來巨大的壓力，如果仍采用“盡力而為”的傳輸方式，將難以滿足復雜性和動態(tài)性的需求。為此，運營商通常采用“過度配置”的方式來確保他們所期望的服務質(zhì)量，這將導致大量網(wǎng)絡資源的浪費。并且，傳統(tǒng)IP網(wǎng)絡由交換機、路由器、防火墻以及各種類型的中間件組成，為了能夠在現(xiàn)網(wǎng)中提供相關QoS保障，需要在這些設備中添加繁多的協(xié)議支持，這將使得網(wǎng)絡復雜度越來越高，管理難度不斷上升，最終到達網(wǎng)絡性能瓶頸狀態(tài)。SDN通過解耦轉(zhuǎn)發(fā)平面與控制平面，為上層應用及網(wǎng)絡服務提供商抽象底層網(wǎng)絡基礎設施，提供開放的接口，使得網(wǎng)絡可編程，簡化了網(wǎng)絡的配置與管理，為復雜網(wǎng)絡的QoS保障機制提供了更多的可能性，SDN網(wǎng)絡架構(gòu)如圖1所示。通過邏輯集中的控制平面，能夠獲取全網(wǎng)的拓撲和相關QoS參數(shù)信息，包括鏈路、主機以及交換機等狀態(tài)信息，網(wǎng)絡管理員通過REST API北向接口來制定路由策略，采用OpenFlow南向協(xié)議以更加細粒度的方式處理網(wǎng)絡流量，為應用流選擇最佳的路由路徑，以滿足應用在傳輸過程中的QoS約束需求。

1 傳統(tǒng)QoS保障機制

圖1 SDN架構(gòu)

為了保障應用服務質(zhì)量并且提升端到端網(wǎng)絡性能，在傳輸數(shù)據(jù)流量前，需要在發(fā)送端和接收端之間為每種應用選擇一條最佳路由，這對于緊耦合的IP網(wǎng)絡架構(gòu)而言，實現(xiàn)起來困難。

針對端到端網(wǎng)絡性能的差異化需求，學術界和產(chǎn)業(yè)界均探索出相關解決方案，以下將分析3種經(jīng)典方案：IntServ（Integrated Services，綜合服務）、DiffServ（Differentiated Service，區(qū)分服務）以及MPLS （Multi-Protocol Label Switching， 多協(xié)議標簽交換）。

IntServ由 IETF（The Internet Engineering Task Force， 互聯(lián)網(wǎng)工程任務組）提出，用于在端到端流量傳輸過程中，基于每條流提供QoS保障。在發(fā)送數(shù)據(jù)流量前，應用提出特定QoS約束請求，網(wǎng)絡設備通過RSVP（Resource Reservation Protocol，資源預留協(xié)議）信令協(xié)議在網(wǎng)絡中申請?zhí)囟ňW(wǎng)絡資源，如帶寬、時延等，只有在獲取到確認信息后，網(wǎng)絡設備才開始發(fā)送數(shù)據(jù)流量。雖然該機制能夠有效地滿足應用QoS約束需求，但是在傳輸鏈路中，網(wǎng)絡設備均需支持RSVP信令協(xié)議，存儲與服務相關的網(wǎng)絡狀態(tài)信息，導致網(wǎng)絡負載過高，難以管理，可擴展性較差，并且該機制不適用于較短生命周期的應用流。

為了應對IntServ擴展性差的問題，IETF又提出了DiffServ，該機制基于隊列優(yōu)先級和帶寬分配創(chuàng)建一組不同的服務類型，如帶寬、時延和丟包率等。發(fā)送數(shù)據(jù)流量前，在網(wǎng)絡入口或邊界，檢查數(shù)據(jù)報內(nèi)容，使用預先配置的應用類型進行分類，差分服務類由IP數(shù)據(jù)報報頭的DSCP（Differentiated Services Code Point，差分服務標記字段）來表示，通過這些字段選擇網(wǎng)絡中轉(zhuǎn)發(fā)的節(jié)點，路由器根據(jù)DSCP字段執(zhí)行PHB（Per Hop Behavior，逐跳行為），PHB即轉(zhuǎn)發(fā)設備對報文的處理行為，每個PHB與一種轉(zhuǎn)發(fā)方式或QoS要求相對應，能夠劃分為類選擇器、加速轉(zhuǎn)發(fā)、確保轉(zhuǎn)發(fā)和盡力而為轉(zhuǎn)發(fā)四大類，從而提供一定程度上的QoS保障。然而，由于該機制以相同的方式處理相同類別的數(shù)據(jù)報，且采用逐跳的機制，導致無法適用于基于流的端到端QoS保障。

同樣的，MPLS也由IETF提出，該機制通過標簽技術減少復雜的路由表查找過程。邊界路由器基于FEC（Forwarding Equivalence Class，轉(zhuǎn)發(fā)等價類）在每個報頭添加一個標簽，數(shù)據(jù)報根據(jù)該標簽進行高速的轉(zhuǎn)發(fā)與路由，并且它能夠與IntServ和DiffServ結(jié)合使用。但是該機制部署比較復雜，管理困難，并且屬于靜態(tài)的，用于動態(tài)QoS保障的代價較大。

綜上所述，現(xiàn)有QoS保障機制由于建立在當前互聯(lián)網(wǎng)分布式架構(gòu)之上，缺乏全網(wǎng)資源的動態(tài)監(jiān)控，并且逐跳路由的方式無法動態(tài)地適應當前網(wǎng)絡飛速發(fā)展的需求，因此并不能夠真正意義上便捷有效地為服務提供商、企業(yè)或終端用戶提供端到端QoS保障。

2 基于SDN的QoS保障機制

SDN轉(zhuǎn)控分離、網(wǎng)絡開放可編程等特性，使得網(wǎng)絡管理員能夠簡單高效地在所部署的SDN架構(gòu)中編寫動態(tài)的、定制化的程序，用于管理、配置并優(yōu)化網(wǎng)絡資源。比如通過OpenFlow協(xié)議采集網(wǎng)絡性能參數(shù)，設計并實現(xiàn)了基于遺傳算法的QoS路由算法，能夠快速地找到滿足應用需求的可行路徑。OXP（Open eXchange，開放性可變長協(xié)議）協(xié)議針對多管理域場景，設計了一種高效且支持多模式的東西向接口協(xié)議。同樣的，WE-Bridge采用了完全分布式控制平面，解決了SDN 網(wǎng)絡中單一控制平面所面臨的瓶頸問題，為互聯(lián)網(wǎng)的QoS保障機制提供了一種新的解決思路。以下將分別從SDN架構(gòu)對QoS的支持和OpenFlow協(xié)議對QoS的支持兩個方面進行闡述。

2.1 SDN架構(gòu)對QoS的支持

通過對SDN“3個平面、3個接口”架構(gòu)的研究與分析，可以發(fā)現(xiàn)該架構(gòu)在QoS保障中展現(xiàn)出以下幾項突出優(yōu)勢：

（1）應用感知的流量工程：邏輯集中的控制平面，使得應用層能夠通過控制平面獲取數(shù)據(jù)平面實時的網(wǎng)絡資源信息，并且結(jié)合DPI（Deep Packet Inspection，深度包檢測）技術實現(xiàn)應用分類，網(wǎng)絡管理員能夠定義應用與QoS優(yōu)先級隊列間的映射表，更好地適應動態(tài)的應用需求。

（2）網(wǎng)絡資源監(jiān)控與端到端QoS支持：控制平面通過OpenFlow南向協(xié)議與數(shù)據(jù)平面進行交互，對域內(nèi)網(wǎng)絡資源進行實時監(jiān)控，如鏈路帶寬、鏈路傳輸時延等。

（3）網(wǎng)絡功能虛擬化：在SDN架構(gòu)中，通過OpenFlow南向協(xié)議實現(xiàn)網(wǎng)絡切片，用以創(chuàng)建特殊的專用網(wǎng)絡，適應垂直行業(yè)的差異化需求。

（4）區(qū)分服務：在會話、用戶、設備、應用程序級別上，通過OpenFlow多域匹配的方式，能夠?qū)崿F(xiàn)更加細粒度的網(wǎng)絡控制，并且允許網(wǎng)絡提供商提供不同代價的策略。

（5）多路徑路由：當發(fā)送/接收端之間存在多條物理鏈路時，根據(jù)OpenFlow多匹配域的特性，能夠?qū)崿F(xiàn)多路徑路由，充分合理有效地使用網(wǎng)絡資源。

2.2 OpenFlow協(xié)議對QoS的支持

OpenFlow作為SDN網(wǎng)絡架構(gòu)中南向接口的一種實現(xiàn)方式，由斯坦福大學提出，規(guī)范由ONF（Open Networking Foundation，開放網(wǎng)絡基金會）制定與維護。目前，OpenFlow已經(jīng)從最初的1.0版本發(fā)展到了1.5版本，其中，OpenFlow1.3版本最為穩(wěn)定，被廣泛采用。

1.0版本中包含一個可選項“enqueue”，數(shù)據(jù)流通過依附在端口上的隊列進行轉(zhuǎn)發(fā)，一個OF交換機根據(jù)端口情況，通過OF-CONFIG協(xié)議配置一個或多個隊列，包括Minrate、Maxrate和Experiment 三種參數(shù)，控制器通過南向協(xié)議查詢交換機的隊列信息。但是，該版本只允許單張流表，無法滿足應用的多樣化需求。為此，1.1版本采用多級流表的方式，增加對VLAN和MPLS標簽的匹配以及流量類型的支持。1.2版本中添加了最高速率隊列屬性。

1.3版本通過采用Meter表實現(xiàn)限速功能，結(jié)構(gòu)如圖2所示。每條流表項都能夠在相關指令集中定義一個Meter表，用于限速的實現(xiàn)。一條流表只能綁定一條Meter項，一條Meter項能被多條流表綁定，每個Meter表可以包含一個或多個Meter Bands，用于定義Band類型與速率。

并且，Meter表能夠與“set_queue”隊列設置操作結(jié)合使用，以提供復雜的QoS支持，如DiffServ等。

圖2 Meter表

3 應用場景分析

以下將分別從“多媒體流QoS約束路由”和“域間QoS路由”兩種應用場景進行分析，驗證基于SDN的QoS解決方案的可行性與有效性。

3.1 多媒體流QoS約束路由

近年來，多媒體應用發(fā)展迅猛，如視頻會議、互動游戲和VoIP（Voice over Internet Protocol，網(wǎng)絡電話）等，并且這些應用對端到端網(wǎng)絡帶寬、時延等都有著嚴格的要求，因此需要采用更加復雜且高效的路由協(xié)議來滿足QoS需求。然而，由于現(xiàn)有互聯(lián)網(wǎng)路由協(xié)議無法獲取全局網(wǎng)絡視圖，以及現(xiàn)有QoS保障機制匱乏等局限性，在現(xiàn)網(wǎng)中高效地傳輸多媒體流將面臨各種挑戰(zhàn)。SDN憑借諸多優(yōu)勢為“多媒體流QoS約束路由”提供了一種新的解決方案，采用SDN架構(gòu)的網(wǎng)絡部署方式如圖3所示。首先，通過分流設備，數(shù)據(jù)流量能夠大致被分為兩種隊列，一種是帶有QoS約束的高優(yōu)先級隊列（如視頻會議等），一種是采用“盡力而為”的低優(yōu)先級隊列。

圖3 SDN部署方式

具體流程如下：

（1）SDN控制器采用OpenFlow協(xié)議獲取網(wǎng)絡拓撲及鏈路、節(jié)點信息，并且采集相關QoS參數(shù)信息。

（2）新的應用流到達交換機，由于沒有匹配的流表項，則將報頭通過packet-in消息上送至控制器。

（3）控制器查看報頭信息，區(qū)分應用類型。

（4）如果該應用流不帶有QoS約束需求，則考慮低優(yōu)先級隊列，根據(jù)控制器中的默認路由算法（如迪杰斯特拉算法）進行路由計算，計算結(jié)果為＜發(fā)送端-S2-S3-S5-接收端＞，并采用OpenFlow協(xié)議下發(fā)流表。

（5）如果該應用流帶有QoS約束需求，仍采用迪杰斯特拉算法計算最短路徑，即＜發(fā)送端-S2-S3-S5-接收端＞，當遇到鏈路擁塞、處理時延過大等問題時，難以提供QoS保障。因此，對于帶有QoS約束需求的應用流，需考慮高優(yōu)先級隊列，SDN控制器根據(jù)全網(wǎng)拓撲及鏈路狀態(tài)信息，通過路由模塊計算滿足需求的K條備選鏈路，最終選擇代價最小的鏈路，這類“約束最小代價路徑”問題是NP難度的，可采用LARAC算法進行求解，計算結(jié)果為＜發(fā)送端-S2-S1-S4-S5-接收端＞，并采用OpenFlow協(xié)議下發(fā)流表，該轉(zhuǎn)發(fā)鏈路雖然跳數(shù)更多，但是由于鏈路狀態(tài)更好，所以更加符合QoS的約束需求。

上述分析結(jié)果表明，SDN邏輯集中控制的方式能夠快速響應特定應用對網(wǎng)絡性能的定制化需求，并且通過優(yōu)先級隊列的方式能夠有效地實現(xiàn)多媒體流的QoS約束路由。

3.2 域間QoS路由

傳統(tǒng)網(wǎng)絡針對跨域路由所提供的解決方案，大多是采用BGP（Border Gateway Protocol，邊界網(wǎng)關協(xié)議）。通過分布式部署模型雖然能在一定程度上滿足網(wǎng)絡的擴展性要求，但是“hop-by-hop”的路由決策機制以及基于目的地址前綴的單路徑通告方式，由于路由過程中缺乏協(xié)商，各域內(nèi)的局部最優(yōu)路由無法保證全局最優(yōu)，從而造成用戶的體驗質(zhì)量（Quality of Experience，QoE）下降。SDN網(wǎng)絡具有集中控制、多匹配域等優(yōu)勢，能夠細粒度地實現(xiàn)路由策略的表達，并且，各管理域控制平面都能夠獲取到各自域內(nèi)網(wǎng)絡節(jié)點信息及相關服務質(zhì)量參數(shù)信息，這將為域間交互與協(xié)商帶來諸多便利。多管理域拓撲如圖4所示。

圖4 多管理域拓撲圖

該部署方案采用完全分布式的控制平面，能夠有效地應對網(wǎng)絡不斷擴展的趨勢。其中，轉(zhuǎn)發(fā)設備間不再互相共享網(wǎng)絡狀態(tài)信息，而是通過OpenFlow南向協(xié)議將本地狀態(tài)信息直接發(fā)送給控制平面，各域的控制平面通過與鄰域控制平面間信息的交互，并觸發(fā)協(xié)商，決策域內(nèi)路由以及到下一管理域的域間路由，根據(jù)協(xié)商的結(jié)果，再通過南向接口對數(shù)據(jù)平面進行相應的配置。

路由信息傳遞與更新的具體流程如下：

（1）控制器C1、C2和C3均運行Speaker實例，并且發(fā)生HELLO報文，與相鄰Speaker實例間建立TCP連接。

（2）Speaker間交互OPEN報文，建立鄰居關系后，進入ESTABLISHED模式。

相鄰兩方在ESTABLISHED模式下交互UPDATE報文，完成路由信息的傳遞與更新。C1解析IP報頭信息。若目的IP地址在當前域，則根據(jù)域內(nèi)拓撲及相關QoS參數(shù)信息，根據(jù)本文3.1中所述方案完成域內(nèi)QoS約束路由。若目的IP地址非本域，則根據(jù)NLRI，結(jié)合應用需求及域內(nèi)路由策略，選擇最佳下一管理域C2，觸發(fā)域間協(xié)商。域間協(xié)商與路由的具體流程如下：

（1）C2接收到C1的協(xié)商請求報文后，檢查是否與本域策略沖突，若沖突則直接拒絕；否則根據(jù)協(xié)商請求報文中的應用QoS需求，計算轉(zhuǎn)發(fā)路徑。倘若存在滿足需求的網(wǎng)絡資源，則回復ACCEPT報文及對應的代價信息，否則回復REJECT報文。

（2）倘若目的IP不在C2所管轄的域中，則C1重復以上步驟，與C3進行協(xié)商。

（3）最終，C1如果收到的報文為ACCEPT，代表協(xié)商成功，各控制器根據(jù)協(xié)商結(jié)果配置域內(nèi)交換機。

（4）當控制器發(fā)現(xiàn)域內(nèi)資源無法滿足之前協(xié)商的SLA（Service-Level Agreement，服務等級協(xié)議）約定或域內(nèi)/間鏈路發(fā)送故障時，觸發(fā)協(xié)商通知，及時響應并重路由。

上述分析結(jié)果表明，將SDN架構(gòu)運用于多管理域間的路由，首先能夠降低頻繁路由信息交互帶來的網(wǎng)絡負載；其次，能夠方便地實現(xiàn)管理域間關于應用QoS約束的請求與協(xié)商，以及靈活的SLA約定，為關鍵應用提供端到端服務質(zhì)量保障。

4 結(jié)束語

垂直行業(yè)對于網(wǎng)絡性能的迫切需求，以及傳統(tǒng)QoS保障機制在實施與部署過程中所存在的諸多缺陷與弊端，使得傳統(tǒng)IP網(wǎng)絡面臨艱巨的挑戰(zhàn)。SDN的興起，打破了現(xiàn)網(wǎng)封閉式的網(wǎng)絡架構(gòu)，簡化了網(wǎng)絡配置與管理，提高了網(wǎng)絡的靈活性，為QoS保障帶來了新的機遇。本文結(jié)合SDN架構(gòu)思想以及南向協(xié)議標準OpenFlow，研究了基于SDN的QoS保障機制。對于“輕負載”的網(wǎng)絡環(huán)境，直接選擇滿足QoS約束的端到端路由路徑；對于“重負載”的網(wǎng)絡環(huán)境，通過隊列優(yōu)先級機制來實現(xiàn)。并在此基礎上，對兩種應用場景進行了假設，分別從域內(nèi)和域間兩個角度展開理論論證與分析，表明SDN在現(xiàn)網(wǎng)QoS機制的改進工作方面具備很好的應用價值。