* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Finish old component
Survey
Document related concepts
Multiprotocol Label Switching wikipedia , lookup
Network tap wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Computer network wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Backpressure routing wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Deep packet inspection wikipedia , lookup
Distributed firewall wikipedia , lookup
Airborne Networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Distributed operating system wikipedia , lookup
Service-oriented architecture implementation framework wikipedia , lookup
Transcript
Dynamic Software Reconfiguration in Programmable Networks Nico Janssens DistriNet, Department of Computer Science, K.U. Leuven. [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 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