盧倚霞，王道勝，張國強(qiáng)

南京師范大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，江蘇 南京 210023

引言

當(dāng)前互聯(lián)網(wǎng)的應(yīng)用模式已經(jīng)從發(fā)送者驅(qū)動(dòng)的點(diǎn)對(duì)點(diǎn)通信為主轉(zhuǎn)向以接收者驅(qū)動(dòng)的大規(guī)模信息獲取為主[1]，例如：網(wǎng)絡(luò)新聞、網(wǎng)絡(luò)視頻、網(wǎng)絡(luò)游戲等。在這一應(yīng)用模式中，用戶通常并不關(guān)心誰發(fā)布了這些信息，以及這些信息位于何處，而僅僅關(guān)注信息本身。為解決現(xiàn)有 IP 體系架構(gòu)下，這類應(yīng)用造成的流量爆炸問題，可以從以下幾個(gè)方面著手考慮：

(1) 以內(nèi)容為中心，分離節(jié)點(diǎn)位置和節(jié)點(diǎn)標(biāo)識(shí)。IP 地址語義過載[2]是當(dāng)前互聯(lián)網(wǎng)體系架構(gòu)的主要問題，在當(dāng)前的TCP/IP 協(xié)議中 IP 地址既是節(jié)點(diǎn)的唯一標(biāo)識(shí)，又指示了節(jié)點(diǎn)的拓?fù)湮恢谩Ｒ虼藭?huì)帶來移動(dòng)性、可擴(kuò)展性、安全性等方面的問題。而內(nèi)容中心網(wǎng)絡(luò)體系結(jié)構(gòu)順應(yīng)了當(dāng)前網(wǎng)絡(luò)應(yīng)用模式的轉(zhuǎn)變，以內(nèi)容為中心，實(shí)現(xiàn)了點(diǎn)對(duì)面的內(nèi)容獲取。

(2) 引入發(fā)布/訂閱通信模式，實(shí)現(xiàn)內(nèi)容接收者和內(nèi)容發(fā)布者之間的解耦。發(fā)布/訂閱模型[3]的最主要優(yōu)點(diǎn)是信息生產(chǎn)者和消費(fèi)者之間的松耦合。在空間上，信息生成者和信息消費(fèi)者都不需要彼此是誰，在什么位置。在時(shí)間上，生產(chǎn)者和消費(fèi)者不需要同時(shí)在運(yùn)行狀態(tài)。在控制流上，生產(chǎn)者在發(fā)出消息后，并不阻塞以等待消費(fèi)者的處理，消費(fèi)者也不阻塞以等待消息，而是在消息到來時(shí)自動(dòng)被通知。

(3) 利用 IPv6 組播技術(shù)，保證相同報(bào)文在同一鏈路只被傳輸一次?，F(xiàn)有的網(wǎng)絡(luò)新聞、網(wǎng)絡(luò)視頻類應(yīng)用大多利用端到端的單播通信，重復(fù)傳輸相同的內(nèi)容，網(wǎng)絡(luò)資源利用率低下。為此可以考慮使用組播技術(shù)避免網(wǎng)絡(luò)資源的浪費(fèi)、減少網(wǎng)絡(luò)擁塞。IPv6增加了增強(qiáng)的組播 (Multicast) 支持[4]并且其 128 位的IP 地址編址方案，可以徹底解決 IPv4 中組播地址匱乏的問題。

本文圍繞以上三點(diǎn)展開，在 CCN 中融入發(fā)布/訂閱功能，并研究融入發(fā)布/定義功能的CCN 網(wǎng)絡(luò)與IPv6 網(wǎng)絡(luò)的互通問題，將 CCN 網(wǎng)絡(luò)部署在 IPv6 網(wǎng)絡(luò)邊緣，在 IPv6 網(wǎng)絡(luò)中使用 IPv6 的組播能力提高鏈路資源利用率。

1 相關(guān)工作

CCN[5–7]是美國 Jacobson 教授于 2009年提出的以內(nèi)容為中心的網(wǎng)絡(luò)系統(tǒng)架構(gòu)，是支持當(dāng)前最廣泛使用的網(wǎng)絡(luò)應(yīng)用——內(nèi)容分享。CCN 借助轉(zhuǎn)發(fā)引擎中的CS (Content Store)、PIT (Pending Interest Table) 和FIB (Forwarding Interest Table) 結(jié)構(gòu)實(shí)現(xiàn)內(nèi)容的緩存，數(shù)據(jù)和請求的轉(zhuǎn)發(fā)。同時(shí) CCN/NDN 中添加了兩種新的包結(jié)構(gòu)：請求興趣包 (interest packet) 和數(shù)據(jù)包 (data packet)。

發(fā)布/訂閱通信模型是實(shí)現(xiàn)系統(tǒng)中各個(gè)參與者以發(fā)布/訂閱方式進(jìn)行交互的中間件結(jié)構(gòu)[8][9]。在該模型中，內(nèi)容生產(chǎn)者者和內(nèi)容消費(fèi)者無需直接建立聯(lián)系，而是通過創(chuàng)建中間件系統(tǒng)，作為其互通的媒介。內(nèi)容生成者不需要知道存在哪些內(nèi)容消費(fèi)者，只需要把內(nèi)容轉(zhuǎn)交給中間件系統(tǒng)，再由中間件系統(tǒng)與內(nèi)容消費(fèi)者進(jìn)行交互，將內(nèi)容直接或間接的交付給內(nèi)容消費(fèi)者。

組播[10][11]可以允許一個(gè)或多個(gè)發(fā)送者發(fā)送同一數(shù)據(jù)到多個(gè)接收者，多個(gè)接收者組成了所謂的組播組。當(dāng)發(fā)送者將數(shù)據(jù)包發(fā)送到某一組播組時(shí)，只有屬于該組播組的成員才能收到數(shù)據(jù)包。組播技術(shù)可以保證無論該組播組中又多少成員，在網(wǎng)絡(luò)中的任一鏈路上，該數(shù)據(jù)報(bào)文只被傳輸一次。因此在有多個(gè)接收者的網(wǎng)絡(luò)應(yīng)用中，組播技術(shù)可以提高數(shù)據(jù)的傳送效率，有效利用帶寬，降低主干網(wǎng)絡(luò)出現(xiàn)擁塞的可能性。組播技術(shù)是 IPv6 的一個(gè)重要組成部分，IPv6 協(xié)議中要求所有網(wǎng)絡(luò)設(shè)備都必須支持組播能力。

2 基于 CCN 的發(fā)布/訂閱網(wǎng)絡(luò)與 IPv6 網(wǎng)絡(luò)融合設(shè)計(jì)

為實(shí)現(xiàn) CCN 網(wǎng)絡(luò)中的發(fā)布/訂閱功能，首先，需要引入面向語義的內(nèi)容描述符 (Content Description，CD)[12]、訂閱報(bào)文和數(shù)據(jù)報(bào)文。解決 Interest 和 Data是一一對(duì)應(yīng)的的關(guān)系；其次，需要在內(nèi)容生產(chǎn)者 (亦稱發(fā)布者) 和內(nèi)容消費(fèi)者 (亦稱訂閱者) 之間引入?yún)R聚點(diǎn) (Rendezvous Node，RN)，從而實(shí)現(xiàn)發(fā)布者和訂閱者之間的解耦；最后，為了維護(hù)訂閱者和發(fā)布者之間的訂閱關(guān)系，需要構(gòu)建訂閱表訂閱表(Subscription Table，ST)，以組播的方式分發(fā)內(nèi)容，提高網(wǎng)絡(luò)資源利用率。

為了實(shí)現(xiàn) CCN 網(wǎng)絡(luò)與 IPv6 網(wǎng)絡(luò)的融合部署，本文將基于 CCN 的發(fā)布/訂閱網(wǎng)絡(luò)部署在 IPv6 網(wǎng)絡(luò)邊緣。在網(wǎng)絡(luò)中引入邊緣節(jié)點(diǎn) (Edge Node，EN)。CCN網(wǎng)絡(luò)和 IPv6 網(wǎng)絡(luò)通過入口 EN 和出口 EN 相連，其中入口 EN 負(fù)責(zé)將 CCN 網(wǎng)絡(luò)的訂閱報(bào)文轉(zhuǎn)換為 IPv6 UDP 報(bào)文和將 IPv6 UDP 報(bào)文轉(zhuǎn)換為 CCN 發(fā)布報(bào)文，出口 EN 負(fù)責(zé)將 IPv6 CCN 發(fā)布報(bào)文轉(zhuǎn)換為 IPv6 UDP 報(bào)文和將 IPv6 UDP 報(bào)文轉(zhuǎn)換為訂閱報(bào)文。同時(shí)在 IPv6 網(wǎng)絡(luò)中使用 IPv6 組播技術(shù)。

2.1 匯聚節(jié)點(diǎn)

引入 RN 的目的是實(shí)現(xiàn)發(fā)布者和訂閱者之間的解耦，以及內(nèi)容的實(shí)時(shí)推送能力。為實(shí)現(xiàn)上述功能，一個(gè)完備的RN 應(yīng)具備以下特征：

(1) 匯聚節(jié)點(diǎn)標(biāo)識(shí)唯一且可達(dá)。每一個(gè)匯聚節(jié)點(diǎn)具有一個(gè)唯一的標(biāo)識(shí)符/rendezvous/ID，并且匯聚節(jié)點(diǎn)的路由信息被注入到轉(zhuǎn)發(fā)表(Forwarding Table，F(xiàn)IB)中，對(duì)網(wǎng)絡(luò)中的其他節(jié)點(diǎn)可達(dá)。

(2) 匯聚節(jié)點(diǎn)維護(hù)面向語義的訂閱關(guān)系，解耦發(fā)布者和訂閱者。匯聚節(jié)點(diǎn)接收多個(gè)發(fā)布者的發(fā)布消息，并將其轉(zhuǎn)發(fā)給多個(gè)感興趣的訂閱者，為實(shí)現(xiàn)這一功能，匯聚節(jié)點(diǎn)中應(yīng)維護(hù)面向內(nèi)容語義的訂閱關(guān)系。

本文通過修改 CCN 的轉(zhuǎn)發(fā)引擎中的FIB 結(jié)構(gòu)，實(shí)現(xiàn) RN 的全局路由可達(dá)。FIB 中存儲(chǔ)的是當(dāng)前節(jié)點(diǎn)沿最短路徑到達(dá) RN 的下一跳，其結(jié)構(gòu)為：RNID|Face。其中 RNID 為 RN 的唯一標(biāo)識(shí)，F(xiàn)ace 為出接口。如圖1 所示，RN 位匯聚節(jié)點(diǎn)，其標(biāo)識(shí)符為Rendezvous/01。對(duì)于普通路由節(jié)點(diǎn) R4 而言，通過 2號(hào)端口，可以將報(bào)文沿最短路徑轉(zhuǎn)發(fā)到匯聚節(jié)點(diǎn)，因此在其 FIB 表中添加條目 Rendezvous/01|2。網(wǎng)絡(luò)中的每個(gè)路由節(jié)點(diǎn)按該方式在 FIB 中添加到達(dá) RN 節(jié)點(diǎn)的最短路徑信息。

圖1 FIB 結(jié)構(gòu)示意圖Fig.1 FIB structure

2.2 面向語義的內(nèi)容描述符

CCN 采用層次化的命名方式來命名內(nèi)容，Interest 和 Data 之間是一對(duì)一的關(guān)系，但是基于 CCN的發(fā)布/訂閱系統(tǒng)要求在訂閱報(bào)文 (Subscribe) 和發(fā)布報(bào)文 (Publish) 之間是一對(duì)多映射。為滿足這一需求，本文引入 CD 的概念。CD 是一種用戶可讀的命名層次化命名結(jié)構(gòu)，采用層次化命名方式的優(yōu)勢在于可以有效實(shí)現(xiàn) Subscribe 的抑制。

如圖2 所示，當(dāng)路由節(jié)點(diǎn) Router 的兩個(gè)端口分別收到 CD1=/sports/football/china 和 CD2=/sports/football 的Subscribe 時(shí)，則表示在未來的時(shí)間里，Subscriber1 希望收到所有 CD 為 /sports/football/china的Data，而 Subscriber2 希望收到所有 CD 為 /sports/football 的Data。為滿足 Subscriber1 和 Subscriber2 的用戶需求，顯然 Router 需要收到所有 CD 為 /sports/football 的Data。因此，Router 收到 Subscriber1和 Subscriber2 的Subscribe 時(shí)，由于 CD1=/sports/football/china 是 CD2=/sports/football 的自己，所以Router 抑制 Subscriber2 的訂閱消息，而只向上游節(jié)點(diǎn)轉(zhuǎn)發(fā) Subscriber1 的訂閱消息。利用分層 CD 之間的子集包含關(guān)系，可以有效降低系統(tǒng)中 Subscribe 數(shù)量，降低網(wǎng)絡(luò)負(fù)載。

2.3 訂閱表設(shè)計(jì)

為維護(hù)發(fā)布者和訂閱者之間的訂閱關(guān)系，實(shí)現(xiàn)發(fā)布者訂閱者解耦以及內(nèi)容的時(shí)候推送。本文在CCN 轉(zhuǎn)發(fā)引擎中添加了一個(gè)額外的數(shù)據(jù)結(jié)構(gòu)——ST 用于維護(hù)每個(gè)端口下游的訂閱者。ST 的結(jié)構(gòu)為:Face|CDList，其中 Face 為路由節(jié)點(diǎn)的端口，CDList為該端口收到的訂閱消息中 CD 集合。在 0 中，Sub1和 Sub2 的訂閱消息在轉(zhuǎn)發(fā)的過程中，會(huì)在 R1、R2和 RN 節(jié)點(diǎn)中建立如圖3 所示訂閱表。

圖2 CD 抑制訂閱消息Fig.2 CD suppress subscribe messaging

表1 R1、R2 和 RN 訂閱表結(jié)構(gòu)Table 1 Subscription form structure of R1, R2 and RN

圖3 訂閱表結(jié)構(gòu)示意圖Fig.3 Subscription form structure

在面向 CCN 的發(fā)布/訂閱系中，數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā)過程通過與 ST 表項(xiàng)中每個(gè)端口維護(hù)的CD 集合做精確匹配或前綴匹配實(shí)現(xiàn)。這意味著對(duì)于每一個(gè) CD 為/Prefix1/Prefix2/.../PrefixK 的Data 消息而言，在確定該 Data 消息是否向某一端口轉(zhuǎn)發(fā)時(shí)，需要將該端口中的每一項(xiàng)，與集合 F={/Prefix1, /Prefix1/Prefix2, ..., /Pre fi x1/Prefix2/.../PrefixK} 中的每一項(xiàng)進(jìn)行對(duì)比，直到集合 F 中的某一項(xiàng)與接口中的某一項(xiàng)精確匹配。設(shè)端口維護(hù)的CD List 的大小為 N，集合 F 的大小為 K，則需要 O(NK) 次比較。為了加速數(shù)據(jù)的轉(zhuǎn)發(fā)速率，本文在上述的ST 表結(jié)構(gòu)中添加一個(gè)計(jì)數(shù)布隆過濾器[13]，即 Face|CDList| 計(jì)數(shù)布隆過濾器。

布隆過濾器 (Bloom Filter，BF) 由布隆 (Burton Howard Bloom) 在 1970年提出的。它由一個(gè)長度為 m的二進(jìn)制向量和 k個(gè)值域?yàn)?[0, m] 的隨機(jī)映射函數(shù)組成，可用于檢索一個(gè)元素是否在一個(gè)集合中。其基本原理是：用 k個(gè)值域?yàn)?[0, m] 的哈希函數(shù)對(duì)數(shù)據(jù)集合S 中的每個(gè)數(shù)據(jù)計(jì)算一個(gè)位序列 (h1, h2, ……h(huán)k)，然后設(shè)二進(jìn)制向量中對(duì)應(yīng)位序列的位置值為 1。要查詢某元素在集合中是否存在時(shí)，只需使用 k個(gè)映射函數(shù)將該元素映射到二進(jìn)制向量中，若二進(jìn)制向量中每一位都為 1，則元素存在，否則元素不存在。CBF 由 BF擴(kuò)展而來，主要解決 BF 無法進(jìn)行刪除操作的問題。CBF 將 BF 中二進(jìn)制向量擴(kuò)展為一個(gè)計(jì)數(shù)器數(shù)組。

以二進(jìn)制向量和計(jì)數(shù)器數(shù)組的長度為 16，集合 S=｛x，y，z｝，3個(gè)哈希函數(shù)對(duì)集合 S 中的元素計(jì)算出的位序列為 x={2，7，15}，y={4，7，11}，z={0，1，7} 為例，在 BF 和 CBF 下的映射結(jié)果分別為圖4 所示。

借用 CBF 判斷元素是否存在的思想，為加快數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā)，只需將端口的CDList 用一個(gè)長度為m，哈希函數(shù)個(gè)數(shù)為 k 的計(jì)數(shù)布隆過濾器數(shù)組描述。當(dāng)一個(gè) CD 為 /Prefix1/Prefix2/.../PrefixK 的Data 到達(dá)路由節(jié)點(diǎn)時(shí)，為決定向哪些端口轉(zhuǎn)發(fā)，路由節(jié)點(diǎn)首先構(gòu)造該內(nèi)容描述符的前綴集合 (包含其自身) F={/Prefix1,/Prefix1/Prefix2, ..., /Prefix1/Prefix2/.../PrefixK}，然后將 F 中的每一項(xiàng)，依次映射到 CDList 對(duì)應(yīng)的布隆過濾器數(shù)組中。如果 F 中存在某一項(xiàng)映射到 CDList 的布隆過濾器中時(shí)，k個(gè)哈希函數(shù)對(duì)應(yīng)的計(jì)數(shù)器值均不為 0，則向該端口轉(zhuǎn)發(fā) Data。同樣，如果維護(hù)的CDList 的大小為 N，F(xiàn) 集合的大小為 K，隨機(jī)映射函數(shù)的個(gè)數(shù)為 k，計(jì)數(shù)布隆過濾器數(shù)組的長度為 m，則需要的比較次數(shù)為 O (Kk)。與直接使用基于 CD 的前綴匹配 O(NK) 相比，k 為哈希函數(shù)的個(gè)數(shù)，而 N 為CD 表項(xiàng)的個(gè)數(shù)。明顯 k 的數(shù)量遠(yuǎn)遠(yuǎn)小于 N，所以使用布隆過濾器進(jìn)行 Data 報(bào)文的轉(zhuǎn)發(fā)處理效率遠(yuǎn)遠(yuǎn)高于直接基于變長的內(nèi)容描述符進(jìn)行匹配。

圖4 BF 與 CBF 對(duì)照圖Fig.4 Comparison between BF and CBF

2.4 邊緣節(jié)點(diǎn)

CCN 網(wǎng)絡(luò)和 IPv6 網(wǎng)絡(luò)通過EN實(shí)現(xiàn)面向內(nèi)容的接口和面向 IPv6 地址接口的轉(zhuǎn)換實(shí)現(xiàn)這一功能。為實(shí)現(xiàn) EN 節(jié)點(diǎn)面向內(nèi)容網(wǎng)絡(luò)接口與面向 IPv6 接口間的轉(zhuǎn)換，需要添加一個(gè)新的數(shù)據(jù)結(jié)構(gòu)——內(nèi)容描述符-IPv6組播地址映射表(CD-IPv6 Mapping Table，CD-v6T)。CD-v6T 用于維護(hù) EN 為 CD 分配的組播地址，其結(jié)構(gòu)為：CD|Multicast IPv6，其中 CD 為內(nèi)容描述符，IPv6 為與該 CD 對(duì)應(yīng)的IPv6 組播地址。

如圖5(a) 所示，Subscriber1 和 Subscriber2 都訂閱了 /sports/football。當(dāng)訂閱消息到達(dá)各自的邊緣節(jié)點(diǎn) EN2 和 EN3 后，邊緣節(jié)點(diǎn)將訂閱消息封裝為 IPv6組播地址請求消息。假設(shè) Sub1 的組播地址先到達(dá)發(fā)布者網(wǎng)絡(luò)的邊緣節(jié)點(diǎn) EN1，則 EN1 節(jié)點(diǎn)查詢 CD-v6T。此時(shí) CD-v6T 為空，于是 EN1 為 /sports/football分配組播地址 FF0E::1，并將組播地址封裝到 IPv6 的組播地址應(yīng)答消息中返回給邊緣節(jié)點(diǎn) EN2 后，將組播地址請求消息解封裝為訂閱消息向匯聚節(jié)點(diǎn) RN 轉(zhuǎn)發(fā)。當(dāng) EN1 收到 EN3 的組播地址請求消息后，查詢CD-v6T 發(fā)現(xiàn)已經(jīng)為 /sports/football 分配組播地址，則直接將該組播地址 FF0E::1 返回給 EN3 后，將組播地址請求消息解封裝為訂閱消息向匯聚節(jié)點(diǎn) RN 轉(zhuǎn)發(fā)。EN2 和 EN3 接收組播地址應(yīng)答消息后，分別加入這兩個(gè)組播組。

如圖5(b) 所示，當(dāng) Publisher1 發(fā)布 CD 為 /sports/football 的發(fā)布消息時(shí)，該發(fā)布消息首先被路由到匯聚節(jié)點(diǎn) RN，RN 收到該發(fā)布消息后，將其解封裝為數(shù)據(jù)報(bào)文，并查詢 ST 向邊緣節(jié)點(diǎn) EN1 轉(zhuǎn)發(fā)。EN1 收到該數(shù)據(jù)報(bào)文后，查詢 CD-v6T，獲取為 /sports/football分配的組播地址 FF0E::1，于是 EN1 將數(shù)據(jù)報(bào)文封裝到組播地址為 FF0E::1 的MultiData 報(bào)文中，該報(bào)文會(huì)根據(jù)之前建立的組播生成樹，分別被發(fā)送到 EN2 和EN3。EN2 和 EN3 接收 MultiData 后，解封裝為 Data報(bào)文，查詢 ST，分別向 Subscriber1 和 Subscriber2 轉(zhuǎn)發(fā)。

圖5 基于發(fā)布/訂閱模式的CCN 網(wǎng)絡(luò)和 IPv6 網(wǎng)絡(luò)的融合示意圖Fig.5 Schematic integration of publish / subscribe model of the CCN network and network-based IPv6

3 基于 CCN 網(wǎng)絡(luò)的發(fā)布/訂閱系統(tǒng)與 IPv6網(wǎng)絡(luò)融合的仿真與實(shí)現(xiàn)

3.1 基于 CCN 網(wǎng)絡(luò)的發(fā)布/訂閱系統(tǒng)仿真實(shí)現(xiàn)

為驗(yàn)證基于發(fā)布/訂閱通信模型在 CCN 中實(shí)施的高性能，本文以 OMNeT++ 軟件作為仿真實(shí)驗(yàn)平臺(tái)，實(shí)現(xiàn) PS-CCN，并將該模型與原始的CCN 模型在多個(gè)性能指標(biāo)上進(jìn)行對(duì)比，證明 PS-CCN 模型在某些應(yīng)用場景下的高效性。在仿真實(shí)驗(yàn)中，本文對(duì) Amazon Co-Purchasing and Amazon Reviews 數(shù)據(jù)集做過濾處理，保留 200000 條產(chǎn)品記錄，圖6 為 PS-CCN 仿真模型中每個(gè)節(jié)點(diǎn)平均處理的Subscribe 的數(shù)量，以及CCN 仿真模型在不同的CS 下每個(gè)節(jié)點(diǎn)平均處理的Interest 的數(shù)量。仿真實(shí)驗(yàn)中 CD 的總個(gè)數(shù)為 235，每個(gè) Sub 都需要發(fā)送 235個(gè) Subscribe 消息，而部分Subscribe 會(huì)在節(jié)點(diǎn)的ST 表中被聚合后抑制轉(zhuǎn)發(fā)。Content ID 的個(gè)數(shù)為 200000，考慮到 PIT 表超時(shí)，則每個(gè) Client 至少需要發(fā)送 200000個(gè) Interest。因此，路由節(jié)點(diǎn)處理的Interest 報(bào)文的數(shù)量是遠(yuǎn)遠(yuǎn)超過Subscribe 報(bào)文的數(shù)量的，而兩種報(bào)文的大小近似相同，所以 Interest 造成的流量負(fù)載遠(yuǎn)遠(yuǎn)超過 Subscriber造成的流量負(fù)載。

圖7 為 PS-CCN 仿真模型中每個(gè)節(jié)點(diǎn)平均處理的Publish 的數(shù)量，以及 CCN 仿真模型在不同的CS 下每個(gè)節(jié)點(diǎn)平均處理的Data 的數(shù)量。在 PS-CCN 仿真模型中，發(fā)布者將內(nèi)容推送給 RN，然后有 RN 查詢ST，利用類似組播的方式推送給每一個(gè)訂閱者，這就保證了同一個(gè) Data 報(bào)文在每個(gè)路由節(jié)點(diǎn)只被處理了一次。而在 CCN 中由于 Interest 報(bào)文到達(dá)的隨機(jī)性，雖然可以保證客戶端從最近的節(jié)點(diǎn) (內(nèi)容源或路由節(jié)點(diǎn)中的緩存) 獲取到 Data，但是不能保證相同只被每個(gè)節(jié)點(diǎn)只傳輸一次。

圖6 節(jié)點(diǎn)平均 Subscribe/Interest 報(bào)文數(shù)Fig.6 Average number of subscribed/interest packets

圖7 節(jié)點(diǎn)平均 Publish/Data 報(bào)文數(shù)Fig.7 Average number of publish/data packets

表2 為 PS-CCN 仿真模型中每個(gè)節(jié)點(diǎn)平均的FIB表的大小，以及 CCN 仿真模型中每個(gè)節(jié)點(diǎn)平均的FIB 表的大小。在 PS-CCN 仿真模型中，F(xiàn)IB表中記錄的是節(jié)點(diǎn)到達(dá) RN 的下一跳，由于本實(shí)驗(yàn)拓?fù)渲?，只有一個(gè)拓?fù)涔?jié)點(diǎn)，所以每個(gè)路由節(jié)點(diǎn)中 FIB 條目的個(gè)數(shù)為 1。而在 CCN 仿真模型中，記錄的是到達(dá)某個(gè) Content ID 的下一跳，所以需要將所有記錄的路徑記錄在 FIB 表中，即與記錄數(shù)相等為 200000。

通過對(duì)上述三個(gè)指標(biāo)的衡量，不難發(fā)現(xiàn)在某些場景下，使用 PS-CCN 仿真模型無論在流量負(fù)載還是在內(nèi)存使用率上都會(huì)遠(yuǎn)遠(yuǎn)優(yōu)于 CCN 仿真模型。

3.2 基于 CCN 網(wǎng)絡(luò)的發(fā)布/訂閱系統(tǒng)與 IPv6 融合系統(tǒng)原型實(shí)現(xiàn)

為進(jìn)一步驗(yàn)證 PS-CCN 網(wǎng)絡(luò)與 IPv6 網(wǎng)絡(luò)融合部署的可行性，本文在 IPv6 網(wǎng)絡(luò)上以 OverLay 的方式實(shí)現(xiàn)上述原型系統(tǒng)。系統(tǒng)原型的整體架構(gòu)如圖8 所示。

其中各類節(jié)點(diǎn)的邏輯功能在前面的章節(jié)中已經(jīng)做出了敘述，這里的系統(tǒng)實(shí)現(xiàn)，主要是通信模型的實(shí)現(xiàn)。通信模型包括兩個(gè)轉(zhuǎn)發(fā)層，一個(gè)是邏輯轉(zhuǎn)發(fā)層，該轉(zhuǎn)發(fā)層面向 PS-CCN 網(wǎng)絡(luò)，為上層應(yīng)用提供面向內(nèi)容的發(fā)布/訂閱能力。另一個(gè)為物理轉(zhuǎn)發(fā)層，該轉(zhuǎn)發(fā)層與底層的IPv6 網(wǎng)絡(luò)相關(guān)，實(shí)現(xiàn) PS-CCN 中的報(bào)文在底層網(wǎng)絡(luò)中的交付。

系統(tǒng)的邏輯轉(zhuǎn)發(fā)層負(fù)責(zé)與總控節(jié)點(diǎn)交互完成路由信息的配置。在節(jié)點(diǎn)啟動(dòng)過程中，每個(gè)節(jié)點(diǎn)需要向總控節(jié)點(diǎn)發(fā)送注冊的信息包括： 該節(jié)點(diǎn)的角色類型和該節(jié)點(diǎn)的IPv6 地址。總控節(jié)點(diǎn)收集到所有節(jié)點(diǎn)的注冊信息后，解析網(wǎng)絡(luò)拓?fù)湮募?，?jì)算網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，生成 PS-CCN 路由表和 IPv6 鄰接表下發(fā)給各個(gè)節(jié)點(diǎn)。各個(gè)節(jié)點(diǎn)利用下發(fā)信息實(shí)現(xiàn)基于內(nèi)容中心網(wǎng)絡(luò)的路由到基于 IP 地址的路由的映射。總控節(jié)點(diǎn)與各類節(jié)點(diǎn)的交互過程如圖9 所示。

表2 節(jié)點(diǎn)的平均 FIB 條目Table 2 Average FBI entry for the node

圖8 PS-CCN 系統(tǒng)整體架構(gòu)Fig.8 PS-CCN overall system architecture

物理轉(zhuǎn)發(fā)層負(fù)責(zé)在 IPv6 網(wǎng)絡(luò)上構(gòu)建適用于 PSCCN 通信的網(wǎng)絡(luò)接口，完成報(bào)文在 IPv6 網(wǎng)絡(luò)中的發(fā)送與接收工作。每個(gè)節(jié)點(diǎn)的物理轉(zhuǎn)發(fā)層由報(bào)文接收器和報(bào)文發(fā)送器兩部分組成。其中，報(bào)文接收器負(fù)責(zé)接收 IPv6 的組播或單播報(bào)文，將其解封裝后，交給上層的PS-CCN 網(wǎng)絡(luò)。而報(bào)文發(fā)送器負(fù)責(zé)將上層 PSCCN 網(wǎng)絡(luò)交付的報(bào)文使用 IPv6 socket 套接字封裝到IPv6 UDP 報(bào)文中發(fā)送到指定的目的主機(jī)或特定的組播組。圖10 為 PS-CCN 系統(tǒng)的物理轉(zhuǎn)發(fā)層。

4 結(jié)束語

本文提出一種基于發(fā)布/定義模式，實(shí)現(xiàn)數(shù)據(jù)高效轉(zhuǎn)發(fā) CCN 網(wǎng)絡(luò)模型。該模型實(shí)現(xiàn)了發(fā)布者與訂閱者之間的解耦，允許訂閱者基于內(nèi)容語義進(jìn)行內(nèi)容的訂閱，具有良好的可擴(kuò)展性。另外為了驗(yàn)證該網(wǎng)絡(luò)模型的可行性，本文在 IPv6 網(wǎng)絡(luò)之上以 OverLay 的方式將上述 CCN 網(wǎng)絡(luò)模型分別部署在多個(gè)通過 IPv6 網(wǎng)絡(luò)互聯(lián)的邊緣，在 IPv6 核心網(wǎng)段中，使用 IPV6 組播技術(shù)，保證報(bào)文在相同的鏈路上只被傳輸一次有效減小網(wǎng)絡(luò)負(fù)載。但是，目前該系統(tǒng)還不能夠支持訂閱者的移動(dòng)，以及掉線訂閱者重新上線時(shí)接收錯(cuò)失的數(shù)據(jù)消息等問題。

圖9 總控節(jié)點(diǎn)與各類節(jié)點(diǎn)交互過程Fig.9 Interaction process between Master control node and various types of nodes

圖10 PS-CCN 物理轉(zhuǎn)發(fā)層Fig.10 PS-CCN physical forwarding layer