作業系統
白皮書
摘要
過去數年中，出現了很多提供服務 (QoS) 網路品質的機制。這些機制的最終目的在於提供網路邊緣的應用程式更好的網路「服務」。在本白皮書中，我們簡要討論 QoS 的優勢。然後討論可用的 QoS 機制，以及在它們之間如何相互操作。
1 簡介 在過去數年中，出現很多提供服務 (QoS) 網路品質的機制。這些機制的最終目的在於提供網路邊緣的應用程式更好的網路「服務」。在本白皮書中，我們簡要討論 QoS 的優勢。然後討論可用的 QoS 機制，以及在它們之間如何相互操作。在文件 的第 2 部份，則討論 Microsoft 特有的 QoS 機制，這部分可以單獨參考。
2 QoS 的優勢 近年來，我們目睹電腦網路傳輸的突飛猛進。為了跟上不斷增長的需求，網路管理員已經非常努力地不斷增加容量。但網路用戶端還是經常對網路的性能不滿。隨著新的資源渴求型多媒體應用程式的普及，這種狀況更加惡化。QoS 機制提供一套可供網路管理員使用的工具，能用有效的控制方式來管理網路資源的使用。這樣就可以提供執行關鍵工作的應用程式和使用者更好的服務，同時減緩容量需求的增長速度。換言之，QoS 可協助您在降低服務成本的同時，改善對網路使用者的服務。
2.1 特殊範例以下幾段將說明幾個特殊範例，可以從其中看出 QoS 部署的優勢。
透過 WAN 連結改善關鍵工作應用程式的性能
諸如 SAP 和 PeopleSoft 之類的應用程式，經常用在廣域 Intranet 上，提供關鍵工作服務。這些連結特別容易壅塞，而導致應用程式回應遲緩或工作階段逾時，這種代價可能會很大。QoS 可讓網路管理員將關鍵工作傳輸列為優先項目，使其免於在 WAN 連結上堵塞。這對於較不重要及競爭的應用程式，可用最低成本來完成此工作。QoS 方法就像在繁忙的高速公路上，提供經常往返的車輛專用的通道。關鍵工作傳輸可以導向這些「通道」。
控制多媒體傳輸對網路的影響
諸如 Windows Media™ Technologies、NetMeeting® 會議軟體、RealAudio 和根據 TAPI 3.0 的應用程式之類的多媒體資料流程應用程式，在網路使用者中越來越受歡迎。它們會產生大量的 UDP 傳輸。這種傳輸在網路壅塞時也不會「後退」，從這個意義來說它對網路並不友善。由於這種傳輸對網路資源的潛在影響，因此禁止或限制網路管理員在網路上部署多媒體應用程式。而 QoS 機制讓網路管理員可以控制這些應用程式對網路的影響。
啟用多媒體
在上述範例中，我們討論了使用 QoS 來控制多媒體資料流程應用程式對網路資源的影響，而毋需考慮實際提供給多媒體應用程式的服務。QoS 可用來實際保障特定的資料流程媒體應用程式的特定服務品質。在這種情況下，QoS 實現了多媒體和資料網路的真正收斂。這種收斂的優勢包括可用 IP 電話服務來節省大量成本。
3 QoS 的工作原理 應用程式依變化率來產生傳輸，通常需要網路也依其產生速率來傳送傳輸。此外，各種應用程式或多或少都可容忍網路傳輸延遲及延遲的變化。有些應用程式可以容忍一定的傳輸遺失，有些則不能。如果可用的網路資源是無限的，則所有應用程式都可以依應用程式要求的速度、零反應時間、零封包遺失的方式來傳送傳輸。但網路資源畢竟是有限的。所以，總有一部份網路無法滿足對資源的需求。
網路是透過連接諸如交換機和路由器等網路裝置所建構而成的。網路裝置之間使用介面來轉寄傳輸。如果傳輸到達介面的速度大於介面轉寄傳輸至下一個裝置的速度，就會發生擁塞現象。因此，轉寄傳輸的介面容量成為一項基本的網路資源。QoS 機制的工作原理就是優先分配資源給特定傳輸。
若要如此，首先必須識別不同的傳輸。透過「封包類別」的程序，到達網路裝置的傳輸可分成不同的「資料流」。然後，將每個資料流的傳輸引導至轉寄介面的對應佇列上。每個介面上的佇列都依據一些演算法來接受服務。佇列服務演算法決定各佇列傳輸的轉寄速度，進而決定分配給各佇列及其對應資料流的資源。因此，若要提供網路 QoS，就必須在網路裝置中預備或設定下列各項：
讓裝置將傳輸分成不同資料流的類別資訊。
處理來自不同資料流的傳輸的佇列和佇列服務演算法。
我們將這些一起稱為「傳輸處理機制」。單獨傳輸時，處理機制就沒有用。必須在很多裝置上依一致的方式來預備或設定這些機制，以便透過網路提供有用的端對端服務。因此，若要提供有用的服務，既需要傳輸處理機制，也需要預備和設定機制。
4 QoS 技術 在下列幾節中，將回顧用於提供 QoS 的重要傳輸處理機制及重要預備和設定機制。
4.1 傳輸處理機制有許多傳輸處理機制可供使用。這一節將集中討論幾個重要的機制，包括「混合服務 (diffserv)」、802.1p、「整合服務 (intserv)」、ATM和 ISSLOW。請注意，傳輸處理機制可分成「每一對話機制」或「集合機制」。每一對話機制將每個對話的每個傳輸資料流都分開處理。集合機制則將許多傳輸資料流歸為一個集合類別。這種區別就像是接待飛機乘客。一般而言，乘客可「標示」為頭等艙、商務艙或經濟艙。同一個艙的所有乘客都一起處理。這就是集合處理。每一對話處理就好像為每個乘客提供專用飛機，這是既奢侈又昂貴的。
4.1.1 混合服務 (Diffserv)Diffserv 是一種集合傳輸處理機制，適用於大型路由網路。這種網路可以傳送成千上萬個對話。因此以每一對話為基礎來處理傳輸是不切實際的。Diffserv 定義封包 IP 標頭中稱為 diffserv 碼點 (DSCP)1 的欄位。將傳輸傳送至 diffserv 網路的主機或路由器，使用 DSCP 值來標示每個傳送的封包。Diffserv 網路內的路由器使用 DSCP 將封包分類，並根據分類結果來套用特定的佇列行為。具有相似 QoS 要求的許多資料流傳輸可標示相同的 DSCP，即可讓資料流具有公用佇列或排程行為。
4.1.2 802.1p802.1p 是適合區域網路 (LAN) 使用的集合傳輸處理機制。
它在乙太網路封包的媒體存取 (MAC) 標頭中定義一個欄位，此欄位可為八個優先順序中的一個值。傳送傳輸至 LAN 的主機或路由器將以適當的優先順序值來標示傳送的每個封包。LAN 裝置 (例如交換機、橋接器和網路集線器) 將根據這個值來處理封包。802.1p 優先順序標示的範圍只限於 LAN。
4.1.3 整合服務 (Intserv)Intserv 是定義服務的框架。同理，其中隱含一套基礎傳輸處理機制。一般而言，Intserv 服務是基於每一對話原則來使用。Intserv 通常與 RSVP 訊號通訊協定 (在稍後的預備和設定機制中討論) 有關，但這並非必要。
4.1.4 ATM、ISSLOW 及其它ATM 是一種連結層技術，可提供高品質的傳輸處理。ATM 將封包分解成連結層「單元」，然後使用適合於 ATM 服務之一的佇列服務演算法，將這些單元列入佇列並提供服務。
ISSLOW 是一種在封包透過相對低速連結 (例如撥號數據機) 來傳輸時，用來分解 IP 封包的技術。當音效和資料透過這些連結混合在一起時，音效的潛伏期可能很重要，它會影響應用程式的可用性。ISSLOW 可用來降低這些應用程式的音效潛伏期。
另外還有為各種媒體定義的其它傳輸處理機制，其中包括纜線數據機、混合光纖同軸電纜 (HFC) 裝置、P1394 等等。它們可以使用低層的連結層專用的訊號傳輸機制ATM，例如使用 UNI 訊號傳輸。
4.2 預備和設定機制若要有效提供網路 QoS，就必須在多個網路裝置上讓傳輸處理機制的預備和設定生效。預備和設定機制可分為「自上而下」或「訊號傳輸」兩類。
4.2.1 自上而下預備在「自上而下」預備中，網路管理系統可將傳輸處理組態「推送」到一組網路裝置。一般而言，佇列機制可設定在裝置介面上。然後設定類別標準以決定哪些封包要導向裝置中的不同佇列。分類標準可以根據 IP 5-tuple (來源和目的 IP 位址和連接埠和 IP 通訊協定) 或封包標頭的 DSCP 和 802.1p 集合「遮罩」將封包分類。也許還可以使用遮罩的 5-tuple。分類標準可以只指定 IP 5-tuple 的一個子集，例如，「所有具有來源 IP 位址為 2.2.2.X 的封包」，其中 X 可為任何值。如果指定 DSCP 或 802.1p 為分類標準，就必須在分類裝置上游某處的封包中「標示」DSCP 或 802.1p。此工作可由網路邊緣附近的主機或網路裝置來完成。對於後一種情況，負責標示的網路裝置會設定成根據自己的分類標準來標示，通常是 5-tuple (或其子集)。
4.2.1.1 自上而下預備中的挑戰決定要用的適當分類標準相當具有挑戰性。網路管理員可能喜歡使用 QoS 指派資源給特定的應用程式或使用者的傳輸，而不是使用封包標頭中的欄位，例如 IP 位址和連接埠。「自上而下」 預備系統會嘗試藉由在應用程式和 IP 連接埠之間、使用者和 IP 位址之間建立連結，以提供網路管理員必要的協助。但不幸的是，它們經常不可靠。應用程式可能會使用暫時的連接埠，或使多個傳輸資料流 (需要不同的 QoS) 源自同一個連接埠。DHCP 可能會導致使用者的 IP 位址變更。多重使用者機器可能讓多位使用者使用相同的 IP 位址。IPSec 加密可以加密連接埠，讓它們無法作為分類標準。
「自上而下」預備的另一個挑戰是網路中各節點的傳輸量。例如，管理系統可能在每個網路裝置都設定低潛伏期佇列，其容量可同時處理具有特定潛伏期的 10 個 IP 電話服務工作階段。然後在各裝置上設定分類標準，將 IP 電話服務傳輸導向低潛伏期佇列。只要電話服務傳輸到達各裝置，這項工作就僅限於 10 個工作階段。但如果建立第 11 個電話服務工作階段，此工作階段會跨越裝置之一，就會使潛伏期超越設定的範圍。結果此服務不僅會危及第 11 個工作階段，還會危及 10 個現有的工作階段。這是由於「自上而下」預備的相對靜態性質，以及管理系統不直接瞭解目前傳輸模式的事實。
4.2.2 RSVP 訊號傳輸設定機制RSVP 訊號傳輸可作為「自上而下」預備機制的補充。在這種情況下，主機產生訊號傳輸訊息，其中說明關於特定對話的資料傳輸。這些訊息沿著與資料傳輸相同的路徑在網路中流動。RSVP 訊息提供下列資訊給網路：
我是什麼？來源應用程式和子資料流 (例如列印資料流對時間關鍵型異動)。
我是誰？身份驗證的使用者 ID。
我要什麼？QoS 服務所需的類型。
我需要多少？特定應用程式將其資源需求量化。
怎樣識我的身份？識別資料傳輸的 5-tuple 的分類標準。
哪些網路裝置資源會受到相關資料傳輸的影響。
這種主機訊號傳輸可為 QoS 管理系統帶來很大的好處。主機訊號傳輸的明顯好處，是可在類別資訊與使用者和應用程式之間提供強健的連結。此外，主機訊號傳輸還提供「拓樸認知動態許可控制」。這個功能是解決上述「第 11 個電話服務工作階段」問題的關鍵。RSVP 訊號傳輸會傳送相關的必要資源的訊息給資料路徑沿途的裝置。因此，支援 RSVP 裝置能夠動態評估資料傳輸對資源的影響，並通知上游裝置何時會缺少處理額外傳輸資料流的資源。在「第 11 個電話服務工作階段」的情況下，網路裝置會拒絕第 11 個傳輸資料流進入低潛伏期佇列，以保護現有的 10 個工作階段。很重要的是要注意主機訊號傳輸無法與網路管理員對網路資源的控制相抗衡。它只提供有助於網路資源管理的資訊。
5 品質保證和品質/效率乘積 電話服務傳輸的特點是需要「高品質保證」。這種需要可以量化，其價值取決於這些要求是否絕對滿足。多媒體應用程式通常會需要高品質保證。但並非所有應用程式都需要高品質保證。例如，用戶端/伺服器資料庫異動不能精確量化其資源需求，同理也不會期望得到量化的保證。這些應用程式可受益於承諾減少潛伏期但不提供絕對潛伏期範圍的較低品質保證。
提供高品質保證的方法之一是讓網路有明顯的超額準備。例如，IP 電話服務範例中所述的網路裝置如果預備支援所有潛在的 IP 電話服務工作階段，就可以避免「第 11 個電話服務工作階段」問題。但如果有 1,000 個潛在的工作階段，而平均同一時間只有 10 個工作階段，則可能有必要依 100 倍係數來超額預備網路裝置，以支援高品質保證。這明顯是對網路資源的低效率利用。總之，在網路提供高質保證的能力和網路資源的利用效率之間，總是此消彼長。網路可用常數「品質/效率乘積 (QE 乘積)」來衡量。提供更高的品質保證需要在效率上有所讓步，反之亦然。
提供高品質保證的另一種機制是使用前面所說的 RSVP 訊號傳輸。使用 RSVP 訊號傳輸可以依平均期望負載來預備網路裝置。如果偶爾有負載超出期望值的情況，將會拒絕額外的工作階段，但對現有的工作階段的保證仍能保持完整。藉由使用 RSVP 訊號傳輸，可以有效地提高網路的 QE 乘積，同時提供更高品質保證，以及網路資源更高效率的使用。總之，QoS 機制越複雜，就越能提高指定網路的 QE 乘積。似乎所有網路裝置都應實現可用的最複雜 QoS 機制。但 QoS 機制本身的管理會導致增加管理費用。對訊號傳輸而言，這個管理費用以網路裝置中處理資源的形式表現。這會讓我們得到很重要的一點：「任何 QoS 機制都要在 QE 乘積提高方面的利益與導致管理費用增加之間進行評估」。
下表以實際的 QoS 機制來闡述這個概念：
其中資料列代表遞增的傳輸處理機制的複雜等級。資料行代表遞增的預備和設定機制的複雜等級。請注意左上方的儲存格，它不代表任何 QoS 機制，只提供非常低的 QE 乘積。這種網路的範例如超額預備的 LAN。另一個在右下方儲存格的極端狀況，代表網路的每個網路元件都處理每一對話 RSVP 訊號傳輸，並套用每一對話 intserv 傳輸處理。中間儲存格代表提高 QE 乘積和降低管理費用之間的折衷。代表每一對話許可控制與集合傳輸處理相結合的儲存格，特別值得注意。
下圖說明這種組合：
圖形的最左邊說明了正在傳送的主機。主機傳送到大型路由網路中，目的地是最右邊的接收主機。在路由網路中穿過幾個路由器。這些構成了傳輸處理的集合型式 (例如 diffserv)。路由網路入口處的路由器，將指定為「許可控制代理程式」。它處理來自傳送主機的每一對話 RSVP 訊號傳輸訊息，並決定是否允許主機對話的訊號傳輸進入路由網路的高優先權集合傳輸處理佇列中。
請注意，雖然訊號傳輸訊息端到端地穿過網路，但它們只在主機和指定為路由網路許可控制代理程式的路由器上處理，如箭頭所示。路由網路核心處的路由器套用集合傳輸處理，而不處理訊號傳輸訊息。這種網路邊緣使用的每一對話訊號傳輸與核心集合傳輸處理的模型，在 QE 乘積和 QoS 相關管理費用之間獲得良好的折衷。它可擴展到任意複雜的網路拓樸。總之，透過啟用更高密度的網路許可控制代理程式，在管理費用增加時可以提高 QE 乘積。我們希望 ISP 使用類似的方法，提供 QoS 服務的 VPN。
5.1 同時使用訊號傳輸和自上而下預備真正的網路需要支援各種不同品質保證需求的應用程式。若要可供終端客戶使用，從網路的一端到另一端，這些保證都要有效。網路的一部份將會資源緊張，因此需要有效地預備。而其它部份卻可能超額預備。若要獲得對高、中品質保證的最佳支援，必須在網路的不同部份都可使用訊號傳輸訊息。若要如此，主機將產生針對一系列應用程式的訊號，其中包括多媒體應用程式和關鍵工作的應用程式。然後，網路管理員可以根據前面討論的折衷策略，在網路上適當點指定許可控制代理程式。
訊號傳輸對某些應用程式沒有什麼作用。特別是對於工作階段導向和不產生持續傳輸資料流的應用程式而言，訊號傳輸將導致相關管理費用增加，這並不合算。這些應用程式的資源必須依自上而下方式來預備。因此，隨著 QoS 機制的部署，我們將看到訊號傳輸預備和自上而下預備的結合。由於兩個機制在同一個網路中分配資源，它們必須以某種方式來協調。這個協調點就是策略伺服器。
6 策略和策略伺服器 工業標準 QoS 策略模型定義了策略執行點 (PEP) 和策略決定點 (PDP)。PEP 包括路由器、交換機和其它可以作為許可控制代理程式的裝置。一般而言，PEP 可搭配 PDP 使用，以套用網路管理員的 QoS 策略。PDP 提供了處理抽象策略所需的更高層次的智慧。PDP 檢查到達不同 PEP 的 RSVP 訊號傳輸訊息，並決定相對的傳輸是否可以獲准進入。PDP 還使用自上而下預備將非訊號傳輸傳輸資料流「推送」至 PEP 組態資訊。PDP 通常依賴策略資料儲存區。這個資料儲存區可以採取分散式目錄的型式。
7 摘要 QoS 機制在啟用網路管理員來有效管理網路資源時，可以改善網路使用者的服務。 這些機制包括傳輸處理機制及預備和設定機制。傳輸處理機制包括佇列演算法和封包類別。它們可以套用於傳輸的集合或每一對話傳輸資料流。預備和設定機制可以是自上而下或主機訊號傳輸。自上而下預備中具有傳輸類別的挑戰，通常無法同時提供高品質保證和網路資源的有效利用 (高品質/效率乘積)。主機的訊號傳輸提供給網路的資訊，明顯地促進網路資源和特定使用者及應用程式的結合，可以讓網路管理員體會到 QE 乘積已適當提高。在方興未艾的 QoS 網路中，我們可以期待看到訊號傳輸和自上而下預備機制的結合。策略決定點提供這些 QoS 機制統一的管理。
