Middleware issues: Middleware issues: From P2P systems to Ad Hoc From P2P systems to Ad Hoc Networks Networks Franca Delmastro Franca Delmastro [email protected][email protected]Pervasive Computing & Networking Lab Pervasive Computing & Networking Lab (PerLab) (PerLab) IIT-CNR Pisa IIT-CNR Pisa MobileMAN Project MobileMAN Project Helsinki, June 7 Helsinki, June 7 th th 2004 2004
21
Embed
Middleware issues: From P2P systems to Ad Hoc Networks
Middleware issues: From P2P systems to Ad Hoc Networks. Franca Delmastro [email protected] Pervasive Computing & Networking Lab (PerLab) IIT-CNR Pisa MobileMAN Project Helsinki, June 7 th 2004. Middleware for Ad Hoc networks. Ad Hoc networks and P2P systems: - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Middleware issues:Middleware issues:From P2P systems to Ad Hoc From P2P systems to Ad Hoc
MobileMAN ProjectMobileMAN ProjectHelsinki, June 7Helsinki, June 7th th 20042004
Middleware for Ad Hoc networks
Ad Hoc networks and P2P systems:
The distribution of services and data can fit well with the decentralized nature of Ad Hoc networks
In both cases nodes interactions are temporary
Resources are distributed among heterogeneous nodes
Systems must be reliable in case of node failures and disconnections events
The fundamentals of the structured overlay network
CAN, Chord, Pastry et al. represents a family of middleware solutions for large-scale P2P systems
They use a Distributed Hash Function (DHT) to map physical addresses to a logical address space
Information and workload are uniformely distributed on the network
System scalability with the number of nodes is the main objective for ad hoc networks
The Pastry model
The overlay network is a circular address space where nodes and data are logically mapped.
There is no correspondence between logical and physical distances
Subject-based routing reduce the lookup cost to a logarithmic cost
There are a lot of applications implemented for this solution, and many others are adaptable to this routing policy
Logical & Physical distances
Pastry Ring0 2128 - 1
The Pastry Ring
N1
X1 = H(N1)
N2
X2 = H(N2)
L1
X1
X2
L2
(K2 ,V)
L2 = H(K2 )
(K1 ,V)
L1 = H(K1)
0 2128 - 1
Pastry routing tables
0 2128 - 1
10233001
10233232
02212102
11301233
10323302
10233102
Pastry Multi-hop Routing
23000101
02212102
Route(23302121)
23301101
23301201
33301201
0 2128 - 1
22301203
10233102
bestMatch(RoutingTable[0], 23302121 ) =
22301203
Compare(10233102, 23302121) = 0
Joining the Ring
X has to know a own physical neighbor already present in the ring (node A)
A sends a message with key equal to X
Pastry Routing table of node X is initialized using routing tables of contacted nodes:
LS(X) = LS(Z)
NS(X) = NS(A)
RT(X) is a join of the routing tables of other nodes, according to the prefix shared metric
A
B1
B2
Bk
Z
0 2128 - 1
X
Join(X)
Route(X)
X
Disconnection from the ring
Each node executes a polling procedure to discover “remote” nodes status (referred only to routing table knowledge).
A “remote” node is considered disconnected from the Pastry network if it doesn’t answer to a polling message before a timeout expiration
After a disconnection event, the sender of the polling message has to update its routing tables contacting other “remote” nodes to fill in entries related to that node.
Pastry Pros & Cons
Pros: DHT allows an uniform distribution of IDs and
workload on nodes providing the service The subject-based routing defines a logarithmic
lookup cost on the network dimension (O(log N)) A lot of application can adapt their contents to
this routing strategy
Cons: Routing tables management based on remote
connections can be a big overhead for ad hoc networks
Forcing the network routing with the subject-based policy can reduce network performances
NeSt
Applications
Middleware
Transport
Network
MAC
Using Cross-Layer to CROSS-ROAD
In order to build an overlay network, the middleware can directly use the Network Routing table.
Node ID = H(IPaddress)
Since each ring is associated to a service, the routing protocol has to provide Service Location
Using a proactive LINK-STATE routing protocol, each node knows the entire network
CROSS-layer Ring Overlay for AD hoc networks
Hazy Sighted Link-State
Optimization of Proactive routing protocols
Each node sends periodical LSU packets on the network with frequencies inversary proportional to the routing hops number.
“Hazy” knowledge of distant nodes. Their status is not frequently updated as the 1-hop neighbors.
(*) C. Santivanez, I. Stavrakakis et al., “Making Link-State Routing Scale for Ad Hoc Networks”, MobiHoc 2001(*) C. Santivanez, I. Stavrakakis et al., “On the Scalability of Ad Hoc Routing Protocols”, INFOCOM 2002
Middleware level
A
B
CROSS-ROAD overlay
Nodes providing service S
Ad Hoc Network nodes
Network level
Working hypothesis:
The Network level gives a graph representing the network topology to the Nest
Each node has to be characterized by at least:
(IPaddress, Services, 1hop-neighbors)
The middleware level can access to this graph and recover relevant information for itself
A
B
Interactions with NeSt
NeSt
NetworkData
Abstraction
MiddlewareData
AbstractionMiddleware
Network
Node A
Middleware
Network
NeSt
NetworkData
Abstraction
MiddlewareData
Abstraction
Node BLocal
Provided services
LSU routing pkt containing services
publications and topology updates
Topology update and
remote servicesApplication
messages
CROSS-ROAD Routing Tables
Each node defines the ring autonomously
CROSS-ROAD routing table contains only nodes provide the service (Leafset and Neighborset disappear)
Middleware routing protocol is limited to a peer-to-peer connection
Messages forwarding is realized by the network routing protocol
Network Routing Table
Destination IP
address
Next Hop IP add.
Cost Services
CROSS-ROAD Routing Table
Destination ID = H(IP
address)
Cost
Pastry vs CROSS-ROAD PASTRY:
Join operation requires many remote connections to recover routing tables contents
CROSS-ROAD: Join operation does not
require remote connections: each node can build its ring autonomously
HIGH COST at middleware level
NO COST at middleware level
Pastry vs CROSS-ROAD PASTRY:
The detection of disconnection events requires polling cycles towards remote nodes
CROSS-ROAD: Disconnection events
are detected by the netwrok routing protocol through LSU packets
HIGH COST at middleware level
NO COST at middleware level
Pastry vs CROSS-ROAD PASTRY:
Routing table fixed size involves a not complete knowledge of the network
CROSS-ROAD: Routing table size
depends on the number of nodes taking part to the service
HIGH COST for tables management due to remote connections following topology
updates
NO COST at middleware level: local interactions with NeSt are sufficient to update routing tables
Pastry vs CROSS-ROAD PASTRY:
Subject-based routing involves a multi-hop middleware routing