QoS項目設計方案

版本號：1.5

QoS項目設計方案

中國工商銀行QoS技術研究及實施項目小組

2006年11月9日

＞文檔屬性

屬性內(nèi)容

項目名稱：中國工商銀行QoS技術研究及實施項目

項目編號：

文檔主標題：QoS項目設計方案

文檔副標題：

文檔編號：

文檔版本號：1.5

版本日期：2006-11-9

文檔狀態(tài)：

作者：中國工商銀行QoS技術研究及實施項目小組

＞文檔變更過程

版本修正日期修正人描述

中國工商銀行QoS技術

1.02005年10月28日

研究及實施項目小組

1.12005年11月19日李英哲、是炮修訂稿

1.22005年12月19日李英哲、馬鴻胤修訂稿

1.32006年4月3日李英哲、馬鴻胤修訂稿

1.42006年9月30日李英哲修訂稿

1.52006年11月9日李英哲修訂稿

＞本版本變更內(nèi)容描述

序號修改內(nèi)容描述

1.1版本中總體說明了一級骨干網(wǎng)、二級骨干網(wǎng)和匯接網(wǎng)的QoS部

署原則；根據(jù)總行的意見，將視頻和語音業(yè)務分別放置到不同的PQ

隊列中，針對不同的單位保障不同路數(shù)的視頻會議終端；增加了軟

件開發(fā)中心QoS的部署原則和采用的QoS技術；對于網(wǎng)點思科路

1

由器不支持LLQ技術的采用了PQ技術；根據(jù)總行的意見，細化

QoS的管理要求；增加了對一級骨干網(wǎng)電話銀行的QoS保障原則；

增加了對視頻會議的QoS保障原則；增加了中思科路由器支持

framerelay和ATM的軟件版本。

1.2版本中根據(jù)總行最新的評審意見，重新調(diào)整了本方案的結(jié)構(gòu)及

2

相關章節(jié)的內(nèi)容。

1.3版本中根據(jù)總行的意見，增加了各類應用的分類原則、QoS基

3

礎理論和測試結(jié)論、QoS測試場景。

41.4版本中修改了數(shù)據(jù)中心（上海）到票據(jù)中心的QoS設計方案。

1.5版本中修改了匯接網(wǎng)使用LLQ時的QoS設計方案；修訂第五章

5的相關內(nèi)容：使用PQ隊列前五次最大流量平均值作為帶寬調(diào)整的

依據(jù)。

目錄

第一章、前言.......................................................8

1.1背景介紹..................................................8

1.2設計目標..................................................8

1.3局限性.....................................................9

第二章、QoS技術簡介.............................................10

1.1分類和標識................................................12

1.2擁塞管理.................................................13

1.2.1PQ技術.............................................13

1.2.2LLQ技術............................................14

1.2.3MDRR技術..........................................21

1.2.4PQ、LLQ、MDRR技術的對比.........................24

1.3擁塞避免.................................................25

1.3.1RED技術............................................26

1.3.2WRED技術..........................................28

1.4其他技術.................................................29

1.4.1基于類的管制及應用...................................29

第三章、QoS部署現(xiàn)狀和存在問題....................................31

3.1數(shù)據(jù)中心的出方向..........................................31

3.1.1從數(shù)據(jù)中心到分行的出方向............................31

3.1.2從數(shù)據(jù)中心到軟件開發(fā)中心的出方向....................32

3.1.3從數(shù)據(jù)中心（上海）到票據(jù)中心的出方向................32

3.2一級分行的出方向..........................................34

3.2.1從一級分行到總行、數(shù)據(jù)中心的出方向..................34

3.2.2從一級分行到二級分行的出方向........................35

3.3二級分行的出方向.........................................36

3.3.1從二級分行到總行、數(shù)據(jù)中心、一級分行的出方向........36

3.3.2從二級分行到網(wǎng)點的出方向............................37

3.4網(wǎng)點的出方向..............................................38

3.4.1從網(wǎng)點到總行、數(shù)據(jù)中心、一級分行、二級分行的出方向..…38

3.5軟件開發(fā)中心（廣州基地）的出方向.........................39

3.5.1從廣州基地到總行、數(shù)據(jù)中心、研發(fā)分部的出方向........39

3.5.2從廣州基地到珠海基地的出方向........................41

3.6軟件開發(fā)中心（珠?；兀┑某龇较?........................42

3.6.1從珠海基地到總行、數(shù)據(jù)中心、廣州基地的出方向........42

3.7票據(jù)中心的出方向.........................................43

3.7.1從票據(jù)中心到總行、數(shù)據(jù)中心、票據(jù)分部的出方向........43

3.8存在的問題................................................44

第四章、新的QoS設計思路和部署方案...............................46

4.1各類應用的分類原則和對我行主要應用的分類.................46

4.1.1各類應用的分類原則..................................46

4.1.2數(shù)據(jù)中心側(cè)應用的分類................................49

4.1.3Nova2.2.1中各種應用的分類..........................49

4.2數(shù)據(jù)中心（北京）出方向...................................51

4.2.1從數(shù)據(jù)中心（北京）到城域網(wǎng)單位的出方向..............51

4.2.2從數(shù)據(jù)中心（北京）到數(shù)據(jù)中心（上海）的出方向........51

4.2.3從數(shù)據(jù)中心（北京）到票據(jù)中心的出方向................52

4.2.4從數(shù)據(jù)中心（北京）到深圳分行（包括海外中心）的出方向.52

4.2.5從數(shù)據(jù)中心（北京）到含有研發(fā)分部的分行的出方向......59

4.2.6從數(shù)據(jù)中心（北京）到含有票據(jù)分部的分行的出方向......61

4.2.7從數(shù)據(jù)中心（北京）到其他分行的出方向................63

4.2.8從數(shù)據(jù)中心（北京）到軟件開發(fā)中心的出方向............65

4.3數(shù)據(jù)中心（上海）出方向...................................67

4.3.1從數(shù)據(jù)中心（上海）到總行等城域網(wǎng)單位的出方向........67

4.3.2從數(shù)據(jù)中心（上海）到數(shù)據(jù)中心（北京）的出方向........68

4.3.3從數(shù)據(jù)中心（上海）到深圳分行（包括海外中心）的出方向.68

4.3.4從數(shù)據(jù)中心（上海）到含有研發(fā)分部的分行的出方向......71

4.3.5從數(shù)據(jù)中心（上海）到含有票據(jù)分部的分行的出方向......73

4.3.6從數(shù)據(jù)中心（上海）到其他分行的出方向................75

4.3.7從數(shù)據(jù)中心（上海）到軟件開發(fā)中心的出方向............77

4.3.8從數(shù)據(jù)中心（上海）到票據(jù)中心的出方向................79

4.4深圳分行（包括海外中心）出方向...........................81

4.4.1從深圳分行（包括海外中心）到數(shù)據(jù)中心的出方向........81

4.4.2從深圳分行到網(wǎng)點的出方向............................87

4.5含有研發(fā)分部的一級分行出方向.............................88

4.5.1從含有研發(fā)分部的分行到數(shù)據(jù)中心的出方向..............88

4.5.2從含有研發(fā)分部的分行到二級分行的出方向..............90

4.6含有票據(jù)分部的一級分行出方向.............................92

4.6.1從含有票據(jù)分部的分行到數(shù)據(jù)中心的出方向..............92

4.6.2從含有票據(jù)分部的分行到二級分行的出方向..............94

4.7其他一級分行出方向.......................................96

4.7.1從其他一級分行到數(shù)據(jù)中心的出方向....................96

4.7.2從其他一級分行到二級分行的出方向....................98

4.8二級分行出方向...........................................99

4.8.1從二級分行到一級分行的出方向........................99

4.8.2從二級分行到網(wǎng)點的出方向...........................101

4.9網(wǎng)點出方向...............................................102

4.9.1數(shù)據(jù)流的分類........................................103

4.9.2數(shù)據(jù)流的擁塞管理...................................103

4.10軟件開發(fā)中心（廣州基地）出方向..........................104

4.10.1從廣州基地到數(shù)據(jù)中心的出方向......................104

4.10.2從廣州基地到珠?；氐某龇较?.....................107

4.11軟件開發(fā)中心（珠?；兀┏龇较?.........................109

4.11.1數(shù)據(jù)流的分類和染色.................................110

4.11.2數(shù)據(jù)流的擁塞管理和擁塞避免.........................111

4.12票據(jù)中心出方向..........................................111

4.12.1數(shù)據(jù)流的分類和染色.................................112

4.12.2數(shù)據(jù)流的擁塞管理和擁塞避免.........................112

第五章、QoS隊列的帶寬配置策略...................................114

5.1數(shù)據(jù)中心側(cè)的QoS例行化帶寬調(diào)整.........................114

5.1.1在連接分行的子端口上...............................114

5.1.2在連接軟件開發(fā)中心的子端口上.......................121

5.1.3在連接票據(jù)中心的端口上.............................122

5.2一級分行側(cè)的QoS例行化調(diào)整............................122

5.2.1在連接數(shù)據(jù)中心的ATM子端口上......................122

5.2.2在連接二級分行的ATM子端口上......................129

5.3二級分行側(cè)的QoS例行化調(diào)整............................129

5.3.1在連接一級分行的ATM子端口上......................129

5.3.2在連接網(wǎng)點的端口上.................................130

5.4軟件開發(fā)中心側(cè)的QoS例行化調(diào)整.........................131

5.4.1在廣州基地路由器連接數(shù)據(jù)中心ATM子端口上...........131

5.4.2在廣州基地和珠?；鼗ミB的ATM子端口上............133

5.5票據(jù)中心側(cè)的QoS例行化調(diào)整.............................134

5.5.1在連接數(shù)據(jù)中心（上海）的端口上.....................134

附件1、QoS基礎理論和測試結(jié)論...................................135

附件2、QoS測試場景.............................................151

附件3、一級骨干網(wǎng)電話銀行的QoS保障原則.........................152

附件4、視頻會議的QoS保障原則..................................154

附件5、各廠商網(wǎng)絡產(chǎn)品軟件版本支持情況............................156

第一章、前言

1.1背景介紹

2004年，我行全面實施完成了一級骨干網(wǎng)網(wǎng)絡規(guī)劃建設項目和一級分行

轄內(nèi)網(wǎng)絡建設項目，基于IP整合思路，構(gòu)建了承載全行所有業(yè)務應用系統(tǒng)的

一體化網(wǎng)絡系統(tǒng)。目前，在全國網(wǎng)絡系統(tǒng)中，一、二級骨干網(wǎng)絡和匯接網(wǎng)絡同

時承載著全行各級生產(chǎn)、測試、研發(fā)、辦公業(yè)務應用，隨著新的業(yè)務應用不斷

推出、業(yè)務量的不斷增大，如何解決不同業(yè)務應用爭搶一、二級骨干網(wǎng)和匯接

網(wǎng)的通信線路帶寬問題，即網(wǎng)絡服務質(zhì)量（QoS）問題，成為全行廣域網(wǎng)絡管

理的一個重點。

為此，我行曾先后組織兩大中心制訂了詳細的一、二級骨干網(wǎng)、匯接網(wǎng)

QoS技術使用規(guī)范和標準，并下發(fā)全行執(zhí)行。但是，由于QoS技術較為復雜,

各廠商實現(xiàn)原理各不相同，導致目前我行各級單位在使用QoS技術過程中，

存在技術理論掌握不深入、參數(shù)設置原理不清楚、有關應用分類和隊列設置不

合理等問題，導致近一年來全行發(fā)生多起因QoS技術使用不正確而影響到部

分分行95588語音漫游、網(wǎng)點柜面業(yè)務、視頻會議系統(tǒng)不能正常運行等問題。

為加強我行對有關QoS技術的理解和掌握，確保通過實施有效的QoS優(yōu)

先級控制，達到充分利用各級網(wǎng)絡通信線路帶寬資源的目的，總行信息科技部

啟動了網(wǎng)絡QoS技術研究及全行QoS技術實施項目。

1.2設計目標

上一階段我們對網(wǎng)絡QoS的通用技術及我行廣泛使用的思科、華為、邁

普、銳捷四個廠商網(wǎng)絡設備的廣域網(wǎng)QoS技術進行了研究（其中針對邁普、

銳捷設備，主要研究其在匯接網(wǎng)的QoS技術），搭建了測試環(huán)境對這四家廠商

設備實現(xiàn)的QoS技術進行測試，并提交了《QoS技術研究及測試報告》。本階

段我們將依據(jù)《QoS技術研究及測試報告》中的測試結(jié)果，結(jié)合我行一、二級

骨干網(wǎng)、三級匯接網(wǎng)QoS優(yōu)先級管理需求，對我行各類應用的優(yōu)先級隊列歸

屬、網(wǎng)絡設備QoS配置方法進行重新設計，制定全行的QoS項目設計方案和

標準實施方案。此次應用QoS的主要目的是在網(wǎng)絡擁塞時能夠保證我行關鍵

業(yè)務類、語音業(yè)務類和視頻會議類的帶寬不會被其他業(yè)務所占用，這三類業(yè)務

之間不會相互影響，更主要的是在網(wǎng)絡流量發(fā)生異常時QoS能夠起到一個隔

離的作用，能夠保護我行這三類業(yè)務不受影響或少受影響。

1.3局限性

本方案是在上一階段對QoS技術研究和測試結(jié)果的基礎上編寫的，并沒

有在真正的生產(chǎn)環(huán)境中進行過實際配置和驗證。為了減少后續(xù)實施階段中的風

險，建議先在試點分行進行小范圍的試點，根據(jù)試點的實施情況進一步完善本

方案。

第二章、QoS技術簡介

在早期計算機網(wǎng)絡中，網(wǎng)絡只是簡單地提供“盡力而為"(best-effort)的服

務，在這種服務模型下，所有的業(yè)務流公平地競爭網(wǎng)絡資源，路由器對所有的

IP數(shù)據(jù)包都采用先來先處理(FirstComeFirstService,FCFS)的工作方式,

它盡最大努力將IP數(shù)據(jù)包送達目的地，但對IP數(shù)據(jù)包傳遞的可靠性、延遲等

不能提供任何保證。這種方式很適合Email、FTP、WWW等業(yè)務。

但隨著Internet和各種業(yè)務的迅猛發(fā)展，尤其是隨著視頻、語音等多媒體

業(yè)務的興起，計算機的交互也越來越實時和生動，這就對網(wǎng)絡提出了更高的要

求。對那些有帶寬、延遲、抖動等特殊要求的應用來說，現(xiàn)有的“盡力而為”的

服務顯然是不夠的。同時，近年來發(fā)展起來的一些新的應用(如多媒體應用，

組播應用等)不僅增加了網(wǎng)絡流量，更因為這些應用改變了以往互聯(lián)網(wǎng)上的流

量性質(zhì)，它們具有全新的服務要求。由于不能預留帶寬，不能限制網(wǎng)絡延遲和

抖動，傳統(tǒng)的IP網(wǎng)絡沒有服務質(zhì)量保證的弱點已經(jīng)顯示出來，為此，業(yè)界提

出了IPQoS(QualityofService)的概念，就是希望在IP網(wǎng)絡上能夠?qū)Σ煌?/p>

的業(yè)務提供不同的帶寬、延遲等方面的保證。

QoS旨在針對不同用戶和不同應用的需求，為其提供不同的服務質(zhì)量保

證，例如：提供專用帶寬、減少鏈路時延、降低時延抖動、減少數(shù)據(jù)包丟失率、

平滑網(wǎng)絡流量等。它有一系列的度量指標，包括時延、抖動、吞吐量和丟包率

等：

①時延：也稱為延遲，指兩個參照點之間發(fā)送和接收數(shù)據(jù)包的時間間隔。

②抖動：指在同一條路徑上發(fā)送的一組數(shù)據(jù)流中數(shù)據(jù)包之間的時間差異。

③吞吐量：網(wǎng)絡中發(fā)送數(shù)據(jù)包的速率，可用平均速率或峰值速率表示。

④丟包率：在網(wǎng)絡中傳輸數(shù)據(jù)包時丟棄數(shù)據(jù)包的比率。

目前有很多服務模型和機制可以滿足網(wǎng)絡服務質(zhì)量(QoS)的需求，主要

使用的模式為以下兩種：IntegratedServices和DifferentiatedServices,簡稱

IntServ模式和DiffServ模式。

IntServ是綜合服務模式。該模式在發(fā)送數(shù)據(jù)包前，需要通過向網(wǎng)絡發(fā)送

信令(signal)來申請?zhí)囟ǖ姆眨瑧贸绦蚴紫韧ㄖW(wǎng)絡它自己的流量參數(shù)

和需要的特定服務質(zhì)量請求，包括帶寬、時延等。網(wǎng)絡在收到該請求后，基于

應用程序的資源申請和網(wǎng)絡現(xiàn)有的資源情況，判斷是否為應用程序分配資源。

一旦網(wǎng)絡確認為應用程序的數(shù)據(jù)包分配資源，則只要應用程序的數(shù)據(jù)包控制在

流量參數(shù)描述的范圍內(nèi)，網(wǎng)絡將承諾滿足應用程序的QoS需求。這種預留需

要在網(wǎng)絡路徑上的每一跳都要進行，這樣才能提供端到端的QoS保證。由于

該模式為應用程序預留了網(wǎng)絡資源，因此該資源就只能為該應用程序所使用，

如果這些預留的資源沒有被使用，就會造成網(wǎng)絡資源的浪費。

DiffServ是多服務模式。與IntServ不同，應用程序在發(fā)出數(shù)據(jù)包前，它

不需要通知網(wǎng)絡為其預留資源，同時網(wǎng)絡不需要為每個流維護狀態(tài)。它可以根

據(jù)每個數(shù)據(jù)包指定的QoS來提供特定的服務。相比較而言，DiffServ模式的方

式更加靈活，更具擴展性。該模式的實現(xiàn)方式簡單說明如下：當網(wǎng)絡擁塞時，

首先網(wǎng)絡設備會對流經(jīng)的數(shù)據(jù)包進行分類(Classification)和標識(Marking),

根據(jù)分類的情況數(shù)據(jù)包會進入不同的隊列中，進入隊列前可以對這些數(shù)據(jù)包進

行流量控制(TrafficRegulation)和擁塞避免(CongestionAvoidance),進入

隊列后可以對這些數(shù)據(jù)包實施擁塞管理(CongestionManagement),最終數(shù)

據(jù)包或者被發(fā)送出去或者被丟棄，這樣就保證了整個網(wǎng)絡的高效運行。整個過

程大體如下圖所示：

分類標識流量控制擁塞避免擁塞管理（隊列和調(diào)度）

下面我們將對DiffServ模式的相關實現(xiàn)環(huán)節(jié)及技術進行介紹：

1.1分類和標識

分類是指把網(wǎng)絡流量根據(jù)一定的條件劃分成多個優(yōu)先級或多個服務級別。

網(wǎng)絡設備可以根據(jù)不同的信息對數(shù)據(jù)包進行分類，比如：IPprecedence值、

DSCP值、協(xié)議端口、二層802.1Q的CoS值、流入端口、源/目的Mac地址

等。

標識是指通過設置不同級別數(shù)據(jù)包的IPprecedence值和DSCP值來實現(xiàn)

的，它用于把屬于不同級別的數(shù)據(jù)包“染色”。通過把經(jīng)過分類的數(shù)據(jù)包標識成

不同的級別，整個網(wǎng)絡中的設備就都可以識別數(shù)據(jù)包的類別，而不需要進行再

分類和再標識。當然我們也可以在其它的設備中根據(jù)所實施策略的不同對數(shù)據(jù)

包進行重新分類和標識。

數(shù)據(jù)包的分類和標識通常應該在網(wǎng)絡邊緣（接入層或分布層）實施，比如

在非核心路由器或支持三層交換的交換機上實現(xiàn)。在骨干網(wǎng)上一般不進行數(shù)據(jù)

包的分類和標識，骨干網(wǎng)只負責數(shù)據(jù)包的高速傳輸，但為了實現(xiàn)集中控制也可

以在分布層或核心層設備上進行分類和標識。

數(shù)據(jù)包在網(wǎng)絡入口點進行分類和標識后，網(wǎng)絡設備會根據(jù)數(shù)據(jù)包的優(yōu)先級

按照預定的QoS策略進行相應的處理，比如擁塞管理、帶寬分配等等，為數(shù)

據(jù)包提供適當?shù)难舆t范圍、延遲抖動范圍和帶寬等QoS參數(shù)。

1.2擁塞管理

網(wǎng)絡設備的每個物理端口都有自己的硬件和軟件隊列系統(tǒng)：硬件隊列系統(tǒng)

（通常稱為傳輸隊列或TxQ）一般使用FIFO隊列，軟件隊列系統(tǒng)可以根據(jù)不

同的平臺和IOS版本進行選擇和配置。如果軟件隊列為空而且硬件隊列不滿

時，數(shù)據(jù)包會直接進入硬件隊列等待傳輸，否則數(shù)據(jù)包會進入軟件隊列，經(jīng)過

不同的軟件隊列調(diào)度方式調(diào)度后，進入硬件隊列進行傳輸。如下圖所示：

擁塞管理是指網(wǎng)絡在發(fā)生擁塞時，如何進行流量的管理和控制。處理的方

法是使用隊列技術：通過將數(shù)據(jù)包放到不同的隊列，根據(jù)各個隊列的優(yōu)先級最

終決定數(shù)據(jù)包從接口發(fā)送出去的順序。擁塞管理的處理包括創(chuàng)建隊列，識別不

同類別的數(shù)據(jù)包，將數(shù)據(jù)包放到不同的隊列，對不同隊列進行調(diào)度等。

在一個接口沒有發(fā)生擁塞的時候，數(shù)據(jù)包在到達接口后立即就被發(fā)送出

去。在數(shù)據(jù)包到達的速度超過接口發(fā)送數(shù)據(jù)包的速度時，接口就發(fā)生了擁塞。

擁塞管理會將這些數(shù)據(jù)包進行分類，送入不同的隊列；而隊列調(diào)度對不同優(yōu)先

級的數(shù)據(jù)包進行分別處理，優(yōu)先級高的數(shù)據(jù)包會得到優(yōu)先處理。

擁塞管理提供了許多隊列技術，下面將對一些隊列技術進行詳細的說明。

1.2.1PQ技術

PQ技術是擁塞管理中的一種隊列技術，它的工作原理如下圖所示:

ForwardedPackets

如圖所示，PQ使用了4個FIFO隊列，優(yōu)先級分別為High、Medium.

Normal.Low,我們可以根據(jù)數(shù)據(jù)包的特征定義一系列的規(guī)則，將數(shù)據(jù)包按照

先進先出的策略分別放入這四個優(yōu)先級不同的隊列。

■調(diào)度方式：在發(fā)送數(shù)據(jù)包的時候，每次都調(diào)度高優(yōu)先級隊列中的數(shù)據(jù)包,

當該隊列中沒有數(shù)據(jù)包時較低優(yōu)先級隊列中的數(shù)據(jù)包才得

到調(diào)度。如果當較低優(yōu)先級的數(shù)據(jù)包發(fā)送時高優(yōu)先級的隊列

中又來了新的數(shù)據(jù)包，則在較低優(yōu)先級隊列中的該數(shù)據(jù)包發(fā)

送完畢后又會去發(fā)送高優(yōu)先級隊列中的數(shù)據(jù)包，依此類推。

沒有分類的數(shù)據(jù)包缺省進入Normal隊列。

■丟棄策略：每個隊列都采用尾丟棄的策略，當一個隊列滿時新到達該隊

列的數(shù)據(jù)包將被丟棄。

1.2.2LLQ技術

LLQ技術也是擁塞管理中的一種隊列技術。在介紹這個技術之前我們先介

紹與其相關的其他幾個技術。

令牌桶技術

令牌桶是傳輸速率的一種測量工具。它由三部分組成：平均速率(Mean

Rate),突發(fā)大小(BurstSize)和時間間隔(TimeInterval,Tc)。平均速率

通常用bps(bitspersecond)來表示，這三部分之間的關系如下：平均速率

=突發(fā)大小/時間間隔。

這三部分的定義如下：

?平均速率：也稱為承諾信息速率(CommittedInformationRate,CIR),

它定義了平均情況下每個單元時間內(nèi)所能發(fā)送或者轉(zhuǎn)發(fā)的數(shù)據(jù)

量。

?突發(fā)大?。阂卜Q為承諾突發(fā)大小(Comm讓tedBurstSize,Be),它定義了

在給定的時間單元內(nèi)所能發(fā)送流量的比特數(shù)或字節(jié)數(shù)。對于流

量管制(例如CAR)來說，它定義了突發(fā)的字節(jié)數(shù)；對于流量

整形(例如GTS)來說，它定義了突發(fā)的比特數(shù)。

?時間間隔：也稱為測量間隔(MeasurementInterval),它定義了每次突發(fā)

的時間額度(單位是秒)。

令牌桶可以在流量管制或者流量整形中使用。它本身并不會丟棄數(shù)據(jù)包或

者實施優(yōu)先級策略，它只會丟棄超出令牌桶大小的令牌。令牌桶是這樣工作的：

1、令牌桶中的每個令牌允許源發(fā)送一定數(shù)量的數(shù)據(jù)包。

2、令牌以一定的速率放置到令牌桶中。

3、發(fā)送一個數(shù)據(jù)包，就要從桶中取出與數(shù)據(jù)包大小相同的令牌。

4、如果令牌桶中沒有足夠的令牌來發(fā)送數(shù)據(jù)包，根據(jù)配置策略的不同，對數(shù)

據(jù)包會采取不同的動作(數(shù)據(jù)包或者會等待令牌數(shù)量足夠時再發(fā)送、或者

被丟棄、或者被重新標識)。

5、令牌桶有一定的容量，如果令牌桶已經(jīng)裝滿了令牌，后續(xù)的新令牌都會被

丟棄。

基于類的管制

基于類的管制(class-basedpolicing)需要對數(shù)據(jù)包進行分類，對每一

類數(shù)據(jù)包都使用單獨的單令牌桶或者雙令牌桶來衡量，并根據(jù)衡量結(jié)果對數(shù)據(jù)

包執(zhí)行符合、超出或違反動作。下面我們介紹的是單桶模型。

對于每類流量，單桶模型使用了如下兩個參數(shù)來衡量其速率：

■平均速率(CommittedInformationRate,CIR)：定義了一段時間內(nèi)的

平均發(fā)送速率。

■普通突發(fā)(NormalBurstSize,Be)：定義了令牌桶的大小。當令牌桶

中的令牌達到了Be大小時，后續(xù)的令牌都會被丟棄。

它的工作方式如下：當數(shù)據(jù)包到達時，如果令牌桶中沒有足夠的令牌，則

記錄當前的數(shù)據(jù)包到達時間，通過如下的公式計算出當前應該有多少新的令牌

放置到令牌桶中：

（當前數(shù)據(jù)包到達時間一上一次放置令牌的時間）XCIR

如果此時令牌桶中已經(jīng)有足夠的令牌我們稱其為符合（conform）,同時從

令牌桶中取出相同數(shù)量的令牌；如果令牌桶中的令牌數(shù)量不足，我們稱其為超

出（exceed）。根據(jù)配置的不同，可以對數(shù)據(jù)包采取不同的符合和超出動作。

一般情況下我們會發(fā)送符合的流量，丟棄超出的流量。

WFQ技術

ForwardedPackets

Interface°

WFQ可以為所有的網(wǎng)絡流量提供一種公平的帶寬分配方式，它是一種動

態(tài)的調(diào)度方法，采用的是基于流（Flow-Based）的公平隊列。所謂的流是由IP

包頭和TCP/UDP包頭中的如下信息確定的：源/目標地址，源/目標TCP或

UDP端口，傳輸層協(xié)議，IP包頭的ToS值。WFQ根據(jù)每個流的上述信息使

用Hash算法，可以將每個流的數(shù)據(jù)包映射到相應的隊列中。由此可見，同一

個流的數(shù)據(jù)包都會進入同一個隊列，但由于受WFQ隊列總體數(shù)量的限制，同

一個隊列也可能包含多個流的數(shù)據(jù)包。

在說明WFQ的調(diào)度方式和丟棄策略前，我們先介紹一個概念：數(shù)據(jù)包的

傳輸結(jié)束時間。當前數(shù)據(jù)包的傳輸結(jié)束時間=同一隊列中前一數(shù)據(jù)包的傳輸結(jié)

束時間+當前數(shù)據(jù)包的大小X當前數(shù)據(jù)包的權值。權值與數(shù)據(jù)包的IP

precedence<+1成反比。從上述公式可以看出，數(shù)據(jù)包越小、IPprecedence

值越大，該數(shù)據(jù)包的傳輸結(jié)束時間也越小。

■調(diào)度方式：在發(fā)送數(shù)據(jù)包的時候，由于所有的數(shù)據(jù)包在進入各自所屬的

隊列前都計算了自己的傳輸結(jié)束時間，因此在下一步進入硬

件隊列時，就可以按照數(shù)據(jù)包的傳輸結(jié)束時間依次調(diào)度。數(shù)

據(jù)包的傳輸結(jié)束時間越小，數(shù)據(jù)包進入硬件隊列的次序也就

越早，也就能夠越早的得到傳輸。

根據(jù)WFQ的調(diào)度方式，我們可以得出如下的結(jié)論：IPprecedence值

越小，所占用的帶寬越少；IPprecedence值越大，所占用的帶寬越多。這

樣就保證了相同優(yōu)先級業(yè)務之間的公平，同時又體現(xiàn)了不同優(yōu)先級業(yè)務之

間的權值。

例如：在一個128kbps的廣域網(wǎng)線路上，存在著1個VoIP數(shù)據(jù)流(IP

precedence值為5),5個Data數(shù)據(jù)流(IPprecedence值為0),那么我

們可以大概計算出VoIP所占用的帶寬：(5+1)/((5+1)x1+(0+1)

x5)x128=69.8kpbSo

又例如：在一個128kbps的廣域網(wǎng)線路上，存在著1個VoIP數(shù)據(jù)流(IP

precedence值為5),20個Data數(shù)據(jù)流(IPprecedence值為0),那么我

們可以大概計算出VoIP所占用的帶寬：(5+1)/((5+1)x1+(0+1)

x20)x128=29.5kpbSo

■丟棄策略：所有的隊列采用WFQ的丟棄策略。

4No\NoEnqueue

N-thpacket

N>HQO?N>CDT?packet

WorstWorst&No

FinishFinish

Time?Time?

Dropthepacketwith

theworstfinishtime

(old)andenqueuethe

N-thpacket(new)

如上圖所示，WFQ系統(tǒng)定義了全局隊列長度值(HQO)和擁塞丟

棄門限值(CDT)

?當全局隊列長度達到HQO時，下一數(shù)據(jù)包會根據(jù)計算出的傳輸結(jié)束

時間采取不同的策略：如果該數(shù)據(jù)包的傳輸結(jié)束時間是所有隊列中

數(shù)據(jù)包傳輸結(jié)束時間最晚的，則丟棄該數(shù)據(jù)包，否則丟棄隊列中現(xiàn)

有傳輸結(jié)束時間最晚的數(shù)據(jù)包，該數(shù)據(jù)包進入相應的隊列。

?如果全局隊列長度沒有達到HQO,但是達到了CDT,下一數(shù)據(jù)包根

據(jù)計算出的傳輸結(jié)束時間也采取不同的策略：如果傳輸結(jié)束時間是

所有隊列中數(shù)據(jù)包傳輸結(jié)束時間最晚的，則丟棄該數(shù)據(jù)包，否則該

數(shù)據(jù)包進入相應的隊列。

?如果全局隊列長度沒有達到HQO,也沒有達到CDT,下一數(shù)據(jù)包直

接進入相應的隊列。

優(yōu)點：

■配置簡單，不需要對數(shù)據(jù)包進行分類。

■可以通過IPPrecedence值的設置保證不同業(yè)務的帶寬。

缺點：

■由于同一隊列中可能會包含多個數(shù)據(jù)流，因此對該隊列中的多個數(shù)據(jù)流

無法進行進一步的QoS保證。

■不能提供固定的帶寬保證。

■由于分類算法和調(diào)度算法很復雜，因此對性能可能會有一些影響。

CBWFQ技術

ForwardedPackets

CBWFQ擴展了WFQ的功能，它允許用戶根據(jù)協(xié)議、accesslist、流入

端口等信息自定義流量的類別，滿足同一條件的數(shù)據(jù)包構(gòu)成了一類流量，進入

同一個隊列，沒有經(jīng)過分類的數(shù)據(jù)包都屬于缺省類別，進入缺省隊列中。

定義了類別后，我們就可以針對這一類流量配置所需要的帶寬和隊列長

度。配置帶寬是指在擁塞發(fā)生時該類流量所能得到保證的最低帶寬，隊列長度

是指該類流量所在隊列允許積累的最大數(shù)據(jù)包數(shù)量。

CBWFQ最多可以配置64個隊列，每個隊列采用FIFO的方式進行調(diào)度

和丟棄。如果為缺省類別配置了帶寬，缺省隊列采用FIFO的方式進行調(diào)度和

丟棄；如果沒有配置缺省類別，缺省隊列采用WFQ的方式進行調(diào)度和丟棄。

■調(diào)度方式：在發(fā)送數(shù)據(jù)包的時候，所有的隊列之間采用和WFQ一樣的

調(diào)度方式，CBWFQ中的每個隊列都對應了一個權值。權值

的大小取決于該隊列分配的帶寬占物理端口帶寬的比例，帶

寬越大，權值越小。帶寬的配置可以采用以下的方式之一：

?帶寬的絕對值

?帶寬的百分比

?可用帶寬的百分比

■丟棄策略：每個隊列有自己的長度限制(queuelimit),缺省情況下每個

隊列都采用尾丟棄的策略，當一個隊列滿時到達該隊列的新

數(shù)據(jù)包將被丟棄。另外還可以使用加權隨機早期監(jiān)測方式

（WRED）來丟棄較低優(yōu)先級的數(shù)據(jù)包。

優(yōu)點：

■用戶可以根據(jù)需要將不同的數(shù)據(jù)流分配到不同的類別中。

■沒有被使用的帶寬可以被其他類別的流量所占用。

■對于每個隊列還可以單獨配置QoS,比如可以對其中的一個隊列單獨配

置WFQ。

缺點：

■由于帶寬的分配比例決定了不同隊列中數(shù)據(jù)包被調(diào)度的先后次序，因此

無法滿足VoIP這一類對延遲和抖動敏感的業(yè)務的需要。

介紹了以上的幾個技術后，下面我們開始介紹LLQ技術。

LLQ的工作原理如下圖所示：

ForwardedPackets

由于CBWFQ無法滿足VoIP這一類對延遲和抖動敏感的業(yè)務的需要，因

此LLQ在CBWFQ的基礎上增加了PQ優(yōu)先隊列，我們可以根據(jù)需要將這類

對延遲敏感的業(yè)務放到PQ中，在CBWFQ中的數(shù)據(jù)包發(fā)送前優(yōu)先發(fā)送這些數(shù)

據(jù)包，這樣優(yōu)先隊列中的數(shù)據(jù)包被發(fā)送的延遲最多是接口發(fā)送一個最大長度數(shù)

據(jù)包的時間，無論是延遲還是抖動，優(yōu)先隊列都可以將之降低為最低限度，這

就對延遲敏感的業(yè)務提供了良好的服務質(zhì)量保證。

我們可以根據(jù)需要配置多個優(yōu)先類別，但是屬于這些優(yōu)先類別的數(shù)據(jù)包都

會進入同一個PQ中等待調(diào)度傳輸，只是在擁塞時每個優(yōu)先級類別的數(shù)據(jù)包都

會根據(jù)配置的帶寬進行流量限制(policing),超出流量的數(shù)據(jù)包將被丟棄，這

樣保證了CBWFQ的數(shù)據(jù)包也能夠得到傳輸。

■調(diào)度方式：在發(fā)送數(shù)據(jù)包的時候，在其他隊列的數(shù)據(jù)包進入硬件隊列前,

在PQ配置的帶寬范圍內(nèi)LLQ會優(yōu)先保證PQ隊列中數(shù)據(jù)包

的傳輸，其他的隊列采用CBWFQ的調(diào)度方法。

■丟棄策略：發(fā)生擁塞時，如果PQ隊列已滿，后續(xù)符合PQ條件的數(shù)據(jù)

包會被丟棄，即在擁塞的情況下，PQ隊列不可以超額搶占

帶寬；如果其它非PQ隊列滿，可以使用WRED(稍后介紹)

來丟棄較低優(yōu)先級的數(shù)據(jù)包。

1.2.3MDRR技術

MDRR技術也是擁塞管理中的一種隊列技術，它的工作原理如下圖所示：

ForwardedPackets

MDRR是思科GSR路由器上的一種基于類別的隊列技術。它基于IP數(shù)

據(jù)包的IPprecedence值，把IP數(shù)據(jù)包映射到不同的隊列中。MDRR支持八

個輪循隊列，其中一個可以是PQ隊列。它有兩種調(diào)度模式：嚴格優(yōu)先級模式

(StrictPriorityMode)和交替優(yōu)先級模式(AlternativeMode)。

我們在數(shù)據(jù)中心的Intranet接入路由器上使用的是MDRR嚴格優(yōu)先級模

式，它采用如下的方式進行調(diào)度：只要PQ隊列中有數(shù)據(jù)包就傳送，只有當

PQ隊列中沒有數(shù)據(jù)包時才按照輪循的方式傳送其他隊列中的數(shù)據(jù)包。如果在

傳送其他隊列的數(shù)據(jù)包時，PQ隊列中又有數(shù)據(jù)包，則傳送完當前的數(shù)據(jù)包后,

會繼續(xù)傳送PQ隊列中的數(shù)據(jù)包。

擁塞時非空的RoundRobin隊列會以輪循的方式傳輸固定數(shù)量的數(shù)據(jù)包。

如果在本次輪循中該隊列傳輸?shù)臄?shù)據(jù)包超過了固定的數(shù)量，MDRR會記錄下超

出的數(shù)值，這樣在下次傳輸時，該隊列會減少傳輸?shù)臄?shù)據(jù)包，結(jié)果使得每個隊

列平均傳輸?shù)臄?shù)據(jù)包數(shù)量更接近這個固定的數(shù)量。由此可知，MDRR的每個

RoundRobin隊列都有兩個變量：

1)計量值(quantumvalue)：它是在每一輪中能夠允許發(fā)送的數(shù)據(jù)包大小。

2)赤字計數(shù)器(deficitcounter)：它用于跟蹤每次輪循中隊列還可以傳輸

多少字節(jié)的數(shù)據(jù)包。它的初始值等于計量值。

只要赤字計數(shù)器大于零，該隊列中的數(shù)據(jù)包就會被傳輸。數(shù)據(jù)包被傳輸完

畢后，赤字計數(shù)器會減去和數(shù)據(jù)包大小相同的字節(jié)數(shù)。如果赤字計數(shù)器小于等

于零，該隊列就會結(jié)束本次輪循，不會繼續(xù)發(fā)送數(shù)據(jù)包。在每次新的輪循開始

之前，非空隊列的赤字計數(shù)器都會增加計量值大小的字節(jié)數(shù)。

下面舉例說明MDRR的嚴格優(yōu)先級調(diào)度模式，假設我們配置了以下三個

隊列：

■Queue0：該隊列是PQ隊列。

■Queue1：Quantum為3000字節(jié)。

■Queue2：Quantum為1500字節(jié)。

1)隊列的初始狀態(tài)如下表：

所在隊列隊列中的數(shù)據(jù)包(到達順序/字節(jié)大小)赤字計數(shù)器

Queue03/2502/15001/250—

Queue16/15005/15004/15000

Queue211/150010/2509/2508/2507/2500

由于采用的是嚴格優(yōu)先級調(diào)度模式，因此只要Queue0中有數(shù)據(jù)包就會

得到優(yōu)先傳輸，所以Queue。中的三個數(shù)據(jù)包都會得到傳輸。Queue0中

的數(shù)據(jù)包傳輸完畢后，隊列的狀態(tài)如下表:

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大小）赤字計數(shù)器

Queue0——

Queue16/15005/15004/15000

Queue211/150010/2509/2508/2507/2500

2）下面開始傳輸Queue1中的數(shù)據(jù)包，同樣其赤字計數(shù)器會增加Quantum

的大小變?yōu)?000字節(jié)，此時大小為1500字節(jié)的數(shù)據(jù)包4和數(shù)據(jù)包5

都會被傳輸，由于赤字計數(shù)器變成了零，Queue1停止發(fā)送數(shù)據(jù)包。此

時隊列的狀態(tài)如下表：

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大小）赤字計數(shù)器

Queue0—

Queue16/15000

Queue211/150010/2509/2508/2507/2500

3）根據(jù)嚴格優(yōu)先級模式調(diào)度算法的工作機制，下面開始傳輸Queue2中

的數(shù)據(jù)包，其赤字計數(shù)器會增加Quantum的大小變?yōu)?500字節(jié)。如果

數(shù)據(jù)包7、8、9傳輸完畢后，赤字計數(shù)器將變?yōu)?50字節(jié)，隊列的狀態(tài)

如下表：

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大?。┏嘧钟嫈?shù)器

Queue0—

Queue16/15000

Queue211/150010/250750

4）在Queue2在傳輸數(shù)據(jù)包10的時候，Queue0中又來了一個新的數(shù)據(jù)

包12,其大小為1500字節(jié)。此時隊列的狀態(tài)如下表:

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大小）赤字計數(shù)器

Queue012/1500—

Queue16/15000

Queue211/150010/250750

（傳輸中）

5）雖然在傳輸完數(shù)據(jù)包10時Queue2的赤字計數(shù)器為500字節(jié)，還可以

繼續(xù)發(fā)送數(shù)據(jù)包11,但是根據(jù)嚴格優(yōu)先級模式的調(diào)度算法，此時應該傳

輸Queue0中的數(shù)據(jù)包12。Queue2中的數(shù)據(jù)包10和Queue0中的

數(shù)據(jù)包12傳輸完畢后，隊列的狀態(tài)如下：

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大?。┏嘧钟嫈?shù)器

Queue0—

Queue16/15000

Queue211/1500500

6）由于Queue2中的赤字計數(shù)器仍大于零，下面繼續(xù)傳輸Queue2中的

數(shù)據(jù)包，大小為1500字節(jié)的數(shù)據(jù)包11被傳輸,赤字計數(shù)器變?yōu)橐?000,

Queue2停止發(fā)送數(shù)據(jù)包。此時隊列的狀態(tài)如下表：

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大?。┏嘧钟嫈?shù)器

Queue0—

Queue16/15000

Queue2-1000

7）由于Queue0中一直沒有數(shù)據(jù)包，在傳輸完Queue2中的數(shù)據(jù)包后，

下面開始傳輸Queue1中的數(shù)據(jù)包，其赤字計數(shù)器會增加Quantum的

大小變?yōu)?000字節(jié)，此時大小為1500字節(jié)的數(shù)據(jù)包6會被傳輸，由

于Queue1中沒有數(shù)據(jù)包了，因此赤字計數(shù)器被置為0,Queue1停止

發(fā)送數(shù)據(jù)包。此時所有隊列的數(shù)據(jù)包都被傳輸完畢了，隊列的狀態(tài)如下

表：

所在隊列隊列中的數(shù)據(jù)包（到達順序/字節(jié)大?。┏嘧钟嫈?shù)器

Queue0—

Queue10

Queue2-1000

整個過程中Queue。、Queue1>Queue2中數(shù)據(jù)包傳輸?shù)拇涡蛉缦?

Queue0（數(shù)據(jù)包1）、Queue0（數(shù)據(jù)包2）、Queue0（數(shù)據(jù)包3）、Queue

1（數(shù)據(jù)包4）、Queue1（數(shù)據(jù)包5）、Queue2（數(shù)據(jù)包7）、Queue2（數(shù)據(jù)

包8）、Queue2（數(shù)據(jù)包9）,Queue2（數(shù)據(jù)包10）、Queue0（數(shù)據(jù)包12）、

Queue2（數(shù)據(jù)包11）、Queue1（數(shù)據(jù)包6）

1.2.4PQ、LLQ、MDRR技術的對比

擁塞管理技術優(yōu)點缺點

PQ1、為高優(yōu)先級隊列的數(shù)據(jù)包提供1、當高優(yōu)先級隊列中的數(shù)據(jù)包擁塞

了低延遲的傳輸。時，會造成低優(yōu)先級隊列中的數(shù)

據(jù)包無法傳輸。

2、在網(wǎng)絡中經(jīng)過的每一跳都需要對

數(shù)據(jù)包進行分類。

LLQ1、可以將對延遲和抖動敏感的業(yè)

務放到PQ隊列中，滿足其對

延遲的需要。

2、為PQ和CBWFQ隊列提供了

最低的帶寬保障。

3、未被使用的帶寬可以被

CBWFQ隊列使用。

MDRR1、可以將對延遲和抖動敏感的業(yè)1、由于嚴格優(yōu)先級模式下，PQ隊

務放到PQ隊列中，滿足其對列沒有帶寬限制，因此當PQ隊

延遲的需要。列的數(shù)據(jù)包擁塞時，會造成

2、由于每次輪循時都會考慮上次RoundRobin隊列中的數(shù)據(jù)包

輪循的赤字計數(shù)器值，因此無法傳輸。

MDRR能夠在RoundRobin2、只能根據(jù)數(shù)據(jù)包的IP

隊列之間進行準確的帶寬分precedence值進行分類。

配。3、只能支持有限的隊列（8個隊

列）。