The ANA Project

The ANA Project

Kaiserslautern, Germany

4 March 2012

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

Disclaimer

2

Where will we need networking in the future?

3


4


5


6


8

Networking Characteristics

9

Delay tolerant↔real time

Local↔global

Private↔public

Resource constraint↔unlimited resources

Control↔data

Reliable↔best effort

The Internet Hourglass

10

Delay tolerant↔real time

Local↔global

Private↔public

Resource constraint↔unlimited resources

Control↔data

Reliable↔best effort

• 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

Motivation

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

11

IP

The Internet Hourglass

Applicationlayer

Linklayer

Ethernet, WIFI (802.11), ATM,SONET/SDH, FrameRelay,modem, ADSL, Cable, Bluetooth…

Disruptive approaches need

a disruptivearchitecture

Changing/updatingthe Internet coreis difficult orimpossible !(e.g. Multicast,Mobile IP, QoS, …)

Everythingon IP

Homogeneous networking abstraction

Voice, Video, P2P, Email, youtube, ….Protocols – TCP, UDP, SCTP, ICMP,…

IP onEverything

IPv6IPvX

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

ANA core

ANA core

ANA core

ANA core ANA core

ANA core

ANA core

• Self-association• Node bootstrapping• neighborhood discovery• address configuration • functional composition (suitable network stack)• Beyond IP!!!

New ANA Compartment

• Self-organization• determine comm. Protocol (non-IP) • form compartment • intra-compartment routing• service discovery

• Self-optimization• enhanced & integrated monitoring• functional re-composition• resilience

15


Internet(IP Compartment)

ANA Compartment

Other ANA Compartment inter-compartment routing

ANA core

ANA core

ANA coreANA core

ANA core

16

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

Applicationlayer

Linklayer

Generic framework

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

• Per application port

• UDP/TCP handling

• IP does defragmentation, checksum,…

• All packets from Ethernet with: 0x0800 IP0x86DD IPv60x809B Apple Talk

Phy Layer

MAC Layer

Net Layer

Trans Layer

App Layer

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

Phy/MAC Layer

Functional Compartment

Routing

Reliable Transport

MonitoringFragmentation

Mobility Prediction

Checksum

20

Functional Composition

Phy/MAC Layer

Functionalcomposition

TCP

ANA coreMinimum InfrastructureMaximum ExtensibilityDispatching Table

Application Layer

UDPSAFTSCTP

AODVOSPFRIPFBRDSR

New RP?New TP?

OSIATM frameIP frame

IPX

New prot?

Pub/Sub

probingcapturesystemmonitor

passive monitoring

Virt. Coord

adaptive monitoring

Mobilityprediction

ServicediscoveryService

placement

21


Internet

ANA core

Compartment 1

Compartment 2

ANA core

ANA core

ANA coreANA core

Compartment n

OneLab2

ANA core

ANA core

ANA core

ANA coreANA core

ANA core

Applications

End Node Network Node

ANA core

ApplicationsExtensible APIs and

Transitioning

Functional Composition

Self-Association & Organization

ServiceDiscovery

Routing and Transport

Monitoring

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

t

Semanticrichness

Socketinterface

ANA primitives

Mappings to hardware,software systems

adaptionlayer

Changing set ofNW funct.

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

Design phaseFirst "Blueprint"

(architectural model)

First prototypingphase

Testing + feedback phase

2nd design phaseMature "Blueprint"

2nd prototypingphase

Finalintegration

26

2010

Extratime

• 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 1: Sensor Network

27

• 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

Example Scenario 2: Video Surveillance System

28

Flexible Protocol Graph – Single Node

29

Flexible Protocol Graph – Single Node

30

• Blocks loaded by an administrator• Protocol stack changes

Negotiation between different nodes Maintenance: Use existing protocol graph for negotiation

Flexible Protocol Graph – Multiple Nodes

31

negotiation

• Blocks loaded by an administrator• Protocol stack changes

Negotiation between different nodes Maintenance: Use existing protocol graph for negotiation

Flexible Protocol Graph – Multiple Nodes

32

negotiation

ANA Blueprint a look from inside

33

ANA: a meta-architecture• ANA does not impose how network compartments

should work internally:

the ANA framework specifies how networks interact.

ANA framework

Internaloperationis notimposed

ANA specifiesinterfaces and interactions withnetwork compartment

…

leading to multiple andheterogeneous compartmentsbut generic interaction

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.

data is sent to IDPwhich has state to call correct functioninside FB

FB 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 alsoother 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 framework

Internaloperation

is notimposed

…

leading to multiple andheterogeneous compartmentsbut generic interaction

ANA specifiesinterfaces and interactions withany network compartment

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=…

resolveRequest(“A”)

How resolution is performed is specific to each compartment.

Compartment

A

A=…

Resolution processreturns communication entry point a

A

a

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 processreturns communication entry point a

A

a

Compartment45

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.

Local labels for handling (global) addresses

46

A

data is sent to IDPwhich has state to reach the destination

IC

CTX = 10.1.2.3SRV = tcp:80

How CTs, ICs, FBs, and IDPs fit together

FB1 IC FB2

cba

Node compartment Node compartment

Networkcompartment

47

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

Example of communication setup

48

p

Access object (FB) to private view of node compartment

This indicates that FBis the control-FB for thecompartment

v

ANA client has a control channelto the node compartment.

client1 client2

• Clients get access to the network compartment access objects.

Example of communication setup (2)

49

client1Network Compartment

e

Access objects (FB) to Network compartment f

p v

Client has now access to the membershipdatabase of the node compartment which contains the list of available network compartments.

client2

Client2 registers (via the IDP 'f') an identifier "B" with network compartment.

Conceptually, this creates an entry in the membership database.

50


In the export view, this IDP indicates that client2 is reachablevia some identifier (e.g. B).

In the compartment databasethere is now a member B.

B = …

"stack" FB b

e fp v

b

client1 client2

• Client1 resolves (via the IDP 'e') the identifier "B" and receives startpoint IDP 'a'.


51

ba

B = …

"stack" FBs

ve

p

For a link-layer compartment,this IC abstracts the physical link.

i

i

ba

s

s

f

client1 client2

• Typically, client1 only sees exported view (unless compartment exposes internal operation).


52

a b

Export view ofthe compartment

client1 client2

Forwarding … some examples.

53

Bridging

+ intermediateprocessing

54

Overlay scenario with compartments

Send to medium Listen to medium

Send to medium Listen to medium

Compartment N

Compartment L1 Compartment L2

imported element imported element

55


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

Compartment N

Compartment L1 Compartment L2

imported element imported element

56


• Figure just showing export view of compartment N.

Compartment N

ANA node 1 ANA node 2 ANA node 3

Which could also be drawn like that(just showing the export view).

ANA node 3

ANA node 1 ANA node 2

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

Where does autonomic fit in?

57

client

...

...

If client does not knowhow to reach identifier "X",it can try to resolve() it with all the network compartments it knows about.

? "X"

? "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 askdedicated systems from a "yellow-pages" compartment tohelp resolving "X" (e.g., to learn which compartment to join)

? "X"

? "X"

? "X"

yellow-pages system

...

? "X"

"Chains" of functions are setup on-demand in a dynamic way.

Packet dispatching in ANA is based on IDPs.

60

Functional composition

app

b

a

c

e

f2f1 a -> f1(e)

b -> f2(c)c -> fwd(e) e -> eth-if(0)

Information Dispatch Table

app

b

a

c d

e

f2f1f3

a -> f1(e)b -> f2(c)c -> f3(d)d -> fwd(e)e -> eth-if(0)

Information Dispatch Table

re-binding of IDP 'c' isnot visible to users of 'c'(function f2 here)

re-binding is a simplechange in dispatch table

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.

App/serviceep

f

Node Compartment

a

61

Different “views” for a compartment

A network compartment has different views, for different usage.

"ANA world"

Underlying HardwareSend to medium

(Ethernet, wifi, etc)Listen to medium

(Ethernet, wifi, etc)

Node compartment Node compartment

data indata out

exportedview

structuralview

Compartment

This shows that there is really just one IDP "mapped" in the different views.

importedview

IC abstracts serviceprovided by

underlying hardware

IC abstracts communicationservice provided by

the compartment

62

Node architecture

Adaptation layer

Legacy appsApplications

sockets

MINMEX

NodeCompartment

InformationDispatch Table

MINMEXcontroller

ANA Playground + API

compartments,learning logic,service checker,IP overlay,monitoring,turf,p2p,AN style …

Platform abstraction layer (optional)

Platform OS

Event notificationsystem

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.

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

"10.1.2.3" z

node M

ETH-FB

IP-FB

zy

publish

Ethernet Compartment

69


Resolving an IPv4 address in the Ethernet compartment.

node N

ETH-FB


i

eresolve

"10.1.2.3" z

IP-FB

node M

ETH-FB

IP-FB

zy

s

How the resolution is performedis compartment specific

(e.g. broadcast message sent toFF:FF:FF:FF:FF:FF)

s ETH-M

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


Sending data.

node N

ETH-FB


i

e

send

"10.1.2.3" z

IP-FB

node M

ETH-FB

IP-FB

zy

s

s ETH-M

send(s, DATA)

71


Releasing an information channel.

node N

ETH-FB


i

erelease

"10.1.2.3" z

IP-FB

node M

ETH-FB

IP-FB

zy

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.12Final ANA Blueprint: version 2.1

• Deliverable D1.13Final public release of ANA Core software

74

Final status 2010

75

Phy/MAC Layer

Functionalcomposition

TCP

ANA coreMinimum InfrastructureMaximum ExtensibilityDispatching Table

Application Layer

UDP

SAFT

TURF

IP

Pub/SubIMF

Mobilityprediction

Servicediscovery

Serviceplacement

capture

Virt. Coord

Remediation

IPv2

ANA BrowserANA Browser v2

CCR

NFSR

FBR

ISS

MCIS

FDE

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

ana

79

• 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

Software Architecture

80

Publish Subscribe SystemApplications / Use Cases

[email protected]


• By developing mobile applications with E.g., ANA API for opportunistic networks Content dissemination Social networking Flea Market Round games

82


• 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

Data Link Layer

Peer Manager

FBTransfer

FB

WLAN – 802.11 Bluetooth

SynchronizationFB

ContentApp/GUI

SAFTFBs

83

ana

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)

Planet Lab node

PlanetLab/SAC

GatewayPlanetLab/SAC

Cloud

Internet Internet

84

85

OneLab2 – ANA testbed opportunities?

Internet

PlanetLab

Robot Testbed• Controlled mobility

Vehicular Testbed• Uncontrolled mobility

Office Testbed • Uncontrolled mobility

Campus Testbed• Uncontrolled mobility

Sport event Testbed• Semi-controlled mobility

PlanetLab node

PlanetLab/SAC

Gateway

The ANA Project

Documents

networking characteristics

evolving network

reorganization of network

ana projectto

ana projectkaiserslautern

ip ip address configuration

function recomposition

mode routing protocol