Download Finish old component

Dynamic Software
Reconfiguration in
Programmable Networks
Nico Janssens
DistriNet, Department of
Computer Science, K.U. Leuven.
nico.janssens@cs.kuleuven.be
February 13, 2007
DistriNet


DistriNet: “Distributed Systems and Computer Networks”
development of open, distributed object support platforms for
advanced applications, using state of the art software technology

always application driven
 often conducted in close collaboration with industry

research topics include







security
middleware
mobile / sensor networks
embedded systems
autonomous and decentralized systems
software architecture
language technology
February 13, 2007
Overview of this talk
Problem statement
 Scope and background
 Approach
 Local reconfigurations
 Distributed reconfiguration
 Performance measurements
 Contributions and future research

February 13, 2007
Problem statement

Computer networks
 core
of distributed systems
 availability
February 13, 2007
is crucial
Problem statement

network functions: typically
abstracted away from end-users
and applications


intermediate nodes are (mostly)
closed vertically integrated
systems
since the mid 1990’s: various
initiatives


to open up the network
infrastructure
to increase its programmability
February 13, 2007
Problem statement

Besides programmability, also re-configurability is an
important issue!


to support the increasing evolution of network software
adaptive networks
compressio
n
February 13, 2007
decompression
Problem statement

Changing the software of a (programmable) network
device off-line may potentially break the network’s
availability!
February 13, 2007
Problem statement

Changing the software of a (programmable) network
device off-line may potentially break the network’s
availability!
Dynamic software reconfiguration
February 13, 2007
Problem statement

To be beneficial, dynamic reconfiguration must be effective and
efficient

Often complex and error prone
Support is needed to conduct dynamic software
reconfiguration in programmable networks
February 13, 2007
Problem statement
NeCoMan (Network reConfiguration
Management): middleware coordinating dynamic
reconfigurations in programmable networks

Main requirements
Correct reconfigurations
2. Limited reconfiguration overhead
3. Limited user input
4. Reusability
1.
February 13, 2007
Overview
Problem statement
 Scope
 Approach
 Local reconfigurations
 Distributed reconfigurations
 Performance measurements
 Contributions and future research

February 13, 2007
Scope
programmable
networks
dynamic
software
reconfiguration
dynamic change
management support
February 13, 2007
Scope
dynamic software
reconfiguration in out-of-band
active networks
programmable
networks
dynamic
software
reconfiguration
dynamic change
management support
February 13, 2007
Scope – Programmable Networks
Out-of-band active networks [Coulson 2003]
in
packet
processing
out
control
plane
data
plane
node execution
environment
service
X
in
out
service
Y
February 13, 2007
(In-band active networks)
in
packet
processing

service
X
out
service
Y
Scope – Programmable Networks

Dynamic software reconfiguration
 The
majority of programmable network architectures
enable the initial deployment of specific services …
 … but they do not support subsequent
reconfigurations of services that are already in use
[Hicks 2000].

exceptions include Click, Cactus, Netkit and Ensemble
February 13, 2007
Scope
compositional adaptation of
pipe-and-filter based (network)
architectures
programmable
networks
dynamic
software
reconfiguration
dynamic change
management support
February 13, 2007
Scope – Dynamic software
reconfiguration

Compositional adaptation [McKinley 2004]
comp
A
comp
A
comp
C
comp
A
comp
C
comp
B
comp
B
comp
A
comp
C
comp
C
removal addition
February 13, 2007
replacement
comp
A
comp
B
comp
C
comp
A
comp
D
comp
C
Scope – Node architectural style

Pipe-and-filter (network) architectures [Shaw &
Garlan 1996]
 Click,
In
Routing
February 13, 2007
NetScript, CANEs, NetBind, DiPS+
Compression
Out
In
Routing
Decompression
Out
Scope
programmable
networks
dynamic
software
reconfiguration
dynamic change
management support
customizable change
management support for out-ofband active networks
February 13, 2007
Scope – Dynamic change
management support



goal: improve effectiveness and efficiency of a dynamic
reconfiguration
most existing change management support conform to the black-box
philosophy
customizability needed to optimize dynamic reconfigurations

E.g. replacement compression service with new incompatible version
vs. replacement reliability service with compatible version.
February 13, 2007
Scope – Dynamic change
management support



goal: improve effectiveness and efficiency of a dynamic
reconfiguration
most existing change management support conform to the black-box
philosophy
customizability needed to optimize dynamic reconfigurations

E.g. replacement compression service with new incompatible version vs.
replacement compression service with compatible version.
February 13, 2007
Scope
programmable
networks
dynamic
software
reconfiguration
dynamic change
management support
February 13, 2007
network service
characteristics
Scope – Network services
 Isolated


network services (e.g. filter and logging service)
self-contained (no dependencies)
reactive processes
filter
February 13, 2007
Scope – Network services

Distributed network services
(e.g. compression, reliability,
fragmentation, encryption, etc.)





distributed dependencies
client-server based
collaboration
reactive processes
asynchronous buffered
communications
many-to-many service
composition
February 13, 2007
network
Compression
Component
Decompression
Component
send data packet
compressed data packet
arrival data packet
Overview
Problem statement
 Scope
 Approach
 Local reconfigurations
 Distributed reconfigurations
 Performance measurements
 Contributions and future research

February 13, 2007
Approach

NeCoMan contains 4 (basic) algorithms to carry out an
extensive set of reconfigurations


Main requirements:
1. Correct reconfigurations
2. Limited reconfiguration overhead
3. Limited user input
4. Reusability
local and distributed reconfigurations
NeCoMan contains various predefined customizations to
these algorithms

pre-conditions to apply these customizations
February 13, 2007
Approach

NeCoMan restricts the user input to




Main requirements:
1. Correct reconfigurations
2. Limited reconfiguration overhead
3. Limited user input
4. Reusability
a description of the reconfiguration that NeCoMan must carry out
a description of the service characteristics and reconfiguration
semantics
the IP addresses of all affected nodes
Based on the service characteristics and the
reconfiguration semantics, NeCoMan selects the
appropriate reconfiguration algorithm and (if
possible) applies some of the predefined
customizations to this algorithm
February 13, 2007
Approach

Main requirements:
1. Correct reconfigurations
2. Limited reconfiguration overhead
3. Limited user input
4. Reusability
separation of concerns to promote reusability

NeCoMan contains no node or service specific reconfiguration
support!
 must be provided by the nodes’ reconfiguration support


8 primitives
NeCoMan coordinates the execution of these primitives
NeCoMan
API
February 13, 2007
(CuPS)
(local) node
reconfiguration
support
(local) node
reconfiguration
support
(DiPS+)
node
architecture
node
architecture
-create
-remove
-link
-unlink
-intercept packets
-impose safe state
-activate processes
-release packets
Approach

Main requirements:
1. Correct reconfigurations
2. Limited reconfiguration overhead
3. Limited user input
4. Reusability
separation of concerns to
promote reusability


contains reconfiguration logic
composes a tailored
reconfiguration based on the
user input
(node-specific) virtual machine


executes (portable)
reconfiguration scripts
conducts the actual node
reconfiguration
script generator
reconfiguration script
script generator


NeCoMan
virtual machine
reconfiguration
operations
synchronization
messages
node
reconfiguration
support
programmable
node
architecture
data
packets
node x
February 13, 2007
Overview




Problem statement
Scope
Approach
Local reconfigurations
 Algorithms
 Customizations



Distributed reconfigurations
Performance measurements
Contributions and future research
February 13, 2007
Local Reconfigurations

2 main algorithms


replacement component of distributed service
addition, replacement and removal of isolated services


similar, will not be discussed
6 predefined customizations
February 13, 2007
Local Reconfigurations
Algorithm for replacing component of a distributed network service
-create
-remove
-link
-unlink
install new
component
-intercept packets
-impose safe state
-activate processes
-release packets
finish old
component
(local) node
reconfiguration
support
activate new
component
node
architecture
remove old
component
reconfiguration
phases
February 13, 2007
reconfiguration
actions
Local Reconfigurations: approach
1.
2.
3.
4.
Partial ordering of high-level reconfiguration phases
Preliminary partial ordering of NeCoMan’s
reconfiguration actions
Partial ordering of NeCoMan’s reconfiguration actions
Linearization
February 13, 2007
Local Reconfigurations: approach

Partial ordering of high-level reconfiguration phases

result from reconfiguration conditions
install new
component
(ICnew)
(H.1)
activate new
component
(ACnew)
(H.2)
finish old
component
(FCold)
February 13, 2007
(H.3)
remove old
component
(RCold)
Local Reconfigurations: approach

Preliminary partial ordering of NeCoMan’s
reconfiguration actions
activate new component (ACnew)
install new component (ICnew)
CCnew
(3.1)
(3.1)
LOextnew
APservernew
(3.5)
(H.1)
LIextold-new
RPservernew
int
LO
APclientnew
new
(3.5)
(3.4)
(3.4)
(3.4)
LIintold-new
finish old component (FCold)
IPclientold
(3.2)
(3.6)
UOextold
ISSclientold
(H.3)
IPserverold
(3.3)
ISSserverold
(3.6)
(H.2)
UOintold
(3.6)
(3.6)
DCold
remove old component (RCold)
February 13, 2007
RPclientnew
Local Reconfigurations: approach

Partial ordering of NeCoMan’s reconfiguration actions
finish old component
(FCold)
install new component
(ICnew)
CCnew
(3.1)
(3.7)
(3.1)
LOextnew
(3.7)
(3.10)
LO
new
(3.2)
(3.3)
ISSclientold
ISSserverold
(3.11)
(3.11)
(3.8)
(3.9)
(3.12)
(3.13)
(3.8)
APclientnew
APservernew
(3.14)
(3.13)
LIintold-new
LIextold-new
UOintold
UOextold
(3.6)
(3.6)
(3.9)
(3.9)
(3.5)
(3.5)
RP
(3.6)
(3.4)
server
new
(3.4)
RPclientnew
activate new component
(ACnew)
February 13, 2007
IPserverold
int
(3.10)
(3.9)
IPclientold
(3.4)
(3.6)
DCold
remove old component
(RCold)
Local Reconfigurations: approach

Complete ordering of NeCoMan’s reconfiguration actions
install new component:
ICnew
link new serviceexternal outports:
LOextnew
p1
p2
finish old component:
FCold
intercept packets directed
to old client processes:
IPclientold
p3
p4
create new service
component:
CCnew
link new serviceinternal outports:
LOintnew
delete old service
component:
DCold
unlink old serviceinternal outports:
UOintold
p17
p16
p15
unlink old serviceexternal outports:
UOextold
February 13, 2007
remove old component:
RCold
p14
intercept packets directed
to old server processes:
IPserverold
p6
p5
p7
impose safe state over
old client processes:
ISSclientold
release packets for
new server processes:
RPservernew
p13
release packets for
new client processes:
RPclientnew
p12
impose safe state over
old server processes:
p8
ISSserverold
(re)link serviceinternal inports:
LIintold-new
p11
(re)link serviceexternal inports:
LIextold-new
p10
activate new server
processes:
APservernew
p9
activate new client
processes:
APclientnew
activate new component:
ACnew
Local Reconfigurations: example

example: replacement compression component
February 13, 2007
In
Routing
Compression
Out
In
Routing
Compression
Out
Local Reconfigurations: example

Install new component
 create
new component
 link outports new component
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Install new component
 create
new component
 link outports new component
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Finish old component
 intercept
packets
 impose safe state
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Finish old component
 intercept
packets
 impose safe state
Compression
In
February 13, 2007
Routing
Compression
Out
Finishing
impose
safe state
 packet
monitoring
<<client>>
network
compression
component
February 13, 2007
send data
packet
compress
send data
packet
compress
send data
packet
compress
<<server>>
decompression
component
ed data p
a cke t
arrival data
packet
ed data p
a cke t
arrival data
packet
ed data p
a cke t
arrival data
packet
Finishing
impose
safe state
 protocol-transaction
<<client>>
send data
packet
<<server>>
<<client>>
acknowledgement
component
retransmission
component
network
retransmission
component
data pack
et 1
t1
a ck p a cke
send data
packet
send data
packet
data pack
et 2
a ck p a cke
t2
cke t 3
a ck p a
 state
February 13, 2007
monitoring
transfer
arrival data
packet
arrival data
packet
arrival data
packet
open
connection
send data
packet
close
connection
network
<<server>>
acknowledgement
component
syn
syn+ack
ack
data
ack
fyn
ack
arrival data
packet
Local Reconfigurations: example

Activate new component
 start
processes
 link inports
 release packets
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Activate new component
 start
processes
 link inports
 release packets
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Activate new component
 start
processes
 link inports
 release packets
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Remove old component
 unlink
outports old component
 delete old component
Compression
In
February 13, 2007
Routing
Compression
Out
Local Reconfigurations: example

Remove old component
 unlink
outports old component
 delete old component
Compression
In
February 13, 2007
Routing
Compression
Out
addition, replacement
and removal of
isolated services
Customizations: overview

replacement
component of
distributed service
6 predefined customizations

resulted from re-ordering and
discarding all reconfiguration
actions that both local
algorithms include
 from these combinations, we
selected the customizations
that limit the reconfiguration
overhead and still yield a
valid reconfiguration (given
that some additional preconditions are fulfilled)
February 13, 2007
Customization
Activate before finishing


No finishing


No processes


Only client of server processes


Only service-internal inports or
outports


Addition or removal


Customization: activate before
finishing


communication is disrupted as from intercepting packets
until they are released again
however … this disruption can be reduced by activating
the new component before finishing the old one
Compression
Compression
In
Routing
February 13, 2007
Compression
Out
In
Routing
Compression
Out
Customization: activate before
finishing
Compression
In

Routing
Compression
Pre-conditions
 the
old component is stateless
 the new service component is able to process all
ongoing protocol-transactions
 the network tolerates packet re-ordering

Effect
 activation
phase becomes executed before the
finishing phase
 no packet interception
February 13, 2007
Out
Customization: no finishing


for some reconfigurations, there is no need to finish the
old service
e.g. when replacing a compression component in a
TCP/IP network

old component can be removed without reaching a
reconfiguration-safe state
Compression
In
Routing
February 13, 2007
Compression
Compression
Out
In
Routing
Compression
Out
Customization: no finishing

Pre-conditions



the affected components operate in a best-effort network
the new component is able to process all ongoing protocoltransactions
inconsistent execution states (if any) do not compromise the
correct functioning of the network


e.g. for stateless components
Effect


old component will not be finished
may reduce communication disruption...
 … if inconsistencies do not impact the network performance!
February 13, 2007
Overview





Problem statement
Scope
Approach
Local reconfigurations
Distributed reconfiguration
 Algorithms
 Customizations


Performance measurements
Contributions and future research
February 13, 2007
Distributed Reconfigurations

2 main algorithms

one for reconfigurations that involve reaching quiescence
 another one for reconfigurations where no quiescence will be reached

8 predefined customizations
February 13, 2007
Distributed Reconfigurations

Quiescence [Kramer & Magee 1990]
 service
is frozen and consistent
 applied to distributed network services:


all ongoing protocol-transactions have completed
no new protocol-transactions will be initiated until after the
reconfiguration actions have completed
<<client>>
network
Compression
Component
send data packet
send data packet
send data packet
February 13, 2007
Decompression
Component
co m
co m
<<server>>
p re s
c o mp
se d
data
p a ck
se d
et
data
p a ck
r e sse
et
d dat
a pac
ke t
p re s
quiescence
arrival data packet
arrival data packet
arrival data packet
Distributed Reconfigurations

Algorithm for reconfigurations that involve reaching quiescence
@ node x
@ node y
install new
component
install new
component
finish old
component
finish old
component
activate new
component
remove old
component
-create
-remove
-link
-unlink
-intercept packets
-impose safe state
-activate processes
-release packets
activate new
component
(local) node
reconfiguration
support
(local) node
reconfiguration
support
remove old
component
node
architecture
node
architecture
distributed reconfigurations = actions for local
reconfiguration + distributed synchronization
February 13, 2007
Distributed Reconfigurations:
approach
1.
2.
3.
4.
Partial ordering of high-level reconfiguration phases
Preliminary partial ordering of NeCoMan’s
reconfiguration actions
Partial ordering of NeCoMan’s reconfiguration actions
Linearization
February 13, 2007
Distributed Reconfigurations:
example
Example: replacement of
compression service with
new version
In
Routing
Compression
Out
In
Routing
Decompression
Out
In
Routing
Compression
Out
In
Routing
Decompression
Out
February 13, 2007
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Install new component
• create new component
• link outports new component
February 13, 2007
In
Routing
Decompression
Out
NeCoMan
Install new component
• create new component
• link outports new component
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Install new component
• create new component
• link outports new component
February 13, 2007
In
Routing
Decompression
Out
NeCoMan
Install new component
• create new component
• link outports new component
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
In
Routing
Decompression
NeCoMan
Finish old component
• impose safe state
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
In
Routing
Decompression
NeCoMan
Finish old component
• impose safe state
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
In
Routing
Decompression
NeCoMan
Finish old component
• impose safe state
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
In
Routing
Decompression
NeCoMan
Finish old component
• impose safe state
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Activate new component
• start processes
• link inports
• release packets
February 13, 2007
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
• link inports
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Activate new component
• start processes
• link inports
• release packets
February 13, 2007
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
• link inports
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Activate new component
• start processes
• link inports
• release packets
February 13, 2007
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
• link inports
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Activate new component
• start processes
• link inports
• release packets
February 13, 2007
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
• link inports
Out
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Remove old component
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
Out
NeCoMan
Remove old component
• unlink outports old component
• delete old component
Distributed Reconfigurations:
example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Remove old component
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
Out
NeCoMan
Remove old component
• unlink outports old component
• delete old component
Distributed Reconfigurations

2 main algorithms

one for reconfigurations that involve reaching quiescence
 another one for reconfigurations where no quiescence will be reached

8 predefined customizations
February 13, 2007
Distributed Reconfigurations

Monitoring for quiescence can be very time consuming (may
significantly delay the reconfiguration)

when many protocol-transactions are active at the same time (e.g. many
compressed packets in transit)
 when it takes a long time for the ongoing protocol-transaction to complete
(e.g. TCP protocol)


In some cases it may even be impossible to reach a quiescent state,
for instance because the employed protocol is non-deterministic
Alternative for quiescence

deactivating the affected components immediately at each node
independently
 restoring consistency by transferring the execution state of the old
components to the new ones
February 13, 2007
Distributed Reconfigurations

Different algorithm
 replacement
only (no addition and removal)
 no coordinated finishing
 no coordinated activation
 thus … independent execution of local reconfiguration
algorithm
February 13, 2007
no quiescence
Customizations: overview
quiescence

8 predefined customizations

resulted from re-ordering and
discarding all reconfiguration
actions as well as the
synchronization points that
both distributed algorithms
include
February 13, 2007
Customization
No coordinated activation
 
Activate before finishing
 
No finishing
 
No finishing of server processes
 
No processes
 
Only client of server processes
 
Only service-internal inports or
outports
 
Addition or removal
 
Customizations: no coordinated
activation

Example

replacing the components of a compression service where the old and
new processes are able to accept and service each others
invocations
 adding a compression service on two programmable nodes when the
network or the applications can deal with (or filter out) compressed
packets

Effect


no distributed synchronization when activating the new service  less
communication disruption
Pre-conditions

old and new service components are compatible, or


in case of replacement
the network is able to deal with incorrect service compositions

in case of addition or removal
Customization: no coordinated
activation

resulting algorithm
 no
coordinated activation
 no coordinated finishing
 thus … independent execution of local reconfiguration
algorithm
February 13, 2007
Customizations: activate before
finishing

Pre-conditions
 the
old service components do not share their
execution state (if any) with their client applications
 if these components encapsulate execution state  no
state transfer
 the network tolerates packet re-ordering

Effect
 packet
marking and dispatching
 3 instead of 2 synchronization messages
 no packet interception
February 13, 2007
Activate before finishing: example
Example: replacement of
compression service with
new version
In
Routing
Compression
Out
In
Routing
Decompression
Out
In
Routing
Compression
Out
In
Routing
Decompression
Out
February 13, 2007
Activate before finishing: example
Compression
In
Routing
Compression
NeCoMan
Install new component
• create new component
• add marking support
February 13, 2007
Decompression
Out
In
Routing
Decompression
NeCoMan
Install new component
• create new component
• link service-external outports new
component
• add dispatching support
Out
Activate before finishing: example
Compression
In
Routing
Compression
NeCoMan
Install new component
• create new component
• add marking support
February 13, 2007
Decompression
Out
In
Routing
Decompression
Out
NeCoMan
Install new component
• create new component
• link service-external outports new
component
• add dispatching support
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Install new component
• create new component
• add marking support
February 13, 2007
Out
In
Routing
Decompression
NeCoMan
Install new component
• create new component
• link service-external outports new
component
• add dispatching support
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Activate new component
• start processes
• link inports
February 13, 2007
Out
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Activate new component
• start processes
• link inports
February 13, 2007
Out
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Activate new component
• start processes
• link inports
February 13, 2007
Out
In
Routing
Decompression
NeCoMan
Activate new component
• start processes
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
Out
In
Decompression
Routing
NeCoMan
Finish old component
• impose safe state
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
Out
In
Decompression
Routing
NeCoMan
Finish old component
• impose safe state
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
NeCoMan
Finish old component
• intercept packets
• impose safe state
February 13, 2007
Out
In
Decompression
Routing
NeCoMan
Finish old component
• impose safe state
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
Out
NeCoMan
Remove old component
• remove marking support
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
NeCoMan
Remove old component
• remove dispatching support
• unlink outports old component
• delete old component
Out
Activate before finishing: example
Compression
Decompression
MC
DC
In
Routing
Compression
Out
NeCoMan
Remove old component
• remove marking support
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
NeCoMan
Remove old component
• remove dispatching support
• unlink outports old component
• delete old component
Out
Activate before finishing: example
Compression
In
Routing
Compression
Decompression
MC
Out
NeCoMan
Remove old component
• remove marking support
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
NeCoMan
Remove old component
• remove dispatching support
• unlink outports old component
• delete old component
Out
Activate before finishing: example
Compression
In
Routing
Compression
Decompression
Out
NeCoMan
Remove old component
• remove marking support
• unlink outports old component
• delete old component
February 13, 2007
In
Routing
Decompression
NeCoMan
Remove old component
• remove dispatching support
• unlink outports old component
• delete old component
Out
Overview
Problem statement
 Scope
 Approach
 Local reconfigurations
 Distributed reconfiguration
 Performance measurements
 Contributions and future research

February 13, 2007
Performance measurements: test
setup
T
A
K
M
B
L
C
N
February 13, 2007
T
A
O
D
L
B
Communication disruption: add
compression
February 13, 2007
Communication disruption: replace
compression
February 13, 2007
Communication disruption: remove
compression
February 13, 2007
Communication disruption: add
reliability
February 13, 2007
Communication disruption: replace
reliability
February 13, 2007
Communication disruption: remove
reliability
February 13, 2007
Overview
Problem statement
 Scope
 Approach
 Local reconfigurations
 Distributed reconfiguration
 Performance measurements
 Contributions and future research

February 13, 2007
Contributions: Programmable Networks
NeCoMan: a middleware to dynamically
reconfigure out-of-band active network


Extensive analytical validation
Proof-of-concept prototype

DiPS+ node architecture






Project PEPITA (ITEA)
Project SCAN (IWT)
CuPS node reconfiguration support
NeCoMan DiPS+ VM
NeCoMan script generator
Performance evaluation
February 13, 2007
Project RACING (FWO)
Project AgCo2 (GOA)
Contributions: Dynamic Software
Reconfiguration
Specification of the reconfiguration
conditions that must be fulfilled to conduct
correct en efficient reconfigurations


these reconfiguration conditions specify the partial
ordering of the identified reconfiguration actions
benefits of making these conditions explicit:


they provide some guidance for the development of future
reconfiguration support
they allow to reason about the reconfiguration process
February 13, 2007
Contributions: Dynamic Change
Management Support
black box change
management support
• reconfiguration process
cannot be changed
NeCoMan
open change
management support
[Hillman and Warren 2004]
• increases again the cost
and risks of dynamic
software reconfiguration
• allows to customize the reconfiguration process
• still protects the user from the complexity of composing a
correct and efficient reconfiguration algorithm
Customizable change management support to
reconfigure programmable networks
February 13, 2007
Future research

Programmable Networks

NeCoMan cannot always select the most optimal algorithm for
each reconfiguration


NeCoMan assumes that the execution of its actions never fails


this requires taking into account extra context specific information
requires failure recovery support
Other research areas



Reflective middleware
Middleware for transparent application reconfiguration
Dynamic distributed aspect weaving
February 13, 2007
Thank you for your
attention!
February 13, 2007