This document proposes a backward-compatible extension to CCNx that unifies content delivery and publish/subscribe event notifications by using the same forwarding tables. It describes how content requests and notifications can both use multiple spanning trees and fan-out limits for forwarding. An experimental evaluation shows that the unified approach outperforms using separate mechanisms for content delivery and notifications in terms of overhead and performance. The proposal concludes that an information-centric network should natively support both on-demand content retrieval and publish/subscribe notifications using a shared infrastructure.
CCNxCon2012: Session 5: Steaming up CCN against TCP
CCNx Extension for Improved Support for Notifications and Content-Based Addresses
1. A Backward-Compatible CCNx Extension for Improved Support
for Notifications and Content-Based Addresses
Antonio Carzaniga Michele Papalini Alexander L. Wolf
University of Lugano, Switzerland University of Lugano, Switzerland Imperial College London, United Kindom
antonio.carzaniga@usi.ch michele.papalini@usi.ch a.wolf@imperial.ac.uk
Objective
We have argued that an Information-Centric Network should natively support publish/subscribe event notification in addition to
on-demand content delivery. Both primitives could use the same forwarding information base. Here we propose a backward-
compatible CCNx extension that implements such a unified ICN.
A Unified Content-Based Network Layer Routing Scheme
On-demand Content Delivery Publish/Subscribe Event Notifciation
prefix/1 prefix/1
forwarding forwarding a b c a b c
producer consumer producer consumer
tables tables
subscribe
register(prefixes) notification: (prefix)
interest:name name +
content d e f g h d e f g h
data:content
prefix/2 prefix/2
long-lived information transient information
pull push i j k i j k
prefix/1 T1 prefix/2 prefix/1 T2 prefix/2
request/reply one way message
anycast multicast router f: prefix → tree T, next-hop list
Unified Content-Based Network Layer (FIB) prefix/1 → T1 , {b}
→ T2 , {e}
forwarding prefix/2 → T1 , {b, k}
Node A tables Node B
→ T2 , {e, k}
register(predicate)
notification:name
+ content We propose a routing scheme based on multiple spanning
trees. Each message has a field that specifies which tree is
interest:name
reply:content
to be used to forward the message. The message also
shared forwarding information specifies a fan-out limit that specifies the maximum number
symmetric structure of times a message is duplicated during forwarding.
On-Demand Content Delivery Pub/Sub Notification Experimental Evaluation
prefix/1 sub/news File transfer: CCNx’s getfile application
a b c a router f: prefix
b → T, next
c
interest:id=11,“/prefix/2”,
tree=2,fan-out=1,src=g,. . .
(FIB) sub/news → T1 , {j, b} Notification: two implementations on the
→ T2 , {g, e}
basic CCN:
sub/news
g Polling
d e f h d e f g h
prefix/2 sub/news producer consumer
register(news/ )
i j k i j k interest:news/
prefix/1 prefix/2 interest:news/
sub/news
interest:news/
prefix/1 data:news/0
sub/news
a b c a b c
Interests as Notifications
data:id=11,“/prefix/2”,dst=g,. . .
producer consumer
sub/news
d e f g h d e f g h register(prod-1/news/ )
prefix/2 sub/news register(news/ )
interest:news/prod-1/0
notification:id=9,“sub/news”,
tree=2,fan-out=∞,. . . interest:prod-1/news/0
router k: node j→ next
i k i j k data:prod-1/news/0
(Unicast)
prefix/1 g → f prefix/2 sub/news
File Transfer Notification
80 25 100 180 25
CCNx CCNx CCNx+polling CCNx+polling CCNx+polling
70 Unified Unified CCNx+interest 160 CCNx+interest CCNx+interest
Missed / Duplicated [%]
Table Entries [x1000]
PITs Entries [x1000]
20 Unified 140 Unified 20 Unified
60 50
Packets [x1000]
Packets [x1000]
120
50 15 15
100
40 0
80
30 10 10
60
20 -50 40
5 5
10 20
0 0 -100 0 0
F1 F4 PIT1 CACHE1 PIT4 CACHE4 L1 L4 M1 M4 H1 H4 L1 L4 M1 M4 H1 H4 L1 L4 M1 M4 H1 H4
Conclusion Future Work
• An ICN should and could natively provide publish/subscribe • Optimize the use of multiple trees in order to reduce the stretch
event notification service and maximize the throughput
• The two communication method share the same forwarding • Study the scalability of the proposed architecture
information and can be synergistic