1. © 2006 BBN Technologies 1SPINDLE Project Intentional Naming and Deferred Binding in DTN Prithwish Basu BBN Technologies pbasu@bbn.com DTNRG meeting, IETF 71 Philadelphia, March 13, 2008

2. © 2006 BBN Technologies 2SPINDLE Project Outline Intentional naming Persistent deferred binding in DTN Example: Addressing by location and role DARPA DTN demonstration

3. © 2006 BBN Technologies 3SPINDLE Project Intentional Naming A DTN application registers with its attributes User node addresses an endpoint by a predicate on some attributes = intentional destination name Intentional name needs to get resolved to the appropriate application(s) now or in future –Delivery to an intentionally named endpoint ~ querying a distributed database –Name has persistent delivery semantics Related work –MIT’s INS, but our focus is on DTN –Berkeley’s P2 system (Declarative Routing)

4. © 2006 BBN Technologies 4SPINDLE Project Examples of Use Cases Heterogeneous network names –DNS name, IP addr, telephone number, etc. –Source can send bundle to “Node with IPv6 address A” Descriptive location and role based addressing –Node(s) within 100m of bridge at (Lat,Long) –All soldiers with rank lieutenant or higher in building B Authorization based addressing –All personnel with Top Secret clearance Node-attribute based addressing –All nodes with at least 100GB of free storage –Sensor nodes reporting temperature > 45 degrees C

5. © 2006 BBN Technologies 5SPINDLE Project Expressivity of Names How expressive should names be? –Basic: aliases –Intermediate: (a1 > v1)  ((a2 < v2)  (a3 == v3)) –Advanced: Body of a Horn clause in Logic Programs –Semantic Web motivation: OWL Description Logic Programs –Query models: SQL queries, PROLOG goals, SPARQL, etc. Delivery Semantics –Unicast: dtn:intent:uni#president(BBN) –Anycast: dtn:intent:any#within(restaurant,FenwayPark,1km) –Multicast: dtn:intent:all#within(restaurant,FenwayPark,1km)

6. © 2006 BBN Technologies 6SPINDLE Project Name Scheme Adhere to the : syntax but define “ssp” further Applications register their attribute(value) information –dtn:app#attr1(val1),attr2(val3),attr3(val3) Bundle’s destination field has an intentional name –dtn:intent#attr1(val1),attr2(val2) –dtn:intent#attr1(val1);attr1(val2) –dtn:intent#pred1(attr1(val1),attr3(val3)) –… Semantics: DTN endpoint(s) which can satisfy the query are potential recipients of the bundle The predicate query can be complex as long as it can be executed in the network at the appropriate node

7. © 2006 BBN Technologies 7SPINDLE Project Name Resolution and Persistent Deferred Binding Complete resolution may not be possible at source –Source may not know about potential bound endpoint(s) –Source may have stale information Hence, perform progressive resolution –Resolve portion of the name that can be resolved with available information in the local KB –This may not disclose the identity of ultimate endpoint(s) –But may forward the bundle toward a node that can help make progress (so ultimate binding is deferred) –Persistent: a query can lie dormant in a node until the predicate evaluates to true at a later time (can happen in mobile scenarios) In the general form, this is the semi-join problem in distributed DBs and is hard, especially in DTN –But several scenarios may be more tractable

8. © 2006 BBN Technologies 8SPINDLE Project dtn:intent#within(role_id(yellow),coord(X,Y),10) (X,Y) r = 10 GRAIN: Gradient-based Resolution Algorithm for Intentional Names Disseminate GPS location to neighbors S Geog-route STEM stage only coord(X,Y) is resolved Metadata Ext Block = STEM Predicate-scoped FLOOD role_id(yellow) is resolved Metadata Ext Block = FLOOD Persistent deferred delivery to descriptively named groups under disruption & mobility

9. © 2006 BBN Technologies 9SPINDLE Project Example: Intentional Names Based on Role and Geographic Attributes Fort A P Hill, Virginia source Destination = dtn:intent#within(role_id(rifleman),coord(long,lat),radius),policy(geogrouteallnbrs)

10. © 2006 BBN Technologies 10SPINDLE Project Notional Architecture: Name Attribute Dissemination

11. © 2006 BBN Technologies 11SPINDLE Project Notional Architecture: Resolution

12. © 2006 BBN Technologies 12SPINDLE Project Architectural and Algorithmic Issues Scalability for the general case –Semi-join problem in DTNs becomes hard as #attrs grows Incremental Deployment –All DTN nodes may not be running LB decision plane –We need tunneling with Bundle-in-Bundle encapsulation, because the original bundle fields such as intentional name cannot be altered Security concerns –DOS attack due to multi/anycast feature of names –Made worse due to persistence –Verify that the name resolution was done by a trusted party

13. © 2006 BBN Technologies 13SPINDLE Project BACKUPS

14. © 2006 BBN Technologies 14SPINDLE Project Semi-Join Problem in Distributed DBs Consider name dtn:intent#guardian(N,X),student(X,bostonlatin) –N is the main unbound variable = canonical name attribute –Want to deliver to guardians of all students of Boston Latin Tables/predicates: guardian, student –Could be base facts: guardian(tom,john), student(john,bostonlatin) –Or inference rules: guardian(X,Y) :- father(X,Y) ; mother(X,Y) Even if rules/ontologies are known, all base facts may not reside on the same node –… so the goal can be evaluated at a resolver only by performing a semi-join on the tables guardian and student This is hard to do in the general case, especially in DTN –So we need techniques for synchronizing fact bases for increasing the probability of successful resolutions

15. © 2006 BBN Technologies 15SPINDLE Project Expressive Overlap of Description Logic with Logic Programs Extracted from Grosof et al., WWWC 2003 “Description logic programs: combining logic programs with description logic” First Order Logic Description Logic Horn Logic Programs Description Logic Programs Logic Programs [Negation as Failure] [Procedural Attachments]