1. PURSUIT Architecture From Ideas over an Approach to Design to an Architecture and Its Choices Dirk Trossen, Computer Laboratory 1

2. Space of ICN The Breadth of the Challenge 2 Ideas Design Approaches Architectures Design Choices

3. Space of ICN The Coverage of PURSUIT 3 Ideas Design Approach Architectures Design Choices

4. Take the Input… Operating on Information (structures) Late binding (to location) Pub/sub service model Incorporate computation & storage Increased optimization potential Reflexive vs. Reflective Better alignment of interests 4 A new way to design systems

5. …Borrow From Meta-Reasoning… Different timeframes for operations (and their optimization) –But possibly through the same approach for design? Attention Filter Reflective Processes Reflexive Processes Measure React Threshold-based Trigger Ignore Operational Problem 5

6. …And Turn It All Into A Vision! Provides an improved impedance match between net & svc/apps –Better aligned with today’s application concepts Provides tussle delineation of crucial functions –Better suited for future (unknown) business models Enables optimized sub-architectures –Better suited for variety of access technologies Provides high performance Scales to the needs of the Future Internet Envision a system that dynamically adapts to evolving concerns and needs of their participating users 6

7. Starting Point: Solving Problems in Distributed Systems One wants to solve a problem, each of which might require solving another problem –Examples: Send data from A to B(s), involving fragmentation along the link(s) Disseminate a video over a local network Problems involve “a collection of information that” an implementation “can use to decide what to do”, which is to implement a problem solution (*) -> Computation in distributed systems is all about information dissemination (pertaining to a task at hand) *S. J. Russell, P. Norvig, “Artificial Intelligence: A Modern Approach”, 2nd Edition, Pearson Educ., 1998 7

8. Turning into Design Principles… Everything is Information –Higher-level information semantics are constructed as graphs of information Information is scoped –Provide a simple mechanism for structuring data and limiting the reachability of information to the parties having access to the particular mechanism that implements the scoping Functionality is scoped –Functions to disseminate information implement a scoped strategy! Scoped information neutrality –Within each scope of information, data is only forwarded based on the given (scoped) identifier Ensure balance of power –No entity is provided with data unless it has agreed to receive those beforehand 8

9. …Translated onto Invariants (Across Architectures) Flat-label referencing: identify anything as information Scoping: group information and functions (including scopes themselves) Pub/sub service model: anything is delivered by pub/sub Separation of functions: each scope provides functions for finding (rendezvous), constructing (topology) and delivering (forwarding) –Can be implemented jointly for optimization reasons Dissemination strategy per scope: the implementation of the functions is described by a dissemination per scope –Inherited by each sub-scope 9

10. Information-Centrism is Key Information is everything and everything is information Scopes build information networks Notion of metadata by linking to other identifiers –Policy is metadata Producers and consumers need no internetwork-level addressing! FatherFriendSpouseColleague Scope Family Scope Company A Data: Picture Data: Mail Governance policy Scope Friends Governance policy Governance policy 10

11. Operating on Graphs of Information SId 1 SId 2 SId 1 SId 2 SId 3 RId 1 RId 2 RId 3 RId 1 RId 2 RId 3 RId 4 RId 3 256 bit data e.g., P:L Statistically unique within its scope – although global uniqueness can be defined through dissemination strategy 11

12. Information Semantics: Immutable vs. Mutable Items Documents –Each RId points to immutable data (e.g., document version) –Not well suited for real-time type of traffic –Each item is identifiable throughout the network Channel –Each RId points to channel of data (e.g., a video stream), i.e., the data is mutable –Well-suited for video type of traffic –Problems with caching though (since no individual video segments visible) 12

13. Information Semantics: Algorithmic Identification Idea: Use an algorithm to tie together a set of data items Allow for data items to be addressed individually through algorithmically generated RIds Allow for addressing collection through algorithm (and its seed) Example: reliable fragmentation Thought exercise: algorithmic scoping! Access ‘channel’ via seed RId, go to segment via alg(seed) Publish alg as metadata to seed -> Channel implicitly visible to network, together with individual segment RIds, by virtue of alg as implicit channel Id, alg being app- specific alg(seed) Segment determined via RId = alg(seed), e.g., alg = seqNo

14. Put Together: A Functional Model For Solving Problems Each scope implements the solution to a problem The architecture is concerned with facilitating the exchange of information for the problem solution! Think object-oriented! Functional and information scoping is achieved here! Strategies are represented through standards, running code etc! Strategies can be represented as explicit representations Semantic Web technologies help here Functions need not to be strongly separated Example: link-local dissemination! RendezvousTopology Forwarding Pub/Sub Service Model SId RId Functional scoping Information scoping Dissemination Strategy Recursion 14

15. An E2E Principle… The problem in question can be implemented through an assembly of sub-problem solutions, whose individual dissemination strategies are not in conflict with the ones set out by the problem in question. Hence, problems are assembled to larger solutions by recursively applying the scoping invariant of the functional model! Conflicts are avoided through design and re-design, e.g., via standards procedures! Can extend this to runtime reconciliation! NOTE: I leave it as a thought exercise to relate this to the IP E2E principle! 15

16. Core Functions vs. Problem Solutions Core functions –Rendezvous, topology management and forwarding Finding, constructing a delivery graph and delivering along this graph Problem solutions –Low-level: anything from reliability over retransmissions to fragmentation but also management problems (e.g., link state collection) –High-level: anything from complex information space (say video collection) to individual items and their delivery (say a single video) 16

17. Where is the Boundary? Example: Reliability 1.Realize as part of (core) forwarding function –Becomes part of dissemination strategy 2.Realize as individual problem solution over given forwarding function(s) –Can be realized over many strategies Best Current Practice here: Minimality and flexibility Favors option 2 since –it keeps individual dissemination strategies (and their realization) minimal –Allows for different reliability solutions over a single strategy BUT: it does not prohibit option 1! 17

18. Put Together in A High- Level Architecture RP: Rendezvous point ITF: Inter-domain topology formation TM: Topology management FN: Forwarding node ITF Topology RP Rendezvous Network Network Architecture Service Model Helper Error Ctrl … Fragmentation Caching TM Forwarding Network Forwarding Network Forwarding Network Forwarding Network FN pub sub Apps Node Architecture 18

19. Realizing Our Architecture Apply the design approach (i.e., functional model and E2E principle) across the various level of the architecture –Node/Link-local as well as global realizations Implement the core functions at these various levels –Rendezvous, topology, forwarding Add specific appropriate network-level problem solutions –Reliability, fragmentation, … Two Areas highlighted in the following: domain-local forwarding & mobility 19

20. Conclusions PURSUIT is not (only) about architecture – it is about a new way to design systems Concise foundation in a functional model approach allows for this new design Core for this approach is information required for a computational problem in a holistic view Architectures are enabled by a (possibly differing) choice of solutions –That includes architectures like DONA, CCN, even IP! Working on particular choices ourselves though –More to come in later presentations 20

21. A Subset of the Larger Team Cambridge: George Parisis, Ben Tagger AUEB: George Xylomenos, Christos Tsilopoulos, Xenofon Vasilakos, Alex Kostopoulos CERTH: Paris Pflegkas, Vasilis Sourlas Aalto: Kari Visala, Pasi Sarolahti, Sasu Tarkoma, Dmijtri Lagutin, Arto Karila NSN: Jarno Rajahalme RWTH: Janne Riihijarvi, Borislava Gajic Ericsson: Petri Jokela, Andras Zahemsky, Jimmy Kjallman (and Pekka Nikander, of course) CTVC: Stuart Porter, Martin Long MIT: Karen Sollins, David Clark ISI: John Wroclawski, Steve Schwab