1 / 20

A Common ICN API A discussion starter

A Common ICN API A discussion starter. IRTF ICNRG Vancouver, Nov 2013 Börje Ohlman Alina Quereilhac. Disclaimers. This should not be regarded as a proposal. This is a thought experiments to better understand the key components of ICN APIs and interfaces

tannar
Download Presentation

A Common ICN API A discussion starter

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Common ICN API A discussion starter IRTF ICNRG Vancouver, Nov 2013 Börje Ohlman Alina Quereilhac

  2. Disclaimers • This should not be regarded as a proposal. This is a thought experiments to better understand the key components of ICN APIs and interfaces • In these slides I use CCN to represent CCN/NDN

  3. Background • ICN is now where packet networking was in the late 70’s, early 80’s • We then had SNA, OSI, DecNet, AppleTalk, IP, IPx, etc. • Some of you will remember multi-service routers… • I’m not saying that I long back to those days… ;-)

  4. Internet Mobile networks Broadcast TV/Radio Real world Application independent API for accessing any object, regardless of location P2P sensor person person person P2P App 2 App 3 App 4 App 1 P2P P2P P2P getObject(objectID) getObject(attr1, attr2, attr3) API CDN CDN CDN ICN CDN CDN

  5. Information-centric inter-networking interface (ICiNi) and ICN API ICNApp1 ICNApp1 ICNApp2 ICNApp2 ICNApp3 ICNApp3 ICN API ICN API ICN ICN ICN ICN ICiNi

  6. Information-centric inter-networking interface (ICiNi) and API ICNApp1 ICNApp2 ICNApp3 ICNApp1 ICNApp2 ICNApp3 ICN API ICN API NetInf CCN NetInf CCN ICiNi

  7. ICN API ICNApp1 ICNApp2 ICNApp3 ICNApp1 ICNApp2 ICNApp3 ICN API Common format ICN API Common format CCN NetInfadaptationlayer NetInf CCNadaptationlayer NetInf CCN Adaption layer functions • Mappings of • primitives • names • object representations Motivation • Applications can be reused, interworked and evaluated Research challenges • Define common • primitives, e.g. • PUBLISH, PUT, GET, SEARCH, … • naming format • content object representation ICiNi

  8. API and network interfaces are the same in ICN • The primitives used in the API are the same as the messages sent over network interfaces in both CCN and NetInf • CCN messages are • INTEREST • DATA • NetInf messages are • GET • RESPONSE.

  9. Requirements for a Common ICN API • The API/interface should be RESTFUL • Which seems reasonable as we are not dealing with e2e connections • This is important if we should be able to build gateways that does not get overly complex and/or gets into scalability issues • The common API needs a common naming format • One proposal could be to use the ni naming format (RFC 6920) in a way that unifies CCN and NetInf naming • the Authority part is a CCN name (if known) • the Digest Value is the NetInf name (if known)

  10. Possible Common ICN name format for the ICN API • Possible common name format • cf://[Authority part ala CCN]/[NetInf name (hash)] • CCN could include the Digest Value of the objects in the CCN name • That would ease the translations • Could be beneficial for CCN • could be used as a hash value when doing cache and PIT lookups.

  11. Information-centric inter-networking interface (ICiNi) ICNApp1 ICNApp2 ICNApp3 ICNApp1 ICNApp2 ICNApp3 CCN NetInf ICN API ICN API NetInf CCN • Motivation • Unlikely there will be only one ICN network protocol (at least initially) • Give us understanding of what are the critical issues for ICN inter-networking • Research challenges • Define inter-networking protocol • Mapping of names ICiNi

  12. Topology Common App Common App NetInf CCN 1 1 9 NetInf CCN 2 CCN 8 NetInf Gateway (a) Gateway CCN 3 10 4 CCN 5 Common App NetInf 11 Gateway (b) Common App NetInf CCN NetInf 13 7 CCN 12 6 CCN Common App Common App 14 publisher CCN CCN 15 16 replica

  13. Content object representation, metadata ICNApp1 ICNApp2 ICNApp3 ICNApp1 ICNApp2 ICNApp3 CCN NetInf CCN ICN API ICN API NetInf CCN CCN Object?? • Content objects retrieved through the API should be understood by the destination ICN implementation regardless of where it comes from • Possibilities: • Define common content object format • Keep all native ICN formats ICiNi

  14. Common object format • The ICN API should be capable of constructing/parsing content objects with common format • Still, a way of deciding whether a ‘common format object’ or a ‘native object’ should be sent back is needed ICNApp1 ICNApp2 ICNApp3 ICN API CCN CCN NetInf Request tag:common Send CCN or common format? ICiNi

  15. Information-centric inter-networking interface (ICiNi) – using common object store ICNApp1 ICNApp2 ICNApp3 ICNApp1 ICNApp2 ICNApp3 ICN API Common format ICN API Common format CCN NetInfadaptationlayer NetInf CCNadaptationlayer NetInf CCN • Motivation • Having one common (virtual) object store avoids n2 problem • Research challenges • Common name and object format for the common store NetInfadaptationlayer CCNadaptationlayer Common object store(ICiNi)

  16. Conclusions • The basic CCN/CCN and NetInf APIs have strong similarities • The new ICN API will look very different from today’s socket API • We should try to define it in a way that can be stable over a long time and allow for evolution of the underlying ICN approach(s) • Potentially there are three common things that could be defined • Common API primitives • Common Naming format • Common Object/Transfer format, especially for metadata • There more things we need to define, among them: • How would routing work? • How would pub/sub work? • What about Search and Attribute requests?

  17. Backup slides

  18. NetInf use of a Common ICN API • A NetInf node receiving a CCN name • Ask NRS for a locator to where it can send a GET/HTTP request to reach the publisher (in this case a CCN gateway or directly to the CCN publisher) of the requested object • The  CCN gateway or publisher could then either return the object directly or calculate a Digest Value to be sent back to the NetInf node that then could make a new request and possibly find the object in a NetInf cache.

  19. CCN use of a Common ICN API • A CCN node receiving a NetInf name • Merge the Authority part (which in these scenarios would have to be mandatory) and the Digest Value into a CCN name • Forward an interest with that name towards what should be a NetInf gateway which easily could reconstruct the NetInf name • Find the object in the NetInf part of the network and return it • Possible name formats • /[Authority part]/[NetInf name] • Used for direct routing in the CCN network • /netinf/[Authority part]/[NetInf name] • Used to find a NetInf GW

  20. NDO Structure SHA-256 Hash (Base64) ni:///sha-256;B_K97zTtFuOhug27fke4_Z… Object Name multipart/mixed Objectin Message application/json Object management data Named data object multipart/mixed application/steam-meta+xml Application-specific meta data SHA-256hash coverage application/binary Actual object bits RFC 6920: Naming Things with Hashes

More Related