Download Pursuit Architecture 1

PURSUIT Architecture
Mikko Särelä
19.9.2011
T-110.6210
Are the Fundamentals Still
Valid?
Fundamentals of the Internet
• Collaboration
– Reflected in forwarding and
routing
• Cooperation
– Reflected in trust among
participants
• Endpoint-centric services
– (mail, FTP, even web)
– Reflected in E2E principle
 IP, full end-to-end reachability
Reality in the Internet Today
•
Phishing, spam, viruses
– There is no trust any more!
•
Current economics favor senders
– Receivers are forced to carry the
cost of unwanted traffic
vs.
•
Information-centric services
– Do endpoints really matter?
– Endpoint-centric services move
towards information retrieval
through, e.g., CDNs
 IP with middle boxes &
significant decline in trust in the
Internet
2
Observation: It's All About Information
Internet Today:
• In 2006, the amount of digital information
created was 1.288 X 10^18 bits
• 99% of Internet traffic is information
dissemination & retrieval (Van Jacobson)
• HTTP proxying, CDNs,
video streaming, …
• Akamai’s CDN accounts for 15% of
traffic
• Between 2001 and 2010, information will
increase 1million times from 1 petabyte
(10^15) to 1 zettabyte (10^21)
• Social networking is information-centric
• Most solutions exist in silos
• overlays over IP map
information networks
onto endpoint networks
Internet Tomorrow:
• Proliferation of dissemination & retrieval
services, e.g.,
• context-aware services & sensors
• aggregated news delivery
• augmented real life
• Personal information tenfold in the next
ten years
(IBM, 2008)
• Increase of personalized video services
• e.g., YouTube, BBC iPlayer
• Vision recognized by different
initiatives & individuals
• Internet of Things,
Van Jacobson, D. Reed
• Lack of interworking of silo solutions will
slow innovation and development speed
3
Hypothesis: Increased Information Requires Informationcentric Network Approaches
Application developers care about information concepts
– Creation of information topologies of various kinds
-> Endpoint-centric networking structures are inadequate
– Topological network changes too slow in timescale
– Topological network boundaries too restrictive
– Topological network boundaries often not aligned with
information topologies
– Overlaying possible but restricted in (developer) scalability
-> If it is all about information, why not route on
information?
4
Why not?
• Why not route on information?
Main Design Principles
• Information is multi-hierarchically organised
– Information semantics are constructed as
directed acyclic graphs (DAGs)
• Information scoping
Information
Hierarchies
Information
reachability/
scoping
– Mechanisms are provided that allow for limiting
reachability of information to parties
• Scoped information neutrality
– Within each information scope, data is only
delivered based on a given (rendezvous)
identifier.
Communication Model
• The architecture is receiver-driven
– No entity shall be delivered data unless it has
agreed to receive those beforehand.
6
Information Concepts
• Information
– Smallest something
• Information collections
– Sets of semantically similar information
• Information networks
– Sets of information under some common
governance
• Information producer
– Entity publishing information to a particular
network
• Information consumer
– Entity subscribing to information in a particular
network
7
Grouping Information Networks
8
Architectural processes
• Rendezvous
– The process of resolving higher level identifiers to lower
level identifiers within a given scope.
– Three simple cases: link-local, intra-domain, inter-domain
• Topology management and formation
– Management of data delivery topologies and forwarding
graphs
• Forwarding
– Data delivery within a single administrative domain or
across multiple domains.
– Temporal forwarding identifiers for each publisher and
subscriber are derived via the rendezvous and topology
management processes
– Various routing and forwarding protocols can be used, for
example a new protocol replacing IP or IP-based overlays
9
Architecture Overview
AS
Rendezvous
Subscribe
Forwarding
node
Subscriber
Topology
Forwarding
node
AS
Topology
Forwarding
edge nodes
Data Forwarding
AS
Rendezvous
Topology
Forwarding
node
Publish
Forwarding
node
Create
delivery
path
Configure
Forwarding
path
Publisher
10
Service Model and API
We have considered four different classes of
network services
1. A low-level page model that exposes
network forwarding and
rendezvous/topology formation functions
2. A mid-level memory object model
• Memory pages are mapped to
publications
3.
4.
Higher-level APIs
Channel API
Memory Object API
Low-level page API
A mid-level channel model
Various high-level service models
including shared state and document
models
12
Node Architecture: Component Wheel
• Components may be decoupled in space,
time, and context
– Layerless protocol suite
• Applications may insert or request new
components to the wheel at runtime
– Implemented as helper functions
• The components are attached to the local
blackboard (BB)
– Components are attached to the local
blackboard, sharing publications, state
– Pub/sub is used to signal changes to
blackboard state
13
Component Wheel Interactions
Subscriber
Blackboard
Caching
Routing and forwarding
Low-level Link
Register and subscribe notifications
Register and subscribe notifications
Subscribe
Notify first component in plan
Component done, no cache hit
Notify second component in plan
Access memory object
Forward subscription
Publication
Insert publication as memory object
Notify componen in plant
Notify that has been added to cache
Notify subscriber
14