Localized mobility management protocol implementation using PMIPv6

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2011

Bruno Filipe

Silva Santos

Localized Mobility Management Protocol

Implementation using PMIPv6

Implementa¸

c˜

ao de Gest˜

ao de Mobilidade

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática 2011

Bruno Filipe

Silva Santos

Localized Mobility Management Protocol

Implementation using PMIPv6

Implementa¸

c˜

ao de Gest˜

ao de Mobilidade

Localizada usando PMIPv6

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requesitos necessários à obten¸cão do grau de Mestre em Engenharia de Electrónica e Telecomunica¸cões, realizada sob a orienta¸cão cient´ıfica do Prof. Dr. Rui Lu´ıs Andrade Aguiar e do Dr. Diogo Nuno Pereira Gomes, professores do Departamento de Electrónica, Telecomunica¸cões e Informática da Universidade de Aveiro.

(4)

(5)

o j´uri / the jury

presidente / president Prof. Dr. Jos´e Lu´ıs Guimar˜aes Oliveira

Professor Associado da Universidade de Aveiro

vogais / examiners committee Prof. Dr. Manuel Alberto Pereira Ricardo

Professor Associado da Universidade do Porto

Prof. Dr. Rui Lu´ıs Andrade Aguiar

Professor Associado c/ Agrega¸c˜ao da Universidade de Aveiro (orientador)

Dr. Diogo Nuno Pereira Gomes

(6)

(7)

agradecimentos / acknowledgements

Ao Prof. Rui Aguiar pelo apoio, esp´ırito cr´ıtico e partilha de conhecimento que foram importantes na elabora¸cão desta disserta¸cão, e também pela oportunidade e orienta¸cão desta disserta¸cão.

Ao Diogo Gomes pelo convite a integrar o grupo HNG (Heterogeneous Net-working Group), actualmente ATNoG (Advanced Telecommunications and Networking Group), no Instituto de Telecomunica¸cões e pela co-orienta¸cão desta disserta¸cão.

Ao Instituto de Telecomunica¸cões por me ter fornecido todas as condi¸cões ao desenvolvimento desta disserta¸cão. Em particular, ao Daniel Corujo e João Paulo Barraca pelo apoio prestado, e também aos outros colegas do grupo ATNoG.

`

A minha fam´ılia e amigos pelo apoio, motiva¸c˜ao, divers˜ao e conv´ıvio pro-porcionados.

(8)

(9)

Resumo A popularidade dos dispositivos móveis, a evolu¸cão das suas funcionali-dades e aplica¸cões que requerem conectividade à Internet sem interrup¸cões, têm exigido um aumento cont´ınuo de largura de banda e a convergência de todos os servi¸cos para redes IP. Várias tecnologias têm vindo a ser de-senvolvidas para fazer face a estas exigências, tornando a redes actuais e futuras bastante heterogéneas. O desafio é desenvolver uma solu¸cão capaz de providenciar mobilidade IP nas redes actuais e de próxima gera¸cão. O Internet Engineering Task Force (IETF) desenvolveu vários protocolos para mobilidade IP, em que o Mobile IPv4 e o Mobile IPv6 foram os primeiros. No entanto estes protocolos requerem a participa¸cão do nó móvel na sinaliza¸cão do protocolo, e por causa do desempenho da mudan¸ca de ponto de acesso, foram desenvolvidas várias extensões. Em particular, o IETF desenvolveu o protocolo Proxy Mobile IPv6, influenciado pela popu-laridade das redes locais sem fios. Este é baseado em gestão de mobilidade pela rede o que o torna transparente para o nó móvel. A sinaliza¸cão também ´

e muito mais simples e a deteçcão de movimento é agnóstica à tecnologia. Nesta disserta¸cão de mestrado é apresentada uma implementa¸cão de gestão de mobilidade localizada usando Proxy Mobile IPv6 (PMIPv6). A imple-menta¸cão resultante, conhecida como Open Proxy Mobile IP (OPMIP), foi avaliada numa plataforma de testes com vista à medi¸cão dos parâmetros de desempenho, permitindo chegar a conclusões quanto ás vantagens da abordagem seguida. Também é apresentada e analisada uma solu¸cão que utiliza uma implementa¸cão do IEEE 802.21, dispon´ıvel em código aberto, para o suporte de deteçcão de movimento independente da tecnologia e mobilidade sem interrup¸cões. Os resultados obtidos demonstram a aplica-bilidade da solu¸cão em alternativa às extensões ao PMIPv6 para melhoria do desempenho na mudan¸ca de ponto de acesso.

(10)

(11)

Abstract The popularity of mobile devices with the ever increase of features and more rich applications requiring Internet connectivity, has led to a continuous in-crease in bandwidth requirements and a convergence of all services to all-IP networks. Several network access technologies have been developed to face these requirements, making today’s and future networks highly heteroge-neous. The challenge is to provide a solution to manage and provide IP Mobility in today’s and next generation heterogeneous networks.

The IETF has developed several protocols to provide IP mobility function-ality, with Mobile IPv4 and Mobile IPv6 being the first ones. But these protocols require a mobile node to participate in the protocol signaling and, due to handover performance concerns, several protocol extensions where developed. In particular, the IETF developed the Proxy Mobile IPv6 (PMIPv6) protocol, influenced by the popularity of WLAN networks. This protocol is a network managed solution that makes IP mobility transparent to the mobile node. Signaling is also significantly simpler and the movement detection technology agnostic and outside of the specification.

In this Master Thesis an implementation of localized mobility management using PMIPv6 standard is presented. The resulting implementation, dubbed Open Proxy Mobile IPv6 (OPMIP), was evaluated on a testbed and its per-formance measured, drawing conclusions on the advantages of the approach taken. This thesis also presents a solution that uses an open-source IEEE 802.21 implementation to support media independent movement detection and seamless handover. The results obtained show the applicability of the seamless handover with PMIPv6, an alternative to PMIPv6 protocol exten-sions to improve handover performance.

(12)

(13)

List of Figures

2.1 Mobile node communication with a correspondent node while on a foreign

network . . . 9

2.2 Mobility Header Format . . . 10

2.3 Binding Update Message Format . . . 11

2.4 Binding Acknowledge Message Format . . . 11

2.5 Mobility Options Generic Format . . . 12

2.6 PMIPv6 Signaling . . . 23

2.7 Proxy Binding Update message format . . . 24

2.8 Proxy Binding Acknowledge message format . . . 25

2.9 Home Network Prefix Option . . . 25

2.10 Handoff Indicator Option . . . 25

2.11 Access Technology Type Option . . . 26

2.12 Link Layer Identifier Option . . . 26

2.13 Link Local Address Option . . . 26

2.14 Timestamp Option . . . 27

2.15 Proxy Binding Update message operation decision . . . 31

2.16 PMIPv6 and IEEE 802.21 Integration Signalling . . . 32

3.1 OPMIP hierarchical view of component dependencies. . . 40

4.1 Amazing testbed node disposition. . . 53

4.2 Packet Inter-arrival Time . . . 56

4.3 Packet Loss Fraction . . . 57

(16)

(17)

List of Tables

2.1 Binding Update List entry . . . 15

2.2 Binding Cache entry . . . 18

2.3 Binding Update List entry extensions . . . 28

2.4 Binding Cache Entry . . . 30

3.1 The Boost.Asio io service object API. . . 38

3.2 Router Node entry. . . 40

3.3 Mobile Node policy entry. . . 41

3.4 Tunnels component API. . . 41

3.5 Route Table component API. . . 42

3.6 MAG service component API. . . 44

3.7 LMA component API. . . 48

3.8 The MAG driver abstract interface. . . 51

4.1 Processing Times (Mean and Confidence Interval) . . . 58

4.2 Proxy Binding Registration Mean Time in Microseconds at different Rates . . 58

4.3 Processing Time in the ODTONE and OPMIP Scenario . . . 59

(18)

(19)

List of Acronyms

2G Second-Generation Wireless Telephone Technology 3G Third-Generation Wireless Telephone Technology 4G Fourth-Generation Wireless Telephone Technology API Application Programming Interface

BA Binding Acknowledge

BE Binding Error

BU Binding Update

ESP Encapsulating Security Payload

FA Foreign Agent

FMIPv6 Fast Mobile IPv6 FPMIPv6 Fast Proxy Mobile IPv6

HA Home Agent

HAck Handoff Acknowledge HI Handoff Indication

HMAC Hash Message Authentication Code HMIPv6 Hierarchical Mobile IPv6

IANA Internet Assigned Numbers Authority ICMP Internet Control Message Protocol

ICMPv6 Internet Control Message Protocol version 6 IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force

IKE Internet Key Exchange

(20)

IO Input/Output IP Internet Protocol

IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 JSON JavaScript Object Notation

L2 Link Layer

L3 Network Layer

LMA Local Mobility Anchor LRU Least Recently Used MAP Mobility Anchor Point MAG Mobile Access Gateway MIPv4 Mobile IPv4

MIPv6 Mobile IPv6

MTU Maximum Transmission Unit NAI Network Access Identifier OPMIP Open Proxy Mobile IP PBA Proxy Binding Acknowledge PBU Proxy Binding Update PMIPv6 Proxy Mobile IPv6 SMS Short Text Message

TCP Transmission Control Protocol TLV Type-Length-Value

UDP User Datagram Protocol VoIP Voice over IP

WLAN Wireless Local Area Network

(21)

Chapter 1

Introduction

The popularity of mobile devices has prompted the fast pace development of this tech-nology and an increase of service offerings. Combined with the explosion of social networks over the Internet, and the widespread usage of WLANs, the necessity of convergence of the Internet Protocol (IP) in mobile telephony has become the current trend.

It was the 2G, primarily the GSM [1] standard (coinciding with the move from larger “brick-like” phones to smaller devices) that sparked the mobility revolution. This allowed users to be reachable anywhere without physical links, perhaps one of the main obstacles for widespread communication technology adoption. Mobile networks have far exceeded the penetration rates of fixed networks in all regions of the world. For example in Portugal, the subscription penetration rate in 2010 was 142,33% of the population. Compared to fixed line subscriptions this presents a ratio of 3,4:1 [2]. 2G networks also introduced a new variant of communication, the Short Text Message (SMS). SMS became the predominant form of communication among the youngsters, a trend that would latter spread to all ages. The popularity of mobile networks and the evolution of mobile terminals demanded for more data services and, given the trends, it was clear that there would be a continuous demand for more bandwidth for which the 2G was not prepared. The 2G was mainly built for voice services, thus the industry began work on a next generation of mobile technologies.

3G networks where developed with a focus on high speed IP data. One of main tech-nological evolutions was the change to packet switching instead of circuit switching for data transmission. During the development phase, a number of transition technologies were de-veloped, such as GPRS [1] and EDGE [1] on GSM based networks, and CDMA2000 [3] on CDMA based networks. Finally, the 3G systems standardized where the UMTS, standard-ized by 3GPP [1] for GSM based networks, and the CDMA2000, standardstandard-ized by 3GPP2 [3] for CDMA based networks. The high speeds offered by 3G enabled the streaming of media content. Also, new interfaces began to be commercialized providing access to the Internet to laptop computers, commonly termed “mobile broadband”.

Today we are on the transition from 3G to 4G networks and new technologies continue to be developed to increase data speeds, such as the HSDPA [1], HSDPA+ [1], WiMAX [4] and LTE [5]. The ITU-R has specified in its recommendations for 4G data rates of 100 Mbit/s for high mobility scenarios (such as cars and public transports) and 1 Gbit/s for low mobility scenarios (such as pedestrians and stationary users) to support advanced services and applications [6]. This next generation will be based on an all-IP network [7]. A differentiation

(22)

from previous technologies is the elimination of circuit switching, and thus voice calls will be supported by Voice over IP (VoIP). Several technologies are being developed to fulfill the requirements of 4G such as LTE-Advance [8] and WirelessMAN-Advance [9]. Another important development was the IEEE 802.11 wireless technology (WiFi) [10]. This gave laptop computers more freedom of movement while staying connected to the Internet, that is, to more easily connect a laptop without the annoyance of physical wires and the inherent difficulty that this type of technology presents in public places in terms of availability of connection points. This has become a fundamental component in today’s laptops and this technology continues to being evolved to support higher speeds [10]. It is now very common to find many places that offer free WiFi access to the Internet, specially in coffee shops and shopping areas. Even mobile phones have WiFi, as it allows a faster access than traditional mobile phone wireless technologies. Today, laptops dominate the market of personal computers and, like mobile phones, it may be argued that mobility played an important role in the adoption of the technology.

The evolution of mobile network technologies was, obviously, accompanied with the evo-lution of mobile devices, mainly mobile phones and then laptop computers. Mobile phones have gradually evolved to accommodate more features than those of a basic phone. Once they become hand-held, the next step was to increase its capabilities and functionality. Starting with more software capabilities such as browsing the Internet, listening to music, watching videos, interact with popular social networks such as Facebook [11] and Twitter [12], and even video content on YouTube [13]. More hardware has been integrated into mobile phones such as camera for video and photographs, GPS for navigation, Bluetooth [14], WiFi [10], giro-scope, digital compass and motion sensors. Today’s market is dominated by two kinds of mobile phones: the smartphone, which is the high end of mobile phones featuring most of all features previously mentioned; and the feature phone, which is the low end usually lacking most of hardware features previously mentioned. Most of the smartphone features benefit or require access to the Internet. Google Maps [15] navigation software, for mobile devices with GPS, not only uses the Internet to obtain its maps, which has the major benefit of always having the latest version, but also retrieves coordinates through WiFi [10] networks or GSM cells. This information can be collaborative, i.e, it comes from the user and to the user: a lot of information on places provided by Google Maps are provided by the users. It is very common for someone using this to search for a restaurant and see other people’s comments and then latter write their own review. Another interesting feature that smartphones can provide is augmented reality. This uses various hardware devices such as the camera, GPS, compass and motion sensors to augment reality, that is, identify the user location and field of view and provide additional information, that can be obtained online, into layers that are shown overlayed with the image captured by the smartphone camera. Moreover, users may buy and/or download new software to their mobile devices and in some devices upgrades for the mobile phone OS can also be downloaded. Almost everything we used to do is shifting to mobile devices. Today’s mobile devices and their trends opens many possibilities, to explore the fundamental social component which defines us as humans.

1.1 Motivation and Challenges

It is expected that mobile networks and devices become more powerful and rich, while providing ubiquitous connectivity over heterogeneous networks. The Internet is more widely

(23)

available than ever before. It is becoming a fundamental aspect of our social life, as can be seen by phenomena of social networks like Facebook and many others, after all, humans are social beings. It is expected a continuous demand for a better connectivity and higher speeds. Today we see users are not only consuming, but also producing content on the Internet such as blogs and videos, as it can see for example by the popularity of YouTube. The widespread usage of different access technologies and the increasing support for multiple technologies by a single device brings the challenge of uninterrupted communication while moving between heterogeneous networks. It is now very common in public places to have WiFi connectivity which offers higher speeds than cellular oriented technologies. It would be desirable for the mobile phone to exploit this in a seamless manner. Even considering cellular technologies only, depending on coverage by mobile operators, the user will be able to experience different access technologies. Considering the case where the user is traveling on a train and watching videos streams, even if from a service like YouTube, the change of access technology will most likely cause service failures if the application or protocol cannot cope with this.

A solution to the above problem, making mobility completely transparent to applications and protocols above IP, is the support for mobility by the IP protocol. However, IP was not developed with mobility in mind and because of how IP addressing and routing works, it is not trivial to change it to support mobility. An IP address is divided in two parts: a network prefix and a host identifier. The network prefix identifies the network where the host is attached. This is also the only part of the address that routers use to forward packets to other routers in order to reach its final destination. The host identifier part is used to make an host IP address unique between all the other hosts on the same network. The whole IP address is thus required to identify the host within a network. It was expected that most devices stay on the same network, thus the tight integration of the network in the IP addressing for simplicity and efficiency of the protocol. From this basic description of how IP routing works, it can be seen that when a mobile node moves between networks, its IP address must change simply because a portion of the address is tied to the network, and thus it would not be possible to keep it. The change of IP address has the immediate consequence that other nodes will no longer be able to reach the mobile node, and thus the mobile node would become unreachable. To enable IP mobility, a mobile node needs to move from one network to another without changing its IP address perception by other nodes. This way a mobile node can continue to communicate with other nodes without interruption. The Internet routing mechanisms will simply deliver packets destined to a mobile node to the network that matches the mobile node’s IP address. Thus to solve this problem, extensions to the IP protocol were developed to cope with this without requiring changes to the IP routing mechanism.

1.2 Mobility Protocols

Several protocols have been developed to address these IP mobility challenge. These pro-tocols were developed by the IETF and can be categorized into global mobility management and local mobility management protocols. There are other protocols that address IP mobility, such as the case of the GPRS tunneling protocol [1]. However, not all wireless networks are cellular networks: Wireless Local Area Networks (WLANs) networks are very common and used in public and private buildings.

Due to the increasing number of heterogeneous technologies, a protocol was developed by the Institute of Electrical and Electronics Engineers (IEEE) to support media

(24)

indepen-dent handover [16]. This presents potential solutions for mobility support in a technology agnostic manner, and also to address seamless handovers between different or even the same technologies.

Global Mobility Management Protocols

The first approaches to solve the Internet Protocol version 6 (IPv6) mobility challenge involved the mobile node and a router entity on the mobile node’s home network, know as the Home Agent (HA). The mobile node does the mobility management by registering its current location with its HA when in a foreign network. A bi-directional tunnel between the mobile node and the home agent routes the mobile node traffic from and to its home network, thus allowing it maintain its home address, independently of its current location. The main advantage is that it can work across any network operated by other providers other than the one supplying the mobility service, as long as the mobile node can reach the required entities. The main disadvantages are the higher complexity, security issues, overhead and also the required modifications imposed on the IP network stack to support the protocol. The very first protocol to be developed was the Mobile IPv4 (MIPv4) [17][18][19]. However, MIPv4 has not been deployed widely as expected and has several shortcomings, including the inherent limited number of IP addresses, a key problem because of the fast growing number of mobile devices. To overcome the issues of MIPv4, research and development on Mobile IP shifted to IPv6 which does not lack IP addresses and has a number of facilitation mechanisms such as statefull and stateless address auto-configuration. Plus, based on the experience with MIPv4 and the features provided by IPv6, the Mobile IPv6 (MIPv6) protocol [20] was designed with less complexity and is more integrated into the IPv6 protocol. Even so, for delay sensitive applications, MIPv6 was not suitable enough, therefore an extended MIPv6 protocol, the Fast Mobile IPv6 (FMIPv6) [21][22][23] was developed to address handover latency issues.

Local Mobility Management Protocols

Another approach to solve the IPv6 mobility challenge resorts to network-based mobility. A new entity in the access network handles the registration with the HA and correspondent nodes on behalf of the mobile node, with the aim of improving handover latency. The main advantage is the proximity of the local entity that assists or provides mobility handover procedures, which can make a significant difference due to the latency of wired vs wireless access technologies. The main disadvantage is that it only works on networks within the same domain and/or provider. The Hierarchical Mobile IPv6 (HMIPv6) [24] was the first protocol to support local mobility management, but it retains many of the MIPv6 and FMIPv6 features and functionality thus it can fallback to one those. Another protocol was latter developed that broke away with the compatibility with the previous protocols, the PMIPv6 [25] which performs exclusively network based mobility. It is completely transparent to the mobile node, which has the main advantage of not requiring changes to the mobile node’s IP network stack, and it is an order of magnitude much simpler that the previous protocols. Because this protocol relies on the network side, particularly in the access technology, to detect the mobile node movement, it was left out of the PMIPv6 standard how this is done, allowing more freedom to exploit and evolve new ways of performing a handovers.

(25)

Media Independent Handover Protocol

The IEEE 802.21 standard [16] released in 2009 provides support for seamless handover in heterogeneous network environments, but also within the same network. Its main purpose is to facilitate handover management in a media independent way through high level interfaces that abstract the underlying technologies. It also provides mechanisms for detecting or querying for existing networks, select and allocate resources on networks to connect to. Because of the mechanisms provided by IEEE 802.21, it is highly relevant for tackling the seamless handover challenges in heterogeneous networks. Thus in this thesis a solution is presented that uses the IEEE 802.21 standard as the basis for the mobile node detection mechanism in the mobility implementation, for technology agnostic support and seamless handover in the detection mechanism.

1.3 Open Proxy Mobile IPv6

Global mobility protocols allow a mobile node to be reach any network domain as long it can reach its Home Agent (HA). However, this approach has some disadvantages [26]:

• The update latency is higher, because of the distance from the mobile node’s HA and the latency of wireless networks compared to wired ones.

• The signaling overhead on a wireless network negatively impacts the handover perfor-mance and also a mobile node’s energy consumption.

• Security issues with privacy exist, since the mobile node exposes it’s location.

• Changes are required to the IP stack in the mobile nodes, which have been already deployed and made interoperable.

The NETLMM working group of the IETF defined a set of goals [27] to address the issues with global mobility protocols, the most relevant ones being:

• Improved handover latency. • Reduced handover signaling. • Location privacy.

• Simplified mobility management security. • Link layer technology agnostic.

• Support unmodified mobile node’s IP stack.

• Support Internet Protocol version 4 (IPv4) and IPv6.

The outcome of these goals was the PMIPv6 protocol [25]. These protocol goals make this protocol the logical candidate for this thesis. The first four goals provide a protocol with improved performance and reduced complexity, a motivation for today’s popularity of mobile terminals. The fifth goal makes the case for media independent and seamless handover, a

(26)

motivation for today’s highly heterogeneous networks. The last goals provide the motivation to deployment with much less to none interoperability issues.

With these goals and opportunities provided in mind, this thesis presents an implemen-tation, that uses the PMIPv6 protocol, known as the OPMIP. Further, previous work [28] as shown that FMIPv6 can perform better than PMIPv6 in predictive mode, with different access technologies. Others [29] have analyzed and proposed a FMIPv6 like solution, the Fast Proxy Mobile IPv6 (FPMIPv6), to improve the PMIPv6 handover performance. In this thesis, an integration scenario with the IEEE 802.21 protocol is presented which provides a so-lution [30] to support seamless handover, thus eliminating the Link Layer (L2) handover from the equation. This same solution also provides a technology agnostic movement detection mechanism.

1.4 Contributions

The following contributions were made in this thesis:

• An implementation of localized mobility management base on PMIPv6, known as Open Proxy Mobile IP (OPMIP). This implementation provides the functional entities Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) of the PMIPv6 standard. The MAG entity has a modular driver architecture and supports several drivers for movement detection. This implementation provides drivers for IEEE 802.11 and IEEE 802.21.

• An integration with an open source IEEE 802.21 implementation, the ODTONE frame-work [31], which is used by the IEEE 802.21 MAG driver.

• A paper ”Using an Open-Source IEEE 802.21 Implementation for Network Based Lo-calized Mobility Management”, accepted for publication on the IEEE Communications Magazine in September, 2011 [30].

1.5 Document Outline

The remainder of this document is organized as follows. Chapter 2 introduces the reader to the state of art on Mobile IP protocols. A summary is provided on global and local mobility management protocols. Since this work is based on PMIPv6 and most protocols derive from MIPv6, emphasis is put on MIPv6 and PMIPv6. MIPv4 is briefly compared with MIPv6, since MIPv6 is very similar to MIPv4. An integration scenario with IEEE 802.21 is also presented in this section. Chapter 3 describes the OPMIP, an implementation of the PMIPv6 protocol and its integration with ODTONE [31], an IEEE 802.21 open source implementation. Chapter 4 presents an analysis of the implementation with several measurements of the implementation performance. In chapter 5 a summary of the work is presented with final considerations and future work.

(27)

Chapter 2

Mobility Management

Mobility management consists of location and handoff management [32]. Location man-agement tracks the location of mobile nodes. When a mobile node changes its point of access, the mobile node (or an entity in the point of access) must register the new location with the network. After the update, services are delivered at the new location. The challenge with location update is to keep the signalling overhead and latency at a minimum for service delivery. Handoff management consists in moving from an access point to another, in order to keep the connection alive. Handoffs can be horizontal or vertical. A horizontal handoff is a handoff between homogeneous networks, while a vertical handoff is a handoff between hetero-geneous networks. The challenge with handoffs is to keep the signaling and power overhead at a minimum, to avoid traffic disruption (e.g., packet loss and latency), and to use network resources efficiently.

Solutions for mobility management are available at different layers: L2, Network Layer (L3) or a combination of both. L2 solutions are dependent on specific link technologies, on heterogeneous networks such solutions have limited scope. Since supporting heterogeneous networks is an important requirement, L2 only solutions are not discussed in this thesis. L3 solutions can be classified into global or local mobility management. These solutions work at the IP layer, and are not limited to specific link layer technologies. A combination of both solutions refers to the assistance of link technologies to optimize handoffs in L3 solutions. By obtaining movement detection or signal strength from the link technology, or coordinate an handoff between different technologies (using media independent mechanisms), the system can optimize L3 handoffs with the purpose of eliminating packet loss and handover latency.

Global mobility management solutions apply to the movement between different domain-s/providers, or different access technologies infrastructures which are not interoperable (such as the movement from a 3G network to a WLAN network). In global mobility solutions the mobile node is responsible for movement detection and updating its location with the network. Some combined solutions use L2 information to assist in movement detection. To route the traffic, a tunnel is established between an entity in the domain and the mobile node. Some solutions may also use optimized routing mechanism for direct communication with corre-spondent nodes, but such solutions require support from correcorre-spondent nodes. MIPv6 is a global mobility management protocol, as long as the mobile node can reach the entity in its home network (independently of the access network domain/provider) the protocol will be able to perform mobility management at a global scale. The FMIPv6 protocol is an example

(28)

of an extension to MIPv6, aiming to improve the handover performance of MIPv6.

Local mobility management solutions apply to movement within the same domain/provider, and it can also apply to different access technologies within the same domain. In local mo-bility management solutions, an entity in the point of access assists, or provides, movement detection and location update on behalf of the mobile node. Traffic is tunnelled between the entity in the point of access and a fixed entity in the domain, and then tunnelled or routed between the entity in point of access and the mobile node. HMIPv6 is a local mobility man-agement protocol extension to MIPv6 and FMIPv6. HMIPv6 still requires the mobile node to perform some of the movement detection and location updating. However, the signaling is significantly reduced since the entity in the point of access will perform location updating with other entities on behalf of the mobile node. PMIPv6 is a local mobility management solution which is transparent to mobile nodes. The entity on the point of access will perform movement detection and signaling on behalf of the mobile node. The movement detection in the PMIPv6 standard is implementation specific, thus implementations are free to exper-iment and come up with new different ways of performing movement detection. In a similar fashion to FMIPv6, the FPMIPv6 protocol is an extension to PMIPv6 with the aim of im-proving handoff performance (eliminate packet loss during a handover procedure). However, alternative solutions, which don’t require extensions to the PMIPv6 standard, can use media independent handover based solutions to support seamless handovers in both homogeneous and heterogeneous networks.

Media independent handover is, perhaps, the most prominent combined L2 and L3 solu-tion. With the release of the IEEE 802.21 [16], the possibilities of scenarios evolving network or mobile node initiated handovers is endless due to the flexibility provided by the standard. Since the movement detection in PMIPv6 is implementation specific, an IEEE 802.21 solu-tion to this could provide a media independent movement detecsolu-tion mechanism and seamless handover support. Different scenarios can be easily supported by such solution.

2.1 Mobile IPv6

The Mobile IPv6 (MIPv6) protocol enables the movement of the mobile node, away from its home link. The mobile node is always identified with its home address, independent of its current location, thus maintaining transport and higher layer communications every time it moves to a new location. On a foreign network, the mobile node acquires an address using conventional mechanisms, such as stateless or stateful auto-configuration. This address is known as the care-of address. To be reachable by its home address, the mobile node traffic must be routed between the mobile node’s current location and its home network.

(29)

Figure 2.1: Mobile node communication with a correspondent node while on a foreign network

Figure 2.1 illustrates mobile node traffic routing when on foreign network, the traffic between the mobile node and the correspondent node is illustrated by a dashed red line. A tunnel, illustrated by the fat green line, is established between the mobile node’s care-of address and an entity, the HA, in its home network to re-route the traffic to the mobile node that reaches its home network. The mobile node must maintain an association between its current care-of address and its home address with its HA. This association is known as a binding. Thus, a mobile node can communicate in the following manners:

• If the mobile node is located on its home network no MIPv6 processing is required, since the packets are naturally routed to the mobile node. In this case, the mobile node has no binding with its HA.

• While the mobile node is on a foreign network, the mobile node keeps its current care-of address updated with its HA. In this case, the HA will receive the packets on behalf of the mobile node, the HA will then tunnel them to the mobile node care-of address. In a similar fashion, the mobile node will tunnel packets from its home address to its HA. Then the HA will send them on behalf of the mobile node. This is known as Reverse Tunnelling.

The modes of communication described above allow for the communication of mobile nodes with any correspondent node, even if they are not MIPv6 aware. However, MIPv6 provides another communication mode between a mobile node and a correspondent node, that provides route optimization. In this mode, if a correspondent node is MIPv6 aware, the mobile node can also establish a binding with the correspondent node, thus bypassing the HA for traffic between the mobile node and correspondent node. In this case a tunnel is not used, but instead a extension header is added to IPv6 packets, that identifies the mobile node’s home address associated with the traffic.

(30)

2.1.1 Protocol Messages

MIPv6 introduces new protocol messages and extensions to the IPv6 protocol. These are: • A new IPv6 protocol, using the mobility header, for creating and managing bindings

between a mobile node and HAs and correspondent nodes.

• A home address option, for traffic routing from a mobile node to correspondent node. • A new variant of the routing header, the type 2 routing header, for traffic routing from

a correspondent node to mobile node.

• New Internet Control Message Protocol (ICMP) messages for HA discovery and address configuration.

• Extensions to the ICMP Neighbour Discovery messages.

Since the focus of the thesis is on the PMIPv6, a very brief explanation is given of the protocol messages defined by MIPv6, with the exception of protocol messages which are reused by PMIPv6.

2.1.1.1 Mobility Protocol

The mobility header is an extension header similar in many ways to the ICMP header. It is a common header for several messages, identified by field type in the header. The header is followed by the specific message fields and finally, depending on message type, followed by option fields. However, its used specifically for mobility management proposes in this case binding management. Figure 2.2 depicts the mobility header format:

3 0 2 0 1 0 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Message Data Checksum

Payload Proto Header Length MH Type Reserved

Figure 2.2: Mobility Header Format

The mobility header messages introduced by MIPv6 are: • Binding Refresh Request Message

This message is sent by correspondent nodes to request a mobile node to update its mobility binding. This message uses a MH Type value of 0.

(31)

• Home Test Init Message

This message is used by a mobile node to initiate the return routability procedure and request a home keygen token from a correspondent node. This message uses a MH Type value of 1.

• Care-of Test Init Message

This message is used by a mobile node to initiate the return routability procedure and request a care-of keygen token from a correspondent node. This message uses a MH Type value of 2.

• Home Test Message

This message is the response to Home Test Init message. This message uses a MH Type value of 3.

• Care-of Test Message

This message is the response to Care-of Test Init message. This message uses a MH Type value of 4.

• Binding Update Message

This message is used by the mobile node to update its care-of address with other nodes. This message uses a MH Type value of 5. The format after the mobility header is:

Reserved A H L K Lifetime Sequence # Mobility Options 3 0 2 0 1 0 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1

Figure 2.3: Binding Update Message Format • Binding Acknowledgement Message

This message is used by a node to acknowledge a Binding Update (BU) from a mobile node. This message uses a MH Type value of 6. The format after the mobility header is: K 3 0 2 0 1 0 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Sequence # Status Reserved Lifetime Mobility Options

(32)

• Binding Error Message

This message is used to indicate an error related to mobility management when the Binding Acknowledge (BA) message is not appropriate. This message uses a MH Type value of 7.

The messages can carry mobility options. The mobility options uses a Type-Length-Value (TLV) format, see figure 2.5. The Type field indicates the type of mobility option and the Length field indicates the length in octets of the Data field. When processing a mobility option which is not recognized, it must be ignored.

3 0 2 0 1 0 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 Data... Type Length

Figure 2.5: Mobility Options Generic Format

MIPv6 specifies the following mobility options: • Pad

This option is used to insert padding for alignment purposes. The Type value is 0 and it has neither a Length or Data fields, this is a special case.

• PadN

This option is used to insert padding for alignment purposes. The Type value is 1, the Length field indicates an additional zero or more octets of padding in the Data field. • Binding Refresh Advice

This option is used only on the BA message sent from the mobile node’s HA. It indicates the time until the mobile node should send a new registration.

• Alternate Care-of Address

This option is used only on the BU message sent from the mobile node. It indicates an alternative care-of address for situations where it cannot use the source address. • Nonce Indices

This option is used only on the BU message sent from the mobile node to a correspondent node, and only together with a Binding Authorization Data option. It indicates to the correspondent node which nonce value to use when producing a home or care-of keygen token.

• Binding Authorization Data

This option is used in BU and BA messages. It contains a cryptographic value used to determine the authenticity of the message. This message is mandatory for the BUs and BAs messages exchanged with a correspondent node.

(33)

2.1.1.2 Home Address Option

This option uses the same TLV format of the equivalent mobility option. It contains the source home address of the mobile node. It is used by a mobile node to route traffic directly to a correspondent node. It’s carried on a IPv6 packet as an extension header.

2.1.1.3 Type 2 Routing Header

This extension header is used by a correspondent node to route traffic directly to a mobile node care-of address. This extension header contains the mobile node’s home address, while the IPv6 destination address contains the mobile node’s care-of address.

The type 2 routing header is a variant of the IPv6 type 1 routing header extension [33]. The format is the same as the type 1 routing header, but with a type value of 2 and a segments left value of 1. The first and only address in the type specific data is the home address of the destination mobile node.

2.1.1.4 New ICMP Messages

MIPv6 defines two new ICMP messages for HA discovery and two new ICMP messages for address configuration:

• Home Agent Discovery Request

This message is used by the mobile node to discover the HA on its home network. The mobile node sends this message to its home network anycast address for HAs [34]. • Home Agent Discovery Reply

This message is used by a HA in reply to HA discovery request. It contains a list of HA addresses.

• Mobile Prefix Solicitation

This message is used by the mobile node to request a mobile prefix advertisement from its HA.

• Mobile Prefix Advertisement

This message is used by a HA to give prefix information about the home network when the mobile node is away.

2.1.1.5 ICMP Neighbour Discovery Extensions

MIPv6 introduces extensions to the ICMP Router Advertisement [35] message:

• A new flag is introduced that indicates if the router sending the Router Advertisement is a HA.

• A new flag is introduced to the prefix option that indicates that the prefix field contains a HA global address instead of a network prefix.

(34)

• A new Advertisement Interval option that indicates the time interval between unsolicited router advertisements. A mobile node uses this information for its movement detection algorithm.

• A new Home Agent Information option that gives information about the HA preference and lifetime.

2.1.2 Security

The protection and authenticity of the mobile node signaling with the HA must be done using IPSec security [36]. For the encapsulated traffic between the mobile node and its HA, it’s optional but recommended to used Encapsulating Security Payload (ESP) [37]. Internet Key Exchange (IKE) [38] may also be used for the automatic management of keys.

The protection and authenticity of the mobile node signaling with cthe orrespondent nodes does not use a pre-established or management system for security associations. The MIPv6 specifies a procedure, the return routability procedure, to establish security associations with correspondent nodes.

The return routability procedure allows a correspondent node to check if packets to a mobile node can reach the mobile node at the supplied care-of address. During the procedure, a security association is established, i.e., a key is negotiated which will then be used to authenticate messages. Only after this procedure can a correspondent node accept bindings from the mobile node.

2.1.3 Tunneling and Forwarding

A bidirectional tunnel must be used to route the traffic between the mobile node and its HA. Mobility is achieved because the HA receives and sends the mobile node’s traffic at the home network, the bidirectional tunnel allows the traffic to reach the mobile node and for the mobile node to send it without concern with ingress filtering [39]. The tunnel must use IPv6-in-IPv6 encapsulation [40] and the endpoints must be the HA global address and the mobile node’s registered care-of address.

To receive packets destined to the mobile node, the HA must fake the presence of the mobile node in the network. This is done by multicasting Neighbour Advertisement messages and replying to Neighbor Solicitation messages [41] on behalf of the mobile node. The HA must forward the traffic, received on behalf of the mobile node, to the respective bidirectional tunnel and the traffic coming from the same bidirectional tunnel must be forward to the home network.

2.1.4 Mobile Node

The mobile node is responsible for doing movement detection and keep correspondent nodes, if the correspondent node supports route optimization, and its HA updated with its current location. MIPv6 defines a conceptual data structure, the Binding Update List, for managing the mobile node’s binding associations.

(35)

Field Description

node address The address of the node to which the BU was sent. home address The mobile node’s home address for which the BU was

sent.

lifetime The lifetime of the BU. When the lifetime is reached, the entry must be deleted.

sequence number The maximum sequence number sent on the previous sequence update

last BU time The time at which the last BU was sent. It’s used to limit the send rate.

state The state of the BU. This manages the retransmission, if needed, of BU.

future flag A flag that specifies if future BUs should be sent. This flag is set when a ICMP Parameter Problem error mes-sage is received.

Table 2.1: Binding Update List entry

Table 2.1 depicts the fields contained on a Binding Update List entry. MIPv6 defines additional fields, which address security for bindings with correspondent nodes. These fields contain the binding management key, used for hash authentication. This key is established in the return routability procedure. This is accomplished with the aid of node keys, nonces, cookies, tokens and cryptographic procedures. The BU list entry must also store the aid data for establishing the binding management key.

Besides being used to manage BUs, the Binding Update List is also used to determined how packets are sent to a correspondent node, i.e., either directly to a correspondent node or via the HA.

Movement Detection

A mobile node can detect movement in several ways:

• neighbour unreachability detection [35], where the default router is no longer reachable when sending packets

• router advertisements [35], information can be used to detect changes which can con-stitute a L3 handover

• L2 handover: some technologies provides means to detect movement at the link layer A mobile node must consider that the above mechanisms may or may not imply an L3 handover. Thus a mobile node, upon detecting a L3 handover, must verify if the default router is still reachable unless is certain.

Upon detecting a L3 handover on a foreign network the mobile node acquires an address, using stateful or stateless address auto-configuration, which will be its care-of address. A mo-bile node can have multiple care-of addresses, which can happen when transitioning between networks if the technology allows multiple connections and/or with different technologies.

(36)

However, the mobile node can only have one primary care-of address, which is the one regis-tered with its HA. Having multiple care-of addresses enables the mobile node to make a more smooth transition to a new care-of address since it can delay the disassociation of the old care of address until a new one is ready, the mobile node should also accept packets address to its previous care-of address to further assist with a smooth transition.

If a mobile node detects that it’s connected to its home network, then it must send a de-registration BU to its HA. This informs the HA to no longer intercept packets on behalf of the mobile node. The mobile node cannot use its home address until the de-registration process is completed, since its HA is intercepting packets on the mobile nodes behalf. After the de-registration process is completed, the mobile node must multicast a Neighbour Advertisement [35] to advertise its link layer address for its home address.

Bindings with the Home Agent

A mobile node sends a BU to its HA when: • it decides to change its primary care-of address.

• it needs to extend the registration lifetime of its current care-of address, before it expires. • it needs to de-register its binding.

When sending a BU, the mobile node must create or update the corresponding Binding Update List entry and construct the BU message in the following way:

• the Home Registration and Acknowledge flags must be set.

• the sequence number must be set from the value of the last sent BU, after being incre-mented.

• for registrations the lifetime must be set to value greater than zero and should be less or equal to the lifetime of the home address and the care-of address.

• for de-registrations the lifetime must be set to zero.

• the care-of address must be used as the source address for the packet, otherwise is must be included in a Alternate Care-of Address mobility option.

• the packet must contain a Home Address Destination option, which gives the home address for the binding

The mobile node must retransmit the BU until it receives a matching BA. If the mobile node has more than one HA, it can try the next HA when it reaches the maximum binding timeout period.

Upon receiving a matching BA:

• if the status is 0, the BU was successful.

• if the status is set to 1 (accepted but prefix discovery necessary), the mobile must perform a mobile prefix discovery and then try to register again.

(37)

• if the status is set to 135, the last valid accepted sequence number is the one from BA, the mobile node must register again with a valid sequence number.

• if the status is an error other than 135, then the mobile node must update the Binding Update List entry to indicate that future BU, should not be sent (see Table 2.1).

Bindings with a Correspondent Node

When a mobile node completes a BU registration (or de-registration) procedure with its HA, the mobile node should initiate a BU registration or (de-registration) procedure with each correspondent node. Prior to sending the BU, the mobile node must perform a return routability procedure [20]. After completing this procedure successfully, the mobile node may send a BU to a correspondent node.

The procedure for sending BUs to a correspondent node is the same as the one for a HA, but with the following differences:

• The Home Registration flag is not set.

• The Acknowledge flag is optional, but if not set the mobile node will not receive a BA. • If the BU is a de-registration, the care-of address must be the mobile node’s home

address.

Binding Acknowledgements

When a mobile node receives a BA it must match a sent BU or it must ignore the BA. A BA matches a BU if:

• the packet is well formed and meets the authentication requirements. • the source address matches the destination of the BU.

• the sequence number field matches the BU one.

For registrations, if the lifetime field on the BA is less than the one sent on the BU, then the remaining lifetime for the BU on the Binding Update List entry must be subtracted from the sent lifetime minus the acknowledged lifetime.

Binding Refresh Requests

When a mobile node receives a Binding Refresh Request message and has a Binding Update List entry for it, then the mobile node should update the binding lifetime if it’s interested in maintaining the binding.

(38)

Field Description

home address The home address of the mobile node to which the entry belongs.

care-of address The care-of address of the mobile node for which the binding was registered.

lifetime The lifetime of the biding. When the lifetime is reached, the entry must be deleted.

sequence number The maximum sequence number of last received BU. last BU time The time at which the last BU was sent. It’s used to

limit the send rate.

home registration flag Indicates if the entry is a home registration entry. Ap-plies only to nodes that support the HA functionality. usage The usage state of the entry for cache replacement

policy decisions.

Table 2.2: Binding Cache entry

2.1.5 Correspondent Node

A correspondent node, with route optimization support, can accept bindings from a mobile node. MIPv6 defines a conceptual data structure, the Binding Cache, for managing BUs from mobile nodes, see table 2.2.

When sending packets, the correspondent node must search the Binding Cache, before searching the Neighbour Discovery conceptual Destination Cache [35] to determined the des-tination. If a valid entry is found, the correspondent node should send the packet to the care-of address of the destination node with a Type 2 routing header with the home address of the destination node. The correspondent node should not do this for link-local packets.

When receiving a packet with a Home Address Destination option header, the correspon-dent node must check if it has a Binding Cache entry for the given home address. If not, or if the care-of address does not match the source address, the packet must be dropped and a Binding Error message must be sent. When sending a Binding Error message, the home ad-dress field is set to the value of the Home Adad-dress Destination option header of the offending packet or zeroed if unknown.

Binding Updates and Acknowledges

When a correspondent node receives a BU from a mobile node, it must create, update or delete the corresponding Binding Cache entry. The correspondent node then sends a BA in response to a BU, if the BU has the acknowledged flag set. The BA must be sent with a Type 2 routing header, unless the source address of the BU is the same as the mobile node’s home address, and with a Binding Authorization Data mobility option, unless the Home Nonce Index and/or Care-of Nonce Index are invalid. The status field is set to a value that either indicates that the binding was accepted or the reason for being rejected. The reasons for rejection can be:

(39)

This only happens if a Binding Cache entry already exists and the sequence numbers don’t match. The BA sequence number field must be set to the last accepted one. • Invalid Home Nonce Index and/or Care-of Nonce Index.

• Mismatch between the Home Registration flag in the BU and the Binding Cache entry. Applies only to correspondent nodes with HA functionality.

For other rejection cases, the BU is ignored and no BA is sent.

Binding Refresh Request

If a Binding Cache entry is about to expire but it’s actively being used, the correspondent node may request the mobile node to update the binding by sending it a Binding Refresh request message.

Cache Replacement Policy

A correspondent node can have limited resources. Thus it can employ a cache replacement strategy, such as a Least Recently Used (LRU), to maintain a limited amount of entries in its Binding Cache in a reasonable manner.

2.1.6 Home Agent

The HA uses the same conceptual Binding Cache as the correspondent nodes (see table 2.2) that records the binding state information with each mobile node that is serving. Each HA also maintains a list of other HAs which is determined from Router Advertisements serving on the same home network, used for the dynamic home agent discovery mechanism.

When the HA has a binding with a mobile node, is must intercept packets destined to the mobile node. To achieve this, the HA must multicast onto the home link a Neighbour Advertisement message on behalf of the mobile node. This message advertises the HA link-layer address for the mobile node IP address. Thus packets destined to the mobile node will be sent to the HA. The HA must also reply in the same manner to Neighbour Solicitations on behalf of the mobile node.

The packets intercepted by the HA on behalf of mobile node must then be tunneled to the care-of address of the mobile node, using a bi-directional tunnel. The HA will also receive on this tunnel packets from the mobile node, that it must then send through the home link on behalf of the mobile node.

Binding Updates and Acknowledges

When the HA receives a BU from a mobile node it must create, update or delete the cor-responding Binding Cache entry. This Binding Cache entries are marked as home registration entries and are not subject to cache replacement policy (see Table 2.2). The HA node must send a BA in response to a BU. The status field is set to value that either indicates that the binding was accepted or the reason for being rejected, reasons for rejection can be:

(40)

• Invalid sequence number:

This only happens if a Binding Cache entry already exists and the sequence numbers don’t match. The BA sequence number field must be set to the last accepted one. • The HA functionality is not supported, i.e., the node only supports correspondent node

operation.

• The home address option does not match with the home network prefix. • Insufficient resources.

For other rejection cases, the BU is simply ignored and no BA is sent.

Dynamic Home Agent Discovery

Each HA on a home network keeps a list of other HAs that it learns from the issued periodic router advertisements. The HA must keeps the list updated by adding and removing the entries according to the information obtained from the Router Advertisements.

When a mobile node sends a ICMP Home Agent Address Discovery Request message, the serving HA must reply with ICMP Home Agent Address Discovery Reply message with the list off HAs that it knows about.

Prefix Advertisement

The HA must send a ICMP Mobile Node Prefix Advertisement when the prefix informa-tion changes or when it receives a ICMP Mobile Node Prefix Request from a mobile node.

2.2 Mobile IPv4

The Mobile IPv4 (MIPv4) protocol is the predecessor of the MIPv6 protocol. MIPv6 shares many features and similarities with MIPv4. This section provides a brief summary of the main differences between the MIPv4 and the MIPv6 protocols.

MIPv6 takes advantage of the features provided by the IPv6 that the IPv4 does not provide. It also benefited from the experience gained from the development of MIPv4. These are the main differences:

• MIPv6 uses IPv6 Neighbour Discovery, which is independent of the link layer technology. MIPv4 depends on link layer specific neighbour discovery mechanisms such as ARP [42]. • MIPv6 uses the IPv6 extension header facility for its mobility management protocol, while the MIPv4 uses User Datagram Protocol (UDP) for this. MIPv6 also uses a routing header for route optimization, while MIPv4 must use IP encapsulation. Thus, the resulting overhead is much lower for MIPv6 then to MIPv4.

• MIPv4 requires a specific router on foreign networks, the Foreign Agent (FA), to detect the mobile node attachment.

(41)

• Support for route optimization is an optional extension on MIPv4.

• The Dynamic Home Agent Discovery in MIPv6 returns a single reply to the mobile node, on MIPv4 separate replies from each HA are sent to the mobile node.

• MIPv4 allows triangular routing, which is incompatible with ingress filtering [18], how-ever the standard was updated [19] to support rhow-everse tunneling to handle ingress fil-tering.

2.3 Fast Mobile IPv6

The FMIPv6 [23] protocol was introduced to address handover latency issues of MIPv6. To solve this issue, the FMIPv6 protocol introduces new extensions to the mobile node and access routers to assist in the handover process.

A mobile node may connect to a new access point, while maintaining is connection to the old access point, when it has more than one interface. At the new access point it gathers information about the new access router (for example, from router advertisements). The same can be accomplished through link layer specific mechanisms. The mobile node then sends a Router Solicitation Proxy message to its old access router indicating that it wishes to make a fast handover to the new access point, providing the information about the new access point. The old access router replies indicating, if the new access router supports fast handover. If so, a new care-of address and prefix information is provided in the reply. The mobile node then performs a fast handover, using the new care-of address with the old access router. The old access router sends an indication to the new access router and after getting a reply it indicates to the mobile node that the handover is completed. During the signaling, between the old and new access routers, a tunnel is created between them to smooth the handover. This tunnel will be used to forward the traffic to/from the new access point, until the mobile node finishes registering with its HA and correspondent nodes. At the new access point, the mobile node expects the new access router to receive traffic redirected from the old access point until the registrations for the new location are completed.

Protocol Extensions

Two new Internet Control Message Protocol version 6 (ICMPv6) messages are introduced, termed Router Solicitation for Proxy Advertisement and Proxy Router Advertisement. The Proxy Router Solicitation for Proxy Advertisement message is used by the mobile node to indicate its intention to perform a fast handover. The Proxy Router Advertisement is the reply message sent by the access router, but if the handover is network initiated, it’s sent gratuitously. A new option is introduced for the Proxy Router Advertisement which is the IPv6 address/prefix option.

Two new mobility protocol messages are introduced, termed Handoff Indication (HI) and Handoff Acknowledge (HAck). The HI is used by the old access router to indicated to a new access router about the mobile node’s handover intention. The HAck is used by the new access router as the reply to the HI. New options are also introduced for these messages which are the IPv6 address/prefix option, equivalent to the Proxy Router Advertisement, and the link-layer address, with an indication of what link layer address it refers to.

(42)

Finally, two new options are introduced to the BU and BA messages, these messages are designated by the FMIPv6 as Fast Binding Update/Acknowledged, these options are the link-layer address and binding authorization data which are already defined by PMIPv6.

Advantages and Disadvantages

The main advantage of FMIPv6 is that it provides a mechanism for a more smooth handover experience by re-routing traffic between the old access router and the new one until the handover is complete. However, it adds more complexity to an already complex protocol and requires extended modifications to a mobile node’s IP stack.

2.4 Hierarchical Mobile IPv6

The Hierarchical Mobile IPv6 (HMIPv6) [24] protocol was the first to introduce [43], prior to PMIPv6, network based mobility management. It is an extension of MIPv6 which introduces a new entity, the Mobility Anchor Point (MAP), to address the handover latency issues of MIPv6. HMIPv6 can be seen mostly as an extension of the MIPv6 protocol: a mobile node is free to choose one or the other, thus allowing it to operate in local or global mobility management scenarios.

To smooth a handover, the mobile node updates its current location with the new MAP entity. This entity is located on the access network, and it will handle the signaling with the HA (located in its home network) and correspondent nodes on behalf of the mobile node. Thus, only one binding message has to be sent to the MAP, instead of having to send bindings to the HA and each correspondent node. Additionally, as the traffic will be tunneled between the mobile node and the MAP, the MAP effectively acts on behalf of the mobile node towards the other entities. Considering that typically a mobile node will use a wireless access technology, which has greater latency and less bandwidth than a wired technology, the nearby MAP can provide a significant improvement in mobility handover performance. Also, a MAP does no require a permanent HA and home address for the mobile node as it can learn about them through the MAP entity in the access network.

Protocol Extensions

A mobile node learns about MAPs through Router Advertisements and Neighbour Dis-covery [35]. The MAP option [24] is introduced for this purpose in these messages. A new flag, the M flag, is introduced to the MIPv6 BU message to indicate that a message is a local binding update, which is the message that a mobile node must send to the MAP to update its current location. HMIPv6 requires changes to the mobile node operation and the new MAP entity, whereas all the other entities defined by MIPv6 are left unchanged.

Advantages and Disadvantages

The major advantage of HMIPv6 is the significant reduction of the mobile node partici-pation in the signaling with the introduction of the MAP entity. The lack of a MAP entity is not a problem for the HMIPv6 since a mobile node can simply fallback to MIPv6. In terms

(43)

of security the mobile node gains more privacy in relation to the correspondent nodes and HA. The remaining disadvantages are mostly the same as in the MIPv6 protocol with the complexity of the protocol and the required extended modification to the mobile node’s IP stack.

2.5 Proxy Mobile IPv6

The Proxy Mobile IPv6 (PMIPv6) protocol [25] is an extension of the MIPv6 protocol that provides network-based mobility. A new functional entity, the MAG, is introduced as the proxy mobility agent. The home agent entity is conceptually and functionally extended by a new entity, the LMA. The MAG resides on the access link where the mobile node can attach to. It’s responsible for detecting the mobile node movement to and from the access link and register its binding with the mobile node’s LMA.

As the mobile node moves and changes its point of attachment from one MAG to the other within a PMIPv6 domain, it will continually use the same address(es). The MAG will always advertise the same network prefix(es) and the mobile node’s LMA will stay the same, has long as the mobility session is alive. When a mobile node attached to a PMIPv6 domain without having a previous session, a new one is established. In a new session, new network prefixes and a new LMA can be assigned to the mobile node. A PMIPv6 domain can also have multiple LMAs, each serving a group of mobile nodes.

Mobile Node MAG 1 MAG 2 LMA

Attach MAG 1 PBU Registration PBA Registration Router Advertisement

Attach MAG 2 PBU

De-Registration PBA De-Registration PBU Registration PBA Registration Router Advertisement

Figure 2.6: PMIPv6 Signaling

Figure 2.6 illustrates the PMIPv6 signaling, where a mobile node attaches to an access point (MAG 1) and then moves to another access point (MAG 2). When a mobile attaches to an access point on a PMIPv6 domain, the MAG in that access point must identify the mobile node and determine the mobile node’s authorization and parameters, from the mobile node’s policy profile database. If it’s authorized, the MAG will send a Proxy Binding Update (PBU) registration message to the mobile node’s LMA. The LMA receives the PBU and also

(44)

determines the mobile node’s authorization and parameters. If accepted, it will setup the endpoint for the bidirectional tunnel to the MAG, the forwarding of the mobile node’s traffic and reply with a Proxy Binding Acknowledge (PBA) registration message. The MAG, upon receiving the LMA’s PBA message, will setup its endpoint of the bidirectional tunnel to the LMA and the forwarding of the mobile node’s traffic. Finally, the MAG will send periodic router advertisements to the mobile node.

When a mobile node detaches from the access link, the MAG will send a PBU de-registration message to the mobile node’s LMA, remove the bidirectional tunnel endpoint with the mobile node’s LMA, remove the forwarding of the mobile node’s traffic and the periodic router advertisements. The LMA, upon receiving the PBU, will remove the tunnel endpoint with the MAG, remove the forwarding of the mobile node’s traffic and reply with a PBA message. The LMA’s binding for this mobility session will only be removed after a certain amount of time if the LMA does not receive a PBU registration.

It is possible for a LMA to receive a PBU registration message, before receiving the PBU de-registration message. In this case, the LMA will simply ignore the PBU de-registration message.

2.5.1 Protocol Messages

The MIPv6 BU and BA messages are reused by the PMIPv6. A new flag, the “proxy” (P) flag, was added to both messages. This flag, when set to a value of 1, indicates that the messages are proxy binding messages, i.e, PBU and PBA messages. Figures 2.7 and 2.8 depicts the PBU and PBA messages format, note the it also includes the flag extensions of other MIPv6 protocol extensions.

Reserved A H L K M R P Lifetime Sequence # Mobility Options 3 0 2 0 1 0 9 8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1

Localized mobility management protocol implementation using PMIPv6

Bruno Filipe

Silva Santos

Localized Mobility Management Protocol

Implementation using PMIPv6

Implementa¸

c˜

ao de Gest˜

ao de Mobilidade

Bruno Filipe

Silva Santos

Localized Mobility Management Protocol

Implementation using PMIPv6

Implementa¸

c˜

ao de Gest˜

ao de Mobilidade

Localizada usando PMIPv6

Contents

List of Figures

List of Tables

List of Acronyms

Chapter 1

Introduction

1.1

Motivation and Challenges

1.2

Mobility Protocols

1.3

Open Proxy Mobile IPv6

1.4

Contributions

1.5

Document Outline

Chapter 2

Mobility Management

2.1

Mobile IPv6

2.2

Mobile IPv4

2.3

Fast Mobile IPv6

2.4

Hierarchical Mobile IPv6

2.5

Proxy Mobile IPv6