Model-driven Development of Complex
Routing Protocols with SDL-MDD
Alexander Geraldy, Reinhard Gotzhein,
and Christoph Heidinger
Networked Systems Research Group
University of Kaiserslautern, Germany
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
1
Outline
• Context
¾
• A generic routing protocol framework
• Design of ReBaC2/AodvLight
• Simulation results
• Conclusions
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
2
Context
• Model-driven development (MDD)
– engineering approach where the formal model guides and directs all
development activities
– MDD activities range from system design over code generation and
deployment to system maintenance.
– MDD is a key approach to improving quality and productivity of system
development.
• SDL-MDD
– model-driven development with SDL as design language
– addresses all phases of system development
– supported by a semantically integrated and complete tool chain
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
3
Context
Process model
formal SDL semantics
SDL language profiles
SDL design patterns
micro protocols
micro protocol framework
ConTraST
ns+SDL,
C-PartsSim
SDL Environment
Framework
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
4
Context
• Complexity of routing protocols
– different routing requirements (e.g., BE/QoS, proactive/reactive, …)
– variety of address types (e.g., unicast, multicast, concast, anycast,
broadcast, geocast, n-hop cast, …)
– large variety of routing algorithms for each address type
– different network types (e.g., wired/wireless, infrastructure-based/
ad-hoc, stationary/mobile, WAN/LAN, high-speed/field bus,
dense/sparse, …)
– optimization potential (e.g., hierarchical routing, adaptive routing,
nested routing, …)
Æ Composition of self-contained, elementary routing protocols
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
5
Outline
• Context
¾ A generic routing protocol framework
• Design of ReBaC2/AodvLight
• Simulation results
• Conclusions
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
6
A generic routing protocol framework
Application
RecvData
RoutingMiddleware
SendData
RouteReq
RouteResp
Route_
Discoverer
Packet_
Forwarder
SendData
SendData
SendData
RecvData
DeMux
RecvData
SendData
BaseTechnology
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
7
A generic routing protocol framework
Application
RecvData
RoutingMiddleware
Route_
Discoverer
SendData
RouteReq
RouteResp
SendData
Packet_
Forwarder
SendData
SendData
RecvData
DeMux
RecvData
SendData
BaseTechnology
RouteDiscoverer
RouteReq
RouteResp
RoutingManager
R1
R2
…
RoutingAdapter
Rn
SendData
RecvData
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
8
A generic routing protocol framework
RouteDiscoverer
RouteReq
RouteResp
RoutingManager
R1
R2
…
RoutingAdapter
Rn
SendData
RecvData
RoutingComponent
RouteReq
RouteResp
RoutingManager
R11
R12
…
RoutingAdapter
R1m
SendData
RecvData
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
9
Outline
• Context
• A generic routing protocol framework
¾ Design of ReBaC2/AodvLight
• Simulation results
• Conclusions
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
10
Design of ReBaC2/AodvLight
Clustering of mobile ad-hoc networks
•
subdivide the network into sets of nodes called clusters
•
nodes of a cluster are cluster members; there may be a distinguished
cluster head
•
types of clusters
– nodes with common parameters (e.g. small topological/geographical distance)
– nodes with different capabilities (e.g. coordinator role, device role)
•
hierarchical network topology Æ reduction of network complexity
•
useful for efficient network management, hierarchical routing etc.
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
11
Design of ReBaC2/AodvLight
Repair-based Clustering (ReBaC2)
•
dynamic, self-organizing process for network partitioning
•
identical rules for cluster initialization and maintenance
Æ graceful dynamic adaptation to topological changes
•
modular clustering metrics (e.g. lower/upper bounds for cluster size, bounded
cluster diameter, lower bound for link quality)
Æ adaptation to specific network situations
•
support for routing (logical tree structure
of cluster members rooted at the cluster
head, gateway nodes to neighboring clusters)
Æ proactive collection of network status information during clustering
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
12
Design of ReBaC2/AodvLight
Ad-hoc On-demand Distance Vector Routing Light (AodvLight)
•
reactive discovery of unidirectional routes (on demand)
•
search by flooding of RREQ messages
•
unidirectional response by RREPs
ReBaC2/AodvLight
•
adaptive cluster establishment and maintenance
•
proactive route discovery within clusters,
based on tree structure
•
reactive route discovery across clusters,
by flooding RREQs to cluster heads
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
13
Design of ReBaC2/AodvLight
Application
RecvData
RoutingMiddleware
Route_
Discoverer
[RecvData]
block type RoutingMiddleware
1(1)
SendData
RouteReq
RouteResp
SendData
Packet_
Forwarder
SendData
SendData
RecvData
DeMux
RecvData
SendData
BaseTechnology
[SendData]
routeDiscoverer:
ReBaC2AodvLight
[RecvData]
[Register]
[RouteReq]
pf: Packet_
[RouteResp]
Forwarder
[SendData]
[SendData]
[SendData, Register] [Register]
demux:DeMux
[RecvData]
[SendData]
deFrag:DeFragmenter
[RecvData]
[SendData]
rename: SignalRenaming
[WLANrecv]
[WLANsend]
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
14
Design of ReBaC2/AodvLight
RouteDiscoverer
block type ReBaC2AodvLight
RouteReq
RouteResp
RoutingManager
R1
R2
…
RoutingAdapter
1(1)
Rn
SendData
[RouteReq]
[RouteResp]
ReBaC2AodvManager
RecvData
[RouteResp]
[RouteReq]
rebac2:
ReBaC2
[RouteResp]
[RouteReq]
aodv:
AodvLight
[RecvData]
[SendData,Register]
[RecvData]
[SendData,Register]
ReBaC2AodvAdapter
[SendData]
[RecvData]
[Register]
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
15
Design of ReBaC2/AodvLight
RoutingComponent
block type ReBaC2
RouteReq
RouteResp
RoutingManager
R11
R12
…
RoutingAdapter
1(1)
R1m
SendData
[RouteReq]
[RouteResp]
ReBaC2Manager
RecvData
[mgmReplies]
[mgmQueries]
ReBac2Control
[(fromAlive),
aliveStat]
[(toAlive),
setCluster]
AliveSender
[alive]
AliveReceiver
[localAlive]
ReBaC2Adapter
[SendData]
[RecvData]
[Register]
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
16
Design of ReBaC2/AodvLight
RoutingComponent
block type AodvLight
RouteReq
RouteResp
RoutingManager
R11
R12
…
RoutingAdapter
1(1)
aodvManager(0,)
R1m
renaming
[RouteReq]
[RouteResp]
SendData
RecvData
aodvRoutingCache
rrr(0,):
RREQ_
Responder
rri(0,):
RREQ_
Initiator
destSeqno:
SeqNo
aodvRequestList
aodvRREQCache
srcSeqNo: SeqNo
aodvAdapter
[SendData]
[RecvData]
[Register]
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
17
Outline
• Context
• A generic routing protocol framework
• Design of ReBaC2/AodvLight
¾ Simulation results
• Conclusions
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
18
Simulation results
• 56 nodes, randomly placed
• 400x400m, tx range 73m
cluster heads
cluster links
gateway links
• 8 clusters (size 3..13)
• max path length: 5 hops
physical links
overlay links
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
19
Outline
• Context
• A generic routing protocol framework
• Design of ReBaC2/AodvLight
• Simulation results
¾ Conclusions
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
20
Conclusions
•
Model-driven development with SDL-MDD
– applicable to complex routing protocols
– tool chain fully operational and usable
•
SDL sufficiently expressive, though not always elegant
– self-contained and reusable micro protocol designs and components
– complex routing architectures
– “glue” for routing protocol composition
– SDL representation of micro protocols depends on the intended
composition
– difficulties to find an adequate data representation for the generic
addressing scheme (still SDL-96, due to available tool support)
A. Geraldy, R. Gotzhein, and C. Heidinger, University of Kaiserslautern, Germany
21