Personal A. O'Neill
G. Tsirtsis
BT
Internet Draft S. Corson
Document: draft-oneill-ema-02.txt Ansible Systems
Category: Informational July 2000
Edge Mobility Architecture
<draft-oneill-ema-02.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 outlines a system for domain-based routing and
addressing support in handling edge mobility such as encountered in
cellular systems and Internet roaming. The system includes novel
features for IP session, address and localised host redirect route
management which promise significant scaling benefits compared to
other micro-mobility solutions. In addition, the system is closely
integrated with the Mobile IP architecture for both signalling and
data forwarding, so that a rich set of capabilities and Internet
Services are possible, and incremental deployment of EMA is possible
within and between AS's. The draft 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 such
as Mobile IP to support this architecture.
O'Neill, Corson, Tsirtsis 1
Internet Draft EMA July 2000
INDEX
1. Introduction
2. Mobile Routing Architecture
2.1 Mobile Session Start-Up. . . . . . . . . . . . . . . . .
2.2 IP Session Dynamics. . . . . . . . . . . . . . . . . . .
2.3 Mobile Node States . . . . . . . . . . . . . . . . . . .
2.3.1 EMA Active . . . . . . . . . . . . . . . . . . . .
2.3.2 EMA Hot Standby. . . . . . . . . . . . . . . . . .
2.3.3 EMA Cold Standby . . . . . . . . . . . . . . . . .
2.3.4 EMA off . . . . . . . . . . . . . . . . . . . . .
2.4 EMA Intra-domain Hand-over Messaging . . . . . . . . . .
2.5 Break Before Make - BBM. . . . . . . . . . . . . . . . .
2.6 Make Before Break - MBB. . . . . . . . . . . . . . . . .
2.7 Hybrid Model . . . . . . . . . . . . . . . . . . . . . .
2.8 Mobile IP Session Completion . . . . . . . . . . . . . .
2.9 EMA Inter-domain considerations. . . . . . . . . . . . .
3. TORA-based Mobile Enhanced Routing (MER)
3.1 TORA Concepts. . . . . . . . . . . . . . . . . . . . . .
3.2 TORA Hand-over Processing. . . . . . . . . . . . . . . .
4. EMA and Mobile IP Convergence
4.1 EMA / MIP Architectural Considerations . . . . . . . . .
4.2 Converged EMA / Mobile IP Addressing . . . . . . . . . .
5. Scalability Characteristics of EMA:TORA
5.1 Temporary Session IP addresses . . . . . . . . . . . . .
5.2 Aggregate Prefix Routes. . . . . . . . . . . . . . . . .
5.3 Localised Host Redirect Routes . . . . . . . . . . . . .
5.4 In-session Dynamics. . . . . . . . . . . . . . . . . . .
5.5 TORA MER . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Performance. . . . . . . . . . . . . . . . . . . . . . .
6. Comparison to Alternatives
6.1 Mobile IP. . . . . . . . . . . . . . . . . . . . . . . .
6.2 Cellular IP. . . . . . . . . . . . . . . . . . . . . . .
6.3 HAWAII . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 OBAST. . . . . . . . . . . . . . . . . . . . . . . . . .
7. Security Considerations
7.1 Authenticating users within a domain. . . . . . . . . .
8. References
O'Neill, Corson, Tsirtsis 2
Internet Draft EMA July 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 outer
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. 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.
O'Neill, Corson, Tsirtsis 3
Internet Draft EMA July 2000
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.
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.
O'Neill, Corson, Tsirtsis 4
Internet Draft EMA July 2000
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 6. In section 4 we overview the
convergence of EMA with Mobile IP resulting in mutual benefits. In
section 5 we look at the scalability of our solution and performance
based on simulations that have been implemented. Finally, in section
7 we outline the emerging security solution for user authentication.
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, but
is nearing completion.
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 six 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 access router
(AR) in the domain, as well as host routes to support mobile
terminal migration away from the allocating (IP address)access
router,
b) the provision and use of a virtual link for routing exchange and
messaging between cooperating access routers to exchange
capabilities, and to effectively and locally manage the hand-over of
the responsibility for, and routing of, the mobile terminal and its
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) 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.
O'Neill, Corson, Tsirtsis 5
Internet Draft EMA July 2000
f) 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.9 and
in [EMA-MIP]
The reasons for each of these components will be explained in the
following sections that will also give examples for CDMA (make-
before- break) and TDMA (break-before-make) hand-over.
2.1 Mobile Session Start-Up
When the mobile host (MH) either has data to send or has been paged
due to incoming traffic, the MN connects to the nearest AR 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.
Specifically, as the MN wanders away from the AAR, a host redirect
route is locally injected, during hand-off, between geographically
adjacent ARs. This ensures that any traffic on the aggregated AAR
route is 'peeled-off' and redirected to the new AR. Subsequent
movement results in additional host redirect routes that
progressively 'peel' the incoming traffic away from both the prefix
route for the AAR, and the previous host redirect route. Hence, the
further we wander at the edge, the further that the sequence of host
redirect routes will extend the redirection away from the aggregated
AAR prefix route (and associated AR).
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.
O'Neill, Corson, Tsirtsis 6
Internet Draft EMA July 2000
2.2 IP Session Dynamics
When the mobile is inactive for short periods during an IP session,
the radio layer has mechanisms and timers which enable the radio
resources to be released to other users. An IP session timer is used
in the AR and MN to identify sufficient inactivity (which could be
application, terminal, user or service class (tariff) specific) to
terminate the dynamic IP session, so releasing the associated radio
resources, temporary host address and associated routing state. This
enables high multiplexing of the temporary IP address space, and
better utilisation of routing and radio system resources. For mobile
users wishing to be able to maintain the temporary IP address for
long periods for application, business, usage pattern reasons etc,
the IP session timer can be set very long (with potential tariff
implications). This could result in long term host specific IP
routing state in the system which is clearly undesirable as a
general mass-market service. This is therefore clearly a per user
policy decision as to the appropriate value for this timer, but a
large default value can also act as a safety mechanism.
2.3 Mobile Node States
We summarise below the IP view of the state of a mobile in EMA which
may be mapped to existing cellular states. We use our own
terminology here due to confusion in naming between the various
global standards in existence, and because we wish to focus on the
various inactivity timers whose lengths are related to the users
profile/privileges, and whose expiry move the mobile between
specific states.
2.3.1 EMA Active
The mobile is presently sending and receiving IP data traffic. The
MN has a local IP address and has a route pointing to it throughout
the EMA domain. The radio layer (L2) and IP layer (L3) are obviously
UP and movement between Access Routers generates an EMA IP hand-
over.
2.3.2 EMA Hot Standby
The MN moves to Hot Standby when it's L2 inactivity timer (not
sending / receiving IP data) expires. This takes the L2 DOWN
temporarily whilst the L3 is still UP, which releases the radio
layer resources to other users. The MN therefore maintains the
current IP address, has an EMA route for that address in the EMA
domain, and movement between Access Routers generates an EMA IP
hand-over. This feature further improves the utilisation of the
radio-layer by decouping the IP address and layer 3 resources from
the L2 radio resources.
O'Neill, Corson, Tsirtsis 7
Internet Draft EMA July 2000
2.3.3 EMA Cold Standby
On expiry of the IP address inactivity timer, the address is
returned to the AAR and any EMA host redirect state is flushed. The
MN now optionally only has it's home address from it's home link.
The L2 is DOWN and movement generates location updates only to the
global paging system because the MN now has no AAR and local fast
route set-up is not required. This feature is designed to avoid
hoarding of IP addresses when the user is inactive, so that the
address can be returned to the AAR for another user.
2.3.4 EMA Off
The MN is switched off and is neither sending location updates nor
is pageable.
2.4 EMA Intra-domain Hand-over Messaging
A hand-over can be initiated either by a MN or the network, and can
be rooted (i.e. initiated) at either the old or new Access Router.
The Old Access Router (OAR) is used to co-ordinate a forward hand-
over when the New Access Router (NAR) is known in advance as a
result of either network or MN-based movement prediction and
associated performance measurements. The NAR is used to co-ordinate
a reverse hand-over when the NAR is not known in advance by the MN
or the network, as a result of either network failure (e.g. old
radio link lost), insufficient network intelligence (no inter-
technology hand-over signalling) or unpredictable user behaviour
(swapping PCMCIA cards). Specifically, 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.
O'Neill, Corson, Tsirtsis 8
Internet Draft EMA July 2000
|>>>>>>>>>>>>>>> 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
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.
O'Neill, Corson, Tsirtsis 9
Internet Draft EMA July 2000
2.5 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 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.
5) Tear down tunnel at old AR (if present).
O'Neill, Corson, Tsirtsis 10
Internet Draft EMA July 2000
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 aggregate tunnel.
2.6 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:
O'Neill, Corson, Tsirtsis 11
Internet Draft EMA July 2000
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.
(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)
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.7 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 access routers understanding each other's capabilities, and
holding up and synchronising the inject stages as appropriate.
O'Neill, Corson, Tsirtsis 12
Internet Draft EMA July 2000
2.8 Mobile IP Session Completion
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 modeled 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.9 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 MN
(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. In addition, we further
allow this temporary tunnel to be replaced by a persistent tunnel
back to the AAR when leaving an EMA-enabled domain so that the host
route between the AART and OAR in that domain can be removed. The
AAR then becomes the HA for the CCoA from the EMA domain which is
then termed a Co-located Roaming Care of Address.
In either case, the end of the MIP tunnel in the new domain is the
MN (rather than the NAR) 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/AAR) 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 aware of intra/inter-domain
changes. This does however potentially lead to tunneling over the
expensive air interface but this is assumed to be necessary in the
majority of cases for MIPv4, MIPv6 anyway and so appropriate Header
compression solutions will be developed.
The NAR is involved with the MN in the MIP/EMA signalling plane
which strikes the best balance in the overall flexibility and
control of hand-over, supporting both MN assisted and network
assisted models. This 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.
O'Neill, Corson, Tsirtsis 13
Internet Draft EMA July 2000
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. [MobileIP] with the
extensions described in [MIPAAA] should be used for inter-domain
tunnelling so that integrated AAA functionality can be provided for
roaming users between domains.
3. TORA-based Mobile Enhanced Routing (MER)
The preceding architecture does not specify how an MER algorithm
creates or modifies its host and prefix-specific IP forwarding
entries, and various approaches are possible. The problem of EMA
routing is divided into two sub-problems: inter-AR routing and host-
specific routing. The inter-AR routing should be continuously
maintained, i.e. proactively, whereas host-specific routing should
be maintained only as needed, i.e. on-demand or reactively, for
scalability reasons.
Inter-AR routing is prefix-based, i.e. each AR advertises a prefix
address into the FMC domain covering a block of host addresses that
it controls. Each host is allocated an interface address covered by
the allocating AR network prefix. While the host is "at home",
packets are routed to the host via this network prefix. This is
undertaken so that packets can be efficiently routed to both fixed
and 'at home' mobile hosts and a virtual, bi-directional link exists
between any pair of cooperating ARs for their communication during
mobile handover.
Host specific routing is required only when the mobile host moves
away from its allocating AR. Host-specific state is injected in the
network during handover to overrule (via longest prefix match
forwarding) a mobile host's 'at home' prefix based route, which
redirects packets to that mobile hosts current AR location.
With the objective of building a large-scale EMA domain, the
Temporally-Ordered Routing Algorithm (TORA) appears potentially
well-suited for use as a EMA:MER algorithm [TORA]
3.1 TORA Concepts
TORA was originally specified as an on-demand routing algorithm, but
this mode of operation is not generally required and a proactive
mode has been specified. Because TORA proceeds independently for
each destination, it may operate proactively for certain
destinations and reactively for others. In the proposed FMC
context, separate versions of TORA will proceed proactively for each
AR and proceed reactively for each mobile host in an edge mobility-
enhanced mode as necessary.
TORA operates with respect to "nodes". Each node is assumed to have
a unique Node ID (NID). A Node ID (NID) is a polymorphic identifier,
and may be either a Router ID (RID) or a Destination ID (DID)
depending on the context. In a manner similar to OSPF, TORA uses a
O'Neill, Corson, Tsirtsis 14
Internet Draft EMA July 2000
Router ID (RID) to uniquely identify a TORA router separately from
its interfaces. A destination identifier in TORA is a destination
network prefix, composed of an interface IP address and a network
mask. Consequently, the neighbor set Ni that lists a node's
neighbors by NID may actually contain two different identifiers. A
neighbor may be identified as a router (by its RID) or as a
destination (by its network prefix) or frequently as both with
multiple entries in the neighbor set table. For the subsequent
discussion, we assume each node i is always aware of its neighbors
in the set Ni.
TORA proactively and/or reactively builds, and then maintains, a
Directed Acyclic Graph (DAG) rooted at a destination. For a given
destination, each participating node i is assigned a height defined
as an ordered quintuple Hi = (ti, oidi, ri, di, i). No two nodes may
have the same height (i.e. the set of heights is totally-ordered).
Height comparisons are performed lexicographically. Starting with
the 'ti' value, comparison tests are for "less than" or "greater
than", with equality resulting in the comparison proceeding element-
wise towards the final element, the NID i. Information may flow from
nodes with higher heights to nodes with lower heights over
'directed' links. Each link is assumed to allow two-way
communication (i.e., nodes connected by a link can communicate with
each other in either direction).
Each initially undirected link may subsequently be assigned one of
three states; (1) undirected, (2) directed from node i to node j, or
(3) directed from node j to node i. If a link is directed from node
i to node j, node i is said to be "upstream" from node j while node
j is said to be "downstream" from node i. Conceptually, information
can be thought of as a fluid that may only flow downhill over
downstream links (see Figure 4). By maintaining a set of totally-
ordered heights at all times, it is easy to see how loop-free,
multipath routing is assured. Information would have to flow uphill
to form a loop, and this is not permitted. Due to the mobility of
some nodes, the set of active links in the system is changing with
time (i.e., new links can be established and existing links can be
severed).
Conceptually, the height quintuple associated with each node is
combined into two parameters: a reference level, and a delta with
respect to the reference level. The reference level is represented
by the first three values in the quintuple (a triple), while the
delta is represented by the last two values (a double). The first
value in the reference level, 'ti', has three meanings. If equal to
zero, it indicates that the height value has remained "unchanged"
since the DAG was initially constructed or was last optimized (this
is the state of all heights in Figure 4). If positive, it is a time
tag representing the "time" of a link failure somewhere in the
network. If negative, it represents a route "freshness" value (the
more negative the fresher the route) generated in response to
handover-induced mobility.
O'Neill, Corson, Tsirtsis 15
Internet Draft EMA July 2000
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 aspects of TORA
necessary to understand its operation as a FMC algorithm within the
EMA. Under appropriate topological conditions, TORA's reaction to
link additions and failures can be highly localized. This is a key
property which we exploit based on the realization 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. We
can therefore have a separate version of TORA, running on each AR,
build and proactively maintain an aggregated DAG for each prefix
owned by that AR. The AR aggregated DAGs are then maintained via a
combination of the aforementioned proactive mechanism and normal
TORA reactive processing, giving us large-scale routing support for
both fixed, and 'at home' mobile, hosts. To support the movement of
the mobile hosts, through the injection of the host routes, we seek
a mechanism that operates in harmony with TORA's notion of height-
based routing, and permits a large degree of flexibility and
scalability concerning the method and scope of host-specific state
injection. The design objective is to localize the scope of
handover-induced messaging so as to reduce the processing load on
routers as much as possible, while maintaining routing efficiency.
Domain scalability is clearly the end goal and the resulting
mechanisms are outlined below.
3.2 TORA Handover Processing
TORA MER differentiates nodes into two classes: routers and hosts.
Routers execute the full MER protocol while hosts execute only a
limited state machine that does not involve packet forwarding. Base
stations (AR) are routers, and mobile hosts (MH) are handed over
between routers. In general, routers may also be mobile (e.g.
mobile ad hoc networks), but we will not consider that case here.
The Mobile enhanced TORA protocol operates reactively, both in terms
of initial route construction and route maintenance in response to
unforeseen topological changes. We have already seen how TORA's
route construction process can be made proactive. Now, we will show
how TORA can respond to known topological changes, whether foreseen
or unforeseen but anticipated.
O'Neill, Corson, Tsirtsis 16
Internet Draft EMA July 2000
@ @
@@@@@@@@@@ @@@@@@@@@@
@ .------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"
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.
O'Neill, Corson, Tsirtsis 17
Internet Draft EMA July 2000
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 Figure 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 involving 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 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. EMA and Mobile IP Convergence - text from [EMA-MIP] draft
Mobile IP (MIP) (versions 4 and 6) provides for the potential
movement of a Home IP address throughout the Internet, from a home
domain subnet, throughout foreign domain subnets equipped with MIP.
It does so by providing a Mobile Node (MN) with a local and
potentially short term IP Care of Address (CoA) in a foreign domain,
towards which packets can be indirectly tunnelled. This CoA is
reported back to a Home Agent (HA), who then tunnels packets, sent
O'Neill, Corson, Tsirtsis 18
Internet Draft EMA July 2000
by any Correspondent Node (CN) to the Home address, towards this
CoA. In addition, direct tunnelled communication, bypassing the HA,
can be achieved through additional signalling between the MN and the
CN. A Foreign Agent (FA) entity can also optionally exist to assist
the MN in the foreign domain by terminating tunnels and acting as a
proxy CoA, a CoA allocator and a proxy signalling point for MIP
signalling.
This section outlines the inter-working architecture for EMA and
Mobile IPv6/v4 that provides mutual co-existence and benefits, both
for the user and the operator.
4.1 EMA / MIP Architectural Considerations
Firstly, the EMA envisages a rich set of hand-over capabilities that
encompass a range of existing, predictive (cellular) and non-
predictive (inter-technology) hand-over models and requirements. The
EMA signalling requirements are a super-set of existing MIP hand-
over capabilities as will be described in detail later, which
indicates that some additions will be required in MIP if EMA is to
solely rely on MIP signalling. Specifically, MIP does not presently
support forward hand-over rooted at the OAR, nor does it provide the
required information exchange between neighbouring ARs to facilitate
such forward hand-over in an all-IP solution. There have however
been drafts and discussions suggesting such additions and these are
in line with the desire for MIP take a significant role in 3G/4G
cellular solutions.
Secondly, the MIP architecture assumes a MN is from an arbitrary
home domain, and an arbitrary HA within that domain. We therefore
cannot make any assumptions in EMA as to whether or not this Home
Domain is equipped with a MER protocol. Equally, we know that any
visited foreign domain may be either MER or non-MER equipped, and we
need to ensure that MIP continues to operate as normal as a MN moves
through MER and non-MER domains. The conclusion therefore is that
MIP functionality related to the Home Address as a source /
destination address, covering CoA registration, HA capabilities and
route optimisation/binding features, must be orthogonal to EMA. EMA
is instead associated with the CoA, FA/Care of Router (CoR), MN-AR
signalling, and the temporary forwarding (between CoA's on hand-
over) features of MIP. The specific details change slightly between
MIPv6 and MIPv4, and depend on the type of CoA (Co-located or not).
Each scenario is broadly described in the following sections.
Thirdly, and finally, the types of Internet access supported by MIP
and MER functionality are very different and are part of the overall
commercial opportunity. MIP facilitates roaming into foreign domains
and links, from a Home link within a Home Domain. Associated AAA
interfaces are used to control access to the foreign links where
necessary, and may also be used to install policy as to how user
traffic is forwarded. These forwarding options provide for IP
traffic associated with a home session address to go to and from the
O'Neill, Corson, Tsirtsis 19
Internet Draft EMA July 2000
Home Domain (forward and reverse HA tunnelling) as in the remote
access model. The other options allow for direct tunnelled
communication between CN and MN (HA bypass) through
optimisation/binding, and in the case of Co-located Care of
Addresses (CCoA) based sessions, native communication independent of
the home address and MIP tunnelling features (as in local or roaming
access). The MIP CCoA is however only a valid session address on a
specific foreign link, and the utility of this address for native
service is consequently severely limited, and it's use therefore
actively discouraged in Mobile IP.
Some movement of this CCoA address is, however, supported in MIP
through the use of temporary tunnelling between ARs, with the
current CCoA at the old AR being treated like a Home Address, and a
new CCoA from the new AR acting as the tunnel endpoint. To aid
subsequent discussions we describe temporary tunnel forwarding
between adjacent ARs as "Horizontal" MIP forwarding, whereas
standard indirect tunnel forwarding via the MN's HA in its Home
Domain, or direct from a CN using optimisation, is termed
"Vertical" MIP forwarding.
MER also enables native communication using the CCoA as a normal
source (destination) session address, but with significantly
increased utility, as a result of the MER ability to update the
routing tables in the domain to enable the CCoA to move with the MN.
The combination of MIP and MER can therefore support both native and
remote access models, along with hybrid combinational models. From
the perspective of a foreign ISP, a roaming MN can be offered native
service and/or non-optimised/optimised remote access depending on
the user's/home operator's privileges in the foreign domain,
assuming appropriate AAA support features are developed.
In the existing UMTS model, the benefit of the co-existence of these
models is clear because the present UMTS network can only support
the remote access model from the MN back through SGSN and GGSN to
the external 'Home' ISP (today via GTP tunnels). This external ISP
provides both the non-routable 'Home' IP address to the MN, and all
associated IP services and onward connectivity to the wider
Internet. Significant benefits would accrue to both the UMTS network
operator and to users if, in addition, the UMTS network could
support native IP services using local IP addresses, local IP
service infrastructure, and direct connectivity between users on
that network and out to the wider Internet. This commercial context
provides additional justification for the co-existence of MIP
(remote access) and EMA:MER (as an efficient means to support native
forwarding) within a future all-IP 3G/4G solution. The details below
will illustrate this in more detail.
O'Neill, Corson, Tsirtsis 20
Internet Draft EMA July 2000
4.2 Converged EMA / Mobile IP Addressing
EMA Access Routers provide a temporary address to the MN in any
domain in which it roams, with the address changing on a per IP
session basis. This temporary address is allocated by the AAR when
the MN has data to send, or when the MN has been paged for incoming
traffic. In IPv6 the MN can automatically and rapidly build a
temporary address by simply appending it's EUI to the advertised
prefixes from it's chosen AAR. This temporary address (and
associated service restriction) is similar to the address that is
today allocated to the majority of dial-up users. These users do not
need permanent IP addresses because they only utilise applications
which are initialised through a client server process...(WEB, mail,
newsgroups, ICQ etc) in which outgoing traffic informs the servers
(and any onward users) of the users IP address. This temporary
address is not however sufficient for users with servers who must be
able to advertise the server address (e.g. DNS), for corporate
roamers who require a valid address from their home network, and for
users of peers to peer applications who wish to receive incoming
calls.
Therefore, in addition to the temporary session address, the MN may
also have a persistent IP address allocated via DHCP (or whatever)
which is used at the IP layer as a globally unique, stable and hence
advertised identifier. This IP address is associated with, and
allocated by, the home ISP or corporate, and is associated with the
home link of the MN. This address may be installed into DNS and SIP
systems for example, and cached by knowledgeable users. When
compared to cellular systems, the persistent address is in concept
similar to the IMSI, whilst the temporary address is in concept
similar to the T-IMSI.
The converged Mobile IP / EMA addressing architecture requires that
the persistent address is used as the Mobile IP Home address to
ensure that the MN may be contacted when roaming using normal Mobile
IP mechanisms. The local temporary address is used as the Mobile IP
Co-located Care of Address (CCoA) and enables this address to be
used for MIP tunnelling as well as for native IP service. The
benefits of this co-existence may be summarised as following;
Mobile IP is used to provide global roaming of a global address
whilst EMA provides routable local addresses.
The local address can be used by the mobile node to source traffic
from any AR within the EMA domain due to the EMA host redirect
routes and IP hand-over. The local address can also act as a sink of
traffic from anyone in the Internet who learns the address (MN
initiated is easy of course), limited only then by the scope of the
address (global, site local, link local, private etc). The MN
persistent home address can be used to sink traffic from any
Internet host either via Home agent or Correspondent Node tunnelling
to the CCoA. The MN persistent home address can be used to source
traffic directly to Correspondent Nodes or via reverse tunneling to
the Home agent and Home domain.
O'Neill, Corson, Tsirtsis 21
Internet Draft EMA July 2000
Further details of the benefits of this co-existence are described
in [EMA-MIP]
5. Scalability Characteristics of EMA:TORA
This is achieved due a number of novel design decisions which should
enable EMA to be supported across large AS's, equivalent to today's
OSPF / IS-IS interior routed domains (many thousands of routers).
5.1 Temporary Session Addresses
The temporary session address means that a MN always starts any IP
session being routable on a prefix route. A host route is only
required for subsequent movement away from this first access router
whilst in-session. When the session ends, the address and associated
host state can be removed. When the mobile is not in-session, there
is no implication on either the domain routing tables or the
addressing resources.
5.2 Aggregate Prefix Routes
The use of prefix routes means that the network can grow to be a big
domain with a large number of access routers, supporting both mobile
and fixed access technologies. Mobility becomes a delta on top of
the prefix fabric rather than having host routes replicate the job
of the prefix route in a very inefficient way.
5.3 Localised Host Redirect Routes
The presence of the prefix aggregate route, and the use of the
temporary session address results in the host route only being
required for in-session mobility. The directivity of the host
redirect, between the NAR and the OAR, and the chaining of such
redirects, results in significant localisation of mobility induced
routing messaging and host route state, instead of a domain wide
host routes. The degree of localisation is dependent on the IP
topology, associated routing metrics and even traffic engineering
based TORA route selection.
The degree of router meshing and the number of levels in the router
hierarchy affect the potential reach of redirect host routes. Higher
degrees of meshing, lower in the network, results in a more direct
horizontal path between adjacent access routers for the hand-over
message and the resulting redirect host route. This causes incoming
packets from the core, and from most other access routers, to take
longer to reach the host redirect state. However it will be seen
sooner by packets coming from any intermediate AR (and associated
connected sources) between the AAR and the present AR of the mobile
due to the installed 'shallow' host route.
O'Neill, Corson, Tsirtsis 22
Internet Draft EMA July 2000
A more tree like structure results in a more triangular path between
adjacent nodes going higher into the core. This will mean that
incoming packets from the core and from most other access routers
will see the redirect later whilst the intermediate AR packets will
see the redirect earlier. In addition, the use of preferential route
metrics can be used to 'steer' the host redirect routes either
higher or lower in the infrastructure as required, giving increased
control above and beyond that 'implied' by the topology.
5.4 In-session Dynamics
It is clear that an 'always on' mobile can be roaming anywhere over
long periods of time. Any mobile routing solution that allocates
persistent IP addresses, is forced to track that address in the
routing/paging system leading to scaling problems. We instead
separate the paging system from the mobiles care-of-address. In
addition, we only track the mobile in the routing system during
active IP sessions, which is likely to be a small proportion of the
'always on' mobile activation time. Further, whilst in-session, most
internet applications require that the user becomes relatively
stationary in the topology because it would be uncommon to drive,
walk or generally concentrate on other things whilst, in parallel,
browsing the web. There are certainly situations in which this
application assumption is incorrect but in those cases it is other
factors that limit the impact of host routes. For example, in the
case of IP telephone calls where people are occasionally driving or
walking, the call durations are short and the associated hand-over
statistics are both well-known (GSM) and of little concern. In the
case of planes and trains, we can simply support such 'rare' hosts
routes within the localised cellular infrastructure and access
routers along major routes through suitable dimensioning and
associated tariffing. However, it is likely that in time IP
infrastructure will be installed in such moving platforms resulting
in a single aggregated host prefix for all those co-located nodes
moving in sympathy.
Further, the use of the MobileIP Permanent Home address and bindings
ensures that the user is always reachable if the host route needs to
be removed (either route hold timer expiry or CCoA reset). Finally,
the profile specific IP session, address and route hold timers
ensure that we can use tariffing to tune and control the impact of
in-session mobility and usage patterns on the overall routing
system.
5.5 TORA MER
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
O'Neill, Corson, Tsirtsis 23
Internet Draft EMA July 2000
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 table
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
based on the availability of fine-grained link status sensing,
possibly from layer 2 mechanisms or from layer 3 mechanisms such as
[FLIP].
5.6 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
O'Neill, Corson, Tsirtsis 24
Internet Draft EMA July 2000
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.
6. Comparison to Alternatives
6.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 and to
provide signalling and temporary tunnelling services during hand-
over Mobile IP 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
O'Neill, Corson, Tsirtsis 25
Internet Draft EMA July 2000
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. In addition, to
support the full set of cases, a converged solution employing both
EMA:MER and MIP clearly provides substantial benefits to the overall
system as shown in [EMA-MIP]
6.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.
6.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.
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 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.
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
O'Neill, Corson, Tsirtsis 26
Internet Draft EMA July 2000
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.4 OBAST
While not a direct alternative to the EMA, a recent proposal on Open
Base Station Transport (OBAST) [OBAST] is similar in spirit to the
work behind EMA. A driving force behind both works is the
development of a seamless IP layer hand-over model where radio layer
specifics are hidden from hand-over processing. Whereas EMA then
focuses more on specific routing and tunneling trade-offs within its
proposed location management architecture, OBAST is somewhat larger
in scope (e.g. it considers some transport layer issues) and puts
forth a network architecture for wireless access mirroring that of
the existing fixed Internet. The two proposals are similar in this
latter sense as well in that EMA (at the network layer) advocates
full convergence of fixed and mobile routing through the development
of mobility-enhanced routing algorithms that permit natively-routed
host mobility together with fixed host routing. Both approaches
also view Mobile IP as useful for supporting inter-domain terminal
mobility. Regarding hand-over control, EMA permits both network and
mobile-controlled hand-over. OBAST is currently silent on the issue
of MN-controlled hand-over, but intends support for a distributed
form of BS-assisted hand-over elected "call anchors". OBAST also
strongly prefers to consider only IPv6 whereas EMA prefers IPv6 but
intends support for IPv4 as well.
7. 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, source address checking would be necessary
and is assumed at all AR's.
The MIP mechanisms described above can re-use mobile IP and AAA
mechanisms as proposed in [AAAMIP] and [CIP] since the requirements
and level of security required are the same. We specifically outline
below the method of authenticating users in the signalling plane
within an EMA domain due to the critical nature and hence threat of
false hand-overs.
O'Neill, Corson, Tsirtsis 27
Internet Draft EMA July 2000
7.1 Authenticating users within a domain
Associated with each mobile node (MN) is a unique identifier known
as its Mobile ID (MID). This is taken here to be an IP address
(which may or may not be associated with an interface), but which
may also be a Network Access Identifier (NAI).
On arrival at a NAR, a MN must first either furnish proof of prior
authentication within the domain, or be initially authenticated
before it may send or receive any form of control or data traffic.
Proof of prior authentication may be readily available in the form
of a pre-paid SIM card or from a MN's private authentication key (as
described subsequently).
To perform an authentication check, the MN must present its
credentials (including its MID) to the NAR. The method to conceal
these items over the air interface is not addressed here.
This transmission also advertises its current CCoA (if any) which it
may have auto-generated on arrival at this NAR. Consequently, this
authentication information may be passed to the NAR with a CCoA
(IPv6), or with a NULL source address (IPv4) as is commonly done
with DHCP. In the latter case the NAR (acting as a proxy for the
MN) substitutes its address for the NULL address. The NAR then
forwards the information to the local authentication server with
which it already has a Security Association (SA).
The local authentication server may then contact other servers as
necessary to perform the authentication check. The outcome of the
check (along with the MN's public key) is returned to the NAR. If
successful, the NAR computes a Private Authentication Key (PAK) for
the MN as an MD5 hash of the MN's MID and the domain's private
"network key" known to all domain ARs. The computation of PAK and
PIK herein are based on the PID scheme of [CIP]. The PAK forms a
shared secret known only to the MN and the network, and serves as
proof of MN authentication to other NARs in the domain.
Unsuccessful authentication results in service denial.
After a successful authentication, the NAR checks the MN's CCoA and,
if NULL (IPv4), allocates a new CCoA for the MN. Using the resultant
CCoA, the NAR computes a Private Identification Key (PIK) for the MN
as an MD5 hash of the MN's CCoA and the domain's private "network
key" known to all domain ARs, encrypts the PIK and PAK with the MN's
public key, and sends these to the MN along with the network's
public key and the MN's CCoA. Being keyed to the MN's CCoA, the PIK
is valid as long as the MN uses this CCoA. The PIK can be used to
authenticate (and optionally to encrypt) IP control packets over the
air interface. Authentication is performed by creating a short hash
from the (PIK, timestamp, packet content) triple that is placed into
the transmitted packets. The validity of each packet can be easily
checked by any NAR even immediately after a handoff and without
prior communication with the MN or with the OAR.
O'Neill, Corson, Tsirtsis 28
Internet Draft EMA July 2000
In addition to authenticating control packets, the PIK can
optionally also be used to provide security for data packets
transmitted over the wireless link. To this avail, any known,
shared secret-based security mechanism can be used where the PIK
serves as the shared secret.
8. References
[EMA-MIP] A. O'Neill, S. Corson, G. Tsirtsis, "EMA Enhanced Mobile
IPv6/IPv4", Internet-Draft,draft-oneill-ema-mip-00.txt, July 2000.
[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.
[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.
[OBAST] P. Neumiller et. all, "Open Base Station Transport (OBAST)",
Internet Draft (work in progress), <draft-neumiller-obast-reqs-
01.txt>, June 2000
O'Neill, Corson, Tsirtsis 29
Internet Draft EMA July 2000
[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
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 88260073
george.tsirtsis@bt.com
gtsirt@hotmail.com
O'Neill, Corson, Tsirtsis 30
Internet Draft EMA July 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
O'Neill, Corson, Tsirtsis 31
Internet Draft EMA July 2000
O'Neill, Corson, Tsirtsis 32