The ANA Project - PowerPoint PPT Presentation

Loading...

PPT – The ANA Project PowerPoint presentation | free to download - id: 6d4b68-NjAyM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The ANA Project

Description:

The ANA Project Kaiserslautern, Germany 4 March 2012 – PowerPoint PPT presentation

Number of Views:6
Avg rating:3.0/5.0
Date added: 15 October 2019
Slides: 83
Provided by: Martin677
Category:
Tags: ana | aodv | project

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The ANA Project


1
The ANA Project
  • Kaiserslautern, Germany
  • 4 March 2012

2
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

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?
7
Where will we need networking in the future?
8
Where will we need networking in the future?
9
Networking Characteristics
Private ? public
Control ? data
Delay tolerant ? real time
Local ? global
Resource constraint ? unlimited resources
Reliable ? best effort
10
The Internet Hourglass
Private ? public
Control ? data
Delay tolerant ? real time
Local ? global
Resource constraint ? unlimited resources
Reliable ? best effort
11
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)
  • Lacks integrated monitoring and security
    mechanisms

Consensus in the research community that a next
step beyond the Internet is needed.
as seen by the number of recent related
projects and initiatives (FIRE, GENI, FIND, FP7,
)
12
The Internet Hourglass
Voice, Video, P2P, Email, youtube, . Protocols
TCP, UDP, SCTP, ICMP,
Application layer
Changing/updating the Internet core is difficult
or impossible ! (e.g. Multicast, Mobile IP, QoS,
)
Homogeneous networking abstraction
IPv6
IPvX
IP
Disruptive approaches need a disruptive architect
ure
Link layer
Ethernet, WIFI (802.11), ATM, SONET/SDH,
FrameRelay, modem, ADSL, Cable, Bluetooth
13
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!
14
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

15
Scenario with ANA
New ANA Compartment
  • Self-organization
  • determine comm. Protocol (non-IP)
  • form compartment
  • intra-compartment routing
  • service discovery
  • Self-association
  • Node bootstrapping
  • neighborhood discovery
  • address configuration
  • functional composition (suitable network stack)
  • Beyond IP!!!
  • Self-optimization
  • enhanced integrated monitoring
  • functional re-composition
  • resilience

16
Scenario with ANA
Other ANA Compartment
inter-compartment routing
ANA Compartment
Internet (IP Compartment)
17
Heterogeneity
  • 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

Application layer
Generic framework
Sensor
Home NW
IP
Pub/Sub
???
Clean Slate
Link layer
We need a framework that is able to host
multiple networks ? ANA framework
18
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

19
From Layers to Functional Composition
  • Per application port
  • UDP/TCP handling
  • IP does defragmentation, checksum,
  • All packets from Ethernet with 0x0800 ?
    IP 0x86DD ? IPv6 0x809B ? Apple Talk

App Layer
Trans Layer
Net Layer
MAC Layer
Phy Layer
20
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
Reliable Transport
Checksum
Routing
Mobility Prediction
Functional Compartment
Monitoring
Fragmentation
Phy/MAC Layer
21
Functional Composition
Application Layer
TCP
AODV
Pub/Sub
passive monitoring
adaptive monitoring
UDP
OSPF
Service discovery
probing
Mobility prediction
SAFT
RIP
capture
Service placement
SCTP
FBR
system monitor
DSR
New TP?
New RP?
Virt. Coord
New prot?
Minimum Infrastructure Maximum Extensibility Dispa
tching Table
ANA core
Functional composition
OSI
IP frame
ATM frame
IPX
Phy/MAC Layer
22
Scenario with ANA
Extensible APIs and Transitioning
Network Node
End Node
Functional Composition
Applications
Applications
Monitoring
Compartment 2
OneLab2
Routing and Transport
Compartment 1
Compartment n
Service Discovery
Internet
Self-Association Organization
23
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

24
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)
25
What did ANA do, finally? Socket De-Construction
Semantic richness
Changing set of NW funct.
Socket interface
adaption layer
ANA primitives
Mappings to hardware, software systems
t
26
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 phase
2nd prototyping phase
Extra time
Final integration
Testing feedback phase
2nd design phase Mature "Blueprint"
27
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

28
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

29
Flexible Protocol Graph Single Node
30
Flexible Protocol Graph Single Node
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

negotiation
32
Flexible Protocol Graph Multiple Nodes
  • Blocks loaded by an administrator
  • Protocol stack changes
  • Negotiation between different nodes
  • Maintenance Use existing protocol graph for
    negotiation

negotiation
33
  • ANA Blueprint
  • a look from inside

34
ANA a meta-architecture
  • ANA does not impose how network compartments
    should work internally
  • ? the ANA framework specifies how networks
    interact.

Internal operation is not imposed
Sensor
Home NW
Pub/Sub
IP

ANA specifies interfaces and interactions
with network compartment
leading to multiple and heterogeneous
compartments but generic interaction
ANA framework
35
ANA ? "one-size-fits-all"
  • ANA does not want to propose another
    "one-size-fits-all network waist".
  • ANA is a meta-architecture to host, interconnect
    and federate multiple heterogeneous networks

Application layer
Multiple "network instances" can co-exist

ANA framework
.
.
.
Link layer
36
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

37
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
38
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

39
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

40
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
41
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).

42
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").

43
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.

44
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 ?

45
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.

46
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 tcp80
47
How CTs, ICs, FBs, and IDPs fit together
Node compartment
Node compartment
FB1
FB2
IC
c
b
a
Network compartment
48
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
49
Example of communication setup (2)
  • Clients get access to the network compartment
    access objects.

client1
client2
Network Compartment
Access objects (FB) to Network compartment
e
f
p
v
Client has now access to the membership database
of the node compartment which contains the list
of available network compartments.
50
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 export view, this IDP indicates that
client2 is reachable via some identifier (e.g. B).
In the compartment database there is now a member
B.
client1
client2
B
b
e
f
p
v
b
"stack" FB
51
Example of communication setup (4)
  • Client1 resolves (via the IDP 'e') the identifier
    "B" and receives startpoint IDP 'a'.

client1
client2
B
a
b
e
f
p
v
b
a
"stack" FBs
i
s
s
i
For a link-layer compartment, this IC abstracts
the physical link.
52
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
53
Forwarding some examples.
Bridging
intermediate processing
54
Overlay scenario with compartments
55
Overlay scenario with compartments
  • Same figure but only with exported views of L
    compartments.

56
Overlay scenario with compartments
  • Figure just showing export view of compartment N.

57
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
.
.
.
58
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
59
Self-optimization
  • Monitor link quality and add error correction
    accordingly

app
Information Dispatch Table
a
e
f1
a -gt f1(e)
f2
f3
re-binding is a simple change in dispatch table
b -gt f2(c)
c -gt f3(d)
d
b
c
d -gt fwd(e)
e -gt eth-if(0)
60
Functional composition
  • "Chains" of functions are setup on-demand in a
    dynamic way.
  • Packet dispatching in ANA is based on IDPs.

app
Information Dispatch Table
a
e
f1
a -gt f1(e)
f2
b -gt f2(c)
c -gt fwd(e)
c
b
e -gt eth-if(0)
re-binding of IDP 'c' is not visible to users of
'c' (function f2 here)
app
Information Dispatch Table
a
e
f1
a -gt f1(e)
f2
f3
re-binding is a simple change in dispatch table
b -gt f2(c)
c -gt f3(d)
d
b
c
d -gt fwd(e)
e -gt eth-if(0)
61
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
a
f
62
Different views for a compartment
  • A network compartment has different views, for
    different usage.

63
Node architecture
64
  • The Blueprint
  • in practice
  • the ANA API

65
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.

66
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)

67
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 20011, FF021, 1.
  • eMule Madonna, Pink Floyd, Blade Runner.

68
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 "" FFFFFFFFFFFF "."
    local address

69
Using the API some examples
  • Publishing an IPv4 address in the Ethernet
    compartment.

z lt-- publish(y, "", "10.1.2.3)
70
Using the API some examples
  • Resolving an IPv4 address in the Ethernet
    compartment.

s lt-- resolve(e, "", "10.1.2.3")
71
Using the API some examples
  • Sending data.

send(s, DATA)
72
Using the API some examples
  • Releasing an information channel.

release(e, s)
73
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)

74
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

75
Final status 2010
Application Layer
TCP
Pub/Sub
IMF
CCR
MCIS
UDP
Service discovery
capture
NFSR
Mobility prediction
SAFT
Virt. Coord
FBR
Service placement
Remediation
TURF
FDE
ISS
Minimum Infrastructure Maximum Extensibility Dispa
tching Table
ANA core
Functional composition
ANA Browser
IP
ANA Browser v2
IPv2
Phy/MAC Layer
76
(No Transcript)
77
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 ...

78
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)

79
Extending the reach of ANA
  • By porting of the framework on multiple mobile
    platforms / devices
  • Linux Open Embedded / Nokia N810
  • Symbian / N95
  • MacOS / iPhone

ana
80
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

81
Publish Subscribe System
  • Applications / Use Cases

82
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

83
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
Content
App/GUI
Synchronization FB
Peer Manager FB
Transfer FB
SAFT FBs
Data Link Layer
Bluetooth
WLAN 802.11
84
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/SAC Gateway
PlanetLab/SAC Cloud
Planet Lab node
Internet
Internet
85
OneLab2 ANA testbed opportunities?
PlanetLab node
  • Sport event Testbed
  • Semi-controlled mobility
  • Office Testbed
  • Uncontrolled mobility

PlanetLab/SAC Gateway
Internet PlanetLab
  • Vehicular Testbed
  • Uncontrolled mobility
  • Robot Testbed
  • Controlled mobility
  • Campus Testbed
  • Uncontrolled mobility
About PowerShow.com