A Solution for Backward-Compatible Reconfigurations of Running

Protocol Components in Protocol Stacks

Mahdi Niamanesh
niamanesh@mehr.sharif.edu
Department of Computer Engineering
Sharif University of Technology, Tehran, Iran
Rasool Jalili
jalili@sharif.edu
Department of Computer Engineering
Sharif University of Technology, Tehran, Iran

Abstract

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

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

1 Introduction
Future communication and computation world, known
as pervasive computing environment, includes wireless
networks, networked systems and devices with hetero-
geneous standards and protocols for different contexts
and situations [25]. The Software Radio technology [3]
offers dynamic reconfigurability for protocol stacks of
such systems and devices in order to facilitate applica-
tions such as changing routing algorithms of switches,
changing security modules in protocol stacks, bug fix-
ing, and customizing protocol stack of a device for bet-
ter performance.
In general, in a software system, dynamic reconfig-
uration of a component to a new one includes such
phases as freeze (stopping the current execution of the
component), change (adding/binding a new component
and unbinding/removing the unnecessary old compo-
nent from the system), state transfer (finding and ini-
tializing a proper state in the new component in order
to resume the execution), and re-execution (resuming
the execution from a non-initial state in the new com-
ponent) [19]. In order to have assured reconfiguration,
the old component should be frozen in a “safe state”
and the new component should resume the execution
from a “reachable” state [10].
In the context of protocol stack reconfiguration, since
each protocol is defined at least between two peer com-
ponents, reconfiguration of a running protocol compo-
nent may require a corresponding reconfiguration in
the peer component(s). However, by backward-compatible
changes of a protocol component, the protocol reconfig-
uration can be carried out in the component indepen-
dently without disrupting its peer component. As an
example, consider a reconfiguration that changes TCP
component in a running TCP/IP protocol stack into
TCP-Vegas component [4]. TCP-Vegas is backward-
compatible with TCP and therefore the reconfiguration
can be performed in the stack independent of its peer
stack.
There are some research activities for presenting dy-
namic protocol stacks. Some of them, such as [18,
29], provide reconfigurability at deployment-time (cus-
tomizability) for protocol stacks. Some others includ-
ing [16, 1] support reconfigurability at run-time for
“idle” protocol stacks. In these works, safe states are
points of protocols’ executions in which transactions of
the corresponding protocol have been completed. How-
ever, in long-running servers, having long and impor-
tant connections (e.g., TCP connections), it is unfa-
vorable to wait until the end of protocol transactions.
A few approaches, such as [13], support dynamic re-
configuration of “running” (not idle) protocol stacks.
UbiCC Journal, Volume 4, Number 3, August 2009
They can reconfigure running protocols in safe states
that can be in the middle of protocol transactions. In
these approaches, reconfiguration of a protocol com-
ponent should be transparent in the peer component’s
point of view.
In this paper, the reconfiguration problem is defined
as changing one of the peer stacks at run-time transpar-
ently. Unlike the related work, we can reconfigure run-
ning protocol components in the middle of their proto-
col transaction. For such a reconfiguration, we propose
a procedure for reconfiguration management and con-
trol. The procedure employs two ideas; we propose
every protocol has a data structure for representing
its state (called PCB); and protocol developers mark
some states as safe states for staring possible reconfig-
urations.
The rest of this paper is organized as follows. Sec-
tion 2 describes backgrounds about protocol executions
and reconfiguration assurance in protocol stacks. In
Section 3, we explain the proposed solution for backward-
compatible reconfigurations in protocol stacks. Mech-
anisms for assurance and also the reconfiguration pro-
cedure are presented. In Section 4, we describe imple-
mentation and evaluation of the solution. In Section
5, we discuss related work and Section 6 concludes the
paper.
2 Background
In this section, we describe a simple model for proto-
col execution and explain assurance in reconfigurations
of protocol stacks.
2.1 Protocol Execution
We consider a simple layered protocol stack model
to describe the reconfiguration problem for communi-
cating protocol components. Fig. 1 shows two com-
municating protocol stacks, (Stack1 and Stack2 ). In
each layer of each stack, one independent entity which
we refer to as protocol components (or in short compo-
nents), provides functionality of its corresponding pro-
tocol. For instance, components P1 and P2 in the fig-
ure, provide functionality of the protocol P . We sup-
pose components as an independent run-time entity.
The protocol components interact with each other by
exchanging protocol messages.
State of a protocol component describes all infor-
mation related to the protocol in a point of execu-
tion. Such information includes values of all variables
and contents of all input/output buffers, related to the
component. For simplicity, we split states of a pro-
tocol component into macro-states and micro-states
785

Figure 1. An example of two communicating
protocol stacks
[6]. Macro-states describe states of the protocols’ finite
state machines. Examples of macro-states in the TCP
protocol are CLOSED and ESTABLISHED. Micro-states
describe states of protocols at run-time, to maintain in-
formation for operations such as reliability, error han-
dling, and congestion control. We use macro-states of
components in specification levels and micro-states in
execution levels.
2.2 Reconfiguration Assurance
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,
a dynamic reconfiguration that changes a running com-
ponent into a new one is assured if after the changing
phase, the new component can be executed just as if it
has been executed from its initial state [10]. Based on
this notion, if the new component starts re-execution
from a reachable state 1 , then the reconfiguration will
be assured. Based on [10], to achieve such a reachable
state, the running component should be frozen in a safe
state, and its state should be transferred into the new
component. Requirements for such a safe state and
state transfer are described below.
Safe state A safe state for a reconfiguration has been
defined as a state having no interaction with the
other components [11, 16]. A component in a
safe state does not accept new requests, does not
initiate new operations, and all its initiated op-
erations have been completed [23].
There are two types of algorithms to find safe
states in an execution. Static algorithms, such
1 State s in component C is said reachable state, if and only if
an execution of component C starting from an initial state can
reach s at some time for some inputs.
UbiCC Journal, Volume 4, Number 3, August 2009
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-
fer to as the restarting state. Two approaches ex-
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
interpret and convert the state from the old com-
ponent. In the latter approach, the old compo-
nent exports its state in an abstract representa-
tion form which is used by the new component.
For the state transfer, firstly, it is necessary to
find the restarting state in the new component;
secondly, the restarting state should be initialized
to resume the execution.
In the following section, we explain the proposed
solution for backward-compatible reconfigurations of
running protocol components.
3 The Solution
In this section, we propose our solution for transpar-
ent reconfigurations of running protocol components.
First, we describe reconfiguration supports for proto-
col components; then we explain required knowledge
for such reconfigurations; finally, we state the proposed
solution for the reconfiguration management and con-
trol.
3.1 Reconfiguration Support for Protocol
Components
Reconfigurable protocol components should provide
some extra functionalities to support dynamic reconfig-
urations. Every protocol component should implement
the ReconfigurableComponent interface. Fig. 2 shows
the required methods; saveState() and restoreState()
methods are used for state transfer and start() and
stop() methods are used to start and stop execution of
the component. The semiFreeze() method should be
implemented for each component in order to support
freezing the component in a proper state.
Moreover, dynamic reconfigurations of protocol com-
ponents require indirect communication between two
786
public interface ReconfigurableComponent {
void saveState(String path);
void restoreState(String path);
void start();
void stop();
void semiFreeze();
}
Figure 2. Reconfiguration interface for a pro-
tocol component
Figure 3. A protocol component
adjacent protocol components (layers) in order to present
transparent run-time reconfigurations [8]. For this rea-
son, a wrapper component is used between two adja-
cent protocol components. For a protocol component,
the wrapper presents interface of the protocol compo-
nent and manages the incoming requests to the compo-
nent, by buffering them during the freeze periods (Fig.
3.
3.2 Protocol Knowledge Base
As stated in the Subsection 2.2, an assured reconfig-
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
In a reconfiguration of an existing component into a
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
ured to each other are called role-compatible protocols.
A pair of protocol and its backward-compatible version
is a well-known example for role-compatible protocols.
For each pair of role-compatible protocols, PKB con-
tains a state mapping function that maps correspond-
ing macro-states of the two protocols. This helps recon-
figurations as follows; when a protocol stops in a state
(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
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)
as an abstract PCB for the base protocol specified
in standards and RFCs. For example, Fig. 5 shows
the parameters for BPCB in original TCP protocol
(RFC793). PKB contains a set of PCBs’ and BPCBs’
parameters and formats for different protocols.
PCB handlers are provided to set values of PCB pa-
rameters. In state transfer, the old PCB is used to
valuate the same parameters in the new PCB. After-
wards, the PCB handlers are used to complete the state
transfer. PKB includes PCB handlers for different re-
configurations. Through PCBs and PCB-handlers we
offer indirect state transfer.
Figure 4. PKB includes PCBs and BPCBs for-
mats, and knowledge of role-compatible pro-
tocols
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
reconfiguration.

3.3.2 The Reconfiguration Procedure

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

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

environment includes two Centrino 1.5 and 1.7 GHz
IBM personal computers with 256 and 512 MB mem-
ory. Linux (Debian 3.1 distribution) is used as the
operating system.
Figure 7. The experimentation environment
Two communicating peer protocol stacks are con-
sidered, Stack1 and Stack2 (Fig. 7). Stack1 is imple-
mented using the proposed solution. Applications on
the top of stacks exchange data with each other. Both
applications use a light-weight version of TCP protocol,
which have been implemented for the transport layer.
The IP layer is simulated using two Linux FIFOs4 , one
for outgoing data and the other for incoming data. In
Stack1 , wrappers for TCP and IP layers have also been
implemented.
In the experiments, a reconfiguration command is
sent to the RMC in Stack1 to initiate a transparent
reconfiguration. The command is to replace running
TCP with TCP-CA (TCP with Congestion Avoidance).
TCP and TCP-CA are implemented such that all their
macro-states are SRPs.
The TCP-CA PCB has two more parameters that
are congestion window size (CWND) and slow start
threshold (SSthresh). These parameters are evaluated
using two PCB handlers to set their default values
(CWND = 512 bytes, SSthresh = 65536 bytes)
Table 1. The performance of replacing TCP
Time(ms)
Install 33
PKB Operations 3 period, which is critical to be short.
Semi-Freeze 3 For the TCP protocol, since the timeout of TCP
Freeze 17
Reconfiguration 56
Table 1 shows the performance of TCP reconfigu-
4 Using FIFO guarantees in-order sent or received packets;
however, this is not our point.
UbiCC Journal, Volume 4, Number 3, August 2009
rations (with empty buffer) according to the steps de-
signed in our reconfiguration procedure. All numbers
are averaged over a large number of iterations. The
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.
In the state transfer TCP-CA PCB is initialized based
on TCP PCB and two PCB-handlers. Restricting the
TCP “send buffer” to become empty for starting a re-
configuration, the state transfer takes up 17 millisec-
onds (5 milliseconds for copying the old PCB into the
new one, and 12 milliseconds for two PCB-handlers).
It is important to note that, the freeze time is the only
period that both old and new protocol components are
unavailable. The total reconfiguration time, which in-
cludes installation, PKB operations, semi-freeze, and
freeze times, is 56 milliseconds.
We have not restricted buffers to become empty for
starting a reconfiguration; therefore, the overall state
transfer time depends on the amount of data in TCP
“send buffer”. Based on our experiments state transfer
of TCP with full buffers of the size 91KB and 133KB
takes 43.5 and 71 milliseconds correspondingly.
Table 2 shows comparisons of our solution (RMC)
and the two related works, which are implemented and
evaluated in the similar environment. As shown in
the table, the freeze period in our solution is much
lower than the others. This is due to performing state
transfer through PCB and PCB-handlers. In compar-
ison, [13] uses Java serialization technique [17] which
takes around 190 milliseconds. This shortening of the
freeze time in our solution is achieved through the PCB
model, which forces one-time development overhead for
each protocol and presents a short time for the freeze
sockets is usually more than tens of seconds on differ-
ent machines6 , the reconfiguration is performed trans-
5 If a protocol component does not consider all its macro-states
as SRP, the semi-freeze period will be longer
6 The default timeout of TCP socket is 5 days; however, ap-
plications set a lower timeout value.
790

Table 2. The comparison of times of reconfig-
uration steps in the related solutions (NA =
Not Available)
Solution/ Finding State Recon. Freeze
Time(ms) SRP Transfer Period
DPF [1] NA NA 200 ≥ 200
[13] 3 190 214 ≥ 190
RMC 3 5 56 5 buffers are empty, the state is safe for a reconfiguration.
parently in application point of view. In general, it is
important to demonstrate that, our solution can trans-
parently reconfigure other protocols (besides TCP) as
well. For this reason, the duration of the freeze period
in a protocol should be less than the timeout of the pro-
tocol users (generally the upper layer protocol users).
As the timeout value for the most of communication
protocols is much more than a second, we can expect
that the presented solution can transparently reconfig-
ure other protocols as well. In our experiments for the
TCP protocol, the freeze period takes 5 milliseconds
for the default size of “send buffer”, which is much less
than the TCP socket timeout in the application layer.
5 Related Work
Developing dynamic reconfigurable systems have been
reported in the literature, such as CONIC[14], ARGUS
[2], and POLYLITH [11]; some others such as [7, 16]
provide reconfigurable component models. In the con-
text of reconfigurable protocol stacks, related work are
mainly focused on implementing frameworks to sup-
port reconfigurable protocol stacks. Reconfigurations
in protocol components can be either at deployment-
time, at run-time with idle protocols, or at run-time
with running protocols.
Ioana Sora et al. propose the “protocol building
block” description and protocol selection algorithms in
[26]. They use an algorithm to select building blocks
in case that all specified features are provided and all
dependencies of selected components are satisfied. This
paper offers protocol stack compositions at deployment-
time.
In [18], a framework called OPtIMA is introduced
for protocol stacks of software-radio based systems.
The goal is to reconfigure protocol stacks built within
the framework. OPtIMA presents the definition and
provision of a library of classes, which can be used
to build reconfigurable protocol stacks. However, the
framework does not support dynamic reconfiguration
of protocols. It only presents customizibility of proto-
UbiCC Journal, Volume 4, Number 3, August 2009
col stacks at deployment-time.
The DiPS/CuPS framework [16] is intended for the
development of customizable system software. This re-
search mainly concentrate on a component model for
protocol components. Reflection points in DiPS/CuPS,
which performs packet switching within a protocol stack,
can only support run-time reconfigurations. Safe states
for reconfigurations are defined based on protocol trans-
actions; when the protocol execution is completed and
Specifically, DiPS/CuPS presents dynamic reconfigu-
rations for protocol stacks with idle protocols. It does
not provide flexible enough mechanisms for reconfig-
urations of running protocols (reconfiguration during
protocol transactions). DiPS/CuPS supports both di-
rect and indirect state transfer mechanisms.
Dynamic Protocol Framework (DPF) [1] mainly con-
centrates on building an adaptive protocol stack by
automatic discovery and selection of protocol compo-
nents. It supports on-the-fly reconfigurations of proto-
col stacks and provides a synchronization mechanism to
ensure the compatibility of protocol stacks on commu-
nication peers. In DPF, safe states for reconfigurations
are restricted to be at the end of protocol transactions.
Moreover, supporting mechanisms for state transfer are
not clearly defined and addressed.
In [13], authors propose a Java-based framework
that allows programmers to create, remove, and re-
place protocol modules at run-time. Programmers im-
plement their components using the component frame-
work. The framework can dynamically reconfigure com-
ponents in safe states. To find a safe state, the frame-
work uses lock management techniques to access a pro-
tocol module. When a reconfiguration command is re-
ceived, the framework attempts to access the “write”
lock to start the reconfiguration. Lock management
adds complexity in programming protocol modules and
also in the application layer. In contrast, we have im-
plemented lock management in wrappers and so there
is no extra overhead for the protocol programmer. For
the state transfer, authors use the Java synchroniza-
tion technique as a direct state transfer mechanism.
However, we have used the PCB model for the indirect
state transfer that causes short freeze time.
6 Concluding Remark
This paper proposes a solution for dynamic recon-
figurations of protocol stacks. Although dynamic re-
configuration for protocol stacks is not new, our work
is novel in that it supports assured and transparent
dynamic reconfigurations for running protocol compo-
nents. Unlike related work, we can reconfigure protocol
791
components during their transactions. Through model-
ing protocols’ states by PCBs, we have achieved a very
short time for the freeze period. This presents enough
transparency of reconfigurations in the peer compo-
nent’s point of view. We believe, PCBs and BPCBs
can be added to protocols standards and RFCs; there-
fore protocol developers can share PCBs and BPCBs
easily.
For validation of the solution, we have implemented
a prototype. Test scenarios for assured and transpar-
ent reconfigurations of the TCP protocol in a TCP/IP
protocol stack are realized through the RMC compo-
nent. The experimental results show maintaining of an
acceptable transparency.
Future work can be carried out in several directions.
Firstly, managing knowledge in PKB and specification
of protocol components require proper tools. Secondly,
automatic generating of SRPs in the source code of
protocol components is feasible. Lastly, providing au-
tomatic detection and execution of transparent recon-
figurations has a great importance in self-configuring
of autonomic systems.
References
[1] L. An, H. K. Pung, and L. Zhou. Design and imple-
mentation of a dynamic protocol framework. Journal
of Computer Communications, 29(9):1309–1315, May
2006.
[2] T. Bloom and M. Day. Reconfiguration and module
replacement in argus: Theory and practice. IEE Soft-
ware Engineering Journal, 2(8):102–108, 1993.
[3] V. G. Bose, A. B. Shah, and M. Ismert. Software
radios for wireless networking. In Proc. of INFOCOM
1998, 3:1030–1036, 1998.
[4] L. S. Brakmo and L. L. Peterson. Tcp vegas: end to
end congestion avoidance on a global internet. IEEE
Journal on Selected Areas in Communications, 8(13),
October 1995.
[5] X. Chen and M. Simmons. Extending rmi to support
dynamic reconfiguration of distributed systems. In 22
nd International Conference on Distributed Comput-
ing Systems (ICDCS’02), 2002.
[6] D. Comer and D. Stevens. Internetworking with tcp/ip
v2. Prentice-Hall, NJ, 1991.
[7] J. Dowling and V. Cahill. The k-component archi-
tecture meta-model for self-adaptive software. In Lec-
ture Notes In Computer Science, 2192:81–88, February
2001.
[8] N. Georganopoulos, T. Farnham, R. Burgess, T. S. J.
Sessler, P. Warr, Z. Golubicic, F. Platbrood, B. Sou-
ville, and S. Buljore. Terminal-centric view of soft-
ware reconfigurable system architecture and enabling
components and technologies. IEEE Communications
Magazine, 42(4):100–110, May 2004.
UbiCC Journal, Volume 4, Number 3, August 2009
[9] K. M. Goudarzi. Consistency preserving dynamic re-
configuration of distributed systems. PhD Thesis, Im-
perial College, London, 1999.
[10] D. Gupta. On-line software version change. PhD the-
sis, Department of Computer Science and Engineer-
ing, Indian Institute of Technology, 1994.
[11] C. Hofmeister and J. M. Purtilo. Dynamic reconfigura-
tion in distributed systems: Adapting software mod-
ules for replacement. In Intl. Conf. on Distributed
Computing Systems, (7):101–110, January 1993.
[12] J. Kramer and J. Magee. The evolving philosophers
problem: Dynamic change management. IEEE Trans-
actions on Software Engineering, 11(16):1293–1306,
1990.
[13] Y. Lee and R. Chang. Developing dynamic-
reconfigurable communication protocol stacks using
java. Software Practice Experience, 6(35):601–620,
January 2005.
[14] J. Magee, J. Kramer, and M. Sloman. Constructing
distributed systems in conic. IEEE Transactions on
Software Engineering, 6(15):663–675, 1989.
[15] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow.
Tcp selective acknowledgment options. RFC 2018,
Sun Microsystems, October 1996.
[16] S. Michiels, F. Matthijs, D. Walravens, and P. Ver-
baeten. Dips: A unifying approach for developing sys-
tem software. In A. D. Williams, editor, Proceedings -
The Eight Workshop on Hot Topics in Operating Sys-
tems, IEEE Computer Society, 2001.
[17] S. Microsystems. Java object serialization specifica-
tion. 2001.
[18] K. Moessner, S. Vahid, and R. Tafazolli. Termi-
nal reconfiguration: The optima framework. Second
International Conference on 3G Mobile Communica-
tion Technologies, IEE-3G2001, pages 241–246, March
2001.
[19] M. Niamanesh, F. H. Dehkordi, N. F. Nobakht, and
R. Jalili. On validity assurance of dynamic reconfig-
uration in component-based program. In IPM Inter-
national Workshop on Foundations of Software Engi-
neering (Theory and Practice) FSEN 2005, ENTCS,
159(7):227–239, May 2006.
[20] M. Niamanesh and R. Jalili. A dynamic-reconfigurable
architecture for protocol stacks of networked systems.
31st Annual IEEE International Computer Software
and Applications Conference (COMPSAC07), 1:609–
612, July 2007.
[21] M. Niamanesh and R. Jalili. Formalizing compatibility
and substitutability in communication protocols using
i/o-constraint automata. In Arbab, F., Sirjani, M.
(eds.) FSEN07, LNCS, pages 49–64, April 2007.
[22] M. Niamanesh, S. Sabetghadam, R. Y. Rahaghi, and
R. Jalili. Design and implementation of a dynamic-
reconfigurable architecture for protocol stack. In
IPM International Workshop on Foundations of Soft-
ware Engineering (Theory and Practice) FSEN07, In
Arbab, F., Sirjani, M. (eds.) FSEN07, LNCS, pages
396–403, 2007.
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.

10

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