原文地址：NFD開發指南-1.介紹
NDN轉發守護程序（ NFD ）是一個網絡轉發器，它與命名數據網絡（ NDN ）協議 [1] 一起實現和發展。 本文檔介紹了NFD的內部結構，並且適合有興趣擴展和改進NFD的開發人員。 有關NFD的其他信息，包括有關如何編譯和運行NFD的說明，可在NFD主頁上找到 [2] 。
NFD的主要設計目標是支持NDN體系結構的各種實驗。 該設計強調 模塊化 （ modularity ） 和 可擴展性 （ extensibility ），以便使用新協議功能，算法和應用程序進行實驗。 我們尚未完全優化代碼以提高性能，目的是性能優化是開發人員可以通過嘗試不同的數據結構和不同的算法來進行的一種實驗。隨着時間的流逝，在相同的設計框架內可能會出現更好的實現。
NFD將在三個方面不斷髮展： 改進模塊化框架 ， 符合NDN協議規範 以及 添加新功能 。 我們希望保持模塊化框架的穩定和精益，使研究人員能夠實施和試驗各種功能，其中某些功能最終可能會成爲協議規範。
1.1 NFD模塊
NFD的主要功能是轉發興趣（ Interest packet ）和數據包（ Data packet ） 。爲了實現這個目的，它將底層的網絡傳輸機制抽象到 NDN Faces 中，並維護諸如 CS 、 PIT 和 FIB 之類的基本數據結構，並實現數據包（ packet ）處理邏輯。 除了基本的數據包轉發外，它還支持多種轉發策略以及一個用於配置，控制和監視NFD的管理接口。 如下圖1所示，NFD包含以下相互依賴的模塊：
-
ndn-cxx Library, Core, and Tools （第10節）
這些庫提供不同NFD模塊之間共享的各種通用服務。 其中包括哈希計算例程，DNS解析器，配置文件， Face 監控和其他幾個模塊。
-
Faces（第2節）
在各種較低級別的傳輸機制之上實現 NDN Face 抽象。
-
Tables（第3節）
實現內容存儲（ CS, Content Store ）、待定興趣表（ PIT, Pending Interest Table ）、轉發信息庫（ FIB, Forwarding Information Base ）、策略選擇（ Strategy Choice ）、測量（Measurements）和其他數據結構，以支持NDN數據包和興趣包的轉發。
-
Forwarding（第4節）
實現基本的數據包（ packet ）處理路徑（ processing pathways ），該路徑與 Faces、Tables 和 Strategies 模塊交互（第5節）。策略是轉發模塊的主要部分，轉發模塊以轉發管道的形式實現了一個框架，以支持不同的轉發策略，有關詳細信息，請參見第4節。
-
Management（第6節）
實現NFD管理協議 [3] ，該協議允許應用程序配置NFD並設置/查詢NFD的內部狀態。 協議交互是通過NDN在應用程序和NFD之間進行的興趣/數據交換來完成的。
-
RIB Management（第7節）
本模塊負責管理路由信息庫（ RIB, Routing Information Base ）。 RIB 可以由不同方以不同方式進行更新，包括各種路由協議，應用程序前綴註冊以及 sysadmins 進行的命令行操作。 RIB 管理模塊處理所有這些請求以生成一致的轉發表，並將其與NFD的FIB同步，該FIB僅包含轉發決策所需的最少信息。
本文檔的剩下部分將更詳盡地描述所有這些模塊。
1.2 在NFD中是如何處理數據包（ packet ）的
爲了使讀者更好地瞭解NFD的工作原理，本節介紹瞭如何在NFD中處理數據包。
數據包通過 Faces 到達NFD。 Face 是廣義的接口（ Interface ）：
- 它可以是物理接口（ physical interface ）——NDN直接在以太網之上運行；
- 也可以是覆蓋隧道（ overlay tunnel ）——NDN作爲TCP，UDP或WebSocket之上的覆蓋；
- 另外，NFD和本地應用程序之間的通信可以通過也是Face的Unix域套接字來完成。
Face 由 LinkService 和 Transport 組成。 LinkService 爲 Face 提供高級服務，例如分片和重組，網絡層計數器和故障檢測，而Transport充當基礎網絡傳輸協議（TCP，UDP，以太網等）的包裝，並提供鏈路層計數器之類的服務。Face通過操作系統API讀取傳入的流或數據報，從鏈路協議數據包中提取網絡層數據包，並將這些網絡層數據包（NDN數據包格式Interests，Datas或Nacks）傳遞給轉發（ Forwarding ）模塊。
網絡層數據包（Interest，Data或Nack）由轉發管道（ forwarding pipelines ）處理，轉發管道定義了對數據包進行的一系列操作步驟。NFD的數據平面是有狀態的，NFD對數據包的處理方式不僅取決於數據包本身，還取決於存儲在表中的轉發狀態。
當轉發器（ Forwarder ）接收到興趣包（ Interest packet ）時，首先將其插入到興趣表（ PIT， Pending Interest Table ）中，其中每個條目代表未決興趣或最近滿足的興趣。在內容存儲庫（CS）上執行匹配數據的查找，內容存儲庫是數據包的網絡內緩存。如果CS中有匹配的數據包，則將該數據包返回給請求者。 否則，該興趣包需要被轉發。
轉發策略（ forwarding strategy ）決定了如何轉發興趣包。NFD允許按名稱空間選擇轉發策略，它在包含策略配置的“策略選擇”表上執行最長的前綴匹配查找，來確定使用哪個策略來轉發興趣包。轉發策略將決定是否，何時以及在何處轉發興趣包（或更準確地說是PIT條目）。在使用某個策略作轉發時，策略模塊：
- 可以從轉發信息庫（FIB）中獲取輸入，該信息庫包含來自本地應用程序的前綴註冊和路由協議的路由信息；
- 還可以使用存儲在PIT條目中的特定的策略信息；
- 也可以記錄和使用存儲在 Measurements 表項中的數據面的性能測量結果。
在策略模塊決定將興趣包轉發到指定的 Face 後，該興趣包將在轉發管道（ forwarding pipelines ）中經過更多步驟，然後將其傳遞給 Face 。 Face 根據基礎協議，在必要時將興趣包分片，將網絡層數據包封裝在一個或多個鏈路層數據包中，然後通過操作系統 APIs 將鏈路層數據包作爲輸出流或數據報發送。
NFD對一個數據包（ Data packet ）到來的處理方式有所不同。它的第一步是檢查興趣表（PIT），以查看是否有此數據包可以滿足的PIT條目，然後選擇所有匹配的條目以進行進一步處理。 如果此數據包（ Data packet ）不能滿足任何PIT條目，則它是未經請求的（ unsolicited ）並且將被丟棄。 否則，數據將添加到內容存儲（ CS ）中，接着通知負責每個匹配的PIT條目的轉發策略。通過此通知，以及另一個“無數據返回”超時，該策略能夠觀察路徑的可訪問性和性能。該策略可以在 Measurements 表中記住其觀察結果，以改進其將來的決策。最後，將數據包（ Data packet ）發送給所有匹配的記錄在PIT條目的下游記錄中的請求者。通過 Face 發送數據包（ Data packet ）的過程類似於發送興趣包（ Interest packet ）。
當轉發器收到Nack時，處理過程將根據使用的轉發策略（ forwarding strategy ）而有所不同。
1.3 NFD如何處理管理興趣（ Management Interests ）
NFD管理協議（ Management protocol ） [3] 定義了三種基於興趣包數據包交換的進程間管理機制：控制命令（ control commands ），狀態數據集（ status datasets ）和**通知流**（ notification streams ）。 本節簡要概述了這些機制的工作方式以及它們的要求。
控制命令 （ control commands ）是已簽名（已認證）的興趣包，用於在NFD中執行狀態更改。由於每個控制命令興趣包的目標都是到達目的管理模塊，而不是被內容緩存（CS）所滿足，因此，通過使用時間戳（ timestamp ）和隨機數（ nonce ）組件，可以使每個控制命令興趣變得唯一。 有關更多詳細信息，請參見控制命令規範 [4]。
NFD收到控制命令請求後，會將請求定向到一個被稱爲“內部 Face ”（ Internal Face ）的特殊 Face 。當請求轉發到此Face時，它會在內部分配給指定的管理員（ manager ）。例如，以/localhost/nfd/faces 作爲前綴的興趣包會分配給Face管理員，請參見第6節。然後，管理員查看請求名稱，以確定請求哪個操作。如果名稱表示有效的控制命令，則調度程序（ dispatcher ）將驗證命令（檢查簽名並驗證請求者是否有權發送此命令），如果驗證成功，則管理器將執行請求的操作。響應以數據包的形式發送回請求者，該數據包由轉發和Face處理，其處理方式與常規數據相同。
Internal Face ：在FIB中始終有一個FIB條目匹配管理協議前綴，並指向 Internal Face （ There is always a FIB entry for the management protocol prefix that points to the Internal Face. ）
上述過程的一個例外是RIB管理（第7節），它是在單獨的線程中執行的。 使用與轉發到任何本地應用程序相同的方法，將所有RIB管理控制命令轉發給RIB線程而不是 Internal Face （RIB線程在啓動時會使用NFD爲RIB管理前綴“註冊”自身）。
狀態數據集 （ status dataset ）是包含定期或按需生成的NFD內部狀態的數據集（例如NFD常規狀態或NFD Face狀態）。任何人都可以使用規範 [3] 中定義的針對特定管理模塊的簡單的沒有簽名的興趣包（ unsigned Interest ）來請求這些數據集。請求狀態數據集新版本的興趣將轉發到內部Face，然後以與控制命令相同的方式轉發到指定的管理器。但是，管理器不會驗證此興趣，而是會生成請求數據集的所有的段（ segments ）並將其放入轉發管道中。這樣，數據集的第一部分將直接滿足初始興趣，而其他部分將通過CS滿足後續興趣。在不太可能發生的情況下，如果後續段在被提取之前已從CS中驅逐，則請求者負責從頭開始重新啓動提取過程。
通知流 （ notification streams ）與狀態數據集相似，因爲任何人都可以使用未簽名的興趣來訪問它們，但是操作方式不同。想要接收通知流的訂戶（ Subscribers ）仍將興趣發送到指定的管理員。但是，這些利益將由調度員丟棄，並且不會轉發給管理者。相反，無論何時生成通知，管理器都會將數據包放入轉發中，以滿足所有未完成的通知流的興趣，然後將通知傳遞給所有訂戶。 預計這些興趣將不會立即得到滿足，並且訂閱者將在到期時重新表達通知流興趣。