Mobile IP Working Group Eva Gustafsson, Ericsson, Editor
INTERNET-DRAFT February 1999
Expires August 1999
Annika Jonsson, Ericsson
Elisabeth Hubbard, Telia
Jonas Malmkvist, Telia
Anders Roos, Telia
Requirements on Mobile IP from a Cellular Perspective
<draft-ietf-mobileip-cellular-requirements-00.txt>
Status of this memo
This document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@smallworks.com mailing list. Distribution of this
memo is unlimited.
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The increasing interest in Mobile IP as a potential macro-mobility
solution for cellular networks leads to new solutions and extensions
to the existing protocol. There is also a need to put together the
demands on Mobile IP, from a cellular perspective, in order to
harmonize the evolution of Mobile IP and the existing mobility
solutions in cellular networks.
This draft lists a first set of requirements on Mobile IP for use in
cellular networks, for instance IMT-2000, and relates the requirements
to proposed solutions. These requirements consider Mobile IPv4, but
the list will be extended for Mobile IPv6 as well.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 1]
Table of contents
1. Introduction......................................................2
2. General requirements..............................................3
3. Authentication....................................................4
4. Surrogate registrations...........................................5
5. Private networks..................................................6
6. Reverse tunnelling................................................6
7. Route optimization................................................7
8. Dynamic home address assignment...................................8
9. Dynamic home agent assignment.....................................8
10. Handover performance.............................................8
11. Conclusions......................................................9
12. Acknowledgements.................................................9
13. References.......................................................9
14. Author's address................................................11
1. Introduction
Recently, there has been an increasing interest in Mobile IP as a
potential future mobility standard, common to cellular systems and the
Internet as a whole [11]. The benefits of adopting a common mobility
solution would include independence of access network technologies,
common solutions for fixed and wireless networks, and ultimately a
world-wide acknowledged mobility standard.
The purpose of this document is to state a first version of the
requirements on Mobile IP as a potential macro-mobility solution for
cellular networks. The requirements in this document mainly refer to
Mobile IPv4 [14] and its extension drafts, but the list of requirements
will be extended for Mobile IPv6 [12] as well.
One important aspect on the requirements is the compatibility with
existing solutions, for instance the GPRS Tunnelling Protocol (GTP). The
General Packet Radio Service (GPRS) will be deployed in GSM cellular
mobile systems starting 1999, giving IP mobility service to potentially
hundreds of millions of users. The GSM/GPRS standard is evolving into
the third generation systems: Universal Mobile Telecommunication System
(UMTS) and the Enhanced Data rates for GSM Evolution (EDGE). These will,
like Cdma2000, fulfil the ITU requirements for third generation mobile
systems, IMT-2000.
We start in Section 2 by describing some general requirements for IP
mobility in cellular networks. Then we list more specific requirements
in Section 3 through Section 10. Section 11 concludes the document.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 2]
2. General requirements
To allow Mobile IP to be a mobility solution which supports many
different kinds of access networks/technologies, the Mobile IP
functionality shall be independent of the access network technology. For
Mobile IP to be deployed in future cellular networks, it also needs to
provide compatibility with existing protocols, for instance GTP.
Mobile IP provides authentication of the signalling messages [14]. For
security reasons, such as keeping the current location of a user unknown
to other users, it should also be possible to provide encryption of the
Mobile IP signalling. This may be implemented through, for instance,
IPSec tunnels and security associations established on a permanent basis
inside and between different administrative domains. It should also be
possible to provide encryption of the traffic. A solution is to employ
IPSec together with Mobile IP, as suggested in [19].
As emerging Internet quality-of-service mechanisms are expected to
enable a wide-spread use of real-time services between stationary nodes,
for instance voice over IP and videoconferencing, there will be a demand
for using the same kind of services when being mobile. Promising a
certain level of quality of service to a mobile user is generally
difficult, since there may not be enough resources available in the part
of the network that the mobile node is moving into. However, when network
resources allow, there should be mechanisms to handle quality of service
for mobile users, particularly in case of reverse tunnelling, route
optimization and handover. The differences between stationary and mobile
nodes making use of quality-of-service mechanisms should also be
minimized. An application requesting a quality-of-service level should
not need to be mobile aware, and network operators should not need to
employ different quality of service platforms for stationary and mobile
users. The emerging quality-of-service architectures, Integrated
Services and Differentiated Services [3][4][17][18], do not consider
mobile nodes. Additions or changes may be needed.
Quality-of-service mechanisms enforce a differentiated sharing of
bandwidth among different services and different users. Thus, there must
be mechanisms available to identify traffic flows with different
quality-of-service attributes, and to make it possible to charge the
different users accordingly.
It is well known that mobile nodes are more complex to handle than
stationary ones. Anyway, the extra handling of mobile nodes should be
based on the same basic mechanisms as the stationary ones, rather than
on separate mechanisms. Among these basic mechanisms are (i) an
Authentication, Authorization, Accounting (AAA) infrastructure; (ii)
quality of service and policy control; and (iii) directory services and
gateway services like IP telephony.
Lastly, as more and more users become mobile, the need for a uniform
service delivery across various access technologies increases.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 3]
Ultimately, the user should not need to know what kind of access
technology is in use at a particular moment. When bandwidth and other
network capabilities allow, IP-based services should appear the same way
independently of the access technology. Moreover, a normal user will try
to employ the most efficient access, considering capacity and cost,
which means that changes of access technology can be expected during
active sessions. Thus, the change of access technology should be as
smooth and as transparent to the user as possible.
These are the general requirements; some of them apply to Mobile IP and
some may be fulfilled through other protocols and solutions. The
following sections address more specific requirements on Mobile IP for
use in a cellular environment, in order to provide solutions
satisfactory for operators as well as end users.
3. Authentication
The authentication of a mobile node or user can be performed at different
locations and be based upon different parameters. We may also consider
two phases of the authentication procedure: initial or full
authentication and subsequent authentications. Full authentication is
performed when the existing security associations are insufficient, for
instance at initial registration, or when a mobile node requests a new
home agent. Subsequent authentications are performed at handover, that
is, when a mobile node changes its point of attachment within the same
administrative domain, or to renew bindings before they are timed out.
The Mobile IP protocol specifies registrations to be performed at the
home agent, and to be based on the home IP address of the mobile node
[14]. However, additional solutions and extensions to Mobile IP have
introduced identification and authentication based on the Network Access
Identifier (NAI) [1][2][5][6][7][8][9]. Basing the authentication on
the IP address means that it is the host that is authenticated, while
authentication based on the NAI results in authentication of the mobile
user. The latter alternative would alleviate the connection between a
specific user and a specific host, and provide a secure way for dynamic
allocation of IP addresses. Therefore, we advocate the full
authentication to be based on a unique user identity, for example the
NAI.
Furthermore, the full authentication should not be performed at the home
agent, since the home agent may be dynamically allocated. Instead, it
should be performed at the home network or home administrative domain
as suggested in [5][7], for instance through AAA functionality.
For reasons of subscription handling and charging, the full
authentication should always be performed at the home domain or by the
home operator, that is, where the user has its subscription. However,
once a mobile node is connected to a visited network, performing
subsequent authentications at the home domain could result in
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 4]
significant signalling delay. To minimize the signalling delay, and to
reduce the signalling between the visited and the home network, it
should be possible to perform subsequent authentications in the visited
network, as described in [5].
Finally, since the Mobile IP protocol shall allow independence of the
access network technology, the Mobile IP authentication should be
independent of the authentication for the access, for instance the radio
resources. A separation of the authentication procedures is motivated
by the fact that radio resources are scarce, and an access network
operator may not want to allow Mobile IP signalling until the access
network in itself has accepted to provide resources for a mobile node.
Also, different access networks with, for instance, radio-based or fixed
access, experience different types of security threats, and may address
them differently.
The requirements for the authentication procedure are:
1. It should be possible to perform Mobile IP authentication without
interaction with the access network / radio resources.
2. There must be a generic Mobile IP authentication procedure,
specifying full and subsequent authentication, as well as authentication
for surrogate registrations.
3. Full authentication must be performed with the home network, the
home administrative domain or with the home operator of the mobile user.
4. There must be a unique user identity for full authentication, for
instance the NAI [2].
5. It should be possible to perform subsequent authentication locally
at the visited network.
6. Mobile IP should use the same authentication infrastructure as
stationary Internet nodes.
4. Surrogate registrations
In access networks that have sufficient lower-level signalling, Mobile
IP registrations between the mobile node and the foreign agent are
unnecessary. Such situations are supported by surrogate registrations
as described in [6].
For reasons of backward compatibility with existing systems, it must be
possible to implement Mobile IP, for instance in GPRS networks, without
introducing Mobile IP signalling in the terminal. Surrogate
registrations provide such a solution. They also provide a means to
minimize the signalling over the radio link, and shall therefore be
included in Mobile IP.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 5]
The requirements for surrogate registrations are:
1. It must be possible to employ Mobile IP in a network without
introducing Mobile IP signalling in the terminal.
2. Secure full and subsequent authentication for surrogate
registrations must be ensured according to the generic authentication
procedure for Mobile IP.
5. Private networks
Since private networks are an important part of the communication
network structure, Mobile IP must support private networks and private
address spaces. A proposed solution is to support private address spaces
through proxy home and foreign agents [5]. This solution also supports
hierarchical foreign agents within a network. Such a hierarchy may be
valuable in order to improve handover performance. It may also be
important for security reasons, since it allows the existence of agents
without direct connection to external agents, that is, agents external
to for instance a private network. Since most private networks are
protected by firewalls, Mobile IP must provide a means for signalling
and traffic to pass these firewalls.
Larger private networks may provide their own home agents, but there is
also the case where one operator provides a home agent which is shared
by several smaller private networks. Then, a mobile node may want access
to a private network which is not its home network. In this case, we
recognize a need for the VPN Identifier Extension in the registration
request [6]. The NAI of a mobile user points out the home network of the
user and the VPN Identifier Extension points out the final destination
of the tunnel.
The requirements for support of private networks are:
1. Support of private address spaces must be included in Mobile IP.
2. Mobile IP must support proxy agents and hierarchical agents.
3. Mobile IP must provide a means for signalling and traffic to pass
through firewalls.
4. The VPN Identifier Extension must be supported in Mobile IP.
6. Reverse tunnelling
The Mobile IP protocol, as specified in [14], is built on the concept
of triangular routing. Reverse tunnelling has been suggested as an
addition to Mobile IP, to support topologically correct reverse tunnels
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 6]
[13]. For reasons of security and charging, it must be possible for a
network operator to employ reverse tunnelling, and to refuse mobile
nodes, or surrogate agents, which do not request reverse tunnelling when
required. It must also be possible to employ encryption of the traffic
with reverse tunnelling. In the case of private networks, it should be
possible to choose how to employ reverse tunnelling: all the way to the
home agent, to the proxy home agent, or only to the proxy foreign agent.
The requirements for reverse tunnelling are:
1. It must be possible to employ reverse tunnelling together with Mobile
IP.
2. A network operator must be able to refuse mobile nodes, or surrogate
agents, which do not request reverse tunnelling when required.
3. With private networks, it should be possible to employ reverse
tunnelling to the home agent, to the proxy home agent or to the proxy
foreign agent.
7. Route optimization
New access techniques are expected to give users significantly more
bandwidth than today, which will lead to more traffic in the backbone
networks. Thus, it is important to minimize the load on the backbone
through efficient routing. In the Mobile IP protocol, datagrams destined
to a mobile node are sent to its home address and are tunnelled by its
home agent to the current care-of address [14]. Route optimization is a
suggested addition to Mobile IP, which allows correspondent nodes to
send datagrams directly to a mobile node [16][15]. In order to minimize
the delay, and to optimize the utilization of network resources, it
shall be possible for an operator to employ route optimization.
Especially, this would improve the performance for two mobile nodes
located in a visited network, which are communicating with each other.
The authentication procedure for route optimization must be according
to the generic authentication procedure for Mobile IP, and there must
be a secure way to distribute information of the current address of a
mobile node. If requested, encryption must also be ensured for the
traffic. Integrated and Differentiated services [3][4][17][18] do not
always handle the change from triangular to optimized routing in a
smooth way. Mobile IP extensions or changes may be needed. Lastly,
choosing the optimal route, with respect to the number of hops, may
result in a lower level of quality of service. In order to maintain a
negotiated quality of service, the quality-of-service mechanisms may
need to interact with the route optimization mechanisms.
The requirements for route optimization are:
1. It must be possible to employ route optimization together with Mobile
IP.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 7]
2. It should be possible to employ quality-of-service mechanisms
together with route optimization.
8. Dynamic home address assignment
A solution for dynamic home address assignment is proposed in [8].
Dynamic assignment of the home address provides a means to better
utilize the IP addresses at the home sub-network. Moreover, in case the
home agent is dynamically assigned the home address needs to be
dynamically assigned as well, since the home address must belong to the
same sub-network as the home agent [14]. The dynamic assignment of home
addresses is in conflict with the use of the home address as the mobile
node identifier in [14], and a different identifier is required. In [8],
the NAI is employed for identification.
The requirements for dynamic address assignment are:
1. Dynamic home address assignment must be included in Mobile IP.
9. Dynamic home agent assignment
In addition to dynamically assigned home addresses, there is a need for
dynamic allocation of the home agent. A dynamically allocated home agent
in the visited network can, for instance, improve the routing
performance. It shall be possible for a mobile node, or a surrogate
agent, to request and obtain a dynamically assigned home agent in the
home network or in the visited network. It shall also be possible for a
mobile node which has obtained a dynamically assigned home agent in a
visited network, to keep this home agent when moving to another network.
A solution for dynamic home agent assignment, fulfilling these
requirements, has been suggested in [9].
The requirements for dynamic home agent assignment are:
1. Dynamic home agent assignment must be included in Mobile IP.
2. It must be possible for a mobile node, or a surrogate agent, to
request and be assigned a dynamic home agent either in the home network
or in the visited network.
3. A mobile node which has been assigned a dynamic home agent in a
visited network must be able to keep this home agent when moving to
another network.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 8]
10. Handover performance
Mobile IP, as specified in [14], does not provide seamless/loss-less
handover between different foreign agents within the same administrative
domain. The existing solution may be acceptable for certain non-delay-
sensitive and loss-tolerant applications, but needs to be improved in
order to support for instance real-time applications.
There have been suggestions on how to improve the handover performance,
in terms of making the signalling procedure faster [5][10][16]. However,
the handover performance still needs to be improved in order to support
for instance real-time applications, or to support loss-less handover.
The requirements for handover are:
1. The handover performance, in terms of loss and delay, must be
improved to support real-time and loss-sensitive applications.
11. Conclusions
This draft provides a first list of requirements on Mobile IPv4 for use
in cellular networks, such as IMT-2000. Beside the general requirements
on functionality and security, there are specific requirements on
authentication, address assignment, routing and issues providing
backward compatibility to existing solutions, for instance GTP.
All the requirements provided in this draft may not be necessary in a
first step of introducing Mobile IP in cellular networks. However, we
believe that they all need to be considered to eventually support all
various demands from different operators and end users. The requirements
list will also be extended for Mobile IPv6.
12. Acknowledgements
The authors would like to thank Henrik Basilier, Martin Korling, Lars
Westberg, Anders Herlitz, Yuri Ismailov, Ulf Olsson, Thomas Eklund and
Georg Chambert at Ericsson for their valuable comments.
13. References
[1] B. Aboba: "Support for Mobile IP in Roaming", Internet draft
(expired), draft-ietf-roamops-mobileip-01.txt, March 1998.
[2] B. Aboba, M. Beadles: "The Network Access Identifier", RFC 2486,
January 1999.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 9]
[3] S. Blake, Editor: "A Framework for Differentiated Services",
Internet draft (work in progress), draft-ietf-diffserv-framework-01,
October 1998.
[4] S. Blake, Editor: "An Architecture for Differentiated Services", RFC
2475, December 1998.
[5] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Mobile IP Regionalized
Tunnel Management", Internet draft (work in progress), draft-ietf-
mobileip-reg-tunnel-00.txt, November 1998.
[6] P.R. Calhoun, G. Montenegro, C.E. Perkins: "Tunnel Establishment
Protocol", Internet draft (expired), draft-ietf-mobileip-calhoun-tep-
01.txt, March 1998.
[7] P.R. Calhoun, C.E. Perkins: "DIAMETER Mobile IP Extensions",
Internet draft (work in progress), draft-calhoun-diameter-mobileip-
01.txt, November 1998
[8] P.R. Calhoun, C.E. Perkins: "Mobile IP Dynamic Home Address
Allocation Extension", Internet draft (work in progress), draft-ietf-
mobileip-home-addr-alloc-00.txt, November 1998.
[9] P.R. Calhoun, C.E. Perkins: "Mobile IP Foreign Agent
Challenge/Response Extension", Internet draft (work in progress),
draft-ietf-mobileip-challenge-00.txt, November 1998.
[10] M. Chuah, A. Yan, Y. Li: "Distributed Registrations Enhancements
to Mobile IP", Internet draft (work in progress), draft-chuali-mobileip-
dremip-02.txt, November 1998.
[11] E. Gustafsson, A. Herlitz, A. Jonsson, M. Korling: "UMTS/IMT-2000
and Mobile IP/DIAMETER Harmonization", Internet draft (work in
progress), draft-gustafsson-mobileip-imt-2000-00.txt, November 1998.
[12] D.B. Johnson, C. Perkins: "Mobility Support in IPv6", Internet
draft (work in progress), draft-ietf-mobileip-ipv6-07.txt, November
1998.
[13] G. Montenegro: "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[14] C. Perkins, Editor: "IP Mobility Support", RFC 2002, October 1996.
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 10]
[15] C. Perkins, D.B. Johnson: "Registration Keys for Route
Optimization", Internet draft (expired), draft-ietf-mobileip-regkey-
00.txt, November 1997.
[16] C. Perkins, D.B. Johnson: "Route Optimization in Mobile IP",
Internet draft (expired), draft-ietf-mobileip-optim-07.txt, November
1997.
[17] S. Shenker, J. Wroclawski: "General Characterization Parameters for
Integrated Service Network Elements", RFC 2215, September 1997.
[18] S. Shenker, J. Wroclawski: "Network Element Service Specification
Template", RFC 2216, September 1997.
[19] J.K. Zao, M. Condell: "Use of IPSec in Mobile IP", Internet draft
(expired), draft-ietf-mobileip-ipsec-use-00.txt, November 1997.
14. Author's address
Eva Gustafsson, Annika Jonsson
Ericsson Radio Systems AB
Network and Systems Research
SE-164 80 Stockholm
SWEDEN
{eva.m.gustafsson | annika.jonsson}@era.ericsson.se
Elisabeth Hubbard, Jonas Malmkvist, Anders Roos
Telia Research AB
Network Research
Vitsandsgatan 9
SE-123 86 Farsta
SWEDEN
{elisabeth.a.hubbard | jonas.x.malmkvist | anders.g.roos}@telia.se
<draft-ietf-mobileip-cellular-requirements-00.txt> [Page 11]
Expires August 1999
