INTERNET-DRAFT A. O'Neill
Internet Engineering Task Force G. Tsirtsis
Expires in August 2000 BT
S. Corson
University of Maryland
Ansible Systems
9 March 2000
Edge Mobility Architecture
<draft-oneill-ema-01.txt>
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 also suggests a specific protocol based on TORA for
the implementation of such an 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.
O'Neill, Corson, Tsirtsis [Page 1]
Internet Draft EMA March 2000
INDEX
1. Introduction
2. Mobile Routing Architecture
2.1 Mobile Session Start-Up
2.2 EMA Intra-domain Hand-over Messaging
2.3 Break Before Make - BBM
2.4 Make Before Break - MBB
2.5 Hybrid Model
2.6 Mobile Switch Off
2.7 EMA Inter-domain considerations
3. TORA-based Mobile Enhanced Routing (MER)
3.1 Inter-AR Routing
3.2 Mobile Host Routing
3.3 TORA Mobility Concepts
4. Scalability
4.1 Performance
5. Comparison to Alternatives
5.1 Mobile IP
5.2 Cellular IP
5.3 HAWAII
6. Security
7. References
O'Neill, Corson, Tsirtsis [Page 2]
Internet Draft EMA March 2000
1. Introduction
Telecommunications networks are rapidly transitioning towards an all-
IP architecture. This trend is not restricted to fixed networks.
Second generation cellular networks have been modified to provide
limited data services, and third generation systems undergoing
rollout now have been designed to deliver IP connectivity to the end
user. These system continue to support mobility based on the
continuing advancements in wireless technology. However, with IP
routing technology being pushed out to the network's edge, it becomes
less cost effective to support the various modes of layer 2 edge
mobility management that accompany today's cellular and PCS
technologies. Rather, unified solutions become advantageous to
domain operators, wherein mobility management becomes an integral
component of an IP layer routing protocol and associated hand-over
mechanisms.
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
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
O'Neill, Corson, Tsirtsis [Page 3]
Internet Draft EMA March 2000
stations so that active IP sessions are maintained. We refer to this
form of routing as Mobile Enhanced Routing(MER), its intra-domain
deployment providing Edge Mobility support within that domain. 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.
External BGP Peerings To the Internet
| * |
| * |
Allocating | * | Roaming
Domain _|_ * _|_ Domain
Border-->| |---------------------------| |<--Border
Router |HBR| * |FBR| Router
|___| * |___|
MER | * | MER or
Protocol _|_ * _|_ OSPF etc)
| | * | |
,--|HIR|--, * ,--|FIR|--,
| |___| | * | |___| |
_|_ _|_ * _|_ _|_
| | | | * | | | |
|HAR| |HAR| * |FAR| |FAR|
|___|<--->|___|<------*------> |___|<--->|___|
*
Movement Movement Movement
intra-domain inter-domain intra-domain
Figure 1: Edge Mobility Domains as part of the Internet
These edge mobility domains as shown in figure 1, can be considered
to have a single IP routing protocol which runs between routers in
the EMA domain, with some of those routers being the edge access
routers (ARs) equipped with, or connected to a (potential) diversity
of radio base station 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-
access router co-ordination 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.
O'Neill, Corson, Tsirtsis [Page 4]
Internet Draft EMA March 2000
This 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 capability
exchange between radio-equipped access routers. 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.
In section 2, we describe an Edge Mobility Architecture (EMA) for the
support of edge mobility, with the aim of being general enough to
support a range of different routing protocols, as well as enabling
hand-over between diverse types of cellular technology through
capability exchange between radio-equipped ARs In section 3 we
provide a description of one proposed approach for Mobile Enhanced
Routing, and compare it with alternative proposals for IP mobility
support in section 5. In section 4 we look at the performance and
scalability of our solution based on simulations that have been
implemented. It will become clear that the routing approach put forth
here needs to be coupled with a companion paging architecture for
location management, the details of which are not covered in this
draft.
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. 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 seven main components, these being the use of;
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 NAP or 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 cooperating access routers to exchange
O'Neill, Corson, Tsirtsis [Page 5]
Internet Draft EMA March 2000
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 provision and use of a temporary tunnel to redirect packets
in flight between the old access router and the new access router
whilst routing converges, and
d) the ability to inject a host route for the mobile,
e) the ability to poison the existing route to the mobile whether
a host or prefix route
f) a method to return the allocated IP address to the allocating
access router on mobile session termination at a different base
station in the same domain.
g) 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 tunnel is located on an access router in
the old domain (HA), across the inter-domain boundary to the
access router in the new domain (FA). In the foreign domain, the
tunnel is extended to further access routers in the foreign domain
using normal Mobile IP foreign agent mechanisms. The details are
covered in section 2.7.
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) hand-over.
2.1 Mobile Session Start-Up
The mobile host (MH) connects to the nearest access router 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 access
router. This Allocating Access Router (AAR) 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. Note that end hosts
statically attached to the EMA domain via Network Access Servers can
be viewed as "at home" mobiles who never move. As the MH moves access
routers, 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 (longest mach) to overrule or
overwrite the underlying proactive prefix routing to the AAR. Placing
an appropriate set of messages over IP ensures that a wide range of
O'Neill, Corson, Tsirtsis [Page 6]
Internet Draft EMA March 2000
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 EMA Intra-domain Hand-over Messaging
In certain wireless technologies (e.g. GSM), hand-overs can be
predicted based on signal-to-interference measurements at nearby ARs
(radio interface in router) or attached downstream base stations
(remote BS's). After the appropriate hand-over criteria are reached,
a hand-over procedure can be initiated from an Old Access Router
(OAR) to a New Access Router (NAR) in response to a known topological
change. In other instances, e.g. with technologies not supporting
hand-over prediction, the unanticipated loss of a link should not be
immediately interpreted at the OAR as an undesirable link failure.
Instead, the OAR should wait for a time to see if the MH reappears,
connected either to itself or to a NAR. If it appears at a NAR, the
OAR again treats this as a known topological change and reacts
accordingly. If it does not appear, the OAR eventually declares link
failure and reacts accordingly. The generalised message set of EMA
described below and shown in Figure 2, may be mapped to a range of
AAA protocols/models, cellular signaling and routing technology etc.
to enable a specific solution to be designed. The aim of the
description is to capture the essence of the model in terms of
responsibilities and timings for IP hand-over.
|>>>>>>>>>>>>>>> 5.RUA >>>>>>>>>>>>>>>|
| |<<<<<<<<<<<<< 4.RU <<<<<<<<<<<<<| |
| | | |
|_| |_|
| | -----------> 3.HI/D --------> | |
|OAR| <----------- 2.HR <---------- |NAR|
|___| -----------> 1.TIN ---------> |___|
Figure 2: Basic EMA Hand-over Messaging
If MH movement is predicted, then the OAR may be informed by the MH
(if mobile assisted operation is implemented) with a Host Tunnel
INitiation (H-TIN) packet or via a layer 2 signal. This causes the
OAR to build a temporary, soft-state tunnel towards the NAR and to
send a Tunnel INitiation (TIN) packet to the NAR. This message may
give the NAR advance warning of hand-over. The tunnel can serve to
help avoid packet loss during any link dead-time. This sequence of
events and the tunnel's construction are optional. What is not
optional is the construction of a virtual link at the OAR. If hand-
over is predicted, this virtual link is accompanied by a tunnel and
is terminated at the NAR. If hand-over is not predicted and the link
to the MH is suddenly lost, a virtual link to the MH itself is
O'Neill, Corson, Tsirtsis [Page 7]
Internet Draft EMA March 2000
retained for some time while the OAR awaits notification of the MH's
location.
Otherwise, the EMA hand-over model has its focus at the NAR and all
mandatory messaging begins there. On arrival at the NAR, the MH
(operating in mobile-assist mode) brings up a new link for IP
purposes (i.e. Make) to the NAR. This triggers the NAR to send a
Hand-over Request (HR) message to the OAR which can contain MH
credentials and privileges. The OAR responds with either a Hand-over
Initiation (HI) (i.e. AAA information and associated state) packet if
hand-over is permitted, or else with a Hand-over Denial (HD) packet.
The HR packet is repeatedly sent until either a HI or HD is received,
or it is determined that the OAR is unreachable. If hand-over is
permitted, the HI packet begins a three-way handshake to transfer
control of the mobile to the NAR. On receipt of the HI, the NAR
initiates routing redirection by sending a Routing Update (RU)
towards the OAR. This is sent reliably hop-by-hop towards the OAR,
and may be resent multiple times until a RU Acknowledgement (RUA) is
received at the NAR or the OAR is determined to be unreachable. This
message exchange remains the same for both BBM and MBB hand-over,
whether or not the hand-over can be predicted.
2.3 Break Before Make - BBM
TDMA technology such as GSM only allows the mobile to be connected to
a single access router at a time, with a data path dead-time incurred
during hand-over. To minimise the potential for packet loss while
maintaining efficient routing, the inject/poison route features are
delayed and invoked only after the Make event occurs at the NAR
thereby ensuring that the link to the OAR is used until the break
occurs. When the mobile disconnects at the radio layer from the old
AR (Break), the new AR, through the inter-AR virtual link or tunnel
(if present), is immediately known to be the next best hop, and
packets hitting the old AR are immediately redirected down the tunnel
to the new AR. If a tunnel is not present (unanticipated break),
then packets may be cached at the OAR in anticipation of a hand-over,
or simply dropped. Some time later the mobile will attach to the new
AR (Make) and, if the tunnel is in place, will immediately receive
in-flight and locally cached packets.
Once the Make event occurs, the new AR informs the old AR of the need
to commence hand-over. The two ARs now collaborate to locally inject
the new route into the routing domain and poison the old route.
Packets to the mobile will then head towards the new AR route. This
route redirect process will typically converge during the data path
dead-time ensuring that only a small number of packets (if any) will
need to be tunnelled from old to new AR. Once routing has converged,
the old AR will eliminate the redirect state associated with the
O'Neill, Corson, Tsirtsis [Page 8]
Internet Draft EMA March 2000
temporary tunnel. The reception of the mobile at the new AR is then
confirmed through acknowledgement messages to the old AR which is
used to confirm hand-over of responsibility for the mobile and it's
IP address in the system.
The following steps outline the break-before-make (BBM) procedure of
EMA which is also shown in figure 3:
1) Detect imminent hand-over and inform new and old ARs
(optional).
2) Build a temporary tunnel from old AR to new AR (optional).
(Break event occurs)
3) Await Make event at new AR.
4) On Make event, inject new route to the new AR and poison old
route to old AR.
5) Tear down tunnel at old AR (if present).
OAR NAR OAR======NAR OAR======NAR
| | | | |
| | | | |
MH-> MH-> MH->
a)Before Handover b)sensing new link c) Tunnel Data
build tunnel on break
^
|
OAR======NAR OAR NAR
| |
| |
MH-> MH->
d)Inject new routing e)Routing converges
on make, forward tear down tunnel
cached data (if any)
Figure 3: Basic EMA BBM Hand-over (with temporary tunnel)
The first two steps are optional because it is not always possible to
predict a hand-over in advance. An unanticipated link failure may
occur between the old AR and the mobile host prior to its arrival at
the new AR. The "inject/poison" route features of EMA can be invoked
only after the old and new ARs have been identified, and have agreed
to the hand-over by creating the dynamic, temporary redirect tunnel
between them. Note that for efficiency purposes a single redirect
tunnel could be pre-configured between adjacent access routers to
support all inter-access router hand-overs, and dynamic mobile-
specific redirect tunnel state temporarily installed against that
O'Neill, Corson, Tsirtsis [Page 9]
Internet Draft EMA March 2000
aggregate tunnel.
2.4 Make Before Break - MBB
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. This hand-over time
determines the timing of the Make event. As with TDMA, it is
desirable to wait until the Make event occurs before injecting the
new host route. However, unlike TDMA, packets continue to arrive at
the mobile via the link to the old AR prior to the Make event. Thus
the temporary tunnel is typically not needed in CDMA, but it is
constructed in case an unexpected early break occurs with the added
benefit that in so doing the same hand-over state machine can be used
for both BBM and MBB modes.
The following steps outline the make-before-break (MBB) procedure of
EMA which is also shown in figure 4:
1) Detect imminent hand-over and inform new and old ARs
(optional).
2) Build a temporary tunnel from old AR to new AR (optional).
3) Await Make event.
(Make event occurs)
4) On Make event, inject new route to the new AR and poison old
route to old AR.
(Break event occurs)
5) Tear down tunnel at old AR (if present) and remove state of
poisoned route.
^
|
OAR NAR OAR=====NAR OAR=====NAR
| | | | |
| | | | |
MH-> MH-> MH->
a)Before Handover b)sensing new link c)Inject new routing
build tunnel on make
OAR=====NAR OAR NAR
| | |
| | |
MH-> MH->
d)Routing converges e)Break occurs
tear down tunnel
Figure 4: Basic EMA MBB Hand-over (with temporary tunnel)
O'Neill, Corson, Tsirtsis [Page 10]
Internet Draft EMA March 2000
We are not directly addressing IP layer support for CDMA soft hand-
over. While feasible in terms of IP layer routing and copying, this
mode of CDMA-based hand-over requires highly synchronised packet
delivery over the air interface(s) to the mobile which may not be
compatible with a heterogeneous IP network infrastructure. Soft hand-
over can still be achieved however if the underlying layer 2 (ATM
AAL) has the required timing and cell duplication functionality as
presently proposed in 3G systems. This is achieved for example by the
IP layer at the OAR handing responsibility for soft hand-over to the
ATM layer which duplicates and times cell delivery to the multiple
neighbor NAR(s).
2.5 Hybrid Model
When a hybrid node is able to support both TDMA and CDMA (or other
combinations of technology) then a consistent set of access router
and Mobile IP messages makes hand-over of the concurrent sessions
between TDMA and CDMA access routers 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.6 Mobile Switch Off
It is clear that the migration of IP addresses away from the
allocating access router can lead to address exhaustion and a gradual
degradation over time of the usefulness of the proactively advertised
access router address block prefix. It is therefore critical that at
the moment that the mobile finishes active sessions, at a distant
access router, that the IP address is returned to the AAR. This can
be modelled as a virtual mobile moving from the distant access router
back to the AAR and then locally returning the IP address. This can
be accomplished using similar mechanisms which are used to support
real inter-access router hand-overs, with the access routers acting
as proxies for the virtual 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 access router.
2.7 EMA Inter-domain considerations
In both the BBM and MBB case above if the NAR is in a different
administrative domain from the OAR, we set-up a Mobile IP (MIP)
tunnel between the OAR (playing the role of a Home Agent) and the NAR
(playing the role of a Foreign Agent). This is independent of whether
the destination domain supports an EMA-MER protocol or a traditional
routing protocol such as OSPF. [MobileIP] with the extensions
described in [MIPAAA] should be used so that integrated AAA
functionality can be provided for roaming users between domains.
O'Neill, Corson, Tsirtsis [Page 11]
Internet Draft EMA March 2000
The end of the MIP tunnel in the new domain is the NAR (rather than
the mobile itself) which means that if the mobile continues moving in
the new domain, and the domain does not support EMA-MER, then this
end of the MIP tunnel needs to move with it. This requires re-
registration of the mobile to its Home Agent (OAR) at every hop
leading to lower hand-over performance without Mobile IP fast-hand-
over extensions. However, we favor this approach because it keeps
the mobile simple and reasonably unaware of intra/inter-domain
changes, and it avoids tunneling over the expensive air interface.
This approach places the network in control while also allows the
mobile to potentially run Mobile IP, using a Co-located Care of
Address, back to a third HA (in say the corporate LAN) for its own
orthogonal purposes.
If the new domain also supports MER then a hybrid mode of Mobile IP
and EMA-MER becomes possible which avoids Mobile IP re-registration
at each new AR within that new EMR domain.
3. TORA-based Mobile Enhanced Routing (MER)
The preceding architecture does not specify how an EMA-compliant,
Mobile Enhanced Routing (EMA-MER) algorithm creates or modifies its
host and prefix- specific IP forwarding entries, and various
approaches are possible. With the objective of building a large-
scale EMA domain, the Temporally-Ordered Routing Algorithm (TORA)
appears potentially well-suited for use as an EMA-MER algorithm. TORA
was originally specified as an on-demand MANET routing algorithm, but
this mode of operation is not generally required and a proactive mode
is being specified. Much of TORA's original protocol mechanism deals
with reaction to link and node failures. Many of these details are
not relevant to the discussion here, and we refer the reader to
[TORA, TORAdraft] for this information. Here we focus on the high-
level aspects of TORA necessary to understand its operation as an MER
algorithm within EMA.
EMA TORA differentiates nodes into two classes: routers and hosts.
Routers execute the full EMA protocol suite while hosts execute only
a limited state machine that does not involve packet forwarding.
Mobile hosts (MH) are handed over between access routers (ARs) which
have either local or remote radio interfaces. In general, routers
may also be mobile (e.g. mobile ad hoc networks), but we will not
consider that case here.
The problem of Mobile Enhanced Routing is divided into two sub-
problems: inter- AR routing and host-specific routing. TORA proceeds
independently for each destination, which enables separate versions
O'Neill, Corson, Tsirtsis [Page 12]
Internet Draft EMA March 2000
of TORA to proceed proactively for each AR, and proceed reactively
for each mobile host in an edge mobility- enhanced mode as necessary.
3.1 Inter-AR Routing
Within the EMA, Inter-AR routing is prefix-based, such that each AR
advertises a prefix address covering a block of host addresses that
it controls, into the EMA domain so that;
(i) packets can be proactively routed to hosts with addresses
covered by these prefixes, and
(ii) a virtual, bi-directional path exists between any pair of co-
operating ARs for their communication during mobile hand-over.
We accomplish this by having a separate version of TORA build and
proactively maintain a Directed Acyclic Graph (DAG) for each prefix.
The DAG is a distributed data structure that provides one or more
routing entries in each router in the EMA domain. In TORA, each
router maintains a "height" for a given prefix, and a prefix DAG is
formed from the set of these heights. Packets may only be forwarded
from a router to its neighboring routers with "lower" heights. In
this way loop-free, multipath routing is assured. The router with
the destination prefix always has the "lowest" height in the DAG.
Initial prefix DAG construction occurs by having each AR router, on
initialisation, transmit an optimization (OPT) packet into the
domain. The AR prefix DAGs are then maintained via a combination of
the aforementioned proactive mechanism and normal TORA reactive
processing. This routing should be continuously maintained, i.e.
proactively, whereas host-specific routing (to be discussed
subsequently) should be maintained only as needed, i.e. on-demand or
reactively.
3.2 Mobile Host Routing
In the EMA, each host is allocated an interface address covered by
the allocating AR network prefix. While the host is at the
allocating access router (AAR) it is considered to be "at home", and
packets are routed to the host via the network prefix of the AR. If
the host moves away from its AAR, host- specific state is injected in
the network during hand-over to overrule (via longest prefix match
forwarding) the host's default DAG and redirect packets to the hosts
current location. Numerous mechanisms can be defined to achieve this.
Given that the inter-AR routing algorithm we have chosen is TORA, we
seek a mechanism that operates in harmony with TORA's notion of
height-based routing, and permits a large degree of flexibility
concerning the method and scope of host-specific state injection. The
O'Neill, Corson, Tsirtsis [Page 13]
Internet Draft EMA March 2000
design objective is to localise the scope of hand-over-induced
messaging so as to reduce the processing load on routers as much as
possible while maintaining routing efficiency. Domain scalability is
the end goal.
3.3 TORA Mobility Concepts
@ @
@@@@@@@@@@ @@@@@@@@@@
@ .------CR-------. @ .------CR-------.
@ | (0002) | @ | (0002) |
@ | | @ |I>>>>>>>>>>>>>I|
@ | | @ |I TIN I|
@ | | @ |I v|
@ OAR NAR @ OAR=============NAR
@(0001) (0003) @(0001) (0003)
@ | @ |I
@ | @ |I
@ | @ |I H-TIN
@ | @ |I
@ | @ |I
@@ MH-> @@ MH->
(0000) (-1000)
(a) (b)
@ @
@@@@@@@@@@ @@@@@@@@@@@@
@ .------CR-------. .------CR-------. @
@ | (-1002) | | (-1002) | @
@ | <<<<<<<<<I| |I<<<<< | @
@ | UDU I| |I UDU | @
@ | I| |v | @
@ OAR=============NAR OAR NAR @
@(0001) (-1001) (-1003) (-1001)@
@@@@@@@@@@@@@@@@@@@| | @
@| | @
@| | @
@| | @
MH-> MH@@
(-1000) (-1000)
(c) (d)
Figure 6: Anticipated BBM hand-over
As mentioned, at any given time the destination has the "lowest"
O'Neill, Corson, Tsirtsis [Page 14]
Internet Draft EMA March 2000
height w.r.t. the remaining TORA DAG. To enable "arbitrary"
destination mobility within the DAG (i.e. mobility between "any" two
points in the DAG), the destination should also "lower" its height
each time it moves and connects to a new point in the DAG. This
action preserves the DAG's loop-free, multipath routing property
while localising the communication necessary to re-orient the DAG.
A special case of such destination mobility is mobile handover in a
cellular network. We now illustrate how the TORA height concept
operates with the EMA message framework with a "GSM-like" scenario of
BBM hand-over shown in Figure 6.
The TORA protocol defines an unicast-directed update (UDU) packet
that replaces the RU message of the EMA. Similarly, an unicast-
directed update acknowledgement packet (UDUA) replaces the EMA's RUA
packet.
We can only show a portion of the message exchange due to space
constraints. The H-TIN packet initiates tunnel creation and
transmission of the TIN packet. The Make event is seen in Figure 6c,
which initiates UDU transmission (we skip the HR and HI phases here)
to redirect routing via injection of host-specific routing state
(shown next to the OAR prefix DAG state). The UDU redirects packet
flow at each router it passes (via height "lowering" in the DAG)
towards the NAR. Since it is sent to the OAR, it eventually re-
directs all packets destined for the OAR towards the NAR. Meanwhile,
packets have been tunnelled towards the NAR since the Break event.
Packet flow for the ongoing call in the example is redirected in Fig.
6d after the UDU hits the call's crossover router, and the tunnel
comes down when the UDU hits the OAR. We also omit the UDUA phase
due to space limitations. The numbers below each router in the figure
represent that router's height, and show that the set of heights
become negative (i.e. lower) as handover progresses. See [FMCTR]
for more details.
As the mobile migrates, a similar sequence will be repeated at each
hand-over, with the mobile's height getting progressively lower.
Hopefully the reader will be able to construct similar message
diagrams for the other cases involvin g unanticipated BBM,
anticipated MBB and unanticipated MBB from what we have presented
(see [FMCTR] for more details). These hand-over forms may occur as
the mobile moves between different types of layer 2 technologies
(e.g. GSM to Bluetooth hand-over) generating different hand-over
event sequences.
Recall, it will also be necessary to re-allocate the IP address back
to the AAR after a sequence of hand-overs. This is accomplished via
a sequence of messages very similar to the hand-over processing (only
O'Neill, Corson, Tsirtsis [Page 15]
Internet Draft EMA March 2000
in reverse) where the IP address is handed back to the AAR and all
host-specific state is erased from the network which we cannot show
due to space limitations.
4. Scalability
TORA was originally conceived as a MANET routing algorithm where it
is intended for use in large-scale, dynamic, bandwidth-constrained
MANETs. The principle objective behind its design is the achievement
of "flat scalability", i.e. achieving a high degree of scalability
(measured as the number of routers in a domain) with a "flat", non-
hierarchical routing algorithm. In its operation the algorithm
attempts to suppress, to the greatest extent possible, the generation
of far-reaching control message propagation.
With TORA, such suppression may or may not be feasible depending on
the topology. As we will see subsequently, a key to achieving highly-
scaled EMA routing with TORA turns out to be an issue of "topology
control". Under appropriate topological conditions, TORA's reaction
to link additions and failures can be highly localised, with smooth
delocalisation as we move to more adverse topologies. This is a key
property which we exploit based on the realisation that, viewed
abstractly, the "make" and "break" operations in cellular networks
correspond to link "additions" and "failures", respectively, in a
unified mobile host/fixed router network. The subsequent lack of
large amounts of far-reaching control message propagation--a feature
common to shortest-path algorithms--afford TORA its relatively quick
convergence and consequent stability.
These properties appear desirable for the design of large-scale
routed domains without any consideration for mobility support. In
the most recent Internet Architecture Board (IAB) report on network
layer issues [IAB99], the IAB concluded that the scalability
bottleneck of presently deployed routing technology stems not from
storage considerations but rather from long convergence times. These
convergence delays are due to the time required to distribute stable
routing information updates (communication complexity) and the time
required to re-compute routing tables (computational complexity).
Operating in a suitable topology, TORA can have relatively low
communication and computational complexity due to the nature of its
distributed computation that forgoes shortest path computation.
TORA also supports loop-free, multipath routing realised as a
consequence of the usage of temporally, totally-ordered "heights".
The provision of multipath routing makes the protocol amenable for
load sharing and traffic engineering. The algorithm also has the
potential to support fast restore via its link reversal mechanism
O'Neill, Corson, Tsirtsis [Page 16]
Internet Draft EMA March 2000
based on the availability of fine-grained link status sensing,
possibly from layer 2 mechanisms or from layer 3 mechanisms such as
[FLIP].
4.1 Performance
Operating as an EMA-MER protocol, initial simulation results indicate
that TORA may be well-suited for use in hierarchical mesh topologies
[FMCTR]. Hierarchical mesh topologies have a limited number fully-
meshed core routers, a greater number of intermediate routers (each
dual-homed to two core routers), an even greater number of edge
routers (each dual-homed to two intermediate routers) and a large
number of access routers (each single-homed to an edge router). Such
topologies have characteristics of both mesh and tree networks, which
vary as a function of the hierarchical fan-out (the greater number of
routers at each lower level) and the amount of multi-homing between
levels.
Proper topology design for TORA involves a balance between tree-like
and mesh- like characteristics. The more tree-like the network, the
better the routing efficiency of TORA relative to a shortest path
routing algorithm due to the reduction in the number of potential
preferred paths between ARs because of the route aggregation effects
of hierarchical topologies. Simulation results obtained thus far
indicate that routing efficiency deviates no more than 5% from
optimal (i.e. shortest path) [FMCTR]. However, the more mesh-like the
network, the greater the degree of control message localisation that
can be obtained during handover. The objective of the localised
hand-over model is to keep host-specific state out of the core and as
far towards the network edge as possible. Simulation results
indicate that with GSM call and mobility statistics for a domain with
1600 ARs, the mesh-like character achieved with dual-homing keeps
host-specific state completely out of the core routers, distributing
it to routers lower in the hierarchy [FMCTR].
The potential scalability of the proposed TORA EMA-MER approach is
indirectly indicated by a comparison of simulation times for
alternative approaches. Results for TORA EMA-MER operating over a
domain with 1760 routers took little more than a day to simulate.
However, to compare against an approach using a shortest-path
computation (imagine a mobile overlay approach atop OSPF in a domain
this large), it is estimated from observed simulation progress that
it would have taken the same computer approximately 84 days to simply
compute the dijkstra computations (one per router) to initialize the
simulation. The TORA approach forgoes support for shortest-path
routing and sacrifices an amount of routing efficiency to achieve
highly-scaled operation in large domains.
O'Neill, Corson, Tsirtsis [Page 17]
Internet Draft EMA March 2000
5. Comparison to Alternatives
5.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. It is also required to support subsequent roaming within a
non-MER domain through re-registration. 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.
5.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 hand-over-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.
5.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 hand-over-based redirection of
host-specific routing paths rooted at a central core router, although
its hand-over and paging mechanisms are more complex than those of
Cellular IP.
O'Neill, Corson, Tsirtsis [Page 18]
Internet Draft EMA March 2000
Cellular IP and HAWAII differ from the proposed architecture in their
use of a central routing tree. In EMA-MER approach, 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 tuneling 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.
More fundamentally, EMA-MER requires a full routing algorithm,
employing hard state for both host-specific and prefix-based
forwarding entries, rather than a soft-state overlay technique for
mobile hosts independent of the underlying fixed routing. Trust is
placed in the host-specific entries, and periodic soft-state
reconfirmation is not utilized. The proposed system is designed to
scale. Central to this design objective is the limitation of network
control signaling, with the understanding that control message
processing is a principal bottleneck to system scalability. Frequent
route verification may potentially overload routers in the domain
sizes we envision which further supports our design decisions.
6. 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.
7. References
[CellularIP] A. Valko, ``Cellular IP: A New Approach to Internet Host
Mobility," ACM Computer Communication Review, Vol. 29, No. 1, January
1999.
[CellularIPdraft] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi and A.
Valko, "Cellular IP", Internet-Draft (work in progress), draft-valko-
cellularip-01.txt, October 1999.
O'Neill, Corson, Tsirtsis [Page 19]
Internet Draft EMA March 2000
[FLIP] H.Sandick et al., "Fast LIveness Protocol (FLIP)", Internet-
Draft (work in progress), February 2000.
[FMCTR] M. S. Corson, A. O'Neill, "An Approach to Fixed/Mobile
Converged Routing", University of Maryland, Institute for Systems
Research Technical Report, TR-2000-5, March 2000,
http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml
[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.
[HAWAIIdraft] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.
Salgarelli, ``IP micro-mobility support using HAWAII," Internet-Draft
(work in progress), draft-ietf-mobileip-hawaii-00.txt, June 1999.
[IAB99] M. Kaat, "Overview of 1999 IAB Network Layer Workshop",
Internet-Draft, draft-ietf-iab-ntwlyrws-over-01.txt, Oct. 1999.
[MIPAAA] S. Glass et. all, "Mobile IP Authentication, Authorization,
and Accounting Requirements", <draft-ietf-mobileip-aaa-reqs-01.txt>,
work in progress, January 2000.
[MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002,
Oct 1996.
[RADIUS] C. Rigney, A. Rubens, W. Simpson and S. Willens, ``Remote
Authentication Dial in User Service (RADIUS),'' Request for Comments
2138, Apr 1997.
[TORA] V. Park, M. S. Corson, "The Temporally-Ordered Routing
Algorithm", Proc. IEEE INFOCOM '97, Kobe, Japan, April 1997.
[TORAdraft] V. Park, M. S. Corson, "Temporally-Ordered Routing
Algorithm (TORA) Version 1 Functional Specification", Internet-Draft
(work in progress), draft-ietf-manet-tora-spec-02.txt, October 1999.
[TORAthesis] V. Park, "A Highly Adaptive Distributed Routing
Algorithm for Mobile Wireless Networks", Masters Thesis, University
of Maryland, College Park, Maryland, 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
O'Neill, Corson, Tsirtsis [Page 20]
Internet Draft EMA March 2000
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
(+44) 1473-646459
alan.w.oneill@bt.com
M. Scott Corson
University of Maryland
Ansible Systems
(+1) 301-405-6630
corson@isr.umd.edu
George Tsirtsis
BT
(+44) 020 8820073
george.tsirtsis@bt.com
O'Neill, Corson, Tsirtsis [Page 21]
Internet Draft EMA March 2000