Protocol Decomposition: the first step towards network ...

Protocol Decomposition: the first step towards network layer reconfiguration Konstantinos Boukis, Nikos Georganopoulos, Hamid Aghvami Centre for Telecommunications Research King's College London University of London 26-29 Drury Lane London WC2B 5RL, UK {konstantinos.boukis, hamid.aghvami}@kcl.ac.uk Toshiba Research Europe 32 Queen’s Square Bristol BS1 4ND, UK {nikos.georganopoulos}@toshiba-trel.com Contact details of the first author: Konstantinos Boukis Centre for Telecommunications Research King's College London University of London 26-29 Drury Lane London WC2B 5RL, UK Tel.: +44 20 7848 1807 Fax.: +44 20 7848 2664 Email: [email protected] Abstract In this paper is presented the research conducted in collaboration of King's College London and Toshiba towards the design of a mobile terminal capable of reconfiguring its network layer with an emphasis on the mobility protocols. An in depth analysis of one of the most significant processes towards reconfigurability is analyzed. This is the decomposition of the terminal functionality in a number of orthogonal components. The analysis concludes with the observation that a single entity capable of adapting to every mobility protocol of interest can be designed. Keywords Reconfigurability, Mobility Management, Decomposition, Orthogonal Components

1

Protocol Decomposition: the first step towards network layer reconfiguration Konstantinos Boukis1 , Nikos Georganopoulos2 , Hamid Aghvami1 (1) Centre for Telecommunication’s Research, King’s College London, 26-29 Drury Lane, London WC2B 5RL (2) Toshiba Research Europe Ltd: Telecommunications Research Laboratory, 32 Queen Square, Bristol BS1 4ND

Abstract— This paper presents the work 1 towards the design of a mobile terminal capable of reconfiguring its network layer with an emphasis on the mobility protocols. Four distinct procedures toward achieving mobility protocol reconfiguration have been identified and the first in the rank, the protocol decomposition which is the classification of the operations that comprise a protocol, is thoroughly analyzed. The analysis concludes with the observation that a single model can be adapted to represent various mobility protocols that have been considered. This model is employed to represent Mobile IP, BCMP and Hierarchical Mobile IPv6.

I. I NTRODUCTION The evolution of mobile communications in recent years has resulted in the development of a plethora of new application and network services. As a result for a single service like mobility management numerous protocols were developed with trivial differences among them. This plethora hampers the terminal design since the problem that arise is how could possibly a terminal be equipped with all the appropriate software for every single service. The problem becomes even more intense for mobile terminals that have no preemptive knowledge for the services offered by the visited networks. This is the issue addressed by flexible reconfigurable systems, i.e. to identify the offered network services and install the appropriate software in order for the terminal to make use of them. Reconfigurable systems has been the focus of the research community for the last years and numerous solutions has been already proposed for tackling different aspects of it. The Flexible Protocol Stack framework, [1], aims to tackle reconfigurability related issues of the data link layer with the aid of a generic protocol stack architecture which consists of two fundamental definitions, the generic protocol components and the generic protocol interfaces (GPI) respectively. The GPI supports the existence of generic service access points which can be dynamically bound and re-bound so as to achieve different protocol stack arrangements. Reconfigurability is achieved with dynamic modification of the generic protocol components with the aim of enabling optional or proprietary features. This framework also provides a mechanism for the development of language and platform independent modules 1 This

research is funded by Toshiba Research Europe Ltd

thus expanding the applicability of the architecture to a large number of distinct execution environments. Furthermore the Dynamic Network Architecture, [2], which enables the number of layers a message traverses to be variable. Consequently the application programmer can configure the appropriate layer format for enhancing the overall performance of the communication system. The focal point of this mechanism is an acyclic protocol graph that represents the communication system and is derived from the decomposition of the communication protocols in a number of generic components. On the contrary to conventional architectures where the protocol graphs are simple, the protocols functionality is complex and both the set of protocols and the topology of the graph are static, the proposed architecture offers a complex protocol graph, simple protocols and both the set of protocols together with the topology are selected by application programmers. The network software is represented with a graph that consists of two types of protocols, the microprotocols and the virtual protocols. The former are similar to conventional protocols whereas the latter serve only to direct messages through the protocol graph. The platform in use for implementing dynamic network architecture is the x-kernel, [3], which provides an explicit architecture for composing network protocols. Although this proposal enables tailoring of the terminal to the offered protocols its main drawback is that a system reboot is required for the changes to take effect. Also the Programmable Handoff in Mobile Networks framework, [4], separates communication hardware from control software thus allowing the modelling of hardware resources using open programmable interfaces. Therefore the creation, development and management of new network services, such as handover, can be automated. Two novel handover schemes are developed and deployed, the first, called multi-handoff, provides different styles of handover control within the same access network. The second, addressed reflective handoff, enables the mobile terminals to roam between wireless access networks that support different mobility management protocols. Reconfiguration on handoff schemes is achieved by identifying a number of common features among different styles of handover. In our research the focus is on the design of a mechanism to enable a mobile terminal to adapt to the mobility protocol offered from the visited network. The development of a recon-

2

figurable network layer platform can be quite a complex task, however it can be eased by breaking it down into individual procedures. Four are the major procedures identified towards designing a reconfigurable network layer platform. 1) The protocols of interest are studied and decomposed in a number of orthogonal functionalities, which are called components. Orthogonality implies that each component performs a unique and independent operation. We refer to this procedure as decomposition and it can be seen as a form of layering within the protocols. 2) The second procedure is the definition of a mechanism for dynamic replacement of the identified components, with the goal of achieving the desired functionality. 3) The third procedure is the identification of the model of computation, i.e. the mechanism employed for component communication. The model of computation has a huge impact on the design since it identifies several issues such as whether every component is implemented as a different process or not. 4) The final procedure is the development of a module that will identify the offered service from the network and it will initiate and manage the reconfiguration process. This paper focuses on the first procedure, the protocol decomposition. The next section presents the decomposition of three mobility protocols, one macro and two micro. Then the analysis advances by the description of a unified entity for mobility management and a discussion on the benefits such an entity can offer. II. P ROTOCOL D ECOMPOSITION This section describes more thoroughly the first procedure towards designing a reconfigurable network layer mobile terminal. The mobile host functionality for every mobility protocol of interest was studied thoroughly and the functional blocks that comprise the overall operation were identified. Due to space limitations three mobility protocols are considered and presented in this paper. Initially the Mobile IP (MIP) is analyzed not only because it is the dominant approach for macromobility scenarios but also due to the influence MIP has on other proposals. Then two proposals for micromobility are presented, the Hierarchical Mobile IP (HMIP) and the BRAIN Candidate Mobility Protocol (BCMP). A. Mobile IP Mobile IP ,[5], [6], is a distributed protocol having its functionality divided between the mobile node, the home and foreign agents. The home agent (HA) is a server situated on the home link of the mobile node. The foreign agent is a router situated on the visited network. The presence of the foreign agent entity is not mandatory and in IPv6 it is omitted altogether. Almost all the MIP operations are initiated from the mobile host and amongst all, the most essential function from reconfiguration perspective is the handover which is responsible for configuring the appropriate parameters that will allow the mobile node to resume IP connectivity after migration to a new network. For the handover to be accomplished the mobile node

!

!

"

Fig. 1.

Mobility protocol decomposition to orthogonal components

must inform its HA of its current location through exchanging protocol messages. Other MIP functions vary from sending ICMP solicitations, either router or mobile prefix solicitations, to exchanging authentication messages. The data flow diagram in Fig. 1 depicts the number of individual components that MIP is analyzed. The MIP component receives as input mobility packets from the IP component. Initially the mobility packets are passed to the Packet Verification component that is responsible to check the validity of the packet. The syntax of the packet is examined so as to verify its compliance with the standards and also to check the packet fields for their consistency. Packets that do not comply with the protocol specifications or that indicate rogue behavior of the sender are silently discarded. The second component in the hierarchy is the Movement Detection, which is a filter that examines incoming router advertisements with the scope of identifying a terminal movement. Ample of algorithms can be employed for the detection of a movement; in the specification of MIPv4 two algorithms are defined as possible candidates, without however restricting development and the employment of alternative mechanisms. The first algorithm is based on the subnet prefix field whereas the second is based on the lifetime field. If a movement is detected the next component in the hierarchy is galvanized. The Handler is a finite state machine, which according to the stimuli and the current state performs the appropriate action. This component is modelled as a finite state machine so as to represent elegantly its polymorphism. We will follow a quite unorthodox approach and prior to explaining extendedly this component we will explain the other components of the model. Then a thorough explanation of the Handler will be presented. After the terminal movement to a new network some

3

" # $ %

! !

&

"

!! !

#

"

!

"

! !

Fig. 2.

The Finite State Machine inside the Mobile IP Handler.

configurations must take place so as for IP connectivity to be resumed. Those configurations are the routing table manipulation and the acquisition of an IP address. The Network Configuration component is responsible for that specific task. It is notified from the Handler when it requires a modification on network parameters and it interacts with IP to accomplish that. The Network Configuration component is responsible for configuring the IP in respect to installing tunnel interfaces for receiving or transmitting data packets. Some events in the protocol operation are triggered from timers. This behavior is modelled with the presence of the Timers component which is set from the Handler when appropriate. Finally the Control Packet Constructor is the component responsible for the creation and transmission of the MIP control messages. It is triggered from the Handler after the presence of a handover for the transmission of registration requests to the Home Agent. Let’s now consider at the Handler in more detail; Fig. 2 presents the states of the machine and also the transitions from one state to the other for MIPv6. The same state machine also models the behavior of MIPv4. On top of every transition is shown the stimulus that initiates the transition together with the action taken. The first state is the Idle which denotes that the terminal is located at its home network and thus it is not employing any MIP specific feature. When a handover is detected the Handler notifies the Network Configuration component to acquire a valid IP address for the current network. The Control Packet Constructor is also triggered so as to construct a Binding Update (BU) or a registration Request for MIPv4 and to transmit it to the HA. Finally the Timer component is set to the protocol specific value in which a response from the HA must been received. After the accomplishment of those actions a transition to the WaitA state occurs. The WaitA state, stands for Wait Acknowledgment, denotes the situation where a binding message has been transmitted to the HA but an acknowledgement message is pending. While in this state if the timer expires the binding message is retransmitted and the terminal remains in the WaitA state. Alternatively if a new handover occur the terminal remains in the same state and the actions described previously are repeated, i.e.

acquisition of IP address, transmission of BU and timer set. A binding acknowledgement with status field 135 denotes that some parameters of the BU message are invalid and thus the message is transmitted again with the correct fields. The reception of a BA (or a registration reply for MIPv4) with a status field that denotes a successful registration triggers the transition to the Bound state. Due to this transition the timer set for BU retransmissions is ceased and additionally for MIPv4 the routing table of the terminal is configured. Binding Acknowledgments that denote unsuccessful registration trigger a transition to the Idle state. Finally, if the terminal returns to its home network a transition to the WaitD state takes place. The Bound state represents the situation where the terminal is currently registered successfully with the HA. Two transitions are possible, either to the WaitA or to the WaitD state. A transition to the former state can occur either on the event of a handover or when a Binding Request message is received. Transition to WaitD takes place when the terminal returns to its home network. While transiting to this state, similar actions occur as in the event of the handover but additionally the terminal must inform other nodes on the network for its return so as the latter to update their IP to layer 2 address mappings. While on the WaitD state the terminal behaves in a similar manner as in the WaitA state. The main differentiation is that when a valid Binding Acknowledgement is received the terminal transits to the Idle instead to the Bound state. Conceptually MIP is a multithreaded protocol in the sense that the mobile terminal interacts simultaneously with a number of nodes varying from the home agent, correspondent nodes that attain sessions with the terminal and finally home agents on the visited links that the mobile terminal desires to register for optimization purposes. Consequently the Handler must maintain a database so as to store state information for every binding individually and to manage this binding independently of others. B. Hierarchical Mobile IP Hierarchical Mobile IPv6 (HMIP), [7], is a proposal that is based on the concept of local bindings complementary to MIP. The focal entity on the protocol architecture is the Mobility Anchor Point (MAP) that functions similarly to a MIP HA, and maintains a binding cache with the terminal’s Regional Care-of Address (RCoA) and On-Link Care-of Address (LCoA). The mobile host informs the MAP of its new LCoA after every intra domain handover. Since HMIP is based on MIP it is modelled with the same abstractions. The first component in the architecture is the Packet Verification which acts identically as described for MIP. In addition to the MIP messages this component must be capable of verifying the added MAP option on the router advertisements and the LCoA Test option on binding acknowledgements. The Movement Detection component is slightly modified since it must be capable of identifying inter and intra domain handovers. The component’s functionality is based on the MAP option of the router advertisements. If a new advertisement contains the address of the MAP the terminal is

4

registered with, then a migration has occurred on the same domain alternatively an inter domain handover is assumed. The Handler shown on Fig. 3 is modelled with a finite state machine which is similar to the MIP Handler except that the WaitD state is omitted. The machine initiates at the Idle state and when an inter domain handover occurs it acquires an RCoA, an LCoA and sends a local BU to the MAP; then a transition to the WaitA state takes place. ! " #

%$' '

&

( (

' '

( (

actions are initiated from the terminal and also acknowledgements are defined this component is responsible for verifying a plethora of messages, varying from Login Replies, to Handoff Acknowledgments and access router beacon messages. The next component is the Movement Detection which identifies terminal migrations and generates the appropriate stimuli to be handled by the next component. It is this component’s responsibility to distinguish between inter or intra domain movements and to trigger the next component the Handler. The Handler is the component that performs the appropriate actions according to the stimuli it receives at its inputs. As in the case of MIP it is modelled with a finite state machine, which is shown in Fig. 4. The initial state is the Idle which denotes that the terminal is not registered yet with the access network. When the presence of the BCMP access network is sensed, a Login Request message is sent and a transition to the WaitL state takes place.

!

!

Fig. 3. The Hierarchical Mobile IPv6 Handler. Note that it is similar to the MIP without the WaitD state. !

From the WaitA state the reception of a successful binding acknowledgement will cause a transition to the Bound state and the initiation of a MIPv6 registration. Additionally a subsequent inter or intra domain move will cause the acquisition of care-of addresses, transmission of a BU and no transition to other state. If, finally, an inter domain handover at the home network occurs then the state machine transits to the Idle state. While on Bound state an inter domain handoff will trigger the acquisition of an RCoA, an LCoA and transmission of a BU together with a transition to WaitA. Similar actions occur on an intra domain handover except that an RCoA is not required. Similarly with WaitA, a return in the home domain will cause a transition to the Idle state. To conclude the Network Configurations, Control Packet Constructor and Timer components behave identically as in MIP. Only the Packet Constructor is required to insert a new flag in the local BU so as to distinguish them from the equivalent MIP messages. C. BRAIN Candidate Mobility Protocol The BRAIN Candidate Mobility Protocol, [8], defines its own messages and functionality for tackling micromobility and relies on other protocols for supporting macromobility. It offers both planned and unplanned handover and employs tunnels for packet delivery. As with every other mobility protocol all operations are mobile host initiated. BCMP is as well modelled with the components depicted in Fig. 1. The first component is responsible for verifying packet consistency and compliance with the standards. Since all

Fig. 4. The finite state machine inside the BCMP Handler. BCMP is completely independent from Mobile IP and their state machines bare no similarities.

While on WaitL subsequent movements trigger the transmission of another Initial Login message. Similarly if an acknowledgement is not received within a specified time period then a retransmission occurs. If, on the other hand, a Login Reply message is received then the terminal configures its interface and routing table and transits to the Bound state. From the Bound state a transition to the WaitH state occurs after the migration to another subnet within the same domain, accompanied by the transmission of a Handover message. If the terminal desires to perform a planned handover instead, then a transition to the WaitP state takes place followed by the transmission of a Handover Preparation message. Inter domain handovers will cause the registration with the new domain, thus a Login Request message is sent and the next state is the WaitL. Finally if the terminal wishes to depart from the network it sends a Logout message and also returns to the Idle state. The WaitH state represents the anticipation of a Handover Acknowledgement message. Subsequent movements from this state are handled according to the style of handover. Intra domain handovers cause the retransmission of a Handover

5

message and no transition to other state. Inter domain handovers will initiate a registration and a transition to the WaitL state. Finally if a valid Handover Acknowledgement is received then the routing table is configured and the next state is the Bound. The WaitP state denotes the expectation of a Handover Preparation Acknowledgement message. A successful reception of an acknowledgement or an intra domain move will cause the transmission of a Handover message and a transition to the WaitH state. If the planned handover does not complete successfully then a transition to the Bound state occurs. Inter domain moves cause initiation of a registration and a transition to the WaitL. The Network Configuration and Timers components act identically as in MIP. Finally the Control Packet Constructor is responsible for constructing the BCMP control packets which are the Login Request, Handover, Handover Preparation and Logout. III. T HE U NIFIED M OBILITY C OMPONENT From the above analysis emerged that all the protocols of interest can be modelled with identical individual components. This lead to the conclusion that a generic architecture can be developed that could adapt to the offered protocol. In this unified component includes generic methods for every single component and according to the protocol that requires to be implemented those generic methods are configured to perform accordingly. For instance the first method in this architecture is the Packet Verification, the second the Movement Detection and so on according to Fig. 1. If the mobile terminal desires to install a protocol instead of acquiring the complete program it only has to obtain the individual components and install them in the architecture. Additionally more than one protocols can be supported simultaneously so coexistence of macro and micro mobility protocols can be managed elegantly. This model for the mobility protocols provides a number of advantages. Most significantly only one component is responsible for tackling mobility. Consequently this is economical from the system resource perspective since only one process is required. Additionally interaction between macro and micro mobility protocols is provided internally in the component and no Inter Process Communication is necessary. Apart from that reconfigurability can be achieved with the acquisition of the appropriate template for every protocol thus minimizing the required modifications and also the necessary modules that need to be obtained from other network nodes. Another advantage is the avoidance of redundant operations. There are a certain number of common operations performed from every protocol, thus if multiple mobility protocols operate simultaneously it is not necessary for those operations to be repeated. One example of that is the movement detection process. Since the micromobility protocol can sense both inter and intra domain handovers it is not necessary to perform the macromobility movement detection. Another example is the Network Configuration component which is system specific, ergo it is not have to be obtained for every single mobility protocol. Closely related to that advantage is also the management of the terminal’s interfaces and routing table. Since

a single component is responsible for managing the terminal resources, confusion that can lead to improper configuration is avoided. To conclude, the unified mobility component is the union of the micro and macro mobility procedures thus redundant operations are omitted. IV. C ONCLUSIONS In this paper part of the research conducted towards the design of a reconfigurable network layer mobile host has been presented. The focus was on the first procedure identified toward accomplishing the goal of reconfigurability which is the protocols’ decomposition. Three of the major mobility protocols were decomposed in a number of orthogonal components and thought out this analysis it emerged that the same abstractions can be employed for analyzing every protocol. Based on this observation it was presented how a unified component can be implemented that will be able of adapting to the appropriate mobility protocol offered from the visited network. Such a unified mobility component is economical from the system resource perspective and additionally it enables elegant cooperation of micro and macro mobility protocols. Currently research efforts focus on the definition of the model of computation employed in the architecture together with the mechanism for dynamic modification of the components. R EFERENCES [1] T. Farnham and T. Scholer, “Flexible Protocol Stack Framework: Design Evaluation and Performance,” in SDR 2003, November 2003. [2] S. O’Malley and L. Peterson, “A Dynamic Network Architecture,” in ACM Transaction on Computer Systems, May 1992. [3] N. C. Hutchinson and L. Peterson, “The x-Kernel: An architecture for implementing network protocols,” in IEEE Trans. Software Engineering, January 1991. [4] M. Kounavis, A. Campbell, G. Ito, and G. Bianchi, “Design, Implementation and Evaluation of Programmable Handoff in Mobile Networks,” in ACM//Kluwer Journal on Mobile Networks and Applications, September 2001. [5] C. Perkins, “IP Mobility Support for IPv4,” RFC 3344, August 2002. [6] D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004. [7] H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier, “Hierarchical MIPv6 mobility management (HMIPv6),” IETF draft, (work in progress), July 2002. [8] C. Boukis, N. Georganopoulos, and H. Aghvami, “A Hardware Implementation of BCMP Mobility Protocol for IPv6 networks,” in GLOBECOM 2003, December 2003.