[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02
INTERNET-DRAFT A. O'Neill
Internet Engineering Task Force BT Laboratories
draft-oneill-ema-00.txt S. Corson
University of Maryland
Ansible Systems
22 October 1999
Edge Mobility Architecture
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 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
This draft concurs with the authors of Cellular IP and HAWAII
regarding the need for domain-based routing support in handling edge
mobility. It suggests that a general routing solution might be
advantageous and presents the loose framework of a possible routing
architecture. It advocates the creation of a specific IETF working
group to address an overall architecture for edge mobility routing,
specific extensions to existing routing protocols to accomplish that
architecture, and extensions to existing Internet technologies to
support this architecture.
1. Introduction
Internet routing protocols have been traditionally designed from an
assumption that the location of an IP interface in the topology is
static. In addition, they assume that address allocation within the
O'Neill, Corson Expires 22 April 2000 [Page 1]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
topology will aim to provide multiple levels of IP address
aggregation such that routing protocols can deal with address
prefixes, rather than large numbers of host routes. Within this
framework, traditional intra-domain protocols, such as OSPF, need
only react to infrequent changes to the network due to link or router
failures or permanent modifications to the addressing scheme or the
topology.
Mobile Ad hoc NETwork (MANET) routing protocols have been developed
to address what could be considered to be an extreme scenario,
whereby the mobile nodes have permanent IP addresses which can
rapidly roam through an ad hoc topology, leading to the need for
alternative routing technology and the general loss of aggregation
opportunities.
A third family of routing protocols is now under investigation for
the case in which the core topology is essentially fixed but the end
systems are mobile. This is the classical edge mobility scenario that
is today supported by cellular networks, primarily as part of the
cellular technology elements (GSM, GPRS etc). Migrating this routing
function to the layer 3 IP routing protocol, to release all the end-
to-end internetworking benefits which has aided the deployment of the
Internet, would tend to suggest a fusion of the MANET and traditional
routing protocol architectures. The primary aim is to move the IP
interface location in the routing topology as the mobile changes base
stations so that active IP sessions are maintained. This is clearly
only one of the possible models and this draft does not make any
judgments as to the pro's and con's of this particular mobility
model, but is simply using it as a precursor for the discussion of
the related hand-over architecture.
These edge mobility networks can be considered to have a single IP
routing protocol which runs between routers in the domain, with some
of those routers being the edge base stations equipped with a
(potential) diversity of radio technologies such as CDMA, TDMA and
Radio LANs etc. The radio layers are assumed to provide the well
known layer 2 hand-over models and other capabilities including
break-before-make, make-before-break, power measurement, mobile
assisted hand-over, paging and security features. To facilitate
internetworking, inter-base station coordination is assumed to use
IP-based communication using messages which are abstractions of the
messages which are today carried in cellular technology-specific
messages, often via central processing elements.
This brief draft proposes a general approach to the support of this
edge mobility function, with the aim of being generic enough to
support a range of different routing protocols, as well as enabling
hand-over between diverse types of cellular technology through
O'Neill, Corson Expires 22 April 2000 [Page 2]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
capability exchange between radio-equipped base stations. It does not
deal with the details of these mechanisms as they are specific to the
type of routing protocol selected. This draft does also not discuss
the effects of the architecture on DNS, DHCP and infrastructure
services, nor does it contribute to the debate on the appropriate
layer and model for mobile terminal paging.
2. Mobile Routing Architecture
The architecture proposed assumes that modifications to either MANET
or traditional routing protocols are possible which will enable these
protocols to comply with this architecture and hence facilitate a
message set and control model which has a degree of protocol
independence. The details of these modifications are left to later
drafts, both from the authors of this draft, and likely contributions
from other researchers in this area. Clearly, the actual detailed
mechanisms, message content/timing and performance are going to be
dependent on the type of intra-domain routing protocol that forms the
basis for the mobility extensions.
The architecture has six main components, the first being the use of
mobile IP across provider boundaries to facilitate the temporary
movement of an IP address (on a mobile terminal interface) away from
its home domain whilst maintaining active sessions. The mobile IP
tunnels are initiated by a base station (HA) at the inter-domain
boundary to the base station (FA) in the foreign domain, and are
extended to further base stations in the foreign domain using normal
Mobile IP foreign agent mechanisms. This bounds subsequent
discussions to intra-domain routing issues. The other five components
are:
a) the provision of a modified intra-domain routing protocol which
provides prefix-based routing within a domain, with each prefix
representing a block of IP addresses allocated to each base
station in the domain, as well as host routes to support mobile
terminal migration away from the allocating (IP address) base
station,
b) the provision and use of a virtual link for routing exchange
and messaging between adjacent base stations to exchange
capabilities, and to effectively and locally manage the hand-over
of the responsibility for, and routing of, the mobile terminal and
it's associated IP address,
c) the ability to inject a host route for the mobile,
d) the ability to poison the existing route to the mobile via the
old base station
O'Neill, Corson Expires 22 April 2000 [Page 3]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
e) the provision and use of a temporary tunnel to redirect packets
in flight between the old base station and the new base station
whilst routing converges, and
f) a method to return the allocated IP address to the allocating
base station on mobile session termination at a different base
station in the same domain.
The reasons for each of these components will be explained in the
following sections which will give examples for CDMA (make-before-
break) and TDMA (break-before-make) handover.
2.1 Mobile Session Start-Up
The mobile connects to the nearest / best base station and is brought
into the IP routing domain by requesting and being allocated an IP
address out of the block of addresses managed by that base station.
The base station will be advertising the IP address prefix associated
with that address block into the intra-domain routing protocol such
that 'at home' mobiles have a proactively and permanently advertised
route, and are immediately reachable to all hosts in the internet.
As the mobile moves base stations, this IP address moves with them so
that higher-layer sessions are unaffected. This is accomplished by
modifying the intra-domain routing using hosts routes to overrule
(longest match) or overwrite the underlying proactive base station
prefix routing. Placing an appropriate set of messages over IP
ensures that a wide range of radio technology specific hand-over
models can be accommodated within a single IP model to allow for
internetworking of IP over those diverse technologies.
2.2 Break before Make
TDMA technology such as GSM only allows the mobile to be connected to
a single base station at a time, with a data path dead-time incurred
during hand-over. The 'inject' route feature is therefore invoked
when the old and new base stations have been identified, and have
agreed to the hand-over by creating the dynamic redirect tunnel
between themselves. Note that for efficiency purposes a single
redirect tunnel could be pre-configured between adjacent base
stations to support all inter-base station hand-overs, and dynamic
mobile-specific redirect state temporarily installed against that
aggregate tunnel. Either way, the base stations collaborate to
locally inject the new route into the routing domain. When the mobile
disconnects at the radio layer from the old base station, the new
base station, through the inter-base station virtual link or tunnel,
is immediately known to be the next best hop, and packets will be
immediately redirected down the tunnel to the new base station. Some
time later the mobile will attach to the new base station and will
O'Neill, Corson Expires 22 April 2000 [Page 4]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
immediately receive in-flight and locally cached packets. The base
stations then again collaborate to poison the old route that points
to the old base station, and to propagate the new route from the new
base station. When routing has converged, the old base station will
detect this and eliminate the redirect state associated with the
temporary tunnel. Packets to the mobile will then head towards the
new base station route. The reception of the mobile is then confirmed
through acknowledgement messages to the old base station which is
used to confirm hand-over of responsibility for the mobile and it's
IP address in the system.
2.3 Make Before Break
CDMA technology enables a mobile terminal to be connected to two base
stations at the same time and to undertake measurements to establish
the preferred channel and hand-over time. In this system it is
therefore important to support concurrent routing paths from all
potential senders to the mobile via the two concurrent base stations.
This requires the inject route feature from the base stations to be
invoked before the mobile leaves the old station, and for the poison
route feature to only be invoked when the hand-over to the new base
station is triggered, rather than simply on connection to the new
base station. Finally, it is necessary to ensure that some data is
simultaneously received over the concurrent paths so that the mobile
is able to make comparative path quality measurements.
2.4 Hybrid Model
When a hybrid node is able to support both TDMA and CDMA (or other
combinations of technology) then a consistent set of base station and
mobile IP messages makes hand-over of the concurrent sessions between
TDMA and CDMA base stations possible. This is achieved by the base
stations understanding each others capabilities, and holding up and
synchronising the inject and poison stages as appropriate.
2.5 Mobile Switch Off
It is clear that the migration of IP addresses away from the
allocating base station can lead to address exhaustion and a gradual
degradation over time of the usefulness of the proactively advertised
base station address block prefix. It is therefore critical that at
the moment that the mobile finishes active sessions, at a distant
base station, that the IP address is returned to the home base
station. This can be modelled as a virtual mobile moving from the
distant base station back to the home base station and then locally
returning the IP address. This can be accomplished using similar
mechanisms which are used to support real inter-base station hand-
overs, with the base stations acting as proxies for the virtual
O'Neill, Corson Expires 22 April 2000 [Page 5]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
mobile. Their aim is to co-ordinate the removal of all host specific
routing entries in the domain as a result of previous mobility away
from the home base station.
3. Comparison to Alternatives
3.1 Mobile IP
Mobile IP [MobileIP] is a well known technique for supporting edge
mobility through the use of stateful intelligence and the permanent
use of tunnels. Mobile IP is used in our proposal as the only
credible means to support hand-over between Autonomous Systems whilst
trying to preserve the current IP interface address and dependent IP
sessions. Mobile IP effectively takes the position that IP routing
should not inherently try to support IP interface movement due to the
implications on the scaling of the intra-domain routing. It is
therefore deemed better to add functionality to hide the interface
movement from the routing protocol(s). The authors of this draft
fully concur with this position for traditional routing protocols
such as OSPF, where the consequence of mobility in any reasonable
domain is clearly disastrous for routing state and message overhead.
However, we believe other routing approaches can achieve sufficient
scaling to be commercially useful, and the case for Mobile IP against
a routing solution becomes a more detailed comparison of interactions
with other IP / cellular protocol features, system reliability,
system overhead, time to market and ultimately cost etc. We believe
that with suitable routing technology, the Mobile IP solution will in
many cases be inappropriate, and we would encourage others to work on
such technology, in competition to our detailed proposals that will
be published when finished.
3.2 Cellular IP
Cellular IP [CellularIP] is an existing proposal which to some extent
fits aspects of this architecture, in particular in that it uses
Mobile IP inter-domain and advocates use of a constant in-session
address. It provides for handover-based redirection and soft state-
based maintenance of host-specific routing and paging entries. These
entries point to a central domain router, and the redirections modify
a set of default routes collectively forming a tree.
3.3 HAWAII
HAWAII [HAWAII] is another proposal similar to Cellular IP. It also
advocates the use of a constant in-session address and Mobile IP
inter-domain. It also provides for handover-based redirection of
host-specific routing paths rooted at a central core router, although
its handover and paging mechanisms are more complex than those of
O'Neill, Corson Expires 22 April 2000 [Page 6]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
Cellular IP.
Cellular IP and HAWAII differ from the proposed architecture in that
here host routes modify a traditional, prefix-routed mesh topology
and form route sets other than trees leading to reduced
configuration, greater resilience, shorter data path lengths and
topological design freedom. In addition, these approaches appear not
to make provision for the temporary tunnelling of packets in flight
whilst redirect routing converges, which can lead to data packet loss
depending on topology, convergence time, link speeds, control packet
loss recovery times and traffic load.
4. IETF Working Group Activity
British Telecommunications (BT) would welcome the creation of a
specific IETF working group to address an overall architecture for
edge mobility routing, specific extensions to existing routing
protocols to accomplish that architecture, and extensions to existing
Internet technology (DNS, DHCP, AAA etc) to support this
architecture. We would be happy for Cellular IP and HAWAII to be
covered by such a working group assuming the respective authors
concur.
5. Security
This draft is too general to explicitly address security issues.
Certainly host and router authentication must be handled in the
architecture, and various mechanisms already exist for these
purposes. For example, host authentication during dynamic address
assignment is possible via [RADIUS]. Router authentication could be
handled via shared key exchange as is common in many routing
algorithms. Additionally, mechanisms would be required for
authenticating Mobile IP messages and the discussion of possible
approaches in [HAWAII] applies here as well. Additionally, source
address checking would be necessary.
6. References
[CellularIP] A. Valko, ``Cellular IP: A New Approach to Internet Host
Mobility," ACM Computer Communication Review, Vol. 29, No. 1, January
1999.
[HAWAII] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.
Salgarelli, ``IP micro-mobility support using HAWAII," Internet
Draft, Work in Progress, June 1999.
[MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002,
Oct 1996.
O'Neill, Corson Expires 22 April 2000 [Page 7]
INTERNET-DRAFT Edge Mobility Architecture 22 October 1999
[RADIUS] C. Rigney, A. Rubens, W. Simpson and S. Willens, ``Remote
Authentication Dial in User Service (RADIUS),'' Request for Comments
2138, Apr 1997.
Appendix A -- IPR Statement
British Telecommunications plc has patent applications relevant to
the architecture mentioned in this draft and to modifications of
routing protocols. The modifications seek to achieve the scaling and
performance objectives required for commercial cellular IP systems.
British Telecommunications plc is currently considering giving an
undertaking to the IETF to grant licences under the patents resulting
from the patent applications on fair and reasonable terms so that
vendors can develop systems based on IETF specifications for
commercial deployment in a timely and cost-effective manner.
British Telecommunications plc would also encourage the IETF to seek
similar undertakings from others re licensing of their patents which
could otherwise hamper the development and deployment of the IETF
specifications related to this technology.
Author's Addresses
Alan O'Neill
BT Laboratories
(+44) 1473-646459
alan.w.oneill@bt.com
M. Scott Corson
University of Maryland
Ansible Systems
(+1) 301-405-6630
corson@isr.umd.edu
O'Neill, Corson Expires 22 April 2000 [Page 8]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/