Dynamic Software Reconfiguration in Programmable Networks

1. Dynamic Software Reconfiguration in Programmable Networks Nico Janssens DistriNet, Department of Computer Science, K.U. Leuven. nico.janssens@cs.kuleuven.be

2. 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

3. Overview of this talk • Problem statement • Scope and background • Approach • Local reconfigurations • Distributed reconfiguration • Performance measurements • Contributions and future research

4. Problem statement • Computer networks • core of distributed systems • availability is crucial

5. 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

6. compression decompression Problem statement • Besides programmability, also re-configurability is an important issue! • to support the increasing evolution of network software • adaptive networks

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

8. Problem statement • Changing the software of a (programmable) network device off-line may potentially break the network’s availability! Dynamic software reconfiguration

9. 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

10. Problem statement • Main requirements • Correct reconfigurations • Limited reconfiguration overhead • Limited user input • Reusability NeCoMan (Network reConfiguration Management): middleware coordinating dynamic reconfigurations in programmable networks

11. Overview • Problem statement • Scope • Approach • Local reconfigurations • Distributed reconfigurations • Performance measurements • Contributions and future research

12. Scope dynamic software reconfiguration programmable networks dynamic change management support

13. dynamic software reconfiguration in out-of-band active networks programmable networks Scope dynamic software reconfiguration dynamic change management support

14. Scope – Programmable Networks • Out-of-band active networks [Coulson 2003] (In-band active networks)

15. 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

16. compositional adaptation of pipe-and-filter based (network) architectures dynamic software reconfiguration Scope programmable networks dynamic change management support

17. Compositional adaptation [McKinley 2004] Scope – Dynamic software reconfiguration removal addition replacement

18. Scope – Node architectural style • Pipe-and-filter (network) architectures [Shaw & Garlan 1996] • Click, NetScript, CANEs, NetBind, DiPS+

19. dynamic change management support customizable change management support for out-of-band active networks Scope dynamic software reconfiguration programmable networks

20. 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.

21. 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.

22. network service characteristics Scope dynamic software reconfiguration programmable networks dynamic change management support

23. Scope – Network services • Isolated network services (e.g. filter and logging service) • self-contained (no dependencies) • reactive processes filter

24. 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

25. Overview • Problem statement • Scope • Approach • Local reconfigurations • Distributed reconfigurations • Performance measurements • Contributions and future research

26. Approach • Main requirements: • Correct reconfigurations • Limited reconfiguration overhead • Limited user input • Reusability • 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

27. Approach • Main requirements: • Correct reconfigurations • Limited reconfiguration overhead • Limited user input • Reusability • 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

28. Approach • Main requirements: • Correct reconfigurations • Limited reconfiguration overhead • Limited user input • 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

29. Approach • Main requirements: • Correct reconfigurations • Limited reconfiguration overhead • Limited user input • Reusability • 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

30. Overview • Problem statement • Scope • Approach • Local reconfigurations • Algorithms • Customizations • Distributed reconfigurations • Performance measurements • Contributions and future research

31. 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

32. Local Reconfigurations Algorithm for replacing component of a distributed network service

33. Local Reconfigurations: approach • Partial ordering of high-level reconfiguration phases • Preliminary partial ordering of NeCoMan’s reconfiguration actions • Partial ordering of NeCoMan’s reconfiguration actions • Linearization

34. Local Reconfigurations: approach • Partial ordering of high-level reconfiguration phases • result from reconfiguration conditions

35. Local Reconfigurations: approach • Preliminary partial ordering of NeCoMan’s reconfiguration actions

36. Local Reconfigurations: approach • Partial ordering of NeCoMan’s reconfiguration actions

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

38. Local Reconfigurations: example • example: replacement compression component

39. Local Reconfigurations: example • Install new component • create new component • link outports new component

40. Local Reconfigurations: example • Install new component • create new component • link outports new component

41. Local Reconfigurations: example • Finish old component • intercept packets • impose safe state

42. Local Reconfigurations: example • Finish old component • intercept packets • impose safe state

43. Finishing • impose safe state • packet monitoring

44. Finishing • impose safe state • protocol-transaction monitoring • state transfer

45. Local Reconfigurations: example • Activate new component • start processes • link inports • release packets

46. Local Reconfigurations: example • Activate new component • start processes • link inports • release packets

47. Local Reconfigurations: example • Activate new component • start processes • link inports • release packets

48. Local Reconfigurations: example • Remove old component • unlink outports old component • delete old component

49. Local Reconfigurations: example • Remove old component • unlink outports old component • delete old component

50. Customizations: overview • addition, replacement and removal of isolated services • 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 pre-conditions are fulfilled)