The ana project
This presentation is the property of its rightful owner.
Sponsored Links
1 / 82

The ANA Project PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

The ANA Project

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


Where will we need networking in the future

Where will we need networking in the future?


Where will we need networking in the future1

Where will we need networking in the future?


Where will we need networking in the future2

Where will we need networking in the future?


Where will we need networking in the future3

Where will we need networking in the future?


Where will we need networking in the future4

Where will we need networking in the future?


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 IP

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

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 single node

Flexible Protocol Graph – Single Node


Flexible protocol graph single node1

Flexible Protocol Graph – Single Node


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


The ana project

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


Overlay scenario with compartments

Overlay scenario with compartments


Overlay scenario with compartments1

Same figure but only with exported views of L* compartments.

Overlay scenario with compartments


Overlay scenario with compartments2

Figure just showing export view of compartment N.

Overlay scenario with compartments


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.


Node architecture

Node architecture


The ana project

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


    Publish subscribe system

    Applications / Use Cases

    Publish Subscribe System

    [email protected]


    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


  • Login