深入探究以太網PAUSE幀處理流程及長距離鏈路控制閾值

一、PAUSE幀的處理流程

傳統(tǒng)的IEEE 802.3以太網定義了一種不可靠的通信介質;它不能保證注入網絡的數據包一定會到達預定的目的地,可靠性是通過上層協(xié)議來期望的。

在通常由源端和目的端之間的多個節(jié)點組成的網絡路徑中，每一節(jié)點的發(fā)送器和接收器之間缺乏反饋是不可靠的主要原因之一。發(fā)送器發(fā)送數據包的速度比接收器接收數據包的速度快，并且當接收器耗盡可用的緩沖空間來吸收傳入流時，它們被迫地丟棄所有超過其容量的流量。這些在第二層工作得很好，只要上層協(xié)議處理丟棄檢測和重傳邏輯。

但是對于不能在上層建立可靠性的應用，在第二層增加流量控制功能可以提供一個解決方案。流量控制允許接收方向發(fā)送向發(fā)送方反饋Buffer緩沖區(qū)的可用性。它是通過802.3 定義的一種PAUSE控制幀來實現(see Annex 31B of the IEEE 802.3 specification)?換句話說，接收方可以產生一個MAC控制幀，并在預測緩沖區(qū)即將溢出時向發(fā)送方發(fā)送一個PAUSE請求。在接收到PAUSE幀后，發(fā)送方通過停止任何新數據包的傳輸來響應，直到接收方準備好再次接受它們。如下圖所示，描述了PAUSE幀的大致的處理流程，具體的PAUSE幀的格式參見上一篇。

1.本端設備接受側達到Pause 閾值，產生反壓通知本端的MAC_TX。

2.本端的MAC_TX會發(fā)送完當前正在傳送的報文后，產生Pause-XOFF幀并傳輸到對端設備。

3.遠端設備的MAC_RX接受并解析Pause幀，并發(fā)送Pause請求給到本端的上層模塊。

4.上層發(fā)送模塊會把當前正在發(fā)送的報文發(fā)完后，停止發(fā)送新的報文給對端

5.與1對應，當反壓撤銷后也會通知到到MAC_TX。

6.與2對應，MAC_TX會發(fā)送Pause XON幀通知對端，可以繼續(xù)接收新的數據包。

7.與3對應，MAC_RX解析出Pause-XON幀，并發(fā)送Pause 撤銷的指示給到本端的上層模塊。

8.與4對應，上層模塊會繼續(xù)發(fā)送新的數據給到對端。

在產生PAUSE幀時，典型的實現不會嘗試猜測PAUSE的特定持續(xù)時間，而是依賴于X-ON和X-OFF的行為，這種方法必須將PAUSE幀中Time Value 設置比較大的值，然后就可以在適當的時候恢復流量。從而不局限于特定的持續(xù)時間，提高設計的靈活性，改善性能。

但是PAUSE幀的處理也有一個弊端，就是鏈路暫停后，整個端口都無法再發(fā)出新的報文，這就使得IEEE 802.3x 以太網PAUSE功能不適合承載可能需要不同服務質量(QoS)的多個流量流，因為它會影響其他網絡應用的性能。對于此，IEEE 802.1Qbb PFC將基本的IEEE 802.3x PAUSE域段擴展到多個CoS，使需要流控制的應用程序與不需要流控制的應用程序獨立運行。PFC使用IEEE 802.1Q VLAN標簽下的IEEE 802.1p CoS值來區(qū)分最多8個獨立流控的CoS.

二、長距離鏈路閾值

當接受端設備發(fā)起PAUSE 請求后，PAUSE幀需要足夠早地發(fā)送回線的另一端，以便發(fā)送方有更多的時間在接收端緩沖區(qū)溢出之前停止傳輸.同時必須將所有現有的數據包排入接收端緩沖區(qū)，因此，在接收端定義適當的緩沖區(qū)閾值對于PFC實現的功能至關重要。本文從學術角度解釋如何計算無損以太網鏈路的headroom大小。該解釋基于IEEE 802.1Qbb 優(yōu)先級流量控制標準。802-1bb-d2-3中提出了以下4個方面的PFC 延時：

a) Processing and queuing delay of the PFC request;
b) Propagation delay of the PFC frame across the media;
c) Response time to the PFC indication at the far end;?
d) Propagation delay across the media on the return path.

當網絡擁塞的時候，端口會發(fā)出流控幀，那么就要對端口的緩存設置一條水線，達到水線后，就出發(fā)PFC PAUSE。如果水線設置的太小，那么可能導致降低網絡帶寬的利用率；如果水線設置的太大，那么可能導致丟包；所以需要設置一個合理的水線值。如下圖所示詳細描述了一條traffic流從Receive side 到 Send side所有的延時，主要包括接口隊列傳輸延時、接口延時、電纜延時、反應延時。

審核編輯：黃飛