Blackadder ICN Prototype - cse.tkk.fi · FromDevice($DEV, SNIFFER false) -> c ::...

Blackadder ICN Prototype

T-110.6120 9.10.2012

Jimmy Kjällman

Ericsson Research, NomadicLab

Blackadder

•  Realizes PURSUIT’s functional model for information-centric networking

Rendezvous Topology

Forwarding

Pub/Sub Service Model

SId

RId RId

Functional scoping Information scoping

Dissemination Strategy

Recursion

Information Structure

•  Scopes, subscopes, information items

•  Information is structured as a directed acyclic graph •  IDs are (statistically) unique within a scope

–  (Possibly) self-generated, flat labels –  Same ID space for both subscopes and information

items •  “Complete” identifier: Prefix + ID

–  One or more paths starting from one or more graph’s root(s)

Information Structure

0001 0003

0001 0001 0002

0001

0001 0002 0003

AAA0 AAA1 AAA2 0002 AAA1

Scope

Information item

AAA2

Information ID : /0003/0002/AAA2

Scope ID : /0001/0001/0001, /0002/0001/0001, /0003/0001/0001

0002

0001

0002

0003

0001 0001

0001 0002

Original slides: George Parisis, Computer Laboratory, University of Cambridge, 2011

Core Functions

•  Simplified example

Rendezvous

Topology

Forwarding P S

Dissemination Strategies

•  Defines the methods used for implementation (of a scope) –  Architectural components –  Data formats –  Governance structures –  Etc.

•  Can be “overridden” for sub-items – if permitted –  Strategies have to be aligned

•  Usually engineered at design time •  Larger problem solutions through the assembly of

smaller ones

Service Model

•  Publish/Subscribe

•  For example: –  publish_scope(id, prefix, strategy)

publish_info (id, prefix, strategy) –  unpublish_scope(id, prefix, strategy)

unpublish_info (id, prefix, strategy) –  subscribe_scope(id, prefix, strategy)

subscribe_info (id, prefix, strategy) –  unsubscribe_scope(id, prefix, strategy)

unsubscribe_info (id, prefix, strategy)–  publish_data(id, strategy, data, data_len)–  getEvent(&event)

Blackadder Architecture

•  Click is an external framework that Blackadder uses

Click

IPC Element

Communication Elements

/dev/eth0

App1 App2 App3 App4 AppN………………...

Rendezvous

Forwarding

Local Proxy

/dev/eth1 Raw IP Sockets

Topology Manager

Background Information: The Click Modular Router

•  Open source platform for building packet processing configurations that consist of connected elements –  Language for describing router configurations –  Ready-made elements –  Libraries for creating new elements as C++ classes

•  Portable code –  Kernel and userlevel –  Linux, FreeBSD, Mac OS X, etc.

•  Modular design approach –  Reuse of elements in different configurations

(e.g., in different prototypes or experiments) •  Basic operation: packets are pushed or pulled between

elements

Click Router Configuration

•  Example: Ping (nothing to do with Blackadder, just illustrates a Click router)

define($DEV eth0, $DADDR 8.8.8.8, $GW $DEV:gw)FromDevice($DEV, SNIFFER false)

-> c :: Classifier(12/0800, 12/0806 20/0002)-> CheckIPHeader(14)-> ip :: IPClassifier(icmp echo-reply)-> ping :: ICMPPingSource($DEV, $DADDR)-> SetIPAddress($GW)-> arpq :: ARPQuerier($DEV)-> IPPrint-> q :: Queue-> ToDevice($DEV);

arpq[1] -> q;c[1] -> [1] arpq;


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

IPC Element

•  Implements a Netlink socket for receiving pub/sub requests from applications (or an API library) and for sending back pub/sub events and published data –  These are sent as messages through the socket –  In user space, the IPC element utilizes the selection

mechanism provided by Click –  In kernel space, the element receives sk_buffs in the context

of the running process – buffers are wrapped into Click packets that are later processed by a Click task

•  Everything is asynchronous – like an event-based system

API (Service Model): Functions and Messages

•  publish_scope(id, prefix, strategy) publish_info (id, prefix, strategy)

•  unpublish_scope(id, prefix, strategy) unpublish_info (id, prefix, strategy)

•  subscribe_scope(id, prefix, strategy) subscribe_info (id, prefix, strategy)

•  unsubscribe_scope(id, prefix, strategy) unsubscribe_info (id, prefix, strategy)

•  publish_data(id, strategy, data, data_len)

(These messages are only used node-internally)

ID Prefix ID length LIPSIN Identifier

Type

ID length

Strategy

ID length

1 1 Variable length Variable length1 1 LID size

ID LIPSIN Identifier

Type

ID length

Strategy

1 1 Variable length 1 LID size

Data

API: Events

•  Start Publishing, Stop Publishing •  New Scope, Deleted Scope

•  Published Data

IDType

ID length

1 1 Variable length

ID

Type

ID length

1 1 Variable length

Data


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

Accessing the network

•  Standard Click elements for network communication –  ToDevice and FromDevice for directly sending and

receiving Ethernet frames •  Suitable, e.g., when experimenting over high-speed LANs

–  RawSocket for sending and receiving IP (UDP) packets over raw sockets

•  Suitable, e.g., when experimenting in the PlanetLab testbed or VPNs

•  IP network used as an underlay

Network Packet Format

LIPSIN Identifier

LID size

No. ID

s

ID1 len

gth

ID1

ID2 len

gth

ID2

IDn len

gth

IDn Payload

1 1 1 1


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

Forwarding

•  Receives packets from the network communication elements –  Matches the FID with all outgoing links and

forwards the packets –  A separate LID is assigned to the “internal link”

between the Forwarding element and the Local Proxy Element

•  Implements the notion of destination –  Default method: LIPSIN

Sample forwarding configurations

•  Click configurations – usually auto-generated

Forwarder (MAC, 1,1, 08:00:00:00:00:01, 08:00:00:00:00:11, 10000000000000000000000000000000000000000000000000000000000000001, 08:00:00:00:00:02, 08:00:00:00:00:12, 10000010000000000000000000000000000000000000000000000000000000002, 08:00:00:00:00:03, 08:00:00:00:00:13, 1000001000000000001000000000000000000000000000000000000000000000);fw[1] -> Queue(1000) -> ToDevice(eth0);fw[2] -> Queue(1000) -> ToDevice(eth1);FromDevice(eth0, SNIFFER false) -> Classifier(12/080a)[0] -> [1]fw;FromDevice(eth1, SNIFFER false) -> Classifier(12/080a)[0] -> [2]fw;Forwarder (IP, 1,1, 192.168.0.1, 192.168.0.2, 10000000000000000000000000000000000000000000000000000000000000001, 192.168.0.1, 192.168.0.6, 10000010000000000000000000000000000000000000000000000000000000002, 192.168.1.1, 192.168.1.2, 1000001000000000001000000000000000000000000000000000000000000000); fw[1] -> Queue(1000) -> RawSocket(UDP) -> IPClassifier(dst udp port 9999)[0] -> [1]fw;fw[2] -> Queue(1000) -> RawSocket(UDP) -> IPClassifier(dst udp port 9999)[0] -> [2]fw;


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

Local Proxy

•  “The heart of a network node” – everything goes through it •  Receives all pub/sub requests from applications and other Click

elements •  Keeps track of

–  Pending subscriptions –  Advertised information items (and assigns FIDs)

•  Receives –  Published data and notifications about new or deleted scopes

•  Pushes packets to subscribers (applications or Click elements) –  Notifications to start or stop publishing data

•  Pushes packets to one (of the potentially many) publishers

Local Proxy

•  Applications are identified by the local Blackadder node by their Netlink source address (usually the process ID)

•  Click elements are identified by the outgoing port number (from the Local Proxy to the specific element)

•  These IDs are replaced in all pub/sub requests by a statistically unique Node Label (e.g., hash of MAC address)


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

RV Function

•  The same element runs in all nodes •  Every node can create an information structure that will be

known and maintained by the local RV function •  Other nodes can send pub/sub requests to that node if they

know a path to it •  Usual scenarios

–  A network node (its RV function) maintains a local structure for IPC (node-local strategy)

–  A network node (its RV function) maintains a structure accessible by physical neighbours (link-local strategy)

–  One or more dedicated RV nodes run in a domain – end hosts know how to reach them (domain-local scenario)

RV IPC

•  The RV Element access the world the same way applications do

•  It subscribes to root scope FFFF where all pub/sub requests are published

•  It publishes Topology Formation requests to scope FFFE to which the TM has subscribed

•  Topology formation is required when: –  A set of publishers need to be notified with

Forwarding IDs that point to a set of subscribers –  A set of subscribers need to be notified about a new

or deleted scope


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

The Topology Manager

•  An application –  Calculates shortest paths in a network → Forwarding information

–  Uses (e.g.) the igraph library for this •  How the TM does IPC

–  Subscribes locally to scope FFFE –  Receives requests from the RV node as publications –  Publishes responses directly to publishers and

subscribers using the Information ID /FFFD/destinationNodeID

–  Utilizes an implicit rendezvous dissemination strategy where information is published with a specific FID


Click

IPC Element


/dev/eth0


Rendezvous

Forwarding

Local Proxy


Topology Manager

Dissemination Strategies •  Currently 5 basic strategies are implemented

–  These strategies are used for choosing the scope of information visibility in a network

1.  Node-local –  IPC, “localhost”

2.  Link-local –  Communication with neighbors on a link –  Link IDs are provided by applications –  Implicit RV or TM functions

Dissemination Strategies

3.  Broadcast –  Similar to link-local, but broadcast to (know)

neighbors 4.  Domain-local

–  RV and TM functions involved –  End nodes need a FID for contacting the RV node –  Publishers get FIDs (to subscribers) for individual

information items 5.  Implicit rendezvous

–  FID given in the publish data call –  Mainly used by special components

(e.g., RV and TM)

A Blackadder Network

•  All network nodes run the same software –  Blackadder runs in user space or kernel space in the nodes

•  Configurations can be different –  End-nodes are configured to have link access (LID) and

access to dedicated rendezvous (RV) nodes (with an FID) –  Dedicated forwarding nodes run only the forwarding element

•  And other elements if additional functionality is required (e.g. caching)

–  Dedicated RV and TM nodes •  Any nodes can be RV nodes – an FID is required to reach them •  TM nodes run a Topology Manager (TM) application

–  A deployment tool can be used for generating configuration files and deploying them in a network

–  Network attachment component for dynamic settings

Simple API Example

Publisher ba = Blackadder(True) ba.publish_scope(sid, “”, DOMAIN_LOCAL, None)ba.publish_info(rid, sid, DOMAIN_LOCAL, None) ev = Event(); ev.type = 0while ev.type != START_PUBLISH: ba.getEvent(ev) passwhile True: data = raw_input() ba.publish_data(sid+rid, DOMAIN_LOCAL, None, data, len(data))(This example uses a Python API that is wrapped on top of a C++ API library that translates API calls to messages that are passed through IPC sockets.)

Subscriber ba = Blackadder(True)ba.subscribe_info(rid, sid, DOMAIN_LOCAL, None) ev = Event()while True: ba.getEvent(ev) if ev.type == PUBLISHED_DATA: print ev.data[:ev.data_len]

Blackadder availability

•  Open source (GPLv2 / BSD)

•  Code, documentation, etc. •  http://www.fp7-pursuit.eu/ •  https://github.com/fp7-pursuit/blackadder/

•  Current release: v0.2.1 (in GitHub) •  Next release expected soon

BLACKADDER DEMO

Blackadder ICN Prototype - cse.tkk.fi · FromDevice($DEV, SNIFFER false) -> c ::...

Documents

Transcript of Blackadder ICN Prototype - cse.tkk.fi · FromDevice($DEV, SNIFFER false) -> c ::...