CCNxCon2012: Poster Session: A Backward-Compatible CCNx Extension for Improved Support for Notifications and Content-Based Addresses

  • 351 views
Uploaded on

A Backward-Compatible CCNx Extension for Improved Support for Notifications and Content-Based Addresses …

A Backward-Compatible CCNx Extension for Improved Support for Notifications and Content-Based Addresses
Antonio Carzaniga, Michele Papalini (University of Lugano, Switzerland), Alexander L. Wolf (Imperial College London)

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
351
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 subscriberegister(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