idnits 2.17.1 draft-ietf-seamoby-mm-problem-01.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 == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 111 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 441: '... MUST be able to co-exist gracefully...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 30 has weird spacing: '...tribute worki...' == Line 394 has weird spacing: '...Message con...' -- 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 (February 23, 2001) is 8455 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) == Missing Reference: 'Fast IP6' is mentioned on line 367, but not defined == Unused Reference: '2460' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'Fast MIP6' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'TORA' is defined on line 750, but no explicit reference was found in the text == Unused Reference: '2501' is defined on line 755, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2753 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Fast MIP6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TORA' ** Downref: Normative reference to an Informational RFC: RFC 2501 -- Possible downref: Non-RFC (?) normative reference: ref. 'MIP RSVP' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Loughney (Editor) 3 Internet Engineering Task Force Nokia 4 D. Blair 5 Cisco 6 P. Hazy/H. Li/M. Jaseemuddin 7 G. Tardy 8 Nortel 9 O. H. Levkowetz 10 ABNW 11 J. Manner 12 University of Helsinki 13 P. Neumiller 14 3Com Corporation 15 R. Ramjee 16 Lucent 17 Issued: February 23, 2001 18 Expires: August 23, 2001 20 SeaMoby Micro Mobility Problem Statement 21 23 Status of This Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC 2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as 'work in progress.' 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 Seamless mobility requires preserving the capability, security, and 47 quality of service offered to a mobile node during handovers. To 48 achieve seamlessness, low (ideally no) latency and low (ideally 49 zero) packet loss handover protocols are needed. Limiting the effect 50 of handovers has the potential to improve handover performance in 51 terms of latency and packet loss. This draft identifies the problem 52 area for seamless mobility and defines the scope of the work for the 53 SeaMoby work group. 55 Abstract..............................................................1 56 1 Introduction........................................................3 57 1.1 Scope ...........................................................3 58 1.2 Problem Statement ...............................................4 59 1.3 Terminology .....................................................4 60 1.4 Architectural Diagram.............................................6 61 2 Overview............................................................7 62 2.1 Goals ...........................................................8 63 3 Interaction / Comparison With Other Protocols.......................8 64 3.1 Comparison with Mobile IP .......................................8 65 3.1.1 Scalability & Performance Related Issues .....................9 66 3.2 MANET / Ad-Hoc Networking Comparison ...........................10 67 4 Scenarios..........................................................10 68 4.1 Intra-domain mobility ..........................................10 69 4.1.1 Handover Within a Subnet ....................................10 70 4.1.2 Seamless Intra-domain Mobility With Optimized Routing. ......11 71 4.1.3 Confidentiality and Optimal Path When Roaming ...............11 72 4.1.4 Mobile Network and Route Aggregation ........................11 73 4.2 Inter-domain mobility ..........................................11 74 4.2.1 Local Mobility Spanning Multiple Domains ....................11 75 4.2.2 Local mobility restricted to a single domain ................12 76 4.3 Local-mobility protocol deployment scenarios ...................12 77 4.3.1 Options to Deploy Local-mobility Protocol in Routers ........12 78 4.3.2 Ease of Deployment by Allowing Plug and Play Capability .....12 79 4.3.3 Local-mobility Protocol in Different ADs ....................12 80 4.4 Summary ........................................................13 81 5 Next Steps.........................................................13 82 6 Security Considerations............................................13 83 7 IANA Considerations................................................14 84 8 Acknowledgments....................................................14 85 9 Author's Addresses.................................................14 86 10 References........................................................15 87 Full Copyright Statement.............................................16 88 1 Introduction 90 The convergence of wireless networking and IP networking requires 91 solutions for transporting realtime application data to IP enabled 92 mobile devices and mobile networks. Current IP mobility solutions 93 tend to focus primarily on best effort data transport to and from a 94 mobile device where the routable IP address (for example, Mobile IP 95 Care-of Address) of the Mobile Device changes during handover. 97 Seamless handover for realtime applications imposes strict 98 requirements on latency and packet loss. Packet drops should be 99 minimized when moving from one access router to another. Latency 100 due to the handover from one access router to another should be 101 minimized so as not to impact the applications running on a mobile 102 device or mobile network. 104 The assumption is that a local protocol can address these goals by 105 limiting its applicability to a smaller domain thus reducing the 106 amount of signaling needed that should improve performance. This 107 assumption may require that the scope of a local mobility protocol 108 be restricted to the case of mobility support of a mobile host whose 109 routable IP address does not change. 111 In this draft, the term 'local mobility' is used in place of 112 micromobility. 114 1.1 Scope 116 The scope of mobility will be developed as part of the solution 117 space. Possibilities include: 119 Mobility where the User's routable IP address does not change 121 Where the mobility may be: 123 Within a subnet. 124 Within an administrative domain. 125 Between administrative domains. 126 Within a limited number of hops 128 This is not meant to be an exhaustive survey, but to point in the 129 direction for further analysis. For example, source-based routing 130 [DSR] and tunneling [2002] are two possible solutions for mobility. 131 Some source routing schemes [DSR] allow: 133 "... packet routing to be trivially loop-free, avoids the need for 134 up-to-date routing information in the intermediate nodes through 135 which packets are forwarded, and allows nodes forwarding or 136 overhearing packets to cache the routing information in them for 137 their own future use." 139 Tunnel-based approaches [2002][MIPv6] may have better scaling 140 properties, but this may not be an issue with local mobility 141 domains. 143 1.2 Problem Statement 145 There are many proposals for adding and enhancing mobility in IP 146 networks, for example Mobile IP [2002][MIPv6]. There are a number 147 of proposals to optimize Mobile IP signaling to allow fast handovers 148 [FAST MIPv6]. However, none of these completely address the complex 149 interaction of parameters and protocols needed for Seamless 150 Handovers. 152 A local mobility mechanism, which localizes processing and 153 signaling, thus enabling less latency, should allow better 154 scalability, performance and reliability resulting in seamless 155 handovers. Moreover, a lightweight approach, customized to the exact 156 requirements of local mobility while interoperable with a more 157 general mobility mechanism (e.g. vanilla Mobile-IP [2002]), would 158 allow an easier deployment in situations where local mobility is 159 sufficient, or several general mobility mechanisms are involved. 161 Applicability of the above might be useful for networks with 162 multiple layer 3 access points with unreliable connectivity between 163 the mobile and those access points, for example. 165 While studying solutions for seamless handovers, the SEAMOBY Working 166 Group should include the following considerations: 168 * Mobility maintaining the same routable IP address of a mobile 169 node or mobile network. 170 * Handover between heterogeneous networks. For example, 802.11, 171 Bluetooth and 3G cellular. 172 * How to discover a new Access Link and the Access Router serving 173 the new Access Link. 174 * How to discover the bandwidth, cost, error rate (and other 175 properties) of candidate Access Links. 176 * Involving QoS characteristics as part of the handover process. 177 * Optimize the path for mobile-to-mobile communications. 178 * Enable plug and play capabilities for Mobile Devices, Access 179 Routers/Access Links. 180 * Support for mobility of mobile hosts and mobile networks 182 Prioritization of, additions to, and details of the above items will 183 be worked out during the requirements phase. 185 1.3 Terminology 187 See [SM Terms] for additional terminology. 189 Local Mobility The movement of an IP device without requiring 190 a change to its routable IP address. Although 191 its point of attachment may change during the 192 move, the IP address used to reach the device 193 (both its home and IP subnet routable IP 194 address) do not change. 196 Seamless Handover A handover procedure which does not result in 197 any change in service capability, security, or 198 quality. This procedure has strict timing 199 requirement for the execution and low (zero) 200 packet loss. 202 Subnet A range of IP address designated by a common 203 prefix constitutes a subnet. A subnet exists 204 when no IP routing is required to reach the 205 intended host. Examples: For IPv4: 10.1.1.0/24 206 (subnet mask is 255.255.255.0), for IPv6: 207 1234:5678:90AB:CDEF::/64 209 Network A Network is characterized by a range of IP 210 address designated by a common prefix and may 211 contain one or more adjacent subnets 212 interconnected by IP routers. 214 Administrative Domain A collection of networks under the same 215 administrative control and grouped together 216 for administrative purposes. [2753] 218 Local Mobility Domain A Local Mobility Domain contains one or more 219 IP subnets, networks, or Administrative 220 Domains. Within the Local Mobility Domain, 221 the routable IP address assigned to a Mobile 222 Host or Mobile Router serving a Mobile Network 223 does not change. 225 Mobile Node (MN) An IP node capable of changing its point of 226 attachment to the network. The MN can be 227 either a mobile end-node or a mobile router 228 serving an arbitrarily complex mobile network. 230 Mobile Host (MH) An IP node capable of changing its point of 231 attachment to the network. The MH only refers 232 to an end-node without further routing 233 support. 235 Mobile Router (MR) An IP Router that may change its point of 236 attachment to an IP network. 238 Mobile Network An IP network where one or more Mobile Routers 239 are used to access a larger IP network. 241 Access Point (AP) A layer 2 device, which is connected to one or 242 more Access Routers and offers the wireless 243 link connection to the MH. Access Points are 244 sometimes called 'base stations'. Note that 245 this usage differs from that used by some 246 Access Router vendors, who call their boxes 247 'Access Points'. 249 Access Router (AR) An IP router residing in an Access Network and 250 connected to one or more access points. An AR 251 offers connectivity to MNs. The router may 252 include intelligence beyond simple forwarding 253 service offered by ordinary IP routers. An AR 254 communicates with one or more Access Points. 256 Access Network Gateway (ANG) An IP gateway that separates the Access 257 Network from a third party network. 259 Access Network (AN) An IP network that includes one or more ARs 260 and ANGs. 262 Radio Cell An area associated with each AP, where there 263 is radio coverage, i.e. where radio 264 communication between a MN and the specific AP 265 is possible. 267 1.4 Architectural Diagram 269 The following diagram proposes an example architecture, for 270 reference. It is not meant to impose any restriction upon mobility, 271 but for use to better visualize the problem space. 273 +-+ 274 | | ---+ 275 +-+ | 276 AP1 | 277 | 278 +-+ | +-----+ +-----+ | 279 |<--> | | ---+---| AR1 |-------------------| | | 280 [] +-+ | +-----+ \ /| ANG |--| 281 MN AP2 | \ / | | | 282 | \ / +-----+ | 283 +-+ | \ / | 284 | |----+ X | 285 +-+ / \ | 286 AP3 / \ | 287 / \ +-----+ | 288 +-+ +-----+ / \| | | 289 |<--> | |-------| AR2 |--------------------| ANG |--| 290 [] +-+ +-----+ | | | 291 MR AP4 +-----+ | 292 | 293 Administrative Domain (AD) 1 | 294 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|- 295 Administrative Domain (AD) 2 | 296 | 297 | 298 +-+ +-----+ +-----+ | 299 |<--> | | -------| AR3 |-------------------| | | 300 [] +-+ /+-----+ /| ANG |--| 301 MH AP5 / / | | | 302 / / +-----+ | 303 +-+ / / | 304 | |---- / | 305 +-+ / | 306 AP6 / | 307 / | 308 +-+ +-----+ / | 309 | |-------| AR4 |----------- | 310 +-+ \ +-----+ / | 311 AP7 \ / | 312 \ / | 313 \ +-----+ / | 314 --| AR5 |------ | 315 +-----+ | 317 Figure 1: Architectural Diagram for Local Mobility 319 2 Overview 321 Local Mobility should also consider if the new access router (ARn+1) 322 provides the same 'services' (QoS, etc.) as expected by the user. A 323 local mobility solution should (a) ensure that ARn+1 provides the 324 same QoS as ARn or (b) alert applications that QoS is changing or 325 has changed. 327 2.1 Goals 329 Below are listed a number of issues, which any local mobility 330 solution should address. The exact nature shall be detailed in a 331 requirements for micromobility document. 333 * Mobility without changing the routable IP address 334 * Use Mobile IP WG protocols for mobility between local mobility 335 domains 336 * The solution is IP version neutral, although implementation 337 details may differ for IPv4 and IPv6 338 * Handover to new AR that can provide the same quality and 339 security of service as the old AR or alert the application if 340 change occurs 341 * Scale well with the size of the local mobility domain 342 * Inter-technology/heterogeneous mobility support 343 * Mobility support for mobile hosts and mobile networks 344 * Use MIP for signaling from the MN. 345 * Enable optimized routing for MN to MN communications. 346 * Inter-operate with existing QoS protocols (i.e. RSVP) 347 * Plug and play (automatic setup and recovery, handle failures 348 gracefully) 349 * Allow a progressive deployment 350 * Bandwidth optimization, maximizing throughput e.g. with a smart 351 handover algorithm 352 * User location confidentiality 353 * Support connectivity to multiple Access Routers simultaneously 354 (IP diversity / load balancing) 355 * Allow simple ad-hoc networking 357 These goals should serve as input to local mobility requirements. 359 3 Interaction / Comparison With Other Protocols 361 Local Mobility will interwork with Context Transfer. 363 This work will define the areas of intersection (and non- 364 intersection) between SeaMoby and the following: 366 * Mobile IP [2002], [MIPv6] 367 * Fast Handovers [Fast IP6] 368 * Hierarchical MIPv4 / MIPv6 369 * Regional Registrations for IPv6 370 * Mobility management in other networks 372 3.1 Comparison with Mobile IP 374 Goals Solution based on Mobile IP 375 1) Seamlessness: Fast/Proactive Handover work 376 2) Scalability: Hierarchical Mobile IP work 377 3) Efficiency: Requires tunneling; Route Optimization 378 work; For localized updates, Hierarchical 379 Mobile IP 380 4) Configurability: Plug & Play of ARs/APs not addressed. 381 Autoconfiguration is addressed in IPv6, 382 but capabilities of the APs is not 383 addressed by Mobile IP. 384 5) Reliability: HA/GFA (MIPv4); MAPs (MIPv6) need 385 redundancy, failover capability 386 6) QoS: controversial; tunneling complicates QoS 387 support. 388 7) Paging: controversial; not addressed 389 8) AAA/Registration: controversial; speed of 390 (re)authentication and/or 391 (re)registration during cross-AD handover 392 may require expedited techniques or 393 credential development. 394 9) Security/Message controversial; speed of message (e.g., 395 Authentication: context transfer) authentication during 396 cross-AD handover may require expedited 397 techniques (e.g., key or ticket 398 infrastructure). 399 10) Mobile Network Optimized Routing in IPv4 does not 400 Support: support mobile routing; nor does MIPv6 401 sufficiently define interoperable support 402 for mobile networks. 404 Thus, Mobile IP WG does not completely cover the solution space 405 for Seamless mobility. More detailed analysis should be done to 406 determine the applicability of Mobile IP to local mobility and to 407 identify Mobile IP's shortcomings. 409 3.1.1 Scalability & Performance Related Issues 411 For MIPv4, there is a concern that a GFA/FA in every AR may not 412 scale or even be desirable in extremely inexpensive AR devices. 413 Also, there is a concern that putting an FA essentially everywhere 414 would add complication to what could be a relatively simple micro- 415 mobility handover. 417 Interactions between Mobile IP and QoS mechanisms (for example RSVP) 418 are complex and may not work fast enough. [MIP RSVP] They introduce 419 additional signaling. 421 It has been suggested that in order to scale MIP, Hierarchical / 422 Regional FAs, GFAs, MAPs and other such "in the middle of the 423 network boxes" are needed. This may be considered a limitation of 424 MIP. This begins to chip away at some fundamental philosphies of the 425 internet, such as making the network robust against single points of 426 failures; that intelligence exists at the edge and so on. 428 3.2 MANET / Ad-Hoc Networking Comparison 430 The MANET WG in the IETF has an important charter to create a 431 protocol for mobiles arranged in arbitrary and highly dynamic 432 associations. This work is striving for robust and highly scalable 433 routing solutions. Currently, MANET is not considering fast or 434 seamless handover. 436 In many instances, for example small residential networks found in 437 the home, the network may be relatively small and has far less 438 dynamics. The network may still have a requirement for fast and/or 439 seamless handovers. For this reason there may be some overlap 440 between SeaMoby and ad-hoc networking solutions. Therefore, SeaMoby 441 MUST be able to co-exist gracefully with any MANET solutions 442 algorithm that does become standardized. 444 4 Scenarios 446 This section is intended as to provide some simple, descriptive 447 examples of the problem. The network is based on Figure 1, in 448 section 1.4. In the scenarios, the term mobile node (MN) is used, 449 but the node could be a mobile host, mobile router, etc. 451 I work for company X that controls and manages its intra-net AD1 in 452 Figure 1. Employees at my work use mobile hosts to roam within AD1. 453 In the city, I can be reached through ISP Y's cellular network, AD2 454 in Figure 1. 456 4.1 Intra-domain mobility 458 Company X provides mobility service to its employees within the 459 intra-net AD1. The IP address of a mobile host remains fixed 460 regardless of its attachment point within the administrative domain. 462 4.1.1 Handover Within a Subnet 464 The MN moves out of AP3 (802.11) coverage area, and can select AP2 465 (802.11) or AP1 (Bluetooth), which are all connected on the same 466 subnet (e.g. - Ethernet) to AR1. 468 On each handover, the new access point must ensure sufficient 469 capacity to support traffic related to the mobile node aside of pre- 470 existing connections. In this example, the Bluetooth access point 471 AP1 experiences temporary environmental noise (e.g. - an oven), and 472 the corresponding loss of available capacity. Therefore, a handover 473 to AP2 is selected. This is an intra-AR handover between APs of the 474 same technology. In this case Inter-AP protocol (e.g. - 802.11 IAPP) 475 will be used to do handover. 477 Later, the MN moves to an area that is only covered by AP1 478 (Bluetooth), so an inter-technology handover occurs between AP2 479 (802.11) to AP1 (Bluetooth) 481 4.1.2 Seamless Intra-domain Mobility With Optimized Routing. 483 A user establishes a video phone call with a colleague. During the 484 call both parties move around the building; their Mobile Nodes hop 485 between subnets while changing their attachment point. However, 486 there is no degradation in the quality of the video phone call. The 487 network continuously maintains an optimized communication path 488 between the two mobile nodes. More precisely, the path for a session 489 between two mobile hosts should be ideally the same as the path 490 selected if the mobile nodes were fixed devices. This is an instance 491 of seamless intra-domain mobility with optimized routing. 493 4.1.3 Confidentiality and Optimal Path When Roaming 495 An IETF member wants to download drafts while moving between several 496 work group meetings. The IETF Member would like to maintain 497 confidentiality, while doing so. Binding Updates (BU) will reveal 498 location, and home agent (HA) produce triangular routing. Therefore, 499 it would be very useful to have a local-mobility solution supporting 500 location confidentiality within the administrative domain while 501 providing optimal communication path. 503 4.1.4 Mobile Network and Route Aggregation 505 An ISP provides wireless service for users travelling on the city 506 train. The trains have an IP network installed to provide Internet 507 access to the users on the train. There might be one or more mobile 508 routers that have radio interfaces to communicate with the AP's of 509 the ISP. To reach the hosts on the moving train, it is desirable to 510 have an aggregate route for all the hosts in the train. This is an 511 instance where an ISP provides local mobility for route aggregates. 513 4.2 Inter-domain mobility 515 Service providers may make agreements allowing local mobility to 516 span different administrative districts, or may simply provide 517 roaming between these ADs. This can produce the following scenarios. 519 4.2.1 Local Mobility Spanning Multiple Domains 521 When I drive to the supermarket, I enter Y's domain. My company X 522 has an agreement with Y that allows me to make fast hand-off to Y's 523 domain with the same IP address that I used to roam within X domain. 524 The ISP Y provides under this agreement best effort connectivity to 525 me (using the IP address assigned by X) for some time, before it 526 requires me to perform Mobile-IP, e.g. for negotiating new IP 527 address, issuing BUs, doing AAA, etc. As a result of Mobile-IP 528 processing, I will get a new IP address for roaming within Y's 529 domain, and other contracted services, such as QoS. The ISP Y 530 provides best effort connectivity for the transitory period, because 531 it must perform authentication and authorization, and retrieve 532 user's service (QoS) profile, before providing QoS and other 533 contracted services. This is an instance of fast handover handled by 534 local mobility protocol first, then an inter-domain mechanism (e.g. 535 Mobile-IP)is invoked for AAA and contracted services. 537 4.2.2 Local mobility restricted to a single domain 539 When I drive to the supermarket, I enter Y's domain. My company X 540 has an agreement with Y that allows me to roam within Y's cellular 541 network and receive my contracted services. The ISP Y first assigns 542 me a new IP address before providing me connectivity. Hence, as soon 543 as I discover that I am in Y's domain, I must initiate Mobile-IP 544 processing to perform inter-domain hand-off. 546 4.3 Local-mobility protocol deployment scenarios 548 4.3.1 Options to Deploy Local-mobility Protocol in Routers 550 The local mobility protocol may be deployed in all the nodes or a 551 selected set of the nodes in a network. The network nodes with 552 local-mobility routing capability can be named as Mobile Location 553 Aware Nodes (MLAN). If all the nodes in a network are MLAN, each 554 node knows how to forward the data packets towards a mobile device. 555 If only a subset of the network nodes are MLAN, tunnels can be used 556 to connect the MLANs so that the data packets can be tunneled 557 through the non-MLANs between a pair of MLANs. Therefore, we can 558 think that the local-mobility protocol is applicable among the MLANs 559 for local-mobility routing in the network. Conceptually, there 560 should be no difference for the protocol whether it is used in the 561 network routers or mobile agents. 563 4.3.2 Ease of Deployment by Allowing Plug and Play Capability 565 A service provider may want to temporally setup wireless service in 566 a location, or the service provider want to expand its wireless 567 service to a new area. When the new equipment connected to the 568 network, the new routers/agents can learn how to forward data 569 packets by automatically learning from neighbors or other sources. A 570 new access point should learn the capability of its neighboring APs. 571 This automatic learning process enables plug and play capability 573 4.3.3 Local-mobility Protocol in Different ADs 575 The local mobility domain can have one-to-one mapping to the 576 administrative domain. In this deployment case, a handover between 577 two ADs requires change of the routable IP address of the mobile 578 node. In this case a macro-mobility protocol, such as Mobile IP, is 579 needed inter-domain handover. 581 A local mobility domain can span multiple ADs if a trust 582 relationship exists between them allowing the use of the same 583 routable IP address across ADs. 585 4.4 Summary 587 AD Administrative Domain 588 MD Mobility Domain 589 SN Subnet 591 X -> Applicable 592 | intra-SN | inter-AD |inter-AD 593 |intra-tech|inter-tech|inter-SN|intra-MD|inter-MD 594 -------------------+----------+----------+--------+--------+-------- 595 inter-AP prot | X | | | | 596 local mobility prot| X | X | X | X | 597 Mobile-IP | X | X | X | X | X 599 |Inter-AP prot | local mob. Prot | MIP 600 ------------------------+--------------+-----------------+---------- 601 optimized route | X | X | 602 location confidentiality| X (1) | X (2) | X (3) 603 QoS Support | x (5) | X | 604 Context Transfer | x (5) | X | X (4) 605 Transparent | L3+ | L4+ | L4+ 606 Plug & Play | X | X | 608 (1)except for those participating in the inter-AP protocol in the 609 same subnet 610 (2)transparent at least to anyone outside of the MD 611 (3)transparent to the CN, and only if reverse tunneling is used 612 (4) proprietary at the moment 613 (5) may be redundant in some cases where the L2 provides similar/same 614 mechanisms. 616 5 Next Steps 618 It is proposed that the next steps be: 620 * Setting of requirements for local mobility 621 * Proposal of solutions 622 * Analysis of solutions 623 * Recommendation of micromobility solution 625 In the analysis, a critical piece will be to identify the 626 shortcomings of Mobile IP. 628 6 Security Considerations 630 This type of non-protocol document does not directly affect the 631 security of the Internet. 633 7 IANA Considerations 635 This document does not directly affect IANA. 637 8 Acknowledgments 639 The authors would like to thank Kulwinder Atwal, Peter Lei, Charlie 640 Perkins, Michael A. Ramalho, Philip Roberts, Luca Salgarelli, Hesham 641 Soliman, Michael Thomas, George Tsirtsis, and Mika Ylianttila for 642 their comments and contributions to this document. 644 9 Author's Addresses 646 John Loughney (editor) 647 Nokia Research Center 648 PO Box 407 649 FIN-00045 Nokia Group 650 Finland 651 john.loughney@nokia.com 653 Dana Blair 654 Cisco 655 dblair@cisco.com 657 Peter Hazy 658 Nortel Networks 659 100 Constellation Crescent 660 Nepean, ON K2G 6J8 661 Canada 662 Phone: 1-613-768-2969 664 Muhammad Jaseemuddin 665 Nortel Networks 666 100 Constellation Crescent 667 Nepean, ON K2G 6J8 668 Canada 669 Phone: 1-613-765-7520 670 jaseem@nortelnetworks.com 672 O. Henrik Levkowetz 673 A Brand New World 674 Osterogatan 1 675 S-164 28 Kista 676 Sweden 677 henrik.levkowetz@abrandnewworld.se 679 Hongyi Li 680 Nortel Networks 681 100 Constellation Crescent 682 Nepean, ON K2G 6J8 683 Canada 684 Phone: 1-613-763-5966 685 hyli@nortelnetworks.com 687 Jukka Manner 688 Department of Computer Science, University of Helsinki 689 P.O. Box 26 (Teollisuuskatu 23) 690 FIN-00014 Helsinki 691 FINLAND 692 jmanner@cs.Helsinki.fi 694 Phillip Neumiller 695 3Com Corporation 696 1800 W. Central Road 697 Mount Prospect IL 60056 698 USA 699 phil_neumiller@3com.com 701 Ram Ramjee, 702 Bell Labs, Lucent Technologies, 703 101 Crawfords Corner Road, 704 Holmdel, NJ 07733 705 USA 706 Phone: 1-732-949-3306 707 Fax: 1-732-949-4513 708 ramjee@bell-labs.com 710 Guilhem Tardy 711 Nortel Networks 712 100 Constellation Crescent 713 Nepean, ON K2G 6J8 714 Canada 715 Phone: 1-613-763-1953 717 guilhem.tardy@nortelnetworks.com 719 10 References 721 [2002] Perkins, C., "IP Mobility Support". Internet 722 Engineering Task Force, Request for Comments (RFC) 723 2002, October 1996. 725 [2460] Deering, S., and Hinden, R. (Editors); "Internet 726 Protocol, Version 6 (IPv6) Specification"; RFC 2460, 727 December 1998. 729 [2753] Yavatkar, R., Pendarakis, D., Guerin, R.; "A 730 Framework for Policy-based Admission Control"; RFC 731 2753; January 2000. 733 [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support 734 in IPv6", draft-ietf-mobileip-ipv6-12.txt, April 735 2000. 737 [SM Terms] Manner, J. et al; "Mobility Related Terminology"; 738 ; Work In 739 Progress; January 12, 2001. 741 [Fast MIP6] Tsirtsis, G. (Editor), "Fast Handovers for Mobile 742 IPv6", draft-ietf-mobileip-fast-mipv6-00.txt, a work 743 in progress; February 2001. 745 [DSR] Johnson, D. et al. "The Dynamic Source Routing 746 Protocol for Mobile Ad Hoc Networks"; ; Work in Progress; November 17, 748 2000. 750 [TORA] Park, V. et al. "Temporally-Ordered Routing Algorithm 751 (TORA) Version 1 Functional Specification"; ; Work in Progress; 753 November 24, 2000. 755 [2501] Corson, S.; Macker, J.; "Mobile Ad hoc Networking 756 (MANET): Routing Protocol Performance Issues and 757 Evaluation Considerations"; RFC 2501; January 1999. 759 [MIP RSVP] Thomas, M.; "Analysis of Mobile IP and RSVP 760 Interactions"; ; work in progress; February 12, 2001. 763 Full Copyright Statement 765 Copyright (C) The Internet Society (2000). All Rights Reserved. 767 This document and translations of it may be copied and furnished to 768 others, and derivative works that comment on or otherwise explain it 769 or assist in its implementation may be prepared, copied, published 770 and distributed, in whole or in part, without restriction of any 771 kind, provided that the above copyright notice and this paragraph 772 are included on all such copies and derivative works. However, this 773 document itself may not be modified in any way, such as by removing 774 the copyright notice or references to the Internet Society or other 775 Internet organizations, except as needed for the purpose of 776 developing Internet standards in which case the procedures for 777 copyrights defined in the Internet Standards process must be 778 followed, or as required to translate it into languages other than 779 English. 781 The limited permissions granted above are perpetual and will not be 782 revoked by the Internet Society or its successors or assigns. 784 This document and the information contained herein is provided on an 785 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 786 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 787 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 788 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 789 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.