1 概述
1.1 產生背景
在傳統的IP網絡中，所有的報文都被無區別的等同對待，每個轉發設備對所有的報文均採用先入先出（FIFO）的策略進行處理，它盡最大的努力（Best-Effort）將報文送到目的地，但對報文傳送的可靠性、傳送延遲等性能不提供任何保證。
網絡發展日新月異，隨着IP網絡上新應用的不斷出現，對IP網絡的服務質量也提出了新的要求，例如VoIP等實時業務就對報文的傳輸延遲提出了較高要求，如果報文傳送延時太長，用戶將不能接受（相對而言，E-Mail和FTP業務對時間延遲並不敏感）。爲了支持具有不同服務需求的語音、視頻以及數據等業務，要求網絡能夠區分出不同的通信，進而爲之提供相應的服務。傳統IP網絡的盡力服務不可能識別和區分出網絡中的各種通信類別，而具備通信類別的區分能力正是爲不同的通信提供不同服務的前提，所以說傳統網絡的盡力服務模式已不能滿足應用的需要。
QoS技術的出現便致力於解決這個問題。
1.2 技術優點
QoS旨在針對各種應用的不同需求，爲其提供不同的服務質量。如：
l 可以限制骨幹網上FTP使用的帶寬，也可以給數據庫訪問以較高優先級。
l 對於ISP，其用戶可能傳送語音、視頻或其他實時業務，QoS使ISP能區分這些不同的報文，並提供不同服務。
l 可以爲時間敏感的多媒體業務提供帶寬和低時延保證，而其他業務在使用網絡時，也不會影響這些時間敏感的業務。
1.3 QoS服務模型簡介
通常QoS提供以下三種服務模型（服務模型，是指一組端到端的QoS功能）：
l Best-Effort service（盡力而爲服務模型）
l Integrated service（綜合服務模型，簡稱IntServ）
l Differentiated service（區分服務模型，簡稱DiffServ）
1.3.1 Best-Effort服務模型
Best-Effort是一個單一的服務模型，也是最簡單的服務模型。應用程序可以在任何時候，發出任意數量的報文，而且不需要事先獲得批准，也不需要通知網絡。對Best-Effort服務，網絡盡最大的可能性來發送報文。但對時延、可靠性等性能不提供任何保證。
Best-Effort服務是現在Internet的缺省服務模型，它適用於絕大多數網絡應用，如FTP、E-Mail等，它通過FIFO隊列來實現。
1.3.2 IntServ服務模型
IntServ是一個綜合服務模型，它可以滿足多種QoS需求。這種服務模型在發送報文前，需要向網絡申請特定的服務。這個請求是通過信令RSVP來完成的。RSVP是在應用程序開始發送報文之前來爲該應用申請網絡資源的，所以是帶外信令。
應用程序首先通知網絡它自己的流量參數和需要的特定服務質量請求，包括帶寬、時延等。網絡在收到應用程序的資源請求後，執行資源分配檢查，即基於應用程序的資源申請和網絡現有的資源情況，判斷是否爲應用程序分配資源。一旦網絡確認爲應用程序分配資源，則網絡將爲每個流（Flow，由兩端的IP地址、端口號、協議號確定）維護一個狀態，並基於這個狀態執行報文的分類、流量監管、排隊及其調度。應用程序在收到網絡的確認信息（即確認網絡已經爲這個應用程序的報文預留了資源）後，纔開始發送報文。只要應用程序的報文控制在流量參數描述的範圍內，網絡將承諾滿足應用程序的QoS需求。
IntServ可以提供以下兩種服務：
l 保證服務：它提供保證的帶寬和時延限制來滿足應用程序的要求。如VoIP應用可以預留10M帶寬和要求不超過1秒的時延。
l 負載控制服務：它保證即使在網絡過載的情況下，能對報文提供近似於網絡未過載類似的服務，即在網絡擁塞的情況下，保證某些應用程序的報文低時延和優先通過。
1.3.3 DiffServ服務模型
DiffServ是一個多服務模型，它可以滿足不同的QoS需求。與IntServ不同，它不需要使用RSVP，即應用程序在發出報文前，不需要通知網絡爲其預留資源。對DiffServ服務模型，網絡不需要爲每個流維護狀態，它根據每個報文的差分服務類（IP報文頭中的差分服務標記字段DSCP值），來提供特定的服務。
在實施DiffServ的網絡中，每一個轉發設備都會根據報文的DSCP字段執行相應的轉發行爲，主要包括以下三類轉發行爲：
l 加速轉發（EF）：主要用於低延遲、抖動和丟包率的業務，這類業務一般運行一個相對穩定的速率，需要在轉發設備中進行快速轉發；
l 確保轉發（AF）：採用此轉發行爲的業務在沒有超過最大允許帶寬時能夠確保轉發，一旦超出最大允許帶寬，則將轉發行爲分爲4類，每類又可劃分爲3個不同的丟棄優先級，其中每一個確保轉發類都被分配了不同的帶寬資源。IETF建議使用4個不同的隊列分別傳輸AF1x、AF2x、AF3x、AF4x業務，並且每個隊列提供3種不同的丟棄優先級，因此可以構成12個有保證轉發的PHB；
l 盡力轉發（BE）：主要用於對時延、抖動和丟包不敏感的業務。
區分服務只包含有限數量的業務級別，狀態信息的數量少，因此實現簡單，擴展性較好。它的不足之處是很難提供基於流的端到端的質量保證。目前，區分服務是業界認同的IP骨幹網的QoS解決方案，儘管IETF爲每個標準的PHB都定義了推薦的DSCP值，但是設備廠家可以重新定義DSCP與PHB之間的映射關係，因此不同運營商的DiffServ網絡之間的互通還存在困難，不同DiffServ網絡在互通時必須維護一致的DSCP與PHB映射。
1.3.4 IntServ與DiffServ之間的互通
一般來講，在提供IP網絡的QoS時，爲了適應不同規模的網絡，在IP骨幹網往往需要採用DiffServ體系結構；在IP邊緣網可以有兩種選擇：採用DiffServ體系結構或採用IntServ體系結構。目前在IP邊緣網絡採用哪一種QoS體系結構還沒有定論，也許這兩種會同時並存於IP邊緣網中。在IP邊緣網採用DiffServ體系結構的情況下，IP骨幹網與IP邊緣網之間的互通沒有問題。在IP邊緣網採用IntServ體系結構的情況下，需要解決IntServ與DiffServ之間的互通問題，包括RSVP在DiffServ域的處理方式、IntServ支持的服務與DiffServ支持的PHB之間的映射。
RSVP在DiffServ域的處理可以有多種可選擇的方式。例如下面兩種：
l 一種方式爲RSVP對DiffServ域透明，RSVP在IntServ域邊界轉發設備終結，DiffServ域對IntServ域採用靜態資源提供方式。本方式實現相對簡單，但可能造成DiffServ域資源的浪費。
l 一種方式爲DiffServ域參與RSVP協議處理，DiffServ域對IntServ域採用動態資源提供方式。本方式實現相對複雜，但可以優化DiffServ域資源的使用。
根據IntServ支持的服務和DiffServ提供的PHB的特點，IntServ支持的服務與DiffServ支持的PHB之間的映射問題可以通過下面方式解決：
l 將IntServ中的保證服務映射爲DiffServ中的EF。
l 將IntServ中的負載控制服務映射爲DiffServ中的AF。
2 IP QoS技術實現
目前，H3C的IP網絡產品已經全面提供對DiffServ服務模型的支持：
l 完全兼容DiffServ服務模型的相關標準，包括RFC2474、RFC2475、RFC2597、RFC2598等；
l 支持以IP Precedence或DSCP作爲QoS帶內信令，可靈活配置；
l 支持DiffServ相關的功能組件，包括流量調節器（包括分類器、標記器、測量單元、整形器和丟棄器等）和各類PHB（擁塞管理、擁塞避免等）。
2.1 IP QoS功能總述
IP QoS技術提供了下述功能：
l 流量分類和標記：依據一定的匹配規則識別出對象，是有區別地實施服務的前提，通常作用在接口入方向。
l 擁塞管理：是必須採取的解決資源競爭的措施，將報文放入隊列中緩存，並採取某種調度算法安排報文的轉發次序，通常作用在接口出方向。
l 擁塞避免：過度的擁塞會對網絡資源造成損害，擁塞避免監督網絡資源的使用情況，當發現擁塞有加劇的趨勢時採取主動丟棄報文的策略，通過調整流量來解除網絡的過載，通常作用在接口出方向。
l 流量監管：對進入設備的特定流量的規格進行監管，通常作用在接口入方向。當流量超出規格時，可以採取限制或懲罰措施，以保護運營商的商業利益和網絡資源不受損害。
l 流量整形：一種主動調整流的輸出速率的流控措施，是爲了使流量適配下游設備可供給的網絡資源，避免不必要的報文丟棄和擁塞，通常作用在接口出方向。
l 鏈路效率機制：可以改善鏈路的性能，間接提高網絡的QoS，如降低鏈路發包的時延（針對特定業務）、調整有效帶寬。
在這些QoS技術中，流量分類和標記是基礎，是有區別地實施服務的前提；而其他QoS技術則從不同方面對網絡流量及其分配的資源實施控制，是有區別地提供服務思想的具體體現。
網絡設備對QoS的支持是通過結合各種QoS技術來實現的。圖1描述了各種QoS技術在網絡設備中的處理順序。
圖1 各QoS技術在同一網絡設備中的處理順序
首先是流量分類，其後根據報文所屬類別再將CAR、GTS、WRED、隊列等各種技術運用其上，最終爲具有不同網絡需求的各種業務提供並保證所承諾的服務。
2.1 流量分類和標記
流量分類是將數據報文劃分爲多個優先級或多個服務類。網絡管理者可以設置流量分類的策略，這個策略除可以包括IP報文的IP優先級或DSCP值、802.1p的CoS值等帶內信令，還可以包括輸入接口、源IP地址、目的IP地址、MAC地址、IP協議或應用程序的端口號等。分類的結果是沒有範圍限制的，它可以是一個由五元組（源IP地址、源端口號、協議號、目的IP地址、目的端口號）確定的流這樣狹小的範圍，也可以是到某某網段的所有報文。
下游網絡可以選擇接受上游網絡的分類結果，也可以按照自己的分類標準對數據流量重新進行分類。
下面分別介紹一下在IPv4、IPv6、二層以太網中如何對流量進行分類和標記。
2.1.1 IP QoS業務分類
IP優先級和DSCP在報文中的位置如圖2所示。
(1) 基於IP優先級的業務分類
IPv4報文在IP報文頭的ToS域中定義了8種IP業務類型，如表1所示。
表1 8種IP業務類型定義
|
業務類型 |
IP優先級 |
|
Network Control |
7 |
|
Internet work Control |
6 |
|
CRITIC/ECP |
5 |
|
Flash Override |
4 |
|
Flash |
3 |
|
Immediate |
2 |
|
Priority |
1 |
|
Routine |
0 |
(2) 基於DSCP的業務分類
DiffServ模型定義了64種業務類型，其中典型的業務類型定義如表2所示。
|
業務類型 |
DSCP PHB |
DSCP值 |
|
Network Control |
CS7(111000) |
56 |
|
IP Routing |
CS6(110000) |
48 |
|
Interactive Voice |
EF(101110) |
46 |
|
Interactive Video |
AF41(100010) |
34 |
|
Video control |
AF31(011010) |
26 |
|
Transactional/Interactive(對應高優先級應用) |
AF2x(010xx0) |
18、20、22 |
|
Bulk Data(對應中優先級應用) |
AF1x(001xx0) |
10、12、14 |
|
Streaming Video |
CS4(000100) |
4 |
|
Telephony Signaling |
CS3(000011) |
3 |
|
Network Management |
CS2(000010) |
2 |
|
Scavenger |
CS1(000001) |
1 |
|
Best Effort |
0 |
0 |
2.1.2 IPv6 QoS業務分類
IPv6在報頭中保留了類似IPv4的ToS域，稱爲傳輸級別域（TC），以繼續爲IP提供差分QoS服務，可以基於IPv6 ToS域進行業務分類與標記。同時IPv6報頭中增加20比特流標籤（Flow Label）域，可供後續擴展用。
2.1.3 以太網QoS業務分類
以太網在以太網幀頭的VLAN TAG中定義了8種業務優先級（CoS，Class of Service），如圖3所示。
每一種業務映射到出端口的哪個隊列轉發將關係到該業務的時延、抖動和可獲得的帶寬。8種以太網業務類型定義如表3所示。
表3 8種以太網CoS業務類型定義
|
業務類型 |
業務特徵 |
以太網CoS |
協議舉例 |
|
Network Control |
適用於網絡維護與管理報文的可靠傳輸，要求低丟包率 |
7 |
BGP, PIM, SNMP |
|
Internet work Control |
適用於大型網絡中區分於普通流量的網絡協議控制報文，要求低丟包率和低時延 |
6 |
STP, OSPF, RIP |
|
Voice |
適用於語音業務，一般要求時延小於10 ms |
5 |
SIP, MGCP |
|
Video |
適用於視頻業務，一般要求時延小於 100 ms |
4 |
RTP |
|
Critical Applications |
適用於要求確保最小帶寬的業務 |
3 |
NFS, SMB, RPC |
|
Excellent Effort |
也稱爲“CEO’s best effort”， 比best effort的傳輸優先級稍高一些，用於一般的信息組織向最重要的客戶發送信息 |
2 |
SQL |
|
Best Effort |
缺省使用的業務類型，無優先發送的要求，只要求“盡力而爲”的服務質量 |
1 |
HTTP, IM, X11 |
|
Background |
適用於不影響用戶或關鍵應用的批量傳輸業務 |
0 |
FTP, SMTP |
IEEE 802.1Q推薦的業務類型到隊列的映射關係定義如表4所示。
表4 IEEE 802.1Q推薦的CoS類型與隊列的映射關係
|
Number of queues |
Queue ID |
業務類型 |
|
1 |
1 |
Best Effort, Background, Excellent effort, Critical Applications, Voice, Video, Internet work Control, Network Control |
|
2 |
1 |
Best Effort, Background, Excellent effort, Critical Applications |
|
2 |
Voice, Video, Internet work Control, Network Control |
|
|
3 |
1 |
Best Effort, Background, Excellent effort, Critical Applications |
|
2 |
Voice, Video |
|
|
3 |
Network Control, Internet work Control |
|
|
4 |
1 |
Best Effort, Background |
|
2 |
Critical Applications, Excellent effort |
|
|
3 |
Voice, Video |
|
|
4 |
Network Control, Internet work Control |
|
|
5 |
1 |
Best Effort, Background |
|
2 |
Critical Applications, Excellent effort |
|
|
3 |
Voice, Video |
|
|
4 |
Internet work Control |
|
|
5 |
Network Control |
|
|
6 |
1 |
Background |
|
2 |
Best Effort |
|
|
3 |
Critical Applications, Excellent effort |
|
|
4 |
Voice, Video |
|
|
5 |
Internet work Control |
|
|
6 |
Network Control |
|
|
7 |
1 |
Background |
|
2 |
Best Effort |
|
|
3 |
Excellent effort |
|
|
4 |
Critical Applications |
|
|
5 |
Voice, Video |
|
|
6 |
Internet work Control |
|
|
7 |
Network Control |
|
|
8 |
1 |
Background |
|
2 |
Best Effort |
|
|
3 |
Excellent effort |
|
|
4 |
Critical Applications |
|
|
5 |
Video |
|
|
6 |
Voice |
|
|
7 |
Internet work Control |
|
|
8 |
Network Control |
2.2 擁塞管理
在計算機數據通信中，通信信道是被多個計算機共享的，並且，廣域網的帶寬通常要比局域網的帶寬小，這樣，當一個局域網的計算機向另一個局域網的計算機發送數據時，由於廣域網的帶寬小於局域網的帶寬，數據將不可能按局域網發送的速度在廣域網上傳輸。此時，處在局域網和廣域網之間的轉發設備將不能發送某些報文，即網絡發生了擁塞。如圖4所示，當局域網 1向局域網 2以10M的速度發送數據時，將會使Router 1的串口S1發生擁塞。
擁塞管理是指在網絡發生擁塞時，如何進行管理和控制。處理的方法是使用隊列技術，具體過程包括隊列的創建、報文的分類、將報文送入不同的隊列、隊列調度等。當接口沒有發生擁塞時，報文到達接口後立即被髮送出去，當報文到達的速度超過接口發送報文的速度時，接口就發生了擁塞。擁塞管理就會將這些報文進行分類，送入不同的隊列；而隊列調度將對不同優先級的報文進行分別處理，優先級高的報文會得到優先處理。常用的隊列有FIFO、PQ、CQ、WFQ、CBWFQ、RTP優先隊列等，下面將對這些隊列進行詳細的介紹。
2.2.1 先進先出隊列（FIFO）
如圖5所示，先進先出隊列（以後簡稱FIFO）不對報文進行分類，當報文進入接口的速度大於接口能發送的速度時，FIFO按報文到達接口的先後順序讓報文進入隊列，同時，FIFO在隊列的出口讓報文按進隊的順序出隊，先進的報文將先出隊，後進的報文將後出隊。
在如圖4所示的網絡圖中，假設局域網 1的Server 1向局域網 2的Server 2發送關鍵業務的數據，局域網 1的PC 1向局域網 2的PC 2發送非關鍵業務的數據，則FIFO不會對這兩種不同業務的報文做任何區別對待，報文的出隊完全依賴於報文到來的先後順序。
2.2.2 優先隊列（PQ）
圖6 PQ隊列示意圖
如圖6所示，優先隊列（以後簡稱PQ）對報文進行分類，對於IP網絡，可以根據IP報文的優先級/DSCP、五元組等條件進行分類，對於MPLS網絡，則根據MPLS報文EXP域值進行分類。最終將所有報文分成最多至4類，分別屬於PQ的4個隊列中的一個，然後，按報文的類別將報文送入相應的隊列。PQ的4個隊列分別爲：高優先隊列、中優先隊列、正常優先隊列和低優先隊列，它們的優先級依次降低。在報文出隊的時候，PQ首先讓高優先隊列中的報文出隊併發送，直到高優先隊列中的報文發送完，然後發送中優先隊列中的報文，同樣直到發送完，然後是正常優先隊列和低優先隊列。這樣，分類時屬於較高優先級隊列的報文將會得到優先發送，而較低優先級的報文將會在發生擁塞時被較高優先級的報文搶先，使得高優先級業務（如VoIP）的報文能夠得到優先處理，較低優先級業務（如E-Mail）的報文在網絡處理完關鍵業務後的空閒中得到處理，既保證了高優先級業務的優先，又充分利用了網絡資源。
在如圖4所示的網絡圖中，假設局域網 1的Server 1向局域網 2的Server 2發送關鍵業務的數據，局域網 1的PC 1向局域網 2的PC 2發送非關鍵業務的數據，如果對Router 1的串口S1配置PQ進行擁塞管理，同時配置Server間的數據流進入較高優先級的隊列，PC間的數據流進入較低優先級的隊列，則PQ將對這兩種不同業務的報文做區別對待，Server間的報文總是被先發送，直到暫時沒有Server間的報文，轉發設備才發送PC間的報文。
2.2.3 定製隊列（CQ）
如圖7所示，定製隊列（以後簡稱CQ）對報文進行分類，對於IP網絡，可以根據IP報文的優先級/DSCP、五元組等條件進行分類，對於MPLS網絡，則根據MPLS報文EXP域值進行分類。最終將所有報文分成最多至16類，分別屬於CQ的16個隊列中的一個，然後按報文的類別將報文送入相應的隊列。CQ的1到16號隊列，可以按用戶的定義分配它們能佔用接口帶寬的比例。在報文出隊的時候，CQ按定義的帶寬比例分別從1到16號隊列中取一定量的報文在接口上發送出去。
現在我們將CQ和PQ做個比較：
l PQ賦予較高優先級的報文絕對的優先權，這樣雖然可以保證關鍵業務的優先，但在較高優先級的報文的速度總是大於接口的速度時，將會使較低優先級的報文始終得不到發送的機會。採用CQ，則可以避免這種情況的發生。
l CQ可以規定每個隊列中的報文所佔接口帶寬的比例，這樣，就可以讓不同業務的報文獲得合理的帶寬，從而既保證關鍵業務能獲得較多的帶寬，又不至於使非關鍵業務得不到帶寬。但是，由於CQ輪詢調度各個隊列，它對高優先級尤其是實時業務的時延保證不如PQ。
在如圖4所示的網絡圖中，假設局域網 1的Server 1向局域網 2的Server 2發送關鍵業務的數據，局域網 1的PC 1向局域網 2的PC 2發送非關鍵業務的數據，可以在Router 1的串口S1配置如下CQ進行擁塞管理：
l 配置Server間的數據流進入隊列1，隊列1中的報文佔有60%的帶寬（例如每次出隊6000個字節的報文）；
l 配置PC間的數據流進入隊列2，隊列2中的報文佔有20%的帶寬（例如每次出隊2000個字節的報文）；
l 配置其他隊列中的報文共佔有20%的帶寬（例如每次出隊2000個字節的報文）。
那麼，CQ對這兩種不同業務的報文將做區別對待。報文的發送採用輪詢調度的方式，首先讓隊列1中的報文出隊併發送，直到此隊列中的報文被髮送的字節數不少於6000字節，然後纔開始發送隊列2中的報文，直到此隊列中的報文被髮送的字節數不少於2000字節，然後是其他隊列。各種數據報文佔用帶寬的情況如下：
l Router 1的串口S1的物理帶寬是2M，則發送關鍵業務的數據所能佔的帶寬將至少爲1.2M（2*0.6），發送非關鍵業務的數據所能佔的帶寬將至少爲0.4M（2*0.2）。
l 當S1中除了上述兩個數據流外沒有其他數據要發送時，這兩種數據流將按比例分享接口的剩餘空閒帶寬，即發送關鍵業務的數據所能佔的帶寬將爲1.5M（2*0.6/（0.2+0.6）），發送非關鍵業務的數據所能佔的帶寬爲0.5M（2*0.2/（0.2+0.6））。
l 當S1中只有非關鍵業務的數據要發送時，發送非關鍵業務的數據所能佔的帶寬將可以爲2M。
2.2.4 加權公平隊列（WFQ）
如圖8所示，加權公平隊列（以後簡稱WFQ）對報文按流進行分類：對於IP網絡，相同源IP地址、目的IP地址、源端口號、目的端口號、協議號、IP優先級（或DSCP）的報文屬於同一個流；而對於MPLS網絡，具有相同EXP域值的報文屬於同一個流。每一個流被分配到一個隊列，儘量將不同的流分入不同的隊列。WFQ的隊列數目N可以配置。在出隊的時候，WFQ按流的IP優先級（或DSCP、EXP域值）來分配每個流佔有出口的帶寬。優先級的數值越小，所得的帶寬越少。優先級的數值越大，所得的帶寬越多。這樣就保證了同優先級業務之間的公平，體現了不同優先級業務之間的權值。
例如：接口中當前有8個流，它們的優先級分別爲0、1、2、3、4、5、6、7。則帶寬的總配額將是所有（流的優先級+1）之和，即1+2+3+4+5+6+7+8=36。每個流所佔帶寬比例爲：（自己的優先級數+1）/（所有（流的優先級+1）之和）。即，每個流可得的帶寬比例分別爲：1/36、2/36、3/36、4/36、5/36、6/36、7/36、8/36。
又如：當前共4個流，3個流的優先級爲4，1個流的優先級爲5，則帶寬的總配額將是：（4+1）*3+（5+1）=21。那麼，3個優先級爲4的流獲得的帶寬比例均爲5/21，優先級爲5的流獲得的帶寬比例爲6/21。
由此可見，WFQ在保證公平的基礎上對不同優先級的業務體現權值，而權值依賴於報文所攜帶的優先級。
2.2.5 基於類的加權公平隊列（CBWFQ）
如圖9所示，基於類的加權公平隊列（以後簡稱CBWFQ）首先根據IP優先級或者DSCP、輸入接口、IP報文的五元組等規則來對報文進行分類；對於MPLS網絡的LSR，主要是根據EXP域值進行分類，然後讓不同類別的報文進入不同的隊列。對於不匹配任何類別的報文，報文被送入系統定義的缺省類。
CBWFQ分爲三類隊列：EF隊列、AF隊列、BE隊列，下面分別進行介紹。
(1) EF隊列
如圖9所示，EF隊列是一個具有高優先級的隊列，一個或多個類的報文可以被設定進入EF隊列，不同類別的報文可設定佔用不同的帶寬（通過此方式模擬出多個EF隊列）。在調度出隊的時候，若EF隊列中有報文，則總是優先發送EF隊列中的報文，直到EF隊列中沒有報文時，或者超過爲EF隊列配置的最大預留帶寬時才調度發送其他隊列中的報文。
進入EF隊列的報文，在接口沒有發生擁塞時（此時所有隊列中都沒有報文）都可以被髮送；在接口發生擁塞時（隊列中有報文時）會被限速，超出規定流量的報文將被丟棄。這樣，屬於EF隊列的報文既可以獲得空閒的帶寬，又不會佔用超出規定的帶寬，保護了其他報文的應得帶寬。另外，由於只要EF隊列中有報文，系統就會發送EF隊列中的報文，所以EF隊列中的報文被髮送的延遲最多是接口發送一個最大長度報文的時間，無論是時延還是時延抖動，EF隊列都可以將之降低爲最低限度。這爲對時延敏感的應用（如VoIP業務）提供了良好的服務質量保證。
對於EF隊列，由於在接口擁塞的時候流量限制開始起作用，所以用戶不必設置隊列的長度。由於優先隊列中的報文一般是語音報文（VoIP），採用的是UDP報文，所以沒有必要採用WRED的丟棄策略，採用尾丟棄策略即可。
(2) AF隊列
圖9中，AF隊列1到64分別對應一類報文，用戶可以設定每類報文佔用的帶寬。在系統調度報文出隊的時候，按用戶爲各類報文設定的帶寬將報文出隊發送。這種隊列技術應用了先進的隊列調度算法，可以實現各個類的隊列的公平調度。當接口中某些類別的報文沒有時，AF隊列的報文還可以公平地得到空閒的帶寬，和時分複用系統相比，大大提高了線路的利用率。同時，在接口擁塞的時候，仍然能保證各類報文得到用戶設定的最小帶寬。
對於AF隊列，當隊列的長度達到隊列的最大長度時，缺省採用尾丟棄的策略，但用戶還可以選擇用WRED丟棄策略（請參見後面關於WRED的描述）。
(3) BE隊列
當報文不匹配用戶設定的所有類別時，報文被送入系統定義的缺省類。雖然允許爲缺省類配置AF隊列，並配置帶寬，但是更多的情況是爲缺省類配置BE隊列。BE隊列使用WFQ調度，使所有進入缺省類的報文進行基於流的隊列調度。
對於BE隊列，當隊列的長度達到隊列的最大長度時，缺省採用尾丟棄的策略，但用戶還可以選擇用WRED丟棄策略（請參見後面關於WRED的描述）。
(4) 三種隊列的配合
綜上所述：
l 低時延隊列（EF隊列）用來支撐EF類業務，被絕對優先發送，保證時延；
l 帶寬保證隊列（AF隊列）用來支撐AF類業務，可以保證每一個隊列的帶寬及可控的時延；
l 缺省隊列（BE隊列）對應BE業務，使用接口剩餘帶寬進行發送。
對於進入EF隊列和AF隊列的報文要進行測量，考慮到鏈路層控制報文的發送鏈路層封裝開銷及物理層開銷（如ATM信元頭），建議EF隊列與AF隊列佔用接口的總帶寬不要超過接口帶寬的80%。
2.2.6 RTP優先隊列
圖10 RTP優先隊列示意圖
RTP優先隊列是一種解決實時業務（包括語音與視頻業務）服務質量的簡單的隊列技術。其原理就是將承載語音或視頻的RTP報文送入高優先級隊列，使其得到優先發送，保證時延和抖動降低爲最低限度，從而保證了語音或視頻這種對時延敏感業務的服務質量。
如圖10所示，RTP報文被送入一個具有較高優先級的RTP優先隊列。RTP報文是端口號在一定範圍內爲偶數的UDP報文，端口號的範圍可以配置，一般爲16384～32767。RTP優先隊列可以同前面所述的各種隊列（包括FIFO、PQ、CQ、WFQ）結合使用，它的優先級是最高的。由於CBWFQ中的LLQ完全可以解決實時業務的QoS問題，所以不支持將RTP優先隊列與CBWFQ結合應用。
由於對進入RTP優先隊列的報文進行了限速，超出規定流量的報文將被丟棄，這樣在接口擁塞的情況下，可以保證屬於RTP優先隊列的報文不會佔用超出規定的帶寬，保護了其他報文的應得帶寬，解決了RTP優先隊列的流量可能“餓死”其他數據流量的問題。
2.2.7 隊列技術對比
上述隊列技術，突破了傳統IP設備的單一FIFO擁塞管理策略，提供了強大的QoS能力，使得IP設備可以滿足不同業務的不同服務質量的要求。爲了更好的利用這些隊列技術，現對各種隊列技術做一比較。
2.3 擁塞避免
過度的擁塞會對網絡資源造成極大危害，必須採取某種措施加以解除。擁塞避免是一種流控機制，它可以通過監視網絡資源（如隊列或內存緩衝區）的使用情況，在擁塞有加劇的趨勢時，主動丟棄報文，通過調整網絡的流量來解除網絡過載。
與端到端的流控相比，這裏的流控具有更廣泛的意義，它影響到設備中更多的業務流的負載。設備在丟棄報文時，並不排斥與源端的流控動作（比如TCP流控）的配合，更好地調整網絡的流量到一個合理的負載狀態。丟包策略和源端流控機制有效的組合，可以使網絡的吞吐量和利用效率最大化，並且使報文丟棄和延遲最小化。
2.3.1 傳統的丟包策略
傳統的丟包策略採用尾部丟棄（Tail-Drop）的方法。當隊列的長度達到某一最大值後，所有新到來的報文都將被丟棄。
這種丟棄策略會引發TCP全局同步現象——當隊列同時丟棄多個TCP連接的報文時，將造成多個TCP連接同時進入擁塞避免和慢啓動狀態以降低並調整流量，而後又會在某個時間同時出現流量高峯，如此反覆，使網絡流量不停震盪。
2.3.2 RED與WRED
爲避免TCP全局同步現象，可使用RED或WRED。
在RED類算法中，爲每個隊列都設定上限和下限，對隊列中的報文進行如下處理：
l 當隊列的長度小於下限時，不丟棄報文；
l 當隊列的長度超過上限時，丟棄所有到來的報文；
l 當隊列的長度在上限和下限之間時，開始隨機丟棄到來的報文。隊列越長，丟棄概率越高，但有一個最大丟棄概率。
直接採用隊列的長度和上限、下限比較並進行丟棄，將會對突發性的數據流造成不公正的待遇，不利於數據流的傳輸。RED類算法採用平均隊列長度和設置的隊列上限、下限比較來確定丟棄的概率。計算隊列平均長度的公式爲：平均隊列長度=（以前的平均隊列長度×（1-1/（2的n次方）））＋（當前隊列長度×（1/（2的n次方））），其中n可以通過命令配置。隊列平均長度既反映了隊列的變化趨勢，又對隊列長度的突發變化不敏感，避免了對突發性數據流的不公正待遇。
WRED算法在RED算法的基礎上引入了優先權，它引入IP優先級、DSCP和MPLS EXP區別丟棄策略，考慮了高優先權報文的利益，使其被丟棄的概率相對較小。如果對於所有優先權配置相同的丟棄策略，那麼WRED就變成了RED。
RED和WRED通過隨機丟棄報文避免了TCP的全局同步現象，使得當某個TCP連接的報文被丟棄、開始減速發送的時候，其他的TCP連接仍然有較高的發送速度。這樣，無論什麼時候，總有TCP連接在進行較快的發送，提高了線路帶寬的利用率。
2.3.3 WRED和隊列機制的關係
WRED和隊列機制的關係如圖11所示。
圖11 WRED和隊列機制關係示意圖
當隊列機制採用WFQ時：
l WRED可以爲不同優先級的報文設定計算隊列平均長度時的指數、上限、下限、丟棄概率，從而對不同優先級的報文提供不同的丟棄特性。
l 可以實現基於流的WRED。這是因爲，在進行分類的時候，不同的流有自己的隊列，對於流量小的流，由於其隊列長度總是比較小，所以丟棄的概率將比較小。而流量大的流將會有較大的隊列長度，從而丟棄較多的報文，保護了流量較小的流的利益。
當隊列機制採用FIFO、PQ、CQ時：
l WRED可以爲每個隊列設定計算隊列平均長度時的指數、上限、下限、丟棄概率，爲不同隊列的報文提供不同的丟棄特性。
l 對於流量小的流，由於其報文的個數較少，從統計概率來說，被丟棄的概率也會較小，也可以保護流量較小的流的利益。
2.4 流量監管與流量整形
流量監管的典型作用是限制進入某一網絡的某一連接的流量與突發。在報文滿足一定的條件時，如某個連接的報文流量過大，流量監管就可以對該報文采取不同的處理動作，例如丟棄報文，或重新設置報文的優先級等。通常的用法是使用CAR來限制某類報文的流量，例如限制HTTP報文不能佔用超過50%的網絡帶寬。
流量整形的典型作用是限制流出某一網絡的某一連接的流量與突發。使報文以比較均勻的速度向外發送。流量整形通常使用緩衝區和令牌桶來完成，當報文的發送速度過快時，首先在緩衝區進行緩存，在令牌桶的控制下，再均勻地發送這些被緩衝的報文。
2.4.1 約定訪問速率（CAR）
對於ISP來說，對用戶送入網絡中的流量進行控制是十分必要的。對於企業網，對某些應用的流量進行控制也是一個有力的控制網絡狀況的工具。網絡管理者可以使用約定訪問速率（以後簡稱CAR）來對流量（不包括緊急報文、協議報文）進行控制。
CAR利用令牌桶進行流量控制。
圖12 CAR進行流量控制的基本處理過程示意圖
圖12所示爲利用CAR進行流量控制的基本處理過程。首先，根據預先設置的匹配規則來對報文進行分類，對於不符合分類規則的報文，就直接繼續發送，並不需要經過令牌桶的處理；對於符合分類規則的報文，則會進入令牌桶中進行處理。令牌桶是一個控制數據流量的很好的工具。令牌桶按用戶設定的速度向桶中放置令牌，並且用戶可以設置令牌桶的容量，當桶中令牌的量達到桶的容量時，令牌不再增加。桶中的令牌數表示可借貸的數據突發量，這樣可以允許數據的突發性傳輸。如果令牌桶中有足夠的令牌可以用來發送報文，則允許報文通過，報文可以被髮送出去，同時，令牌桶中的令牌量隨報文發送相應減少。如果令牌桶中的令牌少到報文不能再發送時，則報文被丟棄。等到桶中生成了新的令牌，報文才可以被髮送出去，這就可以限制報文的流量只能小於等於令牌生成的速度，達到限制流量的目的。
在實際應用中，CAR不僅可以用來進行流量控制，還可以進行報文的標記或重新標記。即，通過CAR可以設置IP報文的優先級或修改IP報文的優先級，達到標記報文的目的。例如，當報文符合流量特性的時候，可以設置報文的優先級爲5；當報文不符合流量特性的時候，可以丟棄，也可以設置報文的優先級爲1並繼續進行發送。這樣，後續的處理可以儘量保證不丟棄優先級爲5的報文，在網絡不擁塞的情況下，也發送優先級爲1的報文；當網絡擁塞時，首先丟棄優先級爲1的報文，然後才丟棄優先級爲5的報文。
此外，CAR還可以對流量進行多次分類處理。例如，可以限制部分報文的流量符合某個流量特性，然後限制所有報文的總流量。
2.4.2 通用流量整形（GTS）
通用流量整形（以後簡稱GTS）可以對不規則或不符合預定流量特性的流量進行整形，以利於網絡上下游之間的帶寬匹配。
GTS與CAR一樣，均採用了令牌桶技術來控制流量。GTS與CAR的主要區別在於：利用CAR進行報文流量控制時，對不符合流量特性的報文進行丟棄；而GTS對於不符合流量特性的報文則是進行緩衝，減少了由突發流量造成的報文的丟棄。
GTS的基本處理過程如圖13所示，其中用於緩存報文的隊列稱爲GTS隊列。
圖13 GTS處理過程示意圖
GTS可以對接口上指定的報文流或所有報文進行整形。當報文到來的時候，首先根據預先設置的匹配規則來對報文進行分類，對於不符合分類規則的報文，就繼續發送，不需要經過令牌桶的處理；對於符合分類規則的報文，則會進入令牌桶中進行處理。令牌桶按用戶設定的速度向桶中放置令牌，如果令牌桶中有足夠的令牌可以用來發送報文，則報文直接被繼續發送出去，同時，令牌桶中的令牌量隨報文發送相應減少。當令牌桶中的令牌少到報文不能再發送時，報文將被緩存入GTS隊列中（後續到達GTS的報文，檢測到緩存隊列中有報文，直接入隊。若隊長達到上限，報文被直接丟棄）。當GTS隊列中有報文的時候，GTS按一定的週期從隊列中取出報文進行發送，每次發送都會與令牌桶中的令牌數作比較，直到令牌桶中的令牌數減少到隊列中的報文不能再發送或是隊列中的報文全部發送完畢爲止。
在如圖4所示的網絡圖中，爲了減少由突發流量造成的報文的丟失，可以在Router 1的出口對報文進行GTS處理，對於超出GTS流量特性的報文，將在Router 1中緩衝；當可以繼續發送下一批報文時，GTS再從緩衝隊列中取出報文進行發送。這樣，發往Router 2的報文將都符合Router 2的流量規定，從而減少報文在Router 2上的丟棄。相反，如果不在Router 1的出口做GTS處理，則所有超出Router 2的CAR流量特性的報文將被Router 2丟棄。
2.4.3 物理接口總速率限制（LR）
利用物理接口總速率限制（以後簡稱LR）可以在一個物理接口上限制接口發送報文（包括緊急報文、協議報文）的總速率。
LR的處理過程仍然採用令牌桶進行流量控制。如果用戶在轉發設備的某個接口上配置了LR，規定了流量特性，則所有經由該接口發送的報文首先要經過LR的令牌桶進行處理。如果令牌桶中有足夠的令牌可以用來發送報文，則報文可以發送；如果令牌桶中的令牌不滿足報文的發送條件，則報文入QoS隊列進行擁塞管理。這樣，就可以對通過該物理接口的報文流量進行控制。
圖14 LR處理過程示意圖
LR的處理過程如圖14所示。同樣的，由於採用了令牌桶控制流量，當令牌桶中積存有令牌時，可以允許報文的突發性傳輸。當令牌桶中沒有令牌的時候，報文將不能被髮送，只有等到桶中生成了新的令牌，報文才可以發送，這就可以限制報文的流量只能小於等於令牌生成的速度，達到限制流量的同時允許突發流量通過的目的。
由於LR不需對報文進行分類，所以當用戶只要求對所有報文進行限速時，可以採用LR，配置比較簡單。
相較於GTS，LR不但能夠對超過流量限制的報文進行緩存，並且可以利用QoS豐富的隊列來緩存報文，而GTS則是將報文緩存在GTS隊列中。
2.5 鏈路效率機制
鏈路效率機制可以改善鏈路的性能，間接提高網絡的QoS，如降低鏈路發包的時延（針對特定業務）、調整有效帶寬。
目前有LFI和IPHC兩種鏈路效率機制，下面將分別進行介紹。
2.5.1 鏈路分片與交叉（LFI）
對於低速鏈路，即使爲語音等實時業務報文配置了高優先級隊列（如RTP優先隊列或LLQ），也不能夠保證其時延與抖動，原因在於，接口在發送其他數據報文的瞬間，語音業務報文只能等待，而對於低速接口發送較大的數據報文要花費相當長的時間。採用LFI以後，數據報文（非RTP優先隊列和非LLQ中的報文）在發送前被分片、逐一發送，而此時如果有語音報文到達則被優先發送，從而保證了語音等實時業務的時延與抖動。LFI主要用於低速鏈路。
圖15 LFI工作原理示意
如圖15所示，應用LFI技術，在大報文出隊的時候，可以將其分爲定製長度的小片報文，這就使RTP優先隊列或LLQ中的報文不必等到大報文發完後再得到調度，它等候的時間只是其中小片報文的發送時間，這樣就大大降低低速鏈路因爲發送大報文造成的時延。
2.5.2 IP報文頭壓縮（IPHC）
RTP協議用於在IP網絡上承載語音、視頻等實時多媒體業務。RTP報文包括數據部分和頭部分，RTP的數據部分相對小，而RTP的頭部分較大。12字節的RTP頭，加上20字節的IP頭和8字節的UDP頭，就是40字節的IP/UDP/RTP頭。而RTP典型的負載是20字節到160字節。爲了避免不必要的帶寬消耗，可以使用IPHC特性對報文頭進行壓縮。IPHC可以將IP/UDP/RTP頭從40字節壓縮到2～5字節（不使用校驗和可壓縮到2字節），對於40字節的負載，頭壓縮到5字節，壓縮比爲（40+40）/（40+5），約爲1.78，可見效果是相當可觀的。IPHC可以有效的減少鏈路（尤其是低速鏈路）帶寬的消耗，提高鏈路的利用率。
3 MPLS QoS技術實現
目前，IP網絡僅提供對DiffServ服務模型的支持，但MPLS網絡可以同時提供對DiffServ服務模型和IntServ服務模型的支持：
l MPLS網絡的DiffServ與IP網絡的DiffServ原理相同，不同的是MPLS網絡是通過MPLS報文頭中的EXP值攜帶DiffServ PHB來實現。
l MPLS網絡的IntServ通過MPLS-TE技術實現。
本節將對這兩種MPLS QoS技術進行簡單介紹。
3.1 MPLS DiffServ
DiffServ的基本機制是：在網絡邊緣，根據業務的服務質量要求將該業務映射到一定的業務類別中，利用IP分組中的DS字段（由ToS域而來）唯一的標記該類業務，然後，骨幹網絡中的各節點根據該字段對各種業務採取預先設定的服務策略，保證相應的服務質量。DiffServ的這種對服務質量的分類和標籤機制與MPLS的標籤分配十分相似，事實上，基於MPLS的DiffServ就是通過將DS的分配與MPLS的標籤分配過程結合來實現的。
MPLS DiffServ通過MPLS報文頭中的EXP值攜帶DiffServ PHB實現，標籤交換路由器（LSR）在做出轉發決策時要考慮MPLS EXP值。但是DiffServ PHB最多可以支持64個編碼值，如何承載在只有3bit的EXP字段中？MPLS DiffServ提供兩種解決方案，具體採用哪種方案將取決於具體的應用環境：
l E-LSP路徑，即由EXP位決定PHB的LSP。該方法適用於支持少於8個PHB的網絡，特定的DSCP直接映射爲特定的EXP，標識到特定的PHB。在轉發過程中，LSP決定轉發路徑，但是EXP決定在每一跳LSR上的調度和丟棄優先級，因此同一條LSP可以承載8類不同PHB的流，通過MPLS頭部的EXP域來進行區分。EXP可以直接由運營商配置決定，也可以從報文的DSCP直接映射得到。這種方法不需要信令協議轉的PHB信息，而且標籤使用率較高，狀態易於維護。
l L-LSP路徑，即由標籤和EXP共同決定PHB的LSP。該方法適用於支持任意數量PHB的網絡。在轉發過程中，標籤不僅用於決定轉發路徑而且決定在LSR上的調度行爲，而EXP位則用於決定數據報文的丟棄優先級。由於通過標籤來區分業務流的類型，因此需要爲不同的流建立不同的LSP。這種方法需要使用更多的標籤，保存更多的狀態。
H3C網絡產品提供的MPLS DiffServ技術採用E-LSP解決方案：
l 以EXP值作爲QoS信令，表示MPLS網絡中的業務優先級，EXP值將指示報文在傳輸中所使用的隊列號和丟棄優先級（DiffServ PHB與EXP的映射關係建議如表6所示）。
l 所有的DiffServ功能組件（流量調節器和各類PHB）均爲EXP做了擴展。
表6 DiffServ PHB與EXP的映射關係表
|
DSCP PHB |
EXP優先級 |
|
CS7(111000) |
111 |
|
CS6(110000) |
110 |
|
EF(101110) |
101 |
|
AF4X(100xx0) |
100 |
|
AF3X(011xx0) |
011 |
|
AF2X(010xx0) |
010 |
|
AF1X(001xx0) |
001 |
|
Best Effort |
000 |
圖16 DiffServ PHB與EXP的轉換
如圖16所示，在MPLS網絡的邊緣，缺省情況下，將IP報文的IP優先級直接拷貝到MPLS報文的EXP域；但是在下面的情況下，如ISP不信任用戶網絡，或者ISP定義的差別服務類別不同於用戶網絡，則可以根據一定的分類策略，例如IP報文的IP優先級或DSCP、IP報文的五元組、輸入接口等，在MPLS網絡邊緣重新設置MPLS報文的EXP域，而在MPLS網絡轉發的過程中保持IP報文的ToS域不變。
在MPLS網絡的中間節點，根據MPLS報文的EXP域對報文進行分類，並實現擁塞管理，流量監管或者流量整形等PHB。
3.2 MPLS-TE
MPLS-TE是一種間接改善MPLS網絡QoS的技術。傳統路由協議（如OSPF或IS-IS）主要是保障網絡的連通性和可達性，通常選取不是非常靈敏的參數作爲SPF計算根據，導致網絡負載不均衡、路由動盪等缺陷；MPLS-TE在網絡資源有限的前提下，將網絡流量合理引導，達到實際網絡流量負載與物理網絡資源相匹配，間接改善了網絡的服務質量。
流量工程的性能指標包括兩個方面：
l 面向業務的性能指標：增強業務的QoS性能。例如對分組丟失、時延、吞吐量以及服務等級協定SLA的影響；
l 面向資源的性能指標：優化資源利用。帶寬是一種重要的資源，對帶寬資源進行高效管理是流量工程的一項中心任務。MPLS TE結合了MPLS技術與流量工程，通過建立到達指定路徑的LSP隧道進行資源預留，使網絡流量繞開擁塞節點，達到平衡網絡流量的目的。
MPLS-TE可以爲流建立有帶寬保證的路徑，其具體方法：每條鏈路下都可以配置帶寬（最大物理帶寬、最大可預留帶寬），IGP擴展將泛洪這些信息，生成TEDB；在流量入口建立LSP路徑時，可以指定LSP所需要的帶寬；CSPF進行計算時會計算出滿足帶寬、時延等要求的路徑；最後RSVP-TE根據計算結果建立路徑。通過將TE metric設置爲鏈路時延，從而可以按照VoIP等的時延需求計算可用路徑。
MPLS-TE的鏈路優先級可以用於將某些LSP標記爲比其他LSP更重要，允許其搶佔低優先級LSP的帶寬資源，這樣確保了：（1）在缺少重要LSP的情況下，可以利用低優先級LSP預留資源；（2）重要LSP始終沿最優路徑建立，不受已有預留的影響。MPLS-TE用兩個優先級屬性來決定是否可以進行搶佔：建立優先級和保持優先級，並定義了8個優先級，優先級的範圍是0～7，0最重要。建立優先級用於在建立LSP時控制對資源的接入，而保持優先級用於對已建立LSP的資源訪問。當新建一條路徑Path1時，如果需要與已建立的路徑Path2爭奪資源，只有當Path1的建立優先級高於Path2的保持優先級時，Path1才能搶佔成功。
MPLS-TE的自動帶寬調整特性基於隧道進行流量統計，按照指定頻率在一定範圍內調節隧道的帶寬，可以達到當用戶業務增多時，自動調整分配給這些LSP的帶寬。
4 典型組網方案
4.1 企業VPN QoS實施
ISP可以通過IP網絡向企業提供VPN業務以降低企業的建網費用/租用線費用，對於企業很有吸引力。VPN可以用於連接出差人員與企業總部、異地分支機構與企業總部、企業合作伙伴與企業總部，提供它們之間的信息傳輸。但是如果VPN不能保證企業運營數據的及時有效發送（即提供有效的QoS保證），那麼VPN將仍然不能有效的爲企業服務。例如，往來工作函件數據庫訪問需要受到優先對待，保證這些應用的帶寬要求，而對於與工作無關的E-Mail、WWW訪問等則可以按照Best-Effort信息流對待。
H3C提供的豐富QoS機制完全能夠滿足企業VPN的上述要求：
l 對於不同的業務分別對IP優先級/DSCP進行標記，並且基於IP優先級/DSCP對流量進行分類。
l 通過CBWFQ隊列調度算法，保證企業運營數據的帶寬、時延、時延抖動等QoS性能。
l 通過WRED/尾丟棄機制對於VPN信息區別對待，避免網絡內部流量振盪。
l 通過流量監管機制限制VPN中不同信息流的流量。
在VPN各個站點的CE路由器上對業務流進行分類和着色，例如可以將業務流分爲數據庫訪問、重要工作郵件和WWW訪問三類，並且根據需要利用CAR將這三種業務報文的優先級分別標記爲高、中、低。同時VPN服務提供商還可在每個CE路由器的接入端口設置CAR和GTS功能，分別用於流量監管和流量整形，以此來控制由各VPN站點進入服務提供商網絡的報文流量不會超過承諾的流量上限。LR則可以應用在CE路由器上進行接口總速率限制，裁減和控制CE路由器接入端口的帶寬，保護VPN服務提供商的利益。
在VPN服務提供商網絡的各PE路由器上，缺省情況下，MPLS EXP會拷貝IP報文的優先級。這樣可以在VPN服務提供商網絡的各PE和P路由器，通過配置WFQ、CBWFQ等隊列來控制報文的調度方式，保證在網絡擁塞發生時具有較高優先級的報文能夠優先獲得服務，以達到低時延、低時延抖動等目的，同時可以設置WRED來避免TCP流量的全局同步現象。
另外，如果ISP希望定義與用戶網絡不同的服務級別，或者不信任用戶網絡的IP優先級，也可以採用在PE路由器的入口，根據一定的規則，對MPLS EXP進行重新標記的方式。
4.2 VoIP QoS網絡設計
VoIP QoS的基本要求：丟包率<1%，端到端單程延時<150ms（不同編碼方式要求不同），抖動小於30ms。每路會話的帶寬需求爲21～106Kbps，主要根據採樣速率、壓縮算法、二層封裝等內容決定。
對於VoIP QoS的網絡設計，主要考慮以下幾點：
(1) 合理設計網絡帶寬保證業務傳送需求。
合適的帶寬是保障業務QoS的重要手段。例如一路比較清晰的IP電話需要佔用21～106Kbps範圍內的網絡帶寬，具體帶寬佔用值依據不同的編解碼算法而有所不同。假如一路電話佔用21Kbps帶寬，則不可能在1條64Kbps的鏈路上同時承載4路這樣的IP電話。在網絡建設時，可根據業務模型規劃網絡，合理配備帶寬資源，並根據業務的使用頻度來考慮業務對帶寬的複用。但如果網絡中各種業務都是頻繁業務，則只能採用帶寬疊加的方法。在實際使用線路時，必須綜合考慮運營商網絡帶寬資源的實際情況加以分析。
(2) 選擇合適的語音編解碼技術。
語音壓縮有多種算法，不同的算法所需傳輸帶寬不同。在網絡帶寬充裕的情況下，可採用G.711進行壓縮，其壓縮率很低，基本不影響語音質量，但要求傳輸帶寬很高；在網絡帶寬緊張的情況下，可採用G.729進行壓縮，其對帶寬的佔用率低，但需要以一定的語音失真爲代價（但是在標準規定的範圍內）。
(3) 選擇合適的QoS管理技術。
爲了降低語音報文的傳輸時延，可以將以下技術結合起來：
l 採用LLQ隊列調度算法，使得語音報文進入LLQ，保證語音報文在擁塞發生的情況下被優先調度；也可以採用RTP優先隊列與WFQ結合的方式，如圖17所示。
l 在低速鏈路上採用IPHC報文頭壓縮技術提高鏈路利用率、降低報文時延，如圖18所示。
l 在低速鏈路上採用LFI技術降低語音報文的時延。
圖17 VoIP支持
圖18 IP報文頭壓縮
(4) 合理部署接入層、匯聚層和骨幹層的QoS功能。
l 在接入層網絡進行業務規劃時，可以考慮將不同的業務劃分到不同的VLAN中，比如語音業務終端統一在VLAN 10，視頻業務終端統一在VLAN 20，高速上網業務統一在VLAN 30中。這樣，接入層設備可以根據不同的VLAN號對業務進行排序，優先轉發實時性業務，從而保證QoS。假如接入層設備不支持VLAN劃分，則在網絡規劃時，可以考慮將話音、視頻與高速上網業務分配在不同的網絡中，並在物理層隔離實現，例如可以將不同業務終端的IP地址劃分在不同的網段內。
l 在匯聚層網絡可以通過劃分不同的虛擬專網（VPN）保證語音、視頻業務的帶寬。對於無法劃分虛擬專網的網絡，則可以在接入層和匯聚層之間對業務進行分類，配置語音、視頻業務的優先級高於數據業務，然後在匯聚層按照優先級高低進行數據報文轉發，從而避免大量突發數據業務對語音、視頻業務的影響。
l 在骨幹層網絡將語音、視頻業務統一歸屬到一個VPN中，和數據業務區分開來，從而保證語音、視頻業務的QoS和網絡安全。在同一個VPN內部還可以對業務進行分類，按照優先級高低進行數據報文轉發，也可以結合MPLS技術，綜合全網資源情況，對語音業務提供低時延、有帶寬保證的轉發路徑，保證語音業務的服務質量。
5 參考文獻
l RFC 1349：Type of Service in the Internet Protocol Suite
l RFC 1633：Integrated Services in the Internet Architecture: an Overview
l RFC 2205：Resource Reservation Protocol (RSVP)-Version1 Functional Specification
l RFC 2210：The use of RSVP with IETF Integrated Services
l RFC 2211：Specification of the Controlled-Load Network Element Service
l RFC 2212：Specification of Guaranteed Quality of Service
l RFC 2215：General Characterization Parameters for Integrated Service Network Elements
l RFC 2474：Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
l RFC 2475：An Architecture for Differentiated Services
l RFC 2597：Assured Forwarding PHB Group
l RFC 2598：An Expedited Forwarding PHB (Per-Hop Behavior)
l RFC 2697：A single rate three color marker
l RFC 2698：A two rate three color marker
l RFC 3270：Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
l IEEE 802.1Q-REV/D5.0 Annex G