來源：TSNLAB 微信公眾號

 

TSN近期技術係列文章第二篇，回顧下最基礎的CQF（Cyclic Queuing and Forwarding
，周期排隊轉發），再講講從CQF發展出來的各個變種。

本文目錄：

•一、什麼是CQF

•二、CQF的效果

•三
、CQF的擴展

一些名詞（CQF家族好壯大呀）：

•BCQF: Bin CQF

•cCQF: Count-based CQF

•ECQF: Enhancements to CQF （P802.1Qdv項目的標題）

•tCQF: Time-based CQF

•TCQF: Tagged CQF

•xCQF: 作者起的名字，泛指以上所有

一、什麼是CQF

雖然這是新技術係列，而CQF相關的標準大約在7年前就全部完成了
，按理說不需再講。但為了對本文後續章節理解上盡可能保持準確，還是要重新夯實基礎。讀者們也可以“自檢”一下自己對於CQF的理解。

“CQF就是Qch”，“CQF就是Qci+Qbv”。這兩種說法都OK。不過從本文開始
，我們將停止“用標準項目編號來指代技術”的做法。一來
，這些IEEE 802.1標準項目完結後
，新產生的文稿內容最終會合入大文檔，如Qch

、Qci、Qbv的內容都會合入802.1Q，而隻有技術名稱具有最顯著的標識特性，例如你完全不需要去記802.1Qbb是啥、802.1Q的第36章是啥，你知道PFC（Priority-based Flow Control）這個技術就可以了。其次，一個標準項目可能會有不止一個目標，例如在TSN圈還算比較有名的“Qcc”，這個項目的主要目的是對SRP流預留協議做補充，同時定義了TSN配置模型
，但如果說一個設備支持TSN配置就叫支持Qcc能力，顯然就會很有歧義。而且，最近快要完結發布的P802.1Qdj項目，對TSN配置模型所在的802.1Q文檔第46章會做出很多修改，那以前所謂的“支持Qcc”，還能繼續這麼說麼
，或者改成“支持Qdj”
，不論怎樣都不合理。

按標準的一致性定義，如一個網橋宣稱支持CQF
，則需要按IEEE 802.1Q中的相關定義
，支持Enhancements for scheduled traffic（也就是我們常說的門控調度）和PSFP（逐流過濾與策略）。即CQF是基於門控調度和逐流過濾與策略的能力實現的一種周期排隊轉發的方案。同時，在802.1Q的附錄T中，給出了CQF的部署案例：通過逐流過濾與策略，將報文按時間基準導入一組出口隊列中的一個，之後門控調度使用相同的周期時間、保障該報文可以被發送。

具體舉例如下，圖中第一個長方形是PSFP中流過濾（Stream Filter）的能力，基於流識別的ID和優先級3，把流分配到ID為1的流門。第二個長方形就是PSFP中流門（Stream Gate，注意這個和門控調度的gate不是一個），右側是流門1的門控列表配置：在T00時隙，門開

，配置IPV（內部優先級值）為7；在T01時隙，門開，配置IPV為6。這意味著，在T00時隙內抵達流門1的報文，因為門開，可以正常通過，因為被分配了IPV為7
，則後續會進入相應的出口隊列7；而在T01時隙內抵達流門1的報文
，後續會進入出口隊列6。（注：如果門關，則報文被丟棄

，所以流門在PSFP中也可以起到類似CAR“發紅牌”的流量監管作用）

相應地
，下圖門控調度的門控列表的配置中，也是T00和T01兩個時隙。可以看到
，隊列7和6在這兩個時隙的狀態分別是關、開，開、關。

由於流門的門控列表和門控調度的門控列表使用了相同的周期（包括周期的基準Basetime和周期的長度CycleTime），也就意味著，T00時隙內抵達的報文，會被放到出口隊列7，並且在T01時隙內允許被調度出隊，而T01時隙內抵達的報文
，會被放到出口隊列6，並且在T00時隙內允許被調度出隊。形成了“你進我出，你出我進”的循環
，這也是為什麼這種方案被稱為周期排隊轉發了。

以上是最基礎的一種、兩個隊列“乒乓”的CQF實shi施shi案an例li。那na麼me可ke不bu可ke以yi實shi現xian更geng多duo隊dui列lie的de循xun環huan輪lun轉zhuan？不bu同tong隊dui列lie的de輪lun轉zhuan時shi間jian可ke不bu可ke以yi不bu相xiang同tong，而er是shi成cheng倍bei數shu關guan係xi？當dang然ran可ke以yi
，並bing且qie還hai沿yan用yong上shang述shu案an例li類lei似si的de方fang式shi就jiu可ke以yi實shi現xian。有you興xing趣qu的de讀du者zhe可ke以yi自zi己ji嚐chang試shi。

二、CQF的效果

端到端如何使用CQF？最基本的方法，就是在端到端時間同步的基礎上，每一跳都做類似的配置。在第一跳，保證在時隙0之內抵達的報文，都在時隙1之內發出，並且留足夠的安全量（即時隙後段留一段時間不允許再發包）以保障在時隙1之內這些報文都抵達第二跳
，那麼第二跳設備就可以在時隙2之內發出這些報文。以此類推，端到端的時延就在2NT這個範圍（N是跳數
，T是時隙長度）。

由此我們看出，CQF的核心優勢有兩個：1是大大簡化了傳統門控編排編排的難度，不需要逐流編排，隻需要保證進入每個周期時隙的報文不超過這個時隙的容量；2是端到端的時延容易計算，基本和跳數、時隙長度成正比（因具體實施方案的差異可能略有不同）。而CQF的代價就是犧牲了低時延，即大部分報文原本可以更快被轉發
，而在CQF機製下，必須等到下一個自己的時隙。同時，CQF還有一個額外的效果，就是端到端的時延抖動比較低。

三

、CQF的擴展

其實CQF的本質，在於周期時隙之間的映射
，包括一個網絡設備內從入口（流門）到出口（門控調度）的de映ying射she，也ye包bao括kuo從cong上shang一yi跳tiao網wang絡luo設she備bei的de出chu口kou到dao下xia一yi跳tiao網wang絡luo設she備bei的de入ru口kou的de映ying射she。而er由you於yu每mei個ge時shi隙xi可ke以yi承cheng載zai一yi些xie報bao文wen，所suo以yi一yi個ge時shi隙xi更geng像xiang是shi一yi個ge車che廂xiang
、一個容器。在P802.1Qdv項目中，正在討論新增一種傳輸選擇算法（和CBS、ATS等並列）
，暫定名稱為BCQF（Bin Cyclic Queuing and Forwarding），其中又具體包含tCQF和cCQF兩種分配Bin的方式。

第一章所講的CQF案例，屬於基於時間的CQF（tCQF
，Time-based CQF）。因為端到端時間同步，一個設備內也容易獲取相同的時間基準，因此端到端所有設備的入口、出口都有相同的時間基準。在流門給報文分別的IPV，就是指示報文進入相應bin的號碼。其實CQF的核心問題，就是對於一個入報文，如何決定把它分配到哪個緩存或者說出隊列。這一問題包括兩個方麵：其一

，該緩存對應的轉發資源是否充足，即在該緩存作為出隊列的時候是否能夠在指定時隙內清空隊列
；其二
，某一個報文預期是在哪個時隙被發出。對於網絡設備而言
，能確認不同時隙的邊界就可以。例如，僅僅在頻率同步（而非時間同步）的基礎上，相鄰網絡設備隻要能計算出周期的相位偏差，即可確認時隙的對應關係，如下圖。參考閱讀：https://mentor.ieee.org/802.1/dcn/21/1-21-0056-00-ICne-input-synchronization-for-cyclic-queueing-and-for

除了通過時間同步或者頻率同步配合計算相位差的方法，還可以通過發送Beacon信標來標識bin的邊界，或者還可以通過在報文頭中添加標識字段Tagging來區分報文歸屬於不同的bin。例如TCQF

，相關信息可參考IETF Detnet工作組的個人文稿：https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/，這一tag逐跳隨著MPLS標簽交換進行替換

；另一篇DetNet文稿CSQF: https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-01，將時隙信息帶在SR（SegmentRouting）標簽中，在使用SR標簽指定路徑的同時，也可以指定在路徑上的每一個節點出端口的轉發時隙。

根據計數實現CQF
，即cCQF（Count-based CQF）。Paternoster是一種案例，具體可參考：http://www.ieee802.org/1/files/public/docs2019/cr-seaman-paternoster-policing-scheduling-0519-v04.pdf

除了bin的設置和邊界映射的區分，xCQF還有太多可以展開的研究課題。例如通過同時運行多種長度不同的bin，使得網絡在支持對更大範圍的具有不同帶寬和時延需求的流量進行調度的同時，盡可能提高緩存利用效率
；通過組合逐流門控調度，在總體上降低逐流狀態機數量（降低編排難度）的同時也能保障少數具有極嚴苛時延要求的流量；還有相關參數的配置優化等等。結合第二章所述的xCQF類方案的效果——簡化編排難度，保障易計算的時延上界，同時一定程度上犧牲了網絡輕載時原本能達到的低時延效果——來看
，xCQF為大規模網絡的時延確定性提供了一種可行的方案
，讓我們共同期待它的進展。

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

特別鳴謝：很榮幸邀請到參與IETF Detnet相關研究8年的資深專家耿雪鬆共同參與本文的撰寫與修訂。