【網絡】PFC背景和原理 (DCB=PFC + ETS)


目錄

背景

一、PFC

1.概述

2.報文格式

3.工作機制

 

二、ETS

產生原因

基本原理

優先級組的調度

優先級的調度

三、DCBX

產生原因

基本原理

DCBX TLV介紹


背景

在數據中心網絡當中,典型的存在着以下兩種流量:

存儲數據流:要求無丟包;
普通數據流:允許一定的丟包和時延。


很顯然兩種數據流對服務的要求是不同的,因而傳統的數據中心也往往會部署兩個網絡來滿足對數據中心的這些需求。這種網絡在一定意義上來說是冗余的,會造成資源的浪費,當數據中心規模擴大時,這種方案就變的不可接受了。因此急需一種可以將兩種網絡統一起來的網絡技術。


當將這兩個網絡進行融合時,需要對兩個網絡進行考察:
普通數據流:它沒什么特殊要求
存儲數據流:存儲網一般采用FC協議,存儲也是傳統數據中心最主要的業務,因而對兩個網絡進行融合,最重要的就是要保護客戶在存儲上的投資。為此一些IT廠商提交了一個協議規范FCoE,FCoE(Fibre Channel over Ethernet)技術標准可以將光纖通道映射到以太網,從而可以在以太網上傳輸SAN數據。它能夠在保護客戶在現有FC-SAN上的投資(如FC-SAN的各種工具、員工的培訓、已建設的FC-SAN設施及相應的管理架構)的基礎上,提供一種以FC存儲協議為核心的I/O整合方案。由於FC不允許丟包,因而在采用FCoE時,必須對以太網進行增強以使得以太網不丟包。


當不考慮上層承載業務,並且考慮以當今最普遍的以太網為基礎進行網絡融合時,需要考慮的最主要就是不能丟包。為此IEEE定義了DCB(Data Center Bridging),DCB是IEEE 提出的數據中心橋接技術,主要包含:
IEEE 802.1Qbb Priority-based Flow Control(PFC):用於滿足兩種流量在以太網中共存時,存儲流量無丟包,且對其它的流量無影響的要求。
IEEE 802.1Qaz Enhanced Transmission Selection(ETS):用於避免一種流量類型的大規模流量猝發影響其它流量類型,為不同的流量類型提供最小帶寬保證。一種流量類型只有在其它流量類型帶寬不占用的情況下,才能使用分配帶寬之外的額外帶寬。這使多種流量類型可在同一網絡中和諧共存。


Data Center Bridging eXchange(DCBX):它是基於LLDP(Link Layer Discovery Protocol)的擴展協議,用於在設備間自動協商並配置PFC、ETS及CN等。
IEEE 802.1Qau Congestion Notification:用於降低引起擁塞的端點站的報文發送速率,從根源上避免擁塞,以保持網絡的暢通,解決因擁塞引發報文重傳或流量控制,導致報文時延增加的問題。
DCB使得以太網可以承載兩種不同類型的數據流。同時由於ETS可以為某種流量提供最小帶寬保證,因而除了將普通數據流和存儲數據流融合到一起之外,采用了DCB技術的網絡還可以用來承載計算業務(用ETS在網絡中為計算業務分配相應的帶寬即可保證計算業務所需的時延保證)。

一、PFC

1.概述


PFC是DCB的一部分,它適用於DCB網絡中的全雙工的點到點鏈路。PFC是對IEEE 802.3定義的流控機制的增強,用於在一個鏈路上消除由於擁塞而導致的丟包。它的增強在於它是基於優先級的。傳統的流控機制中,當某條鏈路出現擁塞時流控會阻止該鏈路上的所有流量。而PFC允許在一條以太網鏈路上創建8個虛擬通道,並為每條虛擬通道指定一個IEEE 802.1P優先等級(cos),允許單獨暫停和重啟其中任意一條虛擬通道,同時不影響其它虛擬通道的流量。比如下圖

該圖中虛擬通道六的流量將被暫停,而其它通道的服務不會受到影響。
PFC使得網絡管理員可以將其中一些優先級(最多8個)用於對丟包敏感的上層協議(比如FC),而另一些優先級用於常規的以太網服務。

2.報文格式


PFC的報文就是一個以太網報文,其格式如下:

DA:目的 MAC地址,為固定的組播 MAC地址 01-80-c2-00-00-01。 
SA:源 MAC地址。 
Type:報文類型,為 0x8808。 
Data:數據,為 PFCPDU。 
FCS:幀檢驗序列。
其中PFCPDU不包括pad部分的格式如下:


  
Control opcode:MAC控制操作碼,2字節。PFC PAUSE幀僅是MAC控制幀的一種,對於PFC PAUSE幀,其在MAC控制幀中的操作碼為01-01;
priority_enable_vector:2字節,高字節置0,低字節的每個位代表相應的time[n]是否有效。priority_enable_vector[n]代表優先級n,當priority_enable_vector[n]為1時,表示time[n]有效;當priority_enable_vector[n]為0,表示time[n]無效。
time:包含time[0] 至time[7]的8個數組單元,每個數組單元為2字節。當priority_enable_vector[n]為0時,time[n]沒有意義。當priority_enable_vector[n]為1時,time[n]代表接收站點應該停止優先級為n的報文的發送的時間,時間的單位為物理層芯片發送512位數據所需要的時間。所以發送一次PFC PAUSE幀,要求對端設備暫停發送的時間長度最長為:65535 ×物理層芯片發送512位數據所需要的時間。


3.工作機制


3.1 支持PCF的設備的要求


如果一個設備支持PCF,則它要:
支持在一個或多個端口上至少在一個優先級上使能PFC
只能在受DCBX管理的域上使能PFC
提供PFC aware的系統排隊功能(即排隊系統需要了解PFC信息並且根據PFC的狀態做出是否發送的決策)
遵守PFC的延遲限制


3.2 典型的工作過程
  
以圖中拓撲為例,假設向紅色鏈路轉發的數據量超過了該鏈路的最大速率,則最終會導致Bridge 4上向該鏈路轉發的數據無法被轉發,此時即出現了擁塞。根據網橋的工作原理,這最終會反映在某些輸入端口的輸入隊列變滿上,在此圖中由於Bridge 4的port 1,2,3都用於向紅色鏈路轉發數據,因而它們的輸入隊列都會逐漸變滿。此時port 1,2,3都會通過各自的鏈路向上游發送擁塞指示,上游收到擁塞指示后,就會停止往該鏈路發送數據。以Bridge 1為例(client發的數據太快,終端反饋到Bridge 1),它就會停止從port 2發送數據,這又進一步會導致Bridge 1的port 1的輸入隊列逐漸被填滿,此時Bridge 1又會向其上游發送擁塞指示,該過程一直持續直到到達數據的源頭,對於例子中的拓撲,最終結果就是Client 1,2,3都會收到擁塞指示(更確切的說不一定所有的都會收到,一個鏈路的上游是否會收到擁塞指示關鍵取決於該鏈路的下游的輸入隊列是否逐漸變滿)。


3.3 工作機制


PFC是用於數據中心的一種技術,它是對IEEE 802.3定義的流控機制的增強,它使得一個鏈路不會由於出現擁塞而丟包。但是PFC也有缺點,它可能會導致擁塞信息被一直向上游傳遞,如果使用PFC的同時也使能了CN,則會降低PFC被使用的頻率。


在實際的網絡中PFC經常結合ETS功能一起使用,做法是使用ETS為某種流分配一定的帶寬,同時給該類流分配一個優先級並啟用PFC,這樣就既能保證該類流不丟包又能保證其帶寬。
PFC被設計僅用於點到點的全雙工鏈路,一個典型的使用PFC的點到點鏈路如下圖所示:


  
與傳統的(802.3定義的)流控相比,PFC可以基於優先級工作。這就使得它可以單獨禁止與某(些)個優先級相關聯的流的發送而不影響其它優先級的流,傳統的流控則無法做到這一點。
標准建議對於默認優先級不要使能PFC功能。


3.3.1 發送擁塞通知:


在點到點的全雙工鏈路中:
如果一端發現其在某個優先級上出現了擁塞,並且該優先級上啟用了PFC,就向另一端發送PFC幀來通知另一端在一段時間內不要再(在某個優先級上)發送數據
如果發現其在某個優先級上的擁塞解除了,並且該優先級上啟用了PFC,就向另一端發送PFC幀來通知另一端可以重新(在某個優先級上)發送數據
簡單的說就是在點到點的全雙工鏈路中,如果一端發現其在某個優先級上的擁塞狀態發生了變化,並且在該優先級上啟用了PFC功能,就向另一端發送PFC幀來通告這個變化。

3.3.2 接收擁塞通告


在點到點的全雙工鏈路中如果一端收到了一個PFC幀,則它首先解析8個優先級對應的信息:
如果本端在某個優先級上沒有啟用PFC,則忽略該優先級的信息,否則
如果priority_enable_vector向量中對應該優先級的比特為1,且time[該優先級]不為0,則如果該優先級的發送沒有停止就停止它,同時根據時間值啟動一個定時器,在該定時器到期之前,該優先級的發送會被停止
如果priority_enable_vector向量中對應該優先級的比特為1,且time[該優先級]為0,則如果該優先級的發送是被停止的,就啟動它,並停止相應的定時器
如果priority_enable_vector向量中對應該優先級的比特為0,則如果該優先級的發送是被停止的,就啟動它,並停止相應的定時器 

3.3.3 延遲限制


PFC的目地是消除鏈路由於擁塞而出現的丟包,因而PFC幀的發送必須滿足一定的時間要求。如果發送端在自己的接收隊列滿之后再發送擁塞通告,則在PFC幀從發送端到接收端傳輸過程中,另一端發送的數據就會因為沒有接收緩存而被丟棄;如果發送端過早的發送了PFC幀,雖然不會丟包但是卻會導致網絡利用率下降。最合適的發送擁塞通告的時機是接收緩存還有存儲空間可以存儲一段時間內另一端能發送的所有數據,所謂的一段時間是指發送PFC幀的一端從判斷是否要發送PFC幀到對端接收到PFC幀並決定停止新的數據發送之間的時間。具體如圖所示:
  


如圖可以看出所謂的一段時間由四部分組成:
發送端產生PFC請求以及PFC幀的排隊時間
PFC幀被發送到另一端的時間
PFC幀在接收端排隊時間
PFC幀被接收端處理並最終停止發送新數據的時間
對比廣域網中的擁塞處理,比如TCP的擁塞檢測、避免算法, 其中很關鍵的一部分是計算RTT,但是在DCB好像沒有計算RTT的部分,這正是局域網與廣域網的不同之處,在廣域網中,你無法知道你的數據需要經過多少條物理鏈路,以及這些物理鏈路具有什么樣的特性(比如速率,帶寬等等),因而RTT必須經過探測才能知道(為了盡可能准確還要取平均數,進行平滑計算等等),但是在DCB中,PFC是在一條具體的物理鏈路上生效的,而這個物理鏈路的速率,帶寬,隊列深度都是可知的,因而無需通過收發報文來探測RTT,完全可以通過估算來獲取比較准確的RTT。

從網絡基礎理論上來說,數據在分組交換網路中傳輸需要經歷四種時延處理時延,排隊時延,傳輸時延和傳播時延,對於一個接口芯片來說,處理時延、排隊時延、傳輸時延必須保證接口能夠達到它所聲明的帶寬(如果接口芯片的時延不能保證這一段,則無論如何接口也無法達到它所聲明的速率),因此如果我們知道了接口的速率就可以知道這三種時延的最大值,而傳播時延取決於物理線路的材質,只要材質確定,線路長度可知,這個時延也是可知的,因此說在一條具體的物理線路上我們是可以知道這幾個時延的,也就無需計算RTT。簡單的說,局域網中的擁塞探測方法之所以和廣域網不同(沒那么復雜)是因為具體的物理線路上的時延是可估算的,而且對於芯片來說處理邏輯越簡單越好,因為這樣可以簡單芯片的設計復雜度。

 

表12-26 報文優先級和接口隊列的映射表

報文類型

優先級

隊列

單播

0

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

非已知單播

說明:

CX320優先級和隊列為一一對應關系。

0

0

1、2、3

1

4、5

2

6、7

6

“反壓信號”實際上是一個以太幀,其具體報文格式如圖12-165所示。

圖12-165 PFC幀格式

表12-27 PFC幀的定義

項目

描述

Destination address

目的MAC地址,取值固定為01-80-c2-00-00-01。

Source address

源MAC地址。

Ethertype

以太網幀類型,取值為88-08。

Control opcode

控制碼,取值為01-01。

Priority enable vector

反壓使能向量。

其中E(n)和優先級隊列n對應,表示優先級隊列n是否需要反壓。當E(n)=1時,表示優先級隊列n需要反壓,反壓時間為Time(n);當E(n)=0時,則表示該優先級隊列不需要反壓。

Time(0)~Time(7)

反壓定時器。

當Time(n)=0時表示取消反壓。

Pad(transmit as zero)

預留。

傳輸時為0。

CRC

循環冗余校驗。

由此可見,流量暫停只針對某一個或幾個優先級隊列,不針對整個接口進行中斷。每個隊列都能單獨進行暫停或重啟,而不影響其他隊列上的流量,真正實現多種流量共享鏈路。而對非PFC控制的優先級隊列,系統則不進行反壓處理,即在發生擁塞時將直接丟棄報文。

在FCoE環境下,管理員可指定FCoE流量對應的隊列使能PFC保證不丟包。

 

二、ETS

 

產生原因

數據中心網絡融合后,在網絡中存在三種流量:LAN流量、SAN流量和IPC流量。而融合網絡中對QoS的要求很高,例如SAN流量對丟包很敏感、且要求報文在傳輸過程中是保序的;IPC流量用於服務器之間的通信,流量要求低時延;LAN流量則只需要設備提供盡力而為的服務,丟包和亂序都可以由兩端的主機來處理,不需要網絡節點做過多的干預。傳統的QoS已經無法滿足融合網絡的需求,而增強傳輸選擇ETS(Enhanced Transmission Selection)通過靈活的層次化的調度實現網絡融合后的QoS。

基本原理

ETS提供兩級調度,分別基於優先級組PG(Priority Group)和優先級隊列,如圖12-166所示。接口首先對優先級組進行第一級調度,然后對優先級組的優先級隊列進行第二級調度。

圖12-166 ETS的處理流程

相比普通QoS,ETS的優勢在於提供了基於優先級組的調度,將同一類型的流量歸入同一優先級組,使得同一類流量能夠獲得相同的服務等級。

優先級組的調度

優先級組即一組擁有相同調度方式的優先級隊列,用戶可通過設置將不同的優先級隊列加入到優先級組中。基於優先級組的調度被稱為第一級調度。

缺省情況下,在ETS中定義了3個優先級組PG0、PG1和PG15,分別代表是LAN流量、SAN流量和IPC流量。

缺省情況下,優先級組的屬性如下表所示。表12-28 優先級組的調度

優先級組號

優先級隊列

調度方式

帶寬占用率

PG0

0、1、2、4、5

DRR

50%

PG1

3

DRR

50%

PG15

6、7

PQ

-

協議規定,PG0、PG1的調度方式是DRR,PG15的調度方式為是PQ。其中由於PG15承載IPC流量,對延時要求很高,因此調度方式為是PQ(Priority Queue);PG0和PG1的調度方式為赤字輪循隊列調度DRR(Deficit Round Robin)。另外,用戶也可根據實際情況對優先級組划分帶寬。

 

 

各優先級組的調度方式無法更改。

假設在出接口隊列中,優先級為3的隊列承載的是FCoE流量,則將優先級隊列3划入SAN組(即PG1);優先級0、1、2、4、5的隊列承載普通LAN流量,則划入LAN組(即PG0);優先級6、7的隊列承載IPC流量,則划入IPC組(即PG15)。接口總帶寬是10Gbit/s,PG15占用的帶寬是2Gbit/s,PG1和PG0各分配50%的帶寬限制,即4Gbit/s。

圖12-167 基於優先級組的擁塞管理

圖12-167所示,在t1和t2時刻,接口總流量不超過接口帶寬時,所有流量都能轉發;在t3總流量超過接口帶寬,且LAN流量超過給定的帶寬,按照ETS的參數進行調度,LAN業務流量被丟棄1Gbit/s。

另外,ETS還提供基於優先級組的流量整形。優先級組的流量整形基於優先級組限制流量的突發,使該優先級組內的流量以比較均勻的速率向外發送。具體原理請參見《CX320 交換模塊 配置指南》中的QoS配置-流量整形

優先級的調度

除了基於優先級組的調度外,對於同一優先級組內的隊列,ETS提供基於優先級的調度管理,稱為第二級調度。

另外,ETS還提供基於優先級的隊列擁塞管理、隊列整形、隊列擁塞避免。具體原理請參見《CX320 交換模塊 配置指南》中的QoS配置。

三、DCBX

 

產生原因

在數據中心網絡融合場景下,為實現無丟包以太網,鏈路兩端的PFC和ETS的參數配置需要保持一致。如果依靠管理員手工配置,不僅工作量龐大而且容易出錯。數據中心橋接交換協議DCBX(Data Center Bridging Exchange Protocol)作為一種鏈路發現協議,能夠使鏈路兩端的設備發現並交換DCB配置信息,大大減輕了管理員的工作量。

基本原理

DCBX的具體功能包括:

  • 發現對端設備的DCB配置信息。
  • 發現對端設備的DCB配置錯誤。
  • 配置對端設備的DCB參數。

DCBX能夠交換的DCB配置信息如下:

  • ETS的優先級組信息
  • PFC

DCBX協議將需要交互的DCB配置信息封裝入鏈路層發現協議LLDP(Link Layer Discovery Protocol)中的TLV中,由LLDP來進行鏈路兩端設備的DCB配置交換。LLDP的具體內容請參見《CX320 交換模塊 配置指南-網絡管理配置》中的LLDP配置

結合圖12-168,以DCB中的PFC為例,介紹LLDP承載DCBX的實現過程。

圖12-168 LLDP承載DCBX的實現原理圖

圖12-168所示,在全局以及PortA和PortB上分別使能LLDP功能,並且PortA上配置了允許發送DCBX TLV的前提下,實現過程如下:

  1. PortA和PortB上分別配置PFC參數,並使能DCBX功能。DCBX模塊通知PortA和PortB可以將各自配置的PFC參數封裝到LLDP報文中發送給對端。
  2. PortA的LLDP模塊根據自己的報文發送周期定期向PortB發送攜帶了DCBX TLV的LLDP報文。
  3. PortB接收到LLDP報文后解析出DCBX TLV,將PortA的PFC參數通知給DCBX模塊。DCBX模塊將PortA的PFC參數和本端配置的PFC參數進行比較,協商一致之后生成配置文件,保證兩端配置一致。

DCBX TLV介紹

圖12-169所示,DCB的信息被封裝在特定的TLV中。其中,Type字段固定為127,OUI字段根據協議類型不同有兩種取值,IEEE DCBX的OUI為0x0080c2,INTEL DCBX的OUI為0x001b21。

圖12-169 DCBX的TLV結構

IEEE DCBX TLV包括:ETS Configuration TLV、ETS Recommendation TLV、PFC Configuration TLV和App TLV。具體內容如表12-29所示。

表12-29 IEEE DCBX TLV內容

TLV名稱

subtype

Length

描述

ETS Configuration TLV

09

25

ETS的本地配置。內容包括:

  • 優先級組的配置:優先級組ID和優先級組的帶寬占用率
  • 優先級隊列的配置:優先級隊列ID和所屬優先級組ID

ETS Recommendation TLV

0A

25

ETS的建議配置,通常用於協商ETS兩端的配置,使其保持一致。內容包括:

  • 優先級組的配置:優先級組ID和優先級組的帶寬占用率
  • 優先級隊列的配置:優先級隊列ID和所屬優先級組ID

PFC Configuration TLV

0B

6

PFC的本地配置。內容包括:

  • 優先級隊列ID
  • 隊列是否PFC

App TLV

0C

不固定

PFC設置為自動協商狀態時攜帶此App TLV,其它狀態報文中均不攜帶,用於各產品以及網卡對接。

INTEL DCBX TLV包括:DCBX Control Sub-TLV、Priority Group Sub-TLV、Priority Flow Control Sub-TLV和App Sub-TLV。具體內容如表12-30表12-31所示。

表12-30 INTEL DCBX v1.00 TLV內容

TLV名稱

subtype

Length

描述

DCBX Control Sub-TLV

01

10

DCBX報文信息。

Priority Group Sub-TLV

02

28

ETS的建議配置,通常用於協商ETS兩端的配置,使其保持一致。內容包括:

  • 優先級組的帶寬占用率
  • 優先級組的ID

Priority Flow Control Sub-TLV

03

5

PFC的本地配置。內容包括:

  • 優先級隊列ID
  • 隊列是否PFC

App Sub-TLV

05

不固定

PFC設置為自動協商狀態時攜帶此App Sub-TLV,其它狀態報文中均不攜帶,用於各產品以及網卡對接。

表12-31 INTEL DCBX v1.01 TLV內容

TLV名稱

subtype

Length

描述

DCBX Control Sub-TLV

01

10

DCBX報文信息。

Priority Group Sub-TLV

02

17

ETS的建議配置,通常用於協商ETS兩端的配置,使其保持一致。內容包括:

  • 優先級組的配置:優先級組ID和優先級組的帶寬占用率
  • 優先級隊列的配置:優先級隊列ID和所屬優先級組ID

Priority Flow Control Sub-TLV

03

6

PFC的本地配置。內容包括:

  • 優先級隊列ID
  • 隊列是否PFC

App Sub-TLV

04

不固定

PFC設置為自動協商狀態時攜帶此App Sub-TLV,其它狀態報文中均不攜帶,用於各產品以及網卡對接。

 

參考:

《DCB學習之一(PFC)》

https://blog.csdn.net/goodluckwhh/article/details/11539111?utm_source=blogxgwz1

https://blog.csdn.net/jiangganwu/article/details/83422946

https://support.huawei.com/enterprise/zh/doc/EDOC1000128401/3edde09#fig_dc_fd_dcb_000401

 

圖:

https://blog.ipspace.net/2010/09/introduction-to-8021qbb-priority-flow.html


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM