february 13, 2007 dynamic software reconfiguration in programmable networks nico janssens...

February 13, 2007

Dynamic Software Reconfiguration in Programmable Networks

Nico JanssensDistriNet, Department of Computer Science, K.U. [email protected]

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 is crucial

February 13, 2007

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

compression

decompression

February 13, 2007

Problem statement

Changing the software of a (programmable) network device off-line may potentially break the network’s availability!

February 13, 2007

Problem statement

Dynamic software reconfigurationDynamic software reconfiguration

Changing the software of a (programmable) network device off-line may potentially break the network’s availability!

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

Support is needed to conduct dynamic software reconfiguration in programmable networks

February 13, 2007

Problem statement

Main requirements1. Correct reconfigurations2. Limited reconfiguration overhead3. Limited user input4. Reusability

NeCoMan (Network reConfiguration Management): middleware coordinating dynamic

reconfigurations in programmable networks

NeCoMan (Network reConfiguration Management): middleware coordinating dynamic

reconfigurations in programmable networks

February 13, 2007

Overview

Problem statement Scope Approach Local reconfigurations Distributed reconfigurations Performance measurements Contributions and future research

February 13, 2007

Scope

dynamic software

reconfiguration

programmable networks

dynamic change management support

February 13, 2007

Scope

dynamic software

reconfiguration


dynamic software reconfiguration in out-of-band

active networks


February 13, 2007

Scope – Programmable Networks

Out-of-band active networks [Coulson 2003]

control plane

data plane

in out

service X

service Y

in outpacket

processing

node execution environment

service X

service Y

pack

et

proc

essi

ng

in out

(In-band active networks)

February 13, 2007

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

dynamic software

reconfiguration



compositional adaptation of pipe-and-filter based (network)

architectures

February 13, 2007

Scope – Dynamic software reconfiguration Compositional adaptation [McKinley 2004]

compA

compB

compC

compA

compC

compB

compA

compD

compC

compA

compC

compA

compB

compC

compA

compC

addition

replacement

removal

February 13, 2007

Scope – Node architectural style

Pipe-and-filter (network) architectures [Shaw & Garlan 1996] Click, NetScript, CANEs, NetBind, DiPS+

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

February 13, 2007

Scope

dynamic software

reconfiguration



customizable change management support for out-

of-band 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

dynamic software

reconfiguration


dynamic change management support network service

characteristics

February 13, 2007

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

compressed data packet send data packet

arrival data packet

network

Compression Component

Decompression Component

February 13, 2007

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 local and distributed reconfigurations

NeCoMan contains various predefined customizations to these algorithms pre-conditions to apply these customizations

Main requirements:1. Correct reconfigurations2. Limited reconfiguration overhead3. Limited user input4. Reusability

February 13, 2007

Approach

NeCoMan restricts the user input to 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

Main requirements:1. Correct reconfigurations2. Limited reconfiguration overhead3. Limited user input4. Reusability

February 13, 2007

ApproachMain requirements:

1. Correct reconfigurations2. Limited reconfiguration overhead3. Limited user input4. Reusability

node architecture

(local) node reconfiguration

support

node architecture


support

NeCoManAPI

-intercept packets-impose safe state-activate processes -release packets

-create-remove-link-unlink

(CuPS)

(DiPS+)

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

February 13, 2007

ApproachMain requirements:

1. Correct reconfigurations2. Limited reconfiguration overhead3. Limited user input4. Reusability

programmable node

architecture

node reconfiguration

support

synchronization messages

data packets

script generator

virtual machine

reconfiguration script

NeCoMan

node x

reconfiguration operations

separation of concerns to promote reusability script generator

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

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

install new component

finish old component

activate new component

remove old component

reconfiguration phases

reconfiguration actions

node architecture


support



Local ReconfigurationsAlgorithm for replacing component of a distributed network service

February 13, 2007

Local Reconfigurations: approach

1. Partial ordering of high-level reconfiguration phases

2. Preliminary partial ordering of NeCoMan’s reconfiguration actions

3. Partial ordering of NeCoMan’s reconfiguration actions

4. Linearization

February 13, 2007


Partial ordering of high-level reconfiguration phases result from reconfiguration conditions

(H.1)

(H.2)

(H.3)


(ICnew)


(FCold)


(ACnew)


(RCold)

February 13, 2007


Preliminary partial ordering of NeCoMan’s reconfiguration actions

(H.1)

(H.3)

(H.2)

install new component (ICnew)

CCnew

LOextnew

LOintnew

(3.1)

(3.1)

finish old component (FCold)

IPclientold

IPserverold

ISSclientold

ISSserverold

(3.2)

(3.3)

remove old component (RCold)

DCold

UOextold

UOintold

(3.6)

(3.6)

activate new component (ACnew)

LIintold-new

LIextold-new

APclientnew

RPclientnew

(3.4)

(3.4)

(3.4)

APservernew

RPservernew

(3.5)

(3.5)

(3.6)(3.6)

February 13, 2007


Partial ordering of NeCoMan’s reconfiguration actions

remove old component (RCold)

activate new component (ACnew)

DCold

UOextoldUOint

old

(3.6)(3.6)

LIintold-new LIext

old-newAPclientnew

RPclientnew

(3.4)

(3.4)

(3.4)

APservernew

RPservernew

(3.5)(3.5)

(3.9)

(3.9)(3.9)

(3.9)

(3.7)(3.7)

(3.8) (3.8)

(3.11)

(3.10)

(3.6)

(3.6)

(3.13)(3.14)

(3.13)

(3.10)

(3.11)

(3.12)

finish old component (FCold)

IPclientold IPserver

old

ISSclientold ISSserver

old

(3.2) (3.3)

install new component (ICnew)

CCnew

LOextnew LOint

new

(3.1)

(3.1)

February 13, 2007

Local Reconfigurations: approach Complete ordering of NeCoMan’s reconfiguration actions

p1 p2 p3 p4 p6 p7

intercept packets directed to old client processes:

IPclientold

install new component: ICnew

finish old component: FCold

activate new component:ACnew

remove old component:RCold

(re)link service-internal inports:

LIintold-new

delete old service component:

DCold

p15 p13 p12 p10 p9

create new service component:

CCnew

p8

p17 p16

link new service-external outports:

LOextnew

impose safe state over old server processes:

ISSserverold

impose safe state over old client processes:

ISSclientold

link new service-internal outports:

LOintnew

intercept packets directed to old server processes:

IPserverold

unlink old service-external outports:

UOextold

p11

(re)link service-external inports:

LIextold-new

activate new server processes:APserver

new

release packets for new server processes:

RPservernew

activate new client processes:APclient

new

p14

unlink old service-internal outports:

UOintold

release packets for new client processes:

RPclientnew

p5

February 13, 2007

Local Reconfigurations: example

example: replacement compression component

In RoutingCompres-

sionOut

In RoutingCompres-

sionOut

February 13, 2007


Install new component create new component link outports new component

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007


Finish old component intercept packets impose safe state

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007

Finishing

impose safe statepacket monitoring

compressed data packet

send data packet

arrival data packet

compression component

decompression component

arrival data packet

arrival data packet


send data packet


send data packet

network<<client>> <<server>>

February 13, 2007

Finishing

impose safe stateprotocol-transaction monitoring

state transfer

syn

syn+ack

ack

data

ack

fynack

open connection

send data packet

close connection

arrival data packet


retransmission component

acknowledgement component

send data packet


retransmission component

acknowledgement component

arrival data packet

send data packet

send data packet

arrival data packet

arrival data packet

February 13, 2007


Activate new component start processes link inports release packets

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007


Remove old component unlink outports old component delete old component

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007

Customizations: overview

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 pre-conditions are fulfilled)

Customization

Activate before finishing

No finishing

No processes

Only client of server processes

Only service-internal inports or outports

Addition or removal

replacement component of distributed service

addition, replacement and removal of isolated services

February 13, 2007

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

In RoutingCompres-

sionOut

Compres-sion

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007

Customization: activate before finishing

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

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007

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

In RoutingCompres-

sionOut

Compres-sion

In RoutingCompres-

sionOut

Compres-sion

February 13, 2007

Customization: no finishing

Pre-conditions the affected components operate in a best-effort network the new component is able to process all ongoing protocol-

transactions 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


February 13, 2007


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


send data packet

arrival data packet


Compression Component

Decompression Component

arrival data packet

arrival data packet


send data packet


send data packet

quiescence

February 13, 2007

Distributed Reconfigurations Algorithm for reconfigurations that involve reaching quiescence

distributed reconfigurations = actions for local reconfiguration + distributed synchronization

distributed reconfigurations = actions for local reconfiguration + distributed synchronization









@ node x @ node y

node architecture


support



node architecture


support

February 13, 2007

Distributed Reconfigurations: approach1. Partial ordering of high-level reconfiguration phases

2. Preliminary partial ordering of NeCoMan’s reconfiguration actions

3. Partial ordering of NeCoMan’s reconfiguration actions

4. Linearization

February 13, 2007

Distributed Reconfigurations: example

Example: replacement of compression service with new version

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan

Install new component• create new component• link outports new component

Install new component• create new component• link outports new component

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan

Finish old component• impose safe state

Finish old component • intercept packets • impose safe state

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan

Activate new component • start processes• link inports

Activate new component • start processes• link inports• release packets

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan

Remove old component• unlink outports old component• delete old component

Remove old component• unlink outports old component• delete old component

February 13, 2007

2 main algorithms one for reconfigurations that involve reaching quiescence another one for reconfigurations where no quiescence will be reached



February 13, 2007


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


Different algorithm replacement only (no addition and removal) no coordinated finishing no coordinated activation thus … independent execution of local reconfiguration

algorithm

February 13, 2007

Customizations: overview

8 predefined customizations resulted from re-ordering and

discarding all reconfiguration actions as well as the synchronization points that both distributed algorithms include

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

quiescence

no quiescence

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

February 13, 2007

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: exampleExample: replacement of compression service with new version

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

February 13, 2007

Activate before finishing: example

In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan

Install new component• create new component• add marking support

Install new component• create new component• link service-external outports new component• add dispatching support

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

DC

MC

NeCoMan NeCoMan

Install new component• create new component• add marking support

Install new component• create new component• link service-external outports new component• add dispatching support

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

DC

MC

NeCoMan NeCoMan

Activate new component• start processes• link inports

Activate new component• start processes

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

DC

MC

NeCoMan NeCoMan

Finish old component• impose safe state

Finish old component • intercept packets • impose safe state

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

DC

MC

NeCoMan NeCoMan

Remove old component• remove dispatching support• unlink outports old component• delete old component

Remove old component • remove marking support • unlink outports old component• delete old component

February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

MC

NeCoMan NeCoMan



February 13, 2007


In RoutingCompres-

sionOut In Routing

Decompres-sion

Out

Compres-sion

Decompres-sion

NeCoMan NeCoMan



February 13, 2007

Overview

Problem statement Scope Approach Local reconfigurations Distributed reconfiguration Performance measurements Contributions and future research

February 13, 2007

Performance measurements: test setup

O

K

N

M

L

A B

C D

T

LA B

T

February 13, 2007

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

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

NeCoMan: a middleware to dynamically reconfigure out-of-band active network

NeCoMan: a middleware to dynamically reconfigure out-of-band active network

Project RACING (FWO)Project AgCo2 (GOA)

February 13, 2007

Contributions: Dynamic Software Reconfiguration

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

Specification of the reconfiguration conditions that must be fulfilled to conduct

correct en efficient reconfigurations

Specification of the reconfiguration conditions that must be fulfilled to conduct

correct en efficient reconfigurations

February 13, 2007

Contributions: Dynamic Change Management Support

Customizable change management support to reconfigure programmable networks

Customizable change management support to reconfigure programmable networks

black box change management support

open change management support

[Hillman and Warren 2004]

• increases again the cost and risks of dynamic software reconfiguration

• reconfiguration process cannot be changed

NeCoMan

• allows to customize the reconfiguration process • still protects the user from the complexity of composing a correct and efficient reconfiguration algorithm

February 13, 2007

Future research

Programmable Networks NeCoMan cannot always select the most optimal algorithm for

each reconfiguration this requires taking into account extra context specific information

NeCoMan assumes that the execution of its actions never fails 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 dynamic software reconfiguration in programmable networks nico janssens...

Documents

networks availability

programmability slide

dynamic reconfigurations

crucial slide

future research slide

limited reconfiguration

programmable network

talk problem statement