The Layering Principle and Mobility Performance

Transcription

1 The Layering Principle and Mobility Performance Teemu Rinta-aho Helsinki University of Technology Telecommunications Software and Multimedia Laboratory Abstract Many current networks provide mobility for end-users, and there exists several different protocols and mechanisms to support this on various networking layers. The number of available wireless and wired networks is increasing. These networks are owned and operated by different administrative entities, with different security and other requirements. More and more terminals are now supporting multiple different networking technologies, e.g. both WLAN and UMTS. Together this leads to a situation where all the protocols operating in a layered networking architecture can not fulfill all of today s mobility and security requirements if they don t co-operate. This paper is an introduction to mobility, layered network architectures and their mobility support mechanisms, and to the idea that some level of coordination between layers is required for a layered network architecture to support efficient mobility. Further measurements and simulations are left for further study. KEYWORDS: mobility, layered network architectures 1 Introduction In section 2 we have a look on mobility: what is actually moving, and how. In section 3 we have a look on network architectures and layering. In section 4 some new ideas on how to improve the protocol stack regarding mobility are presented. In section 5 two systems are compared: another one follows strict layering principles, while another one is more relaxed on this principle, allowing better mobility performance. In section 6 some related and future work are introduced, and in section 7 the paper is concluded. 2 Mobility Today, mobile computing in practice is mostly realized as users of laptop computers connecting to the Internet and their home networks via data services of mobile phone networks or some local WLAN hotspots. This is the traditional view of mobile computing, and represents host mobility, in which a communicating host (together with the user and applications) is moving between different access networks. However, mobility support in general, is the process of handling the needs of the mobile objects. These needs usually are reachability and session continuity. 2.1 What is moving To better understand the problems and requirements of mobile computing, it is first necessary to understand what are the mobile objects and what are their requirements on mobility. At the highest level there are five communicating entities, which can be mobile: users, data, applications, hosts, devices, and networks [2]. Mobility of these objects can be characterized as dynamic relationships between all of them. For example, users and applications may change between hosts, physical storage with the data can be attached to different hosts as well. Hosts, in turn, may change attachment to underlying networks, thus changing locators at network interfaces. In addition, hosts may form groups moving networks which are moving between various networks as well [2]. Therefore, mobility support can be thought, on a high level, to be the process of maintaining these dynamic relationships of mobile objects. Basically the mobility has to take care of mapping different identifiers to locators or other identifiers, maintaining the reachability of the mobile objects, and maintaining session continuity through the mobility events [2]. Let s assume the user in Figure 1 is running Application A, which displays Data K. The application may be e.g. a web browser, or a streaming video client, and the data may be a web page or a video file, respectively. The data is refererred to with an URL. The user is using Host X, which has two network interfaces (NW intf 1 and NW intf 2). Data K is handled by Application D on Host Y, which has also two network interfaces. Let s assume Host X is connecting Application A to Interface 1, which is connected to Network 1 (NW1). On the server side, the path is NW2 -> Interface 3 -> Host Y -> Application D. Now, depending on what types of mobility this network architecture supports, we might have: User Mobility (e.g. User moving from Host X to 1

2 Discovering options Making decisions Execution Triggering events are something that trigger or start the mobility process. Triggering events can happen on any networking layer, or outside the networking stack. Some examples of triggering events are: network cable unplugged Host Y) Figure 1: Mobile objects Content Mobility (e.g. Data K moving from Host Y to Host Z) Application Mobility (e.g. App A moving from Host X to Host Y) Host Mobility (e.g. Host X moving from Intf 1 to Intf 2) Interface Mobility (e.g. NW1 to NW2) Intf 1 moving from Network Mobility (e.g. Hosts X, Y, Z form a network which may move in relation to the other networks 1-4) Interface mobility is what e.g. Mobile IP was created for. When an interface connected to a host changes its IP subnet, Mobile IP updates the home address (= Host s identifier) and care-of address (= Host s location) mapping at the Home Agent and in the Correspondent Nodes. Mobile IP is also good for moving the connections from interface to another. But it does not support the simultaneous usage of multiple interfaces. But what if happens so, that the Data K is physically stored on e.g. a USB memory stick, and is moved to a different physical machine, Host Z. First of all, there is the issue to design whether the serving application moves together with the content, or whether there is another application (App E) that can serve the data to the clients. Another issue is to handle the updates in the bindings of mobile objects, and to update the reachability information. These were just two examples of what could be mobile. The next section takes a look on to the mobility process, common to all types of mobile objects. 2.2 The mobility process Mobility can be seen as a continuous process, which consists of the following steps (see Figure 2): Triggering events signal quality went below threshold a new network interface attached a new networking protocol installed These triggering events indicate a change in the system or network status. After receiving such a triggering event, the system needs to discover the options. For example, if the system gets a link-down event from a network interface driver, there is a need to discover what are the other available network interfaces that fulfill the requirements of the running applications and the preferences set by the user. The collection of application, user and the network preferences can be called a set of policies. A user preference could be e.g. how much money he or she is willing to spend on the services, or the required security level for communications. Applications may have minimum requirements for the communication service to be able to do their job, e.g. streaming HDTV application may require a 100Mbit/s network connection. Networks, service providers and operators may have policies on the use of the available networks. This information may be physically stored on e.g. a SIM card, or it may be updated from the network. However the policies are implemented, the system need to be able to prioritize them and resolve possible conflicts. After discovering the current status of the system, and discovering all the options, a decision whether to perform some actions is needed. This decision can be for example making a handover from an access point to another, or making a handover between different types of network interfaces connected to the same mobile node. The last part of the mobility process is the execution. This usually involves signalling between the networking entities. The used signalling protocol depends on the type of mobility. While SIP may be used for session mobility, MIP could be a better choise for host mobility. In current systems the mobility processes are usually restricted to a certain networking layer. This may cause problems if the mobility process is basing the decisions on inadequate amount of information on the whole system. A prime example is Wireless LAN and IP stack. 2

3 Figure 2: Mobility process In e.g. IEEE networks it is not possible to detect the network layer services that are available via an access point, and no way for the higher layers to control the handovers between of IEEE mobile stations between access points. While the IEEE network interface is looking at the network ID (i.e. a text string) and signal quality, IP layer is interested in end-to-end reachability and applications in QoS. Most mobility protocols like Mobile IP actually only patch a network architecture that was not designed for mobility in the first place. This kind of solutions are easier to accept and deploy, than solutions that solve the problem by changing the architecture, like the Host Identity Protocol [9]. In the following chapter we ll have a closer look on the network architectures and some mobility solutions. 3 Network Architectures and Mobility The chosen network architecture has a great impact on the mobility support the network can offer. Typically current network architectures are based on a layered network model, although some other proposals have been proposed [4], but not yet deployed. 3.1 Layered network model Current packet-based network architectures assume that the communication functions are organized into levels of abstraction called protocol layers, and the metadata that controls the protocols on different layers is organized into protocol headers. In Figure 3 the seven layers of the OSI network model are presented. The idea in the model is that each layer only offers services to the layer just above it, and only uses services of the layer just below it. For example, the network layer offers end-to-end packet delivery to the transport layer, and it is using the data link layer to actually send and receive the frames that carry Figure 3: Seven layers of the OSI model the network packets. The layered protocols in a system form a network stack. Current TCP/IP stacks only realize layers from transport to network, while the ethernet drivers and hardware take care of the lowest two layers. Applications connect to the stack through a sockets API. This kind of layered networking architecture has its pros and cons. One of the biggest arguments for this kind of an architecture is the independence of the layers from each other. A developer may change the protocol residing on a certain layer without affecting the protocols on other layers as long as the interfaces don t change. One drawback of the layered networking architecture is the lack of useful information available from other layers, if strict layering is followed. A simple example: both transport (e.g. TCP) and network layer (e.g. IPv6) protocols could use information from the data link layer (e.g. IEEE ) to enhance their performance. Information could be about the link quality or whether the wireless network adapter has decided to change to another access point. TCP congestion control algorithms could take into account whether the packet loss is on the first hop from the node or somewhere deeper in the network, while IPv6 could check the validity of the IP address immediately after a handover and not wait until a signal is received from its own timers. It is probably possible to have a layered protocol stack and good mobility performance, but the mobility decisions should be done in the right place. Whether the place in the system where the decisions are taken is static (e.g. in IP or in WLAN or outside the protocol stack) or dynamically changing, there is a minimum amount of information that is needed. So, the information may flow inside the stack from layer to another 3

4 Figure 4: Common coordinating function through the service interfaces, or it might be collected to a control plane which is controlling the layers (see Figure 4) as proposed in Ambient Networks [1]. 3.2 Network layer mobility To support mobility in the networking layer, IETF has standardized Mobile IP for both IPv4 [10] and IPv6 [7]. These are extensions to the existing IP architecture and protocols at the network layer that hide mobility from the higher layer protocols and applications. The problem with the existing IP architecture regarding mobility is that the role of the IP address is overloaded it serves both as the identifier and the locator of the end host. Mobile IP solves the problem by having one IP address the home address for identifying the node, and another IP address the care-of address for locating the node. Mobile IP also introduces a special node in the home network (the network where the home address topologically belongs to) a home agent that stores the care-of address to home address binding, and redirects traffic to the mobile node while it s not connected to the home network. If the correspondent node does not support Mobile IP binding updates from the mobile node, then the problem of triangular routing occurs. Mobile IP would make traffic stealing attacks possible, but that, among other security issues has been dealt by adding security features into the protocol. 3.3 Adding the host layer Host Identity architecture [8] is another extension to the IP architecture that provides, among other things, multihoming support. The Host Identity Protocol (HIP) provides a protocol for authentication and setting up security associations between two end-hosts [9]. It uses a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The cryptographic construct of the public-private key pairs provides strong mechanisms to authenticate remote identities, therefore HIP solves the IP address ownership problem that comes when using Mobile IP. In HIP, the public keys, not IP addresses, are used to identify a host. IP addresses are only used for routing IP packets. This implicitly leads to the situation that when a node receives a packet, it does not matter what is the source IP address, only the HIT (Host Identity Tag) is needed to identify the source of the packet. HIP adds a new layer host layer into the protocol stack between the transport and the network layers. In host layer, the binding between the HIT and a set of locators is managed. The HIP base exchange [XXX ref] is a 4-way handshake protocol that sets up a security association between two end-hosts. After this it is possible to run e.g. IPsec ESP protocol between the end-hosts. An extension to the HIP base exchange is the support for mobility and multi-homing [5]. HIP MM provides host mobility between IP addresses of same or different address families contrary to the Mobile IP, host layer provides mobility between IPv4 and IPv6 for a dual stack mobile node. 4 Enhancing the protocol stack 4.1 Collecting information Decision is based on available information at a time. The more information one has, and the more accurate it is, the better the decision is likely to be. A big part of the mobility process is the decision about handovers (i.e. decision to update mobility states). An isolated layer can t make good decisions as it lacks the knowledge of the needs of protocols running on other layers, application needs, user preferences, operator policies etc. One way to solve the problem is to move the decision making aside the protocol stack. This decision maker obviously needs information from the protocol stack but as well from the user, applications and the network. This information collection is called Trigger Collection in Ambient Networks [11]. Trigger Collection is a part of Trigger Management, which also contains e.g. Trigger Classification and a Trigger Repository. Triggers are caused by Triggering Events, which are events that may lead to an action in the mobility management system. 4.2 Access selection Currently in IEEE (WLAN) networks the mobile station selects the access point based on radio link parameters and the network id broadcasted in special 4

5 Figure 5: The access discovery and selection problem management frames called beacons. This information is, however, inadequate to base the access selection on. The user of the mobile station may have other preferences, such as price, while the applications need to know the available QoS etc. WLAN access points broadcast beacons on a regular basis, normally every 100 milliseconds. Extending the beacons with extra information makes them larger and thus wastes the available bandwidth on the channel. Inserting all desired information into the beacons would therefore not be desirable. One solution is that the beacon is extended only with a special flag which indicates that the access point is capable of delivering extra information before the standard WLAN attachment frames. If the mobile station supports using this extra information, it may send a special information request frame to the access point. The access point can then send the requested extra information in one or more special information reply frames. These information reply frames may contain any information that can help the mobile station to select the access point. The actual attachment process with the access point follows the normal WLAN procedure or as in the Quick NAP proposal (see the next section). This extra information may contain e.g. cryptographic identities list of available services with prices information on roaming partnerships supported security & AAA mechanisms It should be noted, that while this information is transmitted as part of the WLAN access point scanning, it is not useful in the existing WLAN access point selection algorithms, that are only designed with the link layer in mind. By passing this information to a software module which is aware of the whole stack will most likely result in better decisions. We could e.g. have a laptop which has an IPv4 stack and a WLAN interface. The WLAN interface will happily connect to an access point which is connected to an IPv6-only network, if there is just a strong signal to it. To prevent this kind of situations, the access points need to inform the mobile stations which services they offer. Network layer connectivity with IPv4 is one service, IPv6 another. There are two options, either the mobile station is aware of the services the other layers need or prefer, or there is a central process which makes the decisions and controls e.g. selection of the access point. 4.3 Network attachment Attaching to a WLAN access point requires several actions and roundtrips on several protocol layers before the applications at the mobile station can send and receive IP packets. These actions include e.g. authentication and association at link layer, IP address allocation and assignment, router discovery and network layer mobility updates. Performing these actions independently of each other results in suboptimal total system performance with sequential protocol runs and unnecessary timers on various layers. A new architecture, Quick NAP [3] takes the approach of looking at the whole network attachment process as a whole, and not concentrating on a single layer or a single process. Quick NAP provides a new protocol that combines link layer and network layer control functions within the same messages. In short, after the mobile station 5

6 Figure 6: Unoptimized messaging sequence for network attachment has made the decision to connect to the access point, the client initiates an attachment procedure. The first step is to run a Diffie-Hellman exchange to protect all subsequent communications and to authenticate opportunistically. In parallel with the Diffie-Hellman exchange, also third party authentication and authorization exchanges can be initiated (e.g. EAP, web-logins). After the authentication and authorization steps, the client can explicitly request services, e.g. IP network connectivity, IP address allocation or delegations of mobility updates. In the Quick NAP paper is proposed that the WLAN beacon would carry the hash of the access point s identity and also some other information. However, in the WLAN networks the beacon is broadcasted every certain time invertal, and enlarging it takes the bandwidth away from other (e.g. data) frames. Therefore it might be the best to compromise by keeping the beacon small, but using one extra round trip to query the information as described in the previous section. 5 Performance comparison To see the effects of the layering, we take two mobile nodes, both of which run HIP and IPv6. The first node strictly obeys isolated layering and sequential protocol runs, while another one uses cross-layer information like L2 triggers, parallel setup of many layers while attaching to an access network etc. We will compare the relative performance of these systems. Both mobile nodes (MN) have one g WLAN interface to connect to IPv6 access networks. Both nodes are having end-to-end connections to correspondent nodes (CN). Both nodes are using a home network based authentication server (AAA), and updating their location to the HIP Rendezvous Server (RVS). The difference between the two mobile nodes is that the first one is using the state-of the art protocols on each layer, which are not co-operating or sharing information, while the another mobile node uses different sources of information for access selection and a new network attachment protocol that sets up protocols on several layers in parallel. Another difference is that the first mobile node does not support the information extensions of the , while the second mobile does use this information to make better attachment decisions. After the first mobile node has received an beacon, its wireless lan driver checks whether the network id and the AAA settings match and makes the decision on whether to connect. At this stage, the mobile node does not know whether there is network layer connectivity through the access point. The IPv6 router discovery will later notice whether there are any usable IPv6 routers on the link. If there are none, there is no connectivity for the applications until the mobile node attaches to another access point which has IPv6 routers. IPv6 can t tell this to the WLAN driver, as it is on a different layer. The second node instead, can pick a suitable access point, if one is available, by re- 6

7 Figure 7: Optimized messaging sequence for network attachment ceiving extra information from the access points that were qualified by the information in their beacons (see section 4.2). The first node: After doing the attachment to the access point, 802.1X and EAP are used for authentication and authorization, followed by i protocol run to set up link layer encryption. After the link layer has been set up, setting up network layer follows. However, if there is no interaction between the layers, then there will be a delay before the next IPv6 Router Advertisement is received by the mobile node. After the Router Advertisement is received, the mobile node configures itself an IPv6 address and runs IPv6 Duplicate Address Detection with the mandatory one second delay. After the IPv6 address has been verified, HIP notices that the IPv6 address on the interface has been changed, and that triggers HIP to send location update messages to the location server (RVS) and correspondent nodes (CN), and applications can resume their communication (unless the TCP have timed out...). The second node: The second node supports Quick NAP, which integrates network attachment to the WLAN, IPv6 address allocation and mobility updates into just a few messages between the mobile node and the access point. The access point may communicate on behalf of the mobile node with the Access Network (AN) to allocate an IPv6 address from e.g. a DHCPv6 server. It may also forward the AAA signalling to the mobile node s home network, together with the HIP location update messages to the rendez-vous server (RVS). 6 Related and future work IETF has a working group on detecting network attachment (DNA). The purpose of this working group is to create mechanisms for an IPv6 node to detect that its link layer has or may have undergone a change, and whether its IP layer addressing and routing configurations are still valid or have changed [12]. Some of the proposed mechanisms are e.g. link layer triggers where the L2 protocol informs L3 protocols of changes in the link status. IEEE has a working group (Media Independent Handover Services) [6]. The purpose of the working group is to produce a standard way to do handovers between different IEEE 802 protocol family networks and some cellular networks. Work items include trigger collection, access selection, etc. Role-based architectures offer an alternative to the layered architectures [4]. This is a revolutionary shift in thinking and implementing, so it is yet to see if it progresses from the paper level. It is to be analyzed how this kind of architecture would help in supporting different mobility scenarios. Ambient Networks project presents an Ambient Control Space which aims to glue together the existing and new protocols and networks and offers transparent and seamless mobility between different types of networks, different address spaces and different operators. Future work is to implement the proposed enhancements into access selection and network attachment and to measure the effect of those in real systems. 7 Conclusions In section 2 we had a look into mobility, what it is and what could be the objects that are mobile. The conclusion is that the view on what is mobility should be broad when designing the network architecture, to avoid a later need to patch the mobility support in. Mobility can also be seen as a continuous process, where different events trigger different decisions, causing mobility events to happen. Section 3 introduced layered network architectures, and listed some mobility issues. Also two different solutions to add mobility into the IP architectures was presented, namely Mobile IP and HIP. In section 4 some new approaches on enhancing the 7

8 protocol stacks. One of the most important things is how to collect information, and who is using that information. Another enhancement is the extension of IEEE signalling to help selecting the correct access point. Third work that was introduced, was the Quick NAP, which brings more parallelism and therefore speed into the network attachment step. Section 5 presented how strict layering and even decent mobility performance is difficult to combine without some level of co-operation or information exchange between layers. Two example systems with HIP, IPv6 and WLAN were compared. It is clear that with strict layering the mobility performance would be far from the expectations of the end users. Section 6 presented some related and future work. The intention of the author of this paper is to work further on integrating the ideas presented in this paper. The work could include e.g. implementing a prototype and comparing it to existing solutions. [9] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. Host Identity Protocol. draft-ietf-hipbase-04.txt, work in progress, October [10] C. Perkins. IP Mobility Support for IPv4, revised. draft-ietf-mip4-rfc3344bis-02.txt, work in progress, October [11] V. Typpö, O. Gonsa, T. Rinta-aho, B. Tharon, and S. Bonjour. Triggering Multi-dimensional Mobility in Ambient Networks. In 14th IST Mobile & Wireless Communications Summit (IST 05), March [12] A. Yegin. Link-layer Event Notifications for Detecting Network Attachments. draft-ietf-dnalink-information-03.txt, work in progress, October Acknowledgements Yuri Ismailov, Jari Arkko, Jukka Ylitalo, Tero Kauppinen, members of the Ambient Networks project. References [1] Ambient Networks Project. D1.5 AN Framework Architecture (IST AN/WP1- D05). Technical report, December [2] Ambient Networks Project. D4.2 Mobility Architecture & Concepts (IST AN/WP4/D4.2). April [3] J. Arkko, P. Eronen, S. Heikkinen, and A. Prasand. Quick NAP - Secure and Efficient Network Access Protocol [4] R. Braden, T. Faber, and M. Handley. From protocol stack to protocol heap: role-based architecture. SIGCOMM Comput. Commun. Rev., 33(1):17 22, [5] T. Henderson. End-Host Mobility and Multihoming with the Host Identity Protocol. draft-ietf-hipmm-02.txt, work in progress, July [6] IEEE Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services (IEEE P802.21/D00.01), July [7] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, June [8] R. Moskowitz and P. Nikander. Host Identity Protocol Architecture. draft-ietf-hip-arch-03.txt, work in progress, August