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

Versions: 00 01 02

INTERNET-DRAFT                                                A. O'Neill
Internet Engineering Task Force                              G. Tsirtsis
Expires in August 2000                                                BT
                                                               S. Corson
                                                  University of Maryland
                                                         Ansible Systems
                                                            9 March 2000



                       Edge Mobility Architecture
                       <draft-oneill-ema-01.txt>


Status of this Memo

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This draft concurs with the authors of Cellular IP and HAWAII
   regarding the need for domain-based routing support in handling edge
   mobility.  It suggests that a general routing solution might be
   advantageous and presents the loose framework of a possible routing
   architecture. It also suggests a specific protocol based on TORA for
   the implementation of such an architecture. It advocates the creation
   of a specific IETF working group to address an overall architecture
   for edge mobility routing, specific extensions to existing routing
   protocols to accomplish that architecture, and extensions to existing
   Internet technologies to support this architecture.









O'Neill, Corson, Tsirtsis                                       [Page 1]


Internet Draft                     EMA                        March 2000




INDEX

   1. Introduction

   2. Mobile Routing Architecture
      2.1 Mobile Session Start-Up
      2.2 EMA Intra-domain Hand-over Messaging
      2.3 Break Before Make - BBM
      2.4 Make Before Break - MBB
      2.5 Hybrid Model
      2.6 Mobile Switch Off
      2.7 EMA Inter-domain considerations

   3. TORA-based Mobile Enhanced Routing (MER)
      3.1 Inter-AR Routing
      3.2 Mobile Host Routing
      3.3 TORA Mobility Concepts

   4. Scalability
      4.1 Performance

   5. Comparison to Alternatives
      5.1 Mobile IP
      5.2 Cellular IP
      5.3 HAWAII

   6. Security

   7. References




















O'Neill, Corson, Tsirtsis                                       [Page 2]


Internet Draft                     EMA                        March 2000





1. Introduction

   Telecommunications networks are rapidly transitioning towards an all-
   IP architecture.  This trend is not restricted to fixed networks.
   Second generation cellular networks have been modified to provide
   limited data services, and third generation systems undergoing
   rollout now have been designed to deliver IP connectivity to the end
   user. These system continue to support mobility based on the
   continuing advancements in wireless technology. However, with IP
   routing technology being pushed out to the network's edge, it becomes
   less cost effective to support the various modes of layer 2 edge
   mobility management that accompany today's cellular and PCS
   technologies.  Rather, unified solutions become advantageous to
   domain operators, wherein mobility management becomes an integral
   component of an IP layer routing protocol and associated hand-over
   mechanisms.

   Internet routing protocols have been traditionally designed from an
   assumption that the location of an IP interface in the topology is
   static. In addition, they assume that address allocation within the
   topology will aim to provide multiple levels of IP address
   aggregation such that routing protocols can deal with address
   prefixes, rather than large numbers of host routes. Within this
   framework, traditional intra-domain protocols, such as OSPF, need
   only react to infrequent changes to the network due to link or router
   failures or permanent modifications to the addressing scheme or the
   topology.

   Mobile Ad hoc NETwork (MANET) routing protocols have been developed
   to address what could be considered to be an extreme scenario,
   whereby the mobile nodes have permanent IP addresses which can
   rapidly roam through an ad hoc topology, leading to the need for
   alternative routing technology and the general loss of aggregation
   opportunities.

   A third family of routing protocols is now under investigation for
   the case in which the core topology is essentially fixed but the end
   systems are mobile. This is the classical edge mobility scenario that
   is today supported by cellular networks, primarily as part of the
   cellular technology elements (GSM, GPRS etc). Migrating this routing
   function to the layer 3 IP routing protocol, to release all the end-
   to-end internetworking benefits which has aided the deployment of the
   Internet, would tend to suggest a fusion of the MANET and traditional
   routing protocol architectures. The primary aim is to move the IP
   interface location in the routing topology as the mobile changes base



O'Neill, Corson, Tsirtsis                                       [Page 3]


Internet Draft                     EMA                        March 2000


   stations so that active IP sessions are maintained. We refer to this
   form of routing as Mobile Enhanced Routing(MER), its intra-domain
   deployment providing Edge Mobility support within that domain. This
   is clearly only one of the possible models and this draft does not
   make any judgments as to the pro's and con's of this particular
   mobility model, but is simply using it as a precursor for the
   discussion of the related hand-over architecture.


                     External BGP Peerings To the Internet
                       |              *                |
                       |              *                |
            Allocating |              *                |     Roaming
            Domain    _|_             *               _|_    Domain
            Border-->|   |---------------------------|   |<--Border
            Router   |HBR|            *              |FBR|   Router
                     |___|            *              |___|
              MER      |              *                |     MER or
           Protocol   _|_             *               _|_ OSPF etc)
                     |   |            *              |   |
                  ,--|HIR|--,         *           ,--|FIR|--,
                  |  |___|  |         *           |  |___|  |
                 _|_       _|_        *          _|_       _|_
                |   |     |   |       *         |   |     |   |
                |HAR|     |HAR|       *         |FAR|     |FAR|
                |___|<--->|___|<------*------>  |___|<--->|___|
                                      *
                Movement          Movement         Movement
              intra-domain      inter-domain      intra-domain


           Figure 1: Edge Mobility Domains as part of the Internet


   These edge mobility domains as shown in figure 1, can be considered
   to have a single IP routing protocol which runs between routers in
   the EMA domain, with some of those routers being the edge access
   routers (ARs) equipped with, or connected to a (potential) diversity
   of radio base station technologies such as CDMA, TDMA and Radio LANs
   etc. The radio layers are assumed to provide the well known layer 2
   hand-over models and other capabilities including break-before-make,
   make-before-break, power measurement, mobile assisted hand-over,
   paging and security features.  To facilitate internetworking, inter-
   access router co-ordination is assumed to use IP-based communication
   using messages which are abstractions of the messages which are today
   carried in cellular technology-specific messages, often via central
   processing elements.




O'Neill, Corson, Tsirtsis                                       [Page 4]


Internet Draft                     EMA                        March 2000


   This draft proposes a general approach to the support of this edge
   mobility function, with the aim of being generic enough to support a
   range of different routing protocols, as well as enabling hand-over
   between diverse types of cellular technology through capability
   exchange between radio-equipped access routers. It does not deal with
   the details of these mechanisms as they are specific to the type of
   routing protocol selected. This draft does also not discuss the
   effects of the architecture on DNS, DHCP and infrastructure services,
   nor does it contribute to the debate on the appropriate layer and
   model for mobile terminal paging.

   In section 2, we describe an Edge Mobility Architecture (EMA) for the
   support of edge mobility, with the aim of being general enough to
   support a range of different routing protocols, as well as enabling
   hand-over between diverse types of cellular technology through
   capability exchange between radio-equipped ARs  In section 3 we
   provide a description of one proposed approach for Mobile Enhanced
   Routing, and compare it with alternative proposals for IP mobility
   support in section 5. In section 4 we look at the performance and
   scalability of our solution based on simulations that have been
   implemented. It will become clear that the routing approach put forth
   here needs to be coupled with a companion paging architecture for
   location management, the details of which are not covered in this
   draft.


2. Mobile Routing Architecture

   The architecture proposed assumes that modifications to either MANET
   or traditional routing protocols are possible which will enable these
   protocols to comply with this architecture and hence facilitate a
   message set and control model which has a degree of protocol
   independence. Clearly, the actual detailed mechanisms, message
   content/timing and performance are going to be dependent on the type
   of intra-domain routing protocol that forms the basis for the
   mobility extensions.

   The architecture has seven main components, these being the use of;

      a) the provision of a modified intra-domain routing protocol which
      provides prefix-based routing within a domain, with each prefix
      representing a block of IP addresses allocated to each NAP or base
      station in the domain, as well as host routes to support mobile
      terminal migration away from the allocating (IP address) base
      station,

      b) the provision and use of a virtual link for routing exchange
      and messaging between cooperating access routers to exchange



O'Neill, Corson, Tsirtsis                                       [Page 5]


Internet Draft                     EMA                        March 2000


      capabilities, and to effectively and locally manage the hand-over
      of the responsibility for, and routing of, the mobile terminal and
      it's associated IP address,

      c) the provision and use of a temporary tunnel to redirect packets
      in flight between the old access router and the new access router
      whilst routing converges, and

      d) the ability to inject a host route for the mobile,

      e) the ability to poison the existing route to the mobile whether
      a host  or prefix route

      f) a method to return the allocated IP address to the allocating
      access router on mobile session termination at a different base
      station in the same domain.

      g) the use of mobile IP across provider boundaries to facilitate
      the temporary movement of an IP address (on a mobile terminal
      interface) away from its home domain whilst maintaining active
      sessions. The mobile IP tunnel is located on an access router in
      the old domain (HA), across the inter-domain boundary to the
      access router in the new domain (FA). In the foreign domain, the
      tunnel is extended to further access routers in the foreign domain
      using normal Mobile IP foreign agent mechanisms. The details are
      covered in section 2.7.

   The reasons for each of these components will be explained in the
   following sections which will give examples for CDMA (make-before-
   break) and TDMA (break-before-make) hand-over.

2.1 Mobile Session Start-Up

   The mobile host (MH) connects to the nearest access router and is
   brought into the IP routing domain by requesting and being allocated
   an IP address out of the block of addresses managed by that access
   router. This Allocating Access Router (AAR) will be advertising the
   IP address prefix associated with that address block into the intra-
   domain routing protocol such that 'at home' mobiles have a
   proactively and permanently advertised route, and are immediately
   reachable to all hosts in the internet. Note that end hosts
   statically attached to the EMA domain via Network Access Servers can
   be viewed as "at home" mobiles who never move. As the MH moves access
   routers, this IP address moves with them so that higher-layer
   sessions are unaffected. This is accomplished by modifying the intra-
   domain routing using hosts routes (longest mach) to overrule  or
   overwrite the underlying proactive prefix routing to the AAR. Placing
   an appropriate set of messages over IP ensures that a wide range of



O'Neill, Corson, Tsirtsis                                       [Page 6]


Internet Draft                     EMA                        March 2000


   radio technology specific hand-over models can be accommodated within
   a single IP model to allow for internetworking of IP over those
   diverse technologies.

2.2 EMA Intra-domain Hand-over Messaging

   In certain wireless technologies (e.g. GSM), hand-overs can be
   predicted based on signal-to-interference measurements at nearby ARs
   (radio interface in router) or attached downstream base stations
   (remote BS's).  After the appropriate hand-over criteria are reached,
   a hand-over procedure can be initiated from an Old Access Router
   (OAR) to a New Access Router (NAR) in response to a known topological
   change.  In other instances, e.g. with technologies not supporting
   hand-over prediction, the unanticipated loss of a link should not be
   immediately interpreted at the OAR as an undesirable link failure.
   Instead, the OAR should wait for a time to see if the MH reappears,
   connected either to itself or to a NAR.  If it appears at a NAR, the
   OAR again treats this as a known topological change and reacts
   accordingly.  If it does not appear, the OAR eventually declares link
   failure and reacts accordingly. The generalised message set of EMA
   described below and shown in Figure 2, may be mapped to a range of
   AAA protocols/models, cellular signaling and routing technology etc.
   to enable a specific solution to be designed. The aim of the
   description is to capture the essence of the model in terms of
   responsibilities and timings for IP hand-over.

               |>>>>>>>>>>>>>>> 5.RUA >>>>>>>>>>>>>>>|
               | |<<<<<<<<<<<<< 4.RU  <<<<<<<<<<<<<| |
               | |                                 | |
               |_|                                 |_|
              |   | -----------> 3.HI/D --------> |   |
              |OAR| <----------- 2.HR <---------- |NAR|
              |___| -----------> 1.TIN ---------> |___|

               Figure 2: Basic EMA Hand-over Messaging

   If MH movement is predicted, then the OAR may be informed by the MH
   (if mobile assisted operation is implemented) with a Host Tunnel
   INitiation (H-TIN) packet or via a layer 2 signal.  This causes the
   OAR to build a temporary, soft-state tunnel towards the NAR and to
   send a Tunnel INitiation (TIN) packet to the NAR.  This message may
   give the NAR advance warning of hand-over.  The tunnel can serve to
   help avoid packet loss during any link dead-time.  This sequence of
   events and the tunnel's construction are optional.  What is not
   optional is the construction of a virtual link at the OAR. If hand-
   over is predicted, this virtual link is accompanied by a tunnel and
   is terminated at the NAR.  If hand-over is not predicted and the link
   to the MH is suddenly lost, a virtual link to the MH itself is



O'Neill, Corson, Tsirtsis                                       [Page 7]


Internet Draft                     EMA                        March 2000


   retained for some time while the OAR awaits notification of the MH's
   location.

   Otherwise, the EMA hand-over model has its focus at the NAR and all
   mandatory messaging begins there.  On arrival at the NAR, the MH
   (operating in mobile-assist mode) brings up a new link for IP
   purposes (i.e. Make) to the NAR.  This triggers the NAR to send a
   Hand-over Request (HR) message to the OAR which can contain MH
   credentials and privileges.  The OAR responds with either a Hand-over
   Initiation (HI) (i.e. AAA information and associated state) packet if
   hand-over is permitted, or else with a Hand-over Denial (HD) packet.
   The HR packet is repeatedly sent until either a HI or HD is received,
   or it is determined that the OAR is unreachable.  If hand-over is
   permitted, the HI packet begins a three-way handshake to transfer
   control of the mobile to the NAR.  On receipt of the HI, the NAR
   initiates routing redirection by sending a Routing Update (RU)
   towards the OAR.  This is sent reliably hop-by-hop towards the OAR,
   and may be resent multiple times until a RU Acknowledgement (RUA) is
   received at the NAR or the OAR is determined to be unreachable.  This
   message exchange remains the same for both BBM and MBB hand-over,
   whether or not the hand-over can be predicted.

2.3 Break Before Make - BBM

   TDMA technology such as GSM only allows the mobile to be connected to
   a single access router at a time, with a data path dead-time incurred
   during hand-over. To minimise the potential for packet loss while
   maintaining efficient routing, the inject/poison route features are
   delayed and invoked only after the Make event occurs at the NAR
   thereby ensuring that the link to the OAR is used until the break
   occurs. When the mobile disconnects at the radio layer from the old
   AR (Break), the new AR, through the inter-AR virtual link or tunnel
   (if present), is immediately known to be the next best hop, and
   packets hitting the old AR are immediately redirected down the tunnel
   to the new AR.  If a tunnel is not present (unanticipated break),
   then packets may be cached at the OAR in anticipation of a hand-over,
   or simply dropped.  Some time later the mobile will attach to the new
   AR (Make) and, if the tunnel is in place, will immediately receive
   in-flight and locally cached packets.

   Once the Make event occurs, the new AR informs the old AR of the need
   to commence hand-over. The two ARs now collaborate to locally inject
   the new route into the routing domain and poison the old route.
   Packets to the mobile will then head towards the new AR route. This
   route redirect process will typically converge during the data path
   dead-time ensuring that only a small number of packets (if any) will
   need to be tunnelled from old to new AR. Once routing has converged,
   the old AR will eliminate the redirect state associated with the



O'Neill, Corson, Tsirtsis                                       [Page 8]


Internet Draft                     EMA                        March 2000


   temporary tunnel.  The reception of the mobile at the new AR is then
   confirmed through acknowledgement messages to the old AR which is
   used to confirm hand-over of responsibility for the mobile and it's
   IP address in the system.

   The following steps outline the break-before-make (BBM) procedure of
   EMA which is also shown in figure 3:

      1) Detect imminent hand-over and inform new and old ARs
      (optional).
      2) Build a temporary tunnel from old AR to new AR  (optional).
                          (Break event occurs)
      3) Await Make event at new AR.
      4) On Make event, inject new route to the new AR and poison old
      route to old AR.
      5) Tear down tunnel at old AR (if present).


         OAR     NAR             OAR======NAR          OAR======NAR
            |   |                   |    |                     |
            |   |                   |    |                     |
             MH->                     MH->                   MH->
         a)Before Handover    b)sensing new link      c) Tunnel Data
                                 build tunnel             on break

                               ^
                               |
                     OAR======NAR              OAR     NAR
                              |                        |
                              |                        |
                            MH->                     MH->
                  d)Inject new routing     e)Routing converges
                    on make, forward         tear down tunnel
                  cached data (if any)

          Figure 3: Basic EMA BBM Hand-over (with temporary tunnel)


   The first two steps are optional because it is not always possible to
   predict a hand-over in advance.  An unanticipated link failure may
   occur between the old AR and the mobile host prior to its arrival at
   the new AR. The "inject/poison" route features of EMA can be invoked
   only after the old and new ARs have been identified, and have agreed
   to the hand-over by creating the dynamic, temporary redirect tunnel
   between them. Note that for efficiency purposes a single redirect
   tunnel could be pre-configured between adjacent access routers to
   support all inter-access router hand-overs, and dynamic mobile-
   specific redirect tunnel state temporarily installed against that



O'Neill, Corson, Tsirtsis                                       [Page 9]


Internet Draft                     EMA                        March 2000


   aggregate tunnel.

2.4 Make Before Break - MBB

   CDMA technology enables a mobile terminal to be connected to two base
   stations at the same time and to undertake measurements to establish
   the preferred channel and hand-over time. This hand-over time
   determines the timing of the Make event.  As with TDMA, it is
   desirable to wait until the Make event occurs before injecting the
   new host route.  However, unlike TDMA, packets continue to arrive at
   the mobile via the link to the old AR prior to the Make event.  Thus
   the temporary tunnel is typically not needed in CDMA, but it is
   constructed in case an unexpected early break occurs with the added
   benefit that in so doing the same hand-over state machine can be used
   for both BBM and MBB modes.

   The following steps outline the make-before-break (MBB) procedure of
   EMA which is also shown in figure 4:

      1) Detect imminent hand-over and inform new and old ARs
      (optional).
      2) Build a temporary tunnel from old AR to new AR  (optional).
      3) Await Make event.
                                     (Make event occurs)
      4) On Make event, inject new route to the new AR and poison old
      route to old AR.
                                      (Break event occurs)
      5) Tear down tunnel at old AR (if present) and remove state of
      poisoned route.

                                                                ^
                                                                |
         OAR      NAR             OAR=====NAR          OAR=====NAR
            |                        |   |                |   |
            |                        |   |                |   |
             MH->                     MH->                  MH->
       a)Before Handover    b)sensing new link     c)Inject new routing
                                build tunnel              on make


                     OAR=====NAR              OAR     NAR
                        |   |                        |
                        |   |                        |
                          MH->                     MH->
                  d)Routing converges       e)Break occurs
                    tear down tunnel

         Figure 4: Basic EMA MBB Hand-over (with temporary tunnel)



O'Neill, Corson, Tsirtsis                                      [Page 10]


Internet Draft                     EMA                        March 2000



   We are not directly addressing IP layer support for CDMA soft hand-
   over.  While feasible in terms of IP layer routing and copying, this
   mode of CDMA-based hand-over requires highly synchronised packet
   delivery over the air interface(s) to the mobile which may not be
   compatible with a heterogeneous IP network infrastructure. Soft hand-
   over can still be achieved however if the underlying layer 2 (ATM
   AAL) has the required timing and cell duplication functionality as
   presently proposed in 3G systems. This is achieved for example by the
   IP layer at the OAR handing responsibility for soft hand-over to the
   ATM layer which duplicates and times cell delivery to the multiple
   neighbor NAR(s).

2.5 Hybrid Model

   When a hybrid node is able to support both TDMA and CDMA (or other
   combinations of technology) then a consistent set of access router
   and Mobile IP messages makes hand-over of the concurrent sessions
   between TDMA and CDMA access routers possible. This is achieved by
   the base stations understanding each others capabilities, and holding
   up and synchronising the inject and poison stages as appropriate.

2.6 Mobile Switch Off

   It is clear that the migration of IP addresses away from the
   allocating access router can lead to address exhaustion and a gradual
   degradation over time of the usefulness of the proactively advertised
   access router address block prefix. It is therefore critical that at
   the moment that the mobile finishes active sessions, at a distant
   access router, that the IP address is returned to the AAR. This can
   be modelled as a virtual mobile moving from the distant access router
   back to the AAR and then locally returning the IP address. This can
   be accomplished using similar mechanisms which are used to support
   real inter-access router hand-overs, with the access routers acting
   as proxies for the virtual mobile. Their aim is to co-ordinate the
   removal of all host specific routing entries in the domain as a
   result of previous mobility away from the home access router.

2.7 EMA Inter-domain considerations

   In both the BBM and MBB case above if the NAR is in a different
   administrative domain from the OAR, we set-up a Mobile IP (MIP)
   tunnel between the OAR (playing the role of a Home Agent) and the NAR
   (playing the role of a Foreign Agent). This is independent of whether
   the destination domain supports an EMA-MER protocol or a traditional
   routing protocol such as OSPF. [MobileIP] with the extensions
   described in [MIPAAA] should be used so that integrated AAA
   functionality can be provided for roaming users between domains.



O'Neill, Corson, Tsirtsis                                      [Page 11]


Internet Draft                     EMA                        March 2000



   The end of the MIP tunnel in the new domain is the NAR (rather than
   the mobile itself) which means that if the mobile continues moving in
   the new domain, and the domain does not support EMA-MER, then this
   end of the MIP tunnel needs to move with it. This requires re-
   registration of the mobile to its Home Agent (OAR) at every hop
   leading to lower hand-over performance without Mobile IP fast-hand-
   over extensions.  However, we favor this approach because it keeps
   the mobile simple and reasonably unaware of intra/inter-domain
   changes, and it avoids tunneling over the expensive air interface.
   This approach places the network in control while also allows the
   mobile to potentially run Mobile IP, using a Co-located Care of
   Address, back to a third HA (in say the corporate LAN) for its own
   orthogonal purposes.

   If the new domain also supports MER then a hybrid mode of Mobile IP
   and EMA-MER  becomes possible which avoids Mobile IP re-registration
   at each new AR within that new EMR domain.


3. TORA-based Mobile Enhanced Routing (MER)

   The preceding architecture does not specify how an EMA-compliant,
   Mobile Enhanced Routing (EMA-MER) algorithm creates or modifies its
   host and prefix- specific IP forwarding entries, and various
   approaches are possible.  With the objective of building a large-
   scale EMA domain, the Temporally-Ordered Routing Algorithm (TORA)
   appears potentially well-suited for use as an EMA-MER algorithm. TORA
   was originally specified as an on-demand MANET routing algorithm, but
   this mode of operation is not generally required and a proactive mode
   is being specified. Much of TORA's original protocol mechanism deals
   with reaction to link and node failures.  Many of these details are
   not relevant to the discussion here, and we refer the reader to
   [TORA, TORAdraft] for this information.  Here we focus on the high-
   level aspects of TORA necessary to understand its operation as an MER
   algorithm within EMA.

   EMA TORA differentiates nodes into two classes: routers and hosts.
   Routers execute the full EMA protocol suite while hosts execute only
   a limited state machine that does not involve packet forwarding.
   Mobile hosts (MH) are handed over between access routers (ARs) which
   have either local or remote radio interfaces.  In general, routers
   may also be mobile (e.g. mobile ad hoc networks), but we will not
   consider that case here.

   The problem of Mobile Enhanced Routing is divided into two sub-
   problems: inter- AR routing and host-specific routing.  TORA proceeds
   independently for each destination, which enables separate versions



O'Neill, Corson, Tsirtsis                                      [Page 12]


Internet Draft                     EMA                        March 2000


   of TORA to proceed proactively for each AR, and proceed reactively
   for each mobile host in an edge mobility- enhanced mode as necessary.

3.1 Inter-AR Routing

   Within the EMA, Inter-AR routing is prefix-based, such that each AR
   advertises a  prefix address covering a block of host addresses that
   it controls, into the EMA domain so that;

      (i) packets can be proactively routed to hosts with addresses
      covered by these prefixes, and

      (ii) a virtual, bi-directional path exists between any pair of co-
      operating ARs for their communication during mobile hand-over.

   We accomplish this by having a separate version of TORA build and
   proactively maintain a Directed Acyclic Graph (DAG) for each prefix.
   The DAG is a distributed data structure that provides one or more
   routing entries in each router in the EMA domain.  In TORA, each
   router maintains a "height" for a given prefix, and a prefix DAG is
   formed from the set of these heights.  Packets may only be forwarded
   from a router to its neighboring routers with "lower" heights.  In
   this way loop-free, multipath routing is assured.  The router with
   the destination prefix always has the "lowest" height in the DAG.

   Initial prefix DAG construction occurs by having each AR router, on
   initialisation, transmit an optimization (OPT) packet into the
   domain.  The AR prefix DAGs are then maintained via a combination of
   the aforementioned proactive mechanism and normal TORA reactive
   processing. This routing should be continuously maintained, i.e.
   proactively, whereas host-specific routing (to be discussed
   subsequently) should be maintained only as needed, i.e. on-demand or
   reactively.

3.2 Mobile Host Routing

   In the EMA, each host is allocated an interface address covered by
   the allocating AR network prefix.  While the host is at the
   allocating access router (AAR) it is considered to be "at home", and
   packets are routed to the host via the network prefix of the AR.  If
   the host moves away from its AAR, host- specific state is injected in
   the network during hand-over to overrule (via longest prefix match
   forwarding) the host's default DAG and redirect packets to the hosts
   current location. Numerous mechanisms can be defined to achieve this.
   Given that the inter-AR routing algorithm we have chosen is TORA, we
   seek a mechanism that operates in harmony with TORA's notion of
   height-based routing, and permits a large degree of flexibility
   concerning the method and scope of host-specific state injection. The



O'Neill, Corson, Tsirtsis                                      [Page 13]


Internet Draft                     EMA                        March 2000


   design objective is to localise the scope of hand-over-induced
   messaging so as to reduce the processing load on routers as much as
   possible while maintaining routing efficiency.  Domain scalability is
   the end goal.

3.3 TORA Mobility Concepts


                 @                         @
        @@@@@@@@@@                @@@@@@@@@@
        @  .------CR-------.      @  .------CR-------.
        @  |    (0002)     |      @  |    (0002)     |
        @  |               |      @  |I>>>>>>>>>>>>>I|
        @  |               |      @  |I    TIN      I|
        @  |               |      @  |I             v|
        @ OAR             NAR     @ OAR=============NAR
        @(0001)         (0003)    @(0001)         (0003)
        @  |                      @  |I
        @  |                      @  |I
        @  |                      @  |I H-TIN
        @  |                      @  |I
        @  |                      @  |I
        @@ MH->                   @@ MH->
          (0000)                    (-1000)
                 (a)                       (b)


                 @                           @
        @@@@@@@@@@                           @@@@@@@@@@@@
        @  .------CR-------.         .------CR-------.  @
        @  |    (-1002)    |         |    (-1002)    |  @
        @  |     <<<<<<<<<I|         |I<<<<<         |  @
        @  |          UDU I|         |I UDU          |  @
        @  |              I|         |v              |  @
        @ OAR=============NAR       OAR             NAR @
        @(0001)         (-1001)    (-1003)       (-1001)@
        @@@@@@@@@@@@@@@@@@@|                         |  @
                          @|                         |  @
                          @|                         |  @
                          @|                         |  @
                         MH->                        MH@@
                        (-1000)                     (-1000)
                (c)                          (d)

                Figure 6: Anticipated BBM hand-over


   As mentioned, at any given time the destination has the "lowest"



O'Neill, Corson, Tsirtsis                                      [Page 14]


Internet Draft                     EMA                        March 2000


   height w.r.t.  the remaining TORA DAG.  To enable "arbitrary"
   destination mobility within the DAG (i.e. mobility between "any" two
   points in the DAG), the destination should also "lower" its height
   each time it moves and connects to a new point in the DAG.  This
   action preserves the DAG's loop-free, multipath routing property
   while localising the communication necessary to re-orient the DAG.

   A special case of such destination mobility is mobile handover in a
   cellular network. We now illustrate how the TORA height concept
   operates with the EMA message framework with a "GSM-like" scenario of
   BBM hand-over shown in Figure 6.

   The TORA protocol defines an unicast-directed update (UDU) packet
   that replaces the RU message of the EMA.  Similarly, an unicast-
   directed update acknowledgement packet (UDUA) replaces the EMA's RUA
   packet.

   We can only show a portion of the message exchange due to space
   constraints.  The H-TIN packet initiates tunnel creation and
   transmission of the TIN packet.  The Make event is seen in Figure 6c,
   which initiates UDU transmission (we skip the HR and HI phases here)
   to redirect routing via injection of host-specific routing state
   (shown next to the OAR prefix DAG state).  The UDU redirects packet
   flow at each router it passes (via height "lowering" in the DAG)
   towards the NAR.  Since it is sent to the OAR, it eventually re-
   directs all packets destined for the OAR towards the NAR.  Meanwhile,
   packets have been tunnelled towards the NAR since the Break event.
   Packet flow for the ongoing call in the example is redirected in Fig.
   6d after the UDU hits the call's crossover router, and the tunnel
   comes down when the UDU hits the OAR.  We also omit the UDUA phase
   due to space limitations. The numbers below each router in the figure
   represent that router's height, and show that the set of heights
   become negative  (i.e. lower) as handover progresses.  See [FMCTR]
   for more details.

   As the mobile migrates, a similar sequence will be repeated at each
   hand-over, with the mobile's height getting progressively lower.
   Hopefully the reader will  be able to construct similar message
   diagrams for the other cases involvin g unanticipated BBM,
   anticipated MBB and unanticipated MBB from what we have presented
   (see [FMCTR] for more details).  These hand-over forms may occur as
   the mobile moves between different types of layer 2 technologies
   (e.g. GSM to Bluetooth hand-over) generating different hand-over
   event sequences.

   Recall, it will also be necessary to re-allocate the IP address back
   to the AAR after a sequence of hand-overs.  This is accomplished via
   a sequence of messages very similar to the hand-over processing (only



O'Neill, Corson, Tsirtsis                                      [Page 15]


Internet Draft                     EMA                        March 2000


   in reverse) where the IP address is handed back to the AAR and all
   host-specific state is erased from the network which we cannot show
   due to space limitations.


4. Scalability

   TORA was originally conceived as a MANET routing algorithm where it
   is intended for use in large-scale, dynamic, bandwidth-constrained
   MANETs.  The principle objective behind its design is the achievement
   of "flat scalability", i.e.  achieving a high degree of scalability
   (measured as the number of routers in a domain) with a "flat", non-
   hierarchical routing algorithm. In its operation the algorithm
   attempts to suppress, to the greatest extent possible, the generation
   of far-reaching control message propagation.

   With TORA, such suppression may or may not be feasible depending on
   the topology. As we will see subsequently, a key to achieving highly-
   scaled EMA routing with TORA turns out to be an issue of "topology
   control". Under appropriate topological conditions, TORA's reaction
   to link additions and failures can be highly localised, with smooth
   delocalisation as we move to more adverse topologies.  This is a key
   property which we exploit based on the realisation that, viewed
   abstractly, the "make" and "break" operations in cellular networks
   correspond to link "additions" and "failures", respectively, in a
   unified mobile host/fixed router network. The subsequent lack of
   large amounts of far-reaching control message propagation--a feature
   common to shortest-path algorithms--afford TORA its relatively quick
   convergence and consequent stability.

   These properties appear desirable for the design of large-scale
   routed domains without any consideration for mobility support.  In
   the most recent Internet Architecture Board (IAB) report on network
   layer issues [IAB99], the IAB concluded that the scalability
   bottleneck of presently deployed routing technology stems not from
   storage considerations but rather from long convergence times.  These
   convergence delays are due to the time required to distribute stable
   routing information updates (communication complexity) and the time
   required to re-compute routing tables (computational complexity).
   Operating in a suitable topology, TORA can have relatively low
   communication and computational complexity due to the nature of its
   distributed computation that forgoes shortest path computation.

   TORA also supports loop-free, multipath routing realised as a
   consequence of the usage of temporally, totally-ordered "heights".
   The provision of multipath routing makes the protocol amenable for
   load sharing and traffic engineering.  The algorithm also has the
   potential to support fast restore via its link reversal mechanism



O'Neill, Corson, Tsirtsis                                      [Page 16]


Internet Draft                     EMA                        March 2000


   based on the availability of fine-grained link status sensing,
   possibly from layer 2 mechanisms or from layer 3 mechanisms such as
   [FLIP].

4.1 Performance

   Operating as an EMA-MER protocol, initial simulation results indicate
   that TORA may be well-suited for use in hierarchical mesh topologies
   [FMCTR]. Hierarchical mesh topologies have a limited number fully-
   meshed core routers, a greater number of intermediate routers (each
   dual-homed to two core routers), an even greater number of edge
   routers (each dual-homed to two intermediate routers) and  a large
   number of access routers (each single-homed to an edge router).  Such
   topologies have characteristics of both mesh and tree networks, which
   vary as a function of the hierarchical fan-out (the greater number of
   routers at each lower level) and the amount of multi-homing between
   levels.

   Proper topology design for TORA involves a balance between tree-like
   and mesh- like characteristics.  The more tree-like the network, the
   better the routing efficiency of TORA relative to a shortest path
   routing algorithm due to the reduction in the number of potential
   preferred paths between ARs because of the route aggregation effects
   of hierarchical topologies.  Simulation results obtained thus far
   indicate that routing efficiency deviates no more than 5% from
   optimal (i.e. shortest path) [FMCTR]. However, the more mesh-like the
   network, the greater the degree of control message localisation that
   can be obtained during handover.  The objective of the localised
   hand-over model is to keep host-specific state out of the core and as
   far towards the network edge as possible.  Simulation results
   indicate that with GSM call and mobility statistics for a domain with
   1600 ARs, the mesh-like character achieved with dual-homing keeps
   host-specific state completely out of the core routers, distributing
   it to routers lower in the hierarchy [FMCTR].

   The potential scalability of the proposed TORA EMA-MER approach is
   indirectly indicated by a comparison of simulation times for
   alternative approaches.  Results for TORA EMA-MER operating over a
   domain with 1760 routers took little more than a day to simulate.
   However, to compare against an approach using a shortest-path
   computation (imagine a mobile overlay approach atop OSPF in a domain
   this large), it is estimated from observed simulation progress that
   it would have taken the same computer approximately 84 days to simply
   compute the dijkstra computations (one per router) to initialize the
   simulation.  The TORA approach forgoes support for shortest-path
   routing and sacrifices an amount of routing efficiency to achieve
   highly-scaled operation in large domains.




O'Neill, Corson, Tsirtsis                                      [Page 17]


Internet Draft                     EMA                        March 2000



5. Comparison to Alternatives

5.1 Mobile IP

   Mobile IP [MobileIP] is a well known technique for supporting edge
   mobility through the use of stateful intelligence and the permanent
   use of tunnels. Mobile IP is used in our proposal as the only
   credible means to support hand-over between Autonomous Systems whilst
   trying to preserve the current IP interface address and dependent IP
   sessions. It is also required to support subsequent roaming within a
   non-MER domain through re-registration. Mobile IP effectively takes
   the position that IP routing should not inherently try to support IP
   interface movement due to the implications on the scaling of the
   intra-domain routing. It is therefore deemed better to add
   functionality to hide the interface movement from the routing
   protocol(s). The authors of this draft fully concur with this
   position for traditional routing protocols such as OSPF, where the
   consequence of mobility in any reasonable domain is clearly
   disastrous for routing state and message overhead.  However, we
   believe other routing approaches can achieve sufficient scaling to be
   commercially useful, and the case for Mobile IP against a routing
   solution becomes a more detailed comparison of interactions with
   other IP / cellular protocol features, system reliability, system
   overhead, time to market and ultimately cost etc. We believe that
   with suitable routing technology, the Mobile IP solution will in many
   cases be inappropriate, and we would encourage others to work on such
   technology, in competition to our detailed proposals that will be
   published when finished.

5.2 Cellular IP

   Cellular IP [CellularIP] is an existing proposal which to some extent
   fits aspects of this architecture, in particular in that it uses
   Mobile IP inter-domain and advocates use of a constant in-session
   address. It provides for hand-over-based redirection and soft state-
   based maintenance of host-specific routing and paging entries.  These
   entries point to a central domain router, and the redirections modify
   a set of default routes collectively forming a tree.

5.3 HAWAII

   HAWAII [HAWAII] is another proposal similar to Cellular IP.  It also
   advocates the use of a constant in-session address and Mobile IP
   inter-domain.  It also provides for hand-over-based redirection of
   host-specific routing paths rooted at a central core router, although
   its hand-over and paging mechanisms are more complex than those of
   Cellular IP.



O'Neill, Corson, Tsirtsis                                      [Page 18]


Internet Draft                     EMA                        March 2000



   Cellular IP and HAWAII differ from the proposed architecture in their
   use of a central routing tree.  In EMA-MER approach, host routes
   modify a traditional, prefix-routed mesh topology and form route sets
   other than trees leading to reduced configuration, greater
   resilience, shorter data path lengths and topological design freedom.
   In addition, these approaches appear not to make provision for the
   temporary tuneling of packets in flight whilst redirect routing
   converges, which can lead to data packet loss depending on topology,
   convergence time, link speeds, control packet loss recovery times and
   traffic load.

   More fundamentally, EMA-MER requires a full routing algorithm,
   employing hard state for both host-specific and prefix-based
   forwarding entries, rather than a soft-state overlay technique for
   mobile hosts independent of the underlying fixed routing.  Trust is
   placed in the host-specific entries, and periodic soft-state
   reconfirmation is not utilized. The proposed system is designed to
   scale.  Central to this design objective is the limitation of network
   control signaling, with the understanding that control message
   processing is a principal bottleneck to system scalability. Frequent
   route verification may potentially overload routers in the domain
   sizes we envision which further supports our design decisions.


6. Security

   This draft is too general to explicitly address security issues.
   Certainly host and router authentication must be handled in the
   architecture, and various mechanisms already exist for these
   purposes.  For example, host authentication during dynamic address
   assignment is possible via [RADIUS].  Router authentication could be
   handled via shared key exchange as is common in many routing
   algorithms.  Additionally, mechanisms would be required for
   authenticating Mobile IP messages and the discussion of possible
   approaches in [HAWAII] applies here as well.  Additionally, source
   address checking would be necessary.


7. References

   [CellularIP] A. Valko, ``Cellular IP: A New Approach to Internet Host
   Mobility," ACM Computer Communication Review, Vol. 29, No. 1, January
   1999.

   [CellularIPdraft] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi and A.
   Valko, "Cellular IP", Internet-Draft (work in progress), draft-valko-
   cellularip-01.txt, October 1999.



O'Neill, Corson, Tsirtsis                                      [Page 19]


Internet Draft                     EMA                        March 2000



   [FLIP] H.Sandick et al., "Fast LIveness Protocol (FLIP)", Internet-
   Draft (work in progress), February 2000.

   [FMCTR] M. S. Corson, A. O'Neill, "An Approach to Fixed/Mobile
   Converged Routing", University of Maryland, Institute for Systems
   Research Technical Report, TR-2000-5, March 2000,
   http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml

   [HAWAII] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.
   Salgarelli, ``IP micro-mobility support using HAWAII," Internet
   Draft, Work in Progress, June 1999.

   [HAWAIIdraft] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.
   Salgarelli, ``IP micro-mobility support using HAWAII," Internet-Draft
   (work in progress), draft-ietf-mobileip-hawaii-00.txt, June 1999.

   [IAB99] M. Kaat, "Overview of 1999 IAB Network Layer Workshop",
   Internet-Draft, draft-ietf-iab-ntwlyrws-over-01.txt, Oct. 1999.

   [MIPAAA] S. Glass et. all, "Mobile IP Authentication, Authorization,
   and Accounting Requirements", <draft-ietf-mobileip-aaa-reqs-01.txt>,
   work in progress, January 2000.

   [MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002,
   Oct 1996.

   [RADIUS] C. Rigney, A. Rubens, W. Simpson and S. Willens, ``Remote
   Authentication Dial in User Service (RADIUS),'' Request for Comments
   2138, Apr 1997.

   [TORA] V. Park, M. S. Corson, "The Temporally-Ordered Routing
   Algorithm", Proc. IEEE INFOCOM '97, Kobe, Japan, April 1997.

   [TORAdraft] V. Park, M. S. Corson, "Temporally-Ordered Routing
   Algorithm (TORA) Version 1 Functional Specification", Internet-Draft
   (work in progress), draft-ietf-manet-tora-spec-02.txt, October 1999.

   [TORAthesis] V. Park, "A Highly Adaptive Distributed Routing
   Algorithm for Mobile Wireless Networks", Masters Thesis, University
   of Maryland, College Park, Maryland, 1997.


Appendix A -- IPR Statement

   British Telecommunications plc has patent applications relevant to
   the architecture mentioned in this draft and to modifications of
   routing protocols. The modifications seek to achieve the scaling and



O'Neill, Corson, Tsirtsis                                      [Page 20]


Internet Draft                     EMA                        March 2000


   performance objectives required for commercial cellular IP systems.

   British Telecommunications plc is currently considering giving an
   undertaking to the IETF to grant licences under the patents resulting
   from the patent applications on fair and reasonable terms so that
   vendors can develop systems based on IETF specifications for
   commercial deployment in a timely and cost-effective manner.

   British Telecommunications plc would also encourage the IETF to seek
   similar undertakings from others re licensing of their patents which
   could otherwise hamper the development and deployment of the IETF
   specifications related to this technology.

Author's Addresses

   Alan O'Neill
   BT
   (+44) 1473-646459
   alan.w.oneill@bt.com

   M. Scott Corson
   University of Maryland
   Ansible Systems
   (+1) 301-405-6630
   corson@isr.umd.edu

   George Tsirtsis
   BT
   (+44) 020 8820073
   george.tsirtsis@bt.com





















O'Neill, Corson, Tsirtsis                                      [Page 21]

Internet Draft                     EMA                        March 2000


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