基于dns及其擴展協(xié)議的ccn可信尋址方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明涉及一種基于DNS及其擴展協(xié)議的CCN可信尋址方法及系統(tǒng)。該方法在內容中心網絡(CCN)的每個區(qū)域部署內容管理錨點，并基于各區(qū)域的內容前綴將所述內容管理錨點注冊在DNS中；然后通過內容中心網絡中的逐跳尋址方式以及集中式的DNS尋址方式進行尋址，通過DNSSEC協(xié)議建立完整信任鏈以提供名字解析過程中的安全保證，通過DANE協(xié)議提供公鑰信息驗證，實現(xiàn)對內容的可信驗證并最終獲取所需內容。本發(fā)明很好地結合了當前互聯(lián)網的既有基礎設施，是一種能支撐未來海量業(yè)務的數(shù)據(jù)管理模型，特別是未來CCN在移動互聯(lián)網中部署時，能夠有效地支持動態(tài)的內容管理，實現(xiàn)海量內容尋址過程的靈活高效。
【專利說明】基于DNS及其擴展協(xié)議的CCN可信尋址方法及系統(tǒng)

【技術領域】
[0001] 本發(fā)明屬于網絡【技術領域】，涉及一種基于DNS及其擴展協(xié)議的內容中心網絡 (Content-Centric Networking, CCN)可信尋址方法，以及采用該方法的系統(tǒng)。

【背景技術】
[0002] 隨著信息技術的飛速發(fā)展，新的互聯(lián)網應用層出不窮，致使傳統(tǒng)IP技術面臨眾多 挑戰(zhàn)。特別是移動通信技術的飛速發(fā)展以及物聯(lián)網和云計算等新興數(shù)據(jù)應用的涌現(xiàn)，正在 逐漸改變互聯(lián)網用戶獲取服務資源的傳統(tǒng)模式，使互聯(lián)網逐步從互聯(lián)互通的基本功能向支 撐海量數(shù)據(jù)交互的需求發(fā)展，并對網絡安全、高效移動等都提出新的挑戰(zhàn)。
[0003] 近些年，研究者使用了很多方法和手段來完善和優(yōu)化現(xiàn)有互聯(lián)網，使其支持更大 規(guī)模、更高效率的數(shù)據(jù)資源獲取，如在互聯(lián)網架構方面建設了越來越多的數(shù)據(jù)中心，在傳輸 層面越來越廣泛地使用P2P等優(yōu)化數(shù)據(jù)傳輸?shù)募夹g。但是這些"打補丁"的方式使得傳統(tǒng)互 聯(lián)網體系結構越來越冗余，功能越來越復雜。為此，國內外學者開展了對未來網絡架構重新 設計的諸多研究，并將其提升到了國家戰(zhàn)略高度，旨在從根本上考慮解決當前互聯(lián)網支撐 高效數(shù)據(jù)傳輸?shù)膯栴}。以信息為中心的未來網絡體系（Information Centric Networking, ICN)，通過以標識的內容取代主機的地址，實現(xiàn)基于內容名字尋址與路由的新型網絡架構， 得到了廣泛的關注，其中"內容中心網絡"（Content-Centric Networking,CCN)是最為典型 的代表方案。與傳統(tǒng)方式相比，CCN基于內容名字的尋址路由致力于改變現(xiàn)有的網絡通信 模式，從關注于"資源在哪里"轉變?yōu)?資源是什么"，從實現(xiàn)基于端地址的轉發(fā)轉變?yōu)榛?資源名字的轉發(fā)，從而能一定程度上解決路由可擴展性、數(shù)據(jù)分發(fā)效率等問題。
[0004] 但是，CCN并沒有提出一種能支撐未來海量業(yè)務的數(shù)據(jù)管理模型，特別是考慮到未 來CCN在移動互聯(lián)網中部署時，如何有效地支持動態(tài)的內容管理。此外，雖然CCN基于逐跳 的尋址方式具有非常高的效率，但是缺乏有效的邊界管理，從而可能造成內容尋址過程中 的巨大開銷。最后，CCN的尋址過程沒有很好地結合當前互聯(lián)網的既有基礎設施，不能很好 地支撐其平滑的演進。而這些正是本發(fā)明的主要出發(fā)點。
[0005] 下面簡要介紹一下本發(fā)明用到的當前互聯(lián)網的基礎設施及其核心技術：
[0006] 1) DNS (Domain Name System)就是常說的域名系統(tǒng)。作為Internet上的每一臺 主機，都是用IP來標識的，然而這些煩瑣的數(shù)字不僅難以記憶，又不能代表什么意義，所以 應有一種便于記憶的又有意義的方式來標識Internet上的主機，那就是域名，如網易的域 名是http://www.163. com/。那么域名又是怎樣與IP對應起來的呢？在Internet上有許 多DNS服務器，在DNS服務器的數(shù)據(jù)庫中記錄著IP與域名的對應關系，當你要訪問某臺主 機時，只要提供該主機的域名，DNS就會幫你解析該主機的IP。DNS是互聯(lián)網的重要基礎資 源，幾乎所有的互聯(lián)網應用都依賴于DNS解析。
[0007] 2) DNS 安全擴展（Domain Name System Security Extensions，DNSSEC) :DNSSEC 協(xié) 議是一個針對DNS協(xié)議的安全擴展，它通過給DNS的應答消息添加基于非對稱加密算法的 數(shù)字簽名，來保證數(shù)據(jù)未經篡改且來源正確；再通過域名體系自下而上逐級向父域提交自 己的公共密鑰，來實現(xiàn)整個域名體系的逐級安全認證。具體而言，DNSSEC為DNS數(shù)據(jù)提供 了三方面的安全保障：
[0008] a)數(shù)據(jù)來源驗證：保證DNS應答消息來自被授權的權威服務器；
[0009] b)數(shù)據(jù)完整性驗證：保證DNS應答消息在傳輸途中未經篡改；
[0010] C)否定存在驗證：當用戶請求一個不存在的域名時，DNS服務器也能夠給出包含 數(shù)字簽名的否定應答消息，以保證這個否定應答的可靠性。
[0011] 綜上所述，DNSSEC本質上是在域名系統(tǒng)樹形授權體系的基礎上，再建立一套基于 密碼學手段的簽名/驗證體系，也就是信任鏈體系，通過信任鏈上的逐級安全驗證，來確保 DNS查詢結果的真實可靠(數(shù)據(jù)完整性和非否認性)。
[0012] ICANN第一次DNSSEC根密鑰生成儀式后，互聯(lián)網頂級域根的密鑰在2010年正式 生成。目前，VeriSign等管理gTLD的大公司以及美國、英國、德國、法國、保加利亞、巴西、 瑞典、捷克等國的ccTLD已開始實施DNSSEC，未來必將有更多的TLD部署和實施DNSSEC。 DNSSEC支撐下的互聯(lián)網將更加安全可靠。
[0013] 3)基于 DNS 的命名實體認證（DNS-Based Authentication of Named Entities， DANE):基于DNSSEC協(xié)議，IETF工作組設計了一種新的DNS資源記錄TLSA (TLSA僅是一種 資源記錄的名稱，無其它含義)，以使用DNSSEC基礎設施來保存TLS協(xié)議中用到的數(shù)字證書 或公鑰。DANE協(xié)議的核心是：依托DNSSEC基礎設施來限制TLS服務器可用的CA范圍，從 而使區(qū)運行機構可以聲明可供TLS客戶端使用的數(shù)字簽名的范圍。具體而言，此類聲明分 為三大類：
[0014] a) CA限制聲明。TLS客戶端只能接受某些特定CA頒發(fā)的數(shù)字證書，如果TLS服 務器傳輸?shù)臄?shù)字證書不是由這些特定的CA所頒發(fā)，那么TLS客戶端可視這些數(shù)字證書為無 效。
[0015] b)證書限制聲明。TLS客戶端只能接受某個特定的數(shù)字證書(或公鑰)，而不是其 它證書(或公鑰)，這樣就對TLS能用的CA數(shù)字證書或公鑰做了進一步限制。
[0016] c)信任錨點聲明。TLS客戶端應使用由該區(qū)聲明的信任錨點來驗證該區(qū)的數(shù)字證 書。
[0017] 所有上述三類聲明均可視為對信任錨點范圍的限制，前兩類主要限制當前已有信 任錨點的范圍，而第三類為TLS客戶端提供了 一個新的信任錨點。
[0018] DANE協(xié)議使用DNSSEC基礎設施來保存TLS協(xié)議中用到的數(shù)字證書或公鑰，這使得 DANE協(xié)議繼承了 DNSSEC協(xié)議的各種優(yōu)點。DNSSEC是由IETF提供的一系列DNS安全認證 機制，用于提供一種關于來源鑒定和數(shù)據(jù)完整性的擴展。
[0019] 在實際部署方面，Google Chrome已集成了 DANE協(xié)議客戶端，一些用來產生DANE 資源記錄的原型系統(tǒng)也已出現(xiàn)，這為DANE的大規(guī)模應用奠定了堅實基礎。


【發(fā)明內容】

[0020] 如上所述，內容中心網絡（Content-Centric Networking,CCN)雖然能一定程度上 解決路由可擴展性、數(shù)據(jù)分發(fā)效率等問題，但其并沒有提出一種能支撐未來海量業(yè)務的數(shù) 據(jù)管理模型，特別是考慮到未來CCN在移動互聯(lián)網中部署時，如何有效地支持動態(tài)的內容 管理；此外，CCN缺乏有效的邊界管理，從而可能造成內容尋址過程中的巨大開銷，并且CCN 的尋址過程沒有很好地結合當前互聯(lián)網的既有基礎設施，不能很好地支撐其平滑的演進。
[0021] 本發(fā)明針對上述問題，提出一種可擴展的CCN內容管理架構及尋址方法，通過基 于前綴的分區(qū)域管理實現(xiàn)海量內容尋址過程的靈活高效。
[0022] 具體來說，本發(fā)明采用的技術方案如下：
[0023] -種基于DNS及其擴展協(xié)議的CCN可信尋址方法，其步驟包括：
[0024] 1)在內容中心網絡（CCN)的每個區(qū)域部署內容管理錨點（Content Management Anchor，CMA)，負責對該區(qū)域源內容的位置信息以及漫游源節(jié)點的相關信息進行維護，并基 于各區(qū)域的內容前綴將所述內容管理錨點注冊在DNS中；
[0025] 2)通過內容中心網絡中的逐跳尋址方式以及集中式的DNS尋址方式進行尋址，通 過DNSSEC協(xié)議建立完整信任鏈以提供名字解析過程中的安全保證，通過DANE協(xié)議提供公 鑰信息驗證，實現(xiàn)對內容的可信驗證并最終獲取所需內容。
[0026] 進一步地，所述內容管理錨點及其所轄內容信息以如下方式維護：
[0027] Content-Prefix-A/AAAA-TTL--IP-of-CMA，
[0028] 其中，Content-Prefix是該區(qū)域的內容前綴，A/AAAA標識A記錄或AAAA記錄，TTL 為該記錄的生存時間，ΙΡ-of-CM標識負責維護該前綴對應內容及其源節(jié)點地址的信息。
[0029] 進一步地，Interest數(shù)據(jù)包的發(fā)送范圍通過跳數(shù)限制變量進行控制。每個中間路 由器在接收到Interest數(shù)據(jù)包時首先將該跳數(shù)限制變量減1，如果跳數(shù)限制變量為0則表 示在規(guī)定范圍內未能找到對應的內容；該路由器通過DNS查詢該內容名字的前綴信息，從 而獲取內容管理錨點的地址信息，然后經過對內容管理錨點的查詢得到信息源的當前位置 ?目息，進而獲取所需內容。
[0030] 進一步地，路由器通過TLSA資源記錄驗證內容名字的有效性，驗證該名字在請求 過程中未經篡改，并通過公鑰信息對該名字對應的內容進行驗證，保證數(shù)據(jù)在傳輸過程中 未經篡改。
[0031] 進一步地，通過所有者的私鑰簽名保證數(shù)據(jù)內容的安全性，通過DNSSEC保證內容 和名字之間的安全性，通過DANE建立名字和驗證內容安全性的公鑰之間的可信關系。
[0032] 進一步地，通過在內容中心網絡的每個區(qū)域設置的內容管理錨點支持源節(jié)點的移 動。具體方法為：設內容源最初連接在區(qū)域1內的接入路由器1，該區(qū)域1內設有內容管理 錨點1，當內容源切換到區(qū)域2內的接入路由器2后，首先向該區(qū)域2的內容管理錨點2進 行位置注冊，當內容管理錨點2發(fā)現(xiàn)這個內容不屬于自己管轄區(qū)域時，向對應區(qū)域1的內容 管理錨點1進行位置更新，從而使內容管理錨點1知道該內容已經移動至內容管理錨點2 管轄的區(qū)域；當內容源繼續(xù)移動到新的內容管理錨點時，重復上述步驟。在傳統(tǒng)內容中心網 絡中，源節(jié)點的地址變更會造成嚴重的前綴聚合開銷，從而無法在實際中支持源節(jié)點的移 動。本發(fā)明通過設置接入路由器，可以緩解前綴聚合帶來的巨大開銷和時延。
[0033] 進一步地，在源節(jié)點移動過程中，通過各種類型的DNS資源記錄進行資源定位，通 過DNS的動態(tài)更新機制支持資源記錄位置變更。這樣可以在一定程度上借助DNS這一操作 系統(tǒng)普遍支持協(xié)議促進內容中心網絡的平滑演進。
[0034] 一種采用上述方法的基于DNS及其擴展協(xié)議的CCN可信尋址系統(tǒng)，采用內容中心 網絡（CCN)，包括：
[0035] 內容管理錨點（CMA)，部署在內容中心網絡的每一個內容前綴區(qū)域中，作為一個內 容區(qū)域的管理節(jié)點，用于維護內容及其對應源節(jié)點位置的信息；
[0036] DNS服務器，遵循當前互聯(lián)網中DNS的層次體系連接關系，用于維護內容前綴及其 對應的內容管理錨點位置的對應信息；
[0037] CCN路由器，部署在內容中心網絡中，用于基于內容名字進行路由，并具有緩存功 能和相關的擴展功能；
[0038] 內容接收裝置（Receiver)，部署在終端用戶處，用于請求并接收所需內容；
[0039] 內容提供裝置（Provider )，是內容的源，用于提供內容。
[0040] 進一步地，還包括接入路由器，設置在所述內容中心網絡的每個區(qū)域內，用于提供 移動源的無線接入。
[0041] 本發(fā)明提出了一種可擴展的CCN內容管理架構和尋址方法，在每個區(qū)域部署內容 管理錨點，實現(xiàn)該區(qū)域內容的定位以及跨區(qū)域的資源管理，通過基于前綴的分區(qū)域管理實 現(xiàn)海量內容尋址過程的靈活高效，通過DNS及其擴展協(xié)議(包括DNSSEC和DANE等）實現(xiàn)內 容的可信尋址，并提出了各種可能場景下的動態(tài)內容源管理機制。該方法兼容了內容中心 網絡基于逐跳的內容獲取方式，可以保證內容獲取的效率；并可以緩解前綴聚合帶來的巨 大開銷和時延，保證內容中心網絡的可擴展性；同時，通過"基于DNS維護CMA信息+基于 CMA維護內容信息"的兩步模式保證了內容信息維護的穩(wěn)定性。該方法很好地結合了當前 互聯(lián)網的既有基礎設施，提供了一種能支撐未來海量業(yè)務的數(shù)據(jù)管理模型，特別是未來CCN 在移動互聯(lián)網中部署時，能夠有效地支持動態(tài)的內容管理。

【專利附圖】

【附圖說明】
[0042] 圖1是本發(fā)明的內容管理模型的網絡架構示意圖。
[0043] 圖2是實施例中內容請求流程圖。
[0044] 圖3是實施例中內容傳輸流程圖。
[0045] 圖4是實施例中基于DNS及其擴展協(xié)議的可信尋址架構示意圖。
[0046] 圖5是實施例中源節(jié)點移動性管理機制示意圖。
[0047] 圖6是實施例中接收者和內容源之間不同跳數(shù)的開銷曲線圖。

【具體實施方式】
[0048] 下面通過具體實施例和附圖，對本發(fā)明做進一步說明。
[0049] 本發(fā)明基于區(qū)域的內容管理可以保證未來海量數(shù)據(jù)管理的可擴展性，每個區(qū)域部 署內容管理錨點（Content Management Anchor, CMA)，負責對該區(qū)域源內容的位置信息以及 漫游源節(jié)點的相關信息進行維護。圖1是本實施例的內容管理模型的網絡架構示意圖，如 該圖所示，內容管理錨點（CMA)部署在內容中心網絡的每一個內容前綴區(qū)域中，作為一個 內容區(qū)域的管理節(jié)點，用于維護內容及其對應源節(jié)點位置的信息；DNS服務器遵循當前互 聯(lián)網中DNS的層次體系連接關系，用于維護內容前綴及其對應的內容管理錨點位置的對應 信息；CCN路由器，部署在內容中心網絡中，可以基于內容名字進行路由，并具有緩存功能 和其它擴展的相關的功能；內容接收裝置（Receiver)，部署在終端用戶處，用于請求并接 收所需內容；內容提供裝置（Provider)，是內容的源，用于提供內容。
[0050] CMA及其所轄內容信息注冊在DNS中，以如下方式維護：
[0051] Content-Prefix-A/AAAA-TTL--IP-〇f-CMA
[0052] 其中Content-Prefix是該區(qū)域的內容前綴，A/AAAA標識A記錄（IPv4)或AAAA記 錄（IPv6)，TTL為該記錄的生存時間，由于該生存時間決定了中間路由器對于此信息的緩 存時間，所以應根據(jù)內容的動態(tài)特征進行適應性配置，ΙΡ-of-CM標識負責維護該前綴對應 內容及其源節(jié)點地址的信息。
[0053] -方面，這種管理模型兼容內容中心網絡基于逐跳的內容獲取方式，可以保證內 容獲取的效率；另一方面，這種方式可以緩解前綴聚合帶來的巨大開銷和時延，保證內容中 心網絡的可擴展性，并通過"基于DNS維護CMA信息+基于CMA維護內容信息"的兩步模式 保證內容信息維護的穩(wěn)定性。
[0054] 基于上述模型，本發(fā)明擬對基本的CCN通信機理進行如下改造，Interest數(shù)據(jù)包 的發(fā)送范圍通過跳數(shù)限制變量進行控制，本發(fā)明設該跳數(shù)限制變量為Hop-limit。每個中間 路由器在接收到Interest數(shù)據(jù)包時首先將該Hop-limit減1，如果Hop-limit為0,表示在 規(guī)定范圍內未能找到對應的內容。為了減少洪泛造成的巨大開銷，該路由器通過DNS查詢 該內容名字的前綴信息，從而獲取到CMA地址信息，然后經過對CMA的查詢，得到信息源的 當前位置信息，進而獲取所需內容，內容請求流程和內容處理流程分別如圖2和圖3所示。
[0055] 如圖2所示，對內容請求流程描述如下：
[0056] 1)當路由器接收到用戶發(fā)出的Interest數(shù)據(jù)包時，首先對其進行緩存（CS)匹配： 如果緩存中有對應的內容，直接將對應內容發(fā)回請求到達的接口，然后丟棄該Interest數(shù) 據(jù)包；
[0057] 2)如果緩存中沒有對應內容，則進行PIT的匹配，如果有匹配的條目，路由器將該 請求到達的接口添加到該內容請求的接口列表，然后丟棄該Interest數(shù)據(jù)包；
[0058] 3)如果PIT中沒有匹配的條目，則查看是否有匹配的FIB，如果有匹配的條目，則 創(chuàng)建新的PIT條目，然后將數(shù)據(jù)包中的Hop-limit遞減1。如果Hop-limit值為0,路由器發(fā) 起DNS查詢，向DNS查詢該內容前綴對應的CMA ;如果沒有匹配的FIB，路由器則直接向DNS 查詢；
[0059] 4)如果Hop-limit不為0,路由器按照匹配的FIB發(fā)送Interest數(shù)據(jù)包。
[0060] 如圖3所示，對內容處理流程描述如下：
[0061] 1)當路由器接收到Data數(shù)據(jù)包（即內容數(shù)據(jù)包）時，查看是否有改名字對應的 TLSA記錄，如果有，則利用TLSA對Data中的秘鑰信息進行驗證，如果驗證不通過，則直接丟 棄該內容數(shù)據(jù)包；
[0062] 2)如果驗證通過，路由器查詢緩存中是否有匹配的條目，如果有，則丟棄該數(shù)據(jù) 包，表示收到了重復的數(shù)據(jù)包；
[0063] 3)如果緩存中沒有匹配的內容，路由器檢查是否有匹配的PIT，如果有匹配的 PIT，說明這是之前被請求的內容，路由器首先將該內容添加到緩存中，然后在對應PIT條 目的接口列表中刪除該內容的到達接口（正常情況下內容不應該從請求的接口到達)。如果 此時的PIT條目接口列表為空，則丟棄該內容，并刪除該PIT條目；
[0064] 4)如果PIT條目的接口列表不為空，路由器對該內容進行驗證，如果通過驗證，則 將內容轉發(fā)到剩下的pit接口列表。
[0065] 本發(fā)明方法中，路由器首先通過TLSA資源記錄驗證該內容名字的有效性，以此來 驗證該名字在請求過程中未經篡改，對于該名字對應的內容，路由器通過公鑰信息對其進 行驗證，保證數(shù)據(jù)在傳輸過程中未經篡改。圖4所示為本發(fā)明的內容尋址過程中建立的完 整信任鏈。如圖4所示，數(shù)據(jù)內容的安全保證是通過所有者的私鑰簽名提供，內容和名字之 間的安全性是通過DNSSEC保證(這樣路由器在找到該內容名字對應的所有者時，可以確信 所獲取的信息是安全可信的)，而名字和驗證內容安全性的公鑰之間的可信關系通過DANE 建立。
[0066] 在傳統(tǒng)內容中心網絡中，源節(jié)點的地址變更會造成嚴重的前綴聚合開銷，使得該 機制無法在實際中支持源節(jié)點的移動。為此，本發(fā)明基于上述內容管理模型提出圖5所示 的源節(jié)點移動性支持協(xié)議。圖5中，其中AR為接入路由器（Access Router)，為移動源的接 入路由器，如內容源最初連接在AR1，當其切換到AR2后，首先向該區(qū)域的CMA進行位置注冊 (步驟1)，當CM2發(fā)現(xiàn)這個內容不屬于自己管轄區(qū)域時，向其對應區(qū)域的CMA卿CMA1)進 行位置更新(步驟2)，從而使CAM1知道這個內容現(xiàn)在已經移動到了 CMA2管轄的區(qū)域。當內 容源繼續(xù)移動到AR3時，重復上述步驟，首先向該區(qū)域的CMA (即CM3)進行位置注冊(步驟 3)，而CM3向CMA1更新內容源的位置(步驟4)。
[0067] 由于在一個前綴區(qū)域內管理名字信息的操作類似于DNS的名字解析服務，因此， CMA的部署可以借鑒于DNS權威服務器，這也在一定程度上保證了內容中心網絡中名字管 理服務的可靠性。此外，源節(jié)點移動過程中，可以通過各種類型的DNS資源記錄進行資源定 位，而DNS的動態(tài)更新機制可以用于支持資源記錄位置變更，這也在一定程度上借助DNS這 一操作系統(tǒng)普遍支持協(xié)議促進內容中心網絡的平滑演進。
[0068] 首先，本發(fā)明通過分析內容中心網絡中內容源移動的含義，將擬研究的問題分為 如下三類：
[0069] 1)內容名字變更、內容位置未變更
[0070] 內容本身所處物理位置沒有變更，但可能由于其域內的組織關系發(fā)生了變更，所 以可能造成內容的名字發(fā)生變化，如：
[0071] /sina/nba/rocket/20120213. avi 變更為 /sina/sport/nba/rocket/20120213· avi
[0072] 這種概念上的源移動可以通過CMA維護一條名字等效記錄(如CNAME)支持。
[0073] /sina/sport/nba/rocket/20120213. avi CNAME/sina/nba/rocket/20120213. avi
[0074] 2)內容名字未變更、內容位置變更
[0075] 當節(jié)點在本地區(qū)域發(fā)生位置變更時，直接通過DNS Update通告該區(qū)域的CMA，從而 使CMA更新其A或AAAA記錄。
[0076] 3)內容名字變更、內容位置變更
[0077] 當源節(jié)點移動到別的前綴區(qū)域時，首先需要向該區(qū)域的CMA進行通告，從而獲得 有效的位置和前綴屬性(如圖5中步驟1，3)，如：
[0078] /sina/nba/rocket/20120213. avi 變更為 /sohu/nba/rocket/20120213. avi
[0079] 目標區(qū)域的CMA在接收到該節(jié)點的通告時，通過CMA之間的安全通信鏈路進行該 節(jié)點的位置更新，從而使源前綴區(qū)域的CMA建立一條名字等效記錄(如DNAME)支持(如圖4 中步驟2, 4)。
[0080] /sina/sport/nba/rocket/20120213. avi DNAME/sohu/nba/rocket/20120213. avi
[0081] 下面提供采用本發(fā)明方法得到的實驗結果。如果網絡中接收者和內容源之間的平 均跳數(shù)為N，假設基本CCN情況下，接收者發(fā)出的Interest希望在Η(假設為Hop-limit)跳 內得到相應，那么就要求源節(jié)點在移動之后在新的位置重新進行內容廣播，且至少廣播跳 數(shù)為（N-H)。而在本發(fā)明所提方案中，源節(jié)點僅需要進行CMA的更新，那么兩者之間的開銷 如圖6所示。
[0082] 圖6中，假設網絡中節(jié)點數(shù)量為100, N為10,每一跳的信令處理開銷為1，DNS更 新開銷為1〇(假設DNS服務器和源節(jié)點之間的距離為最大值10)。.由此可見，本發(fā)明能夠 很好地支持源節(jié)點的頻繁移動，保證了 CCN在源移動場景下的可擴展性。
[〇〇83] 以上實施例僅用以說明本發(fā)明的技術方案而非對其進行限制，本領域的普通技術 人員可以對本發(fā)明的技術方案進行修改或者等同替換，而不脫離本發(fā)明的精神和范圍，本 發(fā)明的保護范圍應以權利要求所述為準。
【權利要求】
1. 一種基于DNS及其擴展協(xié)議的CCN可信尋址方法，其步驟包括： 1) 在內容中心網絡的每個區(qū)域部署內容管理錨點，負責對該區(qū)域源內容的位置信息以 及漫游源節(jié)點的相關信息進行維護，并基于各區(qū)域的內容前綴將所述內容管理錨點注冊在 DNS 中； 2) 通過內容中心網絡中的逐跳尋址方式以及集中式的DNS尋址方式進行尋址，通過 DNSSEC協(xié)議建立完整信任鏈以提供名字解析過程中的安全保證，通過DANE協(xié)議提供公鑰 信息驗證，實現(xiàn)對內容的可信驗證并最終獲取所需內容。
2. 如權利要求1所述的方法，其特征在于：所述內容管理錨點及其所轄內容信息以如 下方式維護： Content-Prefix-A/AAAA-TTL-IP-〇f-CMA, 其中，Content-Prefix是該區(qū)域的內容前綴，A/AAAA標識A記錄或AAAA記錄，TTL為該 記錄的生存時間，ΙΡ-of-CM標識負責維護該前綴對應內容及其源節(jié)點地址的信息。
3. 如權利要求1或2所述的方法，其特征在于interest數(shù)據(jù)包的發(fā)送范圍通過跳數(shù) 限制變量進行控制。
4. 如權利要求3所述的方法，其特征在于：每個中間路由器在接收到Interest數(shù)據(jù)包 時首先將所述跳數(shù)限制變量減1，如果跳數(shù)限制變量為〇則表示在規(guī)定范圍內未能找到對 應的內容；該路由器通過DNS查詢該內容名字的前綴信息，從而獲取內容管理錨點的地址 信息，然后經過對內容管理錨點的查詢得到信息源的當前位置信息，進而獲取所需內容。
5. 如權利要求1所述的方法，其特征在于：路由器通過TLSA資源記錄驗證內容名字的 有效性，驗證該名字在請求過程中未經篡改，并通過公鑰信息對該名字對應的內容進行驗 證，保證數(shù)據(jù)在傳輸過程中未經篡改。
6. 如權利要求1所述的方法，其特征在于：通過所有者的私鑰簽名保證數(shù)據(jù)內容的安 全性，通過DNSSEC保證內容和名字之間的安全性，通過DANE建立名字和驗證內容安全性的 公鑰之間的可信關系。
7. 如權利要求1所述的方法，其特征在于：通過所述內容管理錨點支持源節(jié)點的移動， 具體方法為：設內容源最初連接在區(qū)域1內的接入路由器1，該區(qū)域1內設有內容管理錨點 1，當內容源切換到區(qū)域2內的接入路由器2后，首先向該區(qū)域2的內容管理錨點2進行位 置注冊，當內容管理錨點2發(fā)現(xiàn)這個內容不屬于自己管轄區(qū)域時，向其對應的區(qū)域1的內容 管理錨點1進行位置更新，從而使內容管理錨點1知道該內容已經移動至內容管理錨點2 管轄的區(qū)域；當內容源繼續(xù)移動到新的內容管理錨點時，重復上述步驟。
8. 如權利要求7所述的方法，其特征在于：在源節(jié)點移動過程中，通過各種類型的DNS 資源記錄進行資源定位，通過DNS的動態(tài)更新機制支持資源記錄位置變更。
9. 一種采用權利要求1所述方法的基于DNS及其擴展協(xié)議的CCN可信尋址系統(tǒng)，采用 內容中心網絡，其特征在于，包括： 內容管理錨點，部署在內容中心網絡的每一個內容前綴區(qū)域中，作為一個內容區(qū)域的 管理節(jié)點，用于維護內容及其對應源節(jié)點位置的信息； DNS服務器，遵循當前互聯(lián)網中DNS層次體系連接關系，用于維護內容前綴及其對應的 內容管理錨點位置的對應信息； CCN路由器，部署在內容中心網絡中，用于基于內容名字進行路由，并具有緩存功能和 相關的擴展功能； 內容接收裝置，部署在終端用戶處，用于請求并接收所需內容； 內容提供裝置，是內容的源，用于提供內容。
10.如權利要求9所述的系統(tǒng)，其特征在于：還包括接入路由器，設置在所述內容中心 網絡的每個區(qū)域內，用于提供移動源的無線接入。
【文檔編號】H04L29/06GK104065760SQ201310607141
【公開日】2014年9月24日 申請日期:2013年11月25日 優(yōu)先權日:2013年11月25日
【發(fā)明者】延志偉, 李曉東 申請人:中國科學院計算機網絡信息中心