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 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) | @ @ | <<<<<<<< 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", , 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