Personal A. O'Neill G. Tsirtsis BT Internet Draft S. Corson Document: draft-oneill-ema-02.txt Ansible Systems Category: Informational July 2000 Edge Mobility Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft outlines a system for domain-based routing and addressing support in handling edge mobility such as encountered in cellular systems and Internet roaming. The system includes novel features for IP session, address and localised host redirect route management which promise significant scaling benefits compared to other micro-mobility solutions. In addition, the system is closely integrated with the Mobile IP architecture for both signalling and data forwarding, so that a rich set of capabilities and Internet Services are possible, and incremental deployment of EMA is possible within and between AS's. The draft also suggests a specific protocol based on TORA for the implementation of such an architecture. It advocates the creation of a specific IETF working group to address an overall architecture for edge mobility routing, specific extensions to existing routing protocols to accomplish that architecture, and extensions to existing Internet technologies such as Mobile IP to support this architecture. O'Neill, Corson, Tsirtsis 1 Internet Draft EMA July 2000 INDEX 1. Introduction 2. Mobile Routing Architecture 2.1 Mobile Session Start-Up. . . . . . . . . . . . . . . . . 2.2 IP Session Dynamics. . . . . . . . . . . . . . . . . . . 2.3 Mobile Node States . . . . . . . . . . . . . . . . . . . 2.3.1 EMA Active . . . . . . . . . . . . . . . . . . . . 2.3.2 EMA Hot Standby. . . . . . . . . . . . . . . . . . 2.3.3 EMA Cold Standby . . . . . . . . . . . . . . . . . 2.3.4 EMA off . . . . . . . . . . . . . . . . . . . . . 2.4 EMA Intra-domain Hand-over Messaging . . . . . . . . . . 2.5 Break Before Make - BBM. . . . . . . . . . . . . . . . . 2.6 Make Before Break - MBB. . . . . . . . . . . . . . . . . 2.7 Hybrid Model . . . . . . . . . . . . . . . . . . . . . . 2.8 Mobile IP Session Completion . . . . . . . . . . . . . . 2.9 EMA Inter-domain considerations. . . . . . . . . . . . . 3. TORA-based Mobile Enhanced Routing (MER) 3.1 TORA Concepts. . . . . . . . . . . . . . . . . . . . . . 3.2 TORA Hand-over Processing. . . . . . . . . . . . . . . . 4. EMA and Mobile IP Convergence 4.1 EMA / MIP Architectural Considerations . . . . . . . . . 4.2 Converged EMA / Mobile IP Addressing . . . . . . . . . . 5. Scalability Characteristics of EMA:TORA 5.1 Temporary Session IP addresses . . . . . . . . . . . . . 5.2 Aggregate Prefix Routes. . . . . . . . . . . . . . . . . 5.3 Localised Host Redirect Routes . . . . . . . . . . . . . 5.4 In-session Dynamics. . . . . . . . . . . . . . . . . . . 5.5 TORA MER . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Performance. . . . . . . . . . . . . . . . . . . . . . . 6. Comparison to Alternatives 6.1 Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . 6.2 Cellular IP. . . . . . . . . . . . . . . . . . . . . . . 6.3 HAWAII . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 OBAST. . . . . . . . . . . . . . . . . . . . . . . . . . 7. Security Considerations 7.1 Authenticating users within a domain. . . . . . . . . . 8. References O'Neill, Corson, Tsirtsis 2 Internet Draft EMA July 2000 1. Introduction Telecommunications networks are rapidly transitioning towards an all-IP architecture. This trend is not restricted to fixed networks. Second generation cellular networks have been modified to provide limited data services, and third generation systems undergoing rollout now have been designed to deliver IP connectivity to the end user. These system continue to support mobility based on the continuing advancements in wireless technology. However, with IP routing technology being pushed out to the network's edge, it becomes less cost effective to support the various modes of layer 2 edge mobility management that accompany today's cellular and PCS technologies. Rather, unified solutions become advantageous to domain operators, wherein mobility management becomes an integral component of an IP layer routing protocol and associated hand-over mechanisms. Internet routing protocols have been traditionally designed from an assumption that the location of an IP interface in the topology is static. In addition, they assume that address allocation within the topology will aim to provide multiple levels of IP address aggregation such that routing protocols can deal with address prefixes, rather than large numbers of host routes. Within this framework, traditional intra-domain protocols, such as OSPF, need only react to infrequent changes to the network due to link or outer failures or permanent modifications to the addressing scheme or the topology. Mobile Ad hoc NETwork (MANET) routing protocols have been developed to address what could be considered to be an extreme scenario, whereby the mobile nodes have permanent IP addresses which can rapidly roam through an ad hoc topology, leading to the need for alternative routing technology and the general loss of aggregation opportunities. A third family of routing protocols is now under investigation for the case in which the core topology is essentially fixed but the end systems are mobile. This is the classical edge mobility scenario that is today supported by cellular networks, primarily as part of the cellular technology elements (GSM, GPRS etc). Migrating this routing function to the layer 3 IP routing protocol, to release all the end-to-end internetworking benefits which has aided the deployment of the Internet, would tend to suggest a fusion of the MANET and traditional routing protocol architectures. The primary aim is to move the IP interface location in the routing topology as the mobile changes base stations so that active IP sessions are maintained. We refer to this form of routing as Mobile Enhanced Routing(MER), its intra-domain deployment providing Edge Mobility support within that domain. This is clearly only one of the possible models and this draft does not make any judgments as to the pro's and con's of this particular mobility model, but is simply using it as a precursor for the discussion of the related hand-over architecture. O'Neill, Corson, Tsirtsis 3 Internet Draft EMA July 2000 External BGP Peerings To the Internet | * | | * | Allocating | * | Roaming Domain _|_ * _|_ Domain Border-->| |---------------------------| |<--Border Router |HBR| * |FBR| Router |___| * |___| MER | * | MER or Protocol _|_ * _|_ OSPF etc) | | * | | ,--|HIR|--, * ,--|FIR|--, | |___| | * | |___| | _|_ _|_ * _|_ _|_ | | | | * | | | | |HAR| |HAR| * |FAR| |FAR| |___|<--->|___|<------*------> |___|<--->|___| * Movement Movement Movement intra-domain inter-domain intra-domain Figure 1: Edge Mobility Domains as part of the Internet These edge mobility domains as shown in figure 1, can be considered to have a single IP routing protocol which runs between routers in the EMA domain, with some of those routers being the edge access routers (ARs) equipped with, or connected to a (potential) diversity of radio base station technologies such as CDMA, TDMA and Radio LANs etc. The radio layers are assumed to provide the well known layer 2 hand-over models and other capabilities including break-before-make, make-before-break, power measurement, mobile assisted hand-over, paging and security features. To facilitate internetworking, inter- access router co-ordination is assumed to use IP-based communication using messages which are abstractions of the messages which are today carried in cellular technology-specific messages, often via central processing elements. This draft proposes a general approach to the support of this edge mobility function, with the aim of being generic enough to support a range of different routing protocols, as well as enabling hand-over between diverse types of cellular technology through capability exchange between radio-equipped access routers. It does not deal with the details of these mechanisms as they are specific to the type of routing protocol selected. This draft does also not discuss the effects of the architecture on DNS, DHCP and infrastructure services, nor does it contribute to the debate on the appropriate layer and model for mobile terminal paging. O'Neill, Corson, Tsirtsis 4 Internet Draft EMA July 2000 In section 2, we describe an Edge Mobility Architecture (EMA) for the support of edge mobility, with the aim of being general enough to support a range of different routing protocols, as well as enabling hand-over between diverse types of cellular technology through capability exchange between radio-equipped ARs In section 3 we provide a description of one proposed approach for Mobile Enhanced Routing, and compare it with alternative proposals for IP mobility support in section 6. In section 4 we overview the convergence of EMA with Mobile IP resulting in mutual benefits. In section 5 we look at the scalability of our solution and performance based on simulations that have been implemented. Finally, in section 7 we outline the emerging security solution for user authentication. It will become clear that the routing approach put forth here needs to be coupled with a companion paging architecture for location management, the details of which are not covered in this draft, but is nearing completion. 2. Mobile Routing Architecture The architecture proposed assumes that modifications to either MANET or traditional routing protocols are possible which will enable these protocols to comply with this architecture and hence facilitate a message set and control model which has a degree of protocol independence. Clearly, the actual detailed mechanisms, message content/timing and performance are going to be dependent on the type of intra-domain routing protocol that forms the basis for the mobility extensions. The architecture has six main components, these being the use of; a) the provision of a modified intra-domain routing protocol which provides prefix-based routing within a domain, with each prefix representing a block of IP addresses allocated to each access router (AR) in the domain, as well as host routes to support mobile terminal migration away from the allocating (IP address)access router, b) the provision and use of a virtual link for routing exchange and messaging between cooperating access routers to exchange capabilities, and to effectively and locally manage the hand-over of the responsibility for, and routing of, the mobile terminal and its associated IP address, c) the provision and use of a temporary tunnel to redirect packets in flight between the old access router and the new access router whilst routing converges, and d) the ability to inject a host route for the mobile, e) a method to return the allocated IP address to the allocating access router on mobile session termination at a different base station in the same domain. O'Neill, Corson, Tsirtsis 5 Internet Draft EMA July 2000 f) the use of mobile IP across provider boundaries to facilitate the temporary movement of an IP address (on a mobile terminal interface) away from its home domain whilst maintaining active sessions. The mobile IP tunnel is located on an access router in the old domain (HA), across the inter-domain boundary to the access router in the new domain (FA). In the foreign domain, the tunnel is extended to further access routers in the foreign domain using normal Mobile IP foreign agent mechanisms. The details are covered in section 2.9 and in [EMA-MIP] The reasons for each of these components will be explained in the following sections that will also give examples for CDMA (make- before- break) and TDMA (break-before-make) hand-over. 2.1 Mobile Session Start-Up When the mobile host (MH) either has data to send or has been paged due to incoming traffic, the MN connects to the nearest AR and is brought into the IP routing domain by requesting and being allocated an IP address out of the block of addresses managed by that access router. This Allocating Access Router (AAR) will be advertising the IP address prefix associated with that address block into the intra- domain routing protocol such that 'at home' mobiles have a proactively and permanently advertised route, and are immediately reachable to all hosts in the internet. Note that end hosts statically attached to the EMA domain via Network Access Servers can be viewed as "at home" mobiles who never move. As the MH moves access routers, this IP address moves with them so that higher-layer sessions are unaffected. This is accomplished by modifying the intra-domain routing using hosts routes (longest mach) to overrule or overwrite the underlying proactive prefix routing to the AAR. Specifically, as the MN wanders away from the AAR, a host redirect route is locally injected, during hand-off, between geographically adjacent ARs. This ensures that any traffic on the aggregated AAR route is 'peeled-off' and redirected to the new AR. Subsequent movement results in additional host redirect routes that progressively 'peel' the incoming traffic away from both the prefix route for the AAR, and the previous host redirect route. Hence, the further we wander at the edge, the further that the sequence of host redirect routes will extend the redirection away from the aggregated AAR prefix route (and associated AR). Placing an appropriate set of messages over IP ensures that a wide range of radio technology specific hand-over models can be accommodated within a single IP model to allow for internetworking of IP over those diverse technologies. O'Neill, Corson, Tsirtsis 6 Internet Draft EMA July 2000 2.2 IP Session Dynamics When the mobile is inactive for short periods during an IP session, the radio layer has mechanisms and timers which enable the radio resources to be released to other users. An IP session timer is used in the AR and MN to identify sufficient inactivity (which could be application, terminal, user or service class (tariff) specific) to terminate the dynamic IP session, so releasing the associated radio resources, temporary host address and associated routing state. This enables high multiplexing of the temporary IP address space, and better utilisation of routing and radio system resources. For mobile users wishing to be able to maintain the temporary IP address for long periods for application, business, usage pattern reasons etc, the IP session timer can be set very long (with potential tariff implications). This could result in long term host specific IP routing state in the system which is clearly undesirable as a general mass-market service. This is therefore clearly a per user policy decision as to the appropriate value for this timer, but a large default value can also act as a safety mechanism. 2.3 Mobile Node States We summarise below the IP view of the state of a mobile in EMA which may be mapped to existing cellular states. We use our own terminology here due to confusion in naming between the various global standards in existence, and because we wish to focus on the various inactivity timers whose lengths are related to the users profile/privileges, and whose expiry move the mobile between specific states. 2.3.1 EMA Active The mobile is presently sending and receiving IP data traffic. The MN has a local IP address and has a route pointing to it throughout the EMA domain. The radio layer (L2) and IP layer (L3) are obviously UP and movement between Access Routers generates an EMA IP hand- over. 2.3.2 EMA Hot Standby The MN moves to Hot Standby when it's L2 inactivity timer (not sending / receiving IP data) expires. This takes the L2 DOWN temporarily whilst the L3 is still UP, which releases the radio layer resources to other users. The MN therefore maintains the current IP address, has an EMA route for that address in the EMA domain, and movement between Access Routers generates an EMA IP hand-over. This feature further improves the utilisation of the radio-layer by decouping the IP address and layer 3 resources from the L2 radio resources. O'Neill, Corson, Tsirtsis 7 Internet Draft EMA July 2000 2.3.3 EMA Cold Standby On expiry of the IP address inactivity timer, the address is returned to the AAR and any EMA host redirect state is flushed. The MN now optionally only has it's home address from it's home link. The L2 is DOWN and movement generates location updates only to the global paging system because the MN now has no AAR and local fast route set-up is not required. This feature is designed to avoid hoarding of IP addresses when the user is inactive, so that the address can be returned to the AAR for another user. 2.3.4 EMA Off The MN is switched off and is neither sending location updates nor is pageable. 2.4 EMA Intra-domain Hand-over Messaging A hand-over can be initiated either by a MN or the network, and can be rooted (i.e. initiated) at either the old or new Access Router. The Old Access Router (OAR) is used to co-ordinate a forward hand- over when the New Access Router (NAR) is known in advance as a result of either network or MN-based movement prediction and associated performance measurements. The NAR is used to co-ordinate a reverse hand-over when the NAR is not known in advance by the MN or the network, as a result of either network failure (e.g. old radio link lost), insufficient network intelligence (no inter- technology hand-over signalling) or unpredictable user behaviour (swapping PCMCIA cards). Specifically, in certain wireless technologies (e.g. GSM), hand-overs can be predicted based on signal-to-interference measurements at nearby ARs (radio interface in router) or attached downstream base stations (remote BS's). After the appropriate hand-over criteria are reached, a hand-over procedure can be initiated from an Old Access Router (OAR) to a New Access Router (NAR) in response to a known topological change. In other instances, e.g. with technologies not supporting hand-over prediction, the unanticipated loss of a link should not be immediately interpreted at the OAR as an undesirable link failure. Instead, the OAR should wait for a time to see if the MH reappears, connected either to itself or to a NAR. If it appears at a NAR, the OAR again treats this as a known topological change and reacts accordingly. If it does not appear, the OAR eventually declares link failure and reacts accordingly. The generalised message set of EMA described below and shown in Figure 2, may be mapped to a range of AAA protocols/models, cellular signaling and routing technology etc. to enable a specific solution to be designed. The aim of the description is to capture the essence of the model in terms of responsibilities and timings for IP hand-over. O'Neill, Corson, Tsirtsis 8 Internet Draft EMA July 2000 |>>>>>>>>>>>>>>> 5.RUA >>>>>>>>>>>>>>>| | |<<<<<<<<<<<<< 4.RU <<<<<<<<<<<<<| | | | | | |_| |_| | | -----------> 3.HI/D --------> | | |OAR| <----------- 2.HR <---------- |NAR| |___| -----------> 1.TIN ---------> |___| Figure 2: Basic EMA Hand-over Messaging If MH movement is predicted, then the OAR may be informed by the MH (if mobile assisted operation is implemented) with a Host Tunnel INitiation (H-TIN) packet or via a layer 2 signal. This causes the OAR to build a temporary, soft-state tunnel towards the NAR and to send a Tunnel INitiation (TIN) packet to the NAR. This message may give the NAR advance warning of hand-over. The tunnel can serve to help avoid packet loss during any link dead-time. This sequence of events and the tunnel's construction are optional. What is not optional is the construction of a virtual link at the OAR. If hand- over is predicted, this virtual link is accompanied by a tunnel and is terminated at the NAR. If hand-over is not predicted and the link to the MH is suddenly lost, a virtual link to the MH itself is retained for some time while the OAR awaits notification of the MH's location. Otherwise, the EMA hand-over model has its focus at the NAR and all mandatory messaging begins there. On arrival at the NAR, the MH (operating in mobile-assist mode) brings up a new link for IP purposes (i.e. Make) to the NAR. This triggers the NAR to send a Hand-over Request (HR) message to the OAR which can contain MH credentials and privileges. The OAR responds with either a Hand- over Initiation (HI) (i.e. AAA information and associated state) packet if hand-over is permitted, or else with a Hand-over Denial (HD) packet. The HR packet is repeatedly sent until either a HI or HD is received, or it is determined that the OAR is unreachable. If hand- over is permitted, the HI packet begins a three-way handshake to transfer control of the mobile to the NAR. On receipt of the HI, the NAR initiates routing redirection by sending a Routing Update (RU) towards the OAR. This is sent reliably hop-by-hop towards the OAR, and may be resent multiple times until a RU Acknowledgement (RUA) is received at the NAR or the OAR is determined to be unreachable. This message exchange remains the same for both BBM and MBB hand-over, whether or not the hand-over can be predicted. O'Neill, Corson, Tsirtsis 9 Internet Draft EMA July 2000 2.5 Break Before Make - BBM TDMA technology such as GSM only allows the mobile to be connected to a single access router at a time, with a data path dead-time incurred during hand-over. To minimise the potential for packet loss while maintaining efficient routing, the inject/poison route features are delayed and invoked only after the Make event occurs at the NAR thereby ensuring that the link to the OAR is used until the break occurs. When the mobile disconnects at the radio layer from the old AR (Break), the new AR, through the inter-AR virtual link or tunnel (if present), is immediately known to be the next best hop, and packets hitting the old AR are immediately redirected down the tunnel to the new AR. If a tunnel is not present (unanticipated break), then packets may be cached at the OAR in anticipation of a hand-over, or simply dropped. Some time later the mobile will attach to the new AR (Make) and, if the tunnel is in place, will immediately receive in-flight and locally cached packets. Once the Make event occurs, the new AR informs the old AR of the need to commence hand-over. The two ARs now collaborate to locally inject the new route into the routing domain and poison the old route. Packets to the mobile will then head towards the new AR route. This route redirect process will typically converge during the data path dead-time ensuring that only a small number of packets (if any) will need to be tunnelled from old to new AR. Once routing has converged, the old AR will eliminate the redirect state associated with the temporary tunnel. The reception of the mobile at the new AR is then confirmed through acknowledgement messages to the old AR which is used to confirm hand-over of responsibility for the mobile and it's IP address in the system. The following steps outline the break-before-make (BBM) procedure of EMA, which is also shown in figure 3: 1) Detect imminent hand-over and inform new and old ARs (optional). 2) Build a temporary tunnel from old AR to new AR (optional). (Break event occurs) 3) Await Make event at new AR. 4) On Make event, inject new route to the new AR. 5) Tear down tunnel at old AR (if present). O'Neill, Corson, Tsirtsis 10 Internet Draft EMA July 2000 OAR NAR OAR======NAR OAR======NAR | | | | | | | | | | MH-> MH-> MH-> a)Before Handover b)sensing new link c) Tunnel Data build tunnel on break ^ | OAR======NAR OAR NAR | | | | MH-> MH-> d)Inject new routing e)Routing converges on make, forward tear down tunnel cached data (if any) Figure 3: Basic EMA BBM Hand-over (with temporary tunnel) The first two steps are optional because it is not always possible to predict a hand-over in advance. An unanticipated link failure may occur between the old AR and the mobile host prior to its arrival at the new AR. The "inject/poison" route features of EMA can be invoked only after the old and new ARs have been identified, and have agreed to the hand-over by creating the dynamic, temporary redirect tunnel between them. Note that for efficiency purposes a single redirect tunnel could be pre-configured between adjacent access routers to support all inter-access router hand-overs, and dynamic mobile-specific redirect tunnel state temporarily installed against that aggregate tunnel. 2.6 Make Before Break - MBB CDMA technology enables a mobile terminal to be connected to two base stations at the same time and to undertake measurements to establish the preferred channel and hand-over time. This hand-over time determines the timing of the Make event. As with TDMA, it is desirable to wait until the Make event occurs before injecting the new host route. However, unlike TDMA, packets continue to arrive at the mobile via the link to the old AR prior to the Make event. Thus, the temporary tunnel is typically not needed in CDMA, but it is constructed in case an unexpected early break occurs with the added benefit that in so doing the same hand-over state machine can be used for both BBM and MBB modes. The following steps outline the make-before-break (MBB) procedure of EMA which is also shown in figure 4: O'Neill, Corson, Tsirtsis 11 Internet Draft EMA July 2000 1) Detect imminent hand-over and inform new and old ARs (optional). 2) Build a temporary tunnel from old AR to new AR (optional). 3) Await Make event. (Make event occurs) 4) On Make event, inject new route to the new AR. (Break event occurs) 5) Tear down tunnel at old AR (if present) and remove state of poisoned route. ^ | OAR NAR OAR=====NAR OAR=====NAR | | | | | | | | | | MH-> MH-> MH-> a)Before Handover b)sensing new link c)Inject new routing build tunnel on make OAR=====NAR OAR NAR | | | | | | MH-> MH-> d)Routing converges e)Break occurs tear down tunnel Figure 4: Basic EMA MBB Hand-over (with temporary tunnel) We are not directly addressing IP layer support for CDMA soft hand- over. While feasible in terms of IP layer routing and copying, this mode of CDMA-based hand-over requires highly synchronised packet delivery over the air interface(s) to the mobile which may not be compatible with a heterogeneous IP network infrastructure. Soft hand-over can still be achieved however if the underlying layer 2 (ATM AAL) has the required timing and cell duplication functionality as presently proposed in 3G systems. This is achieved for example by the IP layer at the OAR handing responsibility for soft hand-over to the ATM layer which duplicates and times cell delivery to the multiple neighbor NAR(s). 2.7 Hybrid Model When a hybrid node is able to support both TDMA and CDMA (or other combinations of technology) then a consistent set of access router and Mobile IP messages makes hand-over of the concurrent sessions between TDMA and CDMA access routers possible. This is achieved by the access routers understanding each other's capabilities, and holding up and synchronising the inject stages as appropriate. O'Neill, Corson, Tsirtsis 12 Internet Draft EMA July 2000 2.8 Mobile IP Session Completion It is clear that the migration of IP addresses away from the allocating access router can lead to address exhaustion and a gradual degradation over time of the usefulness of the proactively advertised access router address block prefix. It is therefore critical that at the moment that the mobile finishes active sessions, at a distant access router, that the IP address is returned to the AAR. This can be modeled as a virtual mobile moving from the distant access router back to the AAR and then locally returning the IP address. This can be accomplished using similar mechanisms which are used to support real inter-access router hand- overs, with the access routers acting as proxies for the virtual mobile. Their aim is to co-ordinate the removal of all host specific routing entries in the domain as a result of previous mobility away from the home access router. 2.9 EMA Inter-domain considerations In both the BBM and MBB case above if the NAR is in a different administrative domain from the OAR, we set-up a Mobile IP (MIP) tunnel between the OAR (playing the role of a Home Agent) and the MN (playing the role of a Foreign Agent). This is independent of whether the destination domain supports an EMA-MER protocol or a traditional routing protocol such as OSPF. In addition, we further allow this temporary tunnel to be replaced by a persistent tunnel back to the AAR when leaving an EMA-enabled domain so that the host route between the AART and OAR in that domain can be removed. The AAR then becomes the HA for the CCoA from the EMA domain which is then termed a Co-located Roaming Care of Address. In either case, the end of the MIP tunnel in the new domain is the MN (rather than the NAR) which means that if the mobile continues moving in the new domain, and the domain does not support EMA-MER, then this end of the MIP tunnel needs to move with it. This requires re-registration of the mobile to its Home Agent (OAR/AAR) at every hop leading to lower hand-over performance without Mobile IP fast- hand-over extensions. However, we favor this approach because it keeps the mobile simple and reasonably aware of intra/inter-domain changes. This does however potentially lead to tunneling over the expensive air interface but this is assumed to be necessary in the majority of cases for MIPv4, MIPv6 anyway and so appropriate Header compression solutions will be developed. The NAR is involved with the MN in the MIP/EMA signalling plane which strikes the best balance in the overall flexibility and control of hand-over, supporting both MN assisted and network assisted models. This also allows the mobile to potentially run Mobile IP, using a Co-located Care of Address, back to a third HA (in say the corporate LAN) for its own orthogonal purposes. O'Neill, Corson, Tsirtsis 13 Internet Draft EMA July 2000 If the new domain also supports MER then a hybrid mode of Mobile IP and EMA-MER becomes possible which avoids Mobile IP re-registration at each new AR within that new EMR domain. [MobileIP] with the extensions described in [MIPAAA] should be used for inter-domain tunnelling so that integrated AAA functionality can be provided for roaming users between domains. 3. TORA-based Mobile Enhanced Routing (MER) The preceding architecture does not specify how an MER algorithm creates or modifies its host and prefix-specific IP forwarding entries, and various approaches are possible. The problem of EMA routing is divided into two sub-problems: inter-AR routing and host- specific routing. The inter-AR routing should be continuously maintained, i.e. proactively, whereas host-specific routing should be maintained only as needed, i.e. on-demand or reactively, for scalability reasons. Inter-AR routing is prefix-based, i.e. each AR advertises a prefix address into the FMC domain covering a block of host addresses that it controls. Each host is allocated an interface address covered by the allocating AR network prefix. While the host is "at home", packets are routed to the host via this network prefix. This is undertaken so that packets can be efficiently routed to both fixed and 'at home' mobile hosts and a virtual, bi-directional link exists between any pair of cooperating ARs for their communication during mobile handover. Host specific routing is required only when the mobile host moves away from its allocating AR. Host-specific state is injected in the network during handover to overrule (via longest prefix match forwarding) a mobile host's 'at home' prefix based route, which redirects packets to that mobile hosts current AR location. With the objective of building a large-scale EMA domain, the Temporally-Ordered Routing Algorithm (TORA) appears potentially well-suited for use as a EMA:MER algorithm [TORA] 3.1 TORA Concepts TORA was originally specified as an on-demand routing algorithm, but this mode of operation is not generally required and a proactive mode has been specified. Because TORA proceeds independently for each destination, it may operate proactively for certain destinations and reactively for others. In the proposed FMC context, separate versions of TORA will proceed proactively for each AR and proceed reactively for each mobile host in an edge mobility- enhanced mode as necessary. TORA operates with respect to "nodes". Each node is assumed to have a unique Node ID (NID). A Node ID (NID) is a polymorphic identifier, and may be either a Router ID (RID) or a Destination ID (DID) depending on the context. In a manner similar to OSPF, TORA uses a O'Neill, Corson, Tsirtsis 14 Internet Draft EMA July 2000 Router ID (RID) to uniquely identify a TORA router separately from its interfaces. A destination identifier in TORA is a destination network prefix, composed of an interface IP address and a network mask. Consequently, the neighbor set Ni that lists a node's neighbors by NID may actually contain two different identifiers. A neighbor may be identified as a router (by its RID) or as a destination (by its network prefix) or frequently as both with multiple entries in the neighbor set table. For the subsequent discussion, we assume each node i is always aware of its neighbors in the set Ni. TORA proactively and/or reactively builds, and then maintains, a Directed Acyclic Graph (DAG) rooted at a destination. For a given destination, each participating node i is assigned a height defined as an ordered quintuple Hi = (ti, oidi, ri, di, i). No two nodes may have the same height (i.e. the set of heights is totally-ordered). Height comparisons are performed lexicographically. Starting with the 'ti' value, comparison tests are for "less than" or "greater than", with equality resulting in the comparison proceeding element- wise towards the final element, the NID i. Information may flow from nodes with higher heights to nodes with lower heights over 'directed' links. Each link is assumed to allow two-way communication (i.e., nodes connected by a link can communicate with each other in either direction). Each initially undirected link may subsequently be assigned one of three states; (1) undirected, (2) directed from node i to node j, or (3) directed from node j to node i. If a link is directed from node i to node j, node i is said to be "upstream" from node j while node j is said to be "downstream" from node i. Conceptually, information can be thought of as a fluid that may only flow downhill over downstream links (see Figure 4). By maintaining a set of totally- ordered heights at all times, it is easy to see how loop-free, multipath routing is assured. Information would have to flow uphill to form a loop, and this is not permitted. Due to the mobility of some nodes, the set of active links in the system is changing with time (i.e., new links can be established and existing links can be severed). Conceptually, the height quintuple associated with each node is combined into two parameters: a reference level, and a delta with respect to the reference level. The reference level is represented by the first three values in the quintuple (a triple), while the delta is represented by the last two values (a double). The first value in the reference level, 'ti', has three meanings. If equal to zero, it indicates that the height value has remained "unchanged" since the DAG was initially constructed or was last optimized (this is the state of all heights in Figure 4). If positive, it is a time tag representing the "time" of a link failure somewhere in the network. If negative, it represents a route "freshness" value (the more negative the fresher the route) generated in response to handover-induced mobility. O'Neill, Corson, Tsirtsis 15 Internet Draft EMA July 2000 Much of TORA's original protocol mechanism deals with reaction to link and node failures. Many of these details are not relevant to the discussion here, and we refer the reader to [TORA, TORAdraft] for this information. Here we focus on the aspects of TORA necessary to understand its operation as a FMC algorithm within the EMA. Under appropriate topological conditions, TORA's reaction to link additions and failures can be highly localized. This is a key property which we exploit based on the realization that, viewed abstractly, the "make" and "break" operations in cellular networks correspond to link "additions" and "failures", respectively, in a unified mobile host/fixed router network. The subsequent lack of large amounts of far-reaching control message propagation-a feature common to shortest-path algorithms-afford TORA its relatively quick convergence and consequent stability. These properties appear desirable for the design of large-scale routed domains without any consideration for mobility support. We can therefore have a separate version of TORA, running on each AR, build and proactively maintain an aggregated DAG for each prefix owned by that AR. The AR aggregated DAGs are then maintained via a combination of the aforementioned proactive mechanism and normal TORA reactive processing, giving us large-scale routing support for both fixed, and 'at home' mobile, hosts. To support the movement of the mobile hosts, through the injection of the host routes, we seek a mechanism that operates in harmony with TORA's notion of height- based routing, and permits a large degree of flexibility and scalability concerning the method and scope of host-specific state injection. The design objective is to localize the scope of handover-induced messaging so as to reduce the processing load on routers as much as possible, while maintaining routing efficiency. Domain scalability is clearly the end goal and the resulting mechanisms are outlined below. 3.2 TORA Handover Processing TORA MER differentiates nodes into two classes: routers and hosts. Routers execute the full MER protocol while hosts execute only a limited state machine that does not involve packet forwarding. Base stations (AR) are routers, and mobile hosts (MH) are handed over between routers. In general, routers may also be mobile (e.g. mobile ad hoc networks), but we will not consider that case here. The Mobile enhanced TORA protocol operates reactively, both in terms of initial route construction and route maintenance in response to unforeseen topological changes. We have already seen how TORA's route construction process can be made proactive. Now, we will show how TORA can respond to known topological changes, whether foreseen or unforeseen but anticipated. O'Neill, Corson, Tsirtsis 16 Internet Draft EMA July 2000 @ @ @@@@@@@@@@ @@@@@@@@@@ @ .------CR-------. @ .------CR-------. @ | (0002) | @ | (0002) | @ | | @ |I>>>>>>>>>>>>>I| @ | | @ |I TIN I| @ | | @ |I v| @ OAR NAR @ OAR=============NAR @(0001) (0003) @(0001) (0003) @ | @ |I @ | @ |I @ | @ |I H-TIN @ | @ |I @ | @ |I @@ MH-> @@ MH-> (0000) (-1000) (a) (b) @ @ @@@@@@@@@@ @@@@@@@@@@@@ @ .------CR-------. .------CR-------. @ @ | (-1002) | | (-1002) | @ @ | <<<<<<<< MH@@ (-1000) (-1000) (c) (d) Figure 6: Anticipated BBM hand-over As mentioned, at any given time the destination has the "lowest" height w.r.t. the remaining TORA DAG. To enable "arbitrary" destination mobility within the DAG (i.e. mobility between "any" two points in the DAG), the destination should also "lower" its height each time it moves and connects to a new point in the DAG. This action preserves the DAG's loop-free, multipath routing property while localising the communication necessary to re-orient the DAG. A special case of such destination mobility is mobile handover in a cellular network. We now illustrate how the TORA height concept operates with the EMA message framework with a "GSM-like" scenario of BBM hand-over shown in Figure 6. O'Neill, Corson, Tsirtsis 17 Internet Draft EMA July 2000 The TORA protocol defines an unicast-directed update (UDU) packet that replaces the RU message of the EMA. Similarly, an unicast- directed update acknowledgement packet (UDUA) replaces the EMA's RUA packet. We can only show a portion of the message exchange due to space constraints. The H-TIN packet initiates tunnel creation and transmission of the TIN packet. The Make event is seen in Figure 6c, which initiates UDU transmission (we skip the HR and HI phases here) to redirect routing via injection of host-specific routing state (shown next to the OAR prefix DAG state). The UDU redirects packet flow at each router it passes (via height "lowering" in the DAG) towards the NAR. Since it is sent to the OAR, it eventually re-directs all packets destined for the OAR towards the NAR. Meanwhile, packets have been tunnelled towards the NAR since the Break event. Packet flow for the ongoing call in the example is redirected in Figure 6d after the UDU hits the call's crossover router, and the tunnel comes down when the UDU hits the OAR. We also omit the UDUA phase due to space limitations. The numbers below each router in the figure represent that router's height, and show that the set of heights become negative (i.e. lower) as handover progresses. See [FMCTR] for more details. As the mobile migrates, a similar sequence will be repeated at each hand-over, with the mobile's height getting progressively lower. Hopefully the reader will be able to construct similar message diagrams for the other cases involving unanticipated BBM, anticipated MBB and unanticipated MBB from what we have presented (see [FMCTR] for more details). These hand-over forms may occur as the mobile moves between different types of layer 2 technologies (e.g. GSM to Bluetooth hand-over) generating different hand-over event sequences. Recall, it will also be necessary to re-allocate the IP address back to the AAR after a sequence of hand-overs. This is accomplished via a sequence of messages very similar to the hand-over processing (only in reverse) where the IP address is handed back to the AAR and all host-specific state is erased from the network which we cannot show due to space limitations. 4. EMA and Mobile IP Convergence - text from [EMA-MIP] draft Mobile IP (MIP) (versions 4 and 6) provides for the potential movement of a Home IP address throughout the Internet, from a home domain subnet, throughout foreign domain subnets equipped with MIP. It does so by providing a Mobile Node (MN) with a local and potentially short term IP Care of Address (CoA) in a foreign domain, towards which packets can be indirectly tunnelled. This CoA is reported back to a Home Agent (HA), who then tunnels packets, sent O'Neill, Corson, Tsirtsis 18 Internet Draft EMA July 2000 by any Correspondent Node (CN) to the Home address, towards this CoA. In addition, direct tunnelled communication, bypassing the HA, can be achieved through additional signalling between the MN and the CN. A Foreign Agent (FA) entity can also optionally exist to assist the MN in the foreign domain by terminating tunnels and acting as a proxy CoA, a CoA allocator and a proxy signalling point for MIP signalling. This section outlines the inter-working architecture for EMA and Mobile IPv6/v4 that provides mutual co-existence and benefits, both for the user and the operator. 4.1 EMA / MIP Architectural Considerations Firstly, the EMA envisages a rich set of hand-over capabilities that encompass a range of existing, predictive (cellular) and non- predictive (inter-technology) hand-over models and requirements. The EMA signalling requirements are a super-set of existing MIP hand- over capabilities as will be described in detail later, which indicates that some additions will be required in MIP if EMA is to solely rely on MIP signalling. Specifically, MIP does not presently support forward hand-over rooted at the OAR, nor does it provide the required information exchange between neighbouring ARs to facilitate such forward hand-over in an all-IP solution. There have however been drafts and discussions suggesting such additions and these are in line with the desire for MIP take a significant role in 3G/4G cellular solutions. Secondly, the MIP architecture assumes a MN is from an arbitrary home domain, and an arbitrary HA within that domain. We therefore cannot make any assumptions in EMA as to whether or not this Home Domain is equipped with a MER protocol. Equally, we know that any visited foreign domain may be either MER or non-MER equipped, and we need to ensure that MIP continues to operate as normal as a MN moves through MER and non-MER domains. The conclusion therefore is that MIP functionality related to the Home Address as a source / destination address, covering CoA registration, HA capabilities and route optimisation/binding features, must be orthogonal to EMA. EMA is instead associated with the CoA, FA/Care of Router (CoR), MN-AR signalling, and the temporary forwarding (between CoA's on hand- over) features of MIP. The specific details change slightly between MIPv6 and MIPv4, and depend on the type of CoA (Co-located or not). Each scenario is broadly described in the following sections. Thirdly, and finally, the types of Internet access supported by MIP and MER functionality are very different and are part of the overall commercial opportunity. MIP facilitates roaming into foreign domains and links, from a Home link within a Home Domain. Associated AAA interfaces are used to control access to the foreign links where necessary, and may also be used to install policy as to how user traffic is forwarded. These forwarding options provide for IP traffic associated with a home session address to go to and from the O'Neill, Corson, Tsirtsis 19 Internet Draft EMA July 2000 Home Domain (forward and reverse HA tunnelling) as in the remote access model. The other options allow for direct tunnelled communication between CN and MN (HA bypass) through optimisation/binding, and in the case of Co-located Care of Addresses (CCoA) based sessions, native communication independent of the home address and MIP tunnelling features (as in local or roaming access). The MIP CCoA is however only a valid session address on a specific foreign link, and the utility of this address for native service is consequently severely limited, and it's use therefore actively discouraged in Mobile IP. Some movement of this CCoA address is, however, supported in MIP through the use of temporary tunnelling between ARs, with the current CCoA at the old AR being treated like a Home Address, and a new CCoA from the new AR acting as the tunnel endpoint. To aid subsequent discussions we describe temporary tunnel forwarding between adjacent ARs as "Horizontal" MIP forwarding, whereas standard indirect tunnel forwarding via the MN's HA in its Home Domain, or direct from a CN using optimisation, is termed "Vertical" MIP forwarding. MER also enables native communication using the CCoA as a normal source (destination) session address, but with significantly increased utility, as a result of the MER ability to update the routing tables in the domain to enable the CCoA to move with the MN. The combination of MIP and MER can therefore support both native and remote access models, along with hybrid combinational models. From the perspective of a foreign ISP, a roaming MN can be offered native service and/or non-optimised/optimised remote access depending on the user's/home operator's privileges in the foreign domain, assuming appropriate AAA support features are developed. In the existing UMTS model, the benefit of the co-existence of these models is clear because the present UMTS network can only support the remote access model from the MN back through SGSN and GGSN to the external 'Home' ISP (today via GTP tunnels). This external ISP provides both the non-routable 'Home' IP address to the MN, and all associated IP services and onward connectivity to the wider Internet. Significant benefits would accrue to both the UMTS network operator and to users if, in addition, the UMTS network could support native IP services using local IP addresses, local IP service infrastructure, and direct connectivity between users on that network and out to the wider Internet. This commercial context provides additional justification for the co-existence of MIP (remote access) and EMA:MER (as an efficient means to support native forwarding) within a future all-IP 3G/4G solution. The details below will illustrate this in more detail. O'Neill, Corson, Tsirtsis 20 Internet Draft EMA July 2000 4.2 Converged EMA / Mobile IP Addressing EMA Access Routers provide a temporary address to the MN in any domain in which it roams, with the address changing on a per IP session basis. This temporary address is allocated by the AAR when the MN has data to send, or when the MN has been paged for incoming traffic. In IPv6 the MN can automatically and rapidly build a temporary address by simply appending it's EUI to the advertised prefixes from it's chosen AAR. This temporary address (and associated service restriction) is similar to the address that is today allocated to the majority of dial-up users. These users do not need permanent IP addresses because they only utilise applications which are initialised through a client server process...(WEB, mail, newsgroups, ICQ etc) in which outgoing traffic informs the servers (and any onward users) of the users IP address. This temporary address is not however sufficient for users with servers who must be able to advertise the server address (e.g. DNS), for corporate roamers who require a valid address from their home network, and for users of peers to peer applications who wish to receive incoming calls. Therefore, in addition to the temporary session address, the MN may also have a persistent IP address allocated via DHCP (or whatever) which is used at the IP layer as a globally unique, stable and hence advertised identifier. This IP address is associated with, and allocated by, the home ISP or corporate, and is associated with the home link of the MN. This address may be installed into DNS and SIP systems for example, and cached by knowledgeable users. When compared to cellular systems, the persistent address is in concept similar to the IMSI, whilst the temporary address is in concept similar to the T-IMSI. The converged Mobile IP / EMA addressing architecture requires that the persistent address is used as the Mobile IP Home address to ensure that the MN may be contacted when roaming using normal Mobile IP mechanisms. The local temporary address is used as the Mobile IP Co-located Care of Address (CCoA) and enables this address to be used for MIP tunnelling as well as for native IP service. The benefits of this co-existence may be summarised as following; Mobile IP is used to provide global roaming of a global address whilst EMA provides routable local addresses. The local address can be used by the mobile node to source traffic from any AR within the EMA domain due to the EMA host redirect routes and IP hand-over. The local address can also act as a sink of traffic from anyone in the Internet who learns the address (MN initiated is easy of course), limited only then by the scope of the address (global, site local, link local, private etc). The MN persistent home address can be used to sink traffic from any Internet host either via Home agent or Correspondent Node tunnelling to the CCoA. The MN persistent home address can be used to source traffic directly to Correspondent Nodes or via reverse tunneling to the Home agent and Home domain. O'Neill, Corson, Tsirtsis 21 Internet Draft EMA July 2000 Further details of the benefits of this co-existence are described in [EMA-MIP] 5. Scalability Characteristics of EMA:TORA This is achieved due a number of novel design decisions which should enable EMA to be supported across large AS's, equivalent to today's OSPF / IS-IS interior routed domains (many thousands of routers). 5.1 Temporary Session Addresses The temporary session address means that a MN always starts any IP session being routable on a prefix route. A host route is only required for subsequent movement away from this first access router whilst in-session. When the session ends, the address and associated host state can be removed. When the mobile is not in-session, there is no implication on either the domain routing tables or the addressing resources. 5.2 Aggregate Prefix Routes The use of prefix routes means that the network can grow to be a big domain with a large number of access routers, supporting both mobile and fixed access technologies. Mobility becomes a delta on top of the prefix fabric rather than having host routes replicate the job of the prefix route in a very inefficient way. 5.3 Localised Host Redirect Routes The presence of the prefix aggregate route, and the use of the temporary session address results in the host route only being required for in-session mobility. The directivity of the host redirect, between the NAR and the OAR, and the chaining of such redirects, results in significant localisation of mobility induced routing messaging and host route state, instead of a domain wide host routes. The degree of localisation is dependent on the IP topology, associated routing metrics and even traffic engineering based TORA route selection. The degree of router meshing and the number of levels in the router hierarchy affect the potential reach of redirect host routes. Higher degrees of meshing, lower in the network, results in a more direct horizontal path between adjacent access routers for the hand-over message and the resulting redirect host route. This causes incoming packets from the core, and from most other access routers, to take longer to reach the host redirect state. However it will be seen sooner by packets coming from any intermediate AR (and associated connected sources) between the AAR and the present AR of the mobile due to the installed 'shallow' host route. O'Neill, Corson, Tsirtsis 22 Internet Draft EMA July 2000 A more tree like structure results in a more triangular path between adjacent nodes going higher into the core. This will mean that incoming packets from the core and from most other access routers will see the redirect later whilst the intermediate AR packets will see the redirect earlier. In addition, the use of preferential route metrics can be used to 'steer' the host redirect routes either higher or lower in the infrastructure as required, giving increased control above and beyond that 'implied' by the topology. 5.4 In-session Dynamics It is clear that an 'always on' mobile can be roaming anywhere over long periods of time. Any mobile routing solution that allocates persistent IP addresses, is forced to track that address in the routing/paging system leading to scaling problems. We instead separate the paging system from the mobiles care-of-address. In addition, we only track the mobile in the routing system during active IP sessions, which is likely to be a small proportion of the 'always on' mobile activation time. Further, whilst in-session, most internet applications require that the user becomes relatively stationary in the topology because it would be uncommon to drive, walk or generally concentrate on other things whilst, in parallel, browsing the web. There are certainly situations in which this application assumption is incorrect but in those cases it is other factors that limit the impact of host routes. For example, in the case of IP telephone calls where people are occasionally driving or walking, the call durations are short and the associated hand-over statistics are both well-known (GSM) and of little concern. In the case of planes and trains, we can simply support such 'rare' hosts routes within the localised cellular infrastructure and access routers along major routes through suitable dimensioning and associated tariffing. However, it is likely that in time IP infrastructure will be installed in such moving platforms resulting in a single aggregated host prefix for all those co-located nodes moving in sympathy. Further, the use of the MobileIP Permanent Home address and bindings ensures that the user is always reachable if the host route needs to be removed (either route hold timer expiry or CCoA reset). Finally, the profile specific IP session, address and route hold timers ensure that we can use tariffing to tune and control the impact of in-session mobility and usage patterns on the overall routing system. 5.5 TORA MER TORA was originally conceived as a MANET routing algorithm where it is intended for use in large-scale, dynamic, bandwidth-constrained MANETs. The principle objective behind its design is the achievement of "flat scalability", i.e. achieving a high degree of scalability (measured as the number of routers in a domain) with a "flat", non-hierarchical routing algorithm. In its operation the O'Neill, Corson, Tsirtsis 23 Internet Draft EMA July 2000 algorithm attempts to suppress, to the greatest extent possible, the generation of far-reaching control message propagation. With TORA, such suppression may or may not be feasible depending on the topology. As we will see subsequently, a key to achieving highly-scaled EMA routing with TORA turns out to be an issue of "topology control". Under appropriate topological conditions, TORA's reaction to link additions and failures can be highly localised, with smooth delocalisation as we move to more adverse topologies. This is a key property which we exploit based on the realisation that, viewed abstractly, the "make" and "break" operations in cellular networks correspond to link "additions" and "failures", respectively, in a unified mobile host/fixed router network. The subsequent lack of large amounts of far-reaching control message propagation--a feature common to shortest-path algorithms--afford TORA its relatively quick convergence and consequent stability. These properties appear desirable for the design of large-scale routed domains without any consideration for mobility support. In the most recent Internet Architecture Board (IAB) report on network layer issues [IAB99], the IAB concluded that the scalability bottleneck of presently deployed routing technology stems not from storage considerations but rather from long convergence times. These convergence delays are due to the time required to distribute table routing information updates (communication complexity) and the time required to re-compute routing tables (computational complexity). Operating in a suitable topology, TORA can have relatively low communication and computational complexity due to the nature of its distributed computation that forgoes shortest path computation. TORA also supports loop-free, multipath routing realised as a consequence of the usage of temporally, totally-ordered "heights". The provision of multipath routing makes the protocol amenable for load sharing and traffic engineering. The algorithm also has the potential to support fast restore via its link reversal mechanism based on the availability of fine-grained link status sensing, possibly from layer 2 mechanisms or from layer 3 mechanisms such as [FLIP]. 5.6 Performance Operating as an EMA-MER protocol, initial simulation results indicate that TORA may be well-suited for use in hierarchical mesh topologies [FMCTR]. Hierarchical mesh topologies have a limited number fully-meshed core routers, a greater number of intermediate routers (each dual-homed to two core routers), an even greater number of edge routers (each dual-homed to two intermediate routers) and a large number of access routers (each single-homed to an edge router). Such topologies have characteristics of both mesh and tree networks, which vary as a function of the hierarchical fan-out (the O'Neill, Corson, Tsirtsis 24 Internet Draft EMA July 2000 greater number of routers at each lower level) and the amount of multi-homing between levels. Proper topology design for TORA involves a balance between tree-like and mesh- like characteristics. The more tree-like the network, the better the routing efficiency of TORA relative to a shortest path routing algorithm due to the reduction in the number of potential preferred paths between ARs because of the route aggregation effects of hierarchical topologies. Simulation results obtained thus far indicate that routing efficiency deviates no more than 5% from optimal (i.e. shortest path) [FMCTR]. However, the more mesh-like the network, the greater the degree of control message localisation that can be obtained during handover. The objective of the localised hand-over model is to keep host-specific state out of the core and as far towards the network edge as possible. Simulation results indicate that with GSM call and mobility statistics for a domain with 1600 ARs, the mesh-like character achieved with dual- homing keeps host-specific state completely out of the core routers, distributing it to routers lower in the hierarchy [FMCTR]. The potential scalability of the proposed TORA EMA-MER approach is indirectly indicated by a comparison of simulation times for alternative approaches. Results for TORA EMA-MER operating over a domain with 1760 routers took little more than a day to simulate. However, to compare against an approach using a shortest-path computation (imagine a mobile overlay approach atop OSPF in a domain this large), it is estimated from observed simulation progress that it would have taken the same computer approximately 84 days to simply compute the dijkstra computations (one per router) to initialize the simulation. The TORA approach forgoes support for shortest-path routing and sacrifices an amount of routing efficiency to achieve highly-scaled operation in large domains. 6. Comparison to Alternatives 6.1 Mobile IP Mobile IP [MobileIP] is a well known technique for supporting edge mobility through the use of stateful intelligence and the permanent use of tunnels. Mobile IP is used in our proposal as the only credible means to support hand-over between Autonomous Systems whilst trying to preserve the current IP interface address and dependent IP sessions. It is also required to support subsequent roaming within a non-MER domain through re-registration and to provide signalling and temporary tunnelling services during hand- over Mobile IP takes the position that IP routing should not inherently try to support IP interface movement due to the implications on the scaling of the intra-domain routing. It is therefore deemed better to add functionality to hide the interface movement from the routing protocol(s). The authors of this draft fully concur with this position for traditional routing protocols such as OSPF, where the consequence of mobility in any reasonable O'Neill, Corson, Tsirtsis 25 Internet Draft EMA July 2000 domain is clearly disastrous for routing state and message overhead. However, we believe other routing approaches can achieve sufficient scaling to be commercially useful, and the case for Mobile IP against a routing solution becomes a more detailed comparison of interactions with other IP / cellular protocol features, system reliability, system overhead, time to market and ultimately cost etc. We believe that with suitable routing technology, the Mobile IP solution will in many cases be inappropriate, and we would encourage others to work on such technology, in competition to our detailed proposals that will be published when finished. In addition, to support the full set of cases, a converged solution employing both EMA:MER and MIP clearly provides substantial benefits to the overall system as shown in [EMA-MIP] 6.2 Cellular IP Cellular IP [CellularIP] is an existing proposal which to some extent fits aspects of this architecture, in particular in that it uses Mobile IP inter-domain and advocates use of a constant in- session address. It provides for hand-over-based redirection and soft state-based maintenance of host-specific routing and paging entries. These entries point to a central domain router, and the redirections modify a set of default routes collectively forming a tree. 6.3 HAWAII HAWAII [HAWAII] is another proposal similar to Cellular IP. It also advocates the use of a constant in-session address and Mobile IP inter-domain. It also provides for hand-over-based redirection of host-specific routing paths rooted at a central core router, although its hand-over and paging mechanisms are more complex than those of Cellular IP. Cellular IP and HAWAII differ from the proposed architecture in their use of a central routing tree. In EMA-MER approach, host routes modify a traditional, prefix-routed mesh topology and form route sets other than trees leading to reduced configuration, greater resilience, shorter data path lengths and topological design freedom. In addition, these approaches appear not to make provision for the temporary tunnelling of packets in flight whilst redirect routing converges, which can lead to data packet loss depending on topology, convergence time, link speeds, control packet loss recovery times and traffic load. More fundamentally, EMA-MER requires a full routing algorithm, employing hard state for both host-specific and prefix-based forwarding entries, rather than a soft-state overlay technique for mobile hosts independent of the underlying fixed routing. Trust is placed in the host-specific entries, and periodic soft-state reconfirmation is not utilized. The proposed system is designed to scale. Central to this design objective is the limitation of network control signaling, with the understanding that control O'Neill, Corson, Tsirtsis 26 Internet Draft EMA July 2000 message processing is a principal bottleneck to system scalability. Frequent route verification may potentially overload routers in the domain sizes we envision which further supports our design decisions. 6.4 OBAST While not a direct alternative to the EMA, a recent proposal on Open Base Station Transport (OBAST) [OBAST] is similar in spirit to the work behind EMA. A driving force behind both works is the development of a seamless IP layer hand-over model where radio layer specifics are hidden from hand-over processing. Whereas EMA then focuses more on specific routing and tunneling trade-offs within its proposed location management architecture, OBAST is somewhat larger in scope (e.g. it considers some transport layer issues) and puts forth a network architecture for wireless access mirroring that of the existing fixed Internet. The two proposals are similar in this latter sense as well in that EMA (at the network layer) advocates full convergence of fixed and mobile routing through the development of mobility-enhanced routing algorithms that permit natively-routed host mobility together with fixed host routing. Both approaches also view Mobile IP as useful for supporting inter-domain terminal mobility. Regarding hand-over control, EMA permits both network and mobile-controlled hand-over. OBAST is currently silent on the issue of MN-controlled hand-over, but intends support for a distributed form of BS-assisted hand-over elected "call anchors". OBAST also strongly prefers to consider only IPv6 whereas EMA prefers IPv6 but intends support for IPv4 as well. 7. Security This draft is too general to explicitly address security issues. Certainly host and router authentication must be handled in the architecture, and various mechanisms already exist for these purposes. For example, host authentication during dynamic address assignment is possible via [RADIUS]. Router authentication could be handled via shared key exchange as is common in many routing algorithms. Additionally, source address checking would be necessary and is assumed at all AR's. The MIP mechanisms described above can re-use mobile IP and AAA mechanisms as proposed in [AAAMIP] and [CIP] since the requirements and level of security required are the same. We specifically outline below the method of authenticating users in the signalling plane within an EMA domain due to the critical nature and hence threat of false hand-overs. O'Neill, Corson, Tsirtsis 27 Internet Draft EMA July 2000 7.1 Authenticating users within a domain Associated with each mobile node (MN) is a unique identifier known as its Mobile ID (MID). This is taken here to be an IP address (which may or may not be associated with an interface), but which may also be a Network Access Identifier (NAI). On arrival at a NAR, a MN must first either furnish proof of prior authentication within the domain, or be initially authenticated before it may send or receive any form of control or data traffic. Proof of prior authentication may be readily available in the form of a pre-paid SIM card or from a MN's private authentication key (as described subsequently). To perform an authentication check, the MN must present its credentials (including its MID) to the NAR. The method to conceal these items over the air interface is not addressed here. This transmission also advertises its current CCoA (if any) which it may have auto-generated on arrival at this NAR. Consequently, this authentication information may be passed to the NAR with a CCoA (IPv6), or with a NULL source address (IPv4) as is commonly done with DHCP. In the latter case the NAR (acting as a proxy for the MN) substitutes its address for the NULL address. The NAR then forwards the information to the local authentication server with which it already has a Security Association (SA). The local authentication server may then contact other servers as necessary to perform the authentication check. The outcome of the check (along with the MN's public key) is returned to the NAR. If successful, the NAR computes a Private Authentication Key (PAK) for the MN as an MD5 hash of the MN's MID and the domain's private "network key" known to all domain ARs. The computation of PAK and PIK herein are based on the PID scheme of [CIP]. The PAK forms a shared secret known only to the MN and the network, and serves as proof of MN authentication to other NARs in the domain. Unsuccessful authentication results in service denial. After a successful authentication, the NAR checks the MN's CCoA and, if NULL (IPv4), allocates a new CCoA for the MN. Using the resultant CCoA, the NAR computes a Private Identification Key (PIK) for the MN as an MD5 hash of the MN's CCoA and the domain's private "network key" known to all domain ARs, encrypts the PIK and PAK with the MN's public key, and sends these to the MN along with the network's public key and the MN's CCoA. Being keyed to the MN's CCoA, the PIK is valid as long as the MN uses this CCoA. The PIK can be used to authenticate (and optionally to encrypt) IP control packets over the air interface. Authentication is performed by creating a short hash from the (PIK, timestamp, packet content) triple that is placed into the transmitted packets. The validity of each packet can be easily checked by any NAR even immediately after a handoff and without prior communication with the MN or with the OAR. O'Neill, Corson, Tsirtsis 28 Internet Draft EMA July 2000 In addition to authenticating control packets, the PIK can optionally also be used to provide security for data packets transmitted over the wireless link. To this avail, any known, shared secret-based security mechanism can be used where the PIK serves as the shared secret. 8. References [EMA-MIP] A. O'Neill, S. Corson, G. Tsirtsis, "EMA Enhanced Mobile IPv6/IPv4", Internet-Draft,draft-oneill-ema-mip-00.txt, July 2000. [CellularIP] A. Valko, ``Cellular IP: A New Approach to Internet Host Mobility," ACM Computer Communication Review, Vol. 29, No. 1, January 1999. [CellularIPdraft] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi and A.Valko, "Cellular IP", Internet-Draft (work in progress), draft- valko-cellularip-01.txt, October 1999. [FLIP] H.Sandick et al., "Fast LIveness Protocol (FLIP)", Internet- Draft (work in progress), February 2000. [FMCTR] M. S. Corson, A. O'Neill, "An Approach to Fixed/Mobile Converged Routing", University of Maryland, Institute for Systems Research Technical Report, TR-2000-5, March 2000, http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000- 5.phtml [HAWAII] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.Salgarelli, ``IP micro-mobility support using HAWAII," Internet Draft, Work in Progress, June 1999. [HAWAIIdraft] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L.Salgarelli, ``IP micro-mobility support using HAWAII," Internet- Draft (work in progress), draft-ietf-mobileip-hawaii-00.txt, June 1999. [IAB99] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", Internet-Draft, draft-ietf-iab-ntwlyrws-over-01.txt, Oct. 1999. [MIPAAA] S. Glass et. all, "Mobile IP Authentication, Authorization, and Accounting Requirements", , work in progress, January 2000. [MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002, Oct 1996. [OBAST] P. Neumiller et. all, "Open Base Station Transport (OBAST)", Internet Draft (work in progress), , June 2000 O'Neill, Corson, Tsirtsis 29 Internet Draft EMA July 2000 [RADIUS] C. Rigney, A. Rubens, W. Simpson and S. Willens, ``Remote Authentication Dial in User Service (RADIUS),'' Request for Comments 2138, Apr 1997. [TORA] V. Park, M. S. Corson, "The Temporally-Ordered Routing Algorithm", Proc. IEEE INFOCOM '97, Kobe, Japan, April 1997. [TORAdraft] V. Park, M. S. Corson, "Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification", Internet-Draft (work in progress), draft-ietf-manet-tora-spec-02.txt, October 1999. [TORAthesis] V. Park, "A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks", Masters Thesis, University of Maryland, College Park, Maryland, 1997. Appendix A -- IPR Statement British Telecommunications plc has patent applications relevant to the architecture mentioned in this draft and to modifications of routing protocols. The modifications seek to achieve the scaling and performance objectives required for commercial cellular IP systems. British Telecommunications plc is currently considering giving an undertaking to the IETF to grant licences under the patents resulting from the patent applications on fair and reasonable terms so that vendors can develop systems based on IETF specifications for commercial deployment in a timely and cost-effective manner. British Telecommunications plc would also encourage the IETF to seek similar undertakings from others re licensing of their patents which could otherwise hamper the development and deployment of the IETF specifications related to this technology. Author's Addresses Alan O'Neill BT (+44) 1473-646459 alan.w.oneill@bt.com M. Scott Corson University of Maryland Ansible Systems (+1) 301-405-6630 corson@isr.umd.edu George Tsirtsis BT (+44) 020 88260073 george.tsirtsis@bt.com gtsirt@hotmail.com O'Neill, Corson, Tsirtsis 30 Internet Draft EMA July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into O'Neill, Corson, Tsirtsis 31 Internet Draft EMA July 2000 O'Neill, Corson, Tsirtsis 32