NLSR: 命名數據鏈路狀態路由協議

paper地址：NLSR: Named-data Link State Routing Protocol

摘要（Abstract）

本文介紹了一種用於命名數據網絡（NDN， Named Data Network）的路由協議——命名數據鏈路狀態路由協議（NLSR，Named-data Link State Routing Protocol）的設計。由於NDN使用名稱來標識和檢索數據，所以NLSR將可達性傳播到名稱前綴而不是IP前綴。此外，NLSR區別於基於IP的鏈路狀態路由協議，有兩個最基本的特徵。首先，NLSR使用興趣包（Interest Packet）和數據包（Data Packet）來傳播路由更新，直接受益於NDN內生的數據包驗證，更加安全；其次，NLSR爲每一個名稱前綴生成一個按一定規則（比如，開銷）排好序的轉發選項列表，給實現NDN自適應的轉發策略做支撐。在本文中，我們將討論NLSR主要設計思想，主要包括以下幾個部分：

• 一個適用於路由器、安全密碼（keys，包括公私鑰那些）、和路由更新的層次化命名方案；

• 一個適用於單個管理域的層次化信任模型；

• 一個逐條同步協議，用於替代傳統的使用網絡泛洪的方式傳播路由更新；

• 一個給多路徑轉發選項排序的簡單算法。

與基於IP的鏈路狀態路由協議相比，NLSR提供更高效的路由更新傳播，擁有內建的路由更新認證而且原生支持多路徑轉發。

關鍵詞（Keywords）

Routing, NDN, Trust Model

介紹（Introduction）

命名數據網絡（NDN）[3, 4]是一種新型的網絡體系結構，是對當前基於IP的Internet體系結構一次大刀闊斧的整改。NDN在每個包（packet）中都放置一個數據名稱，而不是攜帶目標IP地址；數據的消費者發送一個興趣包（Interest packet）來獲取數據，興趣包中包含了所要獲取數據的名稱標識，一個包含相同名字的數據包（Data packet）可以用來響應這個興趣包（Interest Packet），數據包中包含名稱、數據以及一個由最初的數據生產者生成的對該數據包的簽名。通過給數據包進行顯示的命名和簽名，NDN網絡支持一系列的特性，包括：網內緩存（ in-network caching）、多路徑轉發（multipath forwarding）、多播數據交付（multicast data delivery）和數據真實性校驗（data authenticity）。

爲了能使NDN在廣域網（wide-area networks）上能很好的工作，一個NDN的路由協議需要計算並將合適的轉發條目插入到NDN節點的FIB（NDN網絡的轉發表）表中。每個FIB表項包含一個名稱前綴和一個或多個下一條出口記錄，NDN可以根據FIB表信息來轉發和FIB表項中名稱前綴相匹配的興趣包（Interest packet）。IP網絡下的路由協議必須使用單一的最佳下一跳或者限制其轉發到多個等成本的路徑，來避免循環路徑的產生，而NDN網絡有內建的預防循環路徑產生的機制，所以可以自由的利用多個路徑。因此，NDN網絡需要一個能夠支持基於名稱進行多路徑路由的路由協議。

我們之前爲NDN開發了一個OSPFN [8] 路由協議，它是OSPF路由協議的一個擴展版本，適用於NDN，並將其部署在NDN的測試牀上。OSPFN定義了一種新的不透明的鏈路狀態通告（LSA），用於在路由消息中攜帶名稱前綴。它爲每個名稱前綴計算出最佳的下一跳，並插入到FIB表當中，網絡管理員可以手動爲OSPFN配置一個除了最佳下一跳以外的可選下一跳列表，並插入到FIB表中。雖然OSPFN可以構建基於名稱前綴的FIB表，但同樣存在很多限制。和傳統的基於IP的路由協議一樣，OSPFN仍然使用IP地址作爲路由器的ID，依賴於GRE隧道來跨越傳統的IP網絡，並且對於每個名稱前綴值計算一個最佳的下一跳。我們在部署OSPFN的過程中發現，管理IP地址和隧道是主要的操作問題，並且由於對多路徑的支持不夠，限制了NDN原有的優勢（內建的網內緩存和防路徑循環機制等等）。

在本文接下來的部分，我們將介紹命名數據鏈路狀態路由協議（NLSR）的詳細設計，並使其工作在NDN網絡上（換句話來說，NLSR使用NDN的興趣包和數據包來交換路由消息）。OSPFN是一種與OSPF類似的鏈路狀態協議——鏈路狀態通告（LSA）在整個網絡中傳播，每個路由器構建出了完整的網絡拓撲。和OSPF有所區別的是，在OSPFN中，路由器不再只計算一條最短路徑，而是對所有符合策略的下一跳進行排名，並按序寫入FIB表當中，其在本質上提供了一個基於名稱的多路徑路由表，被用來作爲NDN轉發策略的輸入（NDN的可以利用多路徑信息進行豐富的轉發策略定製）。

NLSR使用名稱而不是IP地址來標識路由器和鏈接，因此它可以使用任何底層的通信渠道（例如：以太網、IP隧道、TCP/UDP隧道等等）來交換路由消息。NLSR直接受益於NDN內建的數據認證機制：由於每個路由更新消息都是由NDN數據包（Data packet）所攜帶的，並且NDN中每個數據包都帶有數據生產者的簽名，所以路由器可以通過驗證每個路由消息的簽名來保證它是由指定的原始路由器生成的，並且在傳播過程中沒有被篡改（數據的完整性和有效性校驗）。

作爲NDN上第一個分佈式的路由協議，NLSR的設計需要回答以下幾個在NDN上獨有的問題：

• 命名（Naming）：如何給路由器（routers）、鏈接（links）和路由更新（routing updates）命名？
• 信任（Trust）：如何分發路由器的加密密鑰（cryptographic keys），以及如何獲得對這些密鑰的信任
• 信息傳播（Information Dissemination）：如何在網絡中傳播路由更新？（基於IP的路由協議採用推的方式將路由更新發送給其他路由器，而在NDN網絡中則需要路由器主動去拉取所有更新）
• 多路徑（Multipath）：如何產生並排序下一跳以促進多跳轉發？

在本文中，我們描述了我們是如何選擇我們的設計方案的，並且闡明瞭這些選擇背後的基本原理。我們的目標不是發明一種新的路由方案（因爲在本質上來講NLSR也是一種鏈路狀態路由協議），而是爲了證明在NDN網絡上建立一個路由協議的可行性和優勢。

由於NDN的自適應多路徑轉發能夠處理在轉發平面上存在的多個數據包傳遞問題（例如：環形路徑），使得路由平面的限制放寬了，設計可以更加自由。舉例來說，路由協議將不用關心路由平面是否會產生環路，因爲NDN的FIB表項的合併操作將使得環路的產生變得不可能。因此，一些原先在IP網絡中不起作用的路由協議設計現在可以在NDN網絡中使用，並且新型路由的設計也成爲可能。探索其它類型的路由設計將是我們未來的工作之一。

本文接下來的部分將包含以下內容：第二節簡要介紹了NDN網絡所提供的一些基本的功能，第三節介紹了設計的細節，第四節展示了實驗測量和結果，第五節討論一些相關的工作，第六節將對全文進行總結。

NDN的基本功能（NDN PRIMARY）

NDN在其轉發平面 [3] 中有三個主要的組件：

• 轉發信息庫（FIB，Forwarding Information Base）：FIB即爲NDN網絡中的轉發表，用於存儲轉發條目，將興趣包與相匹配數據（與興趣包名稱相同的數據包）的潛在來源相關聯。與IP網絡中的轉發表不同的是，對於每一個名稱前綴，他的傳出端口（下一跳）不止一個，而是一個列表。FIB表中的表項可以手動插入，也可以利用NDN路由協議中的控制平面進行填充。
• 未決興趣表（PIT，Pending Interest Table ）：PIT表存儲了未被滿足的興趣包以及他們到來的face接口，因此數據包可以通過查詢PIT表項被路由回到原始的發送興趣包的節點。
• 內容緩存（CS，Content Store）：CS用來緩存數據。

當一個興趣包到達路由器，路由器首先會檢查CS中是否有相匹配的數據，如果有則將數據包從收到興趣包的端口上轉發出去，否則將其添加到PIT表當中（同時記錄下興趣包的入口Face）。如果PIT表中存在相同名稱的條目，新的端口編號將被添加到端口列表當中，以便可以在數據包到來時向所有興趣包到來的端口發送一個數據包的副本。最後，如果興趣包是第一次插入PIT表中（即 PIT表中不存在相同名字的興趣包），則該興趣包將通過查詢FIB錶轉發至下一跳，如果FIB條目中存在多個下一跳，則一個成爲“轉發策略”的模塊將會決定在多條路徑同時存在的情況下，該如何轉發興趣包。

設計（Design）

作爲一種鏈路狀態路由協議，NLSR通過分發鏈路狀態通告（LSAs）來構建網絡拓撲並分發名稱前綴可達性。NLSR路由器建立並維護與鄰接路由器的關係，每當它檢測到任意鏈接的故障或恢復，或者是發現一個新的鄰居，都會生成一個新的LSA並傳播到整個網絡當中。此外，NLSR路由器還會向全網通告本地靜態配置的名稱前綴和local的內容提供者動態註冊的前綴。當任意的名稱前綴被添加或者刪除時，NLSR同樣會生成一個新的LSA並將其傳播到全網。最新版本的LSAs將會存儲在鏈路狀態數據庫（LSDB，Link State Data Base）。

這種拓撲和可達性信息的分發方式最初看起來似乎有點過於直接了，因爲在IP路由器中已經實現了類似的功能。然後，由於在NLSR中使用NDN的興趣包和數據包來進行路由更新，路由協議的設計就必須對IP地址和IP數據推送等一些熟悉的概念（例如：在IP網絡中任何節點都可以簡單的將任何數據包發送到任何其它的節點）做一些轉變。因此，我們需要根據數據的名稱和數據的獲取方式來思考我們的設計。更具體來說，我們需要一個針對路由器和路由更新的系統的命名方案（3.1節詳細介紹）。同時，路由器需要在不知道其它路由器何時會產生新的路由更新的情況下迅速的拉取到最新的路由更新，因爲網絡拓撲和網絡名稱前綴隨時可能發生更改（而一旦網絡拓撲或者名稱前綴發生改變，就會產生新的路由更新）。

在路由功能方面，NLSR與之前的鏈路狀態路由協議主要有以下兩個方面的不同：

• NLSR爲每個名稱前綴提供多個路由，而不是提供單個最短路徑；
• NLSR對每個LSA都進行簽名和驗證，這樣能保證每個路由器只產生自己的前綴和連接信息（不能僞造）

我們將在3.4節介紹我們的路徑計算算法， 在3.6節介紹NLSR的信任模型。

作爲開發基於NDN的路由協議的第一步，NLSR最初的設計運行在單個路由域中，並且只使用簡單的單權限信任模型。我們現在正在將NLSR部署到我們的NDN測試牀上，我們相信這一初步設計的部署經驗可以爲我們以後開發基於NDN的域間路由協議和設計域間路由的信任模型起到拋磚引玉的效果。

• 命名（Naming）

  也許我們設計中最重要的部分便是在路由系統中對每個元素及其相關的公鑰設計一個合適的命名方案。基於我們現有網絡的結構和操作經驗，分層命名的方案可以很好的表示系統中各個組件的關係，還可以很容易區分路由器是否屬於同一個網絡，同時爲給定的路由過程生成消息也變得簡單。同樣的，分層命名的方案還有利於將密鑰和其擁有者關聯起來。

  在我們的設計中，每個路由器的命名都是根據它所在的網絡，所屬的站點以及其所屬站點爲該路由器分配的名字組成的，即 /<network>/<site>/<router>。例如，一個位於亞特蘭大（Atlanta）的一個PoP中的路由器的一個可能命名時這樣子的：/ATT/AtlantaPop1/router3。以這種方式命名的話，如果兩個路由器共享相同的名稱前綴/<network>，則可以判斷這兩個路由器屬於同一個網絡下；如果兩個路由器共享相同的名稱前綴/<network>/<site>，則可以判斷這個兩個路由器屬於同一個網絡下的同一個站點。採用這種分層命名的方式，可以很容易的過濾出錯誤的路由消息。

  路由器上NLSR進程的名字時根據路由器的名稱命名的，具體的就是路由器的名稱作爲前綴，後面跟上NLSR進程的名字NLSR，即/<network>/<site>/<router>/NLSR。這個路由進程名字用於在相鄰NLSR路由器節點之間傳遞週期性的info消息，可以用來檢測鏈接是否失敗，以及檢測NLSR進程本身的一些錯誤（3.5節會詳細介紹）。

  在理想情況下，任何由NLSR進程產生的路由更新消息的命名都應該以該NLSR路由進程的名稱作爲前綴，這樣就很容易可以辨別產生該消息的NLSR進程。換句話說，一個LSA的名稱應該時類似這種格式的：/<network>/<site>/<router>/NLSR/LSA，這樣可以標識該LSA是由指定的NLSR進程生成的。然而， 由於我們在實現的過程中使用了CNNx [5] 和 Repo [5] 來傳播同步LSA消息，而 CNNx repo 嚴格限制了所有參與同步的消息都要共享相同的前綴，我們目前一個折衷的做法是所有路由器生成的LSA都共用一個前綴。我們爲每個LSA使用相同的前綴/<network>/NLSR/LSA（我們稱之爲 ），並在此前綴後加上/<site>/router用以區分不同NLSR路由器生成的LSA。

• 鏈路狀態通告（LSAs）

  NLSR設計了兩種類型的LSA，分別是鄰接LSA（Adjacency LSA）和前綴LSA（Prefix LSA），其中鄰接LSA用於對外宣告一個NDN路由器與其所有鄰居相連的活動的鏈路，而前綴LSA則用於對外宣告在當前的NDN路由器已經註冊的名稱前綴。他們所包含的內容如下表所示：

  表 1 LSA所包含的內容

  Type	Content
  Adjacency LSA	#Active Links (N), Neighbor 1 Name, Link 1 Cost, …,Neighbor N Name, Link N Cost
  Prefix LSA	isValid, Name Prefix

  一個鄰接LSA（Adjacency LSA）的命名通常是這樣的：/<LSA-prefix>/<site>/<router>/LsType.1/<version>，其中<router>指的是產生該LSA的路由器的名字，<version>指的是LSA的版本號（這個版本號是隨時間變化的，路由器每產生一個新的同類型的 LSA，版本號就會改變），在目前的實現裏，LSA的<version>使用的是LSA創建時的時間戳（實際上，和OSPF類似，用序列號來表示也是可以的）。如表1所示，鄰接LSA包含了所有與當前路由器相連的處於激活狀態的鏈接，每一項包含鄰居路由器的名字，和鏈路開銷（link cost）。它是在路由器啓動的時候創建的，且每當路由器的鏈接狀態發生改變時（路由器的鏈接狀態的改變是由週期性的 info 興趣包檢測到的，在3.5節會），都會創建新的鄰接LSA。

  一個前綴LSA（Prefix LSA）的命名通常是這樣的：/<LSA-prefix>/<site>/<router>/LsType.2/LsId.<ID>/<version>，需要提一嘴的是，每個名稱前綴都是使用單獨的前綴LSA來向外通告的。由於一個路由器通常需要宣告多個前綴，所以我們在前綴LSA的命名中使用ID來標識不同前綴的LSA（前綴LSA的ID可以是手動配置的，也可以是基於要宣告的名稱前綴計算得來的）。我們這樣設計前綴LSA是有所考慮的，如果我們將所有的前綴都塞到單個LSA中進行傳播可能會放不下，而且更新的效率不高（因爲每當有前綴添加或刪除的時候就需要生成新的前綴 LSA，如果所有的前綴都用一個前綴 LSA來通告的話，就會傳遞很多冗餘信息）。每個前綴LSA包含一個isValid標記（初始時，isValid = 1）和要宣告的前綴名稱。當一個名稱前綴被取消註冊時，NLSR會將對應的前綴LSA的isValid標記設置爲0，並且將新的LSA傳播給其它節點，其它的NLSR節點收到這個LSA會將這個名稱前綴從LSDB中刪除並且更新FIB表項中對應的表項。

  爲了移除由於路由器故障來不及移除的過時的LSA，每個路由器會週期性的爲每個要通告的前綴生成新版本的前綴LSA，而且每個LSA會有一個生存期（lifetime），一旦生存期失效，這個LSA就會被路由器從LSDB中移除。因此，一旦某個路由器發生故障奔潰，其之前通告的的LSA不會在其它路由器的LSDB中保存太長時間，會很快失效。路由器在計算路由時，不應該收到NLSR中過時的LSA的影響，一旦路由器奔潰，其鄰居將會更新它們LSA的狀態，這樣網絡流量就不會向通往這個奔潰路由器的無效鏈路上傳送了。因爲我們不使用刷新機制來處理丟包和包損壞（這些將由 CNNx Sync 處理），而且過期的LSA並不影響路由計算，因此刷新器的刷新間隔可以設置成較大的間隔，例如：可以每天刷新一次。

• LSDB 同步（LSDB Synchronization）

  爲了從概念上簡化我們的設計，我們將LSDB看作一個數據的集合，把LSA的傳播問題看作由路由器維護的LSDBs的同步問題。路由器週期性地交換他們LSDB的hash值來檢測不一致性，如果發現不一致則從不一致中恢復。這種逐跳的同步方法可以避免不需要的網絡泛洪，當網絡穩定時，鄰居之間只需要相互交換LSDB的hash值即可，而不用互相傳遞所有的LSAs。此外，這種數據同步方式時接收方驅動的，這意味着路由器只會在具有CPU週期時去拉取LSAs，因此路由器基本不會被頻繁的路由器更新整奔潰。

  我們當前的實現使用的是 CNNx 同步協議或 Sync [5] 來將LSAs傳播到鄰居路由器。Sync和CNNx的Repo相關聯，它允許應用程序在Repo中定義命名數據集合，這個集合被稱之爲slice，並保持當前路由器與相鄰路由器中定義相同的slice的同步。Sync會爲Slice中所有的數據計算一個Hash樹，並且在相鄰路由器之間交換根Hash的值來檢測不一致性。如何檢測到Hash值不一致，則兩個鄰居節點會交換Hash樹下一層節點的Hash值，直到他們檢測到導致不一致性的葉子節點，兩個鄰居路由器就會交換對應的數據來達成新的一致性。

  圖1 路由器之間使用 CNNx Sync/repo 相互傳播LSA示意圖（圖中虛線代表週期性消息）

  上圖1顯示了LSA是如何在網絡中傳播的：

  • 爲了同步包含LSAs的Slice，Sync協議（路由器B）週期性的對外發送被稱爲Root Advise的特殊興趣包，這個興趣包攜帶了發送路由器的Slice的hash值（步驟 1）；

  • 當路由器A創建了一個LSA，並把它寫入到Sync的Slice當中（步驟 2），此時路由器A計算的Hash值與路由器B的不同；

  • 這將導致路由器A的Sync回覆路由器B的 Root Advise（通常，在兩個路由器計算得到的hash值相同的情況下，是不需要回復 Root Advise 的，當路由器有有新的LSA產生或者移除時會導致路由器的Hash值不一致，此時才需要回復 Root Advise），這個回覆中攜帶了路由器A本地計算得到的新的Hash值；（步驟3）

  • 收到回覆後，路由器B的 Sync 會比對收到的Hash值，並遞歸的獲取到Hash樹下一層級的Hash值，直到定位到導致不一致性的葉子節點，最終，路由器B的 Sync 會識別出需要同步的數據（這裏所說的數據即爲 NLSR 語境下的 LSA），併發送對應的興趣包將需要同步的數據從路由器A中拉取過來（步驟 4 和 5）；

    • 接着，路由器B的 Sync 會將新收到的數據名字發給本地的NLSR進行（步驟 6）
    • 然後路由器B的NLSR進程就會發送對應名字的興趣包給本地的 repo 來拉取同步過來的LSA數據（步驟 7 和 8），最後更新到本地的LSDB當中（步驟 9）。

  每個 Root Advise 興趣包都有一個存活期（lifetime），路由器在 Root Advise 興趣包到期後會發送一個新的 Root Advise 興趣包。這種週期性傳輸機制的設計是爲了防止 Root Advise 興趣包丟包的發生（試設想，如果Root Advise 興趣包的存活期無限大，會一直等待回覆，如果 Root Advise 興趣包在傳輸的過程中丟失了，而發送方又不知道，且不重傳，那麼發送方會以爲沒有新的更新，一直不去拉取最新的更新），從而降低由於丟包帶來的路由收斂延遲。但是，如果數據包的丟失率很低，頻繁的發送 Root Advise 興趣包亦會帶來無意義的額外開銷。在理想情況下，我們希望根據路由需求和網絡特性來調整 Root Advise 興趣包的發送頻率。爲了支持這個特性並解決 CNNx Sync 實現中的一些其它問題，我們正在致力於開發內建有同步機制的新版本的NLSR，以實現相同的LSA逐跳傳播的效果。

• 多路徑計算（Multipath Calculation）

  基於 鄰接LSAs（Adjacency LSAs）提供的網絡節點間的連接信息，每個NLSR節點都能構建出完整的網絡拓撲。接着路由器只需運行一個簡單的擴展 Dijkstra 算法便可以爲每一個目的節點計算出多跳路由。從 前綴LSAs（Prefix LSAs）中，我們可以知道每個路由器都關聯了哪些前綴。我們可以綜合上述的信息計算出到達每個名稱前綴的下一跳列表。

  我們設計的NLSR中某個路由器計算多路徑路由的方式如下：

  • 首先路由器移除（並非斷開，只是排除）到除了一個鄰居外的其它直接相連的鄰居的路勁（即，只保留一個直接相連的鄰居）；
  • 然後使用 Dijstra 算法計算計算當前路由器到網絡拓撲中其它所有節點的開銷，並記錄；
  • 接着對每一個鄰居都重複上述過程；
  • 最後路由器到網絡上任意的其它節點都會有多條路徑，並且每條路徑都有一個開銷，然後根據開銷進行排名，就能得到到每個目的地的排好序的下一跳列表。

  需要提一嘴的是，NLSR支持讓用戶自行配置對某個名稱前綴最多能有幾條路勁插入到FIB當中，這樣當路由器的鄰居很多的情況下FIB表的大小也是可控的。但是計算開銷仍然會隨着 Face 接口數量的增加而增加，因爲我們需要遍歷所有的 Face 接口來找到所有可能的路徑。我們計劃探索其它多路徑計算算法來解決這個問題。

  與IP不同的是，NDN中的路由信息僅作爲轉發平面的提示信息（參考信息），轉發平面可以根據PIT表中維持的狀態來觀察數據交付的性能，然後結合實際觀測值和來自路由協議排名信息來對每個名稱前綴的多條路徑進行排序。即便如此，路由協議中的排名信息對於初始時將一個興趣包轉發到指定前綴以及在當前路由無法檢索數據時用於探索別的可用路由都是非常重要的。

• 故障與恢復檢測（Failure and Recovery Detection）

  NLSR通過週期性的向每個鄰居節點發送 info 興趣包來檢測鏈路故障和遠端的NLSR進程故障，如果 info 興趣包超時了，則NLSR會在較短的間隔內多次發送 info 興趣包，這樣可以防止 info 興趣包丟包帶來的影響。如果在此期間（這個時間包含info興趣包超時後的若干次重傳時間）鄰居節點沒有響應，則NLSR會將這個鄰居節點的狀態判別爲 down ，與該鄰居節點相連的鏈路也標記爲鏈路故障。檢測到故障之後，NLSR仍然會向故障鄰居發送 info 興趣包來檢測故障是否恢復，但此時發送 info 興趣包的時間間隔應該相對長一點，避免由於長期故障導致較大的無用開銷。需要注意的是，檢測到故障時NLSR時無法區分是鏈路的故障還是遠端NLSR進程的故障，但是無論是哪種故障發生，故障鏈路都不會用於傳輸數據，所以在目前的設計裏不區分這兩種故障也無傷大雅。

  當鄰居節點從故障中恢復時，NLSR會收到對 info 興趣包的恢復，接着NLSR便會將該鄰居的狀態標記爲 Active 。這個操作會導致 鄰接LSA 的更新（產生新版本的鄰接 LSA），並將新的鄰接LSA傳播到網絡中，並準備啓動路由表計算任務。下圖2展示了節點A是如何檢測到節點C的故障，以及時如何檢測到節點B從故障中恢復的。

  圖2 鄰居故障和恢復檢測

• 安全（Security）

  每個NDN的數據包（Data Packet）都是經過數字簽名的，並且生成的數字簽名是數據包組成數據包的一部分。簽名包含名字、內容和少量對簽名驗證有用的支持數據 [3] ，支持數據中很重要的一部分是key locator [1, 3]，它指示了用於給這個數據包簽名的 key 的名稱，這樣接收者就能通過這個名稱去拉取到給這個數據包簽名的 key（當然我們只能拉取到公鑰或證書，不能拉取到私鑰），進而驗證這個數據包的簽名。

  一個具有有效簽名的LSA（即，這個 LSA的簽名是驗證通過的）僅僅說明了這個LSA的簽名是由其 key locator 域指向的 key 的私鑰簽名的，它並沒有告訴我們擁有這個 key 的路由器是否能合法的生成LSA。舉個例子來說，攻擊者可以使用其私鑰簽名一個 前綴LSA（Prefix LSA），並將該LSA注入到路由系統中（此時該 LSA的簽名驗證是可以通過的，但是實際上這個LSA不是一個合法的 LSA）。爲了檢測簽名信息的有效性，我們需要驗證此LSA是否是由授權的NLSR進程簽名的，換句話說，我們需要驗證 key 的名字中包含的相關的NLSR進程是授權的。即便如此，攻擊者還是可以使用與某個有效 key 相同的名字的包，塞入攻擊者自己的key。所以，我們需要一個信任模型來驗證 key 的有效性。

  NLSR是一個域內路由協議（intra-domain routing protocol），在單個網絡域中，通常會有一個網絡管理員（信任錨）可以驗證網絡中 keys 的真實性。因此我們將這個信任錨用於給網絡中的 key 進行簽名和驗證，這樣做易於構建和管理。我們可以簡單的讓信任錨對所有路由器的公鑰進行簽名，但實際上用一個 key 來對大量的 key 簽名是存在很大的安全風險的。爲了解決這個問題，我們在信任錨上設計了一個劃分5個等級的層級結構，它將信任錨中 key 的簽名職責限制到一個較小的範圍。表2展示了每個等級 key 的命名，需要注意的是，所有 key 名稱的最後一個組件（component）都是這個 key 的hash值（在表中未展示出來），所以當某個路由器發送興趣包拉取一個 key 時， 總能保證拉取到的 key 是和名稱所匹配的。

  表 2 Keys Names

  Key Owner	Key Name
  Root	/<network>/keys
  Site	/<network>/keys/<site>
  Operator	/<network>/keys/<site>/%C1.O.N.Start/<operator>
  Router	/<network>/keys/<site>/%C1.O.R.Start/<router>
  NLSR	/<network>/keys/<site>/%C1.O.R.Start/<router>/NLSR

  首先在頂層的是 Root key，爲當前網絡的管理員所擁有，第二層包含一系列的 site keys，由網絡中某個網站的管理員所擁有，並且使用 Root key 進行簽名的。每個 site key 可以簽名一系列的 operator keys（通常一個網站由多個操作員），每個 operator key 又能簽名一系列的 router keys，每個 router key 又能給運行在同一個路由器上的NLSR進程簽名NLSR使用的 key，最後，路由器使用 NLSR key 給每個由NLSR生成的數據簽名。需要注意的是，我們目前的設計裏使用 CNNx sync/repo 來傳播 keys，所以所有的 keys 都共享一個同一個前綴 /<network>/keys （前文中有提到過這是 CNNx 機制限制的，所有用於同步的數據都需要共享同一個相同的前綴），但是我們現在設計的 keys 命名方案確實是一個層級的結構。此外，我們使用兩個標記 %C1.O.N.Start 和 %C1.O.R.Start 來分別指示 operator keys 和 router keys。
  

  圖 3 每個NLSR包的簽名和認證鏈 NLSR嚴格執行基於信任錨的信任模型，圖3描繪了每個NLSR包的簽名和認證的流程。當NLSR路由器發送一個LSA到網絡中時，它會使用它的 `NLSR key` 對數據包進行簽名，並把用來簽名的 `NLSR key` 的名字放在數據包（*Data Packet*）的 `SignedInfo/KeyLocator/KeyName` 域裏面。每當收到一個LSA，NLSR路由器會從本地的內容緩存（*content store*）或者 `repo` （*key 可能已經通過 `key` repo 進行分發* ）中獲取包中指定的 `key`，並驗證內容的簽名，同時NLSR會檢查這 *key* 是否確實屬於生成LSA的那個NLSR進程。接着重複上述過程，直到NLSR拉取到信任錨的自籤 `key`。如果在這個過程中任意一步的 `key` 拉取失敗，或者NLSR發現拉取到的 `key` 是由一個未授權的 `key` 簽名的，亦或是最後的驗證步驟沒有到達信任錨，都認爲該LSA是非法的。需要注意的是，一旦一個 `key` 被驗證有效了，我們將記錄這個信息，以後再收到由該 `key` 簽名的數據包時，不需要再對這個 `key` 進行重複驗證。

評估（EVALUATION）

本節我們將就處理時間、消息傳遞開銷v 和收斂時間三個方面評估NLSR的性能。所有的測試在六個具有不同操作系統和系統規格的異構節點組成的網絡上進行，具體的網絡拓撲如圖4所示。需要特別說明的是，我們爲了在短時間內對協議進行測試，我們將刷新時間設置爲30分鐘，而不是幾天。

圖 4 網絡拓撲

圖 5 每個節點上NLSR進程的CPU的利用率

圖5展示了每個節點上NLSR進程的CPU利用率，圖中節點名稱後括號內的數字代表該節點的度數（即該節點鄰居的個數）。從圖中可以看出，具有較高連通性的節點的CPU佔用率較高，換句話說，在同一個節點上，計算量隨鏈接數的增加而增加。這是因爲在每個鏈路上都需要運行Dijstra算法計算最短路徑（在 3.4 節有詳細的介紹），這會帶來更高的消息傳遞開銷和更多的路由計算。

圖 6 平均CPU利用率

圖6展示了在使用和未使用信任模型時NLSR的處理開銷對比。從圖中可以看出，即便使用了信任模型，需要使用多級的 key 來進行簽名和驗證，NLSR也幾乎不會產生太多額外的開銷。這是因爲實際上，NDN網絡本來就需要對所有傳出的數據包進行簽名，使用信任模型只是多了驗證的步驟，驗證過程需要更多時間去本地的存儲庫中遞歸獲取多個 key 並執行驗證。然後，由於這些都是本地操作（作者的實驗環境中，keys 應該時提前分發到每個節點上的，每個節點只需要去本地的 key repo 就能拉取到需要的 key ）而且只有需要新的 key 時纔會去遞歸驗證，已經驗證的 key 可以反覆使用，所以這隻需要較低的開銷。圖6還展示了，與使用單路徑路由相比，使用多路徑路由會佔用更多的CPU。由於兩種方案的消息傳遞開銷時相同的，這種差異的原因主要是多路徑路由計算的時候需要對每個鄰居計算一次然後合併，計算成本比較高。

圖 7 數據包發送和接收的數量

圖7展示了每個節點平均的消息傳遞開銷，我們分別設置 Sync 的 Root Advise （RA）消息的存活時間爲10 ~ 30秒（默認爲 20 秒），圖中數字描述的是每個節點的 NLSR 和 Sync 平均發送的興趣包的數量和接收到對應數據包的數量。NLSR進程只發送 info 興趣包，這個和 Root Advise （RA）的存活期長短是無關的，所以在只改變 RA 消息的存活期長短的情況下，NLSR發送的 info 興趣包的數量是不變的。Sync 產生的興趣包主要是 RA 興趣包，RA 興趣包是週期性發送的，但是隻有在hash值不一致時纔會收到回覆，因此 RA 興趣包的數量會高於 RA 回覆包的數量。正如預期的一樣，設置較長的發送 RA 興趣包的時間間隔，RA 興趣包的發送數量會降低。Sync 除了發送 RA 興趣包之外，還會發送 節點拉取（NF）興趣包，來獲取 Sync 樹上的節點。NF 包帶來的消息傳遞開銷比 RA 包的要小，尤其是當網絡比較穩定的時候。拉取 LSA 的興趣包是向所有的端口廣播的，但是隻有擁有該缺失的 LSA 的鄰居會回覆，所以 LSA 興趣包的數量要高於 LSA 數據包的數量。

圖 8 使用和不使用多路徑的情況下的收斂時間

在測試收斂時間時也是用和上面一樣的網絡拓撲，在啓動所有的節點後，等待足夠的時間，使得所有節點的 LSDBs 相互保持同步。當網絡收斂後，我們使用 ccnping 工具 [7] 來生成網絡流量。ccnping 服務器放置在 node6 上，在 node2 上啓動 ccnping 客戶端發送 ccnping 興趣包（ping），設置超時時間爲4秒。在60秒後，我們手動關閉 node4，這將強制 node2 換一條路徑去訪問 node6 上的服務。圖8展示了使用多路徑路由的好處：node2 不需要重新計算路徑，它只需要在檢測到 node4 故障時簡單切換到另一條可用的路徑即可。相比之下，只使用單路徑路由花費了大概1分鐘的時間才找到新的可用路徑，並且在180秒重新啓動 node4時回到原來的路徑。收斂的時間可以通過 info 興趣包的超時時間以及重試次數來控制，默認情況下，超時時間爲60秒，在將節點或者鏈接聲明爲down之前的重試次數爲3（間隔 15秒）。

相關工作（Related Work）

據我們所知，在NDN網絡的路由領域只有非常有限的相關工作。Dai 等人提出的路由協議 [2] 表面上與NLSR類似，但還是與NLSR存在以下幾個方面的不同：

• 首先，他們使用 OSPF 收集網絡拓撲信息並計算最短路徑，而我們使用 Sync 傳輸 LSAs，而不是用泛洪的方式；
• 其次，他們的路由消息不是作爲興趣包/數據包發送的，因此無法享受簽名更新的好處（即安全性）；
• 最後，他們的多路徑轉發僅限於由多個生產者提供的內容，例如：在多個服務器副本中進行任播，雖然我們也支持這種情況，但是我們也支持同一生產者的多個路徑。

在 [6]，作者提出了一種在NDN中基於控制器的路由方案（CRoS）。控制器存儲網絡拓撲，計算路由，並存儲命名數據的位置，以便他們可以給網絡中任何的命名數據安裝路由。雖然這種使用分散控制器的想法很有趣，但是網絡仍然需要泛洪特殊格式的興趣包用來檢索控制器，這會帶來巨大的開銷。

結論（Conclution）

雖然基於IP網絡的鏈路狀態的路由協議設計是一個被研究的很透徹的一個話題，但是我們設計NLSR的過程也是一個很棒的學習經歷。爲了滿足NDN的路由要求，NLSR脫離了常規的路由協議使用單路徑的方法，而是爲每個名稱前綴提供多個轉發選項。

我們從這次實踐中獲得的主要收穫是NLSR作爲一個在NDN上開發應用程序的具體方案，它要求：

• 仔細考慮命名空間的設計；
• 一個用於驗證的信任模型的開發；
• 使用興趣包/數據包交換來實現路由消息的更新這一NDN新的設計模式的調整。

此外，使用命名數據通信也可以實現同步，這促進了分佈式系統中的數據集同步。我們的NLSR設計中使用 Sync 來使得路由協議更加健壯，而且在概念上更加簡單。

迄今爲止我們的研究成果意味着我們邁向了基於NDN的路由系統開發的第一步，我們正在進行的工作包括實際部署和操作、探索新的路由方案並擴展到域間路由。

引用（Reference）

[1] C. Bian, Z. Zhu, E. Uzun, and L. Zhang. Deploying key management on NDN testbed. Technical Report NDN-0009, Febryary 2013.

[2] H. Dai, J. Lu, Y. Wang, and B. Liu. A two-layer intra-domain routing scheme for Named Data Networking. Globecom 2012 - Next Generation Networking and Internet Symposium , December 2012.

[3] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard. Networking named content. In Proceedings of ACMCoNEXT, 2009.

[4] L. Zhang et al. Named data networking (NDN) project. Technical Report NDN-0001, PARC, October 2010.

[5] PARC.CCNx open srouce platform. http://www.ccnx.org.

[6] J. Torres, L. Ferraz, and O. Duarte. Controller-based routing scheme for Named DataNetwork. Technical report, Electrical Engineering Program, COPPE/UFRJ,December 2012.

[7] University Of Arizona. ccnping. https://github.com/NDN-Routing/ccnping.

[8] L. Wang, A. M. Hoque, C. Yi, A. Alyyan, and B. Zhang. OSPFN:An OSPFbased routing protocol for Named Data Networking. Technical Report NDN-0003, July 2012.

[9] C. Yi, A. Afanasyev, L. Wang, B. Zhang, and L. Zhang. Adaptive forwarding in named data networking. SIGCOMM Comput. Commun. Rev., 42(3):62–67, June 2012.