DCB工作機制解析三（CN）

阿新 • • 發佈：2018-12-17

一、概述

CN來自於IEEE802.1Qau，它的目地是為頻寬-時延積的量級為5Mbit或更小值的網路域中的長時間存在的流增加擁塞管理功能。這種流常存在於DCB網路，儲存網路，計算機叢集網路等環境中，因而DCB也常用在這些網路環境中。為了使CN技術可以工作，網路中的網橋以及終端都需要支援CN。

該技術可用於是DCB的一部分，它用於避免網路擁塞，以減少丟包和降低網路的延遲（擁塞會導致丟包，丟包後重傳將增加報文的延遲）。為達到避免網路擁塞的目的，乙太網交換機和端點站（在資料中心當中，通常指伺服器）均需支援CN：該技術的基本原理是：

1. 當網橋發現擁塞時，它就傳送擁塞通告給其上游；

2. 擁塞通告最終會被傳遞到網路中的能夠限制自己傳送速率的終端（即資料來源）；

3. 終端在收到擁塞資訊後就根據收到的擁塞資訊降低自己的傳送速率從而消除擁塞進而避免因擁塞而導致的丟包。同時終端還會週期性的嘗試增加報文的傳送速率，如果擁塞已經消除，增加報文的傳送速率並不會引起擁塞，也就不會再收到擁塞通告，報文的傳送速率最終得以恢復到擁塞之前的值，以充分利用網路頻寬。

二、基本概念

擁塞通告（CN）包括了在虛擬橋接的區域網中（in Virtual Bridged Local Area Networks）為選定的流提供佇列擁塞檢測並減輕佇列擁塞的能力。CN被用在頻寬-時延積為5Mbit量級或更小的網路中，以降低受擁塞控制的流（CCF，Congestion Controlled Flow）由於擁塞而丟包的可能性。

CN的實現需要支援VLAN的網橋和終端的協作。一個網路中也可能存在非協作者即不支援CN的網橋或者終端，這時候CN通過對網橋和終端資源的劃分來保證來自非協作者的資料很少會和CCF競爭資源。

2.1 CP

CP： Congestion Point。指的是支援VLAN的網橋或者終端的埠功能，該功能用於監測一個服務於一個或多個擁塞通告優先順序值的佇列，並且能夠產生擁塞通告訊息，移除擁塞通告標籤。簡單的說可以認為CP就是一個擁塞監測點，是產生擁塞的候選點。對於一個CP：

CP根據自己的傳送快取佇列以及QCN演算法來計算每個CCF的狀態。
它不維護關於CCF或者RP的任何資訊，它可以從CCF中的任意一個幀中找到CCF以及RP的資訊。

它獨立的根據自己的傳送快取狀態來決定是否需要傳送CNM。

2.2 RP

RP：Reaction Point。一個終端的埠功能，該功能用於控制CCF的傳送速率，同時會接收擁塞通告資訊並且將其用於計算CCF的傳送速率。對於RP：

每一個RP有一個狀態機。
每個終端獨立的決定產生多少個CCF，如何標識每個CCF，怎麼樣為CCF分配RP。
RP狀態機的狀態變化不會影響相關聯的CCF的CN-TAG
一個源自RP的流在網路中經過的路徑對RP和CP是透明的，它們不知道該流的資料所選擇的路徑是什麼樣的。源自RP的流可能會經過不同的路徑，RP對自己傳送出去的流所走過的路徑不做任何假設。

2.3 QCN協議

QCN：數值化擁塞通告協議（Quantized Congestion Notification protocol）該協議包括兩部分：

CP演算法:發生擁塞的網橋或者終端對在傳送快取中正被髮送的幀進行取樣，併產生一個擁塞通告訊息（CNM）給被取樣的幀的源。CNM中包含了在該CP上的擁塞程度的資訊。
RP演算法:資料來源基於收到的CNM的資訊對其傳送的速率進行限制，同時資料來源也會逐漸增大其傳送速率來進行可用頻寬的探測或者恢復由於擁塞而“損失”的速率。

2.3.1 CP演算法

CP演算法是基於一個快取佇列實現的。CP演算法也利用該佇列來探測是否產生擁塞。CP維護的快取佇列如圖所示：

CP的目的是將佇列快取的使用率維護在一個期望值Qeq上。 CP會計算一個擁塞指示資訊Fb，並且以一個與擁塞程式相關的概率選擇一個進入該佇列的幀，並向該幀的源地址傳送一個包含了Fb的CNM。Fb的計算過程如下：

Qoff = Q – Qeq

Qδ = Q – Qold.

Fb = – (Qoff + w Qδ)

其中Q為即時的佇列大小，Qold是上一次傳送CNM時的佇列大小。因此Qoff表示的是當前佇列大小超過期望值的程度，Qδ表示當前佇列大小超過上次擁塞時佇列大小的程度，實際上即為當前速率與上次擁塞時速率的偏差。w是一個非負常量（標準中提到在模擬時取值為2）。Fb在傳送之前會被數值化為一個6位元的值。如果該值小於0表示有擁塞，否則沒有擁塞，不會發送CNM。出現擁塞時，傳送CNM的概率與Fb的關係如圖所示：

2.3.2 基本的RP演算法

RP演算法需要一種本地的機制來確定何時、怎麼樣來增大發送速率。 RP演算法涉及到的幾個基本概念：

Current Rate (CR): 任意時刻經速率限制器（RL）限制後的傳送速率。
Target Rate (TR): 在收到最後一個CNM訊息之前的傳送速率，它是CR的新的增長目標（即增大CR的目地是增大到該值）。
Byte Counter: 用於統計傳送出去的位元組數的計數器。
Timer:用於觸發速率限制器增大發送速率的定時器。

當僅有位元組計數器可用時，RP演算法的工作過程如下圖所示：

2.3.2.1 降低速率

只有當收到CNM時，RP才會降低傳送速率。在收到CNM後，TR被更新為CR。然後 CR按照如下公式更新

CR =CR*(1 – Gd * |Fb|)

其中Gd是一個常量，其取值需要保證Gd * |Fbmax| = ½,因此速率最多降低到原來值的一半。

2.3.2.2 增大速率

增大速率分為兩個階段。快速恢復階段（FR，Fast Recovery）和主動增加（AI，Active Increase）階段。 1.快速恢復階段

每當速率被降低時，位元組計數器就被重置，同時進入FR階段。FR階段包括5個週期，每個週期相當於速率限制器傳送150k位元組需要的時間。每個週期結束時，TR不變，CR按照如下公式被更新：

CR =½ * (CR + TR)

每個週期取150k位元組是因為，150k位元組相當於傳送100個1500位元組長的幀，如果CP的取樣速率是1%，則如果它還有擁塞時它也能夠取樣到本源傳送的幀併發送新的擁塞通告上來了。因此如果在這樣的一個週期內沒有收到新的CNM，就可以認為沒有擁塞了，因而就可以來嘗試恢復自己因擁塞而“損失”的速率。在這個階段採取的是快速恢復。（相比之下，TCP採用的是乘性減加性增）。 2. 主動增加階段

在快速恢復的五個週期執行完後，位元組計數器進入主動增加階段。該階段用於發現多餘的可用頻寬（TCP的加性增也有類似功能）。此時RP將探測週期設定為50個幀（也可以設定為100個幀）探測一次，在每個週期完後，RP執行如下操作： TR=TR+RAI CR =½ * (CR + TR) RAI是一個常量（標準中給出的是5Mbps）。2.3.3帶定時器的RP演算法

很顯然位元組計數器與傳送速率相關，因而如果CR很小，則位元組計數器取樣的時間也會很長，最終導致RP的演算法變的很慢。因此在RP演算法中引入了一個定時器。

定時器工作過程類似於位元組計數器，也包括FR階段和AI階段。當收到CNM訊息時，該定時器會被重置，並且進入FR階段。FR以及AI的基本工作過程與位元組計數器中的基本一致，唯一變化的是週期的測量方法，在定時器中FR和AI階段的每個週期都用定時器來實現。FR階段，每個週期長度為Tms（標準中給出的模擬時用的時間是10ms），AI階段，每個週期長度被設定為T/2ms。

位元組計數器和定時器共同決定了速率限制器的速率增長。兩種機制獨立的工作，最終：

如果兩者都在FR階段，則速率限制器處於FR階段。此時週期先到的負責按照快速恢復階段的演算法進行速率更新。
只要有任意一個處於AI階段，則速率限制器就處於AI階段。此時週期先到者負責按照AI階段的演算法更新速率。
如果兩者都在AI階段，則速率限制其處於HAI (for Hyper-Active Increase)階段。此時如果位元組計數器或者定時器的第i個週期結束了，則TR和CR按照如下算式更新：

TR =TR + i * RHAI

CR =½ * (CR + TR)

RHAI是一個常量（在標準的模擬中被設定為50Mbps。

需要注意的是在收到一個CNM後至少需要經過50毫秒或者傳送了500個幀之後，速率限制器才能進入HAL狀態。

2.4 CCF

CCF（Congestion Controlled Flow）：具有相同的優先順序的一系列幀，這些幀的傳送終端將其看做是單一的流，並且使用同一個響應點來控制這些幀的傳送速率。簡單的說CCF由來自同一個終端的同一個傳送佇列的資料組成，比如來自同一個終端的同一個程序的資料，來自同一個終端的同一個UDP socket的資料。同一個CCF中的資料都具有相同的CNPV。

需要注意的是終端發出的資料並不一定必須是屬於某個CCF的。非CCF的流不會受CN的控制。對CCF的要求：

在CP上只有很小的機率會出現由於快取滿而丟包。
當前CP上的CCF的平均快取使用量是頻寬-時延積的很小的部分，並且該平均使用量和CCF的數目無關，這是為了保證在進行擁塞避免時還有快取可以快取線路上的報文，從而保證避免丟包不會引入大的時延或者時延抖動。否則，如果沒有足夠的空間來快取線路上的報文，則為了丟包就要進行重傳，從而會導致大的時延或時延抖動。
當前CP上的快取使用量只有很小的機率會underflow。
如果多個CCF共享當前CP，則這些CCF會獲得幾乎相同的頻寬。如果每個CCF有自己的當前CP，則它們獲得的頻寬和該CCF獲取的資源成比例。
只有很小几率會出現underflow和overflow的限制不依賴於CCF的數目，也不依賴於流上的負載。

每一個CP所被提供的頻寬都會被儘量充分利用。只要傳送佇列不空，就會往外發送。如果有兩個CCF：CCF-1，CCF-2經過了同一個CP：CP-1，同時CCF-1還要經過CP-2，CCF-2還要經過CP-3，現在CP-2出現了擁塞，因而CCF-1的流量會受到限制，但是CCF-2不會受到影響。一個簡單的圖示如下：

2.5 CNPV

CNPV（Congestion Notification Priority Value）：擁塞通告優先順序值。該值取自優先順序引數，並被支援CN的網橋或者終端用於支援擁塞通告。同一個擁塞域中的網橋和終端的埠被配置成使得包含該值的幀被分配給相同的CP/SP。因為有8個優先順序值，因而一個埠最多可以支援8個CNPV的值。需要注意的是至少要保證一個值被用於盡力交付的流。

2.6 CN-TAG

CN-TAG（Congestion Notification Tag）：擁塞通告標籤。可以傳輸流標識的一個標籤。RP可以把它加到CCF幀中，CP可以在一個CNM中包含它。

Flow ID(Flow Identifier): 流標識。由支援CN的終端分配的一個標識，在由該終端傳送的CCF中是唯一的。終端可以從CNM中獲取它並最終找到出現擁塞的流以及RP。新增CN-TAG的原因：

通過CN-TAG中的流標識，終端可以找到是一個CCF中的多個流中的哪一觸發了該CNM。
解析流標籤比解析報文內容更容易，因而更容易找到對應的流

CP返回的CNM中總會包含一個CN-TAG，如果觸發該CNM的幀不包含CN-TAG，則該CN-TAG中的流ID被設定為0。如果終端可以基於CNM的基本資訊很容易的找到該CNM所對應的RP，它就可以忽略CN-TAG，否則CN-TAG中的流ID是查詢RP的很方便的手段。 CN-TAG包括兩種封裝格式，分別是乙太網封裝和和SNAP封裝。封裝格式分別如下：

包含了CN-TAG之後的報文個部分順序為（如果沒有就忽略）：

addresses

VLAN-TAG

CN-TAG

data

2.7 CND

CND（Congestion Notification Domain）：擁塞通告域。擁塞域由支援VLAN的網橋和終端組成，這些網橋和終端被連線在一起，並且被配置成支援一個CNPV。支援不同的CNPV的CND可以在網路中共存。不同的CND可以由不同的網橋、終端組成。

簡單的說CND就是被配置成支援某個CNPV的子網，是擁塞通告所生效的一個虛擬的網路域。CND保證了期望獲得擁塞服務的CCF能夠真正獲得期望的擁塞服務。CND用於：

保證只有源自RP的流才會經過CP。
保證源自RP的流不會經過一個不包含CP的擁塞埠。

CND可以通過配置手工建立或者通過擁塞通告TLV來自動建立；如果通過手工配置來建立CND,並且有配置錯誤，那麼擁塞機制就可能不會生效（因為可能會出現非源自RP的流經過了CP，也可能會出現源自RP的流經過了一個不包含CP的擁塞埠）。擁塞通告TLV通過LLDP來發送。擁塞通告TLV格式如下圖所示：

Per-priority CNPV：這是一個一位元組的位元向量，每個位元對應一個優先順序，least-significant 位元對應優先順序0，依次類推。如果某個位元為1則表示該優先順序被用作CNPV，否則不用做CNPV。
Per-priority Ready：這也是一個一位元組的位元向量，每個位元對應一個優先順序。 least-significant位元對應優先順序0，依次類推。每個位元對應於相應的CNPV的cnpdXmitReady。

CND用於在其內部提供擁塞支援，CCF的最終目的地可能並不屬於某個CND，這時候只有流在CND內部時它才能獲得擁塞服務。

2.8 多播支援

該協議並不針對多播，但是也不限制傳送多播資料。如果RP傳送多播時出現了擁塞，它應該將其速率限制到多條路徑中具有最低速率的哪一條的速率（即如果有多條路徑出現了擁塞，則限制其速率為最低的）。

2.9 CNM

CNM（ Congestion Notification Message）擁塞通告訊息包含了RP響應該擁塞通告所需的所有資訊。

2.9.1 CNM封裝

CNM可以是乙太網封裝或者SNAP封裝。 CNM乙太網封裝格式如下圖所示：

CNM的SNAP封裝如下圖所示：

CNM的PDU格式如下圖所示：

Version：CNM訊息的版本號，長度為4bit，佔用第1個位元組的高4位，預設值填充0；
ReservedV：CNM訊息保留欄位，長度為6bit，佔用第1個位元組的低4位，和第2個位元組的高2位，預設值填充0；
Quantized Feedback：CNM訊息的數值化反饋值即Fb，長度為6bit，佔用第2個位元組的低6位；
Congestion Point Identifier (CPID)：擁塞點識別符號，長度為8位元組。為了保證識別符號的唯一性，使用擁塞點裝置的MAC地址作為高位6位元組，低位2位元組用於標識同一裝置的不同埠或者不同優先順序佇列；
cnmQOffset：2個位元組，即Qoff
cnmQDelta：2個位元組，即Qδ
Encapsulated priority：2位元組的封裝優先順序，第1個位元組的高3位，填充觸發CNM訊息的資料幀的優先順序，其它位填充0；
Encapsulated destination MAC：6位元組長的地址，內容是觸發CNM訊息的資料幀的目的MAC地址；
Encapsulated MSDU length：2個位元組，用於表示Encapsulated MSDU欄位的長度；
Encapsulated MSDU：最多佔用64個位元組的觸發CNM訊息的資料幀的內容；

包含了CN-TAG的CNM報文格式如下

addresses

VLAN tag

CN-TAG

CNM-TAG（CNM相關的封裝資訊）

data

2.9.2 CNM典型場景

一個典型的CNM產生場景如下圖所示：

三、工作機制

3.1支援擁塞控制的網橋的工作過程

支援擁塞控制的網橋上的CP在檢測到擁塞後，會產生一個CNM，該CNM會被插入到該介面的輸入佇列中，並最終被髮送給RP。

擁塞檢測是在流被髮送時進行的，如果檢測到了擁塞，它就利用幀中包含的資訊產生一個CNM，並將CNM插入到本介面的輸入佇列，最終該CNM會被根據其中包含的資訊傳送到源RP中。其工作過程如圖所示：

3.2支援擁塞控制的終端的工作過程

終端的工作過程如下圖所示：

從圖中可以看出，支援擁塞控制的終端需要做較多的工作。

3.2.1 流分離

該功能主要完成

根據上層提交的資料的優先順序或者其它配置資訊為其分配優先順序
根據該優先順序以及流選擇資料的內容決定幀應該使用哪個流佇列
如果該優先順序是CNPV，則將其入到流佇列中從而提交給CNPV處理，否則直接交給流多路複用器

該階段不會丟幀，流佇列沒有資源時，實現應該阻止上層繼續提交幀。預設的配置下每個CNPV有一個流佇列，終端可以支援額外的佇列，另外也允許一個佇列支援多個CNPV。

3.2.2 CNPV處理

所有經過該處理階段的幀都必然包含相同的CNPV。其處理邏輯如圖所示：

從圖中可以看出每個CNPV都包含以下幾部分：

一個流佇列。是一個FIFO型別的幀佇列。
一個或多個RP。每個RP包括兩部分，一個RP狀態機，一個速率限制器。RP狀態機執行RP演算法，速率限制器用來限制流的傳送速率。
流選擇功能：用於決定從哪個CNPV的流佇列中取出報文來發送給流多路複用器。如果從流選擇功能中接收幀的傳送佇列已滿，則流選擇功能不會再繼續往其中傳送報文。

3.2.3 其它功能

支援擁塞控制的終端還需要支援的其它功能包括：

流選擇資料庫：流選擇資料庫用於指示幀應該被放入那個流佇列。
流多路複用器:它負責將來自CNPV，忽略CNPV階段，以及來自CP的CNM幀傳遞給下一個階段。
CNM多路訊號分離器:它負責接收CNM並分離CNM幀（即解析），然後根據CNM幀的流標識或者（以及）封裝優先順序找到對應的RP，並將CNM傳送給對應的RP。
輸入流分離:它負責解析幀是否是一個包含CNPV的幀，如果是則將幀送給CP。
終端輸入佇列:用於快取輸入幀
終端輸入選擇：選擇哪個幀將被送給上層

3.3 CND防護

如果想要擁塞機制可以生效，則兩個支援擁塞機制的終端之間的鏈路必須被配置成屬於某一個CND，並且該CND中的網橋要保證不包含該CNPV的幀不會和包含該CNPV的幀使用相同的傳送佇列，即非來自RP的不能經過CP。CND防護即是用來保證這些約束被滿足的一種機制。埠的優先順序重生表被用來支援CND防護。 CND防護的做法：

如果一個埠知道他它的鄰居也被配置成支援某個特定的CNPV，也就是說和本埠屬於同一個與該CNPV關聯的CND，則該埠的對應於該CNPV的優先順序重生表將被忽略，從該介面輸入的報文的優先順序不會被改變。
如果一個埠知道它的鄰居沒有被配置成支援某個特定的CNPV，也就是說不在本埠所在的這個與該CNPV關聯的CND中，則該埠的優先順序重生表中的與該CNPV關聯的表項要被設定成：輸入的幀如果包含了該CNPV，則它要被對映成一個非CNPV的值（本埠可能支援多個CNPV，要從不是CNPV的優先順序中選取一個）。這就保護了CND，使得它不會受不是來自於RP的幀的影響。
如果一個埠被配置成支援某個CNPV，則該埠的優先順序重生表中的任意表項不能將其它優先順序改變為該CNPV的值。
如果一個埠包含多個鄰居，或者一個埠的鄰居不支援擁塞機制，則發往該埠的幀中如果包含了CN-TAG，則需要將CN-TAG去掉。
如果一個包含某一個CNPV的幀被髮往一個支援擁塞機制的系統，但是該系統中接收該幀的介面的優先順序重生表被配置成將CNPV修改為一個其它值，則CN-TAG也需要被移出。

其狀態機如圖所示：

---------------------