2007年B. A. Movsichpff、C. M. Lagoa以及H. Che等人，再度發表一份有關QoS、流量工程（traffic engineering；TE）以及錯誤修復（failure recovery；FR）的整合文章。距離2004年上次報告已有一段時日，QoS的發展現況因此值得關注。一方面是因為QNS（QoS network service）問題在IP網路上的解決標準遲未定案；其次由於IP網路所肩負的商業需求日漸重要。本文中我們將回顧目前網路上各標準主體對於此問題的看法，並深入分析ITU-T所提議的RACF一般化QoS架構。

網路服務品質保證的必要性

家庭化網路應用日益頻繁，未來網路將和電視一樣普及。在下一世代以網路（NGN）為基礎的IP網路架構服務中，QoS（quality of service）便成為一項重要的關鍵技術。因為IP網路不像電路交換式網路（circuit-based network）一樣，本身有一定品質保證機制。對IP網路而言，截至目前為止QoS的保證仍處在百家爭鳴階段，尚未有一個統一的端點式QoS標準出現。一個傳統的QoS概念包含三個主要成員，分別是網路節點的QoS、網路策略／管理部分與QoS訊號，如(圖一)所示。

《圖一　傳統的QoS概念示意圖》

NGN QoS的複雜因素

不過NGN的QoS問題不只涉及此三部分，NGN的QoS問題之所以複雜，乃因其QoS控制機制會受到許多因素的影響。例如NGN網路的應用程式所需效能通常不一致，加上IP網路當時的設計，並不涵蓋應用程式效能的概念，各種應用程式所適用的QoS機制不盡相同；端點對端點之間的路徑通常會因為端點所需要的不同QoS需求而變；傳送技術對QoS型態的支援差異以及不同網路營運商的營運自主性等因素。

IP網路標準發展始料未及

換句話說，端點式QoS標準的建立並未確定，IP網路的發展超乎當時的想像，IP網路本身並不提供端點式（end-to-end）的QoS品質保證機制，目前IP網路應用壓力也越來越大。在這些應用裡，許多方面是當時設計始料未及的，例如：IP語音服務、IP影像應用，IP多媒體服務、甚至是IP網路上的互動遊戲（interactive game）等等。使用者若要能享受更好的服務品質，必須藉由其他額外機制輔助。

規劃網路架構與回饋機制

於是，許多系統或網路服務供應商，便集中資源研究取得更多網路頻寬的可用性，包含如何在一定品質下，減少使用頻寬、或是如何讓網路頻寬變得更大，尤其是在Internet架構下，如何能取得更多頻寬上的使用效益。

這種Internet網路架構包含封包式的即時流量與非即時流量，當網路傳遞有多種路徑可供選擇、並且網路上存有多個不同類別等級（classes of service；CoS）可供使用時，最佳化資料傳輸率與載入平衡法是最常被用來調整網路品質的手段之一。但是不同的調整方法往往需要不同的網路狀態資訊回饋機制，來感知目前網路遞送路徑是否符合可用的QoS最低要求。

為使這些回饋資訊可常被系統使用，故網路資源也必須要規劃保留一定頻寬，使得真正可用的頻寬又顯得更少。因為各種網路應用型態具有本身上的差異，因此需要的品質要求也各不相同。為了解所需要的品質狀態，設計人員需要藉助相關評估方法，一般IP網路上的客觀品質評估模型可參考(表一)所示。

使用來源端控管QoS品質

Movsichpff等人所提議的新方法，主要目的還是在解決之前所存在的問題，新方法引人矚目，在於其只需要使用來源端的推理資訊、亦即考慮該傳遞路徑目前是否擁塞，便可進行必要的QoS品質控管程序，可完成網路資源的最佳化使用，並利用發展資料傳輸率適應法則（data rate adaptation）來最大化可用資源。因為以最少資訊的方式掌控網路服務品質實屬不易，目前所有方法仍存有網路之間通透性的問題。

IntServ與DiffServ架構

我們必須要瞭解有關保證網路品質的主要方法。一種使用的是整合服務（integrated services；IntServ）概念，另一種是差異性服務（differentiated services；DiffServ）概念。前者架構中的節點（nodes）需要取得一個流量狀態（flow state），以調整服務所需的使用頻寬；後者則不需要取得流量狀態資訊，但是利用類別標記（class tag）方式，將相同流量特徵歸為一類，再由每個節點對不同的流量類型提供差異性服務，所以此方式可被用在大規模的網路架構中。相關IntServ與DiffServ的運作如(圖二)所示。

《圖二　IntServ與DiffServ運作架構示意圖》

表面上看來，Internet可用DiffServ的概念來提供QoS服務，但事實上卻非如此。因為DiffServ的應用必須要在網路流量處在不過載（under load）的條件下才能正確運作。然而實際上，Internet網路環境常有過載（overload）情形發生，且過載情形也導致一些封包被丟棄。

因此要在Internet上應用DiffServ概念，運作狀況不一定較好，這點在A. Charny及J. Y. Le Boude的研究中亦有相同發現，亦即當網路流量不過載時，DiffServ才能保證最大延遲限制。另外由I. Stoira及H. Zhang的報告看來，要能做到服務的保證，實作上相當複雜。為克服此問題，研究者提出許多在DiffServ架構下有關點對點服務品質的方法，許多均認為流量的控制有其必要，因為下一代網路型態乃以目前Internet網路架構為主。若使用特殊協定的網路例如多協定標記切換網路MPLS）雖無問題，不過一般封包式的IP網路上便會有問題，因為這些網路當時在設計之初並未考量之，因此解決方案迫在眉睫。

目前的QoS架構機制

概述

QoS的控制程序有多種實作方法，為達到較好的通透性，QoS控制機制必須被定義於相同的基礎架構之上，現行許多QoS機制則建立於特殊傳送技術或控制方法。為解決此問題，架構下一代NGN網路有許多標準制訂主體參與，例如：ITU-T、ETSI、3GPP、IETF以及IEEE等等。有關IP網路的QoS架構討論，遠在2000年時IETF便已制訂RFC 2990予以規範，但其架構只是提供給相關網路工作群組的一個參考，並非是真正網路上的標準架構。直到近幾年，因新應用型態的需要，QoS的議題才又逐漸獲得重視。但因為各家對於NGN的看法多有出入，因此許多標準制訂主體多在自己所認可之NGN架構下，發展QoS的控制架構。

各家定義雖略有差異，一般而言NGN需具備封包式網路、寬頻以及QoS感知的傳送技術、服務功能與傳送方式的獨立性、享有自由存取網路（unfettered access to networks）及相關服務、或提供擇一性與一般化的行動力（generalized mobility），以及隨意服務等屬性。

在參與下一代網路QoS標準制訂上，主體通常有著不同的角色分配，例如ITU-T與ETSI便是制訂網路架構與開發控制程序；另外IETF與IEEE則致力於網路第二層（layer 2）與第三層（layer 3）內特異問題的核心解決方案。QoS的問題雖然廣泛，但整合策略應該會比全新建立一個標準容易。這些標準多屬針對特定問題的解決方案，因此當ITU-T的一般化QoS架構完成後，將可涵蓋其他標準主體所制訂的QoS標準。

綜合以上，法國電信（France Telecom）便提議一種結合IntServ與DiffServ架構、稱為流量感知網路（flow-aware network；FAN）的方法。其中邊界節點只會在網路負載超過一個門檻時，才會將那些超量封包予以丟棄。此外，電子與電信通訊研究所（Electronics and Telecom communication Research Institute；ETRI）與英國電信（British Telecom；BT）等機構，則提議另一種流量狀態感知（flow state aware）技術，其中將Internet服務區分為許多不同的服務類型等級（CoS），並針對這些型態加以定義需求條件與控制程序。

控制架構之比較

目前有數種QoS的提議架構，在此我們將常見部分整理如(表二)所示。

大多數QoS架構在處理端點式的QoS問題，尤其是成本敏感的企業應用而言。這種新系統大多數會先存在於企業模式，企業對企業（E2E）的端點式QoS架構主要應用範圍是以ITU-T架構下的網路多媒體應用為基礎，然後逐漸推廣到一般大眾可負擔的範圍。為使QNS可以普及廣受支持，建立一般化的標準架構建立勢在必行。

ITU-T的RACF標準

在ITU-T NGN架構的一個重要概念，便是分別獨立傳送組織層與服務組織層，藉此，網路資源需求與服務的可信度主要發生於在網路端，由服務組織層依據客戶的要求來決定。換句話說，傳送組織層主要是負責封包的前導與流量控制；而服務組織層主要是負責應用程式的訊號（application signaling），可被視為一個簡易的應用伺服器（application server）。

因此傳送組織層只關心不同型態封包的傳送問題，所有傳送控制的功能，都被放在傳送組織層，這些傳送功能利用控制介面與服務組織層相連結。對於是否允許加入所要求的服務，要視當時網路策略與資源可用性來決定。此外，一旦服務要求被接受後，也同時控制了網路資源的分配。另外服務組織層所關心的是封包的負載費用（payload），至於服務型態與傳送方法之間並無密切關聯性。

ITU-T的RACF依據營運策略與網路資源可用性原則，負責決定服務加入（admission）以及傳送功能上的資料控制。有關ITU-T對於NGN所制訂之傳送與服務架構頗為複雜，如(圖三)所示。

《圖三　ITU-T對於NGN所制訂之傳送與服務架構示意圖》

TCF

傳送控制功能（transport control function；TCF）主要是當作兩個組織面的一種調停機制，可以依據當時的網路資源狀態或是網路提供者策略，決定客戶所提出的服務要求是否被接受。因此，RACF可以視為一種可以決定網路資源及適當控制網路成員的集合功能體。

SCF

服務控制功能（service control function；SCF）則是負責建立應用程式訊號，當SCF傳送一個QoS要求給RACF時，RACF會偵測QoS是否可被接受，然後藉由控制網路元件的方式，保留所需要的網路資源。SCF在應用層發訊時，會去改變位址資訊（address information）。PD-FE會去確認NAPT的控制是否有其必要性，再去控制網路邊界裝置的PE-FE，修改資料封包的IP位址。

NACF

另外，存取網路內存有一種稱為網路附屬控制功能（network attachment control function；NACF），可被用來支援驗證使用者的一些特性資料。在呼叫建立的過程中，NACF會依據存取網路中訂戶的最大可用頻寬，來對相關要求進行確認。通常不管在存取網路或是核心網路，RACF的功能架構均大同小異。

靜態和動態QoS控制架構

不同的網路型態有不同的控制方法或傳送技術，QoS控制機制可分為靜態或動態。靜態的QoS控制架構，控制資訊常被存放在網路裝置的架構檔（configuration file）。例如家庭網路裝置的電源被啟動或架構被管理系統更改時，QoS便會起始化設定，亦即家庭中的門閘（gateway）QoS設定可以被架構檔或遠端管理系統所偵測，這類型QoS控制架構可以參考DSL論壇的架構。

另外動態的QoS控制架構是在兩端利用呼叫設定訊號（call set-up signaling）進行連線時，同時也可對網路的可用資源進行分配與控制。在Cable Lab的QoS控制機制，同時考量了靜態與動態QoS控制方法，在架構服務環境的同時也能建立基本服務，並利用QoS訊號來取得動態的額外服務需求，相對於ITU-T與ETSI／TISPAN所定義的QoS機制有所不同。

ITU-T與ETSI所定義的QoS架構焦點主要放在動態QoS控制上。因此，傳送與服務的獨立性便顯得重要。動態QoS應用端程式的要求訊號可能會動態改變，因此傳送架構必須要保留一些網路頻寬給這些QoS要求使用。不過在發展RACF與RACS（resource and admission control subsystem）時，均有考量DSL環境，因此這些DSL環境亦可直接套用動態QoS控制策略。但RACF體系架構仍嫌龐大，或許因為要考量不同網路通透性的關係。此外，在RACF的一般化架構裡，仍有一些問題尚待解決。

（本文下期將繼續探討RACF需面對的問題，與RACF的功能與功能體，歡迎讀者持續鎖定。）