idnits 2.17.1 draft-ietf-mobileip-ipm-arch-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 490, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-00 -- No information found for - is the name correct? == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-authent-04 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Carey B. Becker 3 Category: Informational Basvaraj Patil 4 Title: Emad Qaddoura 5 Date: September 1999 Nortel Networks 7 IP Mobility Architecture Framework 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 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 Today, the wireless network arena is made up of different types of 34 access (TDMA, CDMA, GSM, etc) and core network technologies (IS-41 35 and MAP over SS7, etc). The heterogeneous nature of today's 36 wireless and wireline packet data networks limits the scope of 37 mobility between these heterogeneous networks. However, as these 38 heterogeneous networks evolve, the mobility management provided by 39 them must evolve to insure seamless roaming between the networks. 41 With the convergence of voice and data, networks of the future will 42 be built on IP packet switched technology, mostly due to inherent 43 advantages offered by the technology. 45 This document identifies several drivers that provide input for an 46 IP Mobility based network and also describes a high level IP 47 Mobility architecture that extends the current third generation 48 IMT2000 wireless architecture and builds on Mobile IP concepts. 50 1. Introduction 52 User mobility is an integral part of today's and future wireless 53 and wireline packet data networks. Today, the wireless network 54 arena is made up of different types of access (TDMA, CDMA, GSM, 55 802.11, etc) and core network technologies (IS-41 and MAP over SS7, 56 etc.). The heterogeneous nature of today's wireless and wireline 57 packet data networks limits the scope of mobility between these 58 heterogeneous networks. However, as these heterogeneous networks 59 evolve, the mobility management provided by them must evolve to 60 ensure seamless roaming between the networks. 62 With the convergence of voice networks and data networks, networks 63 of the future will be built on IP packet switched technology, 64 mostly due to inherent advantages offered by the technology (the 65 details of which are beyond the scope of this document). The change 66 from the current SS7 based wireless networks to IP centric wireless 67 networks is already in the works. In the very near future, mobile 68 devices that support IP stacks will also proliferate. 70 The combination of these two concepts, the networks moving to IP 71 packet switched technology and the evolution of mobility management 72 to ensure seamless roaming, defines what we call IP Mobility. There 73 are several drivers that are paving the way for defining an 74 architecture that is IP Mobility enabled. Some of these are: 76 1. The network should allow for seamless roaming between 77 heterogeneous wireless and wireline networks. 79 2. The network infrastructure should be access independent. 81 As our wireless networks evolve, it will remain a fact of life 82 that we will need to support the multiple types of wireless 83 accesses, e.g., CDMA, TDMA, etc. Users should be able to roam 84 between these different access types via a mobile devices that 85 support access specific PC cards which provide the appropriate 86 'layer 2' access. However, the current networking protocols 87 that perform the mobility management functions specific to the 88 heterogeneous technologies can evolve into a single protocol. 90 3. Mobility needs to be based on the users, not the device used 91 by the user. 93 GSM already supports the concept of mobility being based on a 94 user via the International Mobile Subscriber Identity (IMSI), 95 although the IMSI is not known by the user. In North American 96 Cellular systems, e.g., TDMA, CDMA, etc, a user is identified 97 via a Mobile Identification Number (MIN) that is specific to 98 the mobile device. This association needs to be separated. 99 Also, both of these concepts are based on users being assigned 100 'telephony' user IDs, which are solely based on digits. User 101 IDs should not be restricted to digit only identifiers or 102 restricted to the realm of telephony IDs. 104 4. A roaming user should only need a single subscription to 105 access a home network. 107 Within the scope of packet data services being defined for 108 CDMA systems, a user must have a subscription with a cellular 109 provider to gain access to the cellular network. After which 110 the user is authenticated, the user's mobile device is put on 111 a traffic channel to allow the user's mobile IP subscription 112 to be authenticated with the users home network. The multiple 113 subscriptions translate to multiple unwanted registrations and 114 a waste of radio resources for the second registration. 116 5. The network should support the removal of triangle routes 117 within the network. 119 Triangle routes (which contain routing anchor point) can be 120 established at two points, 1) at the home network as defined 121 in mobile IP [2] and 2) at the foreign network as proposed in 122 [4] and [5]. The network needs to support a mechanism, similar 123 to what is defined in [6], which can alleviate the anchor 124 points. The network needs to support policies that allow or 125 disallow triangle routes, e.g., a policy that wants to hide 126 knowledge of where the user is located. 128 6. Service providers would like to deploy the same network 129 infrastructure in both their wireline and wireless networks. 131 One of the major business drivers is to gain economies of 132 scale from deploying the same network infrastructure, e.g., 133 network operation, services platforms, etc, within the service 134 provider's networks that is independent of the access 135 networks. However, mechanisms should be provided that will 136 allow the networks to be optimized on the type of access 137 network. 139 None of the current packet data technologies, GPRS, Mobile IP and 140 CDPD, support all the concepts depicted in the above drivers. An 141 architecture must be defined that can provide the functions that 142 insure true seamless roaming within a mobility enabled IP network. 144 2. IP Mobility Architecture 146 To be able to achieve a mobility enabled IP network that satisfies 147 the drivers stated in the previous section, an enhanced 148 architecture needs to be defined that extends the current third 149 generation IMT2000 wireless architecture and mobile IP. This 150 section defines such an architecture. 152 The intent of defining this architecture is to stimulate discussion 153 on the merits of its components. The transition strategies required 154 by the packet data technologies to evolve to this architecture are 155 outside the scope of this document. However, it is an important 156 item that should be addressed as part of the work group 157 discussions. 159 The architecture described in this draft is not complete. It does 160 not include some necessary concepts; one example being 161 brokers/proxies as described in [7] and [8]. However, it does 162 contain a substantial subset of what is needed to provide mobility 163 within IP networks. 165 2.1. Network Reference Model 167 The following figure depicts the logical view of the proposed 168 network architecture. 170 + -----------------------------------------------------------+ 171 | +-----+ +------+ +-----------+ +----------------+ | 172 | | DNS | | DHCP | | Unified | | Authentication | | 173 | +-----+ +------+ | Directory | | Server | | 174 | +-----------+ +----------------+ | 175 | | Home 176 | +------------+ +----------+ +------+ | Network 177 | | Mobility | | Security | | AAA+ | | 178 | | Mgmt (HA+) | | Gateway | +------+ | 179 | +------------+ +----------+ | 180 + -----------------------------------------------------------+ 181 | | IP network 182 | | 183 + -----------------------------------------------------------+ 184 | +------------+ +----------+ +------+ +------+ | 185 | | Mobility | | Security | | AAA+ | | DHCP | | Foreign 186 | | Mgmt (FA+) | | Gateway | +------+ +------+ | Network 187 | +------------+ +----------+ | 188 + -----------------------------------------------------------+ 189 || 190 || 191 + -----------------------------------------------------------+ 192 | +----------+ +-----------+ +-----------+ | 193 | | Location | | Cell Site | . . . | Cell Site | | Access 194 | | Tracking | +-----------+ +-----------+ | Network 195 | +----------+ | 196 + -----------------------------------------------------------+ 198 Figure 1: Network Reference Model 200 The following sections describe the functionality of the components 201 of the network reference model. 203 2.2. Home Network 205 The Home Network is very similar in concept to the home network 206 defined in [2[ and the home network defined in the wireless 207 networks. Basically, the Home network is a combination of the two 208 with some extensions. 210 Some of the relevant functions of the Home Network as they relate 211 to mobility are: 213 * It is the home network that 'owns' the mobile user's 214 subscription. 216 * Maintains the mobile user's subscription and associated 217 subscriber profile. 219 * Provides mobility to subscribers on a 'larger' scale. It is 220 responsible for maintaining the current location of the mobile 221 user. 223 * Allocation of mobile node IP addresses 225 * Supports a 'unified' directory for subscriber profiles 226 independent of the access network type. 228 * Stores policies and profiles associated with mobile users. 230 * Provides Authorization functions associated with the mobile 231 user. 233 * May provide the Authentication functions required to 234 authenticate the mobile users. 236 * Support Service Level Agreements (SLA) with all Foreign 237 Networks it wants its users to roam in. 239 * Support a policy that allows 'hiding' the user's location. 240 This policy will mandate that the home be an anchor point for 241 datagrams sent to it's users while they are roaming. 243 2.2.1. Home Network Mobility Components 245 The following describes some functions associated with the 246 components of the Home network. 248 * Mobility Management (MM) 250 Mobility management is comprised of two high level concepts, 251 1) mobile user location tracking and 2) performing routing 252 update functions for mobile nodes. These functions are very 253 similar to what Home Agents do in [2] and what Home Location 254 Registers do in wireless networks, with some enhancements. The 255 location tracking function of the MM expects to receive a 256 single mobile user registration message from the foreign 257 networks that is independent of the access network used at the 258 foreign network. This is true for all messages sent from the 259 foreign networks to the home networks. The architecture 260 supports the concept of a centralized location tracking 261 function for the home network. However, the architecture does 262 not preclude the idea of having a distributed location 263 tracking function. 265 * AAA+ 267 The protocol used to send messages between a foreign network 268 and a home network is the AAA protocol, with extensions to 269 support mobility management (hence AAA+). Another important 270 concept used within the AAA+ framework is that the AAA+ 271 between a foreign network and a home network. This single 272 security association can be used to alleviate the need for 273 security associations between mobile IP FA and HA components 274 and dynamic session key establishment as suggested in [2] and 275 [4]. It is suggested that the security framework be based on 276 IPSec. 278 * Authentication Server 280 The authentication server is a combination of certificate 281 authority, key management system, and digital signature 282 verification server. The authentication server receives 283 roaming mobile user authentication requests via the AAA+ and 284 authenticates the user. 286 * Unified Directory 288 The Unified Directory is the database that contains all the 289 home user's subscriber profiles, network policies, and any 290 other data that needs to be stored at the Home Network. The 291 subscriber profiles in the directory are independent of the 292 access network association. Access to data in the Unified 293 Directory from other components within the network is via a 294 single protocol, LDAP. 296 * DHCP 298 In the Home Network, the DHCP server may be used to assign IP 299 addresses to roaming mobile stations that do not have a 300 permanently configured IP. 302 * DNS 304 In the home network, Dynamic DNS is the protocol used to 305 update DNS with a roaming user's mobile node allocated IP 306 address. If the home network is responsible for allocating the 307 IP address, DNS is updated by DHCP. If the foreign network is 308 responsible for allocating the IP address, the home network 309 mobility manager will update DNS. 311 * Security gateway 313 The security gateway performs all the necessary 'firewall' 314 functions. 316 2.3. Foreign Network 318 The Foreign Network is very similar in concept to the foreign 319 network defined in [2] and the foreign network defined in the 320 wireless networks. Basically, the Foreign Network is a combination 321 of the two with some extensions. 323 Some of the relevant functions of the Foreign Network as they 324 relate to mobility are: 326 * It is the serving area network for one or more access 327 networks. 329 * It can support multiple Access Networks, where each AN is 330 associated with a different technology, e.g. one AN may be a 331 CDMA RAN, another AN may be GSM RAN. 333 * Provides mobility management for mobility within the access 334 networks that it serves. 336 * Provides local services. 338 * Routes data to the mobile user via the access link that the 339 mobile node is currently attached to. 341 * Routes data that is sent by the mobile user. 343 * Allocates IP address to be used by the mobile nodes if allowed 344 by policy. 346 * Support for the establishment of Service Level Agreements 347 (SLA) with all Home Networks that want to allow their user to 348 roam within the foreign network. 350 * Support for user authentication to be provided by at the 351 foreign network after the user initially registers. 353 2.3.1. Foreign Network Mobility Components 355 The following describes some functions associated with the 356 components of the Foreign Network. 358 * Mobility Management (MM) 360 Foreign Network's mobility management is comprised to three 361 high level concepts, mobile user location tracking within the 362 foreign network, handoffs between foreign networks, and 363 performing routing update functions for datagram delivery to 364 the access network/mobile node. These functions are very 365 similar to what Foreign Agents do in [2], with some 366 enhancements. The location tracking function of the MM expects 367 to receive the same formatted mobile user registration message 368 from each of the heterogeneous access network. The 369 architecture supports the concept of a centralized location 370 tracking function within for the foreign network. However, the 371 architecture does not preclude the idea of having a 372 distributed location tracking function. 374 * AAA+ 376 The protocol used to send messages between a foreign network 377 and a home network is the AAA protocol, with extensions to 378 support mobility management (hence AAA+). Another important 379 concept used within the AAA+ framework is that the AAA+ 380 between a foreign network and a home network. This single 381 security association can be used to alleviate the need for 382 security associations between mobile IP FA and HA components 383 and dynamic session key establishment. It is suggested that 384 the security framework be based on IPSec. 386 * DHCP 388 In the Foreign Network, the DHCP server may be used to 1) 389 assign co-located care of addresses to private network mobile 390 nodes and 2) if policies indicate, assign IP addresses to 391 roaming mobile stations that do not have a permanently 392 configured IP. 394 * Security Gateway 396 The security gateway performs all the necessary 'firewall' 397 functions. It supports ESP IPSec security associations with 398 other network security gateways. 400 2.4. Access Network 402 The Access Network defines the 'layer 2' access technology used by 403 a user to gain access to a Foreign Network. The access network can 404 be one of several types: 406 * North American Cellular and GSM radio access networks (and 407 their evolution to 3rd generation) 409 * 802.11 wireless LAN access 411 * 802.3 wireline LAN access 413 * Dial-up network access 415 Figure 1 above only depicts an access network associated with a 416 wireless network. 418 2.5. IP Network 420 The IP network provides the routing of datagrams between Home 421 Networks and Foreign Networks. The IP network can be the public 422 Internet or a closed network such as those defined in IMT2000 423 standards. 425 2.6. Mobile Nodes 427 It can be argued that all nodes in the future will be mobile, or at 428 least have the potential to be mobile. Stationary nodes, generally 429 called correspondent nodes in [2], will only have to be equipped 430 with the appropriate access specific PC card(s) and software that 431 can perform the network registration functions. 433 The mobile node's PC cards provide the 'layer 2' interface to the 434 specific access network. For each of the access network types, 435 there is a layer 2 address associated with the PC card so the 436 access network and mobile node are able to uniquely address each 437 other. Mobile node software will need to determine when and which 438 access networks are available and perform the appropriate 439 registration functions. 441 Both types of nodes will have to support tunneling, e.g., IP in IP 442 encapsulation [9], to a roaming mobile node's care-of addresses. 443 This will help alleviate the triangle routing (anchor points) 444 issue. 446 2.7. User Identification 448 The architecture suggests user identities be based the Network 449 Access Identifier (NAI) as defined in [1]. The NAI allows for a 450 highly flexible definition of a user which does not restrict user 451 identities to digits only. 453 3. Conclusion 455 The architecture defined in this document provides a foundation 456 that will allow true seamless roaming within a mobility enabled IP 457 network. 459 Some of the advantages provided by the architecture are: 461 * A user may have a single subscription with a home network that 462 allows for roaming within all foreign networks that have 463 service level agreements with the home network. 465 * Mobility being based on the user, not the device used by the 466 user. 468 * A single control plane network protocol based on AAA that can 469 be deployed in a provider's network independent of the access 470 network. 472 * A single security framework based on IPSec and used by the 473 AAA+ server to minimize other security associations and the 474 use of dynamic session keys. 476 * The ability to alleviate routing anchor points and support for 477 policies that allow the hiding of users by allowing routing 478 anchor points. 480 * Users to truly roam seamlessly between heterogeneous access 481 networks. 483 4. References 485 [1] B. Aboba, M. Beadles, "The Network Access Identifier" RFC 486 2486, January 1999. 488 [2] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. 490 [3] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Address 491 Allocation Extension", draft-ietf-mobileip-home-addr-alloc- 492 00.txt, November 1998. 494 [4] P. Calhoun P, C. Perkins, "Mobile IP Foreign Agent 495 Challenge/Response Extension", draft-ietf-mobileip-challenge- 496 00.txt, November 1998. 498 [5] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework", Internet- 499 Draft, draft- calhoun-diameter-framework-01.txt, August 1998 501 [6] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 502 Internet Draft, ietf- mobileip-optim-07.txt, November 1997. 504 [7] B. Aboba, et al, "Review of Roaming Implementations", RFC 505 2194, September 1997. 507 [8] P. Calhoun, W. Bulley, "DIAMETER User Authentication 508 Extensions", Internet- Draft, draft-calhoun-diameter-authent- 509 04.txt, July 1998 511 [9] W. Simpson, "IP in IP Tunneling", RFC 1853, October 1995. 513 5. Acknowledgements 515 The authors would like to thank Russ Coffin, Mary Barnes, and Lachu 516 Aravamudham of Nortel Networks and John Myhre of ATT Wireless 517 Services for their useful discussion. 519 6. Authors' Addresses 521 Carey B. Becker 522 Nortel Networks Inc. 523 2201 Lakeside Blvd. 524 Richardson, TX. 75082-4399 526 Phone: 972-685-0560 527 email: becker@nortelnetworks.com 529 Basavaraj Patil 530 Nortel Networks Inc. 531 2201 Lakeside Blvd. 532 Richardson, TX. 75082-4399 534 Phone: 972-684-1489 535 email: bpatil@nortelnetworks.com 537 Emad Qaddoura 538 Nortel Networks Inc. 539 2201 Lakeside Blvd. 540 Richardson, TX. 75082-4399 542 Phone: 972-684-2705 543 email: emadq@nortelnetworks.com