Transcript Autonomous Network Architecture

The ANA Project
Kaiserslautern, Germany
4 March 2012
Disclaimer
ANA has been a collaborative effort – 10 partners
Many thanks to all team members!
But specifically for the core architects and developers:
 Christian Tschudin
 Christophe Jelger
 Ariane Keller
 Franck Legendre
 Simon Heimlicher
 Ghazi Bouabene
2
Where will we need
networking in the future?
3
Where will we need
networking in the future?
4
Where will we need
networking in the future?
5
Where will we need
networking in the future?
6
Where will we need
networking in the future?
8
Networking Characteristics
Private
↔
public
Delay tolerant
↔
real time
Resource constraint
↔
unlimited resources
Control
↔
data
Local
↔
global
Reliable
↔
best effort
9
The Internet Hourglass
Private
↔
public
Control
↔
data
Everything on IP
Delay tolerant
↔
real time
IP
Local
↔
global
IP on everything
Resource constraint
↔
unlimited resources
Reliable
↔
best effort
10
Motivation
•
The Internet suffers from architectural
stress:
 not ready to integrate and manage the
envisaged huge numbers of
dynamically attached devices (wireless
revolution, mobility, personal area
networks, etc)
Consensus
Lacks integrated
monitoring
and that a
in the research
community*
next step mechanisms
beyond the Internet is needed.
security
* as seen by the number of recent related projects and initiatives (FIRE, GENI, FIND, FP7, …)
11
The Internet Hourglass
Voice, Video, P2P, Email, youtube, ….
Protocols – TCP, UDP, SCTP, ICMP,…
Changing/updating
the Internet core
is difficult or
impossible !
(e.g. Multicast,
Mobile IP, QoS, …)
Everything
on IP
Application
layer
IP
IPv6
IPvX
Link
layer
IP on
Everything
Ethernet, WIFI (802.11), ATM,
SONET/SDH, FrameRelay,
modem, ADSL, Cable, Bluetooth…
Homogeneous
networking
abstraction
Disruptive
approaches need
a disruptive
architecture
12
Objectives
•
•
•
Goal: To demonstrate the feasibility of autonomic networking.
•
•
Identify fundamental autonomic networking principles.
Design and build an autonomic network architecture.
ANA in a blink:
•
•
•
•
Network must scale in size and in functionality.
Evolving network: variability at all levels of the architecture.
ANA = framework for function (re-)composition.
Dynamic adaptation and re-organization of network.
Networks have to work
 doing research through prototypes.
•
•
Early build an experimental network architecture.
Prototype used as feedback to refine architectural models.
Architectures are not built, they grow!
13
Scenario – today
• each device has to implement IP
• IP address configuration through
DHCP, zeroconf, ad hoc mode
• routing protocol has to be agreed on
 Most often results in manual
configuration
14
Scenario – with ANA
New ANA Compartment
ANA core
ANA core
ANA core
ANA core
• Self-organization
•• Self-optimization
• Self-association
determine comm. Protocol
• enhanced
& integrated
• Node
bootstrapping
(non-IP)
monitoring
• neighborhood
discovery
• form
compartment
• functional
re-composition
• address
configuration
• intra-compartment
routing
• resilience
• functional
composition
• service
discovery
(suitable network stack)
• Beyond IP!!!
ANA core
ANA core
ANA core
15
Scenario – with ANA
Other ANA Compartment
inter-compartment routing
ANA Compartment
ANA core
ANA core
ANA core
ANA core
ANA core
Internet
(IP Compartment)
16
Heterogeneity
•
Pub/Sub
Home NW
Sensor
•
Generic
framework
Link
layer
???
IP
Application
layer
•
•
We have to extend the waist
and host more paradigms
Future networks have to
scale in size AND
functionality
Enable network evolution
Federation instead of
homogeneous abstraction
We need a framework that
is able to host multiple networks

17
The ANA Project
•
To enable this vision we need:
 The ANA core

Highly configurable network stack
 Self-* properties

Service discovery

Self-organization

Self-optimization

Novel protocols
 Functional composition
18
From Layers to Functional
Composition
App Layer
Trans Layer
•
•
•
Net Layer
MAC Layer
Phy Layer
•
Per application port
UDP/TCP handling
IP does
defragmentation,
checksum,…
All packets from
Ethernet with:
0x0800  IP
0x86DD  IPv6
0x809B  Apple Talk
19
From Layers to Functional Composition
•
•
At least same
functionality as before,
but decomposed
Allows for composition of
functionality / services
Also:
•
New functionality
integrated in protocol
stack
 Not so novel, but we add
• Dynamic re-configuration
• Autonomic properties
Applications
Checksum
Reliable
Transport
Routing
Mobility
Prediction
Functional
Compartment
Monitoring
Fragmentation
Phy/MAC Layer
20
Functional Composition
Application Layer
passive
adaptive
monitoring monitoring
probing
capture
system
monitor
Mobility
prediction
Pub/Sub
AODV
TCP
Service
discovery
OSPF
UDP
RIP
SAFT
FBR
SCTP
DSR
New TP?
Service
placement
New RP?
Virt. Coord
Minimum
Infrastructure
Maximum
Extensibility
Dispatching Table
ANA core
New prot?
Functional
composition
IP frame
OSI
ATM frame
IPX
Phy/MAC Layer
21
Scenario – with ANA
Extensible
APIs and
Transitioning
End Node
Network Node
Functional
Composition
Applications
Applications
Monitoring
Compartment 2
OneLab2
ANA core
ANA core
ANA core
ANA core
Routing and
Transport
Compartment 1
ANA core
Compartment n
Service
Discovery
ANA core
ANA core
ANA core
ANA core
ANA core
ANA core
ANA core
Internet
Self-Association &
Organization
22
Pitfalls in network architecture design
Static/rigid standards instead of mechanisms for change
management:

e.g. Global address space (requires uniqueness and
global coordination)
Leaking of and relying on network internal details:

e.g. Built-in address dependency (i.e. address-centric
architecture vs address agnostic)
To avoid running into such pitfalls, we adopt an incremental
approach via prototyping cycles :

Helps revealing faults or inconsistencies in the
architecture design, gain experience and acceptance
23
ANA: the common denominator
ANA must permit variability at all levels of the architecture:

Multiple variants to perform a given task.

Different networks co-exist and compete.

The architecture is open for extensions and
(evolution).
And this should be done in an autonomic way
(less humans in the control loop)
24
What did ANA do, finally?
Socket De-Construction
Semantic
richness
Socket
interface
Changing
set of
NW funct.
adaption
layer
ANA primitives
Mappings to hardware,
software systems
t
25
You cannot "build" an architecture, you "grow" it
•
The project was articulated around 2 prototyping
cycles.

Methodology: design, test/validate, refine.
2006
2007
2008
2009
2010
Design phase
First "Blueprint"
(architectural model)
First prototyping
2nd prototyping
Extra
phase
phase
time
Final
Testing + feedback
integration
phase
2nd design phase
Mature "Blueprint"
26
Example Scenario 1:
Sensor Network
•
•
•
•
Distributed nodes to gain information about the environment

Fire alarm

Temperature measurement in permafrost
Limited resources (power, memory, CPU, etc.)
Network conditions can change frequently
Runtime customization of network stack to save power
dynamic
reconfiguration
Application
Application
Reliability
Link Layer
Protocol
Link Layer
Protocol
27
Example Scenario 2:
Video Surveillance System
•
•
•
•
Surveillance of train stations or airports

Communication between cameras

Communication from cameras to administrator
100% uptime required
Integration of new features without service disruption
Software updates for bug fixes without service disruption
Application
dynamic
reconfiguration
Application
Encryption
version 1.1
Encryption
version 1.2
Link Layer
Protocol
Link Layer
Protocol
28
Flexible Protocol Graph –
Single Node
Thread level
Packet loss
Locality
Application
Congestion
Packet Flow
Controller
Phy/MAC
Temperature
Available
Power
Available
Hardware
Hardware
Utilization
29
Flexible Protocol Graph –
Single Node
Thread level
Packet loss
Locality
Application
Congestion
Packet Flow
Controller
Phy/MAC
Temperature
Available
Power
Available
Hardware
Hardware
Utilization
30
Flexible Protocol Graph –
Multiple Nodes
•
•
Blocks loaded by an administrator
Protocol stack changes

Negotiation between different nodes

Maintenance: Use existing protocol graph for negotiation
Application
Application
Suggestion
Accepted?
No
negotiation
Yes
Reevaluation
Ok to use old graph?
No
Use new
protocol
Yes
Phy/MAC
Phy/MAC
Use old
protocol
Tear down
connection
31
Flexible Protocol Graph –
Multiple Nodes
•
•
Blocks loaded by an administrator
Protocol stack changes

Negotiation between different nodes

Maintenance: Use existing protocol graph for negotiation
Application
Application
Suggestion
Accepted?
No
negotiation
Yes
Reevaluation
Ok to use old graph?
No
Use new
protocol
Yes
Phy/MAC
Phy/MAC
Use old
protocol
Tear down
connection
32
ANA Blueprint
a look from inside
33
ANA: a meta-architecture
•
ANA does not impose how network compartments
should work internally:
…
Pub/Sub
Home NW
Internal
operation
is not
imposed
Sensor
ANA specifies
interfaces and
interactions with
network
compartment
IP
 the ANA framework specifies how networks interact.
leading to multiple and
heterogeneous compartments
but generic interaction
ANA framework
34
A meta-architecture needs abstractions
Abstractions permit to "hide" heterogeneity.

Functional Block (FB)

Information Dispatch Point (IDP)

Information Channel (IC)

Compartment.
ANA contribution: extract the „basics“ of all computer communications,
not only Internet specific concepts
36
Functional Blocks (FBs)
Code and state that can process data packets.
•
Protocols and algorithms are represented as FBs.

Access to FBs is via “information dispatch points” (IDPs).

FBs can have multiple input and output IDPs.

FB internally selects output IDP(s) to which data is sent.
FB
FB
data is sent to IDP
which has state to
call correct function
inside FB
37
Information Channels (ICs)
FBs do packet processing. We also need „packet transfer“.
•
•
•
•
“Information Channels“ are primitive, unidirectional datagram
transport entities
ICs interlink functional blocks, but can also be put in series.
Data is sent to an IDP connected to an IC.
Note: „channels“ are an not tangible, usually distributed
Various types of information channels:
unicast
multicast
anycast
concast
38
ANA Compartment
•
•
•
•
Compartment (CT) = space where FBs, IDPs and ICs live
CTs, beside IDPs, probably the most important ANA
contribution
Compartments indicate management borders, but also
other grouping: name space, policies, technology, hardware etc
Observation: The Internet lacks compartments, at least officially
39
ANA – a Framework for Compartments
•
•
Compartment = wrapper for networks.
ANA does not impose how network compartments should work
internally: the ANA framework specifies how networks interact.
…
ANA specifies
interfaces and
interactions with
any network
compartment
Internal
operation
is not
imposed
leading to multiple and
heterogeneous compartments
but generic interaction
ANA framework
40
Compartments and « Members »
•
•
Compartments offer connectivity among „compartment members“
A (network) compartment defines how to join and leave a compartment:
member registration, trust model, authentication, etc.

Each compartment defines a conceptual membership database.

Registration: explicit joining and exposing is required ("default-off"
model).
A=…
Register(“A”)
How registration is
performed is specific to
each compartment.
Compartment
41
Member resolution

Defines How to reach (communicate with) another member: peer
resolution, addressing, routing, etc.

Resolution: explicit request before sending ("no sending in the
void").
A=…
A=…
Resolution process
returns communication
entry point a
resolve
Request(“A”)
A
A
How resolution is
performed is specific to
each compartment.
a
Compartment
Compartment
42
Compartments and Layers
•
Compartments can be overlaid, i.e. compartments can use the
communication services of other compartments.

The compartment abstraction serves as the unit for the
federation of networks into global-scale communication systems.

It defines interaction rules with the "external world", the
compartment boundaries (administrative or technical), the
peerings with other compartments, etc.
43
What about addresses and names ?
Addressing and naming are left to compartments.

Each compartment is free to use any addressing, naming, and
routing schemes (or is free to not use addresses, for example in
sensor networks).
The main advantages are:

No need to manage a unique global addressing scheme.

No need to impose a unique way to resolve names.

ANA is open to future addressing and naming schemes.
The main drawbacks are:

Back to the CATENET challenges : How to inter-network in such
heterogeneous address/name spaces ?
44
Local labels for handling (global) addresses
•
Target resolution returns a local label = IDP

IDPs are "indirection points inside the network stack".

Addresses/names = input for the resolution process.

The IDP then maintains the state to reach the destination.
A=…
Resolution process
returns communication
entry point a
A
a
Compartment
45
Local labels for handling
(global) addresses
Why is this useful? ("startpoints instead of endpoints")
•
Ability to bind to destinations in an address agnostic way.
•
•
This is important to support many flavors of compartments
that can use different types of addresses and names.
Useful decoupling between identifiers and means to address
them.
•
Important to permit dynamic re-binding of communications.
IC
A
data is sent to IDP
which has state to
reach the destination
CTX = 10.1.2.3
SRV = tcp:80
How CTs, ICs, FBs, and IDPs fit together
Node compartment
FB1
a
Node compartment
FB2
IC
c
b
Network
compartment
47
Example of communication setup
•
Interaction with the node compartment is via a
special kind of FB called an "access object (AO)".

For example, register and resolve requests are sent to the
AO.
client1
client2
ANA client has a control channel
to the node compartment.
This indicates that FB
is the control-FB for the
compartment
p
v
Access object (FB) to private
view of node compartment
48
Example of communication setup
(2)
•
Clients get access to the network compartment access
objects.
client1
client2
Network Compartment
e
p
Access objects (FB)
to Network
compartment
f
v
Client has now access to the membership
database of the node compartment which
contains the list of available
network compartments.
49
Example of communication setup
(3)
Client2 registers (via the IDP 'f') an identifier "B" with network
compartment.

Conceptually, this creates an entry in the membership database.
In the compartment database
there is now a member B.
client1
In the export view, this IDP
indicates that client2 is reachable
via some identifier (e.g. B).
client2
B=…
b
e
f
p
v
"stack" FB
b
50
Example of communication setup
(4)
•
Client1 resolves (via the IDP 'e') the identifier "B"
and receives startpoint IDP 'a'.
client1
client2
B=…
a
b
f
e
p
v
a
s
"stack" FBs
b
i
s
i
For a link-layer compartment,
this IC abstracts the physical link.
51
Example of communication setup (5)
•
Typically, client1 only sees exported view (unless
compartment exposes internal operation).
client1
client2
Export view of
the compartment
a
b
52
Forwarding … some examples.
Bridging
+ intermediate
processing
53
Overlay scenario with compartments
Compartment N
imported element
imported element
Compartment L1
Send to medium
Compartment L2
Listen to
medium
Send to medium
Listen to
medium
54
Overlay scenario with compartments
•
Same figure but only with exported views of L*
compartments.
Compartment N
imported element
Compartment L1
imported element
Compartment L2
55
Overlay scenario with compartments
•
Figure just showing export view of compartment N.
Compartment N
ANA node 1
ANA node 2
ANA node 3
ANA node 3
Which could also be drawn like that
(just showing the export view).
ANA node 1
ANA node 2
56
Where does autonomic fit in?
•
Autonomic path setup/search in ANA

"Brute-force" search via resolve() primitive.
client
? "X"
If client does not know
how to reach identifier "X",
it can try to resolve() it
with all the network
compartments it knows
about.
? "X"
? "X"
..
.
…X
..
.
57
Autonomic path setup/search in ANA
•
Recursive "Brute-force" search via resolve() primitive.
client
If client cannot resolve()identifier "X", it could ask
dedicated systems from a "yellow-pages" compartment to
help resolving "X" (e.g., to learn which compartment to join)
? "X"
? "X"
? "X"
? "X"
..
.
..
.
..
.
yellow-pages
system
58
Functional composition
"Chains" of functions are setup on-demand in a dynamic way.

Packet dispatching in ANA is based on IDPs.
app
a
e
f1
f2
c
b
re-binding of IDP 'c' is
not visible to users of 'c'
(function f2 here)
Information
Dispatch Table
a -> f1(e)
b -> f2(c)
c -> fwd(e)
e -> eth-if(0)
app
a
e
f1
f3
f2
b
c
d
Information
Dispatch Table
a -> f1(e)
b -> f2(c)
c -> f3(d)
d -> fwd(e)
e -> eth-if(0)
re-binding is a simple
change in dispatch table
60
Modelling nodes as compartments
•
Each node itself appears as a compartment.

Member database: catalog of available functions.

Resolution step to access a given function.

Also implements access control.

Resolution instantiates functional blocks (FBs).

The node compartment hosts/executes FBs and IDPs.
Node Compartment
p
e
App/service
f
a
61
Different “views” for a compartment
A network compartment has different views, for different usage.
This shows that there is really just one IDP "mapped" in the different views.
Node compartment
Node compartment
Compartment
exported
view
data in
IC abstracts communication
service provided by
the compartment
data out
structural
view
imported
view
IC abstracts service
provided by
underlying hardware
Send to medium
(Ethernet, wifi, etc)
"ANA world"
Listen to medium
(Ethernet, wifi, etc)
Underlying
Hardware
62
Node architecture
Legacy apps
Applications
sockets
Adaptation layer
ANA Playground + API
MINMEX
Node
Compartment
MINMEX
controller
Information
Dispatch Table
Event notification
system
compartments,
learning logic,
service checker,
IP overlay,
monitoring,
turf,
p2p,
AN style …
Platform abstraction layer (optional)
Platform OS
63
The Blueprint
in practice:
the ANA API
64
Motivation
•
•
•
Network compartments are free to internally run
whatever addressing/naming schemes, routing
protocols, etc.
The "glue" for all interactions in ANA is the
compartment API.
All network compartments must support the API in
order to allow all possible interactions between
compartments.
65
Overview
•
The API offers 6 fundamental primitives. In C-style:
IDPp publish (IDPc, CONTEXT, SERVICE)
int unpublish (IDPc, IDPp, CONTEXT, SERVICE)
IDPr resolve (IDPc, CONTEXT, SERVICE, chanType)
int release (IDPc, IDPr)
void* lookup (IDPc, CONTEXT, SERVICE)
int send (IDPr, DATA)
66
CONTEXTS and SERVICES
•
The SERVICE argument is typically what is being published or
looked up.

•
e.g., an address, a name, a file, a video stream, a
printing service, etc.
The CONTEXT defines some scope inside a compartment.

IPv4: 1.2.3.4, 224.0.0.1, 10.1.2.255.

IPv6: 2001::1, FF02::1, ::1.

eMule: Madonna, Pink Floyd, Blade Runner.
67
CONTEXTS and SERVICES
•
We have currently specified two "well-known"
CONTEXT value.

"."  node-local

"*"  largest possible scope as interpreted by the
compartment
Examples:
•
•
IPv4 compartment:
"*" ~ 255.255.255.255
"." ~ 127.0.0.1
Ethernet:
"*" ~ FF:FF:FF:FF:FF:FF
"." ~ local address
68
Using the API: some examples
Publishing an IPv4 address in the Ethernet
compartment.
IP-FB
y
ETH-FB
Ethernet
Compartment
z
publish
"10.1.2.3"  z
node M
z <-- publish(y, "*", "10.1.2.3”)
69
Using the API: some examples
Resolving an IPv4 address in the Ethernet
compartment.
IP-FB
s
IP-FB
resolve
e
y
ETH-FB
i
s  ETH-M
z
ETH-FB
How the resolution is performed
is compartment specific
(e.g. broadcast message sent to
FF:FF:FF:FF:FF:FF)
"10.1.2.3"  z
node N
node M
Ethernet
Compartment
s <-- resolve(e, "*", "10.1.2.3")
70
Using the API: some examples
Sending data.
IP-FB
send
s
IP-FB
e
y
ETH-FB
z
ETH-FB
i
s  ETH-M
"10.1.2.3"  z
node N
node M
Ethernet
Compartment
send(s, DATA)
71
Using the API: some examples
Releasing an information channel.
IP-FB
IP-FB
release
e
y
ETH-FB
z
ETH-FB
i
"10.1.2.3"  z
node N
node M
Ethernet
Compartment
release(e, s)
72
Blueprint Updates
•
•
•
Event notification system
IDPinfo framework
Security section (catch up with implement.)

Clarify „IDP ownership“

Private and public IDPs

Implementation guidelines (threads, crash
containment, msg queues, symbol export,
ANA-controlled malloc)
73
Main publications and deliverables
•
•
•
•
Ghazi Bouabene, Christophe Jelger, Christian Tschudin, Stefan
Schmid, Ariane Keller, Martin May, The Autonomic Network
Architecture (ANA), In IEEE JSAC special issue on Recent
Advances in Autonomic Communications, January 2010.
Ariane Keller, Theus Hossmann, Martin May, Ghazi Bouabene,
Christophe Jelger, and Christian Tschudin, A System
Architecture for Evolving Protocol Stacks, in Proceedings of
the 17th Int. Conference on Computer Communications and
Networks (ICCCN'08), August 2008, St. Thomas, USA.
Deliverable D1.12
Final ANA Blueprint: version 2.1
Deliverable D1.13
Final public release of ANA Core software
74
Final status 2010
Application Layer
IMF
MCIS
capture
Virt. Coord
Mobility
prediction
Remediation
Pub/Sub
CCR
TCP
Service
discovery
NFSR
UDP
FBR
SAFT
Service
placement
TURF
FDE
Minimum
Infrastructure
Maximum
Extensibility
Dispatching Table
ANA core
Functional
composition
ISS
ANA
ANA
Browser
Browser v2
IP
IPv2
Phy/MAC Layer
75
Assessment 2:
NetArch = a sluggish monster?
•
Look at Nimrod as an example of failed arch
thinking
NetArch = sum of
 concepts
 code framework
 actual algorithms (service discovery, routing,
directories, device drivers, monitoring etc)
 management logic and knobs for humans
 deployment vector (think BSD)
 „rat hole“ to sneak into existing solutions ...
77
Assessment 3:
Battle for the brains
First ANA blueprint was not easy to obtain:
 Fierce battles on „the right view“
This continues when spreading the word
•
•
„not invented here“
inertia of old thinking/habits („I want my
addresses back“)
78
Extending the reach of ANA
•
By porting of the framework on multiple
mobile platforms / devices
 Linux Open Embedded / Nokia N810
 Symbian / N95
 MacOS / iPhone
79
Software Architecture
•
•
•
•
Implementation in the Linux kernel
Linux kernel network stack replaced by flexible protocol
graph
BSD socket interface and device drivers are retained
Configuration via user space tool
Applications
userspace
kernelspace
FP_s
BSD Socket Interface
FB_1
PPE
FP_d
FB_n
Virtual Link Layer
Device Driver
80
Applications / Use Cases
PUBLISH SUBSCRIBE SYSTEM
81
Extending the reach of ANA
•
By developing mobile applications with
E.g., ANA API for opportunistic networks

Content dissemination

Social networking

Flea Market

Round games
82
Extending the reach of ANA
•
PodNet ANA port
Opportunistic content
exchange

SAFT: reuse link-to-link bricks

Peer Manager: keep track of
peers

Synchronization: keep track of
peer status

Transfer: trigger data exchange

Security/Trust: spam avoidance
Application Layer
App/GUI
Content
Synchronization
FB
Peer
Manager
FB
Transfer
FB
SAFT
FBs
WLAN – 802.11
Bluetooth
Data Link Layer
83
ANA and OneLab2 (EU FP7)
•
PLE/SAC Gateway

Extends PlanetLab nodes to support SAC clouds based on
Future Internet network paradigms

Autonomic Networks (EU FP6 ANA)

Opportunistic (Pocket switched networks – EU FP6 Haggle)

Delay-tolerant (DTNRG)
PlanetLab/SA
C Gateway
PlanetLab/SAC
Cloud
Planet Lab
node
Internet
Internet
84
OneLab2 – ANA testbed
opportunities?
Office Testbed
• Uncontrolled mobility
PlanetLab
node
Sport event Testbed
• Semi-controlled mobility
PlanetLab/SA
C Gateway
Internet
Vehicular Testbed
• Uncontrolled mobility
PlanetLab
Campus Testbed
• Uncontrolled mobility
Robot Testbed
• Controlled mobility
85