Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks

STREAMING OVER
MOBILE IPV6 NETWORKS
Master’s Thesis, March 2005
Javier Rodríguez Olalla
Supervisors:
dr. Sándor Imre
László Bokor
István Dudás

Javier Rodríguez Olalla Streaming over Mobile IPv6 networks
2
Table of contents
1. INTRODUCTION............................................................................................................................................. 4
2. IPV6.................................................................................................................................................................... 5
2.1 INTRODUCTION........................................................................................................................................... 5
2.2 MAIN FEATURES OR INNOVATIONS ............................................................................................................. 6
2.3 IPV6 ADDRESSING...................................................................................................................................... 7
2.3.1 Scope ................................................................................................................................................... 8
2.3.2 Unicast address ................................................................................................................................... 8
2.3.2.1 Interface identifier..................................................................................................................... 9
2.3.2.2 The Unspecified Address .......................................................................................................... 9
2.3.2.3 Global unicast address............................................................................................................. 10
2.3.2.4 Link-local unicast address....................................................................................................... 10
2.3.2.5 Site-Local unicast address....................................................................................................... 10
2.3.3 Anycast Address................................................................................................................................. 11
2.3.4 Multicast Address .............................................................................................................................. 12
2.3.5 IPv4 and IPv6 addressing.................................................................................................................. 14
2.4 AUTOCONFIGURATION.............................................................................................................................. 14
2.4.1 Introduction ....................................................................................................................................... 14
2.4.2 Stateless autoconfiguration................................................................................................................ 15
2.4.3 Stateful autoconfiguration ................................................................................................................. 15
2.5 NEIGHBOR DISCOVERY............................................................................................................................. 15
3. MOBILE IPV6................................................................................................................................................. 17
3.1 INTRODUCTION......................................................................................................................................... 17
3.2 STATE OF THE ART.................................................................................................................................... 17
3.3 THE IP MOBILITY PROBLEM ...................................................................................................................... 18
3.4 BASIC OPERATION OF MOBILE IPV6........................................................................................................... 19
3.5 ADDITIONAL HEADERS ............................................................................................................................. 21
3.6 DYNAMIC HOME AGENT ADDRESS DISCOVERY........................................................................................... 22
4. MOBILE IPV4 PROTOCOLS....................................................................................................................... 24
4.1 INTRODUCTION......................................................................................................................................... 24
4.2 MOBILE IPV4 ........................................................................................................................................... 24
4.3 HMIPV6 .................................................................................................................................................. 26
4.4 CELLULAR IP ........................................................................................................................................... 27
4.5 HAWAII ................................................................................................................................................. 28
5. IP MULTICASTING ...................................................................................................................................... 31
5.1 INTRODUCTION......................................................................................................................................... 31
5.2 MULTICAST AND UNICAST ........................................................................................................................ 31
5.3 MULTICAST TRAFFIC MANAGEMENT: MLD............................................................................................... 32

3
6. TESTBED COMPONENTS AND CONFIGURATION .............................................................................. 35
6.1 INTRODUCTION......................................................................................................................................... 35
6.2 THE TESTBED ........................................................................................................................................... 35
6.2.1 Testbed hardware .............................................................................................................................. 36
6.2.2 Testbed logical configuration ............................................................................................................ 37
6.3 SOFTWARE ............................................................................................................................................... 38
6.3.1 MIPL.................................................................................................................................................. 38
6.3.2 MLD Proxy for MIPL ........................................................................................................................ 39
6.3.3 Ethereal ............................................................................................................................................. 40
6.3.4 VLC Player ........................................................................................................................................ 41
6.3.5 Iperf ................................................................................................................................................... 42
7. MOBILITY IN THE TESTBED .................................................................................................................... 43
7.1 INTRODUCTION......................................................................................................................................... 43
7.2 MOBILE IPV6 OPERATION IN THE TESTBED ................................................................................................ 43
8. MULTIMEDIA STREAMING WITHOUT MOBILITY............................................................................ 47
8.1 INTRODUCTION......................................................................................................................................... 47
8.2 MULTIMEDIA STREAMING IN THE HOME NETWORK................................................................................... 47
9. THEORETICAL COMPARISON OF MULTICAST AND UNICAST ..................................................... 55
9.1 INTRODUCTION......................................................................................................................................... 55
9.2 THEORETICAL COMPARISON...................................................................................................................... 55
10. MULTIMEDIA STREAMING WITH MOBILITY .................................................................................... 65
10.1 INTRODUCTION......................................................................................................................................... 65
10.2 UNICAST PLUS MOBILITY .......................................................................................................................... 65
10.3 MULTICASTING TO MOBILE NODES WITH MLD PROXY .............................................................................. 72
11. CONCLUSIONS ............................................................................................................................................. 77
ACKNOWLEDGEMENTS....................................................................................................................................... 79
REFERENCES........................................................................................................................................................... 80
ABBREVIATIONS / GLOSSARY ........................................................................................................................... 81
LIST OF FIGURES ................................................................................................................................................... 82
APPENDIX A. MATLAB SCRIPT OF THE THEORETICAL MODEL............................................................ 84
APPENDIX B. MDL PROXY CONFIGURATION FILE ..................................................................................... 85

4
1. Introduction
In the recent years, there has been an explosion of the mobile communications and
Internet demand. The increasing number of portable computers, combined with the
growth of wireless services, makes supporting Internet mobility important and an
attractive feature in order to provide applications and services to the final users, no
matter where they are situated. The future mobile communications generation will be a
group of different architectures. Therefore, it is necessary to implement the mobility in a
layer or protocol that is able to operate in all the possible architectures and systems.
IP (Internet Protocol) is the most deployed and universal protocol within the networks
and Internet, and because the latter is the global network that connects all places in the
world, it is suitable to make mobility to operate at this layer in order to have a global
standard. That is why Mobile IPv6 was developed, in order to provide Mobility at IP-
level.
In a close future, the concept of roaming will be transferred to a total IP dimension,
where the telephony (fixed and mobile) will be 100% over IP networks. The main
problem to solve is to have enough bandwidth to be able to provide a good quality
service. With the full implementation of the third generation (UMTS, Universal Mobile
Telecommunications System) of mobile communications, there will arise many
applications for the final users that use multimedia streaming, like Television, Radio,
and Video on demand, some of them integrated in web pages. The new version of IP
protocol, IPv6, has a new type of address, multicast address, which allows streamers to
have a more cost-effective transmission towards the final users with a bandwidth
saving, as opposed to the traditional unicast or broadcast used in IPv4.
In this thesis, two main issues are studied: Mobile IPv6 and streaming mechanism over
mobile IPv6 networks. The first part of the thesis is an overview of the theoretical
literature related to IPv6, Mobile IP protocols and multicasting / unicasting methods.
The second part is a summary of the characteristics of the testbed employed in the
laboratory and the experiments done there regarding the two main topics of the thesis.
Finally, some conclusions are displayed after studying the results of the laboratory tests.

5
2. IPv6
2.1 Introduction
IPv6 (initially called “IPng” or Internet Protocol Next Generation) is the new version of
the IP protocol developed by the IETF (Internet Engineering Tasking Force, the main
organization concerned with Internet information transmission standards) at the
beginning of the 90s [1]. The previous version, called IPv4, is the protocol implemented
in most of the computers and networks nowadays.
The future Internet needs security, autentification and privacy mechanisms, and users
need enough capacity to support new multimedia applications (which use more and
more bandwidth) with guaranteed video and audio flow delays.
IPv6 was developed because some different reasons. The most important one is the
increasing number of machines being connected to Internet everyday. In a close future,
the 32 bits used in IPv4 (which means 232
different IPv4 addresses) will not be enough
to index their IP addresses. In IPv6, the number of addresses to be used has been
dramatically increased until 2128
(128 bits per address). This deficit of addresses in IPv4
comes from the original development of the IP protocol in the 70s, when the huge
success of this protocol in many fields, not only scientific or educational, but also in the
daily life was not predicted by its creators. This problem could partially be solved using
address reassignment or NAT (Network Address Translation). The second solution
consists of using one public IP address for the whole network and private IP addresses
inside it. However, with this solution many applications would be constrained to the
Intranets, since many protocols are not capable of going through NAT devices, like Real
Time protocols, IPsec. In addition, there is also a problem that would remain, which is
the great size of the routing tables in the Internet backbone, which leads to an adverse
effect on the response times.
After IPv4 was created, and due to many new applications that use it, it has been
necessary to create “patches”. The most known are some related to the use of Quality of

6
Service (QoS), Security (IPsec) and mobility (Mobile IP). The inconvenient using those
extensions arises when using them simultaneously (because they were designed
independently afterwards).
2.2 Main Features or innovations
The main new characteristics of IPv6 are [1]:
• Expanded addressing capabilities. IPv6 increases the size of the IP address from
32 bits to 128 bits. Solutions designed to solve the lack of addresses, like NAT,
are not necessary now with IPv6. The scalability of multicast routing is improved
by adding a "scope" field to multicast addresses. In addition, a new type of address
called an "anycast address" is defined, used to send a packet to any one of a group
of nodes.
• Flexible and simplified header format: The fixed size of the IPv6 header (40
bytes) and the possible additional headers to place next to it makes possible for the
routers to save processing time and make packet routing more efficient.
• Enhanced support for extensions and options. The changes in the header options
codification make limits less stringent and more flexible to introduce new options
in the future. Moreover, the IP packets are delivered more efficiently because
there is no fragmentation in the routers. Hence, routing is more efficient in the
network backbone and there is an increase in the speed.
• Autoconfiguration. It is a possibility to configure without needing servers. Devices
can configure their own Ipv6 addresses using the information they obtain from the
network router. Moreover, there are reconfiguration facilities.
• Security. In Ipv4, the only way to solve security problems was using SSL to have
transport level security, or using SSH or HTTP to have application level security.
The third solution was IPsec (network level security) but it is not commonly used.
However, in IPv6 is mandatory to use IPsec.
• Quality of Service (QoS) and Class of Service (CoS). Packets from particular
traffic flows can be labelled. Senders can request special treatment for them, like
quality of service or real time service. It is possible to reserve network resources to
multimedia applications with guaranteed bandwidth and delays.

7
• Mobility. More and more, the tendency is to have network connection in every
place and to take advantage of the same functionality regardless of the place where
to connect. It is possible to use multimedia services like voice over IP or video on
demand without interrupting the active connections with protocols like MIP
(Mobile IP) or HMIP (Hierarchical MIP), even when making a network change, as
it will be explained later. Again, they are patches for the IPv4 protocol, but in IPv6
is a mandatory functionality, so every system, which uses IPv6, must implement
it, because it has been included initially with the protocol. This feature will be
very important when UMTS mobile telephone networks start to operate.
• Autentification and privacy capabilities: IPv6 specifies extensions that use
autentification, data integrity and confidentiality.
It is necessary to remark these are basic characteristics. The own structure of the
protocol allows itself to grow and to be scalable, depending on the requirements of the
new applications or services. Scalability is the most important feature of IPv6,
compared with IPv4.
IPv6 is a fundamental ingredient for the vision we have of the Society of Mobile
Information. Nowadays, the number of wireless phone surpasses already fully the
number of fixed terminals of Internet. Presently, IPv6 is outlined as the only viable
architecture that can accommodate the new wave of cellular devices that support
Internet. In addition, IPv6 allows to the supply of services and benefits demanded by
mobile infrastructures (GPRS, General Packet Radio Service, or UMTS), networks of
broadband, electronic of consumption and terminals, and the subsequent
interoperability/management
2.3 IPv6 Addressing
IPv6 addresses are 128 bits identifiers for interfaces and sets of interfaces. There could
be 2128
different addresses.). Multiple addresses can be assigned to the same node
interface. There are three IPv6 address types: Unicast, anycast and multicast address [2].

8
2.3.1 Scope
In IPv6, addresses can have different scopes, global and non-global. The scope is
defined as the area where the address can be used as a unique identifier of one or several
interfaces. The address scope is a part of the address, so it is possible to distinguish
easily. There are three different scopes [2]
• Link-local. It is used to identify interfaces in the same link. These addresses start
with fe80:.
• Site-local. It is used to identify interfaces in the same “site”. The definition of
“site” is a little generic, but in principle a “site” is the topologic area of the
network belonging to an organization building or campus. They start with fec0:.
• Global. It is used to identify interfaces in the whole Internet. They start with 2001:
or 3ffe.
Concerning scope, anycast and unicast addresses use the same rule. However, multicast
addresses can have 14 different scopes, which identify from local interfaces to global
addresses.
2.3.2 Unicast address
It identifies a single interface. A packet sent to a unicast address is delivered only to that
identified interface. It is equal to the current IPv4 addresses. For the communication
within a LAN (Local Area Network), it is enough to use link-local addresses, it is not
necessary to use global scope addresses.
Unicast addresses are aggregatable using CIDR (Class-less Interdomain Routing) like in
Ipv4. IPv6 nodes may do not have any knowledge about the internal structure of the
IPv6 addresses, depending on their task in the network (for example, host or router). At
least, a node considers unicast addresses have no structure. Figure 1 illustrates this case.
Figure 1. Basic unicast address format
128 bits
Node address

9
A more sophisticated host could know the subnet prefix of the link which it is
connected. The situation would be the illustrated in Figure 2:
Figure 2. Unicast address with subnet prefix and interface identifier
Other more sophisticated devices could have more hierarchy network knowledge, its
limits, etc. Hence, “the interface identifier” is used to identify interfaces in a link where
they must be unique. In some cases, these identifiers will be unique in a wider scope. In
general, the interface identifier is equal to the interface’s link-level address. The same
interface identifier can be used by multiple interfaces of the same node, without
affecting their global exclusivity in the IPv6 scope.
2.3.2.1 Interface identifier
Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link.
They are required to be unique within a subnet prefix. It is recommended that the same
interface identifier not be assigned to different nodes on a link. They may also be unique
over a broader scope. In some cases, an interface's identifier will be derived directly
from that interface's link-layer address. The same interface identifier may be used on
multiple interfaces on a single node, as long as they are attached to different subnets.
2.3.2.2 The Unspecified Address
The address “0:0:0:0:0:0:0:0” or “::” is called the unspecified address. It must never be
assigned to any node. It indicates the absence of an address. One example of its use is
in the Source Address field of any IPv6 packets sent by an initializing host before it has
learned its own address.
The unspecified address must not be used as the destination address of IPv6 packets or
in IPv6 Routing Headers. An IPv6 packet with a source address of unspecified must
never be forwarded by an IPv6 router.
n bits 128-n bits
Subnet prefix Interface identifier

10
2.3.2.3 Global unicast address
The general format for IPv6 global unicast addresses can be observed in Figure 3
Figure 3. Global unicast address format
The global routing prefix is a (typically hierarchically structured) value assigned to a
site (a cluster of subnets/links), the subnet identifier is an identifier of a link within the
site, and the interface identifier identifies interfaces on a link
2.3.2.4 Link-local unicast address
They have been designed in order to address one only link to autoconfigure (using
interface identifiers), neighbor discovery or situations where there are no routers.
Therefore, routers cannot retransmit any packet with local source or destination
addresses which are link-local (their scope is limited to the local network). They are
equivalent to the IPv4 APIPA (Automatic Private IP Addressing) private addresses.
Figure 4 shows the general structure of link-local addresses.
Figure 4. Link-local unicast address format
2.3.2.5 Site-Local unicast address
They are designed to allow addressing inside a site or organization, without needing a
global prefix. They are configured using one subnet identifier of 16 bits. Routers must
not retransmit out of the site any packet which source or destination address are site-
local address (its scope is limited to the local network or organization). Figure 5 shows
the general structure of site-local unicast addresses.
n bits m bits 128 -n-m bits
Global routing prefix Subnet identifier Interface identifier
10 bits 54 bits 64 bits
1111111010 0 Interface identifier

11
Figure 5. Site-local unicast address format
Although a subnet identifier may be up to 54-bits long, it is expected that globally
connected sites will use the same subnet identifiers for site-local and global prefixes.
2.3.3 Anycast Address
It identifies a set of interfaces (typically belonging to different nodes). A packet sent to
an anycast address is delivered to any of the interfaces identified with that anycast
address (the “nearest” one, according to the measure of distance of the routing
protocols). When one unicast address is assigned to more than one interface, turning it
into an anycast address, the nodes assigned with that anycast address have to be
explicitly configured to know that it is an anycast address. It allows creating, for
example, redundancy environments where several machines can take care of the same
traffic according to a set sequence, in the case the first machine fails.
The network router must know which interfaces have assigned an anycast address and
their distances, in order the packets to be delivered to the “closest” anycast address.
The anycast addresses use the same space than the unicast addresses, they are not
syntactically distinguishable from unicast addresses. Because the anycast address scope
is the same as the unicast, there are anycast addresses with local, site and global scope.
It is important to know this type of address only can be used as a destination address,
never as a source one. Figure 6 shows the anycast address format.
Figure 6. Anycast address format
10 bits 54 bits 64 bits
1111111011 0 Interface identifier
n bits 128-n bits
Subnet prefix 0000000000000000000000

12
There is one anycast address, required for each subnet, called “subnet router anycast
address”. Its syntax is equal to the prefix that specifies the unicast address
corresponding link and the interface identifier is equal to zero. Every router must be
able to support this address for the networks they are connected. Packets sent to this
anycast address will be sent to one of the corresponding subnet routers.
Anycast addresses are employed in the following applications:
• Communication with the “closest” server.
• Services discovery. When configuring IPv6 in one node, it would not be necessary
to specify it the address of the DNS (Domain Name System) server, proxy, etc...
There would be an anycast address that identifies those services.
• Mobility: Nodes which need to communicate with one router from an available
group in their network.
Until more experience has been gained and solutions are specified, the following
restrictions are imposed on IPv6 anycast addresses:
• An anycast address must not be used as the source address of an IPv6 packet.
• An anycast address must not be assigned to an IPv6 host, that is, it may be
assigned to an IPv6 router only.
2.3.4 Multicast Address
Transmission of unicast streams to more than one receptor is inefficient because the
traffic is being multiplied with redundant information with every new receptor that
receives the same information than the others. With multicast, only one copy of the
information is sent from the server to the network, and this network has the task to
deliver one copy of the data to each client if needed. In IPv4, it is possible to make this,
but in IPv6 it is mandatory.
The multicast address identifies a group of interfaces (typically belonging to different
nodes). A packet sent to a multicast address is delivered to every interface identified by
the multicast address. The mission of this type is to be used in broadcast applications,
like the one concerned in this thesis. Figure 7 shows the multicast address format.

13
8 bits 4 bits 4 bits 112 bits
11111111 flags scope Group identifier
Figure 7. Multicast address format
• The first 8 bits are always set to “1”, this set identifies the address as a multicast
address.
• Flags is a set of 4 bits (000T). The first three bits are reserved and must be
initialized to 0. The fourth bit (T), if it is set to “0”, it indicates a permanently
assigned (“well-know”) multicast address, assigned by the Internet Assigned
Number Authority (IANA). If it is set to “1”, it indicates a non-permanently-
assigned (“transient”) multicast address.
• Scope is a 4-bits multicast scope value used to limit the scope of the multicast
group. Some values of the scope are:
1 interface-local scope
2 link-local scope
4 admin-local scope
5 site-local scope
8 organization-local scope
E global scope
Interface-local scope spans only a single interface on a node, and is useful only for
loopback transmission of multicast. Link-local and site-local multicast scopes span the
same topological regions as the corresponding unicast scopes. Admin-local scope is the
smallest scope that must be administratively configured, i.e., not automatically derived
from physical connectivity or other, non- multicast-related configuration. Organization-
local scope is intended to span multiple sites belonging to a single organization.

14
2.3.5 IPv4 and IPv6 addressing
There are some differences between IPv6 and IPv4 addressing. Some of them are shown
below:
• IPv6 addresses, regardless of the type (unicast, anycast or multicast), are assigned
to interfaces, not to nodes. Since every interface belongs to a unique node, any of
the unicast addresses of the node interfaces could be used to refer the said node.
• One unique interface can have several IPv6 addresses of any type.
• One unicast address or group of unicast addresses can be assigned to numerous
physical interfaces, if the implementation manages these interfaces, from the
Internet viewpoint, as an only one, so a load balance between multiple devices is
possible.
2.4 Autoconfiguration
2.4.1 Introduction
The autoconfiguration is defined as the group of steps a host makes when it decides how
to autoconfigure its interfaces in IPv6. The process includes the creation of a link-local
address, the verification of its unicity in that link, determination of the information
which has to be autoconfigured (addresses and other information) and, in the case of
addresses, determination of the mechanism used to obtain them. The autoconfiguration
is only possible in environments where multicasting can be used.
Addresses can be obtained manually, using DHCPv6 (stateful or predetermined
configuration) or automatically (stateless or automatic discovery).The protocol defines
the link-local, global and site local address generation process with the automatic
procedure (stateless). In addition, it defines the mechanism to detect duplicated
addresses.
The autoconfiguration has been designed for hosts, not for routers, although some of the
routers configuration (its own link-local address, for instance) could be generated by
this mechanism.

15
2.4.2 Stateless autoconfiguration
The stateless autoconfiguration does not require any host manual configuration, router
minimum configuration or additional servers [3]. A host generates its self-address by
means of a combination of locally available information and information advertised by
the routers. The router reports the subnet (or subnets) identification prefix associated
with the link, while the host generate one “interface identifier” which identifies one-to-
one the interface in the subnet. The address is determined by the combination of both
fields. If there is no router, the host only can generate the link-local address, although
this is enough to let the communication between nodes connected to the same link. This
mechanism is used when the exact address assigned to a host is not important, but only
it is necessary to assure the address is unique and correctly routable.
2.4.3 Stateful autoconfiguration
In this autoconfiguration, the host obtains the interface address and/or the information
and configuration parameters from a server. Servers keep one database with the
addresses assigned to each host. DHCP is a UDP (User Datagram Protocol) client/server
protocol designed to reduce the cost of nodes management in environments where
administrators need a control of the network resources assignment, superior than the one
with the stateless configuration. Some important changes between DHCPv4 and
DHCPv6 are based on the addressing and autoconfiguration [4]. This mechanism is
used for example when is necessary to know which address uses each host at any
moment by some reason. It is possible to use both mechanisms.
2.5 Neighbor Discovery
The IPv6 protocol equivalent to the IPv4 protocol ARP (Address Resolution Protocol)
is called “Neighbor Discovery”. With this mechanism, one node that has been
incorporated to a network, discovers the presence of others nodes in its same link.
Therefore, it can determine their link-local addresses and it is able to locate the routers
and to keep the connectivity information about the active routes to the neighbors. It also
has been used to keep clean the caches where the network context information is stored,

16
so it is possible to detect any change. If any router or route fails, the host will look for
functional alternatives [5] .
This protocol is enough complex and sophisticated, since it is the base to allow the
autoconfiguration mechanism in IPv6. It defines mechanisms to: Discover routers,
prefixes and parameters, address autoconfiguration, address determination, next hop
determination, non-reachable nodes detection, duplicated addresses and address changes
detection, incoming load balance, anycast address and proxies advertisement.
It has many advantages, comparing to IPv4 mechanisms. For example: Router discovery
is part of the protocol base, so it is not necessary to use routing protocols. The router
advertisement includes the link-local addresses, so it is not necessary any additional
exchange of packets for its resolution and it allows the address autoconfiguration.
Neighbor Discovery defines five different ICMP packet types: A pair of Router
Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and
Neighbor Advertisements messages, and a Redirect message. The messages serve the
following purpose:
• Router Solicitation: When an interface becomes enabled, hosts may send out
Router Solicitations that request routers to generate Router Advertisements
immediately rather than at their next scheduled time.
• Router Advertisement: Routers advertise their presence together with various link
and Internet parameters either periodically, or in response to a Router Solicitation
message. Router Advertisements contain prefixes that are used for on-link
determination and/or address configuration, a suggested hop limit value, etc.
• Redirect: Used by routers to inform hosts of a better first hop for a destination.
• Neighbor Solicitation: Sent by a node to determine the link-layer address of a
neighbor, or to verify that a neighbor is still reachable via a cached link-layer
address. Neighbor Solicitations are also used for Duplicate Address Detection.
• Neighbor Advertisement: A response to a Neighbor Solicitation message. A node
may also send unsolicited Neighbor Advertisements to announce a link-layer
address change

17
3. Mobile IPv6
3.1 Introduction
In recent years, there have been many progresses in communications technologies. Two
of them are the growth of the portable computering and the important implantation of
the mobile communication devices. IP protocol is one of the principal pillars of the most
deployed communications network: Internet. However, the current internetworking
protocols have some problems when handling nodes with a certain grade of mobility.
Most of the IP protocol variants assume implicitly that nodes are always connected to
fixed points. Therefore, IP address makes a one-to-one identification with the node in
the network where it is connected. Any packet destined to that node is routed depending
on the information content in the IP address node.
Therefore, it is obvious that if a mobile node changes from one network to another,
maintaining its first network IP address, it will not be found or traced in its new
situation, because packets sent to that node will be routed to its previous connection
point (IP address).
With Mobile IP, the node obtains some freedom to move through networks, being
always accessible with an IP address [6]. Superior layers do not realize the network
change, because it is transparent to them, so the same applications (like for example
multimedia transmission) which are used in networks with fixed connection points can
also work correctly in mobile networks. This mobile feature appeared as a patch or add-
on in IPv4 but in IPv6 it is implicit.
3.2 State of the art
Firstly, it is important to remark the difference between portability and mobility. The
first term means the capacity one device has to be connected to different access
networks, but being necessary to stop and restart the network active connections in the
new network connection point. Therefore, it is just an automatic configuration, but not a

18
transparent support for the mobility of the device. Mobility, on the other hand, means
the capacity one device has to change network connection points without needing to
restart any connection type.
One important question is why the mobility solution is at IP-level and not at other
levels. There are mobility solutions at other levels, but the most accepted generic
solution nowadays is the IP mobility. Using inferior-levels mobility leads to a limitation
of the mobility to only a group of networks that use the same subnet technology and the
need for using multiple solutions, suitable each one for each type of network. On the
other hand, using superior-levels mobility requires to developed solutions to each
transport protocol, with the same problems as using inferior-levels mobility.
In the present situation, where the IP technology is clearly dominant in
telecommunications based on packet switching, IP mobility is the most logical option.
Using IP as the level where mobility is implemented, also originates other type of
technological challenges that creates the appearance of particular solutions, which
improve the performance, depending on the application, inferior layers and involved
protocols.
3.3 The IP mobility problem
In IP networks, the physical node localization and the IP address are closely linked. The
network prefix of a node IP address identifies the network where it is connected so all
the nodes from the same network use the same prefix. If one node is moved to another
place (out of the original network), all the IP packets sent to the IP address are routed
(using IP routing) to the network where the node was originally connected, so they will
not be delivered correctly. When the mobile node changes its network connection point,
all the packets destined to its IP address are delivered to the original network. The
mobile node has to change its IP address with the correct network prefix. With this
address change, connectivity is restored, but mobility is not achieved, only portability,
because mobility involves not to lose connectivity (apart from one time interval) with
the original IP address and not to interrupt any superior layers connection (like for
example TCP – Transport Control Protocol).

19
3.4 Basic operation of mobile IPv6
Mobile IPv6 provides layer 3 transparent mobility for the superior levels (i.e. TCP), so a
mobile node can be reachable with its home address no matter it is connected to its
Home Network or another [11]. The transition or handover between networks is
transparent for the superior levels and the connectivity loss produced during the
handover is due to the exchange of the corresponding signaling messages.
Every mobile node (Mobile Node, MN) has a local address (home address), which it is
its original network address. This address remains although the mobile node passes to
another network. Packets sent to the mobile node, when staying in its original network,
will be routed normally as if the node was not mobile. The prefix of this address is the
same that the network’s prefix where the node is originally connected.
When a mobile node goes to a different network from the original, it will obtain a new
“guest” address (Care-of Address, CoA, belonging to the address space of the visited
network). The mobile node can acquire its care-of address through conventional IPv6
mechanisms, such as stateless or stateful auto-configuration. From now on, it can be
reached also with this new address (apart from the home address). After obtaining the
new address, the mobile node contacts with one router from its original network (Home
Agent, HA) and, with a registration, communicates its current CoA to it. Afterwards,
when a packet is sent to the mobile node home address, the Home Agent will intercept it
and tunnel it to the mobile node CoA. This correspondence between the mobile node
home address and its current CoA (while it stays in the new network) is called binding.
With this mechanism, the packets reach the mobile node current location, because the
CoA belongs to the address space of the subnet where it is connected, so the IP routing
delivers the packet sent by the home agent (which has inside the encapsulation original
IP packet) to the mobile node. The mobile node can have more than one CoA address.
This scene is for example the normal structure of wireless networks (for example in
cellular telephone system), where one mobile node can be connected simultaneously to
several networks (for example several overlapped cells) and it must be reachable by any
of them.

20
Normally, a mobile node obtains one CoA address with a stateless autoconfiguration,
although it can use also stateful methods (like DHCPv6) or static preassignment.
One typical packets exchange between one mobile node and one correspondent node is
shown in Figure 8. One packet sent by the correspondent node to the mobile node, when
the latter is visiting one network, arrives to the Home Network, where the home agent
intercepts it and sends it to the mobile node current location. In addition, it can be
observed that packets sent by the mobile node are directly delivered. This has been
changed in the last specifications of mobile IPv6 (due to security problems). In most
basic cases, packets sent by the mobile node go through a reverse tunnel.
Therefore, MIPv6 provides mechanisms which allow a direct connection between the
mobile and correspondent node, without being necessary the intervention of the home
agent. When the home agent is necessary for that type of communication, it is called
“triangle routing” and it is less efficient. This mechanism appears in IPv4, but in IPv6
there is one route optimization mechanism that surpasses it.
This optimization routing procedure allows the mobile node to put its CoA address
(temporal address while visiting a network) as the original address in the IPv6 packets it
sends to correspondent nodes. The mobile node includes one IPv6 destination option
called “home address” which contains its home address, so the correspondent nodes can
identify from which mobile node the packets come from. At the same time, the packets
sent by a correspondent node to the mobile node have the CoA of this mobile node as
the destination address. Once again, to achieve transparency in the mobility, these
packets have one special IPv6 routing header, containing only one hop, similar to the
mobile node home address.

21
Figure 8. Route optimization in Mobile IPv6
3.5 Additional headers
Mobile IPv6 uses destination option headers in order to obtain the functional mobility
[11]. With these headers, it is possible to send signaling information in the same data
packet .
The new destination options to support mobility are:
• Home Address Option: It indicates which the mobile node home address when it
is outside of its original network.
• Binding Update Option. It is used to create, update and remove entries of the
bindings between the mobile node and the care-of address. One packet with this
option will produce the binding (in the correspondent node or the home agent)
between the packet original address and the address inside the Home Address
Option field.

22
• Binding Acknowledgement Option. It is sent by the Home Agent and
Correspondent Nodes as an answer of the Binding Updates sent by the Mobile
Node.
• Binding Request Option. It is sent by the Correspondent Node to request the
mobile node to refresh its entry in the Mobile Node current associations list.
The Binding Updates and Acknowledgements cause a change in the nodes state, so they
must be authenticated. Mobile IPv6 uses Authentication Header in order to prevent any
possible attack.
However, the authentication is not the only problem. It means to manage which
correspondent node can change some associations in the mobile node table. One
solution is using IKE (Internet Key Exchange) with DNSSEC, assuming the mobile
node and the correspondent node use the same public key infrastructure.
3.6 Dynamic Home Agent Address Discovery
When attached to a Foreign Network, a Mobile Node might not know the address of its
Home Agent. For example, a router operating as the Mobile Node's Home Agent might
be reconfigured or replaced by a different node serving as a Home Agent on the Home
Network.
Using Dynamic Home Agent Address Discovery (DHAAD), a Mobile Node only needs
a Home Network prefix configured and it can dynamically find the address of a Home
Agent on its Home Network when it needs to register its care-of address [11].
The following is an overview of how DHAAD works:
• Each Home Agent listens to Router Advertisement messages sent by the other
Home Agents, and records the addresses of these Home Agents.

23
• The Home Agents listen for Dynamic Home Agent Address Discovery requests
(or DHAAD requests) from the Mobile Nodes on a special IPv6 subnet anycast
address for the Home Network, the Mobile IPv6 Home-Agent's anycast address
(seven-bit anycast identifier: 0x7E).
• The Mobile Node attaches to a foreign network and needs to send a Binding
Update to a Home Agent on its Home Network, but does not have an address for a
Home Agent.
• The Mobile Node sends an ICMPv6 DHAAD request message to the Mobile IPv6
Home-Agents subnet anycast address for its Home Network.
• The Home Agents reply to the Mobile Node with ICMPv6 DHAAD response
messages that include a list of global unicast addresses for the Home Agents on
the Home Network. The response includes Home Agent addresses based-on their
Home Agent preference level.
• The Mobile Node then sends a Binding Update with its care-of address to a Home
Agent on the Home Network. The Mobile Node determines which Home Agent to
send its Binding Update to based on the Home Agent preference value included in
the Dynamic Home Agent Address Discovery response message. If the Mobile
Node does not receive a response, it might send a Binding Update to another
Home Agent.

24
4. Mobile IPv4 protocols
4.1 Introduction
Apart from Mobile IPv6, there are other existing IP mobile protocols. MIPv6 appears as
an improvement of MIPv4, as it can be read after this. The problem of MIPv6 is that it
handles macromobility and micromobility movements as they were the same.
Therefore, it has several deficiencies when handling micromobility.
Several IP micromobility protocols have been proposed, designed, and implemented in
order to complement the base Mobile IP protocol by providing fast, seamless, and local
handoff control.
The primary role of micromobility protocols is to ensure that packets arriving from the
Internet and addressed to mobile hosts are forwarded to the appropriate wireless access
point in an efficient manner. To do this, micromobility protocols maintain a location
database that maps mobile host identifiers to location information.
This section is an overview of the previous version of MIPv6 (MIPv4) and three IP
micromobility protocols: HMIPv6, Cellular IP and HAWAII.
4.2 Mobile IPv4
Mobile IP was originally defined for IP version 4, before IPv6 existed. The base
protocol is defined in RFC 2002 [6]. The following is a list of the major differences
between Mobile IPv4 and Mobile IPv6 concepts:
• IPv4 addresses are 32 bits long. IPv6 addresses are 128 bits long, which almost
surely eliminates the possibility of using-up all the addresses in IPv6.
• Mobile IPv4 uses tunnel routing to deliver data-packets to Mobile Nodes. Mobile
IPv6 uses tunnel routing and source routing with IPv6 Type 2 routing headers.

25
• Mobile IPv4 deploys Foreign Agents for Mobile Node movement detection and to
decapsulate data-packets addressed to the Mobile Node’s care-of address. MIPv6
Mobile Nodes decapsulate messages sent to their care-of address and use IPv6
Router Advertisements for movement detection, therefore eliminating the need for
Foreign Agents.
• Mobile IPv4 uses Agent Discovery for Movement Detection. Mobile IPv6 uses
IPv6 Router Discovery.
• Mobile IPv4 Route Optimization is an extension to the protocol, not part of the
base RFC; requires preconfigured and static security associations; and, was
difficult to operate with ingress-filtering routers. Mobile IPv6 Route Optimization
is a fundamental part included in the protocol; provides integrated Return
Routability to dynamically secure Route Optimization; and, operates effectively
with ingress-filtering routers.
• Mobile IPv4 reverse tunneling is an extension to the protocol. Mobile IPv6
bidirectional tunneling is part of the core protocol.
• Mobile IPv4 uses one home address. Mobile IPv6 uses a globally routable home
address and a link-local home address.
• Mobile IPv4 uses ARP to determine the link layer address of neighbors. Mobile
IPv6 uses IPv6 Neighbor Discovery and is decoupled from any given link layer.
• Mobile IPv4 Dynamic Home Agent Address Discovery uses a directed broadcast
approach and returns separate replies from each Home Agent to the Mobile Node -
Mobile IPv6 Dynamic Home Agent Address Discovery uses anycast addressing
and returns a single reply to the Mobile Node.

26
• Mobile IPv4 Mobile Nodes can obtain care-of addresses via Agent Discovery,
DHCP, and manual configuration. Mobile IPv6 Mobile Nodes can obtain care-of
addresses via Stateless Address Autoconfiguration, DHCPv6, and manual
configuration
4.3 HMIPv6
Hierarchical Mobile IPv6 (HMIPv6) protocol from Ericsson and Nokia uses a hierarchy
of Foreign Agents to locally handle Mobile IP registration. It is the proposed
enhancement of Mobile Internet Protocol versions 6 (MIPv6) designed to reduce the
amount of signaling required and to improve handoff speed for mobile connections.
HMIPv6 is a proposed standard from the Internet Engineering Task Force (IETF) [7].
MIPv6 defines a means of managing global mobility, but it does not address the issue of
local (within-site) mobility separately. Instead, it uses the same mechanisms in both
cases, which is an inefficient use of resources in the case of local mobility. HMIPv6
adds another level, built on MIPv6, which separates local from global mobility. In
HMIPv6, global mobility is managed by the MIPv6 protocols, while local handoffs are
managed locally.
A new node in HMIPv6 is defined. It is called the Mobility Anchor Point (MAP) and it
serves as a local entity to aid in mobile handoffs. The MAP, which replaces MIPv4's
foreign agent, can be located anywhere within a hierarchy of routers. In contrast to the
foreign agent, there is no requirement for a MAP to reside on each subnet. The MAP
helps to decrease handoff-related latency because a local MAP can be updated more
quickly than a remote home agent.
Using MIPv6, a mobile node sends location updates to any node it corresponds with
each time it changes its location, and at intermittent intervals otherwise. This involves a
lot of signaling and processing, and requires many resources. Furthermore, although it is
not necessary for external hosts to be updated when a mobile node moves locally, these
updates occur for both local and global moves. By separating global and local mobility,
HMIPv6 makes it possible to deal with either situation appropriately.

27
4.4 Cellular IP
Cellular mobile telephony systems are based on a different concept from that of Mobile
IP. Instead of aiming at global mobility support, cellular systems are optimized to
provide fast and smooth handoff within restricted geographical areas. In the area of
coverage, mobile users have wireless access to the mobility unaware global telephony
network. A scalable forwarding protocol interconnects distinct cellular networks to
support roaming between them.
Even in limited geographical areas, however, the number of users can grow to a point
where using fast lookups for per user databases is no longer viable. In addition, mobility
management requires mobile hosts to send registration information after migration. The
resulting signaling overhead has significant impact on the performance of wireless
access networks. To overcome this problem, cellular telephony systems require mobile
hosts to register after every migration only when they are engaged in ‘active’ calls. In
contrast, ‘idle’ mobile hosts send registration messages less frequently and as a result
can roam large areas without loading the network and the mobility management system.
In this case, the location of idle mobile hosts is only approximately known to the
network. To establish a call to an idle mobile host, the mobile host must be searched for
in a limited set of cells. This feature of passive connectivity allows cellular networks to
accomodate a very large number of users at any instance without overloading the
network with large volumes of mobility management signaling information.
The Cellular IP protocol from Columbia University and Ericsson Research supports
paging and a number of handoff techniques. It is an Internet host mobility protocol that
takes an alternative approach to that found in mobile telecommunications (e.g., General
Packet Radio Service) and in IP networking (Mobile IP). It is optimized to provide
access to a Mobile IP enabled Internet in support of fast moving wireless hosts [8].
Cellular IP inherits cellular systems principles for mobility management, passive
connectivity and handoff control, but is designed based on the IP paradigm. The
universal component of a Cellular IP network is the base station that serves as a wireless

28
access point but at the same time routes IP packets and integrates cellular control
functionality traditionally found in Mobile Switching Centers (MSC) and Base Station
Controllers (BSC). The base stations are built on regular IP forwarding engines, but IP
routing is replaced by Cellular IP routing and location management. The Cellular IP
network is connected to the Internet via a gateway router. Mobility between gateways
(i.e., Cellular IP access networks) is managed by Mobile IP while mobility within
access networks is handled by Cellular IP. Mobile hosts attached to the network use the
IP address of the gateway as their Mobile IP care-of address. Assuming Mobile IPv4
and no route optimization, packets will be first routed to the host's home agent and then
tunnelled to the gateway. The gateway "detunnels'' packets and forwards them toward
the base stations. Inside the Cellular IP network, mobile hosts are identified by their
home addresses and data packets are routed without tunneling or address conversion.
Cellular IP routing protocol ensures that packets are delivered to the host's actual
location. Packets transmitted by mobile hosts are first routed to the gateway and from
there on to the Internet.
In Cellular IP, location management and handoff support are integrated with routing. To
minimize control messaging, regular data packets transmitted by mobile hosts are used
to establish host location information. Uplink packets are routed from mobile to the
gateway on a hop-by-hop basis. The path taken by these packets is cached in base
stations. To route downlink packets addressed to a mobile host the path used by recent
packets transmitted by the host is reversed. When the mobile host has no data to
transmit then it periodically sends empty IP packets to the gateway to maintain its
downlink routing state. Following the principle of passive connectivity, mobile hosts
that have not received packets for a certain period of time allow their downlink soft-
state routes to timeout and be cleared from the routing cache. In order to route packets
to idle hosts a Cellular IP mechanism called paging is used.
4.5 HAWAII
The HAWAII (Handoff-Aware Wireless Access Internet Infrastructure) protocol from
Lucent Technologies proposes a separate routing protocol to handle intradomain
mobility [9]. HAWAII is an extension to Mobile IP that corrects the following defects:

29
• In Mobile IP, user traffic is disrupted when the mobile host changes domains.
• In Mobile IP, costly updates to the home agent must be made for every domain
change.
• When mobile hosts change domains, they acquire new network paths to the home
agent. In turn, this requires the old QoS guarantee to be torn down, and a new one
(along the new route) to be established. Because these QoS setups are costly, they
should be minimized.
• The requirements for home and foreign agents incur a robustness penalty. This
penalty should be reduced.
Essentially, HAWAII attempts to do this by making the assumption that most of the
mobility is within a single logical administrative domain (which may be composed of
many physical sub-domains), and then taking steps in order to optimize the system for
that type of environment. The HAWAII protocol is driven by five design goals: limit the
disruption to user traffic, enable the efficient use of access network resources, a drive to
enhance scalability, to provide intrinsic support for QoS, and to enhance reliability.
HAWAII has other differences that distinguish it from other micromobility solutions.
After simulation, the authors found that the localized HAWAII schemes caused less
disruption to UDP-based audio and video streams than did Mobile IP schemes.
HAWAII's ability to quickly change routes without notifying the home agent allows it
to drop less packets, resulting in less disruption. The authors also argue that HAWAII is
scalable. Due to how HAWAII distributes its overhead, it results in much less overhead
at the most heavily loaded router as compared to Mobile IP. Furthermore, HAWAII is
better at supporting QoS than competing protocols. HAWAII interoperates well with
existing wire-line QoS protocols because it minimizes changes to the care-of address,
making the mobile host appear more permanent that it really is.
Finally, the authors argue that HAWAII's use of softstate refreshes, and the elimination
of the HA when mobile is in the home domain, allows it to increase reliability over

30
straight Mobile IP. In order to summarize, some advantages and disadvantages of
HAWAII are shown below.
Advantages:
• Limits change of mobile host's IP address.
• Eliminates need for HA when roaming in home domain.
• Can adapt to changed base stations within the current domain more quickly than
Mobile IP.
Disadvantages
• Requires new routers and / or daemons.
• They assume that base stations have IP routing functionality.
• Requires state in routers, which always breeds scalability concerns.
• HAWAII incurs a higher processing overhead on limited power mobile host than
Mobile IP.

31
5. IP Multicasting
5.1 Introduction
The size of the multimedia data when using broadcast methods makes difficult to
receive a good quality streaming data with no interruptions or delays, across the
networks, without using a huge amount of their resources. With multicasting, it is
possible to have a cost effective multimedia transmission, being an alternative to
traditional methods. It is possible to provide television channels broadcast over IP
networks to home users and enables service providers to supply integrated video, voice
and data over IP-based DSL (Digital Subscriber Lines) or fiber networks.
5.2 Multicast and unicast
In a conventional Ethernet network, the most common traffic is unicast or host-to-host
transmission. Every computer listens to all the other packets that are sent in the network
and looks for packets that are addressed to it. Unicast is very suitable for a
communication to one or few computers. However, when it is necessary to send data to
more than a few computers, unicasting is inefficient because a copy of each packet must
be sent to every receiver (even in shared links), so it would flood the network easily,
especially when large multimedia files are sent. Broadcast mechanism is used to
communicate with all of the computers connected to a network. When packets are sent
to the broadcast address, all the computers pick up the packets and process them. This is
useful when it is necessary to send information to every computer, but when not
everyone wants to receive that information is useless.
As said before, in IPv6 there is a new type of address called multicast address [2].
Multicasting is the type of communication between computers in a network that enables
one computer to send one stream of data to only the interested receivers. Only one
stream of packets is sent to the multicast group, composed the latter by the computers
interested in receive that data so the other computers are not interrupted. The multicast
stream is separated when it passes through the routers, so there are no redundant copies
of the information, as it happens in unicast, where a separate stream of data is being sent

32
to each receiver. The difference between unicast and multicast can be observed in
Figure 9.
Figure 9. Unicast versus multicast mechanism
Multicast is scalable across different sized networks, but in particular is well suited to
WAN environments. People from different locations can receive streaming data files
(video, music, etc) without taking up excessive bandwidth.
Multicast addresses identify a transmission session rather than a specific physical
destination or host, so all the components of the multicast group are identified by a
single IP address.
5.3 Multicast traffic management: MLD
Multicast is relatively simple in a single physical segment within a network. The data
sender provides a destination address, the device driver transform this address to the
corresponding MAC (Medium Access Control) address and sends the package out on
the network. The receiving devices indicate if they want to receive the multicast data.
However, when the multicast data is extended beyond a single physical network and it
passes through routers, it is more complicated to manage it. Every device involved in
the transmission has to be coordinated with the others. Things to be considered are the
establishment of a path between source and destination, how to forward multicast data

33
through a network and to know which hosts want to join a multicast group. After this,
the steps that define who receives the multicast data are explained more.
MLD stands for Multicast Listener Discovery and it is a sub-protocol of ICMPv6. It
defines which device receives the multicast data in a network [10].
MLD allows an IPv6 router to determine, for each of its directly attached links:
• Which Ipv6 nodes are interested in receiving multicast traffic.
• From which groups each node is interested in receive traffic.
• From which sources a node is interested in receive or not traffic, if the node
specifies one list of sources.
MLD controls automatically the flow of traffic using multicast queries and hosts. The
querier is a network device (normally a router) that sends query messages to find out
which network devices belongs to a given multicast group. Queriers and hosts use MLD
reports to join or leave multicast groups and to begin receiving multicast data.
MLD has three types of messages:
• Query messages: To learn which multicast addresses have listeners. There are
three subtypes of query messages: General, group-specific and multicast address
specific.
• Report messages: These messages (Multicast Listener Report) have their multicast
address field set to the specific IPv6 multicast address that the sender is listening.
They are sent by the MLD hosts and they contain information about the groups
and sources from where the hosts wish to receive traffic.
• Done messages: They let the source know that a receiver does not want to receive
multicast data anymore. These messages have their multicast address field set to
the specific IPv6 multicast address to which they are no longer listening.

34
MLDv2 provides support for source filtering that enables a host to report interest in
receiving packets from specific source addresses “only” or from “all but” specific
source addresses. This information is used by multicast routing protocols to avoid
delivering multicast packets from specific sources to networks where there are no
interested receivers. MLD snooping enables switches to forward multicast data to hosts
that want to receive the packets instead of sending them to all ports on a VLAN (Virtual
LAN).
Routing multicast traffic is more complex than routing unicast or broadcast traffic,
because a multicast address identifies a particular transmission session rather than a
specific physical destination. The multicast data source does not to need all the
addresses of the receiving devices, so the routers have to translate multicast addresses
into host addresses. In multicast mechanism, routers must interact with each other to
exchange information about neighboring routers.
The involved routers in multicast transmission establish distribution trees to connect all
the multicast group members in order to distribute the multicast data. The distribution
trees specify the forwarding path from the source to each of the members of the
multicast group. The most basic types of trees are source specific trees that find the
shortest path from the source to the receivers and centre specific trees that use
distribution centers and build a single tree that is shares by all the members of a group.
Regarding QoS, to maintain a continuous flow of data, it is essential not to have packet
loss or delay while transmitting multicast streaming. The most common method of
delivering multicast data streams is with UDP. UDP is a Layer 4 protocol (transport
protocol) that transmits packets without requiring any acknowledgement from the
receiver and without retransmitting packets if they do not reach the receiver. This
protocol is employed instead of TCP (where acknowledgement and retransmission
exist) because in real time stream there is no time to retransmit any lost packets so any
packet loss or delay (cause by congestion for example) affect the final quality of the
received data stream. To achieve QoS in multicast data, higher priority can be given to
the multicast packets when being processed by the router or switch network.

35
6. Testbed components and configuration
6.1 Introduction
After an overview of the theoretical base of this thesis, this section and the next one
focus on the practical part of the thesis. This section explains the hardware and software
of the network system used in the laboratory. In this system, practical experiments took
place by using and applying the theoretical knowledge obtained during the
documentation stage of the thesis. Firstly, the test system elements and their
configuration are described. Then, the employed main software applications are
detailed.
6.2 The testbed
The testbed is the hardware-software system used during the thesis, which is placed in
the Mobile Communication and Computing Laboratory (MC2
L) at the Department of
Telecommunications of the Budapest University of Technology and Economics. Figure
10 shows a layout of the testbed with its main components and connections.
Figure 10. MC2
L Testbed.

36
6.2.1 Testbed hardware
The testbed showed in the above figure is composed of the following devices:
• Home Agent (HA). It is a Pentium 4 (Fujitsu SIEMENS) configured to make
Home Agent services. It has one network interface installed. The model is Intel(R)
PRO/1000 CT Network Connection, which supports 10/100 Mbps.
• Router. It is a Pentium 233 MHz (64 MB RAM) with special software installed to
make it operate as an IPv6 router.
It has three Digital Equipment Corporation 21143 Tulip PCI Network
Interface cards installed for the subnets inside the testbed that support 10/100
Mbps. For the outside connection (to Internet), it has one 3Com 3C509 Etherlink
III. ISA Network Interface card installed that supports 10 Mbps.
• Hub. The model is EDIMAX ED-1408P. It has eight ports and it supports dual
speed (10/100Mbps).
• Mobile Node 1 (MN1). It is an ASUS Pentium IV (laptop computer). It has a
BreezeNet SA-PCR Station Adapter WLAN PCMCIA card installed, which
makes it operate as a mobile node. The adapter has multi-rate support for 1, 2 and
3 Mbps.
• Mobile Node 2 (MN2). It is a Hewlett Packard Pentium III (laptop computer). It
has a BreezeNet SA-PCR Station Adapter WLAN PCMCIA card installed, which
makes it operate as a mobile node. The adapter has multi-rate support for 1, 2 and
3 Mbps.
• Access Points. They are the air interface of the testbed by acting the role of
cellular Base Stations. The Access Points model is BreezeNet AP-10 PRO.11,
which supports various data rates simultaneously: at 3 Mbps, 2 Mbps or 1 Mbps.
The hub connects multiple Ethernet segments together making them act as a single
segment. When using a hub, every attached device shares the same broadcast domain
and the same collision domain. Therefore, some of the measurements made in the Home
Network could have been done in any of the device interfaces attached to the hub,
because the hub broadcasts all the data it receives in one port to its other ports. Figure
11 explains the normal operation of the hub:

37
Figure 11. Normal operation of the hub when receiving data in one port
6.2.2 Testbed logical configuration
The testbed is basically a network with IPv6 support (it also supports IPv4). Inside the
testbed there are three IPv6 wireless subnetworks. These subnetworks have been created
in the testbed with overlapping radio cells controlled by the Access Points. The wireless
network prefixes are 3ffe:ffff:501:100::/64 (Home Network prefix),
3ffef:fff:501:200::/64 and 3ffe:ffff:501:300::/64. The testbed is connected to Internet
through the fourth interface of the router (IPv4/IPv6 connection).
The manually defined global IPv6 addresses of the devices are the following:
• Home Agent (HA): 3ffe:ffff:501:100::100/64 (Scope: global)
• Router: First interface (eth1): 3ffe:ffff:501:100::1/64 (Scope: global)
Second interface (eth2): 3ffe:ffff:501:200::1/64 (Scope: global)
Third interface (eth3): 3ffe:ffff:501:300::1/64 (Scope: global)
• Mobile Node 1 (MN1): 3ffe:ffff:501:100::50/64 (Scope: global)
• Mobile Node 2 (MN2): 3ffe:ffff:501:100::150/64 (Scope: global)
Figure 12 illustrates the logical configuration of the testbed, with the subnetwork
prefixes and the IPv6 addresses of its components.

38
Figure 12. Testbed logical configuration
6.3 Software
All the testbed components have the Debian Sarge GNU/Linux kernel 2.4.26 (with IPv6
support) installed as their operating system. This distribution was chosen because it is
very easy to maintain and upgrade, well supplied with packages and reliable. Apart
from the operating system, other software has been necessary for the tests.
6.3.1 MIPL
MIPL (Mobile IPv6 for Linux) is a transparent Linux implementation of Mobility
support in IPv6 RFC [11] [12]. As explained before, mobile IPv6 basically gives IPv6
nodes freedom to move to other networks being transparent to the upper protocols
without interrupting their previous connections with other network nodes. It introduces
an extension header called “mobility header”, new destination option (Home Address
destination option), new IPv6 ICMP Message and other modifications of IPv6.

39
There are currently two available Mobile IPv6 implementations for Linux. The
Lancaster University in the United Kingdom has the oldest implementation that has not
been updated since 1998 so it is considered obsolete. The newest implementation, up-
to-date version, is the MIPL project of the Helsinki University of Technology [12].
The Mobile IPv6 implementation installed in the testbed is MIPv6-1.1-v2.4.26 and is a
full kernel space implementation of the Mobile IPv6 specification RFC 3775 [11] and
works for the kernel 2.4.26 (the one installed in the testbed). It does not support IPSec.
MIPL reduced the number of the possible software environments to be used, so that is
why a Linux distribution was necessary to be installed on the testbed. In order to make
MLD proxy to work, MIPL was manually patched to kernel v2.4.27.
6.3.2 MLD Proxy for MIPL
As it has been seen before, MLD stands for Multicast Listener Discovery and it is a sub-
protocol of ICMPv6 that defines which device receives the multicast data in a network.
With MLD proxy installed on a Mobile IPv6 Home Agent, the latter can receive MLD
reports sent by one of its mobile nodes (for more explanation of MLD protocol, see
section 5.3 ). Therefore, the mobile node can send MLD reports to the Home Agent via
the tunnel created between them. The MLD proxy catches those reports and joins (from
its own LAN) the multicast group or groups on behalf of the mobile nodes it serves. The
multicast data is then forwarded to the current location of the mobile node. Mobile
nodes can also be multicast sources (they still need to join the group for the MLD proxy
to forward the data). It is also possible to specify whether link-local and site-local
multicast is forwarded or not [13] [14].
Figure 13 outlines one example of MLD Proxy operation. There are three mobile nodes
wanting to join two multicast groups (MN1 wants to join group G1 and MN2 and MN3
want to join G2). They send the corresponding MLD reports via the tunnels to their
Home Agent. The Home agent catches those reports and joins the two multicast groups
and then it forwards the multicast data to the corresponding nodes (MN1 will receive

40
the multicast data from group G1 and MN2 and MN3 from group G2). In Figure 13, the
Home Agent’s forwarding table and the MLD Proxy global table can also be observed.
Figure 13. MLD proxy mechanism scheme
MLD Proxy version 0.83 is compatible with MLDv1 and MLDv2.
6.3.3 Ethereal
Ethereal is a software used to capture and analyze the data that flows in a network link.
The version of Ethereal installed on the testbed computers is 0.10.6 (Debian package).
Live data can be read from Ethernet, FDDI (Fiber Distributed Data Interface), Token-
Ring, IEEE 802.11, and classical IP over ATM (Asynchronous Transfer Mode) or
loopback interfaces. Ethereal can dissect data from 658 different protocols [15]. This
network packets analyzer is Open Source software released under the GNU General
Public License and currently it runs on most UNIX platforms and various Windows
platforms [16] . Ethereal has been used to make several tasks, as it will be explained
later. Figure 14 shows a screenshot of Ethereal main window with some information of
captured packets.

41
Figure 14. Screenshot of Ethereal main window
6.3.4 VLC Player
VLC media player is a cross-platform (Linux, Windows, Mac OS X, etc) multimedia
player for several audio and video formats (MPEG-1, MPEG-2, MPEG-4, Divx, mp3,
ogg, etc) as well as DVDs, CDs and various streaming protocols. The version installed
in the testbed is 0.8.0-test1 (Debian package).
VLC player can be used as a server to stream in unicast or multicast in IPv4 or IPv6
networks with high-bandwidth using UDP or RTP protocol [17]. It is possible to add a
channel information service based on the SAP (Session Announcement Protocol) / SDP
(Session Description Protocol) standard. The miniSAP server sends announcements
about the multicast programs on the network, and VLC receive these announcements
and automatically adds the programs announced to their playlist. This free software has
been developed under the context of the VideoLAN project and released under the GNU
General Public License [18]. Figure 15 outlines the VideoLAN solution, where it can be
seen that there are different possibilities to stream multimedia from different sources,
streamers and clients.

42
Figure 15. VideoLAN Client solution diagram
6.3.5 Iperf
Iperf is a tool used to measure UDP and TCP bandwidth performance in network links.
It reports the maximum bandwidth, delay jitter and datagram loss [19]. In the
laboratory, the IPv6 version of the release was used. The installed version is 1.7.0
(Debian package).
The program operates in the following way: The server waits and listens in one port in
order to receive packets generated by the client running Iperf. In the client’s part, it is
possible to define the maximum bandwidth to use when generating the packets, so
modifying this bandwidth different situations of the network load can be simulated
(congestion or no congestion, for example). In addition, the generated datagram size can
be modified, in order to adjust to the size of the emulated application stream.
The server detects UDP datagram loss by ID numbers in the datagrams. Usually a UDP
datagram becomes several IP packets so losing a single IP packet will result in losing
the entire datagram. To measure packet loss instead of datagram loss, it is possible to
make the generated datagrams small enough to fit into a single packet. Thus, there
would not be datagram reassembly.
Iperf also can test how a network performs with compressed or uncompressed streams,
creating representative streams. This is usually due to the link layer compressing data.

43
7. Mobility in the testbed
7.1 Introduction
The first main topic of the thesis concerns IP mobility. This section summarizes the
experiments done with the testbed focused on how IPv6 mobility works in a real system
and how it is configured in order to use unicasting and multicasting mechanisms.
7.2 Mobile IPv6 operation in the testbed
The three wireless subnetworks of the testbed let the Mobile Nodes make movements
between the Home Network and two different foreign wireless networks. Firstly, the
correct mobility of the Mobile Nodes was checked in order to study the operation of
Mobile IPv6 in the testbed and contrast it with the theory. Mobile Node 1 (MN1) moved
from its Home Network to a foreign network (subnetwork 2), as illustrated in Figure 16,
while at the same time it was receiving “pings” (ICMPv6 requests generated by the
ping6 command) from the Home Agent (HA).
Figure 16. Mobile Node 1 movement

44
In order to study the basic operation of Mobile IPv6 in this movement, Ethereal was
running in MN1 to capture and analyze the exchanged packets between the HA and
MN1 and the packets received by MN1 when it moved to the visited network. As it can
be seen in the highlighted packet of Figure 17, MN1 has received successfully the care-
of address (CoA) of the visited network. This address,
3ffe:ffff:501:200:20c:6eff:fee4:fdf1, is generated with stateless autoconfiguration,
composed by the prefix of subnetwork 2 (3ffe:ffff:501:200::/64) plus the interface
identifier (EUI-64 identifier) derivative from its MAC address (which is also the
interface identifier of its home link-local address). MN1 sends a binding update from
this new CoA to the HA’s address (3ffe:ffff:501:100::100) to let it know that it has
obtained correctly a new address to operate in the visited network. Inside the
highlighted packet it is observed that in the options header, the original address (the
home address) of MN1 is included, as it was expected in a normal operation of Mobile
IPv6 protocol. HA sends a Binding acknowledgement to MN1´s CoA to let it know it
has received it correctly.
Figure 17. Exchanged packets during Mobile Node 1 movement
The rest of the packets shown in figure 10 belong to ICMPv6 protocol. Before moving,
MN1 sends echo requests from its home address to the HA’s address
(3ffe:ffff:501:100::100) and the HA answers sending echo replies. After moving and

45
receiving the care-of address and binding acknowledgement, MN1 sends echo requests
from its CoA to the HA’s address and HA replies to that CoA. ICMPv6 Echo Request
and Echo Reply messages are used to facilitate network reachability testing. A device
tests its ability to communicate with another by sending it an Echo Request message
and waiting for an Echo Reply in response. The ping utility (in this case ping6, the IPv6
version of ping), a widely used diagnostic tool in TCP/IP, makes use of these messages.
When a mobile node needs to send a Binding Update to the Home Agent after it has
obtained the new care-of address, it may not have an address for a Home Agent (the
Home Agent could have been replaced or reconfigured). Thus, it sends an ICMPv6
DHAAD (Dynamic Home Agent Address Discovery) request message to the Mobile
IPv6 Home Agents subnet anycast address for its Home Network. The Home Agent
replies to the Mobile Node with ICMPv6 DHAAD response messages that include a list
of global unicast addresses for the Home Agents on the Home Network. After receiving
this packet, the mobile node can now send the binding update to the Home Agent.
Regarding the Neighbor Discovery protocol (see section 2.5 for more information)
some different messages types can be observed: neighbor solicitation, neighbor
advertisement, and router solicitation and router advertisement. There are two packets
from an unspecified IPv6 address (::) sent by a device seeking to have its IP address
configured.
The Neighbor Advertisement sent from the of MN1’s CoA to the router’ link-local
address in subnetwork 2 is used to inform about the link-local address of the mobile
node and it is a response to the neighbor solicitation sent just before from the router.
The neighbor solicitation sent by a node is used to determine the link-layer address of a
neighbor, or to verify that a neighbor is still reachable via a cached link-layer address.
Neighbor Solicitations are also used for Duplicate Address Detection.
There is one router solicitation packet from the link-local address of MN1 that is sent to
the all-routers multicast address (ff02::2). When an interface becomes enabled, hosts
may send out Router Solicitations that request routers to generate Router

46
Advertisements immediately rather than at their next scheduled time. The router sends
from its interface attached to the subnetwork 2 (eth2) a Router Advertisement to the all
nodes multicast address, which can contain prefixes that are used for on-link
determination and/or address configuration, a suggested hop limit value, etc.
When MN1 comes back to its original network, it receives a new address (apart from
the one manually configured) because of the router advertisement within the Home
Network.
The same movement was done with Mobile Node 2 and the mobility worked correctly.
The exchanged packets were nearly the same, with differences in the IPv6 addresses of
the involved devices. Both of them returned to the Home Network correctly. Other
movements were checked (movements to the subnetwork 3, for example) but it is not
relevant to describe these here, because the mechanism is very similar to the one
explained above.

47
8. Multimedia streaming without mobility
8.1 Introduction
After checking the correct operation of mobile IPv6 in the testbed, the next step was to
test and compare unicast and multicast streaming inside a subnetwork. That means, in
this section all the devices are in the Home Network, there is not any movement to other
foreign networks.
8.2 Multimedia streaming in the Home Network
In all the streaming tests, the same file (MPEG-1 video file) was always used. The
software used for this section was mainly VLC player and Iperf (both explained in
section 7.1). Firstly, this video file was streamed from the router interface number 1 to
the unicast address of both mobile nodes. UDP protocol was used as the transport
protocol, since it is very suitable for streaming as it has been explained before. VLC
player worked as a server in the router and both mobile nodes made VLC to be ready to
listen, receive the unicast stream and reproduce it.
The typed command lines in the router and mobiles nodes were the following:
Router: Process 1: vlc -vvv –video_file_name.mpg –-ipv6 –sout
udp:[3ffe:ffff:501:100::50%eth1] –-ttl 3
Process 2: vlc -vvv –video_file_name.mpg –-ipv6 --sout
udp:[3ffe:ffff:501:100::150%eth1] –-ttl 3
Mobile Node 1 and 2: vlc -vvv --ipv6 –udp:
It is always necessary to add the command line option “--ipv6” to use IPv6 instead of
IPv4. Besides, it is necessary to specify the output network interface of the router
(because it has more than one interface) after the destination address. Mobile nodes just
have to listen and check if there are UDP datagrams destined to their unicast IPv6
address. In the case of the mobile nodes, it is not necessary to specify the input
interface. The “--ttl” option is the value of the TTL (Time To Live) of the IPv6

48
packets which means the stream could cross more than one router, but in this case it
could be omitted because the measurements and tests are only done inside the scope of
only one router. Figure 18 illustrates the path the unicasting streams take within the
Home Network until they reach the mobile nodes where they are reproduced. Once
again, it can be observed how the hub broadcasts the data to all its ports.
Figure 18. Unicasting streaming in the Home Network
The unicast streams were received correctly in both mobile nodes because there was
enough bandwidth in the shared link. Therefore, there was no degradation of the images
or audio. In this situation, there is no difference for the final users (mobile nodes)
between multicast and unicast, although the generated network load is not the same,
because in unicast two streams have been sent and in multicast only one would be sent.
Figure 19 shows a screenshot of the video stream received and played correctly in the
VLC player screen of one of the two mobile nodes.

49
Figure 19. Unicast streaming with not overloaded network
The difference between both mechanisms is more visible when there are many receivers
because with unicast there would be one stream per receiver and in multicast always
only one in each link.
After streaming successfully, the next step was to stream again with unicasting
mechanism in the same network (Home Network) but under different circumstances.
These circumstances are the situation where the network is overloaded or congested.
The overload or congestion can happen because of many reasons: Many mobile nodes
receiving their corresponding unicast stream and therefore saturating the wireless shared
access, other traffic data (not necessary streaming type) flowing across the wired links
apart from the unicast streams, etc. Reception errors will arise when the links within the
Home Network do not have enough bandwidth to deliver all the packets in real time to
the mobile nodes and there will be a delay in the received streams. Besides this
problem, other errors will occur if the access point is not an “intelligent” device like a
router, for example. It cannot buffer packets, so apart from not receiving the packets in
time, these packets will be lost, causing a high degradation of the received stream in the
mobile nodes.
As explained in section 6.3.5, Iperf is mainly used to find out the supported bandwidth
of a given link by generating traffic data and calculating the maximum generated
bandwidth. However, it can also generate traffic data with a fixed bandwidth, and this

50
feature is used in this section in order to simulate traffic data between nodes and
therefore to create congestion. In this case, to create overload in the Home Network,
Iperf was running as the server in the router and as a client in the Home Agent. Iperf did
not run in the mobile nodes so the processing performance in the streaming reception
with VLC player was not adversely affected. Figure 20 shows a capture made by
Ethereal while the two unicast streams plus the generated traffic by Iperf were flowing
across the Home Network.
Figure 20. Unicasting under overloaded network conditions
In the figure above we can distinguish the UDP packets of both unicast streams sent by
an IPv6 global address of the router’s first interface
(3ffe:ffff:501:100:200:f8ff:fe07:62a9) destined to the home addresses of the mobile
nodes (::50 and ::150). This global address is acquired because of the stateless
autoconfiguration, adding the Home Network’s prefix (3ffe:ffff:501:100::/64) plus the
EUI-64 identifier derivative from the MAC address of the router’s first interface
(::200:f8ff:fe07:62a9/64). This identifier is also the interface identifier of the link-local
address of the router’s first interface. There is also a neighbor advertisement from the
router’s global home address (3ffe:ffff:501:100:1) sent to the link-local address of the
Home Agent as an answer to a neighbor solicitation sent from the latter. Finally, we can
observe the packets Iperf generates from the Home Agent, destined to the Router (the
simulated overloading conditions). These packets are destined to a port (value 5001)

51
called “ttcp” because Iperf is reminiscent of ttcp, an older tool designed to measure TCP
and UDP performance that uses that port [20].
The two unicast streams plus the extra data traffic generated by Iperf caused packet loss
and therefore degradation of the received audio and video in both mobile nodes. This
degradation is directly proportional to the amount of data generated by Iperf.
Transcoding (to convert the format of one media file to another format) could be used
(VLC player has this feature) to use less bandwidth, but it is not relevant for the study.
Figure 21 shows a screenshot of the video stream received and played in the VLC
player screen in one of the two mobile nodes when there is not enough bandwidth for
the unicast streaming. The received video and sound were frequently erroneous.
Figure 21. Unicast streaming with overloaded network
The last part of this section was to stream again the same file from the first interface of
the router to both mobile nodes but using multicast mechanism instead of unicast. As it
was explained before, when multicast is used, there will be only one stream in each link
so there will not be duplicated information. In this case, the typed command lines were
the following:
Router: vlc -vvv –video_file_name.mpg –-ipv6 --sout udp:[ff02::1%eth1]
–-ttl 3
Mobile Node 1 and 2: vlc -vvv --ipv6 –udp:

52
The difference now is that in the router, there is only one vlc server running and the
destination address (ff02::1) is the IPv6 special multicast address called “All nodes
(hosts and routers) multicast group”. Other tests were done using an invented multicast
address (like for example ff02::1234) and making mobile nodes to listen to this specific
multicast address, and the results were similar. Figure 22 shows how multicast works
within the Home Network.
Figure 22. Multicasting streaming in the Home Network
As shown in the figure above, (see also Figure 18 to compare) the router only sends one
copy of the video stream instead of two as it happened with unicast mechanism. Since
the stream is sent to the “all nodes multicast group”, every device listening to udp
datagrams would receive the stream. If one of the mobile nodes stops listening to the
multicast address nothing changes, as the router will always send one multicast stream
if at least one node is joining the multicast group to receive it. Therefore, if there were
more nodes joining the multicast group the router would also send only one multicast
stream to the Home Network links.

53
Figure 23 shows a capture made by Ethereal. In the capture the packets generated by
Iperf sent from the Home Agent (HA) to the router within the Home Network (the same
special destination port called ttcp, as before) can be observed again. Apart from these
packets, there can be seen packets generated from the link-local address of the router’s
first interface that belong to the multicast stream (their destination is the special
multicast address, ff02::1, called “all nodes multicast group”) the router are sending to
the Home Network. There is only one stream, which can be received by any host or
router that are listening to udp packets.
Figure 23. Multicasting under overloaded network conditions
The reception in both mobile nodes was correct, since only the streaming traffic data
travelled inside the Home Network links and there was enough bandwidth. The situation
is the same as when using unicast without overloading the network by generating traffic
with Iperf.
After this successful multicast streaming, the same network overload circumstances
while using unicasting were now simulated again with Iperf. In order to verify the
advantage (mainly, the saving of bandwidth) of multicasting as opposed to unicasting,
an experimental maximum generated bandwidth was fixed in Iperf. In this situation, it
was possible to receive correctly the video stream in both mobile nodes with multicast
but the stream was received degraded in the case of unicast. If Iperf generates a bigger

54
traffic than this limit, neither mechanism could make it possible to have a good
reception, but this case is not interesting for the purposes of this thesis, only the
situations in which the advantages of multicasting can be observed.
It can be concluded that multicasting is more effective because it uses less bandwidth
than unicast. This advantage is more notable when there is a high number of receivers,
for example Internet TV or Radio. With multicasting, these services can be supplied
without needing to improve a lot the infrastructure of the networks so it is more cost
effective. On the other hand, in scenarios where there are many routers, when using
multicasting mechanism, control traffic is generated for the communication between the
routers, and if there are a notable number of routers, the extension functions regarding
multicasting could increase the processing time in the routers´ operations.

55
9. Theoretical comparison of multicast and unicast
9.1 Introduction
This section proposes a mathematical study in order to state the advantages of
multicasting as opposed to unicasting in a theoretical network model.
9.2 Theoretical comparison
The following formulas explain the relation between the traffic generated by a device
that streams with both mechanisms, when there are n receivers. Mathematically, the
relation between the two mechanisms is as follows:
;Snbunicast ⋅= Sbmulticast = n
b
b
multicast
unicast =⇒
bunicast and bmulticast are the total amount of bytes generated by the streamer when unicast
and multicast are used, respectively. S is the whole size of the stream (in bytes) and n is
the number of receivers. This is the case when the streamer sends the stream through
only one of its interfaces and after that, the different streams go through different routes,
as illustrated in Figure 24.
Figure 24. Unicasting versus multicasting
In the case of the example showed in Figure 24, if the router generates a stream with a
whole size of 15Mbytes, it has to generate and send a total amount of 3·15 = 45 Mbytes

Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks

Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks

Similar to Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks (20)

Javier Rodriguez Olalla - Streaming over Mobile IPv6 networks