PURSUIT ArchitectureFrom Ideas over an Approach to Design to an Architecture and Its Choices

Dirk Trossen, Computer Laboratory

1

Spa

ce o

f IC

N

The Breadth of the Challenge

2

Ideas

DesignApproaches

Architectures

Design Choices

Spa

ce o

f IC

N

The Coverage of PURSUIT

3

Ideas

DesignApproach

Architectures

Design Choices

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

…Borrow From Meta-Reasoning…

• Different timeframes for operations (and their optimization)– But possibly through the same approach for design?

Attention Filter

ReflectiveProcesses

ReflexiveProcesses

Me

asu

reReact

Threshold-based

Trigger

Igno

reOperational Problem

5

…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

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

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

…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

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! Father FriendSpouse Colleague

Scope Family

Scope Company A

Data: Picture

Data: Mail

Governancepolicy

Scope FriendsGovernance

policy

Governancepolicy

10

Operating on Graphs of Information

SId1 SId2

SId1 SId1 SId2

SId3

RId1 RId2 RId3

RId1 RId2 RId3RId4

RId3

256 bit data

e.g., P:LStatistically unique withinits scope – although globaluniqueness can be definedthrough dissemination strategy

11

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

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 determinedvia RId = alg(seed), e.g., alg = seqNo

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!

Rendezvous Topology

Forwarding

Pub/Sub Service Model

SId

RId RId

Functional scopingInformation scoping

DisseminationStrategy

Recursion

14

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

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

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

Put Together in A High-Level Architecture

RP : Rendezvous pointITF : Inter-domain topology formationTM : Topology managementFN : Forwarding node

ITFITF

Topology

RPRP

Rendezvous

RendezvousNetwork

Net

wor

k A

rchi

tect

ure

Service Model

Helper

Error Ctrl

…

Fragmentation

Caching

TMTM

TM TM

Forwarding

ForwardingNetwork Forwarding

Network

ForwardingNetwork

ForwardingNetwork

FN

pubpub

pubsub

Apps

Nod

e A

rchi

tect

ure

18

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

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 presentations20

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