Internet Engineering Task Force Martin Johnsson
INTERNET-DRAFT Ericsson
draft-ietf-mobileip-simple-01.txt March, 1999
Simple Mobile IP (SMIP)
Status Of This Memo
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 otherdocuments 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
This document describes an alternative to the support for IP mobility compared
to the solution outlined and specified in [MobIP]. As the title of the solution
implies, it addresses the problems with the overall complexity of the current
Mobile IP solution including some of the proposed extensions as outlined in
[RouteOpt], [3G-IMT]. This more simplistic approach relies on two basic
prerequisites: Development made in recent years, and also development foreseen
in a near-term future, regarding certain key protocols and techniques for name-
to-address resolution, directory services, address assignment, and roaming
support; and also the fact that the solution is suited for usage within one
organizational scope.
Johnsson Expires September, 1999 [Page 1]
INTERNET DRAFT SMIP March, 1999
1.0 Introduction
The support for IP mobility as specified in [MobIP] relies on the concept of
home agent (HA) and foreign agent (FA). The home agent resides on the same IP
subnet as the mobile terminal (MT) is normally connected to, and a foreign
agent resides on subnets which mobile terminals may visit. Through the use of a
fixed IP address and a care-of address assigned to the MT , the user may
connect its terminal to some other subnet besides the subnet which the terminal
is normally connected to. IP packets destined for the MT will be forwarded by
the HA to the FA and then finally to the MT (by means of tunneling). Packets
from the MT can be sent directly towards its destination.
The solution has several drawbacks (some just a result of evolving
technologies, no offense):
- triangular routing, i.e. assymetric routing with respect to topology
- inefficient use of link resources through the use of tunneling which may span
a large number of router hops
- support for QoS is not straightforward with triangular routing
- inefficient use of network resources through non-optimal routing
- the use of a fixed (and public) IP address, which is not the normal case in
today's Internet and intranets
To address at least some of these drawbacks, one basically has to look for a
more symmetric and distributed solution, possibly as similar as possible as the
solution in use for fix terminals, with the addition of the need for support
for mobility. It is also then possible to let the solution rely on existing
protocols, or protocols/technologies under development. In this context, it is
important to distinguish between session mobility and user mobility:
Session mobility: Applications and TCP sessions will not be affected by the
fact that the terminal is moving within and between subnets, except for some
packet loss which may result out from a handover between radio base stations.
User mobility: A user of an MT which may get connected to a subnet within the
context of an administrative domain, e.g. an intranet.
For datacom-type of applications, e.g. Web browsing, the requirement is to
support session mobility throughout a geographical area which has continious
radio coverage. Typical examples of such areas are buildings, campuses, and
public "hot spots" like hotels, conference centers, airports.
Regarding user mobility, the requirement is that it doesn't need to be better
than what is supported for fix terminals, though it should be noted that mobile
terminals may drive the need for increased support for user mobility. The
latter becomes more and more evident with the introduction of nomadic computing
and the nomadic office. Clearly, this means that the notion of "home" and
"foreign" don't make sense anymore. As a consequence, those concepts have been
removed and instead been renewed in this memo.
This background, prerequistes, and requirements, is the foundation for the
solution outlined in this memo.
Johnsson Expires September, 1999 [Page 2]
INTERNET DRAFT SMIP March, 1999
2.0 A reference model
The following reference model is referred to in the following sections
describing the protocol layout and basic procedures.
|-------------------- Mobile LAN -------------------|
|------------- Local LAN ------------|
+----+ +---+ +----+ +-----+
| | Air Interf. | | Fixed LAN | | | |
| MT |- - - - - - - |RBS|------------| LR |--------| MER |
| | | | | | | |
+----+ +---+ +----+ +-----+
FIGURE 1. SMIP Reference Model
A Mobile Terminal (MT) connects to a LAN through the Radio Base Station (RBS)
via the air interface, e.g. Hiperlan 2 or 802.11. The RBS functions as a bridge
on the LAN. The Local Router (LR) routes packets to/from the subnet which the
MT is currently connected to. The Mobility-Enabled Router (MER) is a router
handling routing packets to and from Mobile LANs (MLAN). Each MT is connected
to an MLAN as well as a local LAN. Thus, an MT has two IP addresses for one
network interface (the air interface in this case); one reflecting connectivity
to the local LAN handled by LR, and one IP address reflecting connectivity to
the MLAN. An LLAN may have both wireless and fixed hosts connected to it, while
an MLAN only has wireless hosts connected.
As the MT is moving, the connectivity towards the local LAN is changing, and
thus also the IP address reflecting this change in local LAN connectivity. The
IP address reflecting the MLAN connectivity is never changing.
The protocol reference model for the MT is depicted in figure 2 below.
+-----------+
|Application|
+-----------+
| Transport |
+-----------+
| IP-MLAN |
+-----------+
| IP-LLAN |
+-----------+
| Link |
+-----------+
| Physical |
+-----------+
FIGURE 2. MT protocol reference model.
Johnsson Expires September, 1999 [Page 3]
INTERNET DRAFT SMIP March, 1999
The two levels of IP are stacked on top of each other, just like IP-in-IP
tunneling as defined in [IP-TNL]. As descibed above and according to the
protocol reference model, the transport layer will not experience any change in
IP address.
Other protocols of importance for the solution, and which are not shown in
figure 2, are DHCP and the optional use of IPsec protocols. The use of these
protocols will be further detailed below.
3. Protocols and procedures
3.1 Bootup phase
In the bootup phase, it is proposed that the MT accuires the two IP addresses
needed for the two IP layers, IP-MLAN and IP-LLAN, by means of extensions
through a set of new options to DHCP.
During the bootup phase, the MT will also retrieve information via DHCP about
the address of the MER handling the MLAN to which the MT is connected to.
3.2 IP packet handling
3.2.1 IP packet handling at the MT
The transport layer will submit packets for transmission to IP-MLAN. IP-MLAN
will set the source IP address to the address corresponding to the IP address
of the MLAN, and the destination IP address to the address of the packet's
final destination. IP-MLAN will in turn submit the IP packet to IP-LLAN. IP-
LLAN will set the source IP address to the address corresponding to the IP
address of the LLAN, and the destination IP address to the address of the MER.
Finally, the address is submitted to the link and physical layers for
transmission over the local LAN.
Upon reception, IP packets from the physical and link layers are delivered to
IP-LLAN. The contents of the IP header is checked to specifically verify that
the source IP address is the address of the MER. The IP header for the IP-LLAN
layer is then stripped off, and then the contents left of the packet is
delivered to the IP-MLAN layer. The IP-MLAN strips off the IP header of this
layer, and finally the packet is delivered to the transport layer.
3.2.2 IP packet handling at LR
Packets from the MT will be routed to the MER by LR as indicated by the IP
destination address.
Packets to the MT will be routed onto the local LAN which the MT is connected
to.
Johnsson Expires September, 1999 [Page 4]
INTERNET DRAFT SMIP March, 1999
3.2.3 IP packet handling at MER
MER will receive packets from MTs destined for the MER itself. MER strips off
the IP header of this packet, and then uses the information in the IP header
related to MLAN for purposes of routing the packet to its final destination.
Packets received by the MER with an destination IP address associated to an MT
on an MLAN, will be encapsulated into an IP packet. The source IP address is
set to the address of MER, and the destination IP address to the address of the
MT pertaining to the local LAN which the MT is currently connected to.
3.3 IP mobility handling
As the MT moves, a shift may occur with respect to the connectivity to the
local LAN. It is currently out of the scope of this memo how an MT discovers
that a shift is underway with respect to LLAN. But for example, the protocols
at the air interface may include protocol support for indicating this shift in
connectivity. The current version of this memo only deals with the handling of
the IP connectivity and the correlation between MLAN and LLAN, and also the
necessary change of IP address at the IP-LLAN level due to change in LLAN
connectivity.
3.3.1 IP connectivity
As with fixed terminals, there is no need to advertise connectivity between an
MT and a router on a LAN (LR and MER in the SMIP case).
3.3.2 MLAN - LLAN correlation
To enable correct routing of messages from the MER towards an MT, the MER must
at each instance of time know the current location of the MT, i.e. to know
which LLAN the MT is currently connected to. Due to a possible movement of the
terminal, this connectivity may change over time. Thus, the MER must receive
indications about an MT's current location.
It is proposed that the MLAN - LLAN binding has limited lifetime, and thus the
binding must be periodically refreshed to avoid timer expiration. In addition,
it is also proposed that the MT triggers an update of this binding to the MER
whenever a change in this mapping occurs. If the timer expires, the mapping
shall be removed by the MER, and MER shall treat the MT as being unreachable.
This memo proposes to use an extension to ICMP for handling of IP connectivity
and correlation between MLAN and LLAN. The procedure of using an ICMP message
for this purpose, is to send an ICMP both periodically and triggered according
to the above description.
Johnsson Expires September, 1999 [Page 5]
INTERNET DRAFT SMIP March, 1999
3.3.3 IP address for LLAN connectivity
Due to the movement of the MT, LLAN connectivity may change, and thus the IP
address reflecting this connectivity.
It is proposed that when the MT receives an indication that an handover between
RBSs results in that the MT moves from one LLAN to another, the MT requests a
new IP address for the LLAN level by means of a possible set of new options to
DHCP.
3.3.4 Moving out and within radio coverage
An MT may temporarily be moved out of the range of radio coverage from RBSs,
and later once again be moved within the range of radio coverage. This is
similar as unplugging and then replug a fix terminal to a LAN.
When an MT detects that it once again is connected to a local LAN, it is
proposed that the MT reinitiates DHCP requests for the two IP addressess
reflecting connectivity towards an LLAN and an MLAN. This may in turn lead to
that the MT will be assigned new IP addresses for one or both of the two IP
levels. DHCP may need to be extended with a set of new options to support this
scenario.
3.4 Security support
IPsec protocols such as the Authentication Header and the Encapsulating
Security Payload defined in [AH] and [ESP] respectively, may be inserted
between the two IP headers of the IP-LLAN and IP-MLAN levels. The rules that
govern the use of IPsec protocols shall comply to the IPsec protocol suite of
recommendations when using IPsec in tunnel mode of operation.
Other security mechanisms may be supported as well, for instance on the
transport level, but that is outside the scope of this memo.
3.5 ARP and broadcasts
As the MLAN is "virtual" in the sense that the mapping between the logical and
physical structure of the MLAN is not one-to-one, e.g. it may include router
hops, the Address Resolution Protocol as defined in [ARP] shall not be used. It
shall also be specifically noted that for clarity and consistency the MT shall
be, with respect to addressing, associated to the address of the IP-MLAN level.
This results in that all traffic to/from an MT must pass through the MER.
But, for the purpose of conserving bandwidth, and to make most efficient use of
network resources, ARP may be used to forward traffic directly between the
source and the destination hosts, iff they are located on the same LLAN. In
this case, the IP-LLAN protocol layer is "empty", i.e. no IP header is added by
IP-LLAN.
Johnsson Expires September, 1999 [Page 6]
INTERNET DRAFT SMIP March, 1999
The assymetric traits of this option with respect to routing shall be used with
great care.
Other forms of broadcasts are sent just as unicast packets encapsulated to the MER, which will retransmit the broadcast encapsulated in unicast packets to all MTs on the MLAN.
3.6 Multicast
In IP, the Internet Group Management Protocol as defined in [IGMP] is the
foundation for group membership registration. A host reports group membership
to its local router by responding to group membership queries. The important
characteristic to note about IP multicast in this scope of work, is that it is
receiver-oriented, meaning that IP multicast addresses indicates a set of
destination hosts, i.e. those being members of a certain group. It has nothing
to do with the source IP address of a host.
With respect to mobility, the IP multicast paradigm is well suited to serve
also this aspect of connectivity, as both IGMP and the different routing
protocols for multicast rely on the soft state concept. As a result, the graph
of the distribution tree for a multicast group adapts depending on the current
locations of group members.
3.6.1 Receiving multicast
The discussion above results in that an MT with respect to IP multicast and
traffic directed towards an MT (i.e. MT is a group member), works exactly the
same as for fixed terminals. This means that the IP-MLAN layer is "empty" in
this direction of traffic.
One issue though may arise in the event of IGMP version 3 [IGMPv3]. In this
case, a member may indicate from which sender(s) the member host is willing to
receive IP multicast packets from. This may lead to the need for specifically
indicating the very source of a membership report, which then must correspond
to the address of the IP-MLAN. This is still for further study.
3.6.2 Transmitting multicast
When transmitting multicast packets, the source of the packets must equal the
address of the IP-MLAN level for reasons of consistency. Thus, IP multicast
packets are transmitted in the same way as unicast packets described above in
section 3.
This may lead to non-optimal distribution trees for IP multicast, especially
for those members which are nearer to the MT source than the MER. Possible
work-arounds or alternative solutions can quite easily be deduced, e.g.
snooping into tunneled datagram or shortcutting the IP-LLAN level, but this is
for further study.
Johnsson Expires September, 1999 [Page 7]
INTERNET DRAFT SMIP March, 1999
An alternative option would be to transmit the multicast packets
unencapsulated, i.e. by shortcutting the IP-LLAN level.
4. Miscelleneaous
4.1 DNS
The DNS will resolve to addresses corresponding to the IP-MLAN level. Regarding
the IP-LLAN level, this address is invisible to DNS.
4.2 DHCP servers and MER/MLAN relation
The DHCP servers will through the responses back to the MT, give proposal(s) as
to which MER the MT can use and establish connectivity. The proposal should
preferably be based on the current location of the MT, i.e. LLAN connectivity,
and what MER(s) that are available in the "neighborhood" of MT's current
location. Proposals on MER may also be based on some estimate of how the MT may
move around, which results in some kind of judgement of tradeoffs based on
routing performance, QoS, etc.
This is not part of the current scope of this memo to define any algorithms or
rules, that can be used to decide upon appropriate proposal(s) on MER(s). For
the time being, it will be up to the management of DHCP servers to configure
appropriate MER proposals.
4.3 QoS
QoS is a difficult and still pending issue also for fixed terminals, and
becomes emphasized and highlighted for mobile terminals. On the IP layer, an MT
may make use of either of the two proposed solutions for QoS provisioning
defined as of today: Integrated Services using RSVP or Differentiated Services
(DiffServ) using the DS field in the IP header.
The main issue in SMIP as outlined in this memo, is the IP tunnel between the
MT and the MER, and of course the fact that the terminal is mobile.
Regarding RSVP, [RSVP-Tnl] describes how end-to-end RSVP sessions map to tunnel
sessions. Due to the aspect of a mobile terminal, the reservations for the
tunnel between the MT and the MER must be created dynamically on demand, which
is outlined as one of the options in [RSVP-Tnl].
Regarding DiffServ as defined in [DiffServ], there are no specific rules as how
to perform mapping of a service indicated by the DS field between an end-to-end
service and the service for a tunnel. This will be a matter of local policies.
Johnsson Expires September, 1999 [Page 8]
INTERNET DRAFT SMIP March, 1999
4.4 Handover between MERs
It could be envisaged that the need for session mobilility should be extended
beyond the limitation of connectivity to one MER, meaning that a "handover"
would be performed from one MER to another, possibly leading to a change in
MLAN connectivity, depending on how to solve this form of mobility. The support
for session mobility between MERs is for further study.
5. Notice Regarding Intellectual Property Rights
Ericsson may seek patent or other intellectual property protection
for some or all of the technologies disclosed in this document. If any
standards arising from this disclosure are or become protected by one or
more patents assigned to Ericsson, Ericsson intends to disclose
those patents and license them on reasonable and non-discriminatory
terms. Future revisions of this draft may contain additional information
regarding specific intellectual property protection sought or received.
6. References
[3G-IMT] : IP Mobility Architecture Framework, C. B. Becker et al,
Work in Progress
[AH]: IP Authentication Header, S. Kent et al, RFC 2402
[ARP]: Ethernet Address Resolution Protocol., D. C. Plummer, RFC 826
[DiffServ]: An Architecture for Differentiated Services, S. Blake et al,
RFC 2475
[ESP] : IP Encapsulating Security Payload, S. Kent et al, RFC 2406
[IGMP] : Internet Group Management Protocol, Version 2, W. Fenner, RFC 2236
[IGMPv3] : Internet Group Management Protocol, Version 3, B. Cain et al,
Work in Progress
[IP-Tnl]: IP Encapsulation within IP, C. Perkins, RFC 2003
[MobIP]: IP Mobility Support, C. Perkins, RFC 2002
[Route-Opt] : Route Optimization in Mobile IP, C. Perkins et al,
Work in Progress
[RSVP-Tnl] : RSVP Operation over IP Tunnels, A. Terzis et al, Work in Progress
Johnsson Expires September, 1999 [Page 9]
INTERNET DRAFT SMIP March, 1999
7. Authors' Address
Martin Johnsson
Ericsson Radio Systems
Wireless LAN Systems
Esplanaden 3C
SE-164 80 Stockholm, Sweden
Martin.Johnsson@era.ericsson.se
Johnsson Expires September, 1999 [Page 10]
INTERNET DRAFT SMIP March, 1999
