|
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
|
|
QoS 即服務質量，是在園區網和ISP網絡中應用的主流技術，其目的在於劃分服務等級，針對各種應用的不同需求提供不同的服務質量，比如提供專用帶寬減少報文丟失率減低報文傳送時的延遲和抖動。
在一個網絡中需要三個部分來實現端到端的QoS：
1）各網絡設備支持QoS提供隊列調度和流量整形等功能。
2）信令技術協調端到端之間的網絡設備。
3）QoS技術控制和協調端到端的報文在一個網絡內的發送。
每個網絡設備提供如下功能：
1）報文的分類，不同類別對應不同的處理方式。
2）排隊技術滿足不同應用要求的不同服務質量。
3）流量監管和流量整形限制和調整報文輸出的速度。
4）接入控制確定是否允許用戶信息流使用網絡資源。
QoS服務模型
1）Best-Effort 盡力而爲的服務模型，也就是沒有應用QoS，IP網絡本身就是這特點。
2）Intserv 集成服務模型，用戶在發送報文前要向網絡申請特定的業務，通過RSVP 協議（資源預留協議）通知路由器，聲明應用程序的QoS需求，比如我用VOIP，需要12k的帶寬和100ms以內的延遲，集成服務模型就會將其歸到事先設定的一種服務等級中。
總的來說集成服務模型就是一種固定服務的預訂機制，靈活性較差，就好比一個大廚只會做土豆絲炒肉和芹菜炒肉，你要芹菜炒土豆絲，他說不會...靠，想喫素都不行。
RSVP只是一個信令協議，在網絡節點之間傳遞，本身不實現QoS 功能。缺點比較致命，就是RSVP協議本身數據太多而且不斷刷新，並且這種爲單一數據流進行帶寬預留的解決思路在浩瀚的Internet上想要實現是根本不可能的，所以該模型在1994年推出以後就沒有使用過。
3）Diffserv 區分服務模型，目前廣泛應用的模型，由一系列技術組成。Diffserv可以滿足不同的QoS需求。與Integrated service不同，它不需要信令，即應用程序在發出報文前，不需要通知路由器。網絡不需要爲每個流維護狀態，它根據每個報文指定的QoS，來提供特定的服務。可以用不同的方法來指定報文的QoS，如IP包的優先級/Precedence、報文的源地址和目的地址等。網絡通過這些信息來進行報文的分類、流量整形、流量監管和排隊。
QoS標記
標記在網絡邊界處進行，目的在於將區分數據，表明其之間的不同，這樣在網絡內部隊列技術就可以依據這個標記將數據劃分到相應的隊列，進行不同的處理。
在IP報文中有專門的字段進行QoS的標記，在IPV4中爲TOS，IPv6中爲TrafficClass。TOS字段用前6bit來標記DSCP，如果只用前3 bit 就爲IP優先級。DSCP和IP優先級都是標記的標準。
IP優先級提供0-7共8種服務質量，6和7都保留所以常用的是0-5，每個數字都對應一個名稱，比如0對應Routine ，這樣在更改數據包優先級等配置時，既可以用數字也可以用名稱。
注意優先級中的數字本身沒有實際的意義，標記爲5的數據優先級不一定就比標記爲0的高，只是一個分類標準而已。真正的操作是在配置上針對不同的優先級採取不同的措施，比如什麼標識的數據包屬於什麼隊列。
IP優先級和DSCP不能同時設置，如果同時設置的話只有DSCP生效，那麼標記了DSCP的數據包到了只會識別IP優先級的路由器，就只會看前3bit，而且不管是IP優先級還是DSCP都是用自己的前3bit和二層的CoS值形成映射。
在二層用CoS字段進行標記，正常的以太網幀是沒有標記的，但是在ISL的報頭和802.1Q的Tag中都有3bit 用來定義服務級別，從0到7，不過只有0-5可用，6和7都保留。
PHB
客戶在向ISP要求QoS服務的時候，ISP會列出清單，表明可以提供的網絡服務，每種服務的性能都不同，並以一個特定的DSCP值來標記，這個值決定在ISP網絡中對該流量的PHB，也就是每一臺網絡設備如何處理這樣的流量，通常客戶和運營商之間會協商一個配置文件，描述了各種服務等級的提交速率。
服務被定義後，一種服務，分配一個DSCP值，相應指定一種PHB轉發行爲。PHB的效果是可見的，比如我確實保證了你的流量延遲在100ms以內，但具體是如何實現的就是黑盒子裏的內容了。
默認的PHB行爲是盡力而爲，編碼爲DSCP 000000，另外還有EF PHB和AF PHB（CBWFQ中會再提到）。
EF PHB 針對VOIP這樣的服務，保證低延遲，低抖動和較小的丟包率。因爲分組延遲和抖動的主要原因是排隊延遲，而排隊延遲通常是在擁塞時排隊過長引起的，EF PHB 保證通信不需要排隊或隊列足夠短，所以一般要在高度加權的隊列上傳送。EF PHB的編碼爲DSCP 101110。
AF PHB 對應4種AF Class，每一個Class都將自己要發的數據包優先級分爲高中低三個檔次，而且Class之間也有差異，Class等級越高，對應的IP優先級也就越高，QoS質量也就越好。PHB編碼的前3bit表示IP報文優先級，接下來的2bit表示丟包優先級（不會是00），最後1bit總是0。
以下是4種Class具體的對應值：
Low Drop Precent Medium Drop Precent High Drop Precent
Class1 001-01-0 001-10-0 001-11-0
Class2 010-01-0 010-10-0 010-11-0
Class3 011-01-0 011-10-0 011-11-0
Class4 100-01-0 100-10-0 100-11-0
隊列技術
隊列技術是在接口發生擁塞的時候對數據進行排隊，應用隊列技術的前提是接口有緩衝內存。以Catalyst 5000爲例，每個以太網端口有192KB的緩衝區內存，其中24k用於輸入，168k用於輸出。每個端口最多可以創建2500個64字節的緩衝區，大多數的緩衝區都用於輸出隊列。
我們在研究各種隊列技術時，重點分析以下幾個方面：
1）數據已經進行標記，如何依據標記將其分到各隊列？ 2）如果要分隊列的話，分成幾個隊列？
3）形成隊列後要調度數據，先從哪個隊列開始？
4）調度時每次從一個隊列裏取多少數據從接口發出去？
研究隊列技術時往往會感到困惑，既然根據隊列優先級調度有先後之分，那麼帶寬的平均分配和佔用又是怎麼回事，到底是同時發送，佔用各自的帶寬，還是先後發送，佔用全部帶寬？
首先明確一點，接口輸出的是比特流，在任一時刻不會同時發送兩種數據，因爲那一時刻通過的是一個bit，這個bit只會屬於一個數據包，況且數據類型本來就是上層的東西，接口就認比特流。我們在想象QoS的時候，可以認爲是一些隊列面對着出口，調度一聲令下就從一個隊列裏出列一些數據衝出接口。
以CQ爲例，CQ給隊列1分配60 %帶寬，每次出隊6000字節的數據，隊列2分配40 %帶寬，每次出隊4000字節的數據，那麼在輪詢調度的時候，首先讓隊列1中的報文出隊，併發送直到不少於6000字節數據後，纔開始發送隊列2的報文，直到發送不少於4000字節數據後，纔開始下一隊列。
雖然各隊列的數據發送始終有先有後，但是發送6000字節只是一個瞬間完成，至於這個瞬間有多短，取決於接口性能。接着就是一個4000字節的傳輸瞬間，那麼在1s之內會交替着發送N個6000字節和N個4000字節，最後在這宏觀上的1秒，我們看到這兩種數據在同時傳輸，佔用的帶寬分別1.2M和0.8M。
綜上所述帶寬的同時佔用是以秒爲單位的宏觀體現，調度算法處理數據的時間根本就不在這個量級上，1s實在是太太太長了，在1s內會先後發送數據N次。所以從微小的瞬間來看數據發送始終有先後，而調度算法就是決定誰先誰後，這也是QoS決策的中心問題。
而優先級隊列考慮的不是取多少數據，而是先取哪個隊列的數據，因爲如果先傳送並有一定的帶寬保證就能實現該數據傳輸的低延遲效果。 以LLQ優先隊列來講，如果我們事先定義該隊列可佔用的最大帶寬爲2M，那麼根據這個值就能計算出每次從LLQ隊列中取多少數據出來，比如2000字節，在調度的時候優先考慮LLQ，只要隊列中還有數據就一直取，直到LLQ隊列爲空或者已經取出超過2000字節的數據，這時再考慮其它隊列。
以下是各種隊列技術的介紹：
1. FIFO（先進先出隊列，First In First Out Queuing）
傳統的Best-Effort服務策略，默認應用在帶寬大於2.048M的接口上，只適用於對帶寬和延遲不敏感的流量，像是WWW，FTP，E-mail 等。FIFO不對報文進行分類，當報文進入接口的速率大於接口能發送速率時，FIFO按報文到達接口的先後順序讓報文進入隊列，同時在隊列的出口讓報文按進隊的順序出隊。
簡單來說，數據就排一隊，先到先服務。
2. PQ（優先隊列，Priority Queuing，升級版爲LLQ）
PQ 根據IP優先級和DSCP 等條件將所有報文歸爲4類。PQ需要用戶自己手動設定分類標準，比如針對某一進站接口，或者某一具體協議的流量等等，再將其歸到隊列中。
4 類報文分別對應4 個隊列：高優先隊列，中優先隊列，正常優先隊列和低優先隊列。高優先級隊列的報文都發送完了才能發送下一個優先級的報文。這樣的機制雖然能保證關鍵數據總是得到優先處理，但是低優先級的隊列很可能因此擁塞的要命。
PQ的限制和缺點：PQ爲靜態配置，不能適應網絡結構的變化。數據包要經過處理器的分類，因此轉發數據包的速度要比FIFO慢。此外PQ還不支持隧道接口。
（config）# priority-list 1 protocol sna high //設定sna 流量是高優先級
（config）# priority-list 1 protocol ip low tcp 80 //設定www 流量是低優先級
（config）# priority-list 1 protocol ip medium //設定其他ip 流量是中等優先級
（config）# priority-list 1 queue-limit 50 40 60 80 //設定優先級隊列的隊列深度，從高到低
（config-if）# priority-group 1 //在接口下應用隊列
3. CQ（自定義隊列，Custom Queuing） CQ 按照一定的規則將報文分成17類，對應17個隊列，每個報文根據自己的類別按照先進先出的策略進入相應的CQ 隊列。
在CQ的17個隊列中，0 號隊列是超級優先隊列，不允許用戶配置，路由器總是先把0號隊列中的報文發送完再考慮1-16號，所以該隊列一般被定義爲系統隊列，把實時性要求高的交互式協議和鏈路層協議放在0號隊列。
1到16 號隊列是用戶隊列，可以自己定義各隊列分得帶寬的比例，在報文出隊的時候，CQ按定義的帶寬比例分別從1-16號隊列中輪詢式的拿一定量的報文在接口發送出去。 CQ的限制和缺點：CQ爲靜態配置，不能適應網絡結構的變化。數據包要經過處理器的分類，因此轉發數據包的速度要比FIFO慢。
（config）# queue-list 1 protocol sna 1 //在queue-list 1 中定義sna 流量歸到隊列1
（config）# queue-list 1 protocol ip 2 //在queue-list 1 中定義ip 流量歸到隊列2
（config）# queue-list 1 queue 1 byte-count 15000 //定義queue 1的帶寬爲15000 bytes
（config）# queue-list 1 queue 2 byte-conut 3500 //定義queue 2的帶寬爲3500 bytes
（config）# queue-list 1 queue 3 byte-conut 1500 //寬默認值就是1500 bytes
（config-if）# custom-queue-list 1 //在接口應用CQ隊列
PS：PQ和CQ均爲定製優先級的隊列技術，目前已不怎麼使用。
4. WFQ（加權公平隊列，Weighted Fair Queuing） WFQ 按數據流的會話信息自動進行流分類（相同源IP地址，目的IP地址，原端口號，目的端口號，協議號，IP優先級的報文同屬一個流），並且儘可能多地劃分出N個隊列，以將每個流均勻地放入不同隊列中，從而在總體上均衡各個流的延遲。
在出隊的時候，WFQ按流的優先級（precedence 或DSCP）來分配每個流應占有出口的帶寬。優先級的數值越小，所得的帶寬越少。優先級的數值越大，所得的帶寬越多。最後，輪詢各個隊列，按照帶寬比例從隊列中取出相應數量的報文進行發送。WFQ是傳輸速率在2.048M以下的接口默認的隊列機制。
舉例來說，接口中當前共有5 個流，它們的優先級分別爲0、1、2、3、4，則帶寬總配額爲所有（流的優先級+1）的和。即1 + 2 + 3 + 4 + 5 = 15，每個流可得的帶寬分別爲：1/15，2/15，3/15，4/15，5/15。
WFQ的限制：WFQ不支持隧道或者採用了加密技術的接口，因爲這些技術要修改數據包中WFQ用於分類的信息。WFQ提供的帶寬控制的精度不如CBWFQ，因爲是基於流的分類，基於隊列的帶寬分配，每個隊列可能會有多個流，這樣無法再針對具體的數據類型指定帶寬。
WFQ在接口下啓用，就一條命令：(config-if) # fair-queue
5. CBWFQ（基於類的公平隊列，Class-Based Weighted Fair Queuing） CBWFQ是WFQ的擴展技術，總體看來就是有一個低延遲隊列LLQ來支撐EF PHB，被絕對優先發送，另外有64個BQ來支撐AF PHB，可以保證每一個隊列的帶寬及可控的時延，還有一個WFQ對應Best-effort行爲，使用接口剩餘帶寬進行轉發。
LLQ隊列是一種單獨的隊列技術，只不過CBWFQ將其引進作爲自己的組成部分，該隊列可以排列不同類型的數據，並分別指定帶寬，不過關鍵點是優先級高，處於這個隊列的數據總是優先發送，直到該隊列爲空或數據流超出LLQ預留最大帶寬時才調度其他隊列的報文。 BQ（Bandwith Queue）是普通隊列，編號1-64，每一類報文佔一個隊列，根據用戶設置來分配帶寬，各隊列爲公平調度，具體算法未知。如果有報文不符合用戶設定的所有類，就會編入缺省隊列中。在這個隊列中爲各種數據實行WFQ的機制，即基於流的隊列調度，這是目前常用的配置方法，不然就是當成BQ來自動處理了。
CBWFQ能保證你設置隊列的帶寬，在不擁塞的時候，能共享空閒的帶寬，使可用帶寬超過你設置的帶寬，在擁塞的時候，保證設置的帶寬。而LLQ只有在擁塞的時候才起作用，LLQ凌駕於CBWFQ隊列，被絕對優先轉發。
考慮到鏈路層控制報文的發送，鏈路層封裝開銷以及物理層開銷，建議LLQ和BQ佔用的帶寬不要超過接口帶寬的75%，LLQ只採用尾丟棄，BQ和WFQ可以採用尾丟棄或者WRED。 CBWFQ對WFQ做的一些改進：
在WFQ中weight用來指明隊列優先級，而在CBWFQ中weight用來指明某類流量的優先級。數據包根據weight排在相應類的隊列中。
CBWFQ一個隊列一種數據，所以可以爲某類流量指定相應的帶寬，而WFQ無法實現，因爲是基於流，種類多的很，最後可能每個隊列裏都有好幾種流量。
CBWFQ分類數據時除了根據IP地址和端口號，還可以通過ACL或數據輸入接口，WFQ無法實現。
CBWFQ使用存在的限制： 目前流量整形不支持CBWFQ CBWFQ不支持子接口。
CBWFQ配置，首先看看BQ的：
class-map match-any class0 //定義class map，用match 匹配特殊的數據流
match ip precedence 4
match ip precedence 0
policy-map tos-based //定義policy map，用定義每類數據的處理策略
class class0 bandwidth 6750 //使用關鍵字bandwith，說明是在配置BQ隊列
interface s1/0 //將策略應用在接口上
service-policy output tos-based
再來看看如何配置LLQ，同上面的不同就是定義policy map時用的是priority關鍵字：
class-map match-all steven24
match access-group 100
access-list 100 permit ip host 141.2.20.20 host 129.2.20.34 precedence critical
policy-map video1 //定義LLQ策略爲Video預留1518k的帶寬
class steven24 priority 1518 //使用關鍵字priority說明在配置LLQ隊列
set ip precedence 5 //更改IP優先級，下一跳會按更改後的值處理
class class-default fair-queue
interface FastEthernet1/0
service-policy output video1 //在接口下應用策略
總結：PQ和CQ都需要手動配置，在命令中可以看出，並不能依據IP優先級或DSCP來劃分隊列，而且配置起來比較麻煩，命令煩瑣。在WFQ中只有一條命令，執行基本是自動化的，但這樣不好控制流量，而且要事先進行QoS標記。
在CBWFQ中QoS的事先標記不是必須的，因爲引入了MQC的概念，通過結構化的命令行匹配特定的數據流（如果匹配的是IP優先級或DSCP，則需要事先的QoS標記）再製定細化的處理策略，不過歸隊列還是算法自動完成，CBWFQ是目前推薦使用的模式。
CBWFQ和QoS標記看起來配置步驟十分相似，都是用class map 和policy map，但是其實有很大不同，而且有先後順序。首先要明確QoS標記的流程：
1）用class map 抓住數據流最本質的特點，比如特定源地址，目的地址，協議等。
2）用policy map進行標記動作，比如用Set 命令設置IP優先級，DCSP，COS等。
3）在接口應用該配置。
這樣看來，如果是要針對IP優先級，DSCP來做策略，步驟是：
QoS標記（匹配特殊數據流-->設定優先級-->應用在接口）---> CBWFQ用class map匹配優先級--->CBWFQ用policy map指定策略--->CBWFQ應用在接口
而如果QoS策略不涉及IP優先級或DSCP，沒有必要實現標記，因爲只用MQC就可以搞定：
CBWFQ用class map匹配特定數據流--->CBWFQ用policy map指定策略--->CBWFQ應用在接口
6. RTP（Real-time Transport Protocol）優先隊列 RTP 優先隊列是一種解決實時業務（包括語音與視頻業務）服務質量的簡單的隊列技術。其原理就是將承載語音或視頻的RTP 報文送入高優先級隊列，使其得到優先發送，保證時延和抖動降低爲最低限度，從而保證了語音或視頻這種對時延敏感業務的服務質量。
RTP和LLQ一樣是獨立的隊列技術，不過一般不會單獨應用。RTP可以同FIFO，PQ，CQ，WFQ和CBWFQ結合，優先級始終是最高的。
7.WRR 加權輪詢隊列
WRR是應用在交換機上的隊列技術，每個交換機端口支持4個輸出隊列，調度算法在隊列之間輪流調度，通過爲每個隊列配置一個加權值（依次爲W3，W2，W1，W0），使其得到相應的帶寬資源，比如一個100M的端口，配置加權值爲50，30，10，10，那麼最低優先級隊列至少會獲得10M的帶寬。
WRR調度隊列的方式雖然是輪詢的，但是每個隊列不是固定的分配服務時間，如果某個隊列爲空，那麼會馬上切換到下一個隊列調度。
HQ-WRR調度模式在WRR的基礎上，在4個調度隊列中以隊列3爲高優先級隊列，如果端口出現了擁塞，首先保證隊列3的報文優先發送，然後對其餘3份額隊列實行WRR調度。
|
流量管理
QoS的標記不僅可以用於隊列技術，還可以用於流量管理。應用流量管理的起因在於帶寬資源有限和流量本身的傳輸價值需要定位。具體的技術成爲CAR（Commited Access Rate），限制約定速率。
一般來講，用戶注入網絡的流量不是都有意義的，比如園區網中的清道夫流量，對公司生產沒有任何價值，可能只是員工上班時間在網上看電影產生的，這樣的流量沒有必要傳輸，在網絡邊界進行標記後，在網絡內部識別出是清道夫流量就直接丟棄，不會爲這樣的流量浪費帶寬。
CAR提供這樣的流量控制，其本身的功能是設定IP優先級來描述分組和限制速率。CAR並不將數據保存到緩存區或使其平穩，當超過允許的突發流量時就會丟棄分組。
實施CAR的流程：
1）流量匹配 匹配方式有4種:匹配所有數據，使用速率限制列表匹配某個IP優先級，使用速率限制列表匹配某個Mac地址，使用IP標準或擴展ACL進行匹配。
2）流量檢測 應用令牌桶模型，令牌桶有4個關鍵參數：平均速率或承諾信息速率，即CIR（單位bit/s）；常規突發量BC，即瞬間可以超過令牌桶的流量跑；時間間隔Ti=Bc/CIR；擴展突發量BE。
令牌桶就是一個關口，令牌以一定的速率進入令牌桶，滿了就停止進入，令牌桶中的令牌數量會根據報文的長度相應的減少，當少到不能再發送時報文就會被丟棄，這樣通過控制令牌進入令牌桶的速率就可以限制流量。
令牌桶能保存的最大令牌數等於BC 標準令牌桶BE=BC，沒有擴展突發功能，令牌不夠就直接丟棄，擴展突發功能令牌桶BE>BC，允許流量暫借更多的令牌，然後採用隨機丟棄的方法，緩緩丟棄流量。
流量控制在接口進行，不過在隊列技術之前。首先依據預先設置的匹配規則對報文進行分類，如果是沒有流量特性的報文就繼續發送，如果有就會通過令牌桶這個關口，如果令牌桶中有足夠的令牌，則允許報文通過，如果令牌不滿足報文的發送條件則報文被丟棄。
在實際應用中CAR還可用於報文的標記或重標記，比如一個報文設置優先級爲5，本來應該丟棄，但是現在網絡空閒，傳輸沒有問題，就把優先級改爲1，後續的路由器會這樣處理，如果網絡依然不擁塞，就傳送這個優先級爲1的報文，如果出現擁塞，先丟棄優先級爲1的，再丟棄優先級爲5的。
CAR的使用限制：只能對IP流量做限速，不支持FastEtherChannel，不支持隧道接口，不支持ISDN PRI接口。
擁塞控制
擁塞控制在隊列中使用，可以用來避免TCP全局同步的問題，具體技術爲RED，WRED以及流WRED。
考慮到內存資源有限，按傳統的處理方法，當隊列的長度達到規定的最大長度時就會實行尾丟棄，即丟棄後來的數據包。就TCP報文而言，如果大量的報文被丟棄將造成TCP超時，從而引發TCP的慢啓動和擁塞避免機制。
而當隊列同時丟棄多個TCP報文將造成多個TCP連接同時進入慢啓動和擁塞避免，稱之爲TCP全局同步。這樣多個TCP連接發向隊列的報文同時減少，使發向隊列的報文的量都不及線路的發送速度，帶寬利用不上，而後又同時慢啓動漸漸到達峯值以至於出現擁塞，這樣發向隊列的報文總是忽多忽少，使線路上的流量在峯值和谷底間波動。
RED
隨機預檢測，具體動作就是設定隊列的閾值，當隊列得長度小於低閾值時不丟棄報文；當隊列長度在高低閾值之間時，開始隨機丟棄報文，隊列長度越長，丟棄概率越高；當隊列長度大於高閾值時，則丟棄所有報文。
由於RED隨機地丟棄報文，將避免使多個TCP連接同時降低發送速度，從而避免了TCP的全局同步現象，當某個TCP連接的報文被丟棄開始減速發送的時候，其他的TCP連接仍然有較高的發送速度，這樣無論什麼時候總有TCP連接在進行較快的發送，提高了線路帶寬的利用率。
WRED
現在所採用的基本上都是WRED（Weighted Random Early Detection）。原理和RED一樣，區別在於WRED引入了IP優先權DSCP值來區別丟棄策略，可以爲不同IP優先級DSCP 設定不同的隊列長度、隊列閾值、丟棄概率，從而對不同優先級的報文指定不同的丟棄特性。
在設置時如果直接採用隊列的長度與用戶設定的閾值比較並進行丟棄，將會對突發性的數據流造成不公正的待遇，不利於數據流的傳輸，所以在與設定的閾值比較並進行丟棄時採用隊列的平均長度。
平均隊列長度 = （以前的平均隊列長度*(1-1/2^n)+(當前隊列長度/2^n)
隊列的平均長度既反映了隊列的變化趨勢又對隊列長度的突發變化不敏感避免了對突發性的數據流造成不公正的待遇。另外還要注意WRED不能配置在使用了基於路由交換處理器(RSP)的CQ、PQ和WFQ隊列機制的接口上。
基於流的WRED
只有自適應TCP流會對擁塞信號做出反應並降低速率；而非自適應UDP流並不會對擁塞信號做出反應，也不降低地中，由於這個原因，非自適應流在擁塞時發送分組的速率將比自適應流高得多，因此貪婪的非自適應流常常比自適應流量使用更多的隊列資源。
流WRED對WRED做了改進，它對佔用的隊列資源比公平份額多的流進行懲罰。爲了給隊列中活動的通信流以公平，WRED根則流和IP優先級將所有到達的分組歸類到隊列中。它還維護所有活動隊列(即隊列中有分組的的流)的狀態估息，這種狀態信息用於決定每個流的公平隊列資源份額(隊列長度／活動流的數目)，而佔用的隊列資源多於自已的公平份額的流得到的懲罰將比其他流嚴厲。
流量整形
流量整形(traffic shaping)典型作用是限制流出某一網絡的某一連接的流量與突發，使這類報文以比較均勻的速度向外發送。流量整形通常使用緩衝區和令牌桶來完成，當報文的發送速度過快時，首先在緩衝區進行緩存，在令牌桶的控制下再均勻地發送這些被緩衝的文。
流量整形的核心算法有以下兩種，具體採用的技術爲GTS（Generic Traffic Shaping），通用流量整形：
漏桶算法（Leaky Bucket）
漏桶算法是網絡世界中流量整形（Traffic Shaping）或速率限制（Rate Limiting）時經常使用的一種算法，它的主要目的是控制數據注入到網絡的速率，平滑網絡上的突發流量。漏桶算法提供了一種機制，通過它，突發流量可以被整形以便爲網絡提供一個穩定的流量。
令牌桶算法（Token Bucket）
有時人們將漏桶算法與令牌桶算法錯誤地混淆在一起。而實際上，這兩種算法具有截然不同的特性並且爲截然不同的目的而使用。它們之間最主要的差別在於：漏桶算法能夠強行限制數據的傳輸速率，而令牌桶算法能夠在限制數據的平均傳輸速率的同時還允許某種程度的突發傳輸。
在某些情況下，漏桶算法不能夠有效地使用網絡資源。因爲漏桶的漏出速率是固定的參數，所以即使網絡中不存在資源衝突（沒有發生擁塞），漏桶算法也不能使某一個單獨的流突發到端口速率。因此，漏桶算法對於存在突發特性的流量來說缺乏效率。而令牌桶算法則能夠滿足這些具有突發特性的流量。通常，漏桶算法與令牌桶算法可以結合起來爲網絡流量提供更大的控制。
GTS
GTS可以對不規則或不符合預定流量特性的流量進行整形，使得網絡上下游之間的帶寬匹配。GTS與CAR一樣均採用了令牌桶技術來控制流量，但主要區別在於：利用CAR進行報文流量控制時對不符合流量特性的報文進行丟棄，而GTS對於不符合流量特性的報文則是進行緩衝減少了報文的丟棄，同時滿足報文的流量特性。
GTS可以對接口上指定的報文流或所有報文進行整形當報文到來的時候，首先對報文進行分類如果報文不需要進行GTS處理，就繼續發送不經過令牌桶的處理；如果報文需要進行 GTS處理，則與令牌桶中的令牌進行比較。
令牌桶按用戶設定的速度向桶中放置令牌，如果令牌桶中有足夠的令牌可以用來發送報文，則報文直接被繼續發送下去，同時令牌桶中的令牌量按報文的長度做相應的減少，當令牌桶中的令牌少到報文不能再發送時，報文將被緩存入GTS隊列中。
當GTS隊列中有報文的時候，GTS按一定的週期從隊列中取出報文進行發送。 每次發送都會與令牌桶中的令牌數作比較。直到令牌桶中的令牌數減少到隊列中的報文不能 再發送或是隊列中的報文全部發送完畢爲止。
幀中繼流量整形（FRTS）
在以下4種情況下使用FRTS：1中心高速，分支低速的時候。2單條物理線路承載到不同目的地的衆多VC。3若FR發生了擁塞，想讓路由器將數據流攔住（Throttle）。4需要在同一條FR的VC上傳輸多種協議（IP、SNA）的數據流，並希望每種數據流都能佔到一定BW。
FR中的FECN和BECN用於暗示網絡上發生了擁塞，當收到帶有BECN標記的數據包時，FR 流量整形(FRTS)將動態的對流量進行整形。注意：FRTS只能使用在FR的PVC和SVC上。其中有一種自適應的FRTS，在每個Tc間隔內，進程將檢查是否從幀中繼網絡中收到BECN，如果在一個Tc間隔收到BECN，那麼傳送速率降低25%直到降到CIR的一半爲止。當且僅當16個Tc內沒收到BECN，通訊速率恢復到CIR。
FRTS配置步驟
1）建立一個MAP-CLASS，名字區分大小寫。
2）定義流量整形的方法，比如設置平均速率和最高速率。
3）在接口上封裝FRAME-RELAY。
4）在端口上應用MAP-CLASS 5，開啓流量整形，一般用於源端接口。
本文出自 “Steven.Q的學習筆記” 博客，謝絕轉載！