馮 飛 韓毅剛 傅秋宇 武淑艷

(天津市光電傳感器與傳感網(wǎng)絡技術重點實驗室南開大學電子信息與光學工程學院 天津 300350)

?

基于以太網(wǎng)的CCN路由節(jié)點實現(xiàn)

馮 飛 韓毅剛 傅秋宇 武淑艷

(天津市光電傳感器與傳感網(wǎng)絡技術重點實驗室南開大學電子信息與光學工程學院 天津 300350)

針對目前內容中心網(wǎng)絡CCN(Content-Centric Networking)僅有基于覆蓋網(wǎng)實現(xiàn)的現(xiàn)狀，提出一種CCN網(wǎng)絡基于以太網(wǎng)實現(xiàn)的方案。該方案將CCN在協(xié)議棧中的位置下移至以太網(wǎng)MAC層之上，直接將CCN數(shù)據(jù)包封裝在以太網(wǎng)幀中傳輸，從而擺脫IP網(wǎng)絡體系結構的限制，充分發(fā)揮CCN網(wǎng)絡在設計上的優(yōu)勢。基于這一方案，在Linux平臺上設計和實現(xiàn)CCN路由節(jié)點的基本功能，并利用該路由軟件進行CCN網(wǎng)絡的實際部署，成功地實現(xiàn)了CCN網(wǎng)絡環(huán)境下的文件傳輸。

內容中心網(wǎng)絡 底層實現(xiàn) 路由節(jié)點 以太網(wǎng)

0 引 言

隨著互聯(lián)網(wǎng)應用的不斷增長及應用方式的轉變，傳統(tǒng)的IP網(wǎng)絡在內容分發(fā)、安全性、可擴展性等方面面臨嚴峻挑戰(zhàn)[1]。盡管P2P、CDN等改良技術已逐漸被運用到實際的網(wǎng)絡部署中，也取得了一定的效果。但是由于TCP/IP協(xié)議本質上的缺陷，無法從根本上解決互聯(lián)網(wǎng)的資源利用問題[2]。因此，國內外很多研究機構致力于探索設計全新的未來網(wǎng)絡來取代IP網(wǎng)絡，以解決當前互聯(lián)網(wǎng)的主要問題。其中，內容中心網(wǎng)絡CCN[3]是目前國際上研究較多的一種體系結構，其核心思路是采用名字路由，用對數(shù)據(jù)命名代替對物理主機的命名，從而使網(wǎng)絡上數(shù)據(jù)的傳輸不再依賴終端位置，在時間和空間上解耦信息的發(fā)布者和接收者。

目前，CCN已經(jīng)有了原型實現(xiàn)的支持，就是PARC(Palo Alto Research Center)公司研發(fā)的CCNx項目[4]。該項目為CCN設計出了一個原型系統(tǒng)，很多網(wǎng)絡研究者的工作都是基于這個開源項目設計和研究的。然而，CCNx是基于TCP/IP協(xié)議上的覆蓋網(wǎng)，基于覆蓋網(wǎng)實現(xiàn)的CCN網(wǎng)絡無法擺脫IP網(wǎng)絡本質上的缺陷，不能充分發(fā)揮CCN網(wǎng)絡設計在內容傳輸、安全性和移動性上的優(yōu)勢。因此，有必要對內容中心網(wǎng)絡進行底層實現(xiàn)，擺脫TCP/IP協(xié)議的限制，充分發(fā)揮CCN網(wǎng)絡在體系架構上的優(yōu)勢。

本文提出一種CCN網(wǎng)絡基于以太網(wǎng)實現(xiàn)的方案，該方案將CCN在協(xié)議棧中的位置下移到以太網(wǎng)MAC層之上，利用巨型幀技術直接把完整的CCN數(shù)據(jù)包封裝在以太網(wǎng)幀中傳輸。在路由節(jié)點中，網(wǎng)卡捕獲數(shù)據(jù)幀后，數(shù)據(jù)鏈路層根據(jù)以太網(wǎng)幀的類型字段過濾出CCN數(shù)據(jù)包交由上層CCN部分處理。上層協(xié)議依然遵循CCN的工作機制，但路由轉發(fā)表FIB和前向轉發(fā)表PIT所記錄的轉發(fā)接口改由物理網(wǎng)口和MAC地址組成，以解決由內容名到物理地址的轉換問題?；谶@一方案，本文通過在Linux平臺上編寫應用層的網(wǎng)絡程序，實現(xiàn)了基于以太網(wǎng)的CCN路由節(jié)點的基本功能，并利用該路由軟件在實驗室環(huán)境下實際搭建了底層實現(xiàn)的CCN網(wǎng)絡進行實驗驗證。

1 CCN工作機制

傳統(tǒng)IP網(wǎng)絡采用Host-to-Host的通信模式，在獲取內容時，總要先映射到內容所在的設備。而CCN采用全新的網(wǎng)絡體系架構，以內容的名字代替IP地址作為標識，解除了內容與其具體的存儲位置的綁定關系，使網(wǎng)絡專注于內容的發(fā)布和獲取。在CCN網(wǎng)絡中，終端設備或者路由節(jié)點可以通過發(fā)布名字前綴來聲明自己可以提供的內容，成為內容源。覆蓋網(wǎng)環(huán)境下，內容源發(fā)布的名字前綴可以借助域內、域間路由機制(域內采用OSPF協(xié)議的擴展，域間采用BGP協(xié)議的擴展)在全網(wǎng)進行傳播[5]，網(wǎng)絡節(jié)點根據(jù)收到的名字前綴(路由信息)，整合、計算出路由表，為用戶的請求提供轉發(fā)服務。另外，CCN為路由器增加了存儲的功能，可以緩存經(jīng)過的數(shù)據(jù)。對于訪問熱度較高的內容，這樣設計既節(jié)省了用戶訪問的響應時間，減輕了內容源的負載，還從整體上減少了網(wǎng)絡的流量。

CCN的數(shù)據(jù)包類型分為兩類：Interest包和Data包。二者功能不同，Interest包是請求包，Data包是響應包。內容請求方通過向網(wǎng)絡發(fā)送帶有內容名的Interest包來獲取內容(數(shù)據(jù))，內容源或緩存有該內容的路由節(jié)點收到Interest包后，將被請求的內容、內容名以及內容發(fā)布者的簽名等信息封裝成Data包，經(jīng)Interest包到達的路徑逆向發(fā)送給內容請求方。當出現(xiàn)請求內容相同且轉發(fā)路徑重疊的情況時，內容請求者可共享該請求。

CCN路由節(jié)點上有三個關鍵的數(shù)據(jù)結構完成轉發(fā):路由轉發(fā)表FIB(Forwarding Information Base)、內容緩存CS(Content Store)和前向轉發(fā)表PIT(Pending Interest Table)。FIB相當于IP網(wǎng)絡中的路由表，由路由協(xié)議自動生成，決定了Interest包的轉發(fā)出口。區(qū)別是CCN中的FIB可以提供一組出口，這樣請求可以到達不同內容源。CS負責緩存已經(jīng)轉發(fā)的Data包，以響應相同的內容請求。緩存的內容依緩存策略決定。PIT表記錄了已經(jīng)轉發(fā)但是尚未獲得響應的Interest包及其到達的接口，這樣響應的Data包可以準確地到達其請求者。

路由節(jié)點對于Interest包和Data包的處理過程如圖1、圖2所示。當一個Interest包到達時，路由器先提取Interest包中的內容名，然后在CS中進行內容名的精確匹配查找，若找到請求的內容，則響應該請求，并丟棄該Interest包；如果未在CS中找到被請求內容，則繼續(xù)在PIT中進行內容名的精確匹配查找，如果PIT中存在該內容名條目，則在條目中增加該Interest包的到達接口，并丟棄該Interest包；如果PIT中沒有該內容名條目，則在FIB中進行內容名最長前綴匹配查找，如果匹配到該內容名的前綴，則按照FIB提供的所有接口轉發(fā)該Interest包，并在PIT中記錄；如果匹配失敗，則丟棄該Interest包。當一個Data包到達時，路由器根據(jù)Data包的內容名在CS中進行精確匹配查找，如果存在，則丟棄該Data包；如果不存在，則繼續(xù)在PIT中進行精確匹配查找，如果匹配成功，則按照PIT中記錄的接口轉發(fā)，并緩存在CS中；如果匹配失敗，則丟棄該Data包。

圖1 Interest包處理過程

圖2 Data包處理過程

2 底層實現(xiàn)方案分析

CCN的底層實現(xiàn)是指將CCN在協(xié)議棧中的位置下移至以太網(wǎng)MAC層之上，取代IP協(xié)議“瘦腰”位置，使整個網(wǎng)絡真正依靠內容名字進行通信。CCN底層實現(xiàn)的協(xié)議棧結構如圖3所示。CCN原本就是為取代傳統(tǒng)的IP網(wǎng)絡而設計的，理論上來說，其依靠內容名字進行路由的機制，完全可以拋開IP協(xié)議獨立運行。但是，這需要數(shù)據(jù)鏈路層協(xié)議在相鄰節(jié)點之間建立起適合CCN數(shù)據(jù)包傳輸?shù)耐ǖ馈?/p>

應用層CCN部分以太網(wǎng)MAC層物理層

圖3 CCN底層實現(xiàn)協(xié)議棧結構

清華大學的陳震等[6]提出了一種CCN底層實現(xiàn)的方法，該方法中CCN網(wǎng)絡節(jié)點通過網(wǎng)卡和網(wǎng)線直接相連，上層運行CCNx，下層使用原始套接字與物理網(wǎng)卡綁定作為CCNx的轉發(fā)接口。以太網(wǎng)MAC層只保留成幀和校驗功能，將地址字段和類型字段都用來承載CCN數(shù)據(jù)包。這種實現(xiàn)方法相當于把協(xié)議棧壓縮為物理傳輸層、網(wǎng)絡層和應用層。但是，由于沒有MAC地址，該方法實現(xiàn)的路由節(jié)點無法與現(xiàn)有的網(wǎng)絡拓撲和網(wǎng)絡設備兼容，比如交換機、集線器等設備。而且，網(wǎng)絡節(jié)點運行期間數(shù)據(jù)鏈路上只允許傳輸CCN數(shù)據(jù)包，系統(tǒng)必須禁用TCP/IP協(xié)議棧，保證網(wǎng)絡純凈。CCN的部署不可能一蹴而就，這種實現(xiàn)方法不利于CCN的實際部署。因此，本文提出的底層實現(xiàn)方法完整地保留了以太網(wǎng)層的功能，這樣搭建的CCN網(wǎng)絡不僅適用于現(xiàn)有的網(wǎng)絡拓撲和網(wǎng)絡設備，還可以與TCP/IP協(xié)議棧兼容。

以太網(wǎng)幀中的源、目的MAC地址是通信雙方物理設備的標識?，F(xiàn)在的以太網(wǎng)大多采用星型結構，一個物理網(wǎng)口可以連接到多臺設備。所以，無論是在交換式以太網(wǎng)中還是共享式以太網(wǎng)中，通信雙方都需要通過MAC地址找到與自己連接的對端設備。在傳統(tǒng)的IP網(wǎng)絡中，網(wǎng)卡收到網(wǎng)絡層送來的IP包后，通過地址解析協(xié)議(ARP)將目的IP地址裝換為目的MAC地址，再封裝成以太網(wǎng)幀發(fā)送出去。而CCN包中只有內容名一個標識，ARP的解析方式不再適用。因此，CCN層不僅要向以太網(wǎng)層提交CCN數(shù)據(jù)包，還要提供下一跳節(jié)點的標識。

根據(jù)CCN的工作機制，Interest包根據(jù)FIB表的一組出口轉發(fā)。在CCN基于覆蓋網(wǎng)的實現(xiàn)CCNx中，需要事先手動配置鄰近路由節(jié)點的IP地址，所有的網(wǎng)絡傳輸通過TCP連接或UDP連接進行。對于CCNx來說，F(xiàn)IB表中的一組出口就是指與鄰近節(jié)點所建立的socket套接字。而在CCN的底層實現(xiàn)中，這組出口可以是物理網(wǎng)口和MAC地址的組合。由物理網(wǎng)口和MAC地址的組合可以唯一地確定一臺鄰接設備。所以在轉發(fā)Interest包時，路由節(jié)點可以依據(jù)FIB中對應的物理網(wǎng)口和MAC地址表項，將Interest包封裝成以太網(wǎng)幀發(fā)送出去。FIB表應由路由協(xié)議生成，由路由協(xié)議完成鄰接節(jié)點的探測。實驗階段也可以像CCNx一樣事先手動配置。同理，Data包的轉發(fā)依據(jù)PIT表所記錄的Interest包的到達接口，路由節(jié)點在轉發(fā)Interest包之前，要在PIT表中記錄其到達的物理網(wǎng)口以及源MAC地址，為響應的Data包提供轉發(fā)依據(jù)。

網(wǎng)卡收到以太網(wǎng)幀后，會根據(jù)幀首部的類型字段判斷荷載中的協(xié)議類型，并轉交給相應的協(xié)議棧進行處理。以太網(wǎng)標準中沒有為CCN分配類型值，在實驗階段只能臨時使用未被分配的類型值作為CCN的類型值。取Interest包的類型值為0x0601，Data包的類型值為0x0602。

另外，標準的以太網(wǎng)幀的MTU(最大傳輸單元)為1 500 B。而CCN的Data包中所傳輸?shù)膬热輭K的大小為固定的4 KB，再加上內容名、簽名等信息，遠大于標準的以太網(wǎng)幀的MTU。覆蓋網(wǎng)中通過TCP連接或者UDP連接傳輸CCN數(shù)據(jù)包時，數(shù)據(jù)包的分段對于路由節(jié)點來說是透明的。但是要將CCN數(shù)據(jù)包直接放入以太網(wǎng)幀中傳輸，則必須考慮數(shù)據(jù)包被分段傳輸?shù)那闆r。將CCN數(shù)據(jù)包按照標準以太網(wǎng)幀的MTU進行分段傳輸，必然會帶來額外的字節(jié)開銷，降低傳輸效率。而且CCN屬于未來網(wǎng)絡的范疇，在未來高速的數(shù)據(jù)傳輸中，如果還是延續(xù)這一最大幀長的限制，只會增加網(wǎng)絡設備單位時間內處理數(shù)據(jù)包的數(shù)目，由此帶來的開銷會隨著網(wǎng)絡速度的提高而愈加明顯。因此，為避免分段傳輸，可以采用巨型幀技術[7]。巨型幀就是指MTU超過1 500 B的以太網(wǎng)幀。目前很多商家的千兆網(wǎng)卡都支持巨型幀，可以通過將網(wǎng)卡的MTU修改到4 KB以上來承載CCN數(shù)據(jù)包。

圖4展示了以太網(wǎng)幀承載CCN數(shù)據(jù)包時的幀結構。除了荷載增大到了4 KB以上，其余字段類型均與以太網(wǎng)標準保持一致。這樣構造的以太網(wǎng)幀，可以在由千兆交換機組成的以太網(wǎng)中完整傳輸，實現(xiàn)相鄰節(jié)點間的數(shù)據(jù)交換。

字節(jié)7166246～4K+412前導碼幀定界符目的MAC地址源的MAC地址類型CCN數(shù)據(jù)包校驗序列結束位

圖4 承載CCN數(shù)據(jù)包的以太網(wǎng)幀

3 路由軟件的實現(xiàn)

目前IP網(wǎng)絡中的路由器多采用硬件實現(xiàn)，但是硬件路由器成本高，不容易升級擴展。對于尚處于實驗階段的CCN來說并不適合。因此，本文選擇軟件路由器的實現(xiàn)方法，通過編寫應用程序在單臺計算機上實現(xiàn)CCN路由節(jié)點的功能。路由軟件基于Linux系統(tǒng)運行，采用C語言編寫。底層部分利用SOCK_PACKET類型套接字實現(xiàn)對網(wǎng)卡數(shù)據(jù)的操作，從而繞開Linux內核的TCP/IP協(xié)議棧，直接收發(fā)封裝有CCN數(shù)據(jù)包的以太網(wǎng)幀。路由轉發(fā)部分主要實現(xiàn)了FIB、PIT和CS三個關鍵的數(shù)據(jù)結構，其中，路由表通過配置文件讀入，緩存策略采用最近最少使用算法LFU(Least Frequently Used)。

3.1 總體架構及功能描述

路由軟件的架構如圖5所示，程序的功能模塊全部在用戶空間完成，主要包括存儲器管理模塊、網(wǎng)絡接口層模塊、Interest包處理模塊、Data包處理模塊、FIB管理模塊、PIT管理模塊、CS管理模塊。

圖5 路由軟件架構

存儲器管理模塊主要負責管理網(wǎng)絡數(shù)據(jù)的存儲空間，記錄網(wǎng)絡數(shù)據(jù)的相關信息，為網(wǎng)絡數(shù)據(jù)在各模塊間的傳遞提供便利。軟件參照Linux內核網(wǎng)絡協(xié)議棧的存儲區(qū)緩存管理器skbuff設計了自己的緩存管理器結構，主要包括網(wǎng)卡設備信息、以太網(wǎng)首部結構指針和網(wǎng)絡數(shù)據(jù)的指針等。

網(wǎng)絡接口層通過對Linux內核協(xié)議棧的網(wǎng)卡數(shù)據(jù)的直接操作實現(xiàn)以太網(wǎng)幀的接收和發(fā)送。對于從網(wǎng)卡收到的CCN數(shù)據(jù)包，調用存儲器管理模塊的處理函數(shù)為其申請skbuff結構存儲，并按其類型分別放入Interest包隊列和Data包隊列等待處理。處理完畢的CCN數(shù)據(jù)包經(jīng)網(wǎng)絡接口層封裝成以太網(wǎng)幀從網(wǎng)卡發(fā)送出去。

Interest包處理模塊和Data包處理模塊按照CCN工作機制，調用FIB管理模塊、PIT管理模塊和CS管理模塊提供的接口，對于Interest包隊列和Data包隊列中的待處理CCN數(shù)據(jù)包進行轉發(fā)處理。

FIB管理模塊維護路由節(jié)點的FIB表項。由于路由表是通過配置文件手動配置的，在路由軟件啟動階段讀入路由表后，F(xiàn)IB表項在運行期間不會發(fā)生改變。因此，F(xiàn)IB管理模塊主要為Interest包處理模塊提供查找服務。

PIT管理模塊維護路由節(jié)點的PIT表項。PIT是CCN路由節(jié)點特有的結構，是其工作機制正常運轉的核心部件。當有Interest包到達時，要在PIT表中查詢是否轉發(fā)過相同請求，若Interest包成功轉發(fā)則要在PIT表中記錄請求的內容名及到達接口。當有Data包到達時，要查詢PIT表中匹配的內容名，并在轉發(fā)后將該表項刪除。因此，PIT表需支持查找、插入和刪除功能。

CS管理模塊維護路由節(jié)點的緩存功能。CS緩存的內容是已經(jīng)轉發(fā)Data包，無論是Interest包還是Data包到來，都要先在CS中進行匹配查找。當緩存即將溢出時，則需要根據(jù)緩存策略刪除已存儲的內容，以存儲新的內容。因此，CS需要支持查找、讀取、插入、替換和刪除等操作。另外，根據(jù)緩存策略的需要，還要為已緩存的內容維護被訪問的一些狀態(tài)，例如內容被訪問的頻率、上次被訪問的時間、上次被修改的時間等。

3.2 網(wǎng)絡接口層

網(wǎng)絡接口層的核心功能是實現(xiàn)封裝有CCN數(shù)據(jù)包的以太網(wǎng)幀的直接發(fā)送和接收，需要繞過Linux內核空間的TCP/IP協(xié)議棧，直接訪問數(shù)據(jù)鏈路層。Linux系統(tǒng)將基于數(shù)據(jù)鏈路層開發(fā)應用程序的接口集成在套接字中[8]。通過創(chuàng)建packet類型的套接字,應用程序可直接在數(shù)據(jù)鏈路層接收或發(fā)送未被系統(tǒng)處理的原始的數(shù)據(jù)報文。在Linux系統(tǒng)中，以下兩種方式創(chuàng)建的packet套接字可直接用于訪問數(shù)據(jù)鏈路層：

(1) PF_INET協(xié)議族中的SOCK_PACKET類型的套接字。

(2) PF_PACKET協(xié)議族中的SOCK_RAW類型的套接字。

兩種套接字的作用相同，本文選用了第一種方式。默認情況下所有網(wǎng)絡接口收到的數(shù)據(jù)報文都會被送到packet套接字，通過bind系統(tǒng)調用可以將建立的套接字與一個固定的網(wǎng)卡綁定在一起。由于路由器一般有多個網(wǎng)卡，所以要為每個網(wǎng)卡都綁定一個套接字。

在初始化階段，除了綁定網(wǎng)卡，還需要修改網(wǎng)卡的MTU適應CCN數(shù)據(jù)包的大小。Linux系統(tǒng)中可以通過ioctl()函數(shù)配置網(wǎng)絡接口的參數(shù)。目前默認的CCN內容塊的大小為4 KB，另外還有內容名、簽名等信息。所以，將MTU修改為5 KB以收發(fā)完整的CCN數(shù)據(jù)包。

路由節(jié)點運行期間，網(wǎng)卡上捕獲的數(shù)據(jù)幀都會送到綁定的套接字，網(wǎng)絡接口層需要根據(jù)以太網(wǎng)幀的類型字段過濾出CCN數(shù)據(jù)包送入響應隊列等待處理。

3.3 PIT管理模塊

PIT管理模塊為Interest包處理模塊和Data包處理模塊提供PIT表項的查找、插入和刪除功能。參考CCNx[9]的實現(xiàn)，PIT表采用了基于哈希表的實現(xiàn)，如圖6所示。PIT表的表項由內容名、指向下一表項的指針和接口集合組成。該接口集合記錄的是已轉發(fā)的Interest包的到達接口，由時間戳、到達網(wǎng)卡和源MAC地址組成。當需要轉發(fā)Data包時，先在PIT表中進行內容名匹配，然后按照匹配表項中的接口集合，調用網(wǎng)絡接口層的函數(shù)封裝成以太網(wǎng)幀從相應的網(wǎng)卡發(fā)送出去。

圖6 PIT表基于哈希表的實現(xiàn)

另外，PIT表還需要實現(xiàn)超時機制，否則Interest包的丟失將導致后續(xù)到達的相同的Interest包一直被阻塞。PIT表項中每一個接口都包含一個時間戳，記錄該Interest包被轉發(fā)的時間。當再有相同的Interest包從該接口到達時，先檢查時間戳，如果超時就重新轉發(fā)該Interest包并更新時間戳。如果未超時則作丟棄處理。超時時間的選擇應根據(jù)網(wǎng)絡狀況作出動態(tài)的調整。

3.4 FIB管理模塊

FIB管理模塊采用字典樹存儲FIB表[10]，如圖7所示。CCN的內容名由“/”隔開的任意字符串構成，例如“/CCNrouter/experiment/test.txt”。前綴匹配時，以“/”之間的字符串為單位進行匹配。在路由節(jié)點啟動階段，從配置文件中讀入路由表，路由表項包括內容名前綴和轉發(fā)接口集合，轉發(fā)接口由轉發(fā)網(wǎng)卡和目的MAC地址組成。內容名按“/”拆分存入字典樹中，在內容名存入的最后一個節(jié)點處存入轉發(fā)接口集合。

圖7 FIB表基于字典樹的實現(xiàn)

FIB表的內容名匹配是最長前綴匹配，當有Interest包需要轉發(fā)時，從根節(jié)點開始搜索，匹配到第一級內容名。若該節(jié)點的接口集合不為空則記錄，再在相應的子樹繼續(xù)搜索，匹配到第二級內容名，若該節(jié)點的接口集合不為空則更新剛剛記錄的接口集合。如此迭代下去，直到FIB表中沒有匹配的下一級內容名或內容名完全匹配。將Interest包按記錄下來的接口集合轉發(fā)出去。

3.5 CS管理模塊

CS管理模塊由哈希表和基于訪問頻率的優(yōu)先隊列組成。哈希表負責緩存中內容名的匹配查找?；谠L問頻率的優(yōu)先隊列負責在緩存區(qū)即將溢出時選出被替換的緩存數(shù)據(jù)。當Interest包到達時，先通過哈希表進行內容名匹配，匹配成功則復制內容塊直接響應請求并在優(yōu)先隊列中增加相應條目的訪問頻率。當Data包到達時，同樣先通過哈希表進行內容名匹配，匹配失敗時從優(yōu)先隊列中選取訪問頻率低的內容塊進行替換。

4 實驗驗證

為了驗證CCN底層實現(xiàn)方案的可行性，利用編寫的路由軟件進行了CCN網(wǎng)絡的實際部署，并成功地實現(xiàn)了在CCN網(wǎng)絡環(huán)境下的文件傳輸。

4.1 實驗環(huán)境搭建

實驗中利用四臺個人計算機和一臺千兆交換機搭建了一個星型網(wǎng)絡，網(wǎng)絡拓撲如圖8所示。其中節(jié)點B為路由節(jié)點，運行路由軟件，操作系統(tǒng)版本為Ubuntu Linux 14.10。路由節(jié)點配置兩塊千兆以太網(wǎng)卡，一塊為主機自帶的PCI網(wǎng)卡，型號為Realtek RTL 8168e，另一塊為擴展的USB網(wǎng)卡，型號為Realtek RTL 8153。節(jié)點A為內容源，運行響應程序，響應程序采用C語言實現(xiàn)，運行時從網(wǎng)卡偵聽封裝有Interest包的以太網(wǎng)幀，根據(jù)Interest包的內容名讀取內容文件作出響應。節(jié)點C和節(jié)點D同為內容請求終端，運行請求程序，請求程序同樣采用D語言實現(xiàn)，運行時向路由節(jié)點發(fā)送封裝有Interest包的以太網(wǎng)幀，同時從網(wǎng)卡偵聽到的Data包中讀取內容塊存儲到本地。

圖8 網(wǎng)絡拓撲

實驗開始階段，根據(jù)網(wǎng)絡拓撲，手動為路由節(jié)點配置FIB表，即將內容名和對應的轉發(fā)接口集合記錄在配置文件中，配置文件的格式如圖9所示。配置好路由表后，啟動路由節(jié)點的路由軟件和內容源節(jié)點的響應程序，等待內容請求終端發(fā)送請求即可。

#entry

name=CCNrouter/experiment/test.txt

#face

dev=etho

mac=6c3be53fb4d8

#endentry

圖9 配置文件格式

4.2 文件傳輸實驗

實驗一由節(jié)點C執(zhí)行一次文件下載操作。節(jié)點C將Interest包封裝在以太網(wǎng)幀中，經(jīng)路由節(jié)點轉發(fā)到達節(jié)點A，節(jié)點A根據(jù)Interest包中內容名及數(shù)據(jù)塊編號作出響應。最終，節(jié)點C成功從節(jié)點A獲取到大小為26.1 MB的視頻文件，傳輸速度為3.2 MB/s。圖10展示了傳輸過程的捕包結果?？梢杂^察到CCN數(shù)據(jù)包成功封裝在以太網(wǎng)幀中，類型值為0x0601的是Interest包，類型值為0x0602的是Data包。Data包的大小達到4 059 B，雖然超過了標準以太網(wǎng)幀的最大傳輸單元，但由于網(wǎng)卡的MTU被修改成了5 KB，Data包得以完整傳輸。

圖10 實際捕獲的CCN數(shù)據(jù)包

實驗二由節(jié)點C和節(jié)點D先后向A節(jié)點請求內容大小不一的視頻文件，節(jié)點C在時間上先于節(jié)點D。表1給出了兩個節(jié)點的文件下載時延對比。

表1 下載時延對比

實驗中路由節(jié)點設置了200 MB的緩存，節(jié)點C向節(jié)點A請求視頻文件時，響應的Data包被緩存在路由節(jié)點的CS結構中。當節(jié)點D再次請求相同的視頻文件時，直接從路由節(jié)點獲得了快速響應。由于內存訪問速度遠高于硬盤的訪問速度，所以節(jié)點D的下載速度較節(jié)點C有3～4倍的提升。

5 結 語

本文提出了一種基于以太網(wǎng)的CCN網(wǎng)絡底層實現(xiàn)方案。該方案直接把完整的CCN數(shù)據(jù)包封裝在以太網(wǎng)幀中傳輸，同時完整地保留了以太網(wǎng)MAC層的功能。該方案實現(xiàn)的CCN網(wǎng)絡不僅適用于現(xiàn)有的網(wǎng)絡拓撲和網(wǎng)絡設備，還可以與TCP/IP協(xié)議棧兼容。基于這一方案，本文在Linux平臺編寫應用程序實現(xiàn)了CCN路由節(jié)點的基本功能，路由軟件的底層部分利用SOCK_PACKET類型套接字實現(xiàn)對網(wǎng)卡數(shù)據(jù)的操作，繞過TCP/IP協(xié)議棧直接收發(fā)以太網(wǎng)幀；路由轉發(fā)部分主要實現(xiàn)了FIB、PIT和CS三個關鍵的數(shù)據(jù)結構。利用該路由軟件，本文在實驗室環(huán)境下實際搭建了底層實現(xiàn)的CCN網(wǎng)絡，并成功進行了文件傳輸實驗。

[1] 黃韜, 劉江, 霍如,等. 未來網(wǎng)絡體系架構研究綜述[J]. 通信學報, 2014, 35(8):184-197.

[2] Lee S W, Kim D, Ko Y B, et al. Cache capacity-aware CCN: Selective caching and cache-aware routing[C]// Global Communications Conference. IEEE, 2014:2114-2119.

[3] Jacobson V, Smetters D K, Thornton J D, et al. Networking named content[J]. Communications of the ACM, 2012, 55(1)：117-124.

[4] Project CCNx[ EB/OL]. http://www.ccnx.org/.

[5] Zhang L X, Estrin D, Burke J, et al. Named data networking (NDN) project[J]. Transportation Research Record Journal of the Transportation Research Board, 2010, 1892(1):227-234.

[6] 陳震, 陳碩, 馬戈. 內容中心網(wǎng)絡底層實現(xiàn)方法、內容中心網(wǎng)絡以及通信方法: CN, CN 103327027 A[P]. 2013.

[7] Jumbo frame[OL]. http://en.wikipedia.org/wiki/Jumbo_frame.

[8] 宋敬彬. Linux網(wǎng)絡編程[M]. 北京：清華大學出版社，2015:317-323.

[9] 陳震，曹軍威.信息中心網(wǎng)絡[M]. 北京：清華大學出版社，2013:103-122.

[10] 劉斌, 汪漪. 內容中心網(wǎng)絡中名字查找技術的研究[J]. 電信科學, 2014(9):10-17,44.

THE IMPLEMENTATION OF CCN ROUTING NODE BASED ON ETHERNET

Feng Fei Han Yigang Fu Qiuyu Wu Shuyan

(TianjinKeyLaboratoryofOptoelectronicSensorandSensingNetworkTechnology,CollegeofElectronicInformationandOpticalEngineering,NankaiUniversity,Tianjin300350,China)

According to Content-Centric Networking only have the implementation based on overlay network currently, a scheme to implement CCN based on Ethernet is proposed. In this scheme, the position of CCN in the protocol stack is moved to the top of the Ethernet MAC layer, and the CCN packet is directly encapsulated in an Ethernet frame to transport. Thus, it gets rid of the restriction of IP network, and gives full play to the advantage of the CCN network design. Based on this scheme, we design and implement the basic functions of CCN routing node on the Linux platform. With the routing software, we implement the actual deployment of CCN network, and successfully finish the file transfer experiments under CCN environment.

Content-centric networking Underlying implementation Routing node Ethernet

2016-09-20。馮飛，碩士生，主研領域：計算機網(wǎng)絡，內容中心網(wǎng)絡。韓毅剛，副教授。傅秋宇，碩士生。武淑艷，碩士生。

TP3

A

10.3969/j.issn.1000-386x.2017.07.018