A QoS policy is a definition of the QoS levels that are assigned across a network. In a converged network, having a QoS policy is as important as having a security policy. A written and public QoS policy allows users to understand and negotiate for QoS in the network.
QoS 政策是對整個網路中所指派 QoS 等級的定義。在匯聚網路中，制定 QoS 政策與制定安全政策同樣重要。書面且公開的 QoS 政策，可讓使用者了解並協商網路中的 QoS。
There are three basic steps involved in defining QoS policies for a network:
為網路定義 QoS 政策時，基本上有三個步驟：
- Identify traffic and its requirements. Study the network to determine the type of traffic running on the network and then determine the QoS requirements for the different types of traffic. The figure shows a network traffic discovery identifying voice, video, and data traffic.找出流量及其需求。研究網路，確定網路上運行的流量類型，然後判斷不同流量類型的 QoS 需求。下圖顯示了一項網路流量探索作業，找出語音、視訊與資料流量。
- Group the traffic into classes with similar QoS requirements. For example, the voice and video traffic are put into dedicated classes, and all of the data traffic is put into a best-effort class.將流量分組為具有相似 QoS 需求的類別。例如，語音與視訊流量會被歸入專用類別，而所有資料流量則歸入盡力而為（best-effort）類別。
- Define QoS policies that will meet the QoS requirements for each traffic class. In the example in the figure, the voice traffic is given top priority and always transmitted first. The video traffic is transmitted after voice but before the best-effort traffic that is only transmitted when no other traffic is present.定義能滿足各流量類別 QoS 需求的 QoS 政策。在圖中的範例裡，語音流量獲得最高優先權，一律優先傳輸；視訊流量則在語音之後、盡力而為流量之前傳輸，而盡力而為流量只有在沒有其他流量時才會傳輸。
Identify Network Traffic and Requirements
找出網路流量及其需求
Before deploying a QoS policy, network traffic must be identified.
在部署 QoS 政策之前，必須先找出網路流量。
Follow these steps to identify network traffic:
請依下列步驟找出網路流量：
- Network audit網路稽核
- Business audit業務稽核
- Service level review服務等級檢視
The first step in creating a QoS policy is to identify network traffic, by determining the traffic flows on the network, understanding the business requirements that are associated with the types of traffic, and understanding the service-level requirements of the traffic.
建立 QoS 政策的第一步是找出網路流量，方法是判斷網路上的流量流向、了解與各類流量相關的業務需求，以及了解該流量的服務等級需求。
Identifying network traffic can be accomplished by deploying classification tools on the network such as Network-Based Application Recognition (NBAR), NetFlow, or packet sniffers, and by conducting interviews with the different departments of the enterprise to determine which applications they utilize to perform their job functions. Enterprise networks typically have a prohibitively large number of applications running on them, so it is important to utilize the department interviews to limit the scope of the network discovery.
要找出網路流量，可以在網路上部署分類工具，例如以網路為基礎的應用程式辨識（Network-Based Application Recognition，NBAR）、NetFlow 或封包擷取工具，並與企業內各部門進行訪談，以確定他們用來執行工作職能的應用程式。企業網路上通常運行著數量龐大的應用程式，因此善用部門訪談來縮小網路探索的範圍非常重要。
Once the network traffic has been identified, a business audit should be completed to determine how the application requirements for each business unit maps into the overall business model and goals. It is important to have executive sponsorship for this process as QoS inherently means that some traffic, and users, will receive priority over others.
找出網路流量後，應完成業務稽核，以確定各業務單位的應用程式需求如何對應到整體業務模式與目標。此過程需要有高階主管的支持，因為 QoS 本質上意味著某些流量與使用者將獲得優先於其他流量與使用者的待遇。
Finally, define the service levels that are required by different traffic classes in terms of delay and jitter requirements, packet loss tolerance, bandwidth that is required, and time sensitivity. This will be determined by understanding the traffic profile and the business use case of the application. For example, database access by end users might require low delay for a good user experience, while database backups might be able to occur during low network use without affecting business requirements.
最後，根據延遲與抖動需求、封包遺失容忍度、所需頻寬以及時間敏感度，定義不同流量類別所需的服務等級。這將透過了解流量特性與應用程式的業務使用情境來決定。舉例來說，終端使用者存取資料庫可能需要低延遲以獲得良好的使用者體驗，而資料庫備份則可能可以在網路使用量低的時段進行，而不會影響業務需求。
Voice traffic typically has a smooth, relatively low-bandwidth profile with strict latency, delay, and packet loss requirements. Voice traffic has extremely stringent QoS requirements. Voice traffic usually generates a smooth demand on bandwidth that will cause minimal network impact with proper capacity planning.
語音流量通常具有平穩、相對低頻寬的特性，並有嚴格的延遲、時延與封包遺失需求。語音流量的 QoS 需求極為嚴格。只要有適當的容量規劃，語音流量通常會產生平穩的頻寬需求，對網路的影響極小。
Video-conferencing traffic typically has a bursty, relatively high-bandwidth profile with strict latency, delay, and packet loss requirements. Video-conferencing applications have stringent QoS requirements. Video-conferencing traffic is bursty and greedy (requires high bandwidth) in nature and, as a result, can impact other traffic.
視訊會議流量通常具有陣發性、相對高頻寬的特性，並有嚴格的延遲、時延與封包遺失需求。視訊會議應用程式的 QoS 需求十分嚴格。視訊會議流量本質上具有陣發性且需求量大（需要高頻寬），因此可能影響其他流量。
Because of the wide variety of data applications, the profile of data traffic varies greatly. There are literally hundreds of thousands of data networking applications, and the associated QoS requirements vary greatly. Different applications may make very different demands on the network, and even different versions of the same application may have varying network traffic characteristics. Transport protocol, delay and packet loss sensitivity, bandwidth requirement, and traffic profile will vary greatly depending on the implementation of the data application. Data traffic differs from voice and video traffic in that it typically has less stringent delay and packet loss requirements. Because data traffic normally cannot tolerate drops, the retransmit capabilities of TCP become important and, as a result, many data applications use TCP.
由於資料應用程式種類繁多，資料流量的特性也差異極大。實際上存在數十萬種資料網路應用程式，其相關的 QoS 需求也大不相同。不同的應用程式對網路可能有截然不同的要求，即使是同一應用程式的不同版本，其網路流量特性也可能有所差異。傳輸協定、延遲與封包遺失敏感度、頻寬需求以及流量特性，會因資料應用程式的實作方式而有很大差異。資料流量與語音、視訊流量不同之處在於，其延遲與封包遺失需求通常較不嚴格。由於資料流量通常無法容忍封包遺失，因此 TCP 的重傳能力就變得十分重要，也因此許多資料應用程式都會使用 TCP。
Group Traffic into QoS Classes
將流量分組為 QoS 類別
It is recommended that data traffic be classified into no more than four groups as described in the table.
建議將資料流量分類為不超過四個群組，如下表所述。
Traffic Class 流量類別 | Application Traffic Properties 應用程式流量特性 |
Mission-critical 任務關鍵 | Applications that are deemed to be the most significant for the success of the enterprise. Typically, these applications technically fit within the transactional and interactive queue, but due to business requirements, they are given a higher level of preference. 被視為對企業成功至關重要的應用程式。技術上，這些應用程式通常屬於交易與互動佇列，但基於業務需求，會給予更高的優先權。 |
Transactional and interactive 交易與互動 | Transactional applications are typically client/server models that consist of user-initiated queries that are followed by server responses, while interactive applications have highly interactive traffic with strict user feedback requirements. 交易型應用程式通常採用主從式（client/server）模型，由使用者發起查詢後接收伺服器回應；互動式應用程式則具有高度互動的流量，並有嚴格的使用者回饋需求。 |
Best-effort 盡力而為 | All noncritical traffic that has not been assigned to a specific data queue will utilize this best-effort class. 所有未被指派至特定資料佇列的非關鍵流量，都會使用此盡力而為類別。 |
Scavenger 劣後（scavenger） | All data traffic that is used by nonbusiness applications. 非業務應用程式所使用的所有資料流量。 |
After the majority of network traffic, which besides different classes of data traffic include voice and video, has been identified and measured, use the business and service-level requirements to define traffic classes.
在找出並量測大部分網路流量（包括不同類別的資料流量、語音與視訊）之後，即可根據業務與服務等級需求來定義流量類別。
Due to its stringent QoS requirements, voice traffic will almost always exist in a dedicated class. Cisco has developed specific QoS mechanisms, that ensure priority treatment over all other traffic.
由於 QoS 需求極為嚴格，語音流量幾乎總是會被歸入專用類別。Cisco 已開發出特定的 QoS 機制，確保語音流量在所有其他流量之上獲得優先處理。
After you define the applications with the most critical requirements, you can define the remaining traffic classes using the business requirements.
在定義出需求最關鍵的應用程式之後，即可根據業務需求定義其餘的流量類別。
An enterprise might define traffic classes as follows:
企業可能會如下定義流量類別：
- Voice: Absolute priority for VoIP traffic語音： VoIP 流量享有絕對優先權
- Mission-critical: Small set of locally defined applications that are critical to the business任務關鍵：少數對業務至關重要、由本地定義的應用程式
- Transactional and interactive: Database access, transaction services, interactive traffic, and preferred data services交易與互動：資料庫存取、交易服務、互動流量，以及優先資料服務
- Best-effort: Internet access and email盡力-而為：網際網路存取與電子郵件
- Scavenger (less than best-effort): Nonbusiness applications such as peer-to-peer file sharing, streaming audio or video sites, or gaming sites劣後（低於盡力而為）：非業務應用程式，例如點對點檔案分享、串流音訊或視訊網站，或線上遊戲網站
Define Policies for Traffic Classes
為流量類別定義政策
Once traffic classes have been defined, QoS policies must be defined for each class.
定義好流量類別後，必須為每個類別定義 QoS 政策。
The following parameters must be defined for each traffic class:
每個流量類別都必須定義下列參數：
- Minimum or maximum bandwidth最小或最大頻寬
- Priority優先權
- Congestion management technique壅塞管理技術
Example Policy
範例政策
Class 類別 | Bandwidth 頻寬 | Priority 優先權 | Congestion Management Examples 壅塞管理範例 |
Voice 語音 | Minimum 1 Megabit per second (Mbps) 最少每秒 1 百萬位元（Mbps） | Level 5 等級 5 | Low Latency Queuing (LLQ) 低延遲佇列（Low Latency Queuing，LLQ） |
Mission-critical and transactional 任務關鍵與交易 | Minimum 1 Mbps 最少 1 Mbps | Level 4 等級 4 | Class-Based Weighted Fair Queuing (CBWFQ) 類別式加權公平佇列（Class-Based Weighted Fair Queuing，CBWFQ） |
Best-effort 盡力而為 | Maximum 500 kilobits per second (kbps) 最多每秒 500 千位元（kbps） | Level 2 等級 2 | CBWFQ CBWFQ |
Scavenger 劣後 | Maximum 100 kbps 最多 100 kbps | Level 0 等級 0 | CBWFQ and Weighted Random Early Detection (WRED) CBWFQ 與加權隨機早期偵測（Weighted Random Early Detection，WRED） |
Defining the QoS policy for each traffic class requires setting the minimum and maximum bandwidth limits, assigning priority to the class, and using QoS technologies to manage congestion.
為每個流量類別定義 QoS 政策，需要設定最小與最大頻寬限制、為該類別指派優先權，並運用 QoS 技術來管理壅塞。
An enterprise might determine QoS policies as follows for a four-class policy:
企業針對四類政策，可能會如下決定 QoS 政策：
- Voice: Minimum bandwidth is 1 Mbps. Mark as priority level 5 and use LLQ to always give voice priority.語音：最小頻寬為 1 Mbps，標記為優先等級 5，並使用 LLQ 讓語音始終享有優先權。
- Mission-critical and transactional: Minimum bandwidth is 1 Mbps. Mark as priority level 4 and use CBWFQ to prioritize traffic flow over best-effort and scavenger queues.任務關鍵與交易：最小頻寬為 1 Mbps，標記為優先等級 4，並使用 CBWFQ 讓其流量優先於盡力而為與劣後佇列。
- Best-effort: Maximum bandwidth is 500 kbps. Mark as priority level 2 and use CBWFQ to prioritize best-effort traffic that is below mission-critical and voice.盡力而為：最大頻寬為 500 kbps，標記為優先等級 2，並使用 CBWFQ 讓盡力而為流量的優先權低於任務關鍵與語音流量。
- Scavenger: Maximum bandwidth is 100 kbps. Mark as priority level 0 and use CBWFQ to prioritize scavenger traffic and WRED to drop these packets whenever the network has a propensity for congestion.劣後：最大頻寬為 100 kbps，標記為優先等級 0，並使用 CBWFQ 排定劣後流量，並在網路有壅塞傾向時使用 WRED 捨棄這些封包。