idnits 2.17.1 draft-oneill-ema-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 239 has weird spacing: '...ting as proxi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 1999) is 8952 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CellularIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'HAWAII' ** Obsolete normative reference: RFC 2002 (ref. 'MobileIP') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. O'Neill 2 Internet Engineering Task Force BT Laboratories 3 draft-oneill-ema-00.txt S. Corson 4 University of Maryland 5 Ansible Systems 6 22 October 1999 8 Edge Mobility Architecture 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft concurs with the authors of Cellular IP and HAWAII 34 regarding the need for domain-based routing support in handling edge 35 mobility. It suggests that a general routing solution might be 36 advantageous and presents the loose framework of a possible routing 37 architecture. It advocates the creation of a specific IETF working 38 group to address an overall architecture for edge mobility routing, 39 specific extensions to existing routing protocols to accomplish that 40 architecture, and extensions to existing Internet technologies to 41 support this architecture. 43 1. Introduction 45 Internet routing protocols have been traditionally designed from an 46 assumption that the location of an IP interface in the topology is 47 static. In addition, they assume that address allocation within the 48 topology will aim to provide multiple levels of IP address 49 aggregation such that routing protocols can deal with address 50 prefixes, rather than large numbers of host routes. Within this 51 framework, traditional intra-domain protocols, such as OSPF, need 52 only react to infrequent changes to the network due to link or router 53 failures or permanent modifications to the addressing scheme or the 54 topology. 56 Mobile Ad hoc NETwork (MANET) routing protocols have been developed 57 to address what could be considered to be an extreme scenario, 58 whereby the mobile nodes have permanent IP addresses which can 59 rapidly roam through an ad hoc topology, leading to the need for 60 alternative routing technology and the general loss of aggregation 61 opportunities. 63 A third family of routing protocols is now under investigation for 64 the case in which the core topology is essentially fixed but the end 65 systems are mobile. This is the classical edge mobility scenario that 66 is today supported by cellular networks, primarily as part of the 67 cellular technology elements (GSM, GPRS etc). Migrating this routing 68 function to the layer 3 IP routing protocol, to release all the end- 69 to-end internetworking benefits which has aided the deployment of the 70 Internet, would tend to suggest a fusion of the MANET and traditional 71 routing protocol architectures. The primary aim is to move the IP 72 interface location in the routing topology as the mobile changes base 73 stations so that active IP sessions are maintained. This is clearly 74 only one of the possible models and this draft does not make any 75 judgments as to the pro's and con's of this particular mobility 76 model, but is simply using it as a precursor for the discussion of 77 the related hand-over architecture. 79 These edge mobility networks can be considered to have a single IP 80 routing protocol which runs between routers in the domain, with some 81 of those routers being the edge base stations equipped with a 82 (potential) diversity of radio technologies such as CDMA, TDMA and 83 Radio LANs etc. The radio layers are assumed to provide the well 84 known layer 2 hand-over models and other capabilities including 85 break-before-make, make-before-break, power measurement, mobile 86 assisted hand-over, paging and security features. To facilitate 87 internetworking, inter-base station coordination is assumed to use 88 IP-based communication using messages which are abstractions of the 89 messages which are today carried in cellular technology-specific 90 messages, often via central processing elements. 92 This brief draft proposes a general approach to the support of this 93 edge mobility function, with the aim of being generic enough to 94 support a range of different routing protocols, as well as enabling 95 hand-over between diverse types of cellular technology through 96 capability exchange between radio-equipped base stations. It does not 97 deal with the details of these mechanisms as they are specific to the 98 type of routing protocol selected. This draft does also not discuss 99 the effects of the architecture on DNS, DHCP and infrastructure 100 services, nor does it contribute to the debate on the appropriate 101 layer and model for mobile terminal paging. 103 2. Mobile Routing Architecture 105 The architecture proposed assumes that modifications to either MANET 106 or traditional routing protocols are possible which will enable these 107 protocols to comply with this architecture and hence facilitate a 108 message set and control model which has a degree of protocol 109 independence. The details of these modifications are left to later 110 drafts, both from the authors of this draft, and likely contributions 111 from other researchers in this area. Clearly, the actual detailed 112 mechanisms, message content/timing and performance are going to be 113 dependent on the type of intra-domain routing protocol that forms the 114 basis for the mobility extensions. 116 The architecture has six main components, the first being the use of 117 mobile IP across provider boundaries to facilitate the temporary 118 movement of an IP address (on a mobile terminal interface) away from 119 its home domain whilst maintaining active sessions. The mobile IP 120 tunnels are initiated by a base station (HA) at the inter-domain 121 boundary to the base station (FA) in the foreign domain, and are 122 extended to further base stations in the foreign domain using normal 123 Mobile IP foreign agent mechanisms. This bounds subsequent 124 discussions to intra-domain routing issues. The other five components 125 are: 127 a) the provision of a modified intra-domain routing protocol which 128 provides prefix-based routing within a domain, with each prefix 129 representing a block of IP addresses allocated to each base 130 station in the domain, as well as host routes to support mobile 131 terminal migration away from the allocating (IP address) base 132 station, 134 b) the provision and use of a virtual link for routing exchange 135 and messaging between adjacent base stations to exchange 136 capabilities, and to effectively and locally manage the hand-over 137 of the responsibility for, and routing of, the mobile terminal and 138 it's associated IP address, 140 c) the ability to inject a host route for the mobile, 142 d) the ability to poison the existing route to the mobile via the 143 old base station 144 e) the provision and use of a temporary tunnel to redirect packets 145 in flight between the old base station and the new base station 146 whilst routing converges, and 148 f) a method to return the allocated IP address to the allocating 149 base station on mobile session termination at a different base 150 station in the same domain. 152 The reasons for each of these components will be explained in the 153 following sections which will give examples for CDMA (make-before- 154 break) and TDMA (break-before-make) handover. 156 2.1 Mobile Session Start-Up 158 The mobile connects to the nearest / best base station and is brought 159 into the IP routing domain by requesting and being allocated an IP 160 address out of the block of addresses managed by that base station. 161 The base station will be advertising the IP address prefix associated 162 with that address block into the intra-domain routing protocol such 163 that 'at home' mobiles have a proactively and permanently advertised 164 route, and are immediately reachable to all hosts in the internet. 165 As the mobile moves base stations, this IP address moves with them so 166 that higher-layer sessions are unaffected. This is accomplished by 167 modifying the intra-domain routing using hosts routes to overrule 168 (longest match) or overwrite the underlying proactive base station 169 prefix routing. Placing an appropriate set of messages over IP 170 ensures that a wide range of radio technology specific hand-over 171 models can be accommodated within a single IP model to allow for 172 internetworking of IP over those diverse technologies. 174 2.2 Break before Make 176 TDMA technology such as GSM only allows the mobile to be connected to 177 a single base station at a time, with a data path dead-time incurred 178 during hand-over. The 'inject' route feature is therefore invoked 179 when the old and new base stations have been identified, and have 180 agreed to the hand-over by creating the dynamic redirect tunnel 181 between themselves. Note that for efficiency purposes a single 182 redirect tunnel could be pre-configured between adjacent base 183 stations to support all inter-base station hand-overs, and dynamic 184 mobile-specific redirect state temporarily installed against that 185 aggregate tunnel. Either way, the base stations collaborate to 186 locally inject the new route into the routing domain. When the mobile 187 disconnects at the radio layer from the old base station, the new 188 base station, through the inter-base station virtual link or tunnel, 189 is immediately known to be the next best hop, and packets will be 190 immediately redirected down the tunnel to the new base station. Some 191 time later the mobile will attach to the new base station and will 192 immediately receive in-flight and locally cached packets. The base 193 stations then again collaborate to poison the old route that points 194 to the old base station, and to propagate the new route from the new 195 base station. When routing has converged, the old base station will 196 detect this and eliminate the redirect state associated with the 197 temporary tunnel. Packets to the mobile will then head towards the 198 new base station route. The reception of the mobile is then confirmed 199 through acknowledgement messages to the old base station which is 200 used to confirm hand-over of responsibility for the mobile and it's 201 IP address in the system. 203 2.3 Make Before Break 205 CDMA technology enables a mobile terminal to be connected to two base 206 stations at the same time and to undertake measurements to establish 207 the preferred channel and hand-over time. In this system it is 208 therefore important to support concurrent routing paths from all 209 potential senders to the mobile via the two concurrent base stations. 210 This requires the inject route feature from the base stations to be 211 invoked before the mobile leaves the old station, and for the poison 212 route feature to only be invoked when the hand-over to the new base 213 station is triggered, rather than simply on connection to the new 214 base station. Finally, it is necessary to ensure that some data is 215 simultaneously received over the concurrent paths so that the mobile 216 is able to make comparative path quality measurements. 218 2.4 Hybrid Model 220 When a hybrid node is able to support both TDMA and CDMA (or other 221 combinations of technology) then a consistent set of base station and 222 mobile IP messages makes hand-over of the concurrent sessions between 223 TDMA and CDMA base stations possible. This is achieved by the base 224 stations understanding each others capabilities, and holding up and 225 synchronising the inject and poison stages as appropriate. 227 2.5 Mobile Switch Off 229 It is clear that the migration of IP addresses away from the 230 allocating base station can lead to address exhaustion and a gradual 231 degradation over time of the usefulness of the proactively advertised 232 base station address block prefix. It is therefore critical that at 233 the moment that the mobile finishes active sessions, at a distant 234 base station, that the IP address is returned to the home base 235 station. This can be modelled as a virtual mobile moving from the 236 distant base station back to the home base station and then locally 237 returning the IP address. This can be accomplished using similar 238 mechanisms which are used to support real inter-base station hand- 239 overs, with the base stations acting as proxies for the virtual 240 mobile. Their aim is to co-ordinate the removal of all host specific 241 routing entries in the domain as a result of previous mobility away 242 from the home base station. 244 3. Comparison to Alternatives 246 3.1 Mobile IP 248 Mobile IP [MobileIP] is a well known technique for supporting edge 249 mobility through the use of stateful intelligence and the permanent 250 use of tunnels. Mobile IP is used in our proposal as the only 251 credible means to support hand-over between Autonomous Systems whilst 252 trying to preserve the current IP interface address and dependent IP 253 sessions. Mobile IP effectively takes the position that IP routing 254 should not inherently try to support IP interface movement due to the 255 implications on the scaling of the intra-domain routing. It is 256 therefore deemed better to add functionality to hide the interface 257 movement from the routing protocol(s). The authors of this draft 258 fully concur with this position for traditional routing protocols 259 such as OSPF, where the consequence of mobility in any reasonable 260 domain is clearly disastrous for routing state and message overhead. 261 However, we believe other routing approaches can achieve sufficient 262 scaling to be commercially useful, and the case for Mobile IP against 263 a routing solution becomes a more detailed comparison of interactions 264 with other IP / cellular protocol features, system reliability, 265 system overhead, time to market and ultimately cost etc. We believe 266 that with suitable routing technology, the Mobile IP solution will in 267 many cases be inappropriate, and we would encourage others to work on 268 such technology, in competition to our detailed proposals that will 269 be published when finished. 271 3.2 Cellular IP 273 Cellular IP [CellularIP] is an existing proposal which to some extent 274 fits aspects of this architecture, in particular in that it uses 275 Mobile IP inter-domain and advocates use of a constant in-session 276 address. It provides for handover-based redirection and soft state- 277 based maintenance of host-specific routing and paging entries. These 278 entries point to a central domain router, and the redirections modify 279 a set of default routes collectively forming a tree. 281 3.3 HAWAII 283 HAWAII [HAWAII] is another proposal similar to Cellular IP. It also 284 advocates the use of a constant in-session address and Mobile IP 285 inter-domain. It also provides for handover-based redirection of 286 host-specific routing paths rooted at a central core router, although 287 its handover and paging mechanisms are more complex than those of 288 Cellular IP. 290 Cellular IP and HAWAII differ from the proposed architecture in that 291 here host routes modify a traditional, prefix-routed mesh topology 292 and form route sets other than trees leading to reduced 293 configuration, greater resilience, shorter data path lengths and 294 topological design freedom. In addition, these approaches appear not 295 to make provision for the temporary tunnelling of packets in flight 296 whilst redirect routing converges, which can lead to data packet loss 297 depending on topology, convergence time, link speeds, control packet 298 loss recovery times and traffic load. 300 4. IETF Working Group Activity 302 British Telecommunications (BT) would welcome the creation of a 303 specific IETF working group to address an overall architecture for 304 edge mobility routing, specific extensions to existing routing 305 protocols to accomplish that architecture, and extensions to existing 306 Internet technology (DNS, DHCP, AAA etc) to support this 307 architecture. We would be happy for Cellular IP and HAWAII to be 308 covered by such a working group assuming the respective authors 309 concur. 311 5. Security 313 This draft is too general to explicitly address security issues. 314 Certainly host and router authentication must be handled in the 315 architecture, and various mechanisms already exist for these 316 purposes. For example, host authentication during dynamic address 317 assignment is possible via [RADIUS]. Router authentication could be 318 handled via shared key exchange as is common in many routing 319 algorithms. Additionally, mechanisms would be required for 320 authenticating Mobile IP messages and the discussion of possible 321 approaches in [HAWAII] applies here as well. Additionally, source 322 address checking would be necessary. 324 6. References 326 [CellularIP] A. Valko, ``Cellular IP: A New Approach to Internet Host 327 Mobility," ACM Computer Communication Review, Vol. 29, No. 1, January 328 1999. 330 [HAWAII] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L. 331 Salgarelli, ``IP micro-mobility support using HAWAII," Internet 332 Draft, Work in Progress, June 1999. 334 [MobileIP] C.E. Perkins, ``IP Mobility Support," Internet RFC 2002, 335 Oct 1996. 337 [RADIUS] C. Rigney, A. Rubens, W. Simpson and S. Willens, ``Remote 338 Authentication Dial in User Service (RADIUS),'' Request for Comments 339 2138, Apr 1997. 341 Appendix A -- IPR Statement 343 British Telecommunications plc has patent applications relevant to 344 the architecture mentioned in this draft and to modifications of 345 routing protocols. The modifications seek to achieve the scaling and 346 performance objectives required for commercial cellular IP systems. 348 British Telecommunications plc is currently considering giving an 349 undertaking to the IETF to grant licences under the patents resulting 350 from the patent applications on fair and reasonable terms so that 351 vendors can develop systems based on IETF specifications for 352 commercial deployment in a timely and cost-effective manner. 354 British Telecommunications plc would also encourage the IETF to seek 355 similar undertakings from others re licensing of their patents which 356 could otherwise hamper the development and deployment of the IETF 357 specifications related to this technology. 359 Author's Addresses 361 Alan O'Neill 362 BT Laboratories 363 (+44) 1473-646459 364 alan.w.oneill@bt.com 366 M. Scott Corson 367 University of Maryland 368 Ansible Systems 369 (+1) 301-405-6630 370 corson@isr.umd.edu