5-NC 292 by tabindah


More Info
									  A Solution for Backward-Compatible Reconfigurations of Running
               Protocol Components in Protocol Stacks

                                           Mahdi Niamanesh
                                 Department of Computer Engineering
                              Sharif University of Technology, Tehran, Iran
                                               Rasool Jalili
                                 Department of Computer Engineering
                              Sharif University of Technology, Tehran, Iran


   Forthcoming networked systems require mechanisms for on-the-fly reconfigurations in their protocol stacks to
be able to operate in different situations and networks. Backward-compatible reconfigurations of protocols are
fast and easy ways for new protocol distributions. However, performing such reconfigurations at run-time and
for running protocol components, without disrupting peer components, is more desirable. This paper proposes a
solution for dynamic reconfiguration management that can transparently reconfigure running protocol components
in the middle of their protocol transaction. Mechanisms for the reconfiguration management including finding safe
states as well as state transfer are proposed. For demonstration, we have implemented a prototype of the solution
to reconfigure a running TCP component. Our experimental results on dynamic reconfigurations show that an
acceptable transparency (through providing a short time for the freeze period) can be maintained using the proposed

     UbiCC Journal, Volume 4, Number 3, August 2009                                                           784
1   Introduction                                            They can reconfigure running protocols in safe states
                                                            that can be in the middle of protocol transactions. In
   Future communication and computation world, known        these approaches, reconfiguration of a protocol com-
as pervasive computing environment, includes wireless       ponent should be transparent in the peer component’s
networks, networked systems and devices with hetero-        point of view.
geneous standards and protocols for different contexts          In this paper, the reconfiguration problem is defined
and situations [25]. The Software Radio technology [3]      as changing one of the peer stacks at run-time transpar-
offers dynamic reconfigurability for protocol stacks of       ently. Unlike the related work, we can reconfigure run-
such systems and devices in order to facilitate applica-    ning protocol components in the middle of their proto-
tions such as changing routing algorithms of switches,      col transaction. For such a reconfiguration, we propose
changing security modules in protocol stacks, bug fix-       a procedure for reconfiguration management and con-
ing, and customizing protocol stack of a device for bet-    trol. The procedure employs two ideas; we propose
ter performance.                                            every protocol has a data structure for representing
   In general, in a software system, dynamic reconfig-       its state (called PCB); and protocol developers mark
uration of a component to a new one includes such           some states as safe states for staring possible reconfig-
phases as freeze (stopping the current execution of the     urations.
component), change (adding/binding a new component             The rest of this paper is organized as follows. Sec-
and unbinding/removing the unnecessary old compo-           tion 2 describes backgrounds about protocol executions
nent from the system), state transfer (finding and ini-      and reconfiguration assurance in protocol stacks. In
tializing a proper state in the new component in order      Section 3, we explain the proposed solution for backward-
to resume the execution), and re-execution (resuming        compatible reconfigurations in protocol stacks. Mech-
the execution from a non-initial state in the new com-      anisms for assurance and also the reconfiguration pro-
ponent) [19]. In order to have assured reconfiguration,      cedure are presented. In Section 4, we describe imple-
the old component should be frozen in a “safe state”        mentation and evaluation of the solution. In Section
and the new component should resume the execution           5, we discuss related work and Section 6 concludes the
from a “reachable” state [10].                              paper.
   In the context of protocol stack reconfiguration, since
each protocol is defined at least between two peer com-      2     Background
ponents, reconfiguration of a running protocol compo-
nent may require a corresponding reconfiguration in             In this section, we describe a simple model for proto-
the peer component(s). However, by backward-compatible      col execution and explain assurance in reconfigurations
changes of a protocol component, the protocol reconfig-      of protocol stacks.
uration can be carried out in the component indepen-
dently without disrupting its peer component. As an         2.1    Protocol Execution
example, consider a reconfiguration that changes TCP
component in a running TCP/IP protocol stack into
                                                               We consider a simple layered protocol stack model
TCP-Vegas component [4]. TCP-Vegas is backward-
                                                            to describe the reconfiguration problem for communi-
compatible with TCP and therefore the reconfiguration
                                                            cating protocol components. Fig. 1 shows two com-
can be performed in the stack independent of its peer
                                                            municating protocol stacks, (Stack1 and Stack2 ). In
                                                            each layer of each stack, one independent entity which
   There are some research activities for presenting dy-
                                                            we refer to as protocol components (or in short compo-
namic protocol stacks. Some of them, such as [18,
                                                            nents), provides functionality of its corresponding pro-
29], provide reconfigurability at deployment-time (cus-
                                                            tocol. For instance, components P1 and P2 in the fig-
tomizability) for protocol stacks. Some others includ-
                                                            ure, provide functionality of the protocol P . We sup-
ing [16, 1] support reconfigurability at run-time for
                                                            pose components as an independent run-time entity.
“idle” protocol stacks. In these works, safe states are
                                                            The protocol components interact with each other by
points of protocols’ executions in which transactions of
                                                            exchanging protocol messages.
the corresponding protocol have been completed. How-
                                                               State of a protocol component describes all infor-
ever, in long-running servers, having long and impor-
                                                            mation related to the protocol in a point of execu-
tant connections (e.g., TCP connections), it is unfa-
                                                            tion. Such information includes values of all variables
vorable to wait until the end of protocol transactions.
                                                            and contents of all input/output buffers, related to the
A few approaches, such as [13], support dynamic re-
                                                            component. For simplicity, we split states of a pro-
configuration of “running” (not idle) protocol stacks.
                                                            tocol component into macro-states and micro-states


    UbiCC Journal, Volume 4, Number 3, August 2009                                                              785
                                                                                as [12, 33], use knowledge of the system struc-
                                                                                ture to identify safe states. They always identify
                                                                                the same set of safe states for a particular re-
                                                                                configuration. Dynamic algorithms, for example
                                                                                [9, 23, 5], use run-time knowledge such as com-
                                                                                ponents interactions to find safe states. Usually,
                                                                                dynamic algorithms disrupt small parts of a sys-
                                                                                tem than static algorithms.
                                                                          State transfer Execution of the new component may
                                                                               be resumed from a non-initial state, which we re-
   Figure 1. An example of two communicating                                   fer to as the restarting state. Two approaches ex-
   protocol stacks                                                             ist to transfer a state between two components,
                                                                               direct state transfer and indirect state transfer
                                                                               [31]. In the former approach, the new component
                                                                               uses the implementation of the old component to
[6]. Macro-states describe states of the protocols’ finite                      interpret and convert the state from the old com-
state machines. Examples of macro-states in the TCP                            ponent. In the latter approach, the old compo-
protocol are CLOSED and ESTABLISHED. Micro-states                              nent exports its state in an abstract representa-
describe states of protocols at run-time, to maintain in-                      tion form which is used by the new component.
formation for operations such as reliability, error han-                       For the state transfer, firstly, it is necessary to
dling, and congestion control. We use macro-states of                          find the restarting state in the new component;
components in specification levels and micro-states in                          secondly, the restarting state should be initialized
execution levels.                                                              to resume the execution.

2.2     Reconfiguration Assurance                                             In the following section, we explain the proposed
                                                                          solution for backward-compatible reconfigurations of
                                                                          running protocol components.
   One of the important reasons for the lack of practical
use of reconfigurable component-based systems is deal-
ing with assurance of reconfigurations [28]. Intuitively,                  3     The Solution
a dynamic reconfiguration that changes a running com-
ponent into a new one is assured if after the changing                       In this section, we propose our solution for transpar-
phase, the new component can be executed just as if it                    ent reconfigurations of running protocol components.
has been executed from its initial state [10]. Based on                   First, we describe reconfiguration supports for proto-
this notion, if the new component starts re-execution                     col components; then we explain required knowledge
from a reachable state 1 , then the reconfiguration will                   for such reconfigurations; finally, we state the proposed
be assured. Based on [10], to achieve such a reachable                    solution for the reconfiguration management and con-
state, the running component should be frozen in a safe                   trol.
state, and its state should be transferred into the new
component. Requirements for such a safe state and                         3.1    Reconfiguration Support for Protocol
state transfer are described below.                                              Components

Safe state A safe state for a reconfiguration has been                        Reconfigurable protocol components should provide
     defined as a state having no interaction with the                     some extra functionalities to support dynamic reconfig-
     other components [11, 16]. A component in a                          urations. Every protocol component should implement
     safe state does not accept new requests, does not                    the ReconfigurableComponent interface. Fig. 2 shows
     initiate new operations, and all its initiated op-                   the required methods; saveState() and restoreState()
     erations have been completed [23].                                   methods are used for state transfer and start() and
       There are two types of algorithms to find safe                      stop() methods are used to start and stop execution of
       states in an execution. Static algorithms, such                    the component. The semiFreeze() method should be
                                                                          implemented for each component in order to support
   1 State s in component C is said reachable state, if and only if
                                                                          freezing the component in a proper state.
an execution of component C starting from an initial state can
reach s at some time for some inputs.                                        Moreover, dynamic reconfigurations of protocol com-
                                                                          ponents require indirect communication between two


      UbiCC Journal, Volume 4, Number 3, August 2009                                                                          786
public interface ReconfigurableComponent {                      ured to each other are called role-compatible protocols.
    void saveState(String path);
    void restoreState(String path);                             A pair of protocol and its backward-compatible version
    void start();                                               is a well-known example for role-compatible protocols.
    void stop();                                                   For each pair of role-compatible protocols, PKB con-
    void semiFreeze();                                          tains a state mapping function that maps correspond-
                                                                ing macro-states of the two protocols. This helps recon-
  Figure 2. Reconfiguration interface for a pro-                 figurations as follows; when a protocol stops in a state
  tocol component                                               (freeze state), through the state mapping function, a
                                                                corresponding state (restarting state) can be found to
                                                                resume the execution.

                                                                3.2.2   Protocol State Information
                                                                We present a model for state (micro-state) represen-
                                                                tation of protocol components by introducing protocol
                                                                control block (PCB) that contains state information at
                                                                run-time. This information includes addressing param-
                                                                eters, buffers (sent, received, un-acknowledged, etc.),
                                                                protocol segment variables, counters, timers, send vari-
                                                                ables, receive variables, and the other required param-
                                                                eters. Protocol developers should implement one PCB
          Figure 3. A protocol component                        data structure for each protocol component in DRAPS.
                                                                   Moreover, for protocols in one category (a proto-
                                                                col and its extensions), we define basic PCB (BPCB)
adjacent protocol components (layers) in order to present       as an abstract PCB for the base protocol specified
transparent run-time reconfigurations [8]. For this rea-         in standards and RFCs. For example, Fig. 5 shows
son, a wrapper component is used between two adja-              the parameters for BPCB in original TCP protocol
cent protocol components. For a protocol component,             (RFC793). PKB contains a set of PCBs’ and BPCBs’
the wrapper presents interface of the protocol compo-           parameters and formats for different protocols.
nent and manages the incoming requests to the compo-               PCB handlers are provided to set values of PCB pa-
nent, by buffering them during the freeze periods (Fig.          rameters. In state transfer, the old PCB is used to
3.                                                              valuate the same parameters in the new PCB. After-
                                                                wards, the PCB handlers are used to complete the state
3.2     Protocol Knowledge Base                                 transfer. PKB includes PCB handlers for different re-
                                                                configurations. Through PCBs and PCB-handlers we
   As stated in the Subsection 2.2, an assured reconfig-         offer indirect state transfer.
uration of a protocol component necessitates to freeze
the component in a safe state and to initialize the new
component completely. In order to achieve this goal,
our idea is to keep enough information about reconfig-
urable protocols in a Protocol Knowledge Base (PKB)
component. Specifically, PKB contains two types of
knowledge, namely, role-compatible protocols, and pro-
tocol state information (Fig. 4), as explained in the
following subsections.

3.2.1    Role-Compatible Protocols                                Figure 4. PKB includes PCBs and BPCBs for-
                                                                  mats, and knowledge of role-compatible pro-
In a reconfiguration of an existing component into a               tocols
new component, the new one should play the same role
as the existing one. For example, we may reconfigure
TCP into SCTP or UDP, but it is not possible to re-
configure TCP into IP. In fact, the role of TCP and IP
differs completely. Two protocols that can be reconfig-


      UbiCC Journal, Volume 4, Number 3, August 2009                                                               787
                                                                   3.2.3    TCP-SACK State Initialization
                                                                   We give an example for building a PCB. TCP-SACK
                                                                   [15] is a selective acknowledgment extension for TCP2 .
                                                                   It uses two TCP options, namely, SACK-PERMIT and
                                                                   SACK. These options are added to the TCP header.
                                                                   The first is an enabling option, which may be sent
                                                                   in a SYN packet to indicate the SACK option can be
                                                                   used once a connection is established. The second may
                                                                   be sent over an established connection, once permis-
                                                                   sion has been given by SACK-permitted. The SACK
                                                                   option is sent by a data receiver to inform the data
                                                                   sender that non-contiguous blocks of data have been
Variables (V)                                                      received and queued. The data receiver awaits the data
    A. Addressing Variables
        SRC: source port                                           reception in order to fill the gaps in the sequence space
        DST: destination port
    B. Segment Variables
                                                                   between received blocks. When missing parts are re-
        SEG.SEQ: segment sequence number                           ceived, the data receiver acknowledges the data by ad-
        SEG.ACK: segment acknowledgment number
        SEG.LEN: segment length                                    vancing the left window edge in the Acknowledgement
        SEG.WND: segment window (Receiver Advertised Window)
        SEG.CTL: control bits (ACK, RST, SYN, FIN)
                                                                   Number Field of the TCP header.
    C. Send Sequence Variables                                        PCB for TCP-SACK can be built by adding two
        SND.UNA: send unacknowledged
        SND.NXT: send next                                         parameters, SACK-PERMIT and SACK, to the TCP
        SND.WND: send window
        ISS: initial send sequence number
                                                                   BPCB. For state initialization in TCP-SACK, the TCP
    D. Receive Sequence Variables                                  PCB is copied into the TCP-SACK PCB and the SACK-
        RCV.NXT: receive next
        RCV.WND: receive window                                    PERMIT parameter in the PCB is set through a PCB
        IRS: initial receive sequence number
    E. Timers
                                                                   handler. Since the SACK parameter is calculated based
        REXMT: Retransmission Timer                                on the received data, it is not necessary to be initial-
        TIMEWAIT: Time-wait Timer
        USERTIME: User Timer                                       ized.
    F. Counters
        dACK: duplicate ACK counter
        ExpBoff: exponential backoff counter
    G. Other
                                                                   3.3     Reconfiguration Management and Con-
        CurrState: Current State                                           trol
        PrevState: Previous State
        RTO: Retransmission Timer Out value
        RTT: Round Trip Time, used to calculate RTO
        SRTT: Smoothed RTT, used to calculate RTO
                                                                      Reconfiguration management and control is provided
        CWND: Congestion window                                    through a component, called RMC. It can receive re-
        MSS: Maximum Segment Size
        SSthresh: Slow Start Threshold                             configuration commands from different sources includ-
        MSL: Maximum Segment Lifetime
    H. Buffers
                                                                   ing system administrators, monitoring components in
        SND.Buff: Send Buffer                                      the system, or peer systems’ RMC. A reconfiguration
        RCV.Buff: Receive Buffer
        OO.RCV.Buff: Out of Order Receive Buffer                   command asks replacing an old protocol component
        SND.UNAQ: Holds sent but unacknowledged segments
        UCallQ: Holds outstanding user calls
                                                                   with a new one. Accordingly, RMC freezes the old com-
        (e.g., SEND, RECEIVE, CLOSE)                               ponent in a safe state, installs a new component, and
                                                                   initializes it for re-execution from a restarting state.
  Figure 5. TCP parameters in its BPCB
                                                                   3.3.1    Finding a Safe State
                                                                   Due to the independence of protocol stack components
                                                                   (layers), finding a safe state for a dynamic reconfigura-
                                                                   tion can be carried out in a simple way. We define a safe
                                                                   reconfiguration point (SRP) as a point of component
                                                                   execution where the component is at the beginning or
                                                                   at the end of the processing of an input packet. In
                                                                   other words, the states just after writing a packet into
                                                                   the output buffer or before reading a packet from the
                                                                      2 Although TCP-SACK requires both endpoint protocol com-

                                                                   ponents to change in order to be of value, this example only
                                                                   explains state initialization.


UbiCC Journal, Volume 4, Number 3, August 2009                                                                           788
input buffer are SRPs. In such points, either no opera-          start() method. From now, the new component is
tion has been started on the packet or all the operations       available for its user components and the application
have been completed. Usually, macro states of proto-            layer can send data through the new protocol.
cols are like this and we use them as SRPs. This defi-              It is worth noting that, when the old protocol com-
nition is consistent with the definitions in [11, 34, 16],       ponent enters into the freeze mode, there maybe some
where all operations of the component in SRP should             packets inside the communication protocol stacks (pack-
be completed. However, we do not restrict the com-              ets that have been sent by the peer component but not
ponent’s buffers to become free in SRPs. This implies            delivered by the old component yet). These packets are
great flexibility in finding SRPs, in comparison with             buffered in upper/lower layers of the frozen component.
the others such as [1]. In our solution, in order to find
a SRP, it is not necessary to wait for the buffers to
become empty.
   Generally, finding a SRP in an execution of a com-
ponent is a reachability problem, which is undecidable
[10]. To cope with this problem, we ask protocol de-
velopers to “mark” some SRPs in the source code of
protocols. Therefore, protocol developers are asked to
put some pieces of code in the source code of proto-
col components to enable them to report macro-states
during the execution if requested. In normal execution
mode, a component does not report SRPs. However,
we introduce semi-freeze mode in which the component
reports every SRP upon reaching (like in debug mode).
The RMC component monitors the reported states of
the component in the semi-freeze mode and stops its
execution upon reaching the proper SRP for a dynamic

3.3.2   The Reconfiguration Procedure
To simplify the problem of transparent reconfigurations              Figure 6. Flowchart for the reconfiguration
of a running protocol component, we assume there is                 procedure
only one reconfiguration at a time and no concurrent
reconfigurations can be initiated.
   The flowchart of the reconfiguration procedure is de-
picted in Fig. 6. There are three preconditions to start        4    Implementation and Evaluation
a reconfiguration. First, the old component should
have at least one SRP; second, mapping functions for               We have implemented a prototype of the RMC com-
the SRPs of the old component should have been de-              ponent3 to demonstrate feasibility of our solution in
fined in PKB; third, new PCB can be completely ini-              transparent reconfigurations of running protocol com-
tialized through the old PCB and PCB handlers.                  ponents. Overhead of using wrappers in protocol stack
   In the case of satisfaction of all preconditions, the        performance has been evaluated in related works such
RMC component starts installation and execution of              as [8, 24]. In this section, we describe the evaluation of
a new component. It installs the new component and              the proposed mechanisms for assured and transparent
invokes the semiFreeze() method of the currently run-           dynamic reconfigurations. The evaluation includes the
ning component to start its semi-freeze mode. In this           reconfiguration procedure and the overhead of finding
mode, RMC monitors the component execution and                  safe states and using PCBs in state transfer.
freezes it by invoking its stop() method in a deter-               Java is chosen as the programming language due
mined SRP. Afterwards, the RMC uses saveState(),                to its platform independence. To load and reconfig-
and restoreState() methods to transfer the state val-           ure protocol components at run-time, we use dynamic
ues in the old component’s PCB into the new compo-              class loading. The configuration of the experimental
nent’s PCB in order to transfer the protocol state. Af-
                                                                   3 An implemented prototype of the RMC is available at
ter that, the new component is re-executed through its


     UbiCC Journal, Volume 4, Number 3, August 2009                                                                  789
environment includes two Centrino 1.5 and 1.7 GHz                  rations (with empty buffer) according to the steps de-
IBM personal computers with 256 and 512 MB mem-                    signed in our reconfiguration procedure. All numbers
ory. Linux (Debian 3.1 distribution) is used as the                are averaged over a large number of iterations. The
operating system.                                                  measured times for component installation, PKB op-
                                                                   erations, semi-freeze, freeze, and the total reconfigu-
                                                                   ration time are shown in the table. PKB operations
                                                                   includes the time of finding SRPs, state mapping func-
                                                                   tions through PKBs, and the time to verify assurance
                                                                   of the reconfiguration (through examining the possibil-
                                                                   ity of complete initialization of new PCB). In our ex-
                                                                   periments, it takes around 3 milliseconds. According
                                                                   to the definition of SRP, the semi-freeze time depends
                                                                   on the processing time for an input/output data in the
                                                                   TCP component. For the implemented TCP, which all
                                                                   macro-states are SRPs, the semi-freeze time is 3 mil-
                                                                   liseconds5 .
                                                                       The freeze time includes the time for state transfer.
    Figure 7. The experimentation environment                      In the state transfer TCP-CA PCB is initialized based
                                                                   on TCP PCB and two PCB-handlers. Restricting the
   Two communicating peer protocol stacks are con-                 TCP “send buffer” to become empty for starting a re-
sidered, Stack1 and Stack2 (Fig. 7). Stack1 is imple-              configuration, the state transfer takes up 17 millisec-
mented using the proposed solution. Applications on                onds (5 milliseconds for copying the old PCB into the
the top of stacks exchange data with each other. Both              new one, and 12 milliseconds for two PCB-handlers).
applications use a light-weight version of TCP protocol,           It is important to note that, the freeze time is the only
which have been implemented for the transport layer.               period that both old and new protocol components are
The IP layer is simulated using two Linux FIFOs4 , one             unavailable. The total reconfiguration time, which in-
for outgoing data and the other for incoming data. In              cludes installation, PKB operations, semi-freeze, and
Stack1 , wrappers for TCP and IP layers have also been             freeze times, is 56 milliseconds.
implemented.                                                           We have not restricted buffers to become empty for
   In the experiments, a reconfiguration command is                 starting a reconfiguration; therefore, the overall state
sent to the RMC in Stack1 to initiate a transparent                transfer time depends on the amount of data in TCP
reconfiguration. The command is to replace running                  “send buffer”. Based on our experiments state transfer
TCP with TCP-CA (TCP with Congestion Avoidance).                   of TCP with full buffers of the size 91KB and 133KB
TCP and TCP-CA are implemented such that all their                 takes 43.5 and 71 milliseconds correspondingly.
macro-states are SRPs.                                                 Table 2 shows comparisons of our solution (RMC)
   The TCP-CA PCB has two more parameters that                     and the two related works, which are implemented and
are congestion window size (CWND) and slow start                   evaluated in the similar environment. As shown in
threshold (SSthresh). These parameters are evaluated               the table, the freeze period in our solution is much
using two PCB handlers to set their default values                 lower than the others. This is due to performing state
(CWND = 512 bytes, SSthresh = 65536 bytes)                         transfer through PCB and PCB-handlers. In compar-
                                                                   ison, [13] uses Java serialization technique [17] which
                                                                   takes around 190 milliseconds. This shortening of the
    Table 1. The performance of replacing TCP                      freeze time in our solution is achieved through the PCB
                            Time(ms)                               model, which forces one-time development overhead for
                Install          33                                each protocol and presents a short time for the freeze
            PKB Operations        3                                period, which is critical to be short.
              Semi-Freeze         3                                    For the TCP protocol, since the timeout of TCP
                 Freeze          17                                sockets is usually more than tens of seconds on differ-
             Reconfiguration            56                          ent machines6 , the reconfiguration is performed trans-
                                                                      5 If a protocol component does not consider all its macro-states

   Table 1 shows the performance of TCP reconfigu-                  as SRP, the semi-freeze period will be longer
                                                                      6 The default timeout of TCP socket is 5 days; however, ap-
  4 Using FIFO guarantees in-order sent or received packets;       plications set a lower timeout value.
however, this is not our point.


     UbiCC Journal, Volume 4, Number 3, August 2009                                                                             790
                                                                col stacks at deployment-time.
    Table 2. The comparison of times of reconfig-                   The DiPS/CuPS framework [16] is intended for the
    uration steps in the related solutions (NA =                development of customizable system software. This re-
    Not Available)                                              search mainly concentrate on a component model for
                                                                protocol components. Reflection points in DiPS/CuPS,
    Solution/   Finding    State     Recon.    Freeze           which performs packet switching within a protocol stack,
    Time(ms)     SRP      Transfer             Period           can only support run-time reconfigurations. Safe states
     DPF [1]      NA        NA         200     ≥ 200            for reconfigurations are defined based on protocol trans-
       [13]        3        190        214     ≥ 190            actions; when the protocol execution is completed and
      RMC          3         5          56       5              buffers are empty, the state is safe for a reconfiguration.
                                                                Specifically, DiPS/CuPS presents dynamic reconfigu-
                                                                rations for protocol stacks with idle protocols. It does
parently in application point of view. In general, it is        not provide flexible enough mechanisms for reconfig-
important to demonstrate that, our solution can trans-          urations of running protocols (reconfiguration during
parently reconfigure other protocols (besides TCP) as            protocol transactions). DiPS/CuPS supports both di-
well. For this reason, the duration of the freeze period        rect and indirect state transfer mechanisms.
in a protocol should be less than the timeout of the pro-          Dynamic Protocol Framework (DPF) [1] mainly con-
tocol users (generally the upper layer protocol users).         centrates on building an adaptive protocol stack by
As the timeout value for the most of communication              automatic discovery and selection of protocol compo-
protocols is much more than a second, we can expect             nents. It supports on-the-fly reconfigurations of proto-
that the presented solution can transparently reconfig-          col stacks and provides a synchronization mechanism to
ure other protocols as well. In our experiments for the         ensure the compatibility of protocol stacks on commu-
TCP protocol, the freeze period takes 5 milliseconds            nication peers. In DPF, safe states for reconfigurations
for the default size of “send buffer”, which is much less        are restricted to be at the end of protocol transactions.
than the TCP socket timeout in the application layer.           Moreover, supporting mechanisms for state transfer are
                                                                not clearly defined and addressed.
5     Related Work                                                 In [13], authors propose a Java-based framework
                                                                that allows programmers to create, remove, and re-
                                                                place protocol modules at run-time. Programmers im-
    Developing dynamic reconfigurable systems have been
                                                                plement their components using the component frame-
reported in the literature, such as CONIC[14], ARGUS
                                                                work. The framework can dynamically reconfigure com-
[2], and POLYLITH [11]; some others such as [7, 16]
                                                                ponents in safe states. To find a safe state, the frame-
provide reconfigurable component models. In the con-
                                                                work uses lock management techniques to access a pro-
text of reconfigurable protocol stacks, related work are
                                                                tocol module. When a reconfiguration command is re-
mainly focused on implementing frameworks to sup-
                                                                ceived, the framework attempts to access the “write”
port reconfigurable protocol stacks. Reconfigurations
                                                                lock to start the reconfiguration. Lock management
in protocol components can be either at deployment-
                                                                adds complexity in programming protocol modules and
time, at run-time with idle protocols, or at run-time
                                                                also in the application layer. In contrast, we have im-
with running protocols.
                                                                plemented lock management in wrappers and so there
    Ioana Sora et al. propose the “protocol building
                                                                is no extra overhead for the protocol programmer. For
block” description and protocol selection algorithms in
                                                                the state transfer, authors use the Java synchroniza-
[26]. They use an algorithm to select building blocks
                                                                tion technique as a direct state transfer mechanism.
in case that all specified features are provided and all
                                                                However, we have used the PCB model for the indirect
dependencies of selected components are satisfied. This
                                                                state transfer that causes short freeze time.
paper offers protocol stack compositions at deployment-
    In [18], a framework called OPtIMA is introduced            6   Concluding Remark
for protocol stacks of software-radio based systems.
The goal is to reconfigure protocol stacks built within             This paper proposes a solution for dynamic recon-
the framework. OPtIMA presents the definition and                figurations of protocol stacks. Although dynamic re-
provision of a library of classes, which can be used            configuration for protocol stacks is not new, our work
to build reconfigurable protocol stacks. However, the            is novel in that it supports assured and transparent
framework does not support dynamic reconfiguration               dynamic reconfigurations for running protocol compo-
of protocols. It only presents customizibility of proto-        nents. Unlike related work, we can reconfigure protocol


       UbiCC Journal, Volume 4, Number 3, August 2009                                                              791
components during their transactions. Through model-               [9] K. M. Goudarzi. Consistency preserving dynamic re-
ing protocols’ states by PCBs, we have achieved a very                 configuration of distributed systems. PhD Thesis, Im-
short time for the freeze period. This presents enough                 perial College, London, 1999.
transparency of reconfigurations in the peer compo-                [10] D. Gupta. On-line software version change. PhD the-
nent’s point of view. We believe, PCBs and BPCBs                       sis, Department of Computer Science and Engineer-
                                                                       ing, Indian Institute of Technology, 1994.
can be added to protocols standards and RFCs; there-
                                                                  [11] C. Hofmeister and J. M. Purtilo. Dynamic reconfigura-
fore protocol developers can share PCBs and BPCBs                      tion in distributed systems: Adapting software mod-
easily.                                                                ules for replacement. In Intl. Conf. on Distributed
   For validation of the solution, we have implemented                 Computing Systems, (7):101–110, January 1993.
a prototype. Test scenarios for assured and transpar-             [12] J. Kramer and J. Magee. The evolving philosophers
ent reconfigurations of the TCP protocol in a TCP/IP                    problem: Dynamic change management. IEEE Trans-
protocol stack are realized through the RMC compo-                     actions on Software Engineering, 11(16):1293–1306,
nent. The experimental results show maintaining of an                  1990.
acceptable transparency.                                          [13] Y. Lee and R. Chang.            Developing dynamic-
   Future work can be carried out in several directions.               reconfigurable communication protocol stacks using
                                                                       java. Software Practice Experience, 6(35):601–620,
Firstly, managing knowledge in PKB and specification
                                                                       January 2005.
of protocol components require proper tools. Secondly,            [14] J. Magee, J. Kramer, and M. Sloman. Constructing
automatic generating of SRPs in the source code of                     distributed systems in conic. IEEE Transactions on
protocol components is feasible. Lastly, providing au-                 Software Engineering, 6(15):663–675, 1989.
tomatic detection and execution of transparent recon-             [15] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow.
figurations has a great importance in self-configuring                   Tcp selective acknowledgment options. RFC 2018,
of autonomic systems.                                                  Sun Microsystems, October 1996.
                                                                  [16] S. Michiels, F. Matthijs, D. Walravens, and P. Ver-
                                                                       baeten. Dips: A unifying approach for developing sys-
References                                                             tem software. In A. D. Williams, editor, Proceedings -
                                                                       The Eight Workshop on Hot Topics in Operating Sys-
 [1] L. An, H. K. Pung, and L. Zhou. Design and imple-                 tems, IEEE Computer Society, 2001.
     mentation of a dynamic protocol framework. Journal           [17] S. Microsystems. Java object serialization specifica-
     of Computer Communications, 29(9):1309–1315, May                  tion. 2001.
     2006.                                                        [18] K. Moessner, S. Vahid, and R. Tafazolli. Termi-
 [2] T. Bloom and M. Day. Reconfiguration and module                    nal reconfiguration: The optima framework. Second
     replacement in argus: Theory and practice. IEE Soft-              International Conference on 3G Mobile Communica-
     ware Engineering Journal, 2(8):102–108, 1993.                     tion Technologies, IEE-3G2001, pages 241–246, March
 [3] V. G. Bose, A. B. Shah, and M. Ismert. Software                   2001.
     radios for wireless networking. In Proc. of INFOCOM          [19] M. Niamanesh, F. H. Dehkordi, N. F. Nobakht, and
     1998, 3:1030–1036, 1998.                                          R. Jalili. On validity assurance of dynamic reconfig-
 [4] L. S. Brakmo and L. L. Peterson. Tcp vegas: end to                uration in component-based program. In IPM Inter-
     end congestion avoidance on a global internet. IEEE               national Workshop on Foundations of Software Engi-
     Journal on Selected Areas in Communications, 8(13),               neering (Theory and Practice) FSEN 2005, ENTCS,
     October 1995.                                                     159(7):227–239, May 2006.
 [5] X. Chen and M. Simmons. Extending rmi to support             [20] M. Niamanesh and R. Jalili. A dynamic-reconfigurable
     dynamic reconfiguration of distributed systems. In 22              architecture for protocol stacks of networked systems.
     nd International Conference on Distributed Comput-                31st Annual IEEE International Computer Software
     ing Systems (ICDCS’02), 2002.                                     and Applications Conference (COMPSAC07), 1:609–
 [6] D. Comer and D. Stevens. Internetworking with tcp/ip              612, July 2007.
     v2. Prentice-Hall, NJ, 1991.                                 [21] M. Niamanesh and R. Jalili. Formalizing compatibility
 [7] J. Dowling and V. Cahill. The k-component archi-                  and substitutability in communication protocols using
     tecture meta-model for self-adaptive software. In Lec-            i/o-constraint automata. In Arbab, F., Sirjani, M.
     ture Notes In Computer Science, 2192:81–88, February              (eds.) FSEN07, LNCS, pages 49–64, April 2007.
     2001.                                                        [22] M. Niamanesh, S. Sabetghadam, R. Y. Rahaghi, and
 [8] N. Georganopoulos, T. Farnham, R. Burgess, T. S. J.               R. Jalili. Design and implementation of a dynamic-
     Sessler, P. Warr, Z. Golubicic, F. Platbrood, B. Sou-             reconfigurable architecture for protocol stack. In
     ville, and S. Buljore. Terminal-centric view of soft-             IPM International Workshop on Foundations of Soft-
     ware reconfigurable system architecture and enabling               ware Engineering (Theory and Practice) FSEN07, In
     components and technologies. IEEE Communications                  Arbab, F., Sirjani, M. (eds.) FSEN07, LNCS, pages
     Magazine, 42(4):100–110, May 2004.                                396–403, 2007.


     UbiCC Journal, Volume 4, Number 3, August 2009                                                                    792
[23] J. Paula, A. Almeida, M. Wegdam, M. van Sinderen,
     and L. Nieuwenhuis. Transparent dynamic reconfig-
     uration for corba. In Proceedings of the 3rd Interna-
     tional Symposium on Distributed Objects and Applica-
     tions, 2001.
[24] O. Rutti, P. T. Wojciechowski, and A. Schiper.
     Structural and algorithmic issues of dynamic proto-
     col update. In the Proc. of the 20th IEEE Interna-
     tional Parallel and Distributed Processing Symposium
     (IPDPS06), April 2006.
[25] M. Satyanarayanan. Pervasive computing: Vision and
     challenges. IEEE PCM, pages 10–17, January 2001.
[26] I. Sora, S. Michiels, and F. Matthijs. Policies for
     dynamic stack composition. Technical Report, Dept.
     Computer Science, Leuven, Belgium, November 2000.
[27] R. Stewart, Q. Xie, K. Morneault, C. Sharp,
     H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla,
     L. Zhang, and V. Paxson. Stream control transmis-
     sion protocol. RFC 2960, October 2000.
[28] C. Szyperski. Component technology: what, where,
     and how? In Proc. of the Int. Conf. on Software En-
     gineering(ICSE), pages 684–693, 2003.
[29] S. K. Tan, Y. Ge, K. S. Tan, C. W. Ang, and
     N. Ghosh. Dynamically loadable protocol stacks - a
     message parser-generator implementation. IEEE In-
     ternet Computing, 8(2):19–25, March 2004.
[30] R. van Renesse, K. Birman, M. Hayden, A. Vaysburd,
     and D. Karr. Building adaptive systems using ensem-
     ble. Software Practice and Experience, 28(9):963–979,
     February 1998.
[31] Y. Vandewoude and Y. Berbers. Component state
     mapping for runtime evolution. In Proceedings of the
     2005 International Conference on Programming Lan-
     guages and Compilers, pages 230–236, June 2005.
[32] A. Venkataramani, R. Kokku, and M. Dahlin. Tcp
     nice: A mechanism for background transfers. In Proc.
     of the Fifth Symposium on Operating Systems Design
     and Implementation, December 2002.
[33] I. Warren. A model for dynamic configuration which
     preserves application integrity. PhD thesis, Lancaster
     University, 2000.
[34] M. A. Wermelinger. Specification of software architec-
     ture reconfiguration. PhD thesis, Universidade Nova
     de Lisboa, September 1999.


     UbiCC Journal, Volume 4, Number 3, August 2009                793

To top