與此同時，為了節約系統交互，在NVMe over Fabrics協議中，完成隊列沒有使用流控機制，因此需要接收端有足夠容納所有已經發出去的命令的完成隊列空間，來容納所有完成請求。
一次IO的傳輸過程如下圖所示：
由于發送請求和完成請求可以直接攜帶數據，從而降低互聯中消耗的交互時間。如果不需要請求中攜帶數據，也可以由Target端在過程中直接從Initiator端獲得相應的數據，如下圖所示。
通過上述機制，NVMe over Fabrics協議實現了對于NVMe協議的命令和數據傳輸的擴展。普通的NVMe命令都可以通過這套機制映射，NVMe的標準命令搖身一變，就成為了互聯協議的命令。不過還是有一些場景是需要特殊考慮的，為了支持這些場景，協議擴展了NVMe命令，增加了與互聯相關的5個命令：Connect，Property Get/ Set，Authentication Send/ Receive。Authentication Send/ Receive主要用于做Initiator端和Target端的安全協議的傳遞，服從SPC-4。下面重點說一說Connect和Property Get/ Set。
在NVMe over Fabrics協議中，約定每個發送隊列都與一個接收隊列對應，不允許多個發送隊列使用同一個接收隊列。發送接收隊列對是通過Connect命令來創建的。Connect命令攜帶有Host NQN，NVM Subsystem NQN和Host Identifier信息，并且可以指定連接到一個靜態的控制器，或者連接到一個動態的控制器。一個主機可以通過不同的Host NQN或不同的Fabric Port建立到一個NVM Subsystem的多重連接。這種靈活性賦予了NVMe over Fabrics極大的靈活性。按照協議規定，同一個控制器的所有發送接收隊列對既可以共享底層的互聯通道，也可以分別獨占一格底層互聯通道，方便根據傳輸層的特點來進行靈活的選擇。
在NVMe協議中，控制器是一個代表與主機進行溝通的接口實體。由于PCIe協議是一種樹狀拓撲結構，因此一旦控制器所處的PCIe Port定下來后，接口所關聯的控制器就完全定下來了。而對于NVMe over Fabrics協議來說，一個Fabric的Port可以嵌入多個控制器，因此根據需要不同，可以選擇實現靜態控制器或動態控制器。動態控制器是一種簡單的模型，適用于對主機具有相同的服務特性的需求。靜態控制器則適用于有不同需要的場景，Initiator可以查詢了解一個Fabric Port內部包含的靜態控制器各自的能力，然后選擇連接到指定的控制器以滿足自身的需要。
在經典的NVMe協議中，PCIe空間的BAR0（BAR1）描述了一段內存空間用于對控制器進行基本的寄存器級別的配置。由于Fabrics結構沒有等效的實現，因此NVMe over Fabrics協議定義了Property Get/ Set分別表示對于控制器端的寄存器讀取和寫入動作。
至此，NVMe的標準操作就完全被準確和高效地映射成互聯網絡所對應的使用方式了。為了能滿足互聯網絡的發現機制，NVMe over Fabrics協議定義了發現服務，用于讓Initiator主動發現NVM Subsystem和對應的可訪問的名字空間。這個服務還同時用于支持多路徑功能。該功能依賴于一個特殊的配置成支持發現服務的NVMe Subsystem。Initiator可以連接到該服務器并使用Discovery Log Page命令來獲取可用的資源。
與NVMe over Fabrics協議一同發布的，還有一份在Linux平臺上實現的基于RDMA和FC傳輸層的NVMe協議的Initiator和Target端的參考代碼。這份代碼不僅僅包含了協議的驅動實現，也包含了對應的CLI工具和Linux OS集成支持。相信對整個生態圈來說這會是一個良好的開端。在剛剛落下帷幕的DCTC2016數據中心技術大會中，我們也看到了業界對于此方案的良好的興趣。其中Broadcom高級架構師Frankie介紹了下一代NVMe Over Fabrics 存儲架構、以太網控制器及 SoC的設計。Xilinx的展示更加直接揭示了借助Xilinx的FPGA的硬件加速，NVMe over Fabrics在RoCE網絡上提供了僅有10us的極低延遲時延。
可以說，行業的熱情是對于NVMe over Fabrics協議的最好的回應?？梢灶A見，隨著Flash成本的持續下降和集成密度的持續增加，隨著新型基于相變存儲的存儲介質的出現和應用，隨著業界對于閃存定義存儲和存儲虛擬化的需求的強化，NVMe over Fabrics必將在高性能存儲以及數據中心中發揮越來越大的價值。
