Background by u49y989

VIEWS: 8 PAGES: 56

									   Enhanced Internet Mobility Using Wireless Routers and Paging


Abstract
The current IP addressing scheme tightly couples the semantics of an IP address. An
IP address currently tells us two things, the identity of a node and its locality in the
internetwork. This creates problems when providing services like mobility and
multihoming for hosts. This project has been carried out in the context of looking at a
different approach to IP addressing that can improve mobility and multihoming
problems. Here the IP address is split into two parts the identity part and the locator
part. The locator part is used for routing purpose and the Identity part is used to
identify a host uniquely in the internet. When a host moves from one network to
another the locator part of the address changes but its identity part remains the same.
This allows session continuity as a mobile host transition between networks. In
protocols like Mobile IP the precise location of a MN must be known before
delivering data. This is done by sending updates to the network every time a host
changes its point of attachment. In contrast today‟s cellular networks only knows
coarse location of a terminal and the precise location is only known when there is any
data to be delivered. When a call arrives for a user the network is queried to locate the
user. This process of locating a terminal is called Paging. It helps to reduce signalling
load and helps the mobile terminal to conserve battery power by reducing the updates
that otherwise are necessary. In this project we propose the concept of paging as an IP
service. Paging process helps determine the exact location of the mobile node before
delivering packets to it. This can allow a mobile node to stay in standby mode without
updating the network and conserve battery power. IP Paging can assist a mobility
protocol to be efficient in terms of power consumption at the mobile nodes and reduce
extra signalling in the core network. We present the design, implementation, and
qualitative and quantitative evaluation of an IP paging protocol.




                                                                                        I
Acknowledgement
I‟d like to express my sincere thanks and gratitude to all those people who gave me a
helping hand in achieving the goal of making this project successful. My utmost
thanks go to my project supervisor Dr. Chris Edwards and Dr. Martin Dunmore for
having entrusted me this interesting project and also for their invaluable advice and
guidance throughout this project. My thanks also go to Mr. Utam Avinash Einstein
Mungur for providing his feedback and supporting my ideas throughout the course of
the project.




                                                                                   II
                                                       TABLE OF CONTENT
1. INTRODUCTION AND MOTIVATION ......................................................................................... 1
    1.1 PROJECT AIMS ................................................................................................................................. 2
    1.2 METHODOLOGY .............................................................................................................................. 2
2. BACKGROUND ................................................................................................................................. 4
    2.1 INTERNET MOBILITY ....................................................................................................................... 4
       2.1.1 Mobile IP/Mobile IPv4 (MIP) ................................................................................................ 4
       2.1.2 Problems with Mobile IPv4 .................................................................................................... 5
       2.1.3 Mobile IPv6 ............................................................................................................................ 5
       2.1.4 Problems with MIPv6 ............................................................................................................. 5
       2.1.5 Common Problem with MIP................................................................................................... 5
    2.2 IDENTITY/LOCATOR SPLIT CONCEPT ............................................................................................... 6
       2.2.1 An Alternate Addressing Architecture for IPv6 ..................................................................... 6
             2.2.1.1 8+8 ................................................................................................................................................. 6
             2.2.1.2 GSE (Global, Site, and End-system) .............................................................................................. 7
        2.2.2 LIN6 ....................................................................................................................................... 7
             2.2.2.1 Network Layer in LIN6 .................................................................................................................. 8
             2.2.2.2 Communication process ................................................................................................................. 8
             2.2.2.3 Problems with LIN6 ....................................................................................................................... 9
       2.2.3 Host identity payload and protocol (HIP) .............................................................................. 9
    2.3 CELLULAR IP ................................................................................................................................ 10
       2.3.1 Network model ..................................................................................................................... 11
       2.3.2 IP paging .............................................................................................................................. 12
3. DESIGN ............................................................................................................................................. 14
    3.1 NETWORK ARCHITECTURE ............................................................................................................ 14
       3.1.1 Paging process ..................................................................................................................... 15
       3.1.2 Layer 4 protocol choices ...................................................................................................... 18
    3.2 PAGING MODULE........................................................................................................................... 18
    3.3 ACCESS ROUTER MODULE ............................................................................................................. 19
    3.4 PAGING AGENT MODULE ............................................................................................................... 19
    3.5 DOMAIN ROOT ROUTER MODULE .................................................................................................. 20
    3.6 PACKET STRUCTURE ..................................................................................................................... 21
4. IMPLEMENTATION ...................................................................................................................... 23
    4.1 TEST-BED...................................................................................................................................... 23
    4.2 PAGING PROCESS .......................................................................................................................... 24
    4.3 PAGING AGENTS............................................................................................................................ 26
    4.4 RETRY TIMEOUT ........................................................................................................................... 26
5. TESTING .......................................................................................................................................... 27
    5.1 INCREMENTAL AND INTEGRATION TESTING .................................................................................. 27
    5.2 SYSTEM TESTING .......................................................................................................................... 27
6. EVALUATION ................................................................................................................................. 28
    6.1 QUANTITATIVE EVALUATION ........................................................................................................ 28
       6.1.1 Paging latency (No retry timeout) ........................................................................................ 28
       6.1.2 Impact of a retry timeout ...................................................................................................... 29
       6.1.3 Impact of a longer retry timeout interval ............................................................................. 31
       6.1.4 Impact of extreme data load ................................................................................................. 32
    6.2 QUALITATIVE EVALUATION.......................................................................................................... 34
       6.2.1 Impact of scaling .................................................................................................................. 34
       6.2.2 Impact of varying paging algorithm..................................................................................... 34
       6.2.3 Handoff ................................................................................................................................ 35
       6.2.4 Reliability ............................................................................................................................. 35
7. CONCLUSION ................................................................................................................................. 37




                                                                                                                                                                       III
    7.1 REVIEW OF AIMS ........................................................................................................................... 37
    7.2 FUTURE WORK .............................................................................................................................. 37
    7.3 CHALLENGES ................................................................................................................................ 38
8. REFERENCES ................................................................................................................................. 39
9. APPENDIX: ...................................................................................................................................... 40
    9.1 ACCESS ROUTER 1 ........................................................................................................................ 40
    9.2 ACCESS ROUTER 2 ........................................................................................................................ 40
    9.3 ACCESS ROUTER 3 ........................................................................................................................ 41
    9.4 ACCESS ROUTER 4 ........................................................................................................................ 42
    9.5 PAGING AGENT 1........................................................................................................................... 42
    9.6 PAGING AGENT 2........................................................................................................................... 43
    9.7 DOMAIN ROOT ROUTER ................................................................................................................. 43
10. PROJECT PROPOSAL ................................................................................................................. 44




                                                                                                                                                 IV
                                    LIST OF FIGURES AND TABLES
LIST OF FIGURES
FIGURE 1: GSE ADDRESSING SCHEME ....................................................................................................... 7
FIGURE 2: LIN6 ADDRESSING METHOD [6] ................................................................................................ 8
FIGURE 3: NETWORK ARCHITECTURE MODEL [6] ...................................................................................... 8
FIGURE 4: LIN6 COMMUNICATION PROCESS [6] ........................................................................................ 9
FIGURE 5: BINDINGS [5] .......................................................................................................................... 10
FIGURE 6: CELLULAR IP NETWORK MODEL [10] ...................................................................................... 11
FIGURE 7: PAGING NETWORK ARCHITECTURE ......................................................................................... 13
FIGURE 8: IP PAGING HIERARCHICAL MODEL .......................................................................................... 14
FIGURE 9: MOBILE HOST STATE DIAGRAM [2] ......................................................................................... 15
FIGURE 10: FLOW CHART OF THE PAGING PROCESS ................................................................................. 17
FIGURE 11: MODULE INTERACTION AND ITS FUNCTIONS ......................................................................... 21
FIGURE 12: PAGING PACKET HEADER ...................................................................................................... 21
FIGURE 13: PAGING PROCESS .................................................................................................................. 23
FIGURE 14: PAGING LATENCIES FOR DIFFERENT LOCATIONS ................................................................... 28
FIGURE 15: AVERAGE PAGING LATENCIES FOR DIFFERENT LOCATIONS ................................................... 29
FIGURE 16: PAGING LATENCIES WITH RETRY TIMEOUT INTERVAL ........................................................... 30
FIGURE 17: AVERAGE PAGING LATENCIES WITH RETRY TIMEOUT INTERVAL........................................... 31
FIGURE 18: PAGING LATENCIES WITH LONG TIMEOUT ............................................................................. 31
FIGURE 19: COMPARING LATENCY .......................................................................................................... 32
FIGURE 20: LATENCIES WITH TRAFFIC LOAD ........................................................................................... 33
FIGURE 21: NETWORK COMPONENTS FAILURE ........................................................................................ 36

List of Tables
TABLE 1: PACKET DESCRIPTION .............................................................................................................. 22
TABLE 2: MODULES AND THEIR FUNCTIONS ............................................................................................ 25
TABLE 3: AVERAGE LATENCIES ............................................................................................................... 33




                                                                                                                                                 V
1. Introduction and motivation

Mobile Internet is becoming the norm; today wide arrays of portable devices with
built-in high speed packet radio access are capable of connecting to the internet. In the
future millions of users will be connected to the internet while on the move. This will
place a higher demand on future cellular and Wi-Fi IP networks. Wireless access
technologies like Wi-Fi, Wi-MAX are already gaining market maturity but more
research is needed on interoperability and integration of these wireless technologies
[1]. Mobile IP (MIP), the current solution to IP is fraught with inadequacies. The
network maintains the exact information of a mobile node by requiring mobile nodes
to update the network upon change of every network location. MIP works fine whilst
there are not many mobile nodes to support, but in the future we expect to see millions
of people using internet on the move, surely MIP faces a number of technical
challenges in terms of performance and scalability. One reason is that MIP uses
techniques like encapsulation to deliver packets destined for a mobile node (MN), this
causes network overhead in terms of delay and packet loss. Moreover when a node is
in idle/standby (not sending/receiving packets) it is supposed to update the network
whenever it changes its point of attachment. This creates unnecessary signalling in the
network and wastes scarce radio bandwidth, and also considering the battery
constraints of the mobile devices, unnecessary signalling drains the mobile terminal‟s
battery.

Another mobility problem arises due to the current IP addressing system. Currently
the IP addressing scheme overloads the semantics of an IP address. In both versions
IPv4 and IPv6, an IP address tells us 2 things: the end-point interface in a network and
the location for routing in the network level. This means when a host moves to a new
network it is assumed that its location is still the same old network. Now when
packets destined for the host arrive they will arrive at its old network which will be
eventually tunnelled to the mobile host for delivery. New research efforts are looking
at decoupling the location and identity semantics from the IP address and using this as
the basis for an IP mobility solution. In essence, this would involve one identity IP
address being associated with the locator address that relates to the location of the
mobile device at any given point in time. As a mobile device moves and changes its
address, applications can still use the identity address to contact the mobile host but
this is mapped to its current locator address by some mapping agent. When a mobile
device roams into new networks, it must first authenticate with the network and then
update the mapping agent with its new location. The network device that handles the
authentication procedure and allocates the new address is called a radio router.

In MIP the network must keep track of the precise location of the mobile host before
any data can be delivered. It requires a mobile host to register whenever it moves into
a new network, In order to reduce signalling in the core network and the impact on
battery power consumption of mobile devices, the future mobile Internet needs to be
able to support operation with “signalling free mobility”, whereby hosts do not
automatically signal the network when they move into the coverage of a new radio
network. Instead when a downlink packet arrives at an access router for a mobile host
that has moved elsewhere, the network will search for the location of the mobile host
before delivering the packets, this process of locating the mobile host is called
Paging. In a network that supports paging mobile hosts are allowed to operate in two


                                                                                       1
distinct states- an active state in which the mobile host is tracked at the finest
granularity possible such as its current access router (resulting in no need for paging),
and a standby state in which the host is tracked at a much coarser granularity such as a
paging area. The mobile host updates the network less frequently in standby state
(every paging area) as compared to that in active state (every access router) [2]. This
helps to significantly reduce the battery power consumption at the mobile host which
is one of the main benefits of providing a paging service in mobility protocols. Thus
IP Paging focuses to optimize the signalling and processing costs in future wireless
technologies. This project will look at a paging architecture and an IP paging protocol
that can be integrated and can interoperate with future IP based wireless network
infrastructure.

1.1 Project aims

In this project we aim to study the different ways of IP addressing systems that current
research is looking into and use it as an approach to provide mobility solutions. The
aim is to work towards the goal of a research work carried out by Cisco on “Mobile
Internet Framework” in the computing Department. This research aims to investigate
as to whether a GSE [8] based architecture, which previously has been promoted as a
candidate solution to the multi-homing problem, can be enhanced to offer a true
mobility solution including scaling to mobility event rates typical in today's cellular
networks. We look at the problems that face today‟s mobility protocols. After a
detailed study of the mobility problems we look at a technique called IP Paging which
allows the mobility protocols to support efficient location management hence
overcome some of the mobility problems. We aim to study the IP Paging functionality
and the network architectures that support it. The aim of this project is to develop an
IP Paging protocol which is capable to operate alongside mobility protocols like MIP
and with other wide-area networks such as GPRS, CDMA. Together IP paging and IP
mobility will support the full functionality present in current wide-area wireless
networks, thereby serving as the basis for efficient and cost-effective all-IP third and
fourth generation wireless networks [2]. The goal is also to evaluate the paging
system for performance and investigate its pros and cons in providing mobility
solutions.

1.2 Methodology

Here we will provide a plan showing how we will meet the required aim of the
project. The main steps that will be taken to achieve the aims are outlined below

   The first step is to have an understanding of various IP Mobility protocols and
    understand how they work. Then we will look into the Identity/Locator split
    concept and how it works.
   Next we will study an IP Paging system and propose an IP layer paging service.
   After that we present the design of our proposed paging architecture and provide
    an implementation of it.
   Then we evaluate the paging system and see how it scales in the current internet
    architecture and what are its pros and cons.
   And finally we will do a quantitative evaluation of the proposed paging system
    and conclude our work.



                                                                                       2
The remaining outline of our report is organised as follows. In Section 2
(Background) we will have a detailed working of IP Mobility and IP Paging. Section
3 (Design): will cover the detailed design of the IP Paging Architecture, then in
Section 4 (Implementation): we outline the implementation of the IP Paging
functionality and provide a detailed understating of how it works, thereafter in Section
5 (Testing): we outline the different testing procedure applied to uncover errors and
bugs from our implementation. Section 6 (Evaluation): provides a detailed evaluation
of the IP Paging Process outlining how far we met our requirements. And finally in
Section 7 (Conclusion): we will provide an overall overview of the work and some
future work to be done. We will also outline the challenges faced during the project.




                                                                                      3
2. Background

In this section we will describe what Internet Mobility is and look into some of the
existing internet mobility protocols, and the problems associated with them. We will
then look at some solutions proposed to address these problems and explain a new
approach called Identity/Locator split. Thereafter we will explain in detail how the
concept of IP Paging works and provide an understanding how it fits into the solution
of providing seamless internet mobility.

2.1 Internet mobility

In both IPv4 and IPv6, the IP address tells us two things: firstly, it identifies a
particular interface on an end host and secondly, it tells it tells us the location of that
interface within the global Internet routing infrastructure. This addressing scheme
tightly couples an end host‟s location and identity semantics; it has all worked well up
until now because internet devices did not change location over the course of a
communication session. However today there are smart mobile devices and
applications that allow users to access the internet on the move. This would mean that
a mobile host has to acquire a new IP Address in each network it travels but, certainly
in doing this it would cause the applications to terminate a session and re-initiate a
new one upon acquiring new IP Addresses. To address this problem the IETF
developed a protocol called Mobile IP (MIP), it allows a mobile host to keep the same
address for its entirety. Several other mobility protocols have been proposed to
address the problems of mobility. We will have a look at them next and see how they
solve the problem of mobility and where they fail.

2.1.1 Mobile IP/Mobile IPv4 (MIP)
Mobile IP solves the problem of mobility. It allows the mobile node to move freely
across networks while maintaining the same IP address throughout its journey. It
works by having special functionality in the access routers called the Home Agent
(HA) (this is in the mobile nodes (MN) home network) and Foreign Agent (FA)
(visiting networks). It also requires the MN to have two addresses. A Home Address
which is the fixed address of the MN and a care-of-address (CoA) that changes
depending on the network the MN is attached to. For example consider two networks
A and B. When a mobile node moves from network A to B, it keeps its address from
network A called the home address. Upon entering network B it will acquire a new IP
Address from the FA, this address is the CoA. The MN conveys this address to the
HA which will eventually be used to forward any packets destined for the MN. The
HA keeps a mapping of both the addresses in its cache called a binding cache, now
when a packet arrives for the MN it will arrive at the HA, the HA checks its binding
cache to see if it has an entry for the address, if it has, it encapsulates the original IP
packet into a new packet with the CoA as the destination address and forwards the
packet to the FA, this process is called tunnelling. The FA in turn will de-capsulate
the packet and forward it to the mobile node. This way the MN can stay connected to
the internet.




                                                                                         4
2.1.2 Problems with Mobile IPv4
The problem of mobility is solved with MIP but there are many shortcomings
associated with it. As we have seen MIP uses tunnelling to forward the packets to the
MN, this leads to extra overhead and moreover tunnelling bypasses value added
features in the internet fabric. As an example we can consider security in the edge of
the access routers. Another problem is that, the MN has a home address which is used
as an identity throughout its journey while roaming in foreign networks. This means
an IP address expressing location is used to refer to a location it actually does not
represent. “This creates an illusion to the transport layer protocols that the location of
the other end-point could be deducted from the available home address. Therefore
transport layer functions like congestion control can go wrong because it would
believe that the static home address actually provides topological information” [3].
Also considering today‟s mobile environments where MN‟s change their point-of-
attachment frequently, MIP could result in high signaling load as well as high handoff
latency and packet loss [4]. Hence we can see that MIP is not capable of providing a
fine grained mobility solution and is not scalable solution when considering the
amount of signalling it will cause in the core network.

2.1.3 Mobile IPv6
As IPv6 was designed to replace the current IP protocol (IPv4), the IETF considered
enhancing the MIP protocol by using the new IPv6 protocol features to implement
extra features and try to address the problems that existed in MIPv4. This new
protocol was called Mobile IPv6 (MIPv6).

In MIPv4 when a Correspondent Node (CN) sends packets to the MN the HA
intercepts the packets, checks its binding cache for the mappings and tunnels them to
the FA which then finally delivers the packet to the MN. The path taken by the
packets forms a triangular route and this is called the triangular routing problem. This
problem is avoided in MIPv6. In MIPv6 not only does the HA have the address
mappings but the CN also maintains these mappings in a binding cache. This enables
the CN to directly route packets to the MN which leads to route optimization.
Moreover when the CN send packets to MN it does not use IP-in-IP encapsulation
instead it uses the IPv6 Routing Header option. In MIPv6 signalling is done using
external headers that can be piggybacked on regular packets whereas in IPv4 it is
done using UDP [4]. Also MIPv6 uses stateless auto-configuration to acquire a CoA
which avoids the need for a FA as compared to MIPv4 in which a FA is compulsory.

2.1.4 Problems with MIPv6
Firstly, MIPv6 has large header overhead since it makes use of extension headers.
Secondly, tunnelling is again the same issue as it was in MIPv4. Also route
optimization may not always be possible to implement due to business or technical
regulations.

2.1.5 Common problem with MIP
A MN must update the HA with a new CoA whenever it moves to a new network.
During this update messaging phase packets will be forwarded to the old location
where the MN was previously registered and will not be delivered. This can cause
active communication sessions to break. Similarly during route optimization an active
communication session is disrupted while the CN obtains a new binding. These delays
can grow with frequent movements of MN(s). Moreover the load on the internet and


                                                                                        5
the HA increases with the increase in the update messages also when the MN is idle
while moving [10]. This can be a problem as more and more mobile nodes will be
connected to the internet. Speaking in general MIP is a good solution for mobility and
is suited for slowly moving mobile hosts but becomes inefficient when supporting
higher load and fast moving hosts.

2.2 Identity/Locator split concept

Now we look at the concept of Identity/Locator split where the traditional IP address
is split into two separate entities, the Identity part and the Locator part. In general the
Identity part will identify a unique host in the internet and the Locator part will tell us
to which network the host is attached. When the host moves across network
boundaries the locator part of the address changes whereas the identity part remains
the same. There have been many proposals of this concept. We will look at some of
them here.

2.2.1 An alternate addressing architecture for IPv6
We have seen how MIP solves the problem of mobility with the concept of a CoA, but
this is not a robust solution considering the number of mobile devices that will be
connected to the internet and their frequent movements across networks. Techniques
like Multihoming and Rehoming are other issues which need to be addressed as it
causes increase in the growth of the routing table in the internet backbone.
Multihoming is advertising multiple prefixes for a single network in the global routing
table and Rehoming is changing network providers. Also as the space of the IP
addresses increases with the deployment of IPv6, there will be many new networks
and hosts being connected to the Internet. This will eventually cause the routing tables
entries in the internet backbone to expand causing increased load on the backbone
routers. Therefore a solution is needed for scalable routing and addressing for the
future needs of mobility, multihoming and rehoming. We will look at some proposed
solutions here.

2.2.1.1 8+8
Mike O‟ Dell proposed an alternative approach for internet routing and addressing. He
called the new approach “8+8”. The concept here is to split the 16 byte IPv6 address
field into two 8 bytes objects. The lower 8 bytes (least significant) form the End
System Designator (ESD) and the upper 8 bytes (most significant) are called the
Routing Goop (RG). The ESD value is used to specify an end system and it remains
constant whereas the RG is used to identify where an end host attaches to the internet
in the global internet topology. This model requires modifying the upper layers above
layer 3 to consider only the ESD when processing data meant to identify the end
system [7]. An example here would be the TCP checksum only using the ESDs value.
TCP association would be identified by ESD/Port instead of IP address/Port [7]. This
would allow TCP connections to continue on a mobile device when it changes
network point of attachments. Hence internet mobility is achieved here without the
use of a CoA which would mean there is no need to inform the home agent of the new
address on every movement to a new network.




                                                                                         6
2.2.1.2 GSE (Global, Site, and End-system)
GSE is an extension to the 8+8 approach. Here the 16 byte IPv6 address is split into
three different parts. The lower N bytes are called the End System Designator (ESD),
and then come the middle M bytes called the Site Topology Partition (STP); this part
is used for local routing purpose. And the remaining top 16-M-N bytes called the
Routing Goop (RG) [8]. The addressing format of the proposed GSE scheme is
shown in figure 1.
               0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             | Routing Goop     | STP| End System Designator |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                    6+ bytes   ~2 bytes       8 bytes

                            Figure 1: GSE addressing scheme

There can be more than one ESD for a node. Each ESD is globally unique and is used
to identify nodes in the GSE internet infrastructure. When a communication session is
active between end points, the layers above the network layer use the ESD value and
the port as an identity for that communication. Now when an end point changes it
point-of-attachment its RG value changes and is mapped to the corresponding ESD. In
this manner layers above network can continue using the ESD value and keep the
communication session active. GSE proposes the use of the Domain Name System for
the purpose of acquiring the correct IP address for routing. There are many issues
about GSE‟s approach for solving the multihoming problem which we will not
discuss here as they are out of the scope of this report. But what we take away from
GSE is the Locator-ID split concept in helping us to solve the problem of mobility.

2.2.2 LIN6
LIN6 uses the same approach as 8+8 in which each host has a 64 bit globally unique
identifier, called the LIN6 ID. LIN6 uses two new concepts: node identifier and
interface locator. The node identifier denotes the identity of a MN, and it does not
change when a node changes its point-of-attachment whereas, the interface locator
denotes the current point-of-attachment to the network, it is assigned to the network
interface of the MN and used to route packets to it. This mean the node identifier
remains the same and the interface locator changes when the node moves [6]. The
relation between the node identifier and the interface locator is called a mapping and
LIN6 uses a mapping agent (MA) to create this mapping. A node registers its mapping
periodically with the MA and it registers a new mapping when it moves from one
network to the other. Here also the transport and the upper layers can communicate
with the MN using the node identifier regardless of its location. This identifier is
called the generalized identifier. This means active communication sessions do not
break during the movement of the MN.

LIN6 maintains compatibility with IPv6 to ensure there is minimum impact to the
conventional infrastructure. The LIN6 addressing method is based on IPv6
Aggregatable Global Unicast Address (AGUA) in which the upper 64 bits of the 128
bit IPv6 address indicates the network prefix to which the address belongs, and the
lower 64 bits represents the interface ID. In LIN6, the interface locator is 128 bits
long, and the node identifier is 64 bits long [6]. The LIN6 addressing method is shown
in figure 2.



                                                                                    7
                          Figure 2: LIN6 addressing method [6]



2.2.2.1 Network layer in LIN6
Here the network layer is divided into two parts, the identification sub layer and the
delivering sub layer. Figure 3 shows the LIN6 network architecture model. The
transport layer passes the generalized identifier to the network layer where it is
mapped to the interface locator by the identification sub-layer by querying the MA.
The delivering sub-layer thereafter delivers the packet using the interface locator.




                        Figure 3: Network architecture model [6]



2.2.2.2 Communication process
In figure 4 consider two mobile nodes MN1 and MN2 in a communication process. It
is assumed that both the MN(s) have registered their mappings with a MA.
     MN1 queries the MA to acquire the current locator of MN2. MA returns the
        current locator value to MN1.
     MN1 creates the LIN6 address of MN2 and sends the packet.
     MN2 now queries the MA to acquire the current locator of MN1. MA returns
        the current locator value of MN1.
     MN2 creates the LIN6 address of MN1 and sends the packet.


                                                                                    8
                  Figure 3        LIN6 communication procedure




                        Figure 4: LIN6 communication process [6]

When a MN moves to a new network it sends a mapping update to its corresponding
MN that it is talking to and the MA. LIN6 uses Domain Name System (DNS) to
locate the MA(s) of a MN.

2.2.2.3 Problems with LIN6
LIN6 does not scale to the security aspect of the protocol. It uses IPsec AH for
address update messages; this requires some kind of global infrastructure to create the
required security associations [5].

2.2.3 Host identity payload and protocol (HIP)
Host Identity Payload and Protocol (HIP) is an approach for addressing the problem
of mobility and multihoming in a more secure way. It tries to avoid the common
problem of address stealing and address flooding that MIP faces. As we know in the
current architecture processes are bound to transport layer sockets, and the sockets are
identified by using IP addresses and ports. HIP uses a new name space of Host
Identifiers (HI) that is used to name the transport layer sockets instead of an IP
address. This is done by dynamically binding a HI to one or more IP addresses,
meaning that a mobile host can have more than one network point of attachment
resulting in mobility and multihoming of a mobile host. Figure 5 shows the bindings
of both the architectures.




                                                                                      9
                                  Figure 5: Bindings [5]

A new layer called the Host Identity Layer introduced between the network and
transport layer takes care of this binding process. The HI here is a public key of a
public-private key-pair of a host. This means the security associations required
between two end points are bound to a static public key. Therefore the verification of
the public key does not require an external public key infrastructure (PKI) which
would not be scalable. HI‟s are also able to convert into an IPv6 compatible address
called the Host Identity Tag (HIT) by applying a hash function to the host identifiers.
This HIT then can be used by layers above the transport layer and hence make it
compatible with IPv6 hosts.

For the whole architecture to function it also requires some extra elements like Packet
Forwarding Agents and some new protocols to enable a mobile host to discover the
correspondent nodes address and a protocol to send updates when a node changes its
point of attachment. Packet forwarding agents can be an access router or a node acting
as a virtual access router, used specially for forwarding purpose. The Host Layer
Protocol (HLP) is used for the end-point to end-point signalling of location updates
and other information about the current available updates. The whole security aspect
is distinct due to the cryptographic nature of the HI due to which security is tightly
coupled into the solution.

2.3 Cellular IP

Cellular IP is a host mobility protocol that takes an alternative approach to that found
in mobile telecommunications (e.g. General Packet Radio Service) and IP networking
(Mobile IP). It is a lightweight and robust protocol that is optimized to support local
mobility and efficiently works with Mobile IP to provide wide area mobility support
[10]. It is proven to work in environments were MN(s) move frequently between
networks, which will be the case in the near future where internet mobility will
become ubiquitous. It uses IP Paging to keep track of the location of idle mobile hosts
and wake them when there are packets ready to be delivered to them. As mobile hosts




                                                                                     10
are allowed to stay in idle mode during their movements across networks, it ensures
efficient power management in the mobile hosts.

Cellular IP operates by maintaining two distributed caches for location management
and routing purposes.
    The Distributed paging cache: This cache maintains the positions of idle
       mobile hosts in a service area. Cellular IP uses this cache to keep track of the
       idle mobile hosts and locate the appropriate mobile hosts that wants to start
       active communication.
    The Distributed routing cache: This cache maintains the position of active
       mobile hosts in the service area and dynamically refreshes the routing state in
       response to the handoff of active mobile hosts [10].



2.3.1 Network model
The cellular IP wireless access network model consists of cells of specific sizes as
shown in figure 6; each cell consists of a base station. The base stations are
interconnected to each other using wired links. Apart from base stations, there are
some nodes that have no radio devices but serve as traffic concentrators or support
mobility management functions. In figure 6 node E doesn‟t have a radio device. Such
wireless access networks are connected to the internet using a router, called gateway
routers. This router can serve both as a home agent and foreign agent depending on
the location of the mobile nodes.




                         Figure 6: Cellular IP network model [10]

It is assumed that Mobile IP is used to support mobility within these wireless access
networks. Now consider the mobile host X in the above figure. When it enters the
wireless access network it registers with its home agent which will eventually forward
packets addressed for the mobile host to the access network. Whilst the mobile host
remains within the same access network, mobility is hidden from the home agent.
Base stations periodically emits beacon signals to allow hosts to identify available


                                                                                    11
base station. Mobile hosts are free to roam within the access network and only inform
their home agent when they leave the access network.

It is important to ensure that for large number of hosts staying connected to the
internet, mobile host protocols need a simple location tracking scheme that imposes
the least traffic and processing load on the global network for idle mobile hosts. This
is referred to as cheap passive connectivity here [10]. Mobility between access
networks occurs at a slower timescale, hence allowing Mobile IP to optimize for
infrequent migrations.

2.3.2 IP paging
As we have seen in the current mobility protocols, the precise location of a mobile
host must be known before data can be delivered. It is to be realised that there is a
trade-off between how closely the network tracks the current location of a mobile
host, against the time and complexity required to locate a mobile host whose position
is not precisely known [10]. To track the location of the mobile node it has to update
the network with messages at frequent time intervals or on the expiration of a timer.
Such network uses paging to locate the position of a mobile host.

Paging is a process to query a set of locations in a network to locate the current
location of a mobile host. The set of locations is called a paging area. Figure 7 shows
the example network architecture with paging area A and paging area B.

In a network that supports a paging architecture a mobile host is allowed to operate in
two distinct states.
 The Active state: In this state a mobile host updates the network on changing
    every base station; here different update messages are used to update the network
    (not paging update messages).
 The Standby state: In this state the mobile host updates the network only on
    changing a paging area; here paging messages are used to update the network. The
    mobile host updates the network less frequently in standby state than in active
    state. This ensures that less update messages are needed in standby state and hence
    battery consumption is reduced which is crucial for the mobile host to sustain
    longer battery time. This is the main benefit of providing a paging service [2].

For example when packets arrive for a mobile host at a Radio Router and the mobile
host is no longer under the network coverage of that router, the radio router buffers
the packets and will page its top level radio routers to ask if they can locate the current
location of the mobile node. If those routers cannot locate it they page the radio router
one level up in their hierarchy and if this is the domain route router it will page the
routers one level below in its hierarchy. This process continues until the mobile host is
located. Once found the mobile host sends a reply back through the path from which
the request came, and will finally reach the initial radio router who initiated the
request. Now the buffered packets will be delivered to the mobile host through the
path which was discovered by the reply message. The mobile host will eventually
register itself with the domain root router and there will be a new path set up. Packets
arriving thereafter will be routed to the mobile host directly through this new path.
But an important thing to note here is when a node is in standby state and moves to a
new network, there should be a way to let the radio router know that the node is in its
vicinity so that when a page request arrives the radio router can respond with a page


                                                                                        12
successful reply. This is done by sending some special type of beacon message in a
standby state. These beacon messages will be sent by the mobile node to the nearest
radio router frequently at specific time intervals.



                                                     Domain
                                                     Root
                                                     Router




                       Radio                                                      Radio
                      Routers                                                     Router
                                                                                    s




         Paging                                                        Paging
         Area A                                                        Area B




                          Figure 7: Paging network architecture

In this manner paging can help reduce the signalling load in the core network and
hence spare bandwidth. It also supports easy location tracking of idle mobile nodes.

There are other micro mobility protocols that support paging functionality like
Hawaii, Hierarchical Mobile IP (HMIP), Intra Domain Mobility Management
Protocol (IDMP) and Paging Extensions for Mobile IP (PMIP) [12]. We will not
explain each in detail because it is out of scope of this report. But the important thing
we note here is that an efficient mobility protocol that needs to function without extra
signalling overhead and allow mobile users to preserve battery life will having have
support for paging functionality.




                                                                                      13
3. Design

In this chapter we will look at the various aspects of our network that supports paging
such as the network architecture, the design of the protocol and the protocol packet
structure. We will also look at how the paging process is executed. We will start with
the network Architecture as this is the most important aspect of the protocol design.

3.1 Network architecture

The network architecture is supposed to be a hierarchical approach. The hierarchy is
divided into levels and each level has its own functionality. A generic design of the
network model is as shown in figure 8. Here the Access Routers (AR) are located at
level M, then at level M+1 we have the optional paging agents (PA), and so on till the
final node which is the gateway to the internet is called the domain root router/root
node. The AR(s) have a paging association with the PA(s) at level M+1, similarly the
PA(s) at level M+1 has a paging association with the PA(s) at level M+2. And the
PA(s) will have a paging association with the Domain Root Router. In this manner all
the nodes in the network are included in the paging hierarchy.
                                   +------------+
                                   | Domain     |
                          +-------| Root        |--------+                   Level M+3
                         /         | Router &   |          \
                        /          | Paging     |           \
                       /           | Agent      |            \
              +----------+         +------------+        +----------+
              | Optional |                               | Optional |
              | Paging    |                              | Paging   |        Level M+2
              | Agent (C)|                               | Agent (B)|
              +----------+                               +----------+
               /       \                                   /     \
              /         \                                 /       \
             /           \                               /         \
      +----------+        \                             /      +----------+
      | Optional |          \                          /       | Optional |
      | Paging   |           \                       /         | Paging   | Level M+1
      | Agent (D)|            \                     /          | Agent (A)|
      +----------+             \                   /           +----------+
        /     \                 \                 /              /      \
       /       \                 \               /              /        \
      /         \                 \             /              /           \ Level M
+--------+    +--------+      +--------+    +--------+     +--------+    +--------+
| Access |    | Access |      | Access |    | Access |     | Access |    | Access |
| Router |    | Router |      | Router |    | Router |     | Router |    | Router |
|   #6   |    |    #5   |     |   #4   |    |   #3   |     |   #2   |    |   #1   |
+--------+    +--------+      +--------+    +--------+     +--------+    +--------+


                          Figure 8: IP paging hierarchical model

Each node in the network except the root node will have one up-link node connected
to it. It is also assumed that the network is divided into paging areas. Our network
topology that we used as a test-bed represents one single paging area. The paging area
helps to divide a large network into subnets so that the paging process can be faster
and more efficient. We will see why this is the case in the later section of the report.
The source code is designed in separate modules and depending on the level in the
hierarchy the modules will be executed accordingly. At level M the Access Router
module will be run, then at levels above the optional paging agents will run the




                                                                                         14
Paging Agent module, the root node will run the same Paging Agent module but with
different logic. We will look at functionality of each module further in this section.

3.1.1 Paging process
In networks that support paging a MN can be in one of the two states, active or
standby. Figure 9 shows the state diagram of a MN. When the node is sending or
receiving data it is in active state. In this state the network keeps track of the precise
location of the node and hence data is delivered quickly. If the MN is inactive for a
period of time (i.e. not sending or receiving any data) it is considered to be in standby
state. During this state the location of the host is coarsely known. If data arrives for
the host now, it must be searched in the network using paging. When in active state,
the MN updates the network each time it changes its point of attachment, and when in
standby state, the MN updates the network less frequently only when it changes a
paging area. Thus power saving is achieved at the MN which is a benefit of a network
that supports signalling free mobility.




                          Figure 9: Mobile host state diagram [2]

The AR(s) in our network hierarchy have the responsibility to initiate paging. When a
downlink packet arrives for a MN it will arrive at the AR that last authenticated the
MN, now assuming that the MN has moved to a new AR. The old AR initiates a
paging request to the uplink node (PA) at level M+1. If the PA has any downlink
nodes attached to it, the page request will be forwarded to those nodes, so for example
if there are two AR(s) connected downlink apart from the AR that initiated paging,
both those AR(s) will be paged and if the MN is located by any one of those AR(s),
they will reply to the PA saying that it found the MN, thereafter the AR also has the
responsibility to reply to the node that might have buffered packets, this will be the
uplink PA associated with the page initiator. The reply message will contain the IP
address of the AR where the node is located so that any packets that were buffered
can be delivered to this AR. Our paging process will use a special packet, the packet
structure will be explained in detail later in this section but we look at some message
types that we have used to identify different processes. The page request will be
identified by message type 7. The page successful reply to the uplink node will be
type 2. The page successful reply sent to the PA associated with the page initiator will
be type 9. If the MN is not found by any of those downlink AR(s) the paging process
is forwarded uplink in the hierarchy. This process of paging continues until the MN is
located and when the page request reaches the root node, it sends the request
downlink and the search process continues. This way the paging process will reach
the AR(s) at the level M again and the MN will be searched, if located the usual
things happen of replying the node uplink and the page initiator. But if the MN is not


                                                                                       15
found in the entire paging area the root node is informed about this with a message
type 3. The root node will then reply to the page initiator saying that the MN was not
searched in entire paging area. This will be message type 5. A flow chart showing the
basic flow of the paging process is shown in figure 10.




                                                                                   16
            CN sending
            packets to MN



                                        Yes
                 Is MN at                       Continue
                 old RR?                        communication


                              No


            Initiate Paging
            Request



                                   Yes
                                              Send Page
                Is MN in                      successful reply
                vicinity of                   back to page
                new RR?                       initiator


                              No

    Page uplink nodes if MN not
    found until we reach root
    router. Root router will page
    downlink in the hierarchy until
    page successful.



    On page success the new AR
    will send a page successful reply
    to the PA just above the AR.




      If there are buffered
      packets send to new AR



           New path set-up
           for the MN


Figure 10: Flow chart of the paging process



                                                                 17
As we said in the IP paging section that a paging system needs some kind of beacon
messaging to let the AR(s) know that the MN has moved in its vicinity. Here we
decided to use the ping command which would normally wake up the MN and
confirm its availability to the AR(s). This design choice was made because we will be
using layer 3 during out implementation of the paging system. Thus using a ping we
don‟t need any extra beacon messages to be introduced. We will see how it works in
detail in the implementation section. Now considering the Identity/Locator split
addressing system the Locator part will be the higher 64 bits of an IP address and the
Identity part will be the lower 64 bits. When a MN moves to a new point of
attachment the Identity part of the IP address will remain the same whereas the
Locator part changes. So the payload of our paging request packet will contain the
Identity IP address of the MN to be searched.

3.1.2 Layer 4 protocol choices
In our implementation we will be using tcp connections for sending and receiving
messages, the choice to use tcp was made considering the reliability of the system. By
using tcp connections we can assure a great degree of reliability for messages not
being lost in transit. Another reason why tcp was chosen over udp is that in a udp
communication session there would have been a need to explicitly send an Ack
message for each packet sent, instead tcp has an Ack which is part of the
communication session itself. Thus tcp helps us reduce the extra messages that need
to be sent otherwise in an end to end communication session.

3.2 Paging module

This module will be responsible to initiate paging at the AR(s). Mobile hosts will be
assumed to be reachable by an AR corresponding to their last authenticated subnet.
Only when this AR fails to deliver a down-link packet, it will then trigger a paging
process to discover the new location of the endpoint and optionally packet delivery.
Now in order to decide whether a MN has moved to a new location, we decided to use
the Neighbour Discovery (ND) functionality available in IPv6. ND allows nodes on
the same link to advertise their existence to their neighbours and to learn about the
existence of their neighbours [9]. There are many processes which ND supports; one
which is important to us here is “Neighbour Unreachability Detection”. It provides a
mechanism to determine whether mobile hosts are available in coverage area of an
AR. It does this by checking its Neighbour Cache (NC) for the Identity part of the IP
address of a MN. The NC also has an associated state with each entry. When an AR
wants to know about the reachability of a MN it checks its NC. There are three
possible states for a node that is reachable by an AR these states are REACHABLE,
DELAY and STALE. If the node is not in one of these states it is assumed to be
unreachable and it entry will have an UNREACHABLE state.

Now if the MN is neither receiving nor sending packets, its neighbour cache entry will
time out within 20-25 seconds and eventually is removed from the cache. This does
not mean that the node has moved away, it could be in idle state. So before initiating a
paging request to ensure whether the MN has certainly moved or not a Ping is done
using the MN Identity IP address, if it is still there it will be activated and a NC entry
will be populated with one of the three states described earlier, and hence after
checking the NC again we are sure that the MN has not moved, else if it is not
available it will be in UNREACHABLE state. We assume here that if the node has


                                                                                       18
shut down it is not available because the ping will not be able to reach it. In this
manner the NC and ping processes which are already a part of the IPv6 protocol
assists us in this paging process and there is no need for any extra functionality like
beacon messages or transmitting any special packets to inform the AR of the presence
of the MN.

Now to initiate a page request the code will be continuously polling the NC to track
an entry for the Identity IP address with the corresponding state. If not in area it will
initiate a paging request to locate the MN. The payload will contain the Identity IP
address of the MN to search. After initiating paging it will no longer be responsible
for any other activity. The other module which will be running on the AR(s) will be
responsible for receiving a paging request and replying back if the node is located. We
will look at the AR module next.

3.3 Access router module

A module runs on the AR(s) that listens for paging requests and searches for the MN.
If found it will reply back with a page successful message and if not found it will not
respond back. By not sending any reply message like this we reduce unnecessary
signalling in the network and hence conserve bandwidth. The AR(s) will be the
Wireless Access points that will provide wireless access to MN(s). In real time
scenarios they will be responsible to handle many MN(s) at one instance so keeping
this in mind we have to make sure that the processes running on the AR(s) are
lightweight. So the code running on the AR(s) was decided to be separate from that
running on the above levels and hence the code complexity at the AR(s) is reduced.

Now when a page request arrives at an AR, the IP address of the node to be searched
will be extracted from the payload and a ping will be done to that address. After that
the NC will be checked. If an entry is found in a reachable state the MN is reachable,
and the AR will reply to the page initiator of a page success so that if any buffered
packets are waiting they can be delivered at the new location. The page initiator
would normally be the AR that initiated the paging. But as we said earlier to have
least complexity at the AR(s) and in order to keep them lightweight, it was decided to
let the PA associated with the page initiating AR handle the buffering and forwarding
of the packets if there is any. So when we say replying to the page initiator, it will
mean the PA that is associated with the AR. The page successful reply will contain
the IP address of the new AR in the payload so that the page initiator knows where to
deliver the buffered packets and from there the AR can send them to the MN. The AR
on locating the MN also replies the PA uplink so that it doesn‟t need to page again
and also stops the paging process propagating further. Next we look at how the PA(s)
handle the paging process.


3.4 Paging agent module

The paging agents are basically routers but with some additionally functionality which
helps with the paging process in the network. Each PA has a paging association with
its downlink nodes (PA or AR). The module that runs on the PA(s) is responsible for
various tasks which we will look into further in this report. The same module is
executed in all the levels above the AR(s), including the Domain Root Router.


                                                                                      19
Depending on the level in the hierarchy, a parameter must be specified to start the
modules which will distinguish each level, so for example if we are starting the PA at
level M+1, parameter 1 must be specified, at level M+2 parameter 2 must be
specified, this way the highest level will in the network topology will be the root
router. Depending on the level the PA(s) are made to set their timer for the waiting
time to receive a message back after sending a paging request downlink. The timer is
adjusted in such a way that as the level of the hierarchy increases the time to wait for
the reply doubles. This ensures all the levels above the AR(s) to wait for enough time
until the lower levels have finished their processes and sending back the reply
message if a node is found.

The PA listens for paging requests. When a page request is received from an AR the
PA will write its IP address in the payload field and forwards the request. This is to let
the AR know where to reply if the endpoint is located. The page request is forwarded
to its down-link routers with the exception of the AR/PA from where the request
arrived. If the functionality to retry a page is set, then after sending a page request the
PA starts the retry timer and waits for the specified time (150 ms in our case, but can
be tuned by administrator according to the needs). If the MN is searched by one of its
down-link AR(s) they will reply back with a page successful message. If there is
functionality for buffering packets the PA(s) will be responsible for forwarding them
to the AR upon receiving a page successful message. Due to time constraints this
functionality was not implemented. Now if the node is not located by any of the
AR(s), the retry timer at the PA will time out within 150 ms and the AR will be paged
again to ensure that a page successful reply message has not got lost or delayed in
transit. The retry timer functionality is to make the system as reliable as possible
because depending on the network there can be congestion or higher processing load
on the nodes. If there is no reply the second time the PA will forward the page request
to its uplink node. If there are more PA(s) in the network hierarchy they will receive
this request and repeat the same process of paging its downlink nodes until there is a
positive reply. In this manner the page request will reach the domain root router if the
MN is not found.




3.5 Domain root router module

The Domain Root Router (DRR) or the Gateway is basically the entry point to the
network for the packets arriving from the Correspondent Nodes. It also has the
responsibility to react to paging request and respond accordingly. The same module
that is executed on the PA(s) runs here but with different logic as it is the root node in
the network hierarchy. The DRR receives paging requests and forwards them to all
connected downlink nodes with the exception of the node that it received paging


                                                                                        20
request from. If the page was successful it doesn‟t receive any reply, because the AR
that located the MN will send a reply back to the page initiator saying that the page
was successful. But if the page was not successful the DRR will be responsible to
reply to the page initiator saying that the page was not successful so that it can take
actions accordingly. Figure 11 shows the communication between all the modules.




         Modules interaction and                                               Initiate Page
                                                     Paging Module               Request
         its functions



                   Access Router                 Paging Agent           Domain Root
                      Module                       Module               Router Module




  Receive Page       Search Mobile       Send Back       Receive Page     Page      Receive reply
    Request              Node              Reply           Request      Downlink     if node not
                                                                         Nodes          found




                          Receive Page            Page          Receive page
                            Request           Downlink/Uplink   response
                                                  Nodes



                 One way interaction

                 Two way interaction



                          Figure 11: Module interaction and its functions




3.6 Packet structure

The paging request will be a special packet. We are using a character string to
represent our packet. The packet structure as shown in figure 12 is 128 bytes in size.
Its first four bytes are used as the header and the remaining as payload. The first byte
is the version of the protocol. The next byte contains the message type. There are
different message types for specific purposes. Each message types are explained
below.
    0………...                HEADER…         ......................4…...          ……128
                 Message Length          of Reserved              MN_IP     PA_IP
     Version Type           address      to Byte                  address   address to
                            search                                to search reply back

                                   Figure 12: Paging packet header


                                                                                               21
Message numbers and their meanings:

7- Page Request
2- Page successful reply to PA
9- Page successful reply to PA (the PA associated with the page initiator)
3- MN not located in entire Paging area (message to root node)
5- MN not found in entire Paging area (reply to PA associated with the page initiator)
4- Unexpected error

Next in the packet comes the length field, this field contains the length of the IP
address that is being searched. By knowing this length we can easily find out the
remaining part of the payload as it is the only other field which is the next field that
contains the IP address of the PA that is associated with the AR that initiated paging.
This IP address is used by the AR to respond back to the PA of the page successful
message. The packet structure can be increased to include other fields as required by
the protocol requirements.

The packet structure is described below

 Field     Size (byte)                                   Description
Version   1              Protocol Version
Message                  This field holds the data type. There are around 8 message types as
          1
Type                     explained above
Len       1              Indicates the size of the Mobile Node IP address
Reserve 1                Reserved byte for future use
MN_IP     24             This field holds the Mobile Node IP address
PA_IP     128-28         This field holds the IP address of the node that will buffer packets
                                Table 1: Packet description




                                                                                      22
4. Implementation
In this section we will cover the implementation of the paging process. We will show
how the paging functionality works in detail and describe how each elements of the
network interact during the process.

4.1 Test-bed

The implementation platform uses PC-based Access routers and Optional Paging
Agents. Each PC runs Ubuntu 7.10 operating system. Our test-bed used in the
implementation is show in figure 13. The entire paging process is implemented in user
space and uses TCP connections listening on a specific port (4444) for send and
receive operation. Our test-bed uses four PCs serving as access router and two PCs
serving as paging agents and one PC as a Domain Root Router. All these PCs are
connected using 100 Mb/s Ethernet connections.

We will start firstly with the implementation of the paging process by looking at how
we implemented it on our test-bed and then look at the some important functionalities
of the paging process.


                                                           Domain Root Router




                  Paging Agent 1                                            Paging Agent 2

             Optional
             buffering
                                          1




Initiate
Paging
                    AR2                   AR1                      AR4                            AR3
           Prefix:                      Prefix:                    Prefix:                    Prefix:
           2004:db4:8000/48             2004:db4:6000/48           2004:db4:2000/48           2004:db4:4000/48




                                   Figure 13: Paging process




                                                                                             23
4.2 Paging process

Initially the MN is connected to “AR2” and is involved in an active communication
session with a correspondent node, after some time interval it goes in standby state.
The address of the MN while in AR2 will be 2004:db4:8000+Identity IP address.
Now it moves into a new access point “AR4” while remaining in standby state. After
some time the correspondent node starts sending some packets destined for the MN.
The packets will arrive at the AR that last authenticated the MN, which in our case is
AR2. When AR2 tries delivering the packets to the MN, it will fail.

In our implementation the paging module will continuously poll the NC to check the
entry for the MN. Until there is an entry for the MN in the NC with a reachable status
it will be reachable. If it is not reachable the AR will ping the Identity IP address of
the MN and check its NC again. If the node is not available AR2 will trigger the
paging process to its PA (PA1) uplink. PA1 will be responsible to buffer the packets if
the functionality is there and forward the page request to its down-link AR(s), with the
exception from where the request arrived. Now when an AR1 receives a page request
it pages in the air to query the location of the MN that is being searched. We look at
how this is done. The pseudo code that does the search process at the Access Router is
as follows

Receive Page_Request
Extract IP Address from payload and create a command to ping
       Ping the IP Address
       Search neighbour_cache for an entry for the Identity_IP Address
       IF Found
       Mobile_Node Located
       Else
       Node_Not_Found

First it will retrieve the Identity IP address of the MN from the page request packet
and do a ping. The ping will cause the MN to go from standby to active state. After
doing a ping it will check its NC to see if an entry with an available status is
populated. Because the node is not available here in AR1, it will not reply and hence
it will be paged again if the retry timeout timer is set. This is to make sure about the
availability of the MN if in case the node was located and the page successful reply
got delayed. Again if there is no reply the page request will be forwarded uplink and
so on till the MN is located. As the MN is on the other side of the network the page
request will reach the root node and will be forwarded down-link in the network
hierarchy. Finally the AR4 will locate the MN and reply (message 1) to the page
initiator which might have buffered packets for the MN if there are any. It will also
reply to the PA above it so that it doesn‟t need to forward the page request any
further. Once located the MN will have a register with the new AR and configure a
new IP address based on the network prefix. The new address will be
2004:db4:2000+Identity IP address. Here the prefix 2004:db4:200 is the Locator part
of the IP address. As said earlier the locator IP address will not be associated with the
transport layer sockets, instead the Identity IP address is linked to the sockets. Hence
the communication sessions are not broken when a MN changes point of attachments.


                                                                                      24
Table 2 shows the various functions that execute on different modules and describes
the functions that they provide.

   Module          Function                                Description
   Location
   Access          int search_MN(char *buffer)             This function searches for the MN
   Routers                                                 by paging in the air. It returns 0
                                                           on success and 1 otherwise

                                                           This function is called by the
                   int exec_command()                      search_MN function to execute
                                                           the commands to ping and check
                                                           neighbour cache. It returns 1 on
                                                           success and 0 otherwise

                   void                                    This function sends a page
                   reply_pageinitiator(char                successful reply to the page
                   *buf)                                   initiator
   Access                                                  This function is called from main
   Routers         void test_command_main()                to execute the commands to ping
   (paging                                                 and check neighbour cache. It
   module that                                             returns 1 on success and 0
   will initiate                                           otherwise
   paging)
                   void initPaging()                       This function will be called to
                                                           initiate a page request if the ping
                                                           fails

   Paging          void page_timeout(void *arg)            This is a thread and will be
   Agents                                                  created when a page request is
                                                           received.

                   void page_uplink(char *buf,             This function will be called to
                   char *srcIP)                            page uplink nodes if the MN is
                                                           not located.

                   int pager(int sds[],char                This function will be called by
                   *buf, int n)                            page_timeout()to send a page
                                                           request to downlink nodes and
                                                           wait for reply
   Domain          void page_downlink(char *IP,            This function will be called to
   Root Router     char *buf)                              sends paging request to downlink
                                                           nodes

                   void node_not_found(char                This function will be called to
                   *buf)                                   send reply to page initiator that
                                                           the node was not found in the
                                                           network


                              Table 2: Modules and their functions




                                                                                                 25
4.3 Paging agents

When the codes are executed on the paging agents and the root router, the first thing
they do is read a file of IP addresses of uplink and downlink nodes and store them in
an array. Now when a page request is received, it starts a thread which pages its
connected nodes except the one on which the request arrived. We use the array of IP
addresses to page the peer nodes and before paging we check it against the IP address
from where the request arrived so that it doesn‟t page that node back. We use non
blocking sockets when we page the downlink routers because when there is no MN
the AR doesn‟t reply which means it would block the program on the receive
operation. The select() function makes sure that the program doesn‟t block and it
returns a ready socket whenever there is any. The following is the code for select

if((select_results=select(fdmax+1, &lreadfds, NULL, NULL, &tv))== -1)

Here fdmax will hold the highest set of file descriptor and lreadfds is a set that will
hold all file descriptors in the set. The root node has the similar functionality like the
PA(s) but with a slight difference because it is the root node. If the node is not found
in the entire paging area the root node is responsible to reply back to the PA that
might have buffered the packets for the MN.

4.4 Retry timeout

We tried the paging process with different scenarios. First we tried it using a retry
timeout, in this case if the PA does not receive a reply after a fixed time interval (150
ms) it will page the downlink nodes again. This functionality can be used if a network
is congested and there is a possibility of the page successful reply to get delayed.
Then we did a test where we page only once and wait for 150ms to get a reply back.
This way the paging process was tried with many different variants and all the
possibilities were evaluated to get a picture how the paging latency is affected. We
will talk more about the evaluation in section 6.

The timer functionality to wait for a certain time was implemented in the select()
function itself which already had a parameter to mention the time that we want to
monitor the sockets for an incoming reply. The select() function is shown below

select(fdmax+1, &lreadfds, NULL, NULL, &tv))== -1)

Here &tv is the parameter where the time is mentioned, tv is a structure variable
which has the option to mention the time in seconds and micro seconds. The function
waits for the specified time and monitors the set of file descriptors (sockets) &lreadfds
to see if there is any ready socket. The value of &tv can be changed to suit the needs
of the network.




                                                                                       26
5. Testing

In this chapter, we will briefly go through the testing phase of the paging system. We
will discuss few methods that were employed to test the Paging system and see how
all the modules were made to fully function with each other.

5.1 Incremental and integration testing

The paging system was developed and tested in incremental stages and at the same
time codes segments developed separately were integrated together and tested. First
we will look at the incremental testing phase. We started the testing of the paging
process using three nodes of the topology. We started with two AR(s) and a PA. The
functionalities at the Access router module were tested. Then by sending some
dummy page request the Paging Agent module was tested. Once the modules were
functioning the paging process was then tested by including multiple AR(s) and PA(s)
to see the scalability effect in the communication process. Initially we simply used an
array of string to perform a search for an IP address that we were sending in the
payload of the paging request message. Once this part of the code was running
successfully, the code complexity was increased to add more functionality. The
paging module was tested to see if it is able to detect the MN(s) unavailability and
initiate a page request automatically. On the other hand the code to search for the MN
(using a ping) when it enters in a new network was tested at the AR(s). This way step
by step all the modules were integrated together to build up the entire paging system.

5.2 System testing

Many logical errors were encountered during the execution of the code at every stage.
The serious ones occurred when using pointers. While using pointers the common
mistake was accessing memory locations which are not allowed. This brings a
message saying “segmentation fault, core dumped”. It was hard to trace the problem
down as it does not inform where the actual error is and hence each line of code was
tested step by step to locate the error.

Once all the modules were checked for logical errors and reliability the entire test-bed
was configured and the nodes in the topology were made to communicate with each
other. The first step was then to test if a page request is able to propagate successfully.
We set up a dummy page request which had a character string in the payload to
search. Doing this helped us to track any possible logical errors that might occur
during the actual paging process. We came across some problems when the retry
timeout timer was used to page twice. This part of the functionality enabled us to spot
certain problems which were crucial to the paging latency. Then we tested the system
with all possible locations of the MN when it is located successfully. Finally when
everything was in its place the code was evaluated.




                                                                                        27
6. Evaluation

In this chapter we will evaluate the Paging Architecture in terms of qualitative and
quantitative aspects. We start with quantitative evaluation first.

6.1 Quantitative evaluation

We will evaluate the paging protocol in terms of latency because it is the vital
parameter for a mobility protocol to function efficiently. There are many factors to be
considered when evaluating paging latency. For example what happens when the retry
timeout timer is used to page twice, what if the time to wait for a reply is not adequate
and finally what if the network is congested and a paging reply is delayed? All these
factors can affect the paging latency. We will evaluate the paging latency for all
different possibilities that can arise when a node is roaming in the network. We also
timed the latency where the node is not found in the entire network. Around 25 pages
for each possibility were done.

6.1.1 Paging latency (No retry timeout)
We will start with the paging process that has no retry timeout interval and waits for
150 ms for a reply. Meaning that the PA pages only pages once and after waiting for
150 ms if there is no reply from its down-link AR(s) it assumes that the node was not
found and forwards the paging request further in the network. We used 150ms to test
for the ideal situation in which we can get a reply back. For reference point
considering the figure 13 where the paging request was initiated from AR2 whilst the
node was located at all other locations. Figure 14 shows the latency for a successful
page when the MN was located in all different locations of the network. It also shows
the latency where the node was not found (“not_located” in the graph) in the paging
area.


                                   Latency without retry timeout

                  350

                  300

                  250
                                                                                      AR1
      Time (ms)




                  200                                                                 AR3

                  150                                                                 AR4
                                                                                      not_located
                  100

                  50

                   0
                        1   3     5   7    9   11 13 15 17 19 21 23 25
                                            No. of page s


                                Figure 14: Paging latencies for different locations




                                                                                                    28
AR1 is the closest and hence it takes the least time to locate a node there as compared
to the other two locations AR3 and AR4. It can be seen that the closer the node to the
page initiator the less time it takes to locate it. When there is no node found we can
see that it takes the maximum time for a reply, this is because the whole network is
queried and the waiting time at the PA(s) is consumed. Figure 15 shows the average
latency figures for all locations. Therefore we can say that the paging latency is
proportional to the distance of the MN in the network hierarchy. This is because of the
waiting time at each PA.


                                            Avg Latency

                  350

                  300

                  250
      Time (ms)




                  200

                  150

                  100

                  50

                   0
                             AR1                AR3                AR4            not_located
                                                 Node 's Location


                        Figure 15: Average paging latencies for different locations



6.1.2 Impact of a retry timeout
Here we examine the paging process with a retry timeout interval of 150 ms. The
PA(s) after paging its downlink nodes for 150 ms, if no reply is received, it will
attempt another page request. This was to show that, when there is congestion in the
network the page response can get delayed and hence by paging again we confirm the
MN‟s availability. Figure 16 shows the latency when a retry timeout is used to page
twice. The waiting time at the PA doubles when the node is not found by the AR(s)
because it pages twice and waits for 150 ms each time. Also as the paging request
propagates further the latency adds up at each PA if the node is not found. Therefore
we notice that the latency doubles as compared to the previous case where no retry
timeout is used. It is worth noting that the latency remains the same when the node is
located by AR1 because it is the first AR to be queried and at the first page request
itself it will reply and the PA don‟t need to wait. But when a node is located away
from the page initiator the latency adds up, this is because of the time consumed by
the PA(s) due to retry timeout.




                                                                                                29
                                  Latency with retry timeout

                700

                600

                500
                                                                                     AR1
    Time (ms)




                400                                                                  AR3
                300                                                                  AR4
                                                                                     not_located
                200

                100

                 0
                      1   3   5     7   9   11 13 15 17 19 21 23 25
                                        No. of Page s



                          Figure 16: Paging latencies with retry timeout interval




The Average latency for all different locations is shown in figure 17 when a retry
timeout is used. Compared to the previous case where no retry timeout is used we can
see the average latency nearly doubles. Thus the decision can be very crucial when
deciding whether to use a retry timeout or not.

                                             Avg Latency

                700

                600

                500
    Time (ms)




                400

                300

                200

                100

                  0
                              AR1               AR3               AR4               not_located
                                                 Node 's Location




                                                                                                   30
                     Figure 17: Average paging latencies with retry timeout interval




6.1.3 Impact of a longer timeout interval
The timeout interval was increased to one second to test what happens in worst case
scenario when there is congestion in the network and the reply message gets delayed
by one second. As it is obvious, we noticed the paging process takes less time when
the MN is located close to the page initiator, i.e. in AR1. Figure 18 shows the paging
latencies for all different locations. The latency is in order of seconds which is too
high as compared to the case where the timeout is in ms in our previous tests.
Comparing latency for AR3 and AR4 network we notice that the average time taken is
nearly same because both the locations are on the other side of the network and under
the same PA. When the node is not located the latency is the most because of the retry
timeout at each PA.



                                        Long timeout interval

                 5.500
                 5.000
                 4.500
                 4.000
                 3.500                                                                 AR1
      Time (s)




                 3.000                                                                 AR3
                 2.500                                                                 AR4
                 2.000                                                                 not_located
                 1.500
                 1.000
                 0.500
                 0.000
                         1   3     5   7   9 11 13 15 17 19 21 23 25
                                           No. of page s



                                 Figure 18: Paging latencies with long timeout




Then we have figure 19 showing the latency between AR1 and AR3, the two locations
are far from each other so we can see a clear difference in time that it takes to locate a
node. This is because the PA pages the AR(s) twice and waits for a one second each
time before forwarding the page request further. This will happen until the MN will be
found and finally the page request reaches the root node and then propagates
downlink to the other side of the network.




                                                                                                     31
                             Latency, Comparing AR1 Vs AR3

                 5.500
                 5.000
                 4.500
                 4.000
                 3.500
      Time (s)




                 3.000                                                         AR1
                 2.500                                                         AR3
                 2.000
                 1.500
                 1.000
                 0.500
                 0.000
                         1   3   5   7    9    11 13 15 17 19 21 23 25
                                              No. of page s




                                     Figure 19: Comparing latency

Thus from the above tests again we can say that the larger the paging area the more
the latency. But as we said in the design section that the user sends an update in
standby state only when they cross a paging area, this helps us to reduce the number
of update messages in the network. So we can see that there is a trade-off between
latency and number of updates when considering the paging area size.


 6.1.4 Impact of extreme data load
We now consider the impact on the paging latency when the network has to handle a
high data load. The retry timeout interval was the same like in the previous case. Here
we generated data traffic using iperf and mgen. We tried to mimic real time data
traffic on the network by creating VoIP traffic (UDP) using mgen and file transfer
traffic (TCP) using iperf which used bi-directional traffic. The commands that were
used for mgen and iperf are as follows.

MGEN Script
0.0 ON 1 UDP DST 2004:db4:3000::3000/7777 SRC 7030 BURST [RANDOM 10.0
PERIODIC [8.0 1024] EXP 4.0]

Iperf Command
iperf -c 2004:db4:3000::3000 -V -w 512 -n 65536 -i 1 -t 3600 –d –p 3333

We started with around 10 mgen connections which were sending traffic from each
AR to the root node. And the root node was sending the same traffic in the opposite


                                                                                     32
direction. These represented VoIP traffic. At the same time each AR was running
iperf which used TCP bi-directional traffic to represent web browsing data which is
the most of the traffic in today‟s internet core. We found that when the traffic on the
links was not using up the entire link capacity (< 100Mbps) the paging latency was
not affected. But when the traffic was loaded to its extremes where the links capacity
was fully used up (100Mbps) the paging latency was highly affected. To load more
traffic more TCP connections and VoIP data traffic was increased. Around 150
connections in total were sending VoIP traffic to all the four AR(s), and 6-7 more
TCP connections were started on each AR to send more data to the root node. In
figure 20 below we show the paging latencies of all possibilities in the network. We
notice an increase in latency by an order of 4-6 seconds as compared to that where
there is no traffic or enough traffic in the network. This is because of the CPU on the
router using up the resources. Table 3 below shows the average latencies with and
without traffic for all different possibilities. The numbers shows that additional
processing power reduces the paging latency significantly than the average latencies.


                                  Latency with Traffic load
                                                                                   >100Mbps
                 14.000

                 12.000

                 10.000
                                                                                    AR1
      Time (s)




                  8.000                                                             AR3

                  6.000                                                             AR4
                                                                                    not_located
                  4.000

                  2.000

                  0.000
                          1   4      7     10    13    16     19   22      25
                                           No of page s




                                  Figure 20: Latencies with traffic load




                      Avg Latency (s) AR1 AR3 AR4 Not_located
                      With traffic    1.088 6.511 6.089 8.378

                      Without traffic        0.340    2.824   2.438        4.487




                                         Table 3: Average latencies




                                                                                                  33
6.2 Qualitative Evaluation

Here we look at some qualitative evaluations. We will see how the paging system is
able to function if it is scaled. The impacts of different paging algorithms will be
analysed and finally we will evaluate how reliable the system is in case of failures of
various network components.

6.2.1 Impact of scaling
As we have seen in our tests in quantitative evaluation that scaling the network can
impact the paging latency. To reduce the paging latency, one solution would be to
divide the network into appropriate paging area sizes. The paging area size should be
decided keeping the maximum distance between two AR(s) that can be tolerated
during paging. Doing so can help us to confine the paging request in a specific paging
area and hence the latency. If the paging area size is chosen carefully then the paging
latency can be assured to be a finite amount of time for a paging area and this way the
network can be scaled to include clusters of paging areas. But again increasing the
number of paging areas means the MN will have to register frequently as it changes
paging area. So there is a trade-off here between latency and paging areas. Another
issue to consider during scaling is how much a paging request is allowed to propagate
in the network because, we don‟t want the page to travel long distances and flood the
network unnecessarily. One solution can be to include a TTL field in the paging
request so that the paging request will only propagate that finite amount of hops.
Including a TTL will not only reduce paging latency when a network is scaled but
also confine the paging request to a certain limit in the network.

6.2.2 Impact of varying paging algorithm
There can be a significant impact on the paging architecture depending on the paging
algorithm used. In our paging architecture we used a retry timeout interval of 150 ms
after which another page request is made again. If the response to the initial page
request gets delayed due to queuing and processing at different nodes in the hierarchy
it could lead to an unnecessary retry page request. Thus high number of page retries
due to low retry timeout interval affects the paging latency and processing load at the
PA(s). If the paging retry timeout interval is increased there can be a decrease in the
overall paging latency up-to certain extent. There is a cut-off point where the latency
increases after that because the timeout interval will be doubled at each PA if a node
is not found. So fine-tuning the waiting time would depend on the network
administrators

We also evaluated the paging process where there is no retry timeout timer. During
that we noticed the latency to be very low which is good in terms of how long the
paging process takes. But if the page reply does not arrive in time, the page request
will unnecessarily propagate further in the network. We then need a mechanism to
control the page request to stop it propagating as soon as the node is located. Another
option can be to wait for enough time for a response after paging so that no page
response is delayed. And because we are using TCP connections we could rely on the
reliability features that TCP offers and ensure that a page response will never be lost



                                                                                    34
in transit. Again this can be a topic of debate where it will be up-to the administrator
to decide whether to retry a page or not.


6.2.3 Handoff
In mobile networks that supports paging users will be moving speedily from one
access point to other. When a user is in active state and moves to a new AR, the user
will register with the new AR and a new path will be set up routing packets. This
process of transferring the routing path from one AR to other is known as handoff.
During the handoff process there can be a slight delay experienced by the user and
hence packet loss too. This delay is known as handoff delay. To keep packet loss at its
minimum the network has to make sure that both the old and new AR(s) downlink
routes are valid and both are delivering packets until the MN performs a completes
handoff with the new AR. During the handoff the MN will first send an update
message to the new AR and still keep receiving packets from the old AR. When it is
listening to the old AR the new route can be set up at the new AR. Once this new
route is set up the host can perform a normal handoff. The delay where the MN is
waiting for the new route to be set up at the new AR is crucial. This is the delay
period during which the packets will be delivered to the old AR and are lost. Real
time applications like VoIP are sensitive to packet loss. For these applications, the
number of lost packets characterizes handoff performance [11]. Whereas applications
that use TCP has end-to-end flow control to manage transmission loss or errors. Thus
here also handoff delay can be a trade-off with packet loss which needs to deal with
carefully while supporting handoff in IP Paging.




6.2.4 Reliability
We now look at some reliability issues that can arise in our IP Paging protocol. We
consider the impact of failure of different network components. The figure 21 shows
our network model with various failure components. The failure of the gateway/root
node (case 1) in the network hierarchy can result in the MN(s) being unreachable.
This issue can be handled by having redundant gateways through which the network
is made reachable. Another failure point in the network can be the AR(s) (case 2). If a
mobile node has moved from its previous location (AR2) and we assume AR2 has
failed operating. Now when packets will arrive for the MN at the AR2 it will be in-
operable and hence paging cannot be initiated for the MN that is at some new
location. This causes the MN to be unreachable indefinitely even though there is an
end-to-end path to the MN.




                                                                                     35
                                                    Root Node


                                                  Case 1



                               PA 1                     PA 2



Case 2
                      Case 3


          AR2                  AR1                AR4                   AR3




                         Figure 21: Network components failure

To address issue the paging can be initiated by a different AR if the AR(s) are made
robust enough through redundancy. But this would also mean to have some code to let
another AR take the initiative of paging when the other is not working. But doing this
would certainly increase the code complexity and performance of the AR(s) which we
don‟t want.

Another failure component can be the link that connects the AR(s) and the PA(s) or
the PA(s) itself. To overcome this issue the AR(s) should be connected to more than
one PA uplink. This is shown in the above in figure 21 (green lines); here AR2 and
AR3 are connected to the other PA(s). Now if the link between AR2 and PA1 fails
(case 3), the intra-link protocols will take care of configuring a new path which will
be from AR2 and PA2.




                                                                                   36
7. Conclusion

Here we will conclude our work by reviewing the aims that we set initially. Then we
will look into some future work to be done and finally some challenges faced during
the course of the project. We start with the review of our aims

7.1 Review of aims

In this project we looked at new ways of IP addressing system and how it benefits to
current issues in mobility and multihoming. We also saw how today‟s cellular
networks are using location management of mobile devices using paging as an
integral part of their service. We then presented the concept of paging as an IP
service. Paging service will help the future IP mobility protocols to maintain efficient
location management and eliminate the signalling overhead in the core network. It
would also allow the mobile terminals to optimize battery performance. Mover paging
already exists in today‟s cellular mobile telecommunications and hence takes the
advantage of those features when it is commonly deployed. We proposed a paging
protocol that can work with the Identity/Locator split IP addressing system. This way
of addressing will help eliminate tunnelling and hence the overhead incurred with it.
We also gave detailed explanation about the protocol and evaluated the protocol for
qualitative and quantitative studies. We saw how the paging latency is affected with
the increase in paging area size. The impact of a retry timeout also increases the
latency quite significantly. There can be a debate on what parameters to use for an
ideal paging system but finally we can say that it will be upon the network
administrators decide to decide what suits best to their networks. There is a flurry of
work being done in the area of IP Paging and we believe a highly efficient paging
system will be a great benefit to the future of IP Mobility Protocols.


7.2 Future work

There is future work to be done on the IP Paging architecture that we implemented
here. One of them is the buffering of packets at the PA. This is important because
certain applications like VoIP, video conferencing are very sensitive to data loss and
the future mobile internet framework will support quality of service (QoS). Security is
another aspect which can be a vital part of a mobility protocol. When a MN moves to
a new location we don‟t have something to say that which node is the correct node
when registering it to a new location. This can be addressed by some authentication
process which would authenticate the MN after it moves to a new location and wants
to start a new communication. The problems that we highlighted in the reliability
section previously could also be looked into in order to ensure the proper functioning
of the system. A system which would fail to respond to a failure can cause total
unreachability of MN(s). Another aspect when considering reliability is resiliency.
Redundancy of links and nodes in the network hierarchy could make a system
converge and increase the reliability. Also worth mentioning is the paging algorithm
choice. A choice between using a retry timeout timer and waiting for long enough for
a reply message is important. An optimum waiting time needs to be decided so as to
make sure no messages get delayed and cause the paging system to execute



                                                                                     37
incorrectly. If the use of retry timer is used it could be possible that some extra bit of
code is needed to only use it if necessary, i.e. depending on the link bandwidth the
system should be able to decide whether to use a retry time. If the links are congested
and the paging messages are getting delayed, it could be a good idea to use a retry
timeout timer. All these and other issues if handled properly could make the mobile
internet framework support scalable, flexible and robust mobility.


7.3 Challenges

During the course of the entire project there were many challenges faced. The first
and foremost step was to start using Linux platform for the implementation of the
project. Linux was quite a new platform to start with and to get all the compatible
software tools needed for the project was something to learn. We got a feel of how
different Linux is compared to other platforms in terms of flexibility and what are its
major applications in networking. The book used for understanding Linux is as
follows:
Book: Michael K. Johnson, Erik W. Troan, Linux Application Development,
ISBN:0-201-30821-5

 The next step was to get used to IPv6 because the entire project was based on IPv6
test-bed. Learning how IPv6 functions in terms of addressing and other functionalities
was a good experience as it is going to be the next protocol to be used in the internet.
It has also created a strong knowledge base. The configuration of the topology was
also done on IPv6 which gave me a good understanding of how routing and
addressing works in IPv6. The configuration commands and other IPv6 information
were retrieved from the following source:
Online: IPv6, http://www.ipv6.org/
Online: 6net, http://www.6net.org/
Book: Martin Dunmore, 6net, An IPv6 Deployment Guide, The 6NET Consortium,
September 2005

Then the most important challenge was learning a new C programming language to
write source code. C programming was not too familiar and hence it made me go
through a whole learning curve. Not only the basic programming but using pointers
and sockets programming tested the limits and it was interesting to see at the end how
I got used to the language. For C programming the material that was used is as
follows.
Book: Bradley L. Jones and Peter Aitken, SAMS Teach Yourself C in 21 Days, sixth
edition, ISBN:0-672-32448-2.
Online: Beej's Guide to Network Programming, Using Internet Sockets,
http://beej.us/guide/bgnet/




                                                                                       38
8. References
[1] Gunasekaran V, Harmantzis F, 2008, Towards a Wi-Fi ecosystem: Technology
    integration and emerging service models

[2] Ramjee R, Li L, Porta T, Kasera S, 2002, IP Paging Service for Mobile Hosts

[3] Vehmersalo E, 2004, Mobility and Multihoming Solutions with Host Identity
    Layer -Introduction and Comparison

[4] P´erez-Costa X, Torrent-Moreno M, Hartenstein H, A Performance Comparison of
    Mobile IPv6, Hierarchical Mobile IPv6, Fast Handovers for Mobile IPv6 and their
    Combination

[5] Nikander P, Ylitalo J, Wall J, Integrating Security, Mobility, and Multi-homing in
    a HIP Way

[6] Kunishi M, Ishiyama M, Uehara K, Esaki H, Teraoka F, LIN6: A New Approach
    to Mobility Support in IPv6

[7] Dell M, Internet-Draft 1996, 8+8 - An Alternate Addressing Architecture for IPv6
    [online],     Available:     http://ietfreport.isoc.org/all-ids/draft-odell-8+8-00.txt
    [Accessed 01 May 2008], work in progress.

[8] Dell M, Internet-Draft 1997, GSE - An Alternate Addressing Architecture for IPv6
    [online], Available: http://ietfreport.isoc.org/all-ids/draft-ietf-ipngwg-gseaddr-
    00.txt [Accessed 01 May 2008], work in progress.

[9] Narten T, Nordmark E, Simpson W, 1998, Network Working Group, Request for
    Comments: 2461 [online], Available: http://www.ietf.org/rfc/rfc2461.txt
    [Accessed 13 July 2008]

[10] Valkó A, Cellular IP: A New Approach to Internet Host Mobility

[11] Valkó A, Gomez J, Kim S, Campbell A, On the analysis of Cellular IP Access
     Networks
[12] Campbell A, Castellanos J, IP Micro-Mobility Protocols




                                                                                       39
9. Appendix:
Network configuration commands


9.1 Access router 1

 Copying radvd.conf file
sudo cp /home/nikul/Desktop/radvd.conf /etc/radvd.conf

 Destroying wireless interface
sudo wlanconfig ath0 destroy
sudo wlanconfig ath0 create wlandev wifi0 wlanmode ap
sudo iwconfig ath0 essid nik
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling wireless interface
sudo ifconfig ath0 up
sudo iwconfig ath0 essid pim
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

 Starting router advertisement
sudo /etc/init.d/radvd start
or
sudo radvd

 Adding routes in routing table
sudo route -A inet6 add ::/0 gw fe80::20d:61ff:fe91:5492 dev eth0
sudo route -A inet6 add 2004:db4:6000::/64 dev ath0
sudo ip -6 addr add 2004:db4:6000::6000/64 dev ath0



9.2 Access router 2

 Copying radvd.conf file
sudo cp /home/nikul/Desktop/radvd.conf /etc/radvd.conf

 Destroying wireless interface
sudo wlanconfig ath0 destroy
sudo wlanconfig ath0 create wlandev wifi0 wlanmode ap
sudo iwconfig ath0 essid nik
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling wireless interface
sudo ifconfig ath0 up



                                                                    40
sudo iwconfig ath0 essid nik
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

 Starting router advertisement
sudo /etc/init.d/radvd start
or
sudo radvd

 Adding routes in routing table
sudo route -A inet6 add ::/0 gw fe80::21c:f0ff:fefa:2d19 dev eth0
sudo route -A inet6 add 2004:db4:8000::/64 dev ath0
sudo ip -6 addr add 2004:db4:8000::8000/64 dev ath0


9.3 Access router 3

 Copying radvd.conf file
sudo cp /home/nikul/Desktop/radvd.conf /etc/radvd.conf

 Destroying wireless interface
sudo wlanconfig ath0 destroy
sudo wlanconfig ath0 create wlandev wifi0 wlanmode ap
sudo iwconfig ath0 essid nik
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling wireless interface
sudo ifconfig ath0 up
sudo iwconfig ath0 essid chris
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

 Starting router advertisement
sudo /etc/init.d/radvd start
or
sudo radvd

 Adding routes in routing table
sudo route -A inet6 add ::/0 gw fe80::209:5bff:fe62:7f3b dev eth0
sudo route -A inet6 add 2004:db4:4000::/64 dev ath0
sudo ip -6 addr add 2004:db4:4000::4000/64 dev ath0




                                                                    41
9.4 Access router 4

 Copying radvd.conf file
sudo cp /home/nikul/Desktop/radvd.conf /etc/radvd.conf

 Destroying wireless interface
sudo wlanconfig ath0 destroy
sudo wlanconfig ath0 create wlandev wifi0 wlanmode ap
sudo iwconfig ath0 essid nik
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling wireless interface
sudo ifconfig ath0 up
sudo iwconfig ath0 essid martin
sudo ifconfig ath0 192.200.100.101 netmask 255.255.255.0

 Enabling forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

 Starting router advertisement
sudo /etc/init.d/radvd start
or
sudo radvd

 Adding routes in routing table
sudo route -A inet6 add ::/0 gw fe80::209:5bff:fe61:1bf8 dev eth3
sudo route -A inet6 add 2004:db4:2000::/64 dev ath0
sudo ip -6 addr add 2004:db4:2000::2000/64 dev ath0


9.5 Paging agent 1

   Adding routes in routing table

sudo ip -6 route add 2004:db4:6000::/48 via fe80::21c:25ff:fe4e:f659 dev eth0
sudo ip -6 route add 2004:db4:8000::/48 via fe80::21b:21ff:fe1d:8a38 dev eth1
sudo ip -6 route add 2004:db4:3000::/48 via fe80::21b:21ff:fe1d:8b19 dev eth2
sudo ip -6 addr add 2004:db4:5000::5000/64 dev eth0
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo ip -6 route add 2004:db4:7000::/48 via fe80::21b:21ff:fe1d:8b19 dev eth2
sudo route -A inet6 add ::/0 gw fe80::21b:21ff:fe1d:8b19 dev eth2




                                                                                42
9.6 Paging agent 2

   Adding routes in routing table

sudo ip -6 route add 2004:db4:3000::/48 via fe80::21b:21ff:fe1d:8b40 dev eth0
sudo ip -6 route add 2004:db4:4000::/48 via fe80::2a0:24ff:feb8:137 dev eth1
sudo ip -6 route add 2004:db4:2000::/48 via fe80::260:97ff:fea1:3a38 dev eth2
sudo ip -6 route add 2004:db4:5000::/48 via fe80::21b:21ff:fe1d:8b40 dev eth0
sudo ip -6 addr add 2004:db4:7000::7000/64 dev eth0
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo route -A inet6 add ::/0 gw fe80::21b:21ff:fe1d:8b40 dev eth0




9.7 Domain root router

   Adding routes in routing table

sudo ip -6 route add 2004:db4:5000::/48 via fe80::210:5aff:fe30:5de6 dev eth2
sudo ip -6 route add 2004:db4:7000::/48 via fe80::201:2ff:fea6:9bf1 dev eth3
sudo ip -6 route add 2004:db4:4000::/48 via fe80::201:2ff:fea6:9bf1 dev eth3
sudo ip -6 route add 2004:db4:2000::/48 via fe80::201:2ff:fea6:9bf1 dev eth3
sudo ip -6 route add 2004:db4:8000::/48 via fe80::210:5aff:fe30:5de6 dev eth2
sudo ip -6 route add 2004:db4:6000::/48 via fe80::210:5aff:fe30:5de6 dev eth2
sudo ip -6 addr add 2004:db4:3000::3000/64 dev eth2
sudo sysctl -w net.ipv6.conf.all.forwarding=1




                                                                                43
10. Project Proposal

                     Enhanced Internet Mobility using
                      Wireless Routers and paging



Abstract

The internet is going mobile. Currently the IP addressing scheme overloads the
semantics of an IP address. In both versions IPv4 and IPv6, an IP address tells us 2
things: the end-point interface in a network and the location for routing in the network
level. Mobile IP provides a solution for mobility but, it has many shortcomings on a
global scale. Also Existing mobility approaches are not well integrated into the rest of
the Internet architecture, instead primarily being separate extensions that at present
are not widely deployed [1]. Here we propose the concept of decoupling the semantics
of an IP address. One Identity IP address is associated with a Locator IP address
which tells us where a Mobile Node (MN) is at any given point in time. A Mapping
Agent keeps the mapping of identity and the locator address. A mobile device
authenticates and registers with devices called Radio Routers as it travels in foreign
networks and then updates the Mapping Agent.

A special case arises when a MN changes networks while it is idle, due to battery
constraints it is allowed only to wake up when it needs to. Now packets destined for
that MN will arrive at the old radio router that previously authenticated the MN. The
old radio router can now „page‟ other radio routers to locate the MN‟s current
location. This process is known as IP Paging. The aim of this project will be to design
and implement a paging infrastructure to support the movement of a MN node and
evaluate the performance of the paging functionality. This will involve two major
phases: firstly, studying the identity/locator split concept, IP Paging and other Paging
systems. Secondly, designing and implementing the system and evaluating the IP
Paging functionalities in terms of performance overhead.



1.     Introduction

The presence of the Internet nowadays is becoming ubiquitous. Technologies like
WiFi, wireless LAN, WiMAX and Wireless Broadband are becoming increasingly
popular. People prefer to stay connected to the internet on the move. “Currently it
looks like that the emergence of ubiquitous computing and ad hoc networks will soon
lead to a situation where the majority of computing hosts are multi-homed and
mobile, and have no static addresses” [2]. When a mobile device moves from one
network to another, it has the keep the same IP address in order to experience
seamless connectivity for running applications. The traditional IP addressing model
overloads the semantics of an IP address. An IP address tells us two things: one, it
identifies a particular interface on an end host and secondly, it tells us the location of
that interface within the Internet routing infrastructure. Currently Mobile IP is used to
provide mobility solution but, it has many problems. New research is looking into


                                                                                       44
decoupling the identity and the location format of a typical IP address and use this as
a basis for an IP mobility solution. This would mean that when a MN moves across
networks its locator address changes, but its identity address remains the same.
Therefore applications can still contact the MN using its identity address while it is
moving, but this is now mapped to its locator address by some Mapping Agent. When
a MN moves into a vicinity of a new network it authenticates with a Radio Router and
then updates the mapping agent.

Mobile devices are highly sensitive to battery usage so a device can be in sleep mode
when it changes location. Instead of expecting the device to wake-up and update its
locator value each time it is preferable to allow the device to sleep and only wake-up
when it needs to. This means the Identity/Locator mapping agent will contain old data
when a CN queries the location of the mobile device and starts sending packets. These
packets will arrive at the last radio router where the mobile device was registered to.
However upon receiving the packets, this radio router can „page‟ other radio routers to
find out the mobile device current location by querying one or more paging agents. A
hierarchy of paging agents and radio routers can provide a network infrastructure to
allow free movement of mobile devices.

The structure of the remainder of this report is as follows: Section 2 discusses the
background of mobile IP and some problems associated with it. Section 3 gives an
overview of the new identity/locator concept and proposes the aims and methodology
that will be used. Section 4 then presents the program of work. Finally Section 5
describes the resources that will be used for the project.



2.     Background


In the current internet architecture an IP address represents both a host‟s identity and
the host‟s topological location. This overloading of the semantics has led to several
security problems, including the so called address ownership problem, making IP
mobility and multi-homing unnecessarily hard from the security point of view [2].
Mobile IP is currently the solution for internet mobility. But it has various problems
associated with it, some of which are elaborated here. The main problem is when a
Home Agent „tunnels‟ traffic to the MN using the care-of-address that is temporarily
associated with the MN. Tunneling causes lots of overhead and bypasses value added
features in the internet fabric like, security in the edge of access routers. Also the
Home Agent can be a single point of failure, causing all the MN‟s that are registered
with it to cease communication.

A MN has a home address which it keeps throughout its journey while roaming in
foreign networks. The problem is that the home address is used to refer to the MN
meaning that, an IP address expressing location is used to refer to a location it actually
does not represent [3]. “This creates an illusion to the transport layer protocols that the
location of the other end-point could be deducted from the available home address.
Therefore transport layer functions like congestion control can go wrong because it
would believe that the static home address actually provides topological information”
[3]. Also the dependence on home address may be difficult when considering future


                                                                                        45
needs of networking, and Mobile IP does not enable the multiple use of care-of-
addresses simultaneously [3]. All these problems show that Mobile IP is not a robust
solution for mobility of hosts. This motivates our research area for an alternative
approach to achieve mobility. Hence we try to avoid all the above problems and
exploit existing techniques like DNS and Paging to achieve mobility in a more
efficient way.



3.    Proposed Research


3.1    Overview: Identity/Locator concept

An identity IP address is used to refer to the MN, whereas a locator IP address tells us
where a MN is at any given point in time. When a MN changes location, applications
can still use the identity IP address to contact the MN but this is now mapped to its
current locator IP address by a Mapping Agent. When a MN changes location it must
first authenticate itself with a radio router and acquire a new address. Thereafter it
updates the mapping agent.

3.2    Paging

When a MN changes location it is allowed to be in sleep mode due to battery
constraints now if this happens, when packets arrive for this MN they will arrive to
the last radio router that the MN was attached because the mapping agent will have
the old identity/locator address. Upon receiving this packet the radio router can page
other radio routers to locate the mobile devices current location by querying one or
more paging agents. Figure 1 shows a hierarchy of radio routers with paging agents
functionalities; the mobile device initially is in paging area A and then moves to
Paging B. Now when a packet arrives for the MN it will go in paging area A to the
router which the MN was previously registered. This radio router will now page its
top level routers (Border Router) to query the location of the MN. Then the Border
router will query the routers in its hierarchy below it and eventually the router which
has the MN will respond and the packets thereafter arriving will arrive at the new
radio routers. In this manner a hierarchy of radio routers and paging agents can
provide seamless connectivity to a roaming mobile device connected to the internet.




                                                                                     46
                                                      Border
                                                      Router




                             Radio                        Radio
                            Routers                      Routers




            Paging                                                      Paging
            Area A                                                      Area B




          Figure 1 Hierarchy of Radio Routers and Paging Agents




3.2       Aims

         To conduct a background research on Identity/Locator split concept
         To conduct research on IP Paging systems
         To design the hierarchical model of radio routers and paging agents
         To design the functionalities in the radio routers and paging agents
         To implement the design in software
         Evaluate the system and measure performance


3.3       Methodology

      The work will be divided into four stages namely: Background Research, Strategy
      & design, Implementation and Evaluation.

      1) The initial stage would be to research on identity/locator split concept and
         existing IP Paging systems.
      2) Based on the research of the first stage, there should be a better understanding
         of what type of system should actually be designed in order to conduct the
         experiment.
      3) Then comes the implementation part, here I would be looking at some
         software engineering strategies before initially starting to implement the actual
         system. After that the program to try out the experiment will be written.
      4) Finally will come the evaluation part where the system will be evaluated under
         different conditions to measure performance.




                                                                                       47
4.       Program of work

4.1      Tasks

      The project is divided into the following tasks:

      [1]. Background Study and Research
           The aim of this task is as follows:
               Understand locator/identity split concept
               Understand how IP Paging systems work
           This task will involve studying the above concepts and deciding which
           approach to use for the experiment. This will last, approximately, 20 days.

      [2]. Designing the IP Paging model
           The aim of this task is to:
                Review several IP Paging systems and designing a system that will
                   serve in carrying out the actual experiments
           This task involves careful consideration of the design model that will be used
           in the evaluation purpose and anticipating problems that might occur. This will
           last 15 days.

      [3]. Implementing the functionalities of Paging agents
           The aim of this task is to program the functionalities of radio routers and
           paging agents and run the demos. This task involves performing the actual
           experiment as outlined in the Methodology. This will last for a month.

      [4]. Evaluation and Analysis
           The aim of this task is to test and analyse the performance of the system.
           Various tests will be carried out and from each test data will be analysed and
           compared. This task will possibly be carried out alongside task 3 and may last
           for 6-7 days.

      [5]. Report Writing
           The aim of the task is to compile both result and observation made from
           conducting the results. This task will be done during the course of the entire
           project.




                                                                                       48
4.2       Schedule




5.        Resources

         Hardware Resources required:
          Radio routers
          Laptops

         Software Resources required:
          Linux platform
          C compiler
          Simulator

         Availability of resources in the department?
          Available




                                                         49
References:

[1] Atkinson R, Bhatti S, Hailes S, 2007A Proposal for Unifying Mobility
    with Multi-Homing, NAT, & Security

[2] Nikander P , Ylitalo J, Wall J, Integrating Security, Mobility, and Multi-homing in
    a HIP            Way

[3] Vehmersalo E, 2004, Mobility and Multihoming Solutions with Host Identity
    Layer -Introduction and Comparison




                                                                                     50
51

								
To top