an and d Im Impl plementa ementation tion (01 0120 20442 - - PowerPoint PPT Presentation

Net etwork work Ke Kerne nel l Ar Archi chitect tectures ures an and d Im Impl plementa ementation tion (01 0120 20442 4423) ) Naming aming an and Ad Addressing ressing

Chaiporn Jaikaeo Chaiporn.j@ku.ac.th Department of Computer Engineering Kasetsart University

Materials taken from lecture slides by Karl and Willig

2

Na Name mes vs. . Add Addre resses



Names: s: Refer to “things”

• Nodes, networks, data, transactions, …
• May or may not be globally unique



Ad Addres esse ses: : Information needed to fi find these things

• Street address, IP address, MAC address
• May or may not be globally unique



Services to map between names and addresses

• E.g., DNS



Some names are also addresses

3

Na Nami ming ng in in WS WSN



Nodes are not independent

• But collaborate to solve a given task



Better to shift view from naming nodes to na naming ing data

4

Add Addre ress s Man Manage ageme ment nt Is Issue ues



Address dress al allo loca catio ion: n: Assign an entity an address from a given pool of possible addresses

• Distributed address assignment (centralized

like DHCP does not scale)



Address dress deal allo locat cation: ion: Once address no longer used, put it back into the address pool

• Because of limited pool size
• Graceful or abrupt, depending on node actions

5

Add Addre ress s Man Manage ageme ment nt Is Issue ues



Address representation



Conflict detection & resolution (Duplicate Address Detection - DAD)

• What to do when the same address is assigned

multiple times?

• Can happen e.g. when two networks merge



Binding

• Map between addresses used by different

protocol layers

• E.g., IP addresses are bound to MAC address

by ARP

6

Un Unique iqueness ness of f Add Addre resses



Globally unique

• Appears at most once all over the wo

worl rld



Network-wide unique

• Appears at most once in a given netwo

work rk



Locally unique

• Appears at most once in a defined

neighbo borho rhood

7

Add Addre ressing sing Ov Overh rhead ead



The fewer bits per address, the better



Global > Network-wide > Local



Tradeoffs

• Address length  management overhead



Typically, address negotiation runs only at the beginning

• Except when there is mobility

8

Di Distributed tributed Ad Addr dress ess As Assignment ignment



Option ion 1: Random assignment

• Unacceptable high risk of duplicate addresses
• No-conflict probability for n addresses and k

nodes is

• By Stirlings approximation
• Similar to the birthday paradox

9

Di Distributed tributed Ad Addr dress ess As Assignment ignment



Option ion 2: Still random, but avoid addresses used in local neighborhood

• By overhearing exchanged packets
• Good enough in many WSN apps where data

sent to a certain sink

10

Di Distributed tributed Ad Addr dress ess As Assignment ignment



Option ion 3: Repair any observed conflicts

• Randomly pick a temporary address and a

proposed fixed address

• Send an addres

ess requ quest t to the proposed address, using temporary address

• If addres

ess s reply y arrives, address already exists

• Collisions in temporary address unlikely, as
• nly used briefly



Option ion 4: Similar to 3, but use a neighbor that already has a fixed address to perform requests

11

Lo Locally cally Un Unique ique Add Addre resses



Fewer bits are needed, due to

• Each address can be reused several times

across the same network

• Lower-number addresses tend to be used more

frequently

• Addresses can be compressed
• E.g., using Huffman coding

12

Is Issues ues wi with th As Asym ymme metr tric ic Li Link nks



Assume nodes communicate with bidirectional neighbors only

• All bidirectional neighbors of each node must have

distinct addresses

• The address of any inbound neighbor must be different

from all bidirectional neighbors

13

Cont ntent ent-Base Based d Add Addre ressing ing



Recall: Paradigm change from id-centric to data-centric networking in WSN



Supported by content-based names/addresses

• Do not described involved nodes (not known

anyway), but the co content nt itself the interaction is about



Classical option: Put a naming scheme on top of IP addresses

• Done by some middleware systems

14

De Descr cribing ibing In Inte terests rests



Inter eres ests ts describe relevant data/event

• Nodes match these interests with their locally
• bserved data



Format: Attribute-Value-Operation (AVO)

• E.g.: <TEMP, 20°C, GE>
• Operations:

15

Des Describing cribing In Inte tere rest/Sensor/Data st/Sensor/Data



List of AVOs



E.g.,

<type,temperature,EQ> <threshold-from-below,20,IS> <x-coordinate,20,LE> <x-coordinate,0,GE> <y-coordinate,20,LE> <y-coordinate,0,GE> <interval,0.05,IS> <duration,10,IS> <class,interest,IS>

Interest

<type,temperature,IS> <x-coordinate,10,IS> <y-coordinate,10,IS>

Sensor

<type,temperature,IS> <x-coordinate,10,IS> <y-coordinate,10,IS> <temperature,20.01,IS> <class,data,IS>

Data

16

Mat Match ching ing Al Algo gorithm rithm



Check whether an interest matches the locally available data

17

Di Dire rected cted Di Diffu ffusion ion



An example of data-centric networking

18

Ge Geographic graphic addr addressing ing



Express addresses by denoting physical position of nodes

• Considered a special case of content-based

addresses

• Attributes for x and y (and z) coordinates



Options

• Single point
• Circle or sphere centered around given point
• Rectangle by two corner points
• Polygon

19

Conclusion nclusion



Addresses can be assigned distributedly



Non-id-centric addresses give additional expressiveness, enables new interaction patterns than only using standard addresses



These addresses have to be supported by specific protocols, in particular, routing protocols