the ana project
Download
Skip this Video
Download Presentation
The ANA Project

Loading in 2 Seconds...

play fullscreen
1 / 82

The ANA Project - PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The ANA Project' - gretel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the ana project

The ANA Project

Kaiserslautern, Germany

4 March 2012

disclaimer
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
networking characteristics
Networking Characteristics

Private↔public

Control↔data

Delay tolerant↔real time

Local↔global

Resource constraint↔unlimited resources

Reliable↔best effort

the internet hourglass
The Internet Hourglass

Private↔public

Control↔data

Delay tolerant↔real time

Local↔global

Resource constraint↔unlimited resources

Reliable↔best effort

motivation
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, …)

the internet hourglass1
Everythingon IPThe 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, …)

Application

layer

Homogeneous networking abstraction

IPv6

IPvX

IP

Disruptive

approaches need

a disruptive

architecture

Link

layer

IP on

Everything

Ethernet, WIFI (802.11), ATM,

SONET/SDH, FrameRelay,

modem, ADSL, Cable, Bluetooth…

objectives
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!

scenario today
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
scenario with ana
ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

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
scenario with ana1
ANA core

ANA core

ANA core

ANA core

ANA core

Scenario – with ANA

Other ANA Compartment

inter-compartment routing

ANA Compartment

Internet

(IP Compartment)

heterogeneity
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

Pub/Sub

IP

???

Clean Slate

Link

layer

We need a framework that

is able to host multiple networks

 ANA framework

the ana project1
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
from layers to functional composition
From Layers to Functional Composition
  • Per application port
  • UDP/TCP handling
  • IP does defragmentation, checksum,…
  • All packets from Ethernet with: 0x0800 IP0x86DD  IPv60x809B Apple Talk

App Layer

Trans Layer

Net Layer

MAC Layer

Phy Layer

from layers to functional composition1
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

functional composition
Functional Composition

Application Layer

passive

monitoring

adaptive

monitoring

Pub/Sub

AODV

TCP

Service

discovery

OSPF

UDP

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

Dispatching Table

ANA core

Functionalcomposition

IP frame

OSI

ATM frame

IPX

Phy/MAC Layer

scenario with ana2
ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

ANA core

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

ServiceDiscovery

Internet

Self-Association & Organization

pitfalls in network architecture design
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
ana the common denominator
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)

what did ana do finally socket de construction
What did ANA do, finally?Socket De-Construction

Semanticrichness

Changing set ofNW funct.

Socketinterface

adaptionlayer

ANA primitives

Mappings to hardware,software systems

t

you cannot build an architecture you grow it
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"

example scenario 1 sensor network
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
example scenario 2 video surveillance system
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
flexible protocol graph multiple nodes
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

flexible protocol graph multiple nodes1
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

slide32
ANA Blueprint

a look from inside

ana a meta architecture
ANA: a meta-architecture
  • ANA does not impose how network compartments should work internally:

 the ANA framework specifies how networks interact.

Sensor

Home NW

Internal

operation

is not

imposed

Pub/Sub

IP

ANA specifies

interfaces and

interactions with

network

compartment

leading to multiple and

heterogeneous compartments

but generic interaction

ANA framework

a meta architecture needs abstractions
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

functional blocks fbs
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

information channels ics
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:

ana compartment
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 alsoother grouping: name space, policies, technology, hardware etc
  • Observation: The Internet lacks compartments, at least officially
ana a framework for compartments
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

compartments and members
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).
member resolution
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").
compartments and layers
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.
what about addresses and names
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 ?
local labels for handling global addresses
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.
local labels for handling global addresses1
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
How CTs, ICs, FBs, and IDPs fit together

Node compartment

Node compartment

FB1

FB2

IC

c

a

b

Networkcompartment

example of communication setup
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

example of communication setup 2
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.

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.

Example of communication setup (3)

In the compartment database

there is now a member B.

In the export view, this IDP

indicates that client2 is reachable

via some identifier (e.g. B).

client1

client2

B = …

b

e

f

p

v

b

"stack" FB

example of communication setup 4
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

b

a

"stack" FBs

i

s

s

i

For a link-layer compartment,

this IC abstracts the physical link.

example of communication setup 5
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

forwarding some examples
Forwarding … some examples.

Bridging

+ intermediate

processing

where does autonomic fit in
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

.

.

.

autonomic path setup search in ana
Recursive "Brute-force" search via resolve() primitive.Autonomic path setup/search in ANA

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)

client

? "X"

? "X"

? "X"

.

.

? "X"

.

.

.

.

.

.

.

yellow-pages

system

functional composition1
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 -> f1(e)

f2

b -> f2(c)

c -> fwd(e)

c

b

e -> 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 -> f1(e)

f2

f3

re-binding is a simple

change in dispatch table

b -> f2(c)

c -> f3(d)

d

b

c

d -> fwd(e)

e -> eth-if(0)

modelling nodes as compartments
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

different views for a compartment
Different “views” for a compartment

A network compartment has different views, for different usage.

slide61
The Blueprint

in practice:

the ANA API

motivation1
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.
overview
Overview
  • The API offers 6 fundamental primitives. In C-style:

IDPppublish (IDPc, CONTEXT, SERVICE)

int unpublish (IDPc, IDPp, CONTEXT, SERVICE)

IDPrresolve (IDPc, CONTEXT, SERVICE, chanType)

int release (IDPc, IDPr)

void* lookup (IDPc, CONTEXT, SERVICE)

int send (IDPr, DATA)

contexts and services
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.
contexts and services1
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
using the api some examples
Using the API: some examples

Publishing an IPv4 address in the Ethernet compartment.

z <-- publish(y, "*", "10.1.2.3”)

using the api some examples1
Using the API: some examples

Resolving an IPv4 address in the Ethernet compartment.

s <-- resolve(e, "*", "10.1.2.3")

using the api some examples2
Using the API: some examples

Sending data.

send(s, DATA)

using the api some examples3
Using the API: some examples

Releasing an information channel.

release(e, s)

blueprint updates
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)
main publications and deliverables
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.12Final ANA Blueprint: version 2.1
  • Deliverable D1.13Final public release of ANA Core software
final status 2010
Final status 2010

Application Layer

CCR

TCP

IMF

Pub/Sub

MCIS

capture

Service

discovery

NFSR

UDP

Mobility

prediction

SAFT

Virt. Coord

FBR

Service

placement

Remediation

TURF

FDE

ISS

Minimum Infrastructure

Maximum Extensibility

Dispatching Table

ANA core

Functionalcomposition

ANA

Browser

IP

ANA

Browser v2

IPv2

Phy/MAC Layer

assessment 2 netarch a sluggish monster
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 ...
assessment 3 battle for the brains
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“)
extending the reach of ana
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

software architecture
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
extending the reach of ana1
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

extending the reach of ana2
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

ana and onelab2 eu fp7
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

ana

Planet Lab node

Internet

Internet

onelab2 ana testbed opportunities
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
ad