Protocol Reconfiguration Schemes for Policy-based Equipment Management Eleni Patouni, Antonis Lilis, Andreas Merentitis, Nancy Alonistioti Department of Informatics & Telecommunications University of Athens Athens, Greece {elenip|alilis|amer|nancy}@di.uoa.gr
Christophe Beaujean, Didier Bourse Motorola Labs European Communications Research Paris, France {christophe.beaujean|Didier.Bourse} @motorola.com
Abstract—The continuous proliferation in modern communication technologies towards a pervasive composite environment prescribes a profound shift in telecommunication management and poses new challenges, in terms of proposing key solutions for the management and support of legacy as well as emerging systems. Driven by these advances, a direct requirement lies in providing an advanced configuration system that will embrace the demands for optimal and adaptive configuration and reconfiguration of the underlying layers. This objective can be achieved by upgrading the capabilities of mobile equipment with the introduction of a configuration system that incorporates advanced features such as policy-based decision making mechanisms and protocol layer adaptation and reconfiguration procedures. This contribution exploits protocol reconfiguration schemes for policy-based equipment management as addressed in the E2R environment. Keywords- reconfiguration, adaptation, protocol component, autonomic communications, policy
I. INTRODUCTION The relentless drive in mobile and wireless communication systems coupled with the increasingly evolving user needs, introduces vast complexity in the corresponding system management. Given the advances posed by the continuous growth and proliferation of legacy and emerging systems, a direct requirement lies in providing an advanced configuration system that embraces the demands for optimal and adaptive configuration and reconfiguration of the underlying layers. Such a paradigm can be pursued by the reconfigurability notion which forms an asset of mobile devices, enabling their dynamic adaptation to the drastically changing environment. The above concept is hooked to the E2R architectural approach for reconfigurable devices, introducing a configuration system for terminals that supports advanced capabilities and operation concepts; the latter encompass configuration and runtime modification of the equipment applications, protocol stack and underlying hardware parameters [1]. In this context, such configuration system is offered by the equipment management and control architecture proposed by E2R, which comprises collaborating mechanisms for the management and control of the reconfiguration process, mapped to Configuration Management Modules (CMM) and Configuration Control Modules (CCM) respectively [1]. This
Eric Nicollet Thales Communications Paris, France
[email protected]
contribution addresses a new paradigm to approach the aspects of policy-based equipment management in next generation networks. In addition, protocol reconfiguration schemes are proposed for realizing on-the-fly configuration and adaptation of operating protocols. The rest of the paper is organized as follows. Related work in the areas of protocol (re)configuration and policy-based management is briefly described in section II. Our introduced mechanisms regarding policy-based decision making are highlighted in Section III. Protocol reconfiguration aspects, in terms of dynamic configuration of protocol components and protocol adaptation are analyzed in Section IV. The validation procedure of the presented mechanisms is portrayed in Section V; in addition, key performance metrics are evaluated and discussed. The evolution of the reconfigurable equipment management to accommodate autonomic environments is outlined in Section VI. Finally, a concluding discussion is provided in Section VII. II. RELATED WORK Several other research activities focus on the extension of the conventional monolithic nature of protocols utilizing modularization schemes that support configuration capabilities. Initially, this approach was adopted to cope with protocol stack formation based on QoS requirements and network indicators, as applied in X-Kernel, Cactus and Appia [2]. However these approaches lack in verifying the correctness of the composition procedure. Moreover, the work in [3] presents a Java-based component framework for protocols, supporting the dynamic insertion or replacement of components. The application of this framework in a TCP implementation proved several disadvantages, allowing only the reconfiguration of a certain component and requiring a user defined handler to handle the difference in fields between the old and new component. All the abovementioned approaches premise specific software architecture styles for the protocol stack software but do not elaborate regarding their design considerations and the introduced mechanisms partaking to protocol stack reconfiguration (e.g., state management models). Recapitulating, though previous works have provided valuable insight regarding the requirements and challenges of protocol stack reconfiguration, there are still important issues that remain unsolved.
1-4244-0063-5/06/$20.00 ©2006 IEEE Authorized licensed use limited to: UNIVERSITAT POLIT?CNICA DE CATALUNYA. Downloaded on May 25,2010 at 13:56:36 UTC from IEEE Xplore. Restrictions apply.
As regards the decision making mechanisms that trigger protocol reconfiguration, several approaches consider policybased management issues. In particular, the approach presented in [4] addresses the policy management issue from a new perspective through posing it as a learning problem from current system behaviour, while creating new policies at runtime in response to changing requirements. A hierarchical policy model is used to capture users and administrators’ high level goals into network level objectives. The PROTON system analyzed in [5] forms a novel solution that assists mobile users in the decision-making process related to roaming between heterogeneous technologies. PROTON deploys a formal policy representation model, based on Finite State Transducers, that evaluates policies using contextual information to manage mobiles’ behaviour in a transparent manner. Figure 1: Policy Framework
III.
POLICY-BASED DECISION MAKING MECHANISMS
One of the most promising solutions to address the needs of equipment management lies in the notion of policy rules that prescribe a set of high level limitations defining the systems behavior in terms of users and application requirements, resource availability and business objectives [4]. Extending the typical static nature of policy rules, this contribution highlights a novel framework that uses ontologies and semantics for policy definition and representation as well as respective mechanisms for decision making and policy enforcement. Such a framework is exploited in the E2R II environment, by introducing the Decision Making & Policy Enforcement module (CMM_DMP). This module takes into account defined policies, contextual information (represented with the use of ontologies) and specifies the prioritization of policies in order to specify certain reconfiguration actions in an autonomic fashion. The CMM_DMP also caters for the implementation and enforcement of the decided reconfiguration, by firing certain actions, such as the downloading and installation of missing software components, or specifying constraints. In addition, this module acts as a policy decision point (PDP), while the rest of the modules that perform the specified actions act as policy enforcement points (PEPs). A high level view of the presented policy framework is illustrated in Figure 1. Specifically, the CMM_DMP collects the policies from the different stakeholders and combines them in order to create the final policy rules. The policies are derived from the device or they are retrieved from the network (e.g. in case of network operator rules). The specific rules are combined according to the priority of the stakeholders and the priority of the particular rule. The final output is the set of rules that defines the equipment policies. Moreover, during the equipment bootstrap, the CMM_DMP communicates with the rest of the CMM modules and retrieves the necessary variables that are set from the CMM_DMP to enforce the specified policies. According to the latter, these variables are set with their corresponding values, and then they are transmitted to the corresponding module. In the above cases the policies may specify that a certain action should take place. Since the CMM_DMP is the module that has the orchestral role in the reconfiguration process, the actions defined in the policies are representing internal actions that are implemented by the CMM_DMP.
The latter is responsible to interact with the other modules in order to trigger the defined actions. In addition, the policy rules may be dynamically updated to capture the changes in the environment or the user preferences. In case that policies change for a certain reason during operation, then after their recalculation, the CMM_DMP communicates with the corresponding CMM modules and sets the affected variables to the new values. In addition, the policy rules are stored in the Policy Repository. Utilizing previous work in policy languages and semantics, we propose the use of SWRL (Semantic Web Rule Language) for policy representation regarding reconfiguration purposes [6]. SWRL is a combination of Web Ontology language (OWL), which is now the W3C recommended standard for ontologies and Rule Markup Language (RuleML) [7][8]. SWRL extends the OWL syntax in order to express Horn-like rules. An example of an SWRL rule regarding resources is shown in Figure 2. In the presented framework, rules can derive from different stakeholder (user, manufacturer, network operator) and bear different priorities. The use of SWRL is considered to define two types of rules for reconfiguration purposes: a) constrain rules that represent the set of physical limitations imposed by the equipment features or network environment, i.e. memory size, CPU frequency, battery life etc. b) action rules which specify procedures to be deployed when certain conditions are met [4]. x x x x Figure 2: Example of SWRL Rule
Authorized licensed use limited to: UNIVERSITAT POLIT?CNICA DE CATALUNYA. Downloaded on May 25,2010 at 13:56:36 UTC from IEEE Xplore. Restrictions apply.
IV.
PROTOCOL RECONFIGURATION ASPECTS
In modern communication environments protocols are often characterized by long-term availability of multiple versions and diversity of protocol stack realizations that constitute frequent protocol updates a key enabler of reconfigurability. Specifically, updated protocol versions or protocol stack instances should be installed and activated based on available contextual information. This requirement necessitates the addition of generic management functionality in order to support protocol stack and component-based protocol layer reconfiguration in heterogeneous environments. In this contribution a framework for protocol reconfiguration is outlined. The design assumptions for the proposed framework concern the dynamic composition of protocol layers to form a protocol stack and the dynamic runtime modification of the protocol stack. The goals of the proposed solution are twofold: a) the dynamic replacement of the functionality of concrete protocol layers or components within these protocols, b) the protocol adaptation procedure, in terms of dynamically tuning protocol parameters. Assuring reliable operation of the protocol i.e., with no loss of data, as well as seamless reconfiguration with minimum performance overhead is a demand applying to both aspects. A. Dynamic Composition and Replacement of Protocol Components The abovementioned framework introduces intra-layer protocol reconfiguration management functionality targeted to control the dynamic binding and replacement of components. Originating from the requirement to support dynamic replacement of functionality in terms of concrete protocol layers or components within these protocols, the deployment of modular component-based schemes dictates the introduction of a new Manager entity within each protocol. This entity is responsible for realizing the dynamic component binding and replacement, while at the same time ensuring successful transition from the old to the new module. The verification and realization of the above procedures is based on a semantic layer of information for each protocol component (metadata) that includes static and dynamic characteristics for the identification of the component and its specific role in the protocol stack configuration respectively. Specifically, piecing together the available functionality offered by each component into full-fledged protocol services is performed by the exchange of administrative information through dynamically created FIFO queues. Such information incorporates configuration control data, i.e. the parameters of a function call. In order to further elaborate on the presented framework, a simple reconfiguration scenario demonstrating the dynamic replacement of a protocol component during runtime is outlined. In the first step the Manager retrieves the available information for the new component (metadata) and utilizes this information to validate the correctness of the proposed reconfiguration action and to identify all the existing components that should communicate with the new component. In case the replacement is found valid, the Manager stops the old component, retrieves its state information and properly initializes the new component, by
passing to it the retrieved state information and the communication links to the stationary protocol components [9]. In addition, in order to check the feasibility aspects of the presented mechanisms, the analyzed framework for dynamic component binding and replacement was applied upon the FTP protocol. Specifically, the modularization of the FTP protocol into two components was considered; the first of them handles the FTP connections and the uploading procedure whereas the second of them handles the file downloading. In addition, the metadata for these two components were specified. In these terms, the Manager based on the FTP components metadata realized their dynamic binding to form the functionality of the FTP protocol. Moreover, the on-the-fly replacement of the FTP downloading component with another downloading component (with enhanced capabilities) was performed. B. Protocol Adaptation: A TCP Case Study Protocol adaptation forms a procedure for the dynamic configuration of operating protocol parameters. This case study examines TCP Adaptation, which offers simple means to improve the performance of transport sessions by tuning their parameters with a minimal impact on the transport layer behaviour. This procedure aims at reducing the effects of random packet losses on the sending rate, i.e. to limit the effects of the Slow Start, without modifying TCP semantics. In the current case study, four TCP parameters can be tuned: a) the initial congestion window value, targeted to bypass the very first steps of the Slow Start, b) the minimum congestion window value in order to reduce congestion window size “aggressiveness”, c) the number of duplicate acknowledgments to receive before considering a packet is lost, to avoid unnecessary packet retransmissions on slow links and d) the Slow Start threshold factor, to minimize the impact of a single packet loss on the data sending rate. Both static configuration (i.e. the configuration of the initial parameters’ values for the future sessions) and dynamic configuration (i.e. the real-time modification of the current sessions’ parameters) are supported, for TCP/IPv4 as well as TCP/IPv6 sessions. A dedicated module, named tcp_param_prof is in charge of managing all the interactions between the different management entities and the TCP Adaptation system. This entity plays the role of a TCP Adaptation server, a unique interface between the operating system and entities likely to request for parameters modification. It first receives information about the parameter values to apply for each known technology (802.11b, UMTS, GPRS, etc) in the form of profiles, and waits for a modification request. Then, the terminal, or any external software entity able to detect and/or manage a handover from an access point to another can trigger the TCP parameters change by simply sending a request to the module. Of course, the request must contain the identifier of the targeted technology. The TCP Adaptation process involves several steps. The entities involved in this process are depicted in Figure 3. At first, using the Network Support Services Interface, a handover is detected in the device, and a handover notification is relayed including the identifier of the technology to which the TCP sessions must switch on. Then, the negotiation control phase
Authorized licensed use limited to: UNIVERSITAT POLIT?CNICA DE CATALUNYA. Downloaded on May 25,2010 at 13:56:36 UTC from IEEE Xplore. Restrictions apply.
The TCP Adaptation mechanism can be refined by modifying the current value of the congestion window each time the access network conditions significantly change, instead of just waiting for a handover. However, such an enhancement would require both a complex resource monitoring system and a new algorithm able to compute the most appropriate value according to a large panel of different parameters (i.e. the available bandwidth), which are not always accessible depending on the transmission support technology. Resource Network HO Monitoring& HO CMM_If Nss CMM_NS CMM_D MP (N) Interf ace ^Ne gotiation (N)
HO(N)
Info (N) HO (N)
Equip ment mana ge ment entities
User Space
Prof ileProf Info (N) CMM_ Mana ger tcp_param_prof
Profiles TCP paramet ers Emul ated entity Communic ation interfac e
Kernel Space TCP Adaptation System
Figure 3: Entities Involved in the TCP Adaptation Process
V.
VALIDATION AND PERFORMANCE ASSESSMENT
The validation of the mechanisms presented in the previous sections is performed via proof-of concept prototypes. These prototypes prescribe the deployment of the following functionality: a) decision making and policy-based mechanisms realized by the CMM_DMP module, b) the presented protocol reconfiguration framework upon its application in the FTP protocol, c) TCP adaptation mechanisms (implemented in Java). Specifically, triggered by the need to attach to a new radio access system or the application requirements, the CMM_DMP dictates that a protocol reconfiguration/adaptation should take place. In the first case, the decision concerns the dynamic replacement of the FTP downloading component. This process was successfully deployed, proving the transparent dynamic plugin of the new component in the protocol stack [9]. In addition, key performance issues are taken into consideration, in terms of calculating the delay introduced by the realization of the reconfiguration.
Reconfiguration TIme 500 450 400 350 time (msec)
follows; during this phase the Resource Monitoring & Negotiation module retrieves the necessary information about both the current TCP parameter’ values and the ones associated with the new technology. At this point it should be noted that a Profile manager is in charge of managing the different TCP parameter values associated with each technology. Thereafter, it is specified if the modification of the TCP parameters is “interesting” or not. Thus, if the new and the old parameter values are exactly the same or if they are very similar, the modification is abandoned. Otherwise, the Resource Monitoring & Negotiation module asks the CMM_DMP to check the new configuration. The CMM_DMP then decides if the new configuration should be applied according to its own policies, and coordinates with the tcp_param_prof module for the deployment of the new configuration.
300 250 200 150 100 50 0 1
10
19
28
37
46
55
64
73
82
91
samples
Figure 4: Total Reconfiguration Time for the Replacement of the FTP Downloading Component
Figure 4 illustrates the total reconfiguration time for the FTP component replacement within a set of samples, considering the underlying hardware capabilities (Pentium III 800MHz PC with 512MB RAM) and operating system (Debian Linux 3.0 R4). The mean value of this delay is found to be 358 msec, proving that the presented protocol reconfiguration framework introduces minimum performance overhead in the system (this value does not include the time required for the component to reach a safe replacement state, since such delay is not affected by the presented framework). Regarding the deployment of TCP adaptation mechanisms, this procedure was successfully performed in both TCP/IPv4 and TCP/IPv6 sessions, tuning the following parameters: initial congestion window value, minimum congestion window value, the number of duplicate acknowledgments and the Slow Start threshold factor. The TCP Adaptation software has been developed under Linux (kernel 2.6.8.1) both in the kernel and the user space. The TCP parameters’ values can be adapted according to the network access conditions in a mobile environment thanks to a GUI monitoring the TCP sessions status in real-time, allowing the selection of several TCP parameters to change, and providing efficient interfaces with the Linux kernel that allow to make the changes immediately operational. The implemented software has four main components: one is located in the user space and three in the kernel space, with interfaces between the two spaces: a) the TCP stack itself, with an extension of the ioctl calls system (new ioctl calls have been added on the socket descriptors) in order to allow the change of the TCP parameters for the already opened sessions (i.e. this extension just modifies the status of the current TCP sockets); b) a tcp_param_get module, monitoring the current values of the TCP parameters for all the current sessions via the Linux Virtual File System (VFS); c) a tcp_param_put module, allowing the modification of the initialization value (i.e. only for the future sessions) of a TCP parameter independently of the others, via the VFS and sysctl calls; d) a GUI able to illustrate in real-time the status of each open TCP session, but also to modify the parameters manually for all the TCP sessions, current or future (Figure 5). Performance evaluation tests in real conditions with different technologies (UMTS, 802.11b, GPRS, Ethernet, etc) will be the target of our future research. These tests will
Authorized licensed use limited to: UNIVERSITAT POLIT?CNICA DE CATALUNYA. Downloaded on May 25,2010 at 13:56:36 UTC from IEEE Xplore. Restrictions apply.
mainly put into relief the gain of TCP Adaptation in presence of environmental perturbations (random packet losses, loss of coverage, etc) and handovers (vertical and horizontal). The key performance metrics are the time required to recover from a packet loss or a temporary loss of connectivity, and the total duration of the TCP sessions. Moreover, it should be noted that the IETF PILC working group has already precisely identified the different TCP parameters that can be tuned to improve the transport sessions performances in wireless environments, but real evaluation tests of its recommendations are missing [10]. Besides, the CERN has proposed solutions for improving TCP by increasing the speed at which the congestion window size increases [11]. However, even if evaluation tests conducted for these solutions seem to give positive results, our approach is different since it targets to preserve the TCP semantics as much as possible and .the TCP behavior modification is less aggressive.
VII. CONCLUSION This paper addressed the E2R phase I concepts on reconfigurable equipment that facilitate a management-centric configuration model charged with the responsibility for the deployment of the reconfiguration process [14]. A policy model was presented and incorporated in a generic framework for decision making and policy enforcement. In addition, the protocol reconfiguration and adaptation procedures were highlighted and key performance metrics were considered. The evolution of the reconfigurable equipment management to serve the requirements posed by autonomic environments was also discussed. ACKNOWLEDGMENT This work has been performed in the framework of the EU funded project E2R II. The authors would like to acknowledge the contributions of their colleagues from E2R II consortium. REFERENCES
TCP TCPAdaptation Adaptationinterface interface(GUI, (GUI,command commandline, line,process) process)
[1]
User Space Parameters adaptation for new sessions
Parameters reading (all sessions)
tcp_param_put tcp_param_put module module
Current sessions adaptation
Virtual VirtualFile FileSystem System(VFS) (VFS) ioctl ioctlsystem systemcalls calls
ssthresh ssthresh factor factor
dup ACK
dup ACK
cwnd init cwnd init
[2]
tcp_param_get tcp_param_get module module
cwnd min cwnd min
[3] Current Current Sessions Sessions
[4]
TCP TCP
[5]
Kernel Space
Figure 5: TCP Adaptation Framework
VI. EVOLUTION OF THE RECONFIGURABLE EQUIPMENT MANAGEMENT TOWARDS AUTONOMIC ENVIRONMENTS The reconfigurable equipment management and control architecture is envisaged to evolve in order to accommodate future autonomic environments [12]. One of the key issues is the evolution of decision making mechanisms to accommodate autonomic decision making and reconfiguration management procedures, based on policy hierarchies. In addition, the incorporation of dynamic policy rules generation, reflecting the QoS requirements and system behaviour, will form one of our next research targets. Moreover, the advancement of the presented protocol reconfiguration frameworks by exploiting self-knowledge features towards autonomic self-configuring software components will be considered [13]. In this direction, a semantic layer of information for each protocol component is introduced, incorporating intelligence in the components. Such information may comprise dynamic characteristics which depict the current component configuration in the system and are dynamically updated according to the different protocol stacks stratification. Based on such information, the protocol components will be able to verify and establish their composition to other components on their own.
[6]
[7] [8] [9]
[10] [11]
[12] [13]
[14]
J. Vogler et al., “Equipment Management and Control Architecture”, IST-2003-507995 Project E²R White Paper, July 2005. Sergio Mena, Xavier Cuvellier, Christophe Gregoire, Andre Schiper: Appia vs. Cactus: Comparing Protocol Composition Frameworks. 22nd International Symposium on Reliable Distributed Systems (SRDS'03), Florence, Italy, October 2003. Y. Lee and R. Chang, “Developing dynamic-reconfigurable communication protocol stacks using Java: Research Articles. Softw. Pract. Exper. 35, 6 (May. 2005), 601-620 N. Samaan and A. Karmouch, “An Automated Policy-Based Management Framework for Wired/Wireless Differentiated Communication Systems” in special issue of JSAC on Autonomic Communication systems, December 2005, Volume 23, Number 12 P. Vidales, J. Baliosian, J. Serrat, G. Mapp, F. Stajano, A. Hopper, Autonomic Systems for Mobility Support in 4G Networks. IEEE Journal on Selected Areas in Communications, Volume 23, Number 12, IEEE, December 2005 SWRL: A Semantic Web Rule Language Combining OWL and RUleML – W3C Memebr Submission 21 May 2004, http://www.w3.org/Submission/SWRL/ OWL Web Ontology Language – W3C Recommendation 10 February 2004, http://www.w3.org/TR/owl-features/ The Rule Markup Initiative, www.ruleml.org E. Patouni, N. Alonistioti, and P. Magdalinos, “A Framework for Protocol Reconfiguration”, in the Proceedings of the Seventh IFIP International Conference on Mobile and Wireless Communication Networks, Marrakech, Morocco, Sept. 2005. IETF Performance Implications of Link Characteristics (PILC) working group, www.ietf.org Sylvain Ravot, “Results on High Throughput and QoS Between the US and CERN”, California Institute of technology - Cern External Network Division, Datagrid WP7, January, 2002 Jeffrey O. Kephart, David M. Chess. "The Vision of Autonomic Computing," Computer, vol. 36, no. 1, pp. 41-50, January, 2003 E.Patouni and N.Alonistioti, A Framework for the Deployment of SelfManaging and Self-Configuring Components in Autonomic Environments, accepted for the International IEEE WoWMoM Workshop on Autonomic Communications and Computing (ACC 06) , Niagara-Falls / Buffalo-NY, 26-29 June, 2006 IST project End-to-End Reconfigurability (E²R), www.e2r.motlabs.com
Authorized licensed use limited to: UNIVERSITAT POLIT?CNICA DE CATALUNYA. Downloaded on May 25,2010 at 13:56:36 UTC from IEEE Xplore. Restrictions apply.
