本文檔狀況
本篇文檔具體說明為互聯網社團制定的互聯網標準跟蹤協議，希望得到討論和改進建議。假如想了解這個協議標準化的聲明和狀況，請參考最新版本的“互聯網官方協議標準”(STD1)。本文檔的分發不受限制。
版權聲明
版權屬于(C)the Internet Society(1999)。版權所有。
摘要
在區分服務工作組的工作中PHBs（每一跳轉發行為）是要害部分。本文檔定義了稱為快速轉發的每一跳行為（PHB）。通過指出這種PHB可以被一種以上的機制實現，并給出它至少可以產生的一種服務，虛擬租用鏈路服務的用例，我們展示了該PHB的一般特性。本文給出了這種PHB的推薦編碼點。
本文檔的pdf版本從以下站點可以得到：
FTP://ftp.ee.lbl.gov/papers/ef_phb.pdf
1．介紹
實現增強ip的區分服務的網絡節點利用IP頭中的一個編碼點來選擇一個PHB作為對該包的特定轉發處理 [RFC2474,RFC2475]。本文檔說明一個特定的稱為快速轉發的PHB。快速轉發PHB可以用來在區分服務域中建立一個低丟失，低時延，低抖動，保證帶寬，端到端的服務。這種服務對于終端就象一個點到點連接或者“虛擬租用鏈路”。這種服務也被描述為特級服務(PRemium service)[2BIT]。
丟失率，時延和抖動都是排隊流量穿越網絡時的經歷。因此為流量聚集提供低丟失率，低延時和低抖動意味著保證聚集不經歷或者很少經歷排隊。當（短期）流量到達某些節點的速率超過它離開時候的速率，就會出現排隊。因此一個保證某些聚集不用排隊的服務等價于限制速率，這樣在每一個通過的節點，聚集的最大到達速率比聚集的最小離開速率小。
建立一個這樣的服務需要兩部分：
1）配置節點使聚集具有一個明確定義的最小離開速率。（“明確定義”意味著不依靠于節點的動態狀態，尤其是不依靠其它流量在此節點的強度）
2) 調整聚集（通過策略和整形）使它在任何節點的到達速率總是小于這個節點配置的最小離開速率。
保證轉發PHB提供第一部分服務。在[RFC2475]中定義的網絡邊界鏈路調節器提供第二部分服務。
保證轉發PHB不是區分服務體系結構的必需部分。即，一個想成為區分服務兼容的節點不需要實現保證轉發PHB。然而，當一個區分服務兼容節點聲明要實現保證轉發PHB，它的實現必須符合本文檔中的規定。
下一節具體描述保證轉發PHB，并給出它可能被實現的例子。要害字“必須”，“禁止” ，“需要”，“應該”，“不應該”，“可以”在[Bradner97]中有解釋.
2．快速轉發每一跳行為說明
快速轉發PHB被定義為對一個特定的區分聚集的轉發行為，這些聚集的包離開任何區分節點的速率必須等于或者超過配置速率。快速轉發流量獲得的速率應該是獨立于任何其他企圖穿越該節點的流量的強度。在等于或者超過以配置速率發送一個輸出連接大小為MTU（最大傳輸單元）包所需時間的任何時間間隔內測量的時候，它應該達到至少是配置速率的平均水平。（小于以配置速率發送一個包的時間刻度內的行為在這里沒有說明）。配置的最小速率對于網絡治理員必須是可設置的（使用該節點支持非易變結構的任何機制）。
假如快速轉發PHB被答應用無限制的搶先占有（preemption）其他流量（例如，一個優先隊列）的機制實現，該實現必須包含一些方法限制快速轉發流量可能給其他流量造成的損失（例如，一個令牌桶速率限制器）。超過限制的流量必須被拋棄。最大快速轉發速率和合適的突發數，對于網絡治理員必須是可以設置的（使用該節點支持非易變結構的任何機制）。最小和最大速率可能相同且只需設置一個參數。
附錄中描述如何用該PHB來構造端到端服務。
2.2實現快速轉發PHB的示例機制
可以使用一些隊列調度機制提供2.1節描述的轉發行為，以此實現快速轉發PHB。只要其他高優先級隊列搶先占有快速轉發的時間沒有超過以配置速率發送一個包的時間，一個簡單的優先級隊列可以給出合適的行為。（通過一個速率策略器（policer），例如用令牌桶和每一個優先級隊列關聯來限制隊列可以餓死其他流量的程度）
在一個加權循環調度器服務的隊列組中使用單一隊列也是可能的，該調度器分配給快速轉發隊列的輸出帶寬的份額等于配置速率。例如，可以用一個PHBs的類選擇兼容集中的一個PHB實現[RFC2474]。
另外一種可能的實現是CBQ調度器，它給快速轉發隊列的優先級可以達到配置速率。
雖然不同的選擇結果導致不同的輔助行為，如對單獨的微流可見的抖動，所有這些機制都具有快速轉發PHB需要的基本屬性。參看附錄A.3仿真量化其中的一些差別。
2.3快速轉發PHB的推薦編碼點
快速轉發PHB的推薦編碼點是101110。
2.4多變性
有快速轉發PHB標記的包可能在區分服務域邊界被重新標記為滿足快速轉發PHB的其他編碼點。有快速轉發PHBs標記的包不應該被一個區分服務域降級或者升級為其他PHB。
2.5隧道
當一個快速轉發包進入隧道時，隧道包必須被標記為快速轉發。
2.6與其他PHB的互操作
只要滿足2.1的條件，在具有快速轉發PHB的同一個區分服務節點或者域內可以配置其他PHBs和PHB組。
3．需要考慮的安全因素
為保護自身不受拒絕服務攻擊，區分服務域邊界必須嚴格監控所有標記為快速轉發的包的速率不超過和鄰接上游域協商的值。（這個速率必須<=快速轉發PHB配置速率）。超過協商速率的包必須被丟棄。假如兩個鄰接域沒有協商快速轉發速率，下游域必須使用0作為速率（即，丟棄所有有快速轉發標記的包）。
既然從快速轉發PHB建立的端到端特級服務需要上游域對有快速轉發標記的流量進行監控和整形以滿足和下游域協商的速率，下游域監控器永遠不需要丟棄包。因此應該注重丟包可能是由于違反安全或者有嚴重的誤配置造成的（例如，借助簡單網絡治理協議（SNMP）來捕捉（traps））。類似的，既然聚集快速轉發流量速率是在每一個內部節點被建立的，快速轉發隊列就不應該發生溢出，所以假如有溢出，應該注重丟包可能是由于攻擊或者嚴重的誤配置造成的。
4．IANA考慮
本文檔在[RFC2474]中定義的編碼空間的一號池中分配一個編碼點，101110。
5．參考文獻
[Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2474]Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, December 1998.
[RFC2475]Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998.
[2BIT]K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[CBQ]S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.
[RFC2415]Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC2415, September 1998.
[LCN]K. Nichols, "Improving Network Simulation with Feedback", Proceedings of LCN '98, October 1998.
6．作者聯系地址
Van Jacobson
Cisco Systems, Inc
170 W. Tasman Drive
San Jose, CA 95134-1706
EMail: van@cisco.com

Kathleen Nichols
Cisco Systems, Inc
170 W. Tasman Drive
San Jose, CA 95134-1706
EMail: kmn@cisco.com

Kedarnath Poduri
Bay Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
EMail: kpoduri@baynetworks.com
附錄A：快速轉發PHB的使用示例和經驗
A.1 虛擬租用鏈路服務
一個已知的特級服務[2BIT]虛擬租用鏈路（VLL）服務，用峰值帶寬量化。
A.2 在能源科學網（ESNET）中的使用經驗
VLL服務原型在能源部[美]（DOE）的能源科學網（ESNet）的骨干網中配置。使用Cisco75xx系列路由器的加權循環隊列特性實現快速轉發PHB。早期測試非常成功，正在開展使該服務在常規生產基礎上有效的工作。（詳情參看 ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf 和
ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf）
A.3 仿真結果
A.3.1 抖動變化
在2.2節，我們指出有許多機制可以用來實現快速轉發PHB。最簡單的是優先級隊列（PQ）,該隊列的到達速率嚴格小于它的服務速率。因為抖動是由通路上的排隊時延產生的，該實現的特性是按預定速率轉發具有快速轉發標記的微流將經歷非常小的抖動，這是由于包在隊列中的時間很短。快速轉發PHB沒有明確的時延要求，但定義中很明確，使用基于快速轉發PHB服務的包流利用優先級隊列比盡力而為轉發的期望抖動值要小。我們使用仿真研究和比較加權循環和優先級隊列的抖動值。既然它們的抖動值分別是最好和最壞的情況，我們選擇這兩個，而且我們想為選擇加權循環或者類似機制的快速轉發實施者提供大致的指導方針。
我們的仿真模型在一個改進的[RFC2415]和[LCN]中描述的ns-2中實現。我們使用包含ns-2的CBQ（類基隊列）模型作為實現優先級隊列和加權平均隊列的基礎。我們的拓撲結構包含在單一的1.5Mbps瓶頸鏈路方向上帶寬遞減的6段（看圖6）。源端以等于預定包速率的平均比特速率產生具有快速轉發標記的包。以預定包速率產生的包和包內間隔（interpacket spacing）具有+-10%的偏差。每個源速率被選擇聚集達到瓶頸鏈路或者450 Kbps的30％。FTPs和HTTPs的混合物用來填充該鏈路。每一個快速轉發包的源端或者全部產生160字節的包或者全部產生1500字節的包。雖然我們用一個包大小展示統計信息，所有的實驗都使用長短包混合的快速轉發源端，因此快速轉發隊列具有兩種包長度。
我們將抖動定義為兩個臨接包到達時間減去離開時間的絕對差值(aj-dj) - (ai-di)。對于每個實驗的目的流，我們將中間和第90％的抖動值記錄在表中（表示為預定快速轉發速率的％）。本文檔的Pdf版本包含抖動百分點的圖。
我們的實驗比較了加權循環和優先級隊列實現的快速轉發PHB的抖動值。我們評價了不同加權循環隊列的權值和隊列數量對于抖動的影響。對于加權循環，我們定義服務/到達速率的比值為快速轉發隊列的服務比率（或者是該隊列在輸出鏈路中的最小份額）乘以輸出鏈路帶寬除以隊列中有快速轉發標記包的峰值到達速率。假如加權循環隊列權值的選擇是嚴格的平衡了到達和離開速率，結果將是不穩定的，因此我們使用一個最小的服務/到達速率比值1.03。在我們的仿真中，這意味著快速轉發隊列得到至少31％的輸出鏈路。如上述，我們在加權循環仿真中用其他流量填滿鏈路，將無快速轉發標記的流量分裂到非快速轉發隊列中。（從實驗的描述中，應該很清楚我們企圖產生最壞的抖動情況，不希望這些設置或者流量重現一個“正常”的運行點）。
我們的第一個實驗集使用最小的服務/到達比值1.06，我們將每一個組成快速轉發聚集的微流的數量從2變到36。我們將這些和一個用24個流實現的優先級隊列相比較。首先，我們檢查一個以預定速率56Kbps發送包大小為1500字節的微流，然后是同樣速率但包大小為160字節的流。表1所示以預定速率發送一個包的時間的第50和第90個百分點的抖動。圖1描劃了包大小為1500字節的流，圖2描劃了包大小為160字節的流。注重以56Kbps發送一個大小為1500字節的包的時間是214ms，對于160字節大小的包是23ms。盡管大部分小包的抖動至少是一個預定速率的包時間，大包的抖動很少超過一個預定速率包時間的一半。記住所有情況下，快速轉發聚集的是一個大包和小包的混合，因此短包可能在快速轉發隊列中等待長包。優先級隊列給出了一個很小的抖動。
表1：多個快速轉發流抖動變化：服務/到達速率的比值是1.06，預定的速率是56Kbps（所有的值都是以預定速率％的形式給出）
1500字節的包 160字節的包
＃快速轉發流 50th % 90th % 50th % 90th %
PQ (24) 1 5 17 43
2 11 47 96 513
4 12 35 100 278
8 10 25 96 126
24 18 47 96 143
下一步我們看看增加服務/到達的比值的影響。這意味著快速轉發包應該保持更短的入對時間，盡管對其他隊列的有效帶寬保持不變。在這個實驗集中，快速轉發聚集流的數量固定為8，總的隊列數量為5（4個非快速轉發隊列）。表2所示為1500和160字節流的結果。圖3描劃1500字節的結果，圖4是160字節的結果。當服務/到達的比值為1.5時性能增加達到穩定。注重更高的服務/到達的比值不能象對優先級隊列那些提供同樣的性能，但是現在90％的包經歷的抖動小于一個預定速率包時間，即使對于小包。
表2：快速轉發流抖動變化：服務/到達的比值變化，8個流聚集，預定的速率是56Kbps
加權循環隊列 1500字節的包 160字節的包
服務/到達 50th % 90th % 50th % 90th %
PQ 1 3 17 43
1.03 14 27 100 178
1.30 7 21 65 113
1.50 5 13 57 104
1.70 5 13 57 100
2.00 5 13 57 104
3.00 5 13 57 100
增加輸出端口隊列的數量可以導致在對快速轉發包的服務時間內的可變性，因此我們實現一個改變每個輸出端口隊列數量的實驗。我們將聚集流的數量固定為8，使用最小的服務/到達的比值1.03。結果如圖5和表3所示。圖5包含以8個流為底線的優先級隊列。
表3：輸出端口具有多個隊列的抖動變化：服務/到達速率的比值是1.03，8個流聚集
＃快速轉發流 1500字節的包
流 50th % 90th %
PQ (8) 1 3
2 7 21
4 7 21
6 8 22
8 10 23
看起來大多數加權循環的抖動都很低，而且考慮預定速率，選取合適的快速轉發隊列中加權循環在輸出鏈路的份額，還可以減小抖動。如已經指出的，當優先級隊列是最好的情況時，加權循環是最壞的情況。其他快速轉發隊列可能包含固定速率限制的加權循環或者類基隊列，但是給它的優先級高于其他隊列。我們期待后者的性能和優先級隊列近似相同，盡管未來的仿真需要證實這一點。我們還沒有系統的研究跳數，快速轉發分配除這30％以外的帶寬，或者更復雜的拓撲的影響。本節的信息不是快速轉發PHB定義的一部分，但是簡單的提供指導實現的背景。
A.3.2 虛擬租用鏈路服務
我們使用仿真來看看利用快速轉發PHB建立的VLL服務是如何運轉的，也就是看看它是否象一條具有預定速率的“租用鏈路”。在最后部分的仿真中，網絡中沒有一個快速轉發包被丟棄，同時對于這些固定比特率（CBR）源也能達到目標速率。然而，我們想看看VLL是否真的象一條到達使用它的TCP的“線路”。因此我們使用VLL服務仿真一個長生存器的FTPs。表4給出每一次仿真中分配給快速轉發流量的鏈路百分比（鏈路上的快速轉發微流少的，帶寬也小），預定的VLL速率，按照預定速率和VLL流平均速率用全雙工專用鏈路連接的同類型的發送者－接受者對的平均速率（所有的發送者－接收者對具有同樣的值）。只有當輸入整形緩存而不是網絡有溢出的時候才出現丟失。由于已知的TCP行為，目標速率是不能達到的。
表4：使用VLL服務的FTP性能
％連接到 平均發送速率（kbps）
快速轉發 預定的 專用的 VLL
20 100 90 90
40 150 143 143
60 225 213 215
完整版權聲明
Copyright (C) The Internet Society (1999). 版權所有.
本文檔及其譯文可以復制并對外提供。可以部分或全部編著、復制、出版、分發與其有關的評議、解釋和有助于實施的派生著作，沒有任何限制，但要求在復制文件和派生著作中包括上述版權警告及本節版權聲明內容。但是，本文件的內容不答應做任何形式的修改，諸如刪除版權警告或者關于互聯網社團或者其他互聯網組織的介紹，除非為了開發互聯網標準或翻譯成英語以外的其他語言的需要，即使在這種情況下，也仍然必須遵循互聯網標準過程中確定的版權程序。
上述許可是永久性的，不會由互聯網社團，它的繼續者或轉讓者予以廢除。
本文件及其提供的信息以“現狀”為基礎，互聯網社團與IETF(因特網工程任務小組)否認所有的保證實示或暗示，包含但并不限于任何保證。所含信息的使用將不會侵犯具有非凡目的的商用性或者適用性的任何權利或隱含的保證。
致謝
RFC編者活動基金現在由互聯網社團提供。