Transcript Publish-Subscribe Internet Routing Paradigm - PSIRP - here

Introduction to
PURSUIT Architecture
From Ideas over an Approach to Design
to an Architecture and Its Choices
Dirk Trossen
University of Cambridge, Computer Laboratory
1
The Breadth of the Challenge
Space of ICN
Ideas
Design
Approaches
Architectures
Design
Choices
2
The Coverage of PURSUIT
Space of ICN
Ideas
Design
Approach
Architectures
Design
Choices
3
Take the Input…
Better alignment of interests
Operating on Information (structures)
Pub/sub service model
Late binding (to location)
Incorporate computation & storage
A new way to design systems
Increased optimization potential
Reflexive vs. Reflective
4
…Borrow From Meta-Reasoning…
Operational Problem
Reflective
Processes
Measure
Attention Filter
Reflexive
Processes
• Different timeframes for operations (and their optimization)
– But possibly through the same approach for design?
5
…And Turn It All Into A Vision!
Envision a system that dynamically adapts to evolving concerns
and needs of their participating users
•
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
6
Starting Point: Solving Problems in
Distributed Systems
• One wants to solve a problem, each of which might require
solving another problem
• 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)
– Examples:
•
•
Send data from A to B(s), involving fragmentation along the link(s)
Disseminate a video over a local network
*S. J. Russell, P. Norvig, “Artificial Intelligence: A Modern Approach”, 2nd Edition, Pearson Educ., 1998
7
Turning into Design Principles…
•
Everything is Information
–
•
Information is scoped
–
•
Functions to disseminate information implement a scoped strategy!
Scoped information neutrality
–
•
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
–
•
Higher-level information semantics are constructed as graphs of information
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
Data: Mail
Data: Picture
Governance
policy
Governance
policy
Scope Company A
Scope Family
Scope Friends
Governance
policy
• Information is
everything and
everything is
information
• Scopes build
information networks
• Notion of metadata by
linking to other
identifiers
– Policy is metadata
Spouse
Father
Friend
Colleague
• Producers and
consumers need no
internetwork-level
addressing!
10
Operating on Graphs of Information
SId1
SId2
SId1
SId1
RId3
RId4
SId3
RId1
RId2
RId3
SId2
RId1
RId2
256 bit
e.g., P:L
RId3
data
Statistically unique within
its scope – although global
uniqueness can be defined
through 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
alg(seed)
• 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!
Segment determined
via RId = alg(seed), e.g.,
alg = seqNo
•
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 appspecific
Put Together: A Functional Model For
Solving Problems
• Each scope implements the
solution to a problem
Pub/Sub Service Model
Dissemination
Strategy
Rendezvous
•
Topology
•
Forwarding
SId
RId
RId
Functional scoping
Information scoping
Recursion
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!
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
Node Architecture
Put Together in A HighLevel Architecture
: Rendezvous point
: Inter-domain topology formation
: Topology management
: Forwarding node
Apps
pub
pub
pub
sub
Fragmentation
Service Model
Topology
ITF
ITF
Network Architecture
RP
ITF
TM
FN
Rendezvous
Caching
Helper
…
RP
RP
Rendezvous
Network
Error Ctrl
Forwarding
TM
TM
Forwarding
Network
TM
FN
Forwarding
Network
Forwarding
Network
TM
Forwarding
Network
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 presentations
20
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