[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Personal                                                     A. O'Neill
                                                            G. Tsirtsis
Internet Draft                                                S. Corson
Document: draft-oneill-ema-02.txt                       Ansible Systems
Category: Informational                                       July 2000

                          Edge Mobility Architecture

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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


      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

   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

   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

   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

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

   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-

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

   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
         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
         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

   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

   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

   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

   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


   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

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


   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


   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,

   [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

   [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
      (+44) 1473-646459

      M. Scott Corson
      University of Maryland
      Ansible Systems
      (+1) 301-405-6630

      George Tsirtsis
      (+44) 020 88260073

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

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/