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

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

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

4. February 13, 2007 Problem statement Computer networks  core of distributed systems  availability is crucial

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

6. 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 decompression

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

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

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

10. February 13, 2007 Problem statement Main requirements 1. Correct reconfigurations 2. Limited reconfiguration overhead 3. Limited user input 4. Reusability NeCoMan (Network reConfiguration Management): middleware coordinating dynamic reconfigurations in programmable networks

11. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations Distributed reconfigurations Performance measurements Contributions and future research

12. February 13, 2007 Scope dynamic software reconfiguration programmable networks dynamic change management support

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

14. February 13, 2007 Scope – Programmable Networks Out-of-band active networks [Coulson 2003] (In-band active networks)

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

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

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

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

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

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

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

22. February 13, 2007 Scope dynamic software reconfiguration programmable networks dynamic change management support network service characteristics

23. February 13, 2007 Scope – Network services Isolated network services (e.g. filter and logging service)  self-contained (no dependencies)  reactive processes filter

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

25. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations Distributed reconfigurations Performance measurements Contributions and future research

26. 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 reconfigurations 2. Limited reconfiguration overhead 3. Limited user input 4. Reusability

27. 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 reconfigurations 2. Limited reconfiguration overhead 3. Limited user input 4. Reusability

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

29. 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  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. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations  Algorithms  Customizations Distributed reconfigurations Performance measurements Contributions and future research

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

32. February 13, 2007 Local Reconfigurations Algorithm for replacing component of a distributed network service

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

34. February 13, 2007 Local Reconfigurations: approach Partial ordering of high-level reconfiguration phases  result from reconfiguration conditions

35. February 13, 2007 Local Reconfigurations: approach Preliminary partial ordering of NeCoMan’s reconfiguration actions

36. February 13, 2007 Local Reconfigurations: approach Partial ordering of NeCoMan’s reconfiguration actions

37. February 13, 2007 Local Reconfigurations: approach Complete ordering of NeCoMan’s reconfiguration actions

38. February 13, 2007 Local Reconfigurations: example example: replacement compression component

39. February 13, 2007 Local Reconfigurations: example Install new component  create new component  link outports new component

40. February 13, 2007 Local Reconfigurations: example Install new component  create new component  link outports new component

41. February 13, 2007 Local Reconfigurations: example Finish old component  intercept packets  impose safe state

42. February 13, 2007 Local Reconfigurations: example Finish old component  intercept packets  impose safe state

43. February 13, 2007 Finishing impose safe state  packet monitoring

44. February 13, 2007 Finishing impose safe state  protocol-transaction monitoring  state transfer

45. February 13, 2007 Local Reconfigurations: example Activate new component  start processes  link inports  release packets

46. February 13, 2007 Local Reconfigurations: example Activate new component  start processes  link inports  release packets

47. February 13, 2007 Local Reconfigurations: example Activate new component  start processes  link inports  release packets

48. February 13, 2007 Local Reconfigurations: example Remove old component  unlink outports old component  delete old component

49. February 13, 2007 Local Reconfigurations: example Remove old component  unlink outports old component  delete old component

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

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

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

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

54. 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!

55. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations Distributed reconfiguration  Algorithms  Customizations Performance measurements Contributions and future research

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

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

58. February 13, 2007 Distributed Reconfigurations Algorithm for reconfigurations that involve reaching quiescence distributed reconfigurations = actions for local reconfiguration + distributed synchronization

59. February 13, 2007 Distributed 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

60. February 13, 2007 Distributed Reconfigurations: example Example: replacement of compression service with new version

61. February 13, 2007 Distributed Reconfigurations: example Install new component create new component link outports new component Install new component create new component link outports new component

62. February 13, 2007 Distributed Reconfigurations: example Install new component create new component link outports new component Install new component create new component link outports new component

63. February 13, 2007 Distributed Reconfigurations: example Finish old component impose safe state Finish old component intercept packets impose safe state

64. February 13, 2007 Distributed Reconfigurations: example Finish old component impose safe state Finish old component intercept packets impose safe state

65. February 13, 2007 Distributed Reconfigurations: example Finish old component impose safe state Finish old component intercept packets impose safe state

66. February 13, 2007 Distributed Reconfigurations: example Finish old component impose safe state Finish old component intercept packets impose safe state

67. February 13, 2007 Distributed Reconfigurations: example Activate new component start processes link inports Activate new component start processes link inports release packets

68. February 13, 2007 Distributed Reconfigurations: example Activate new component start processes link inports Activate new component start processes link inports release packets

69. February 13, 2007 Distributed Reconfigurations: example Activate new component start processes link inports Activate new component start processes link inports release packets

70. February 13, 2007 Distributed Reconfigurations: example Activate new component start processes link inports Activate new component start processes link inports release packets

71. February 13, 2007 Distributed Reconfigurations: example Remove old component unlink outports old component delete old component Remove old component unlink outports old component delete old component

72. February 13, 2007 Distributed Reconfigurations: example Remove old component unlink outports old component delete old component Remove old component unlink outports old component delete old component

73. February 13, 2007 2 main algorithms  one for reconfigurations that involve reaching quiescence  another one for reconfigurations where no quiescence will be reached 8 predefined customizations Distributed Reconfigurations

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

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

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

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

78. February 13, 2007 Customization: no coordinated activation resulting algorithm  no coordinated activation  no coordinated finishing  thus … independent execution of local reconfiguration algorithm

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

80. February 13, 2007 Activate before finishing: example Example: replacement of compression service with new version

81. February 13, 2007 Activate before finishing: example Install new component create new component add marking support Install new component create new component link service-external outports new component add dispatching support

82. February 13, 2007 Activate before finishing: example Install new component create new component add marking support Install new component create new component link service-external outports new component add dispatching support

83. February 13, 2007 Activate before finishing: example Install new component create new component add marking support Install new component create new component link service-external outports new component add dispatching support

84. February 13, 2007 Activate before finishing: example Activate new component start processes link inports Activate new component start processes

85. February 13, 2007 Activate before finishing: example Activate new component start processes link inports Activate new component start processes

86. February 13, 2007 Activate before finishing: example Activate new component start processes link inports Activate new component start processes

87. February 13, 2007 Activate before finishing: example Finish old component impose safe state Finish old component intercept packets impose safe state

88. February 13, 2007 Activate before finishing: example Finish old component impose safe state Finish old component intercept packets impose safe state

89. February 13, 2007 Activate before finishing: example Finish old component impose safe state Finish old component intercept packets impose safe state

90. February 13, 2007 Activate before finishing: example 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

91. February 13, 2007 Activate before finishing: example 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

92. February 13, 2007 Activate before finishing: example 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

93. February 13, 2007 Activate before finishing: example 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

94. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations Distributed reconfiguration Performance measurements Contributions and future research

95. February 13, 2007 Performance measurements: test setup

96. February 13, 2007 Communication disruption: add compression

97. February 13, 2007 Communication disruption: replace compression

98. February 13, 2007 Communication disruption: remove compression

99. February 13, 2007 Communication disruption: add reliability

100. February 13, 2007 Communication disruption: replace reliability

101. February 13, 2007 Communication disruption: remove reliability

102. February 13, 2007 Overview Problem statement Scope Approach Local reconfigurations Distributed reconfiguration Performance measurements Contributions and future research

103. 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 Project RACING (FWO) Project AgCo2 (GOA)

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

105. February 13, 2007 Contributions: Dynamic Change Management Support 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

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

107. February 13, 2007 Thank you for your attention!