NEMO: Network Mobility. Bringing ubiquity to the Internet access
Transcript of NEMO: Network Mobility. Bringing ubiquity to the Internet access
NEMO: Network Mobility.
Bringing ubiquity to the Internet access
Carlos J. Bernardos,
Antonio de la Oliva,
María Calderón
Universidad Carlos III de Madrid
Madrid,Spain
{cjbc, aoliva, maria }@it.uc3m.es
Dirk von Hugo,
Holger Kahle
T-Systems International GmbH, Technology Centre
Darmstadt, Germany
[email protected], [email protected]
Abstract— The success of cellular communications networks
shows the interest of users in mobility Terminal mobility support
in IP networks is a first step in the adaptation of these networks
to the needs of users in this field. But, there exists also the need of
supporting the movement of a complete network that changes its
point of attachment to the fixed infrastructure. This demo
presents an implementation of the basic mobility support solution
standardised by the IETF, as well as multicast extensions and
some optimisation mechanisms proposed within the European
DAIDALOS project.
Keywords: Network Mobility, Route Optimisation, NEMO
I. INTRODUCTION
The success of cellular communications networks shows
the interest of users in mobility. These networks are evolving
to provide not only the traditional voice service but also data
services. IP appears to be the base technology of future
networks, to provide all kind of services and through different
access technologies, both fixed and mobile. Nevertheless, IP
was not designed taking into account mobility of users and
terminals, and in fact, IP does not support it, neither in IPv4
nor in IPv6.
The IETF has defined some IP-layer protocols that enable
terminal mobility in IPv4 [1] and IPv6 [2] networks.
Nevertheless, these protocols do not support the movement of
a complete network that moves as a whole changing its point
of attachment to the fixed infrastructure, that is, network
mobility. The IETF created a working group: NEMO (from
Network Mobility), with the aim of extending existing host
mobility solutions to enable the movement of networks in
IPv6.
II. NETWORK MOBILITY IN IPV6
IP networks were not designed for mobile environments.
Both in IPv4 and IPv6, IP addresses play two different roles.
On the one hand, they are locators that specify, based on a
routing system, how to reach the terminal that is using that
address. On the other hand, IP addresses are also part of the
end-point identifiers of a communication, and upper layers use
the identifiers of the peers of a communication to identify it.
The problem of terminal mobility in IP networks has been
studied for a long time within the IETF, and there exist IP-
layer solutions for both IPv4 [1] and IPv6 [2] that enable the
movement of terminals without stopping their ongoing
sessions. Terminal mobility support in IP networks is a first
step in the adaptation of these networks to the needs of users
in this field. But, there exists also the need of supporting the
movement of a complete network that changes its point of
attachment to the fixed infrastructure, maintaining the sessions
of every device of the network: what is known as network
mobility in IP networks [4]. In this case, the mobile network
will have at least a router that connects to the fixed
infrastructure, and the devices of the mobile network will
obtain connectivity to the exterior through this mobile router.
The IP terminal mobility solution does not support, as is now
defined, the movement of networks. Because of that, the IETF
NEMO WG [5] was created to specify a solution, at the IP
layer, to enable network mobility in IPv6.
The terminology used by the NEMO group names a
router that provides connectivity to the mobile network as a
Mobile Router (MR). Devices belonging to the mobile
network – that obtain connectivity through the MR – are
called Mobile Network Nodes (MNNs) and there are different
types: Local Fixed Node (LFN), that is a node that has no
mobility specific software; Local Mobile Node (LMN), that is
a node that implements the Mobile IP protocol and whose
home network is located in the mobile network; and Visiting
Mobile Node (VMN) that is a node that implements the
Mobile IP protocol, has its home network outside the mobile
network, and it is visiting the mobile network.
The network mobility basic solution (see Figure 1) for
IPv6 [6] [11] is conceptually similar to that of terminals. It is
based in the set-up of a bidirectional tunnel between the MR
and its Home Agent (HA). The HA is located in the home
network of the mobile network, that is, in a location where the
addressing of the mobile network is topologically correct. All
the traffic addressed to the mobile network is delivered to its
HA, that send it towards the MR through the tunnel. The MR
removes the tunnel header and forwards the traffic to its
destination within the mobile network. The traffic originated
in the mobile network is sent by the MR towards the HA
through the tunnel, the HA removes the tunnel header and
forwards the packets to their destination.
III. MULTICAST SUPPORT
To support multicast traffic for mobile networks, the MR
can use the bi-directional tunnel (BT) between the HA and the
MR’s CoA located in the visited network. Alternatively a
remote subscription (RS) to a multicast group within the
visited network as described in MIPv6 [2] is feasible. With
respect to multicast traffic to and from mobile networks, the
BT approach may prove inefficient in terms of non-optimal
(triangular) routing, breech of the multicast nature of the flow,
and limited scalability. The main disadvantage of applying RS
for multicast services emerging or terminating within mobile
networks is the required frequent re-construction of the
multicast tree, especially if the traffic source is moving fast,
resulting in high latency and network traffic overhead. The
approach considered in project DAIDALOS consists of
combining both methods depending on current environment
and communication parameters. Upon subscription of a node
within the mobile network to a multicast group or transmission
of multicast traffic, the MR forwards the request or the traffic
to the HA utilising the MLD (Multicast Listener Discovery)
[7] protocol. Subsequently the corresponding data traffic or
group control messages are forwarded by the HA back to the
MR. This proxy functionality of the HA is described in [8]. In
case of reduced mobility of the sub-network detected by
means of low handover (CoA change) rate, the MR initiates
routing of multicast traffic via the remote access point.
IV. ROUTE OPTIMISATION FOR UNICAST FLOWS
The DAIDALOS route optimisation solution for unicast
flows is called MIRON [9], [10]. MIRON is a route
optimisation protocol that mainly deals with two of the
problems introduced by the use of the MR-HA bidirectional
tunnel specified by the NEMO Basic Support protocol [6]: on
the one hand the angular (also called “triangular”) routing
problem, and on the other hand, the multiple tunnels and the
multi-angular (also called “pinball”) routing present in nested
networks (that is, mobile networks that get access for other
mobile networks). In this demo, only the mechanism that
avoids angular routing is shown.
The triangular routing problem is not specific to mobile
networks. MIPv6 mobile hosts encounter the same issue. In
order to solve such inefficiency, MIPv6 defines a route
optimisation procedure, essentially based on the following:
When a communication between a mobile node and any other
end system (called Correspondent Node, CN) is established,
all the traffic – in both directions - initially goes through the
HA. But the mobile terminal can initiate a route optimisation
process by sending location information (i.e., Binding
Updates) directly to the CN. As it has been previously
described, the BUs sent to the HA are protected with IPsec,
but this operation does not seem viable in case of BUs sent to
CNs, as it cannot be assumed that every mobile terminal has a
trusting relationship with every potential CN in the IP
network. Therefore, an alternative mechanism, called Return
Routability (RR) is used. This mechanism is based on the
verification that a node is reachable at the same time through
its Home Address and also through its Care-of Address. In the
approach followed by MIRON to avoid the triangular routing
Figure 1 NEMO Basic Support protocol operation
in the network mobility case, the MR acts as a proxy,
performing the route optimisation procedure with the CN on
behalf of the nodes of the mobile network. In this way, the
MR sends to the CN location information that binds the
MNN’s address to the MR’s CoA. The most important benefit
of MIRON is that it allows a quick deployment of the route
optimisation support in an IP network, like for example
Internet. This is because of two main reasons: first, the route
optimisation is transparent to the nodes of the mobile network,
which is especially relevant for LFNs (i.e., nodes with no
specific mobility software) and, second, it allows using the
MIPv6 route optimisation support already available at the
CNs.
V. DEMO SETUP
The proposed demonstration is based on a prototype
implemented on Linux 2.6.8.1. As it has been described
before, the NEMO Daidalos architecture basically deals with
three different issues: the provision of Network Mobility
support, by implementing part of the NEMO Basic Support
protocol [6], the provision of Multicast support to mobile
networks (since the aforementioned NEMO Basic Support
protocol does not provide support for multicast traffic within a
Mobile Network) and last, but not least, the route optimisation
of unicast traffic (since the use of the bidirectional MR-HA
tunnel introduced by the NEMO Basic Support protocol is
clearly inefficient, in terms of delay, packet overhead and
reliability).
The setup of the demo is shown in Figure 2 and consists
of the following: a laptop/small PC that acts as Home Agent,
two hardware Linksys routers that act as Access Routers, a
laptop that acts as Mobile Router, two other laptops and a
PDA, acting as Local Fixed Nodes and a laptop/small PC
acting as Correspondent Node. All the machines run Linux,
but the PDA, that runs MS Windows Pocket PC 2003.
To show the Basic Network Mobility Support, the Mobile
Network is initially attached to Access Router (AR) 1. Then,
any of the nodes of the Mobile Network starts a
communication with the CN (a UDP video stream served by
the CN), while the complete network moves from AR1 to
AR2. To show the multicast support, two LFNs start playing a
video stream multicast from the CN, while the network roams
between the different access networks. The last part of the
demo shows the route optimisation solution designed in
Daidalos (MIRON) [10]. To illustrate this, a video is streamed
from the CN to this PDA connected to the mobile network,
showing that the traffic is no longer following the suboptimal
LFN-MR=HA-CN path but the direct LFN-MR-CN path. Of
course, as in the previous cases, the mobile network (the car)
may move without breaking the communications.
In the demo, the Correspondent Node can be a node that
is itself mobile, and belongs to a different Daidalos
demonstrator (NIHO demo) that is also shown as an Infocom
demo. This would show the interaction between these two
components of the Daidalos architecture.
Figure 2 Test Network
REFERENCES
[1] C. Perkins, editor; “IP Mobility Support for IPv4”; RFC 3344, Internet Engineering Task Force, August 2002.
[2] D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”; RFC 3775, Internet Engineering Task Force, June 2004.
[3] DAIDALOS Home Page http://www.ist-daidalos.org/
[4] H.-Y. Lach, et al, "Network Mobility in Beyond-3G Systems", IEEE Communications Magazine, Vol. 41, Issue 7, July 2003.
[5] IETF Network Mobility (NEMO) Working Group: http://www.ietf.org/html.charters/nemo-charter.html
[6] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, Pascal Thubert, “Network Mobility (NEMO) Basic Support Protocol”; RFC 3963, Internet Engineering Task Force, January 2005.
[7] R. Vida, L. Costa (editors), “Multicast Listener Discovery Version 2 (MLDv2) for IPv6”; RFC 3810, Internet Engineering Task Force, June 2004.
[8] C. Janneteau et al., “IPv6 Multicast for Mobile Networks with MLD-Proxy”; IETF Internet Draft, draft-janneteau-nemo-multicast-mldproxy-00.txt, work in progress, April 2004
[9] C. J. Bernardos, M. Bagnulo, M. Calderón, I. Soto, “Mobile IPv6 Route Optimisation for Network Mobility (MIRON)”, draft-bernardos-nemo-miron-00.txt, work-in-progress, July 2005
[10] M. Calderón, C. J. Bernardos, M. Bagnulo, I. Soto, A. de la Oliva, “Design and Experimental Evaluation of a Route Optimisation Solution for NEMO”, to appear in Journal on Selected Areas in Communications, issue on Mobile Routers and Network Mobility
[11] A. de la Oliva, C. J. Bernardos, M. Calderón, “Practical evaluation of a network mobility solution” EUNICE 2005: Networked Applications - 11th Open European Summer School, July 2005