idnits 2.17.1 draft-ietf-mobileip-cellularip-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 == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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. ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 459 has weird spacing: '...shed by all...' == Line 465 has weird spacing: '...ed when movi...' == Line 766 has weird spacing: '...ighbors inste...' -- 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 (January 2000) is 8861 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) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1305 (ref. '2') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1826 (ref. '3') (Obsoleted by RFC 2402) ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Campbell 2 J. Gomez 3 Expires July 2000 C-Y. Wan 4 S. Kim 5 Columbia University 6 Z. Turanyi 7 A. Valko 8 Ericsson 9 January 2000 11 Cellular IP 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document specifies a protocol that allows routing IP datagrams 37 to a mobile host. The protocol is intended to provide local mobility 38 and handoff support. It can interwork with Mobile IP [1] to provide 39 wide area mobility support. Four fundamental design principles of 40 the protocol are: (1) location information is stored in distributed 41 data bases (2) location information referring to a mobile host is 42 created and updated by regular IP datagrams originated by the said 43 mobile host (3) location information is stored as soft state (4) 44 location management for idle mobile hosts is separated from location 45 management of hosts that are actively transmitting or receiving data. 47 Table of Contents 49 1. Introduction 3 50 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. New Architectural Entities . . . . . . . . . . . . . . . 4 52 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 54 1.5. Location Management and Routing . . . . . . . . . . . . . 7 55 2. Cellular IP Functions 8 56 2.1. Location Management . . . . . . . . . . . . . . . . . . . 8 57 2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 2.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 2.4. Wide Area Mobility . . . . . . . . . . . . . . . . . . . 10 60 2.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 11 61 3. Protocol Details 11 62 3.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 11 63 3.2. Beacon Signal Structure . . . . . . . . . . . . . . . . . 12 64 3.3. Packet Formats . . . . . . . . . . . . . . . . . . . . . 12 65 3.3.1. Data packet . . . . . . . . . . . . . . . . . . . 12 66 3.3.2. Route-update packet . . . . . . . . . . . . . . . 12 67 3.3.3. Paging-update packet . . . . . . . . . . . . . . . 14 68 3.3.4. Paging-teardown packet . . . . . . . . . . . . . . 14 69 3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.6. Cellular IP Routing . . . . . . . . . . . . . . . . . . . 15 72 3.6.1. Topology . . . . . . . . . . . . . . . . . . . . . 15 73 3.6.2. Uplink Routing . . . . . . . . . . . . . . . . . . 15 74 3.6.3. Downlink Routing . . . . . . . . . . . . . . . . . 16 75 3.7. Cellular IP Gateway . . . . . . . . . . . . . . . . . . . 17 76 3.8. Cellular IP Mobile Host . . . . . . . . . . . . . . . . . 18 77 4. Extensions to Cellular IP 19 78 4.1. Semi-soft Handoff . . . . . . . . . . . . . . . . . . . . 19 79 4.2. Multiple Gateway Networks . . . . . . . . . . . . . . . . 20 80 4.3. Charging . . . . . . . . . . . . . . . . . . . . . . . . 20 81 5. Security Considerations 20 82 6. Intellectual Property Right Notice . . . . . . . . . . . . . . 20 83 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 85 APPENDIX A. Uplink Neighbor Selection . . . . . . . . . . . . . . 21 87 0. What's Changed 89 The following major improvements have been made to the protocol 90 compared to : 92 - Security support for Cellular IP has been added. 93 - Paging Areas have been introduced. As long as an idle mobile host 94 is moving inside a Paging Area, it is not necessary to transmit any 95 control packets. 96 - Semi-soft handoff has been introduced to improve handoff 97 performance. 98 - Each node maintains only one valid Route Cache mapping and only one 99 valid Paging Cache mapping for each mobile host. There is one 100 exception to this in the case of semisoft handoff. 102 In addition, the following minor changes have been made: 104 - Cache mappings can not be created or modified (but still can be 105 refreshed) by data packets. 106 - Paging-update packets remove Route Cache entries. 107 - An optional paging-teardown packet has been introduced that 108 explicitly removes Paging Cache mappings. 109 - The Base Station's beacon signal has been extended to include 110 Paging Area ID. 111 - The example algorithm in Appendix A. has been extended to 112 distribute Network ID, Gateway IP address and Paging Area IDs. 113 - Control packet format has been changed to ICMP. 114 - Control packets must contain timestamp and authentication 115 information. 116 - Cache mappings now contain timestamp information of the update 117 packet that created the mapping. 118 - Cache mappings also contain the MAC address of the downlink 119 Cellular IP node to allow multiple Cellular IP nodes to reside a 120 shared medium. The notion of Uplink and Downlink I/Fs has been 121 replaced by Uplink and Downlink neighbors. 123 1. Introduction 125 Hosts connecting to the Internet via a wireless interface are likely 126 to change their point of access frequently. A mechanism is required 127 that ensures that packets addressed to moving hosts are successfully 128 delivered with high probability. A change of access point during 129 active data transmission or reception is called a handoff. During or 130 immediately after a handoff, packet losses may occur due to delayed 131 propagation of new location information. These losses should be 132 minimized in order to avoid a degradation of service quality as 133 handoff become more frequent. 135 This memo specifies Cellular IP, a protocol that provides mobility 136 and handoff support for frequently moving hosts. It is intended to 137 be used on a local level, for instance in a campus or metropolitan 138 area network. Cellular IP can interwork with Mobile IP [1] to 139 support wide area mobility, that is, mobility between Cellular IP 140 Networks. 142 1.1. Applicability 144 Cellular IP supports local mobility, that is, mobility inside an 145 access network. To provide global mobility support, Mobile IP [1] 146 should be used in conjunction with Cellular IP. 148 Cellular IP is designed to support frequently migrating, rarely 149 moving or static hosts as well. 151 Cellular IP assumes that a random access L2 protocol covers the air 152 interface. 154 1.2. New Architectural Entities 156 Cellular IP Node 157 A Cellular IP Network consists of interconnected Cellular IP 158 nodes. The role of nodes is twofold. They route IP packets 159 inside the Cellular IP Network and communicate with mobile 160 hosts via a wireless interface. Referring to the latter role, 161 a Cellular IP node that has a wireless interface is also called 162 a Base Station. 164 Cellular IP Base Station 165 See Cellular IP node. 167 Cellular IP Gateway 168 A Cellular IP node that is connected to a regular IP network by 169 at least one of its interfaces. 171 Cellular IP Mobile Host 172 A mobile host that implements the Cellular IP protocol. 174 1.3. Terminology 176 Active Mobile Host 177 A mobile host is in active state if it is transmitting or 178 receiving IP packets. (Exact definition is given in Section 179 3.8.) 181 Cellular IP Network Identifier 182 A unique identifier assigned to Cellular IP Networks. 184 Control packet 185 Paging-update, paging-teardown and route-update packet. 187 Data packet 188 An IP packet that is not a control packet. 190 Downlink 191 Directed to a mobile host. 193 Downlink neighbor 194 All neighbors of a Cellular IP node except its Uplink neighbor 195 are referred to as Downlink neighbors. 197 Idle Mobile Host 198 A mobile host is in idle state if it has not recently 199 transmitted or received IP packets. (Exact definition is given 200 in Section 3.8.) 202 Internet 203 A Cellular IP Network provides access to a regular IP network. 204 This IP network in this memo is referred to as "Internet", but 205 it can also be a corporate intranet, for example. 207 Neighbor 208 One Cellular IP node is said to be the neighbor of another if 209 they are connected directly. Neighbors are identified in a 210 Cellular IP node by interface and MAC address. 212 Paging Area 213 A set of Base Stations. Idle mobile hosts crossing cell 214 boundaries within a Paging Area do not need to transmit control 215 packets to update their position. (Exact definition is given in 216 Section 2.1.) 218 Paging Cache 219 A cache maintained by some Cellular IP nodes, used to route 220 packets to mobile hosts. 222 Paging-timeout 223 Validity time of mappings in Paging Caches. 225 Paging-update packet 226 A control packet transmitted by Cellular IP mobile hosts in 227 order to update Paging Cache. 229 Paging-update-time 230 Time between consecutive paging-update packets. 232 Paging-teardown packet 233 A control packet transmitted by Cellular IP mobile hosts in 234 order to explicitly disconnect from the Cellular IP Network. 236 Route-timeout 237 Validity time of mappings in Route Cache. 239 Route-update packet 240 A control packet transmitted by Cellular IP mobile hosts in 241 order to update Route Cache. 243 Route-update-time 244 Time between consecutive route-update packets. 246 Route Cache 247 A cache maintained by all Cellular IP nodes, used to route 248 packets to mobile hosts. 250 Update packet 251 Paging-update and route-update packet. 253 Uplink 254 Originated by a mobile host. 256 Uplink neighbor 257 The neighbor of a Cellular IP node which is the next hop on the 258 shortest path towards the Gateway. 260 1.4. Protocol Overview 261 The figure shown below presents a schematic view of multiple Cellular 262 IP Networks providing access to the Internet. 264 .............................................. 265 . . 266 . Internet Backbone with Mobile IP . 267 . . 268 .............................................. 269 / | \ 270 / | \ 271 +--+ +--+ +--+ 272 |GW| |GW| |GW| 273 +--+ +--+ +--+ 274 / | \ 275 +-------------+ +--------------------+ +-------------+ 276 | | | | | | 277 | Cellular IP | | Cellular IP | | Cellular IP | 278 | Network | | Network | | Network | 279 | | | __ __ __ | | | 280 +-------------+ +-|BS|---|BS|---|BS|-+ +-------------+ 281 -- -- -- 283 + ... + 284 MH MH 286 In what follows, we present an overview of the operation of Cellular 287 IP, followed by a figure illustrating the functional entities that 288 comprise Cellular IP. 290 Base Stations periodically emit beacon signals. Mobile hosts use 291 these beacon signals to locate the nearest Base Station. A mobile 292 host can transmit a packet by relaying it to the nearest Base 293 Station. 295 All IP packets transmitted by a mobile host are routed from the Base 296 Station to the Gateway by hop-by-hop shortest path routing, 297 regardless of the destination address. 299 Cellular IP nodes maintain Route Cache. Packets transmitted by the 300 mobile host create and update entries in each node's Cache. An entry 301 maps the mobile host's IP address to the neighbor from which the 302 packet arrived to the node. 304 The chain of cached mappings referring to a single mobile host 305 constitutes a reverse path for downlink packets addressed to the same 306 mobile host. As the mobile host migrates, the chain of mappings 307 always points to its current location because its uplink packets 308 create new and change old mappings. 310 IP packets addressed to a mobile host are routed by the chain of 311 cached mappings associated with the said mobile host. 313 To prevent its mappings from timing out, a mobile host can 314 periodically transmit control packets. Control packets are ICMP 315 packets with specific authentication payloads. 317 Mobile hosts that are not actively transmitting or receiving data but 318 want to be reachable for incoming packets, let their Route Cache 319 mappings time out but maintain Paging Cache mappings. IP packets 320 addressed to these mobile hosts will be routed by Paging Caches. 321 Paging Caches have a longer timeout value than Route Caches and are 322 not necessarily maintained in every node. 324 +--------+ 325 |host in | 326 |Internet| 327 +--------+ 328 | Internet 329 | -------------------------- 330 +--------+ Cellular IP Network 331 |Cell. IP| 332 |Gateway | 333 +--------+ 334 | 335 - : 336 | : 337 | :\___________ Uplink neighbor 338 A network of | | (=shortest path 339 | +--------+ toward Gateway) 340 Cellular IP | |Cellular| 341 | |IP node | 342 nodes | +--------+ 343 | | ___________ Downlink neighbors 344 | :/ (=all other 345 - : neighbors) 346 : 347 | 348 +--------+ 349 uplink |Cellular| 350 ^ |IP node | 351 | +--------+ 352 | air | 353 | interface| 354 V +--------+ 355 downlink | Mobile | 356 | host | 357 +--------+ 359 1.5. Location Management and Routing 361 Cellular IP uses two parallel cache systems to store the information 362 related to the location of mobile hosts. The two systems basically 363 operate in the same way. This section is intended to clarify why we 364 use two distinct caches. 366 When a mobile host is in active state, the network must follow its 367 movement from Base Station to Base Station to be able to deliver 368 packets without searching for the mobile host. As a consequence 369 active mobile hosts must notify the network about each handoff. For 370 idle mobile hosts exact location tracking is less important, instead 371 mimizing communication to save battery is of higher priority. By 372 deploying two caches, the granularity of location tracking can be 373 different for idle and active mobile hosts. 375 Separating the location tracking for idle and active mobile hosts 376 also has a performance benefit. Supposing there is just one set of 377 cache, for each downlink packet the entire cache must be searched to 378 find the destination mobile host. It is expected, however, that only 379 a portion of the hosts will be in active state at any given time and 380 that most of the packets are destined for active mobile hosts. Thus 381 by separating the caches for active and idle mobile hosts only a 382 smaller cache needs to be searched for most of the packets. This 383 results in faster lookups and better scalability [5]. 385 2. Cellular IP Functions 387 2.1. Location Management 389 Cellular IP allows idle mobile hosts to roam large geographic areas 390 without the need to transmit location update packets at cell borders. 391 The network operator can group cells into Paging Areas, each 392 comprising of an arbitrary number of (typically adjacent) cells. 393 Each Paging Area has an identifier that is unique in the given 394 Cellular IP Network. Each Base Station transmits its Paging Area 395 Identifier in its periodic beacon signals, thus enabling mobile hosts 396 to notice when they move into a new Paging Area. 398 An idle mobile host that moves into a new Paging Area must transmit a 399 paging-update packet. Paging-update packets are routed from the Base 400 Station to the Gateway using hop-by-hop routing. Selected nodes of 401 the Cellular IP network are equipped with Paging Cache. These nodes 402 monitor passing paging-update packets and update Paging Cache 403 mappings to point toward the new Paging Area. Paging-update packets 404 reach the Gateway and are discarded there to isolate Cellular IP 405 specific operations from the Internet. 407 When the idle mobile host moves within a Paging Area, it transmits a 408 paging-update packet only when the system specific time, paging- 409 update-time expires. Outdated mappings of Paging Caches are cleared 410 if no update arrives before paging-timeout expires. 412 When an IP packet arrives at a Cellular IP node, addressed to a 413 mobile host for which no up-to-date Route Cache mapping is available, 414 the Paging Cache is used to route the packet. This is called 415 "implicit paging". If the node has no Paging Cache, it forwards the 416 packet to all Downlink neighbors. A node that has Paging Cache but 417 has no mapping in it for the destination mobile host discards the 418 packet. 420 On the path from the gateway to the mobile host there may be Cellular 421 IP nodes with and without Paging Cache. After the paging packet 422 leaves the last node which has a Paging Cache it is effectively 423 downlink broadcast by all nodes it passes. The set of cells that are 424 reached by the paging packet forms a Paging Area. The number, size 425 and population of Paging Areas in a Cellular IP network are 426 determined by the topology of the network and the placement of Paging 427 Caches. Based on the configuration of a Paging Area each base 428 station (with Paging Cache configured) could be considered an 429 autonomous Paging Area. The other extreme case is when a Cellular IP 430 Network has no Paging Cache configured in which case the complete 431 network represents a Paging Area where paging devolves to 432 broadcasting throughout the network. 434 When the mobile host receives the paging packet, it moves to active 435 state and creates its Route Cache mappings by sending a route-update 436 packet. Subsequent IP packets addressed to the same host will be 437 routed by Route Caches as long as the mobile host keeps the Route 438 Caches updated. 440 2.2. Routing 442 Packets transmitted by mobile hosts are routed to the Gateway using 443 shortest path hop-by-hop routing. Cellular IP nodes monitor these 444 passing data packets and use them to create and update Route Cache 445 mappings. These map mobile host IP addresses to Downlink neighbors 446 of the Cellular IP node. Packets addressed to the mobile host are 447 routed along the reverse path, on a hop-by-hop basis, by these Route 448 Cache mappings. 450 The structure and basic operation of routing is similar to that of 451 location management. To clarify the duality between the two, we 452 summarize the operation of Paging Caches and Route Caches in the 453 following table. For the reasons of separating the two functions, 454 see Section 1.7. 456 ---------------------------------------------------------------------- 457 Paging Caches Route Caches 458 ---------------------------------------------------------------------- 459 refreshed by all uplink packets (data, data and 460 paging-update, route-update) route-update packets 462 updated by all update packets route-update packets 463 (paging-update, route-update) 465 updated when moving to a new Paging moving to a new 466 Area, or after cell, or after 467 paging-update-time route-update-time 469 scope both idle and active MHs active mobile hosts 471 purpose route downlink packets if route downlink 472 there is no Route Cache entry packets 473 ---------------------------------------------------------------------- 475 The mobile host may keep receiving data packets without sending data 476 for possibly long durations. To keep its Route Cache mappings up to 477 date and to avoid repeated paging, mobile hosts in active state that 478 have no data to send must send periodic route-update packets. Like 479 uplink data packets, route-update packets update Route Caches and 480 ensure that the hop-by-hop route from the Gateway to the mobile host 481 does not time out. 483 In addition, active mobile hosts must transmit a route-update packet 484 when they cross cell borders. This is required because the Route 485 Cache mappings associated with the new Base Station can only be 486 created by authenticated route-update packets. Data packets are not 487 required to carry authentication information and hence can refresh, 488 but not modify Route Cache mappings. 490 For reliability and timeliness, Paging Caches also contain mobile 491 hosts that are contained by Route Caches. For this reason, Paging 492 Caches are updated by all uplink update packets and refreshed by all 493 uplink packets including data packets as well. 495 2.3. Handoff 497 Handoff is initiated by the mobile host. As an active host 498 approaches a new Base Station, it transmits a route-update packet and 499 redirects its packets from the old to the new Base Station. The 500 route-update packet will configure Route Caches along the way from 501 the new Base Station to the Gateway. (The paths leading to the old 502 and new Base Stations may overlap. In nodes where the two paths 503 coincide, the route-update packet simply refreshes the old mapping 504 and the handoff remains unnoticed.) 506 An idle mobile host, moving to a new Base Station, transmits a 507 paging-update packet only if the new Base Station is in a new Paging 508 Area. During handoffs between Base Stations within the same Paging 509 Area idle mobile hosts may remain silent, as paging is performed 510 within the entire Paging Area. 512 2.4. Wide Area Mobility 514 Wide area mobility occurs when the mobile host moves between Cellular 515 IP Networks. The mobile host can identify Cellular IP Networks by 516 the Cellular IP Network Identifier contained in the Base Stations' 517 beacon signals. The beacon signal also contains the IP address of 518 the Gateway. For security and charging purposes, authentication and 519 other user-related information may need to be provided by the mobile 520 host, when it first contacts a Cellular IP Network. This information 521 will be inserted in the payload of the first paging-update packet and 522 may be repeated in a few subsequent paging-update packets for 523 reliability. Upon receiving the first paging-update packet, the 524 Gateway performs admission control that may involve technical and 525 charging decisions. The Gateway's response is sent to the mobile 526 host in regular IP packet(s). If the request was accepted, the 527 response may also carry the required setting for protocol parameters. 528 After successful authentication to the Cellular IP network the mobile 529 host can send a Mobile IP registration message to its home agent, 530 specifying the Gateway's IP address as the care-of-address. 531 (Alternatively, the Gateway can register at the Home Agent on behalf 532 of the mobile host.) 534 The mobile host may leave the service area at any time without prior 535 notice. Mappings associated to the host will be cleared after the 536 timeout. Alternatively, as a performance optimization the host may 537 send a paging-teardown packet to clear Cache mappings from both Route 538 and Paging Caches. 540 2.5. Security 542 Cellular IP control packets (paging-update, route-update and paging- 543 teardown packets) carry mandatory authentication information. This 544 prevents malicious mobile hosts from changing location information 545 related to other mobile hosts using a spoofed source address; details 546 of the authentication mechanism can be found in Section 3.5. 548 Data security issues are not discussed in this document. We note 549 that any further authentication or encryption can be performed in 550 addition to control packet authentication built into Cellular IP. 552 3. Protocol Details 554 3.1. Protocol Parameters 556 The following parameters shall be set by network management. The 557 values listed here are for information only. Note that in the most 558 typical case a mobile host that is in active state will regularly 559 transmit data packets and hence route-update packets will need to be 560 transmitted at handoffs only. 562 ------------------------------------------------------------------- 563 Name Meaning Typical Value 564 ------------------------------------------------------------------- 565 route-update-time Maximal inter-arrival time 3 sec 566 of packets updating the 567 Route Cache 569 route-timeout Validity of Route 9 sec 570 Cache mappings 572 paging-update-time Maximal inter-arrival time 3 min 573 of packets updating the 574 Paging Cache 576 paging-timeout Validity of Paging 9 min 577 Cache mappings 578 ------------------------------------------------------------------- 580 3.2. Beacon Signal Structure 582 Cellular IP Base Stations must periodically transmit beacon signals 583 to allow for mobile hosts to identify an available Base Station. 584 Information elements carried by the beacon signal include: 586 - Layer2 parameters related to the Base Station; 587 - the Cellular IP Network Identifier; 588 - the IP address of the Gateway; and 589 - the ID of the Paging Area. 591 All parameters can be configured by network management. As an 592 alternative, in Appendix A we present an example algorithm for 593 automatically distributing the Cellular IP Network Identifier, the IP 594 address of the Gateway and the Paging Area IDs to Base Stations. 596 3.3. Packet Formats 598 3.3.1. Data packet 600 Cellular IP forwards regular IP packets without modification, 601 segmentation, encapsulation or tunneling. 603 3.3.2. Route-update packet 605 A route-update packet is an ICMP packet where 607 - the source address is the IP address of the sending mobile host; 608 - the destination address is the Gateway; and 609 - the type is Cellular IP Control Packet and the code is Route-update. 611 The payload of the route-update packet carries authentication and 612 control information in the following format: 614 0 1 2 3 615 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | 618 | Timestamp (64 bits long) | 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | CU |S| AType | Auth. Length | CU | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 | Authentication (variable length) | 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 | Control information (variable length) | 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Timestamp Contains a timestamp used to determine the order 633 in which update packets are sent. The timestamp 634 field is formatted as specified by the Network 635 Time Protocol [2]. The low-order 32 bits of the 636 NTP format represent fractional seconds, and those 637 bits which are not available from a time source 638 should be generated from a good source of 639 randomness. Mobile hosts must ensure that the 64 640 bit value of timestamps is strictly increasing in 641 consecutive control packets. 643 CU Currently Unused. Must be set to 0. 645 S flag Set to 1 to indicate semi-soft handoff. Default 646 value is 0. Any Cellular IP node that does not 647 support semi-soft handoffs may ignore this bit. 648 (See Section 4.1.) 650 AType Denotes the authentication method used. The 651 default authentication method is described in [4]. 652 All authentication methods must utilize the 653 timestamp field. 655 Auth. Length Denotes the length of the authentication 656 information in bytes. 658 Authentication Contains the authentication information. 660 Alternatively the Authentication Header [3] could also be used for 661 authenticating control packets. This issue is for further study. 663 Control information is encoded in the following Type-Length-Value 664 format: 666 0 1 2 667 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 669 | Type | Length | Data ... | Type ... 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 672 Type Indicates the particular type of control information. 674 Length Indicates the length (in bytes) of the following data 675 field within. The length does not include the Type and 676 Length bytes. 678 Data This field may be zero or more bytes in length. The 679 meaning, format and length of the data field is 680 determined by the Type and Length fields. 682 Currently the following type of control information is defined 683 (details are for further study): 685 Registration request 686 Used when a mobile host enters the Cellular IP Network. 688 3.3.3. Paging-update packet 690 A paging-update packet is an ICMP packet where 692 - the source address is the IP address of the sending mobile host; 693 - the destination address is the Gateway; and 694 - the type is Cellular IP Control Packet and the code is Paging-update. 696 The payload of the paging-update packet carries authentication and 697 control information in the same format as the route-update packet. 698 The S flag must be 0 for paging-update packets. 700 3.3.4. Paging-teardown packet 702 A paging-teardown packet is a ICMP packet where 704 - the source address is the IP address of the sending mobile host; 705 - the destination address is the Gateway; and 706 - the type is Cellular IP Control Packet and the code is Paging-teardown. 708 The payload of the paging-teardown packet carries authentication and 709 control information in the same format as the route-update packet. 710 The S flag must be 0 for paging-teardown packets. 712 3.4. Addressing 714 Cellular IP requires no address space allocation beyond what is 715 present in IP. Mobile hosts are identified by their home IP 716 addresses. 718 3.5. Security 720 Each Cellular IP Network has a secret network key of arbitrary length 721 known to all Cellular IP nodes. The network key is kept secret from 722 mobile hosts and other nodes outside the Cellular IP Network, 723 however. Upon initial registration the Gateway must authenticate and 724 possibly authorize the mobile host. This initial authentication and 725 authorization can be based on any known symmetric or asymmetric 726 method. After authentication the Gateway concatenates the key of the 727 network and the IP address of the mobile host and calculates the PID 728 of the mobile host by an MD5 Hash similarly as in [4]: 730 PID := MD5(network key, IP address of MH) 732 Then it acquires the public key of the mobile host from a trusted 733 party, encrypts the PID and sends it to the mobile host. This way 734 the mobile host and the Cellular IP network have a shared secret. 735 The PID remains the same during handoff and can be easily computed by 736 each Base Station. 738 The PID can be used to authenticate (and optionally to encrypt) IP 739 packets over the air interface. Authentication is performed by 740 creating a short hash from the (PID, timestamp, packet content) 741 triple that is placed into the transmitted packets. The validity of 742 each packet can be easily checked by any Base Station even 743 immediately after a handoff and without prior communication with the 744 mobile host or with the old Base Station. 746 In addition to authenticating control packets, PID can optionally 747 also be used to provide security for data packets transmitted over 748 the wireless link. To this avail, any known shared secret based 749 security mechanism can be used where PID serve as the shared secret. 751 3.6. Cellular IP Routing 753 Cellular IP nodes need only to implement the algorithm described in 754 this section. They do not need regular IP routing capability. This 755 section describes the routing algorithm in Cellular IP nodes other 756 than the Gateway. The extra functions required only in the Cellular 757 IP Gateway are described in Section 3.7. 759 3.6.1 Topology 761 In uplink direction (toward the Gateway), packets are routed in the 762 Cellular IP Network on a hop-by-hop basis. The neighbor to which a 763 node will forward a packet toward the Gateway is referred to as the 764 node's Uplink neighbor. The Uplink neighbor at each node may be 765 designated by network management. Alternatively, a simplified 766 shortest path algorithm can select Uplink neighbors instead of 767 manual configuration. (A regular shortest path algorithm is also 768 applicable but is more complex than required since it determines 769 routes to all nodes in the network.) A simple algorithm that 770 configures Uplink neighbors and automatically reconfigures them if 771 necessary after a topology change is described in Appendix A. 773 A node's neighbors other than the Uplink neighbor are called Downlink 774 neighbors. 776 3.6.2 Uplink Routing 778 A packet arriving at a node from one of its Downlink neighbors is 779 assumed to be coming from a mobile host. The packet is first used to 780 update the node's Route and Paging Caches and is then forwarded to 781 the node's Uplink neighbor. 783 To update the Caches, the node reads the packet type, port number and 784 the source IP address. Paging-update packets update the Paging Cache 785 only. Route-update packets update both Route and Paging Caches. 786 Data packets only refresh the soft state of both caches, but do not 787 change it. Both types of caches consist of 789 { IP-address, interface, MAC address, expiration time, timestamp } 791 5-tuples, called mappings. The IP address is the address of the 792 mobile host the mapping corresponds to. The interface and the MAC 793 address denote the Downlink neighbor toward the mobile host. The 794 timestamp field contains the timestamp of the control packet that has 795 established the mapping. 797 When a data packet arrives from a Downlink neighbor, the Route Cache 798 entry of the source IP address is searched first. If the data packet 799 is coming from the same neighbor as indicated by the cache entry then 800 it is sent from the direction where the mobile host was last seen. 801 In that case the mapping is only refreshed: the expiration time is 802 set to the current time + route-timeout. If the node has Paging 803 Cache, then the expiration time of the mapping in the Paging Cache is 804 set to current time + paging-timeout as well. Then the packet is 805 forwarded to the uplink. 807 If the data packet arrived from a different neighbor than that is in 808 its mapping or no mapping exists for the IP address, then the packet 809 is dropped. 811 When an update packet arrives from a Downlink neighbor then the 812 authentication is first validated. Packets with invalid 813 authentication must be dropped and the event should be logged as a 814 potential tampering attempt. For valid packets the node creates the 815 following 5-tuple: 817 { the newly arrived packet's source IP address, 818 the interface through which it arrived, 819 the source MAC address of the arrived packet, 820 current time + route-timeout, 821 the timestamp in the arrived update packet } 823 This mapping is used to update Route Cache, if the incoming packet is 824 a route-update packet. If a valid mapping for the source IP address 825 already exists, then it is replaced by the new 5-tuple, if the 826 timestamp is newer, otherwise the packet is dropped. If no mapping 827 exists for the source IP address then the mapping is added to the 828 Route Cache. The Paging Cache is updated in the same way, but using 829 paging-timeout instead of route-timeout. If the node has no Paging 830 Cache then only the Route Cache is updated. If the incoming packet 831 is a paging-update, then only the Paging Cache is updated (if any). 833 If the packet is a paging-teardown packet and the authentication 834 information is valid, then mappings of the mobile host with timestamp 835 earlier than the timestamp of the packet are removed from both the 836 Route and the Paging Cache. 838 After cache modifications the control packet is forwarded to the 839 Uplink neighbor. 841 3.6.3 Downlink Routing 843 A packet arriving to a Cellular IP node from the Uplink neighbor is 844 assumed to be addressed to a mobile host. The node first checks if 845 the destination IP address has a valid mapping in the Route Cache. 846 If such a mapping exists, the packet is forwarded to the Downlink 847 neighbor found in the mapping. 849 If the Route Cache contains no mapping for the destination IP address 850 and the node has no Paging Cache, then the packet is broadcast on all 851 interfaces of the node except the interface of the Uplink neighbor. 853 If the node has Paging Cache and there is a mapping for the 854 destination IP address, then the packet is forwarded to the neighbor 855 found in that mapping. 857 If the node has Paging Cache, but there is no mapping for the 858 destination IP address, then the packet is dropped. 860 3.7. Cellular IP Gateway 862 The following figure is a schematic view of a Cellular IP Gateway. 863 The Gateway can logically be divided into three building blocks: a 864 regular Cellular IP node, a Gateway Packet Filter and a Gateway 865 Controller. 867 IP network 868 =================== 869 | 870 +------------------------------|--------+ 871 | | | 872 | +----------+ +-------------+ | 873 | | Gateway |__________| Gateway | | 874 | |Controller| |Packet Filter| | 875 | +----------+ +-------------+ | 876 | |\_______|___Uplink neighbor 877 | | | 878 | +-------------+ | 879 | Cellular IP | Cellular IP | | 880 | Gateway | node | | 881 | +-------------+ | 882 | | | | | 883 +-------------------------|----|----|---+ 884 <----Downlink neighbors 886 Uplink packets update the Route and/or Paging Caches in the Cellular 887 IP node block and are forwarded towards the Gateway filter. The 888 Gateway filter reads the destination IP address. If this is the 889 Gateway's address, the packet is forwarded to the Gateway controller. 890 Most of these packets are control packets with empty control 891 information field and are immediately dropped. If the packet carries 892 control information, for instance a registration request, it is 893 interpreted and processed by the Gateway controller. 895 If the destination address is not the Gateway's, the packet is 896 forwarded to the Internet. (This means that a packet sent from a 897 mobile host to another mobile host in the same Cellular IP Network 898 goes through the destination Home Agent. However, this is not the 899 case if route optimization is used. To operate efficiently even 900 without Mobile IP route optimization, the Gateway Packet Filter can 901 also check if the destination address of an uplink packet has a valid 902 mapping in any of the Gateway's caches. If a mapping is found, the 903 packet is "turned back" and is treated as a downlink packet.) 905 Packets arriving from the Internet (using Mobile IP) to mobile hosts 906 in the Cellular IP Network are decapsulated and forwarded to the 907 Cellular IP node block. Arriving packets not using Mobile IP are 908 assumed to be sent to mobile hosts of which this Cellular IP Network 909 is the home network. If no foregin registration shows that the 910 mobile host is away, these packets are forwarded to the Cellular IP 911 node block unchanged. 913 The Gateway's Cellular IP node block treats these packets as 914 determined by the Cellular IP Routing algorithm (Section 3.5) 915 according to the mappings in Route and Paging Cache. It is optional 916 whether Cellular IP Nodes have Paging Cache configured or not. 917 However, it is recommended that at least the Gateway's Cellular IP 918 node has Route Cache configured. This ensures that packets addressed 919 to hosts currently not connected to the Cellular IP Network do not 920 enter the network and do not load it in vain but are immediately 921 discarded in the Gateway when neither Route, nor Paging Cache mapping 922 is found for the destination address. (It may be advantageous to 923 also generate an ICMP message in this case and send it back to the 924 packet's source address.) 926 3.8. Cellular IP Mobile Host 928 While connected to a Cellular IP Network, a mobile host must be in 929 one of two states: 'active' or 'idle'. The host moves from idle to 930 active state when it receives or wishes to send a data packet. 931 Active state is maintained as long as the host is transmitting or 932 receiving data packets. When the host has not received or 933 transmitted any data packets for some time (the value of this timer 934 may be implementation-specific) then it returns to idle state. 936 When the host moves from idle to active state, it must transmit a 937 route-update packet. At the same time, a timer is initiated from a 938 value equal to route-update-time. If the timer expires without any 939 data packet being transmitted from the host, again a route-update 940 packet is transmitted and the timer is re-initiated. Any IP packet 941 transmitted before the timer expires, resets the timer to route- 942 update-time. This ensures that while the mobile host is in active 943 state, the largest interval between two transmitted packets is never 944 longer than route-update-time. The mechanism also ensures that if 945 data packets are transmitted with sufficient frequency, no route- 946 update packets will be generated, which will probably be typical. 948 If the host is in active state, it must immediately transmit a 949 route-update packet whenever it connects to a new base station. This 950 typically happens at migration, but is also the case after a wireless 951 channel black-out or when the host enters the Cellular IP Network. A 952 packet transmitted this way also resets the route-update packet 953 timer. 955 In idle state, the mobile host must transmit paging-update packets 956 periodically, at intervals of paging-update-time. In addition, the 957 host must transmit a paging-update packet when it connects to a new 958 Base Station which has a different Paging Area ID from the previous 959 Base Station. (When connecting to a Base Station that belongs to the 960 same Paging Area as the previous one, the host need not transmit 961 paging-update packet.) Similarly to the route-update packet timer, 962 the paging-update timer is reset if a data packet is transmitted. 964 The mobile host must ensure that the 64 bit value of timestamps is 965 strictly increasing in consecutive control packets. 967 4. Extensions to Cellular IP 969 4.1. Semi-soft Handoff 971 When a mobile host switches to a new Base Station it sends a route- 972 update packet to make the chain of cache bindings to point to the new 973 Base Station. Packets that are traveling on the old path will be 974 delivered to the old Base Station and will be lost. Although this 975 loss may be small it can potentially degrade TCP throughput. This 976 kind of handoff, when the mobile switches all at once to the new Base 977 Station is called "hard" handoff. For performance details of hard 978 handoff in a Cellular IP network see [5]. 980 To improve the performance of loss sensitive applications, another 981 type of handoff may be introduced, called "semi-soft" handoff. 982 During semi-soft handoff a mobile host may be in contact with either 983 of the old and new Base Stations and receive packets from them. 984 Packets intended to the mobile host are sent to both Base Stations, 985 so when the mobile host eventually moves to the new location it can 986 continue to receive packets without interruption. 988 To initiate semi-soft handoff, the moving mobile host transmits a 989 route-update packet to the new Base Station and continues to listen 990 to the old one. The S flag is set in this route-update packet to 991 indicate semi-soft handoff. Semi-soft route-update packets create 992 new mappings in the Route and Paging Cache similarly to regular 993 route-update packets. When the semi-soft route-update packet reaches 994 the cross-over node where the old and new path meet (note that the 995 cross-over node already has a mapping for the mobile host), the new 996 mapping is added to the cache instead of replacing the old one. 997 Packets sent to the mobile host are transmitted to both Downlink 998 neighbors. When the mobile host eventually makes the move then the 999 packets will already be underway to the new Base Station and the 1000 handoff can be performed with minimal packet loss. After migration 1001 the mobile host sends a route-update packet to the new Base Station 1002 with the S bit cleared. This route-update packet will remove all 1003 mappings in Route Cache except for the ones pointing to the new Base 1004 Station. The semi-soft handoff is then complete. 1006 If the path to the new Base Station is longer than to the old Base 1007 Station or it takes non negligible time to switch to the new Base 1008 Station, then some packets may not reach the mobile host. To 1009 overcome the problem, packets sent to the new Base Station can be 1010 delayed during the semi-soft handoff. This way a few packets may be 1011 delivered twice to the mobile host, but in many cases this results in 1012 better performance than a few packets lost. Introduction of packet 1013 delay can be best performed in the Cellular IP node that has multiple 1014 mappings for the mobile host as a result of a semi-soft route-update 1015 packet. Packets that belong to flows that require low delay but can 1016 tolerate occasional losses should not be delayed. For performance 1017 details of semi-soft handoff in a Cellular IP network see [5]. 1019 4.2. Multiple Gateway Networks 1021 Cellular IP requires that a mobile host be using exactly one Gateway 1022 at a time. This requirement comes from the fact that the Gateway 1023 serves as the mobile host's Foreign Agent and it relays its packets 1024 both up and downlink. It is also required to make uplink routing 1025 unambiguous. The Cellular IP Network can have multiple Gateways as 1026 long as a single host still uses just one Gateway at any time. (The 1027 host can change Gateway, involving a Mobile IP location updating.) 1028 In a Network with multiple Gateways, nodes must be able to determine 1029 which Gateway a given mobile host is using. Assignment of Gateways 1030 can, for instance, be based on geographical partitioning of the 1031 network, or on partitioning the mobile hosts' address space. This 1032 issue is for further study. 1034 4.3. Charging 1036 Cellular IP Network providers can charge Cellular IP Mobile users for 1037 connectivity or for transmitted data or both. Charging information 1038 is best collected in the Gateway. The Gateway receives all control 1039 packets and can determine the time a mobile host was connected to the 1040 network. It can also measure through traffic in both directions. 1042 5. Security Considerations 1044 A Cellular IP Network is a single administrative domain. It is 1045 connected to the Internet through a Gateway that may eventually also 1046 serve as a firewall. Hence security issues only need to be 1047 considered at the wireless interface. 1049 The security of a Cellular IP system will be determined by the 1050 wireless link. Security issues relating to wireless links are not 1051 specific to Cellular IP, and are out of the scope of Cellular IP, 1052 even though they must be dealt with in practical Cellular IP 1053 implementations. 1055 A security problem specific to Cellular IP is the security of the 1056 control packets, which can be solved by the authentication mechanism 1057 described in Section 3.5. 1059 6. Intellectual Property Right Notice 1061 This is to affirm that Telefonaktiebolaget LM Ericsson and its 1062 subsidiaries, in accordance with corporate policy, will offer patent 1063 licensing for submissions rightfully made by its employees which are 1064 adopted or recommended as a standard by your organization as follows: 1066 If part(s) of a submission by Ericsson employees is (are) included in 1067 a standard and Ericsson has patents and/or patent application(s) that 1068 are essential to implementation of such included part(s) in said 1069 standard, Ericsson is prepared to grant - on the basis of reciprocity 1070 (grantback) - a license on such included part(s) on reasonable, non- 1071 discriminatory terms and conditions. 1073 Ericsson has filed patent applications that might possibly become 1074 essential to the implementation of this contribution. 1076 References 1078 [1] "IP Mobility Support," C. Perkins, ed., IETF RFC 2002, October 1079 1996. 1081 [2] "Network Time Protocol (Version 3): Specification, Implementation 1082 and Analysis," D. Mills, IETF RFC 1305, March 1992. 1084 [3] "IP Authentication Header," R. Atkinson, IETF RFC 1826, August 1085 1995. 1087 [4] "IP Authentication using Keyed MD5," P. Metzger, W. Simpson, IETF 1088 RFC 1828, August 1995. 1090 [5] "Cellular IP Performance," A. T. Campbell, J. Gomez, S. Kim, Z. 1091 Turanyi, A. Valko, C-Y Wan, Work in Progress, , October 1999. 1094 Authors' Addresses 1096 Andrew T. Campbell, Javier Gomez, Sanghyo Kim, Chieh-Yih Wan 1097 Department of Electrical Engineering, Columbia University 1098 Rm. 801 Schapiro Research Building 1099 530 W. 120th Street, New York, N.Y. 10027 1100 phone: (212) 854 3109 1101 fax : (212) 316 9068 1102 email: {campbell,javierg,shkim2,wan}@comet.columbia.edu 1104 Zoltan R. Turanyi, Andras G. Valko 1105 Ericsson Traffic Analysis and Network Performance Laboratory 1106 H-1300 Bp.3.P.O.Box 197, Hungary 1107 phone: +36 1 437 7774 1108 fax : +36 1 437 7219 1109 email: {zoltan.turanyi,andras.valko}@eth.ericsson.se 1111 Appendix A. Uplink Neighbor Selection 1113 This algorithm selects the Uplink neighbor of all nodes of a Cellular 1114 IP Network and reconfigures them if necessary after a change of 1115 topology. An Uplink neighbor is identified by the interface through 1116 which it is accessible from the node and its corresponding MAC 1117 address. The algorithm also distributes the Cellular IP Network 1118 Identifier, the IP address of the Gateway and the Paging Area IDs to 1119 the Base Stations. 1121 The Gateway periodically creates a control packet called a "Gateway 1122 broadcast packet". The Gateway broadcast packet contains 1124 - the Cellular IP Network Identifier; 1125 - the IP address of the Gateway; 1126 - a sequence number increased each time by the Gateway; and 1127 - a Paging Area ID field initially set to the ID of the Gateway. 1129 The Gateway broadcasts the packet on all of its interfaces except 1130 those connected to the Internet. A Cellular IP node receiving a 1131 Gateway broadcast packet follows the steps below. 1133 1) It drops the packet if the sequence number is lower or equal to 1134 the sequence number of one of the previously received Gateway 1135 broadcast packets. In this case no further processing is needed. 1136 2) It stores the sequence number of the Gateway broadcast packet for 1137 later comparison. 1138 3) It stores the Cellular IP Network Identifier and the IP address of 1139 the Gateway. 1140 3) It stores the interface through which the packet arrived together 1141 with source MAC address of the packet (if any) to identify the 1142 Uplink neighbor. All other interface/MAC address combinations 1143 will denote Downlink neighbors. 1144 4) If the node has a Paging Cache, it overwrites the value of the 1145 Paging Area ID field in the packet by its own ID. 1146 5) The value of the (possibly overwritten) Paging Area ID field is 1147 stored as the Paging Area ID of the node. This value will be used 1148 in beacon signals if the node is a Base Station. 1149 6) It stores the Cellular IP Network Identifier and the IP address of 1150 the Gateway. These values will be used in beacon signals if the 1151 node is a Base Station. 1152 7) After a short random delay, the node broadcasts the packet through 1153 all of its interfaces, except the air interface(s) and the 1154 interface of the Uplink neighbor.