idnits 2.17.1 draft-valko-cellularip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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. ** 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: ---------------------------------------------------------------------------- -- 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 (November 1998) is 9286 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) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Valko 3 Ericsson, Columbia University 4 A. Campbell, J. Gomez 5 Columbia University 6 Expires May 1999 November 1998 8 Cellular IP 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id- abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this memo is unlimited. 30 Abstract 32 This document specifies a protocol that allows routing IP datagrams 33 to a mobile host. The protocol is intended to provide local mobility 34 and handoff support. It can interwork with Mobile IP [1] to provide 35 wide area mobility support. Four fundamental design principles of 36 the protocol are: (1) location information is stored in distributed 37 data bases (2) location information referring to a mobile host is 38 created and updated by regular IP datagrams originated by the said 39 mobile host (3) location information is stored as soft state (4) 40 location management for idle mobile hosts is separated from location 41 management of hosts that are actively transmitting or receiving data. 43 Table of Contents 45 1. Introduction 2 46 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 3 47 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 49 1.4. New Architectural Entities . . . . . . . . . . . . . . . 3 50 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.6. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 52 1.7. Location Management and Routing . . . . . . . . . . . . . 7 53 2. Cellular IP Functions 8 54 2.1. Location Management . . . . . . . . . . . . . . . . . . . 8 55 2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 2.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 2.4. Wide Area Mobility . . . . . . . . . . . . . . . . . . . 10 58 2.5. Handling Wireless Channel Black-outs . . . . . . . . . . 10 59 3. Protocol Details 11 60 3.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 11 61 3.2. Beacon Signal Structure . . . . . . . . . . . . . . . . . 11 62 3.3. Packet Formats . . . . . . . . . . . . . . . . . . . . . 11 63 3.3.1. Data packet . . . . . . . . . . . . . . . . . . . 11 64 3.3.2. Route-update packet . . . . . . . . . . . . . . . 11 65 3.3.3. Paging-update packet . . . . . . . . . . . . . . . 12 66 3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.5. Cellular IP Routing . . . . . . . . . . . . . . . . . . . 13 68 3.6. Cellular IP Gateway . . . . . . . . . . . . . . . . . . . 14 69 3.7. Cellular IP Mobile Host . . . . . . . . . . . . . . . . . 15 71 APPENDIX A. Security Issues . . . . . . . . . . . . . . . . . . . . 16 72 APPENDIX B. Network Planning and Performance . . . . . . . . . . . 17 73 APPENDIX C. Multiple Gateway Systems . . . . . . . . . . . . . . . 18 74 APPENDIX D. Charging . . . . . . . . . . . . . . . . . . . . . . . 18 75 APPENDIX E. Uplink I/F Selection . . . . . . . . . . . . . . . . . 18 76 References 19 77 Authors' Addresses 19 79 1. Introduction 81 Hosts connecting to the Internet via wireless interface are likely to 82 change their point of access frequently. A mechanism is required 83 that ensures that packets addressed to moving hosts are successfully 84 delivered with high probability. A change of access point during 85 active data transmission or reception is called a handoff. During or 86 immediately after a handoff, packet losses may occur due to delayed 87 propagation of new location information. These losses should be 88 minimized in order to avoid a degradation of service quality as 89 handoffs become more frequent. 91 This memo specifies Cellular IP, a protocol that provides mobility 92 and handoff support for frequently moving hosts. It is intended to 93 be used on a local level, for instance in a campus or metropolitan 94 area network. Cellular IP can interwork with Mobile IP [1] to 95 support wide area mobility, that is, mobility between Cellular IP 96 Networks. 98 1.1. Protocol Requirements 100 A host connected to a Cellular IP Network must be able to send IP 101 datagrams to hosts outside the Cellular IP Network. 103 IP datagrams arriving to a Cellular IP Network, addressed to a host 104 connected to this Cellular IP Network, should be delivered with high 105 probability to the host regardless of its actual location. 107 IP datagrams generated by one host in the Cellular IP Network 108 addressed to another host in the Cellular IP Network should be 109 delivered to the destination without leaving the Cellular IP Network. 111 A mobile host migrating between Cellular IP Networks must be able to 112 use Mobile IP [1] for wide area mobility. Upon entering a Cellular 113 IP Network, it must be able to provide its home agent with a care- 114 of-address that ensures that its packets are routed to this Cellular 115 IP Network. 117 Mobile hosts migrating inside or between Cellular IP Networks must be 118 able to retain their own home IP addresses regardless of location. 119 Hosts inside a Cellular IP Network are identified by IP addresses, 120 but these addresses have no location significance. 122 Hosts outside the Cellular IP Network must not need any updating or 123 enhancements in order to communicate with hosts inside the Cellular 124 IP Network. Nodes sending or receiving datagrams to/from the mobile 125 host must remain unaware of the host's location inside the Cellular 126 IP Network. 128 1.2. Assumptions 130 Cellular IP assumes that a random access L2 protocol covers the air 131 interface. 133 1.3. Applicability 135 Cellular IP is applicable to networks ranging in size from LANs to 136 metropolitan area networks. To provide global mobility support, 137 Mobile IP [1] should be used above Cellular IP. 139 Cellular IP is designed to support frequently migrating hosts but 140 with appropriate setting of protocol parameters, it can also 141 efficiently serve rarely moving or even static hosts. 143 1.4. New Architectural Entities 145 Cellular IP Node 146 A Cellular IP Network consists of interconnected Cellular IP 147 Nodes. The role of Nodes is twofold. They route IP packets 148 inside the Cellular IP Network and communicate with Mobile 149 Hosts via wireless interface. Referring to the latter role, a 150 Cellular IP Node that has a wireless interface is also called a 151 Base Station. 153 Cellular IP Base Station 154 See Cellular IP Node. 156 Cellular IP Gateway 157 A Cellular IP Node that is connected to a regular IP network by 158 at least one of its interfaces. 160 Cellular IP Mobile Host 161 A Mobile Host that implements the Cellular IP protocol. 163 1.5. Terminology 165 Active Mobile Host 166 A Mobile Host is in active state if it is transmitting or 167 receiving IP packets. (Exact definition is given in section 168 3.7.) 170 Active-state-timeout 171 The time a Cellular IP Mobile Host remains in active state 172 without receiving IP packets. 174 Cellular IP Network Identifier 175 A unique identifier assigned to Cellular IP Networks. 177 Control packet 178 Paging-update and Route-update packet. 180 Data packet 181 An IP packet that is not a control packet. 183 Downlink 184 Directed to a Mobile Host. 186 Downlink interface (I/F) 187 All interfaces of a Cellular IP Node except its Uplink I/F are 188 referred to as Downlink I/Fs. 190 Idle Mobile Host 191 A Mobile Host is in idle state if it has not recently 192 transmitted or received IP packets. (Exact definition is given 193 in section 3.7.) 195 Internet 196 A Cellular IP Network provides access to a regular IP network. 197 This IP network in this memo is referred to as "Internet". 199 Paging Cache 200 A cache maintained by some Cellular IP Nodes, used to route 201 packets to Mobile Hosts. 203 Paging-timeout 204 Validity time of mappings in Paging Caches. 206 Paging-update packet 207 A control packet transmitted by Cellular IP Mobile Hosts in 208 order to update Paging Cache. 210 Paging-update-time 211 Time between consecutive Paging-update packets. 213 Route-timeout 214 Validity time of mappings in Routing Caches. 216 Route-update packet 217 A control packet transmitted by Cellular IP Mobile Hosts in 218 order to update Routing Cache. 220 Route-update-time 221 Time between consecutive Route-update packets. 223 Routing Cache 224 A cache maintained by all Cellular IP Nodes, used to route 225 packets to Mobile Hosts. 227 Uplink 228 Originated by a Mobile Host. 230 Uplink I/F 231 The interface used by a Cellular IP Node to forward packets 232 towards the Gateway. 234 1.6. Protocol Overview 236 The figure shown below presents a schematic view of multiple Cellular 237 IP Networks providing access to the Mobile IP enabled Internet. 239 .............................................. 240 . . 241 . Internet Backbone with Mobile IP . 242 . . 243 .............................................. 244 / | \ 245 / | \ 246 +--+ +--+ +--+ 247 |GW| |GW| |GW| 248 +--+ +--+ +--+ 249 / | \ 250 +-------------+ +--------------------+ +-------------+ 251 | | | | | | 252 | Cellular IP | | Cellular IP | | Cellular IP | 253 | Network | | Network | | Network | 254 | | | __ __ __ | | | 255 +-------------+ +-|BS|---|BS|---|BS|-+ +-------------+ 256 -- -- -- 258 + ... + 259 MH MH 261 In the following, we present an overview of the operation of Cellular 262 IP, followed by a figure illustrating the functional entities that 263 comprise Cellular IP. 265 Base Stations periodically emit beacon signals. Mobile Hosts use 266 these beacon signals to locate the nearest Base Station. A Mobile 267 Host can transmit a packet by relaying it to the nearest Base 268 Station. 270 All IP packets transmitted by a Mobile Host are routed from the Base 271 Station to the Gateway by hop-by-hop shortest path routing, 272 regardless of the destination address. 274 Cellular IP Nodes maintain Routing Cache. Packets transmitted by the 275 Mobile Host create and update entries in each Node's Cache. An entry 276 maps the Mobile Host's IP address to the interface through which the 277 packet entered the Node. 279 The chain of cached mappings referring to a single Mobile Host 280 constitutes a reverse path for downlink packets addressed to the same 281 Mobile Host. As the Mobile Host migrates, the chain always points to 282 its current location because its uplink packets create new mappings 283 and old mappings are automatically cleared after a soft state 284 timeout. After a migration, before the old mappings are cleared, a 285 Node can temporarily have mappings for the same Mobile Host to 286 multiple interfaces. (This causes the chain to temporarily have a 287 fork.) 289 IP packets addressed to a Mobile Host are routed by the chain of 290 cached mappings referring to the said Mobile Host. 292 To prevent its mappings from timing out, a Mobile Host can 293 periodically transmit control packets. Control packets are regular 294 IP packets with empty payloads. 296 Mobile Hosts that are not actively transmitting or receiving data but 297 want to be reachable for incoming packets, let their Routing Cache 298 mappings time out but maintain Paging Cache mappings. IP packets 299 addressed to these Mobile Hosts will be routed by Paging Caches. 300 Paging Caches have a longer timeout value than Routing Caches and are 301 not necessarily maintained in every Node. 303 +--------+ 304 |host in | 305 |Internet| 306 +--------+ 307 | Internet 308 | -------------------------- 309 +--------+ Cellular IP Network 310 |Cell. IP| 311 |Gateway | 312 +--------+ 313 | 314 - : 315 | : 316 | : ___________ Uplink I/F 317 A network of | |/ (=shortest path 318 | +--------+ toward Gateway) 319 Cellular IP | |Cellular| 320 | |IP Node | 321 Nodes | +--------+ 322 | |\___________ Downlink I/F 323 | : (=all other 324 - : interfaces) 325 : 326 | 327 +--------+ 328 uplink |Cellular| 329 ^ |IP Node | 330 | +--------+ 331 | air | 332 | interface| 333 V +--------+ 334 downlink | Mobile | 335 | Host | 336 +--------+ 338 1.7. Location Management and Routing 340 Cellular IP uses two parallel cache systems to store the information 341 related to the location of Mobile Hosts. The two systems basically 342 operate in the same way. This section is intended to clarify why we 343 use two distinct caches. 345 Supposing there is just one set of cache, the following trade-off 346 determines the optimal time cached mappings remain valid. After a 347 Mobile Host performs a handoff, its path to the old Base Station will 348 remain valid until the cached mappings associated with this Base 349 Station are cleared. If in this period packets are sent to the Host, 350 they are routed not only to its current location, but also to the old 351 Base Station. This results in a waste of resources. The waste is 352 especially large if the Mobile Host performs a number of handoffs 353 within the validity time of the mappings. In this case the system 354 approaches a broadcasting based communication system and becomes 355 inefficient. This kind of waste can be minimized by selecting a 356 small timeout interval, typically in the order of packet time scale. 358 On the other hand, in order to maintain mappings, Mobile Hosts must 359 send control packets with a periodicity comparable to the mappings' 360 validity time. If the validity time is in the order of packet time 361 scale, control packets must be transmitted at this time scale even by 362 idle Mobile Hosts which similarly results in a large load generated 363 by control packets making the system inefficient. 365 Separating the caches for active and idle Mobile Hosts allows us to 366 specify two optimal time scales for these operational states. More 367 specifically, active Hosts have mappings in Routing Caches. These 368 mappings remain valid for a short time, associated with the packet 369 time scale. Therefore Active Hosts need to send IP packets 370 relatively frequently; that is, when they have no data to send they 371 send control packets. In contrast, idle Hosts have mappings in 372 Paging Caches. These mappings remain in caches for longer time, in 373 the host mobility time scale. Therefore the frequency at which idle 374 Hosts must send control packets is relatively low, comparable to the 375 frequency of migrations. This load is not significantly higher than 376 explicit migration signalling would impose on the system. 378 2. Cellular IP Functions 380 2.1. Location Management 382 Idle mobile hosts periodically transmit Paging-update packets to keep 383 Paging Cache mappings up-to-date. These Paging-update packets update 384 Paging Cache mappings but not Routing Cache mappings. Paging-update 385 packets reach the Gateway and are discarded there to isolate Cellular 386 IP specific operations from the Internet. 388 As the idle Mobile Host moves, it always sends its Paging-update 389 packets to the nearest Base Station, forcing Paging Caches to point 390 at its up-to-date location. Outdated mappings are cleared after a 391 system specific time, paging-timeout. 393 When an IP packet arrives at a Cellular IP Node, addressed to a 394 Mobile Host for which no up-to-date Routing Cache mapping is 395 available, the Paging Cache is used to route the packet. This phase 396 is called "implicit paging". (In the case of explicit paging, this 397 packet is transformed into an explicit paging packet and all Nodes 398 route it using Paging Caches. This solution can provide some 399 advantages over implicit paging, however, this is for further study.) 400 If the Node has no Paging Cache, it forwards the packet to all 401 Downlink I/Fs. A Node that has Paging Cache but has no mapping in it 402 for the addressed Host discards the packet. 404 Upon receiving the packet, the Mobile Host moves to active state and 405 starts updating its Routing Cache mappings. Further IP packets 406 addressed to the same Host will be routed by Routing Caches as long 407 as the Mobile Host keeps the Routing Caches updated. 409 2.2. Routing 411 Packets transmitted by Mobile Hosts are routed to the Gateway using 412 regular hop-by-hop routing. Cellular IP Nodes monitor these passing 413 data packets and use them to create and update Routing Cache 414 mappings. These map Mobile Host IP addresses to Node interfaces. 415 Packets addressed to the Mobile Host are routed along the reverse 416 path, on a hop-by-hop basis, by these Routing Cache mappings. 418 The structure and basic operation of routing is the same as that of 419 location management. To clarify the duality between the two, we 420 summarize the operation of Paging Caches and Routing Caches in the 421 following table. For the reasons of separating the two functions, 422 see section 1.7. 424 ------------------------------------------------------------------- 425 Paging Caches Routing Caches 426 ------------------------------------------------------------------- 427 updated by all uplink packets (data, data and 428 Paging-update, Route-update) Route-update packets 430 scope both idle and active MHs active Mobile Hosts 432 purpose route downlink packets if route downlink 433 there is no Routing Cache entry packets 435 time scale mobility packet 436 ------------------------------------------------------------------- 438 The Mobile Host may keep receiving data packets without sending data 439 for possibly long durations. To keep its Routing Cache mappings up 440 to date and to avoid repeated paging, Mobile Hosts in active state 441 that have no data to send must send periodic Route-update packets. 442 Like uplink data packets, Route-update packets configure Routing 443 Caches and ensure that the hop-by-hop route from the Gateway to the 444 Mobile Host remains up-to-date. 446 For reliability and timeliness, Paging Caches also contain Mobile 447 Hosts that are contained by Routing Caches. For this reason, Paging 448 Caches are updated by all uplink packets including data and Route- 449 update packets. 451 2.3. Handoff 453 Handoff is initiated by the Mobile Host. As the Host approaches a 454 new Base Station, it redirects its packets from the old to the new 455 Base Station. The first of these redirected packets will configure 456 Routing Caches along the way from the new Base Station to the 457 Gateway. (The paths leading to the old and new Base Stations may 458 overlap. In Nodes where the two paths are the same, the new packets 459 simply refresh old mappings and the handoff remains unnoticed.) 461 For a time equal to the timeout of Routing Cache mappings, packets 462 addressed to the Host will be routed to both the old and new Base 463 Stations. After the timeout has elapsed the Routing Cache mappings 464 associated with the old Base Station will be automatically cleared. 465 After this time, packets addressed to the Mobile Host continue to be 466 delivered to the new Base Station only. 468 If the Mobile Host has no data packets to send at the time of 469 handoff, it generates and transmits a Route-update packet immediately 470 after moving to the new Base Station. This ensures that mappings are 471 created quickly with the result of minimizing the downlink packet 472 loss. 474 2.4. Wide Area Mobility 476 Wide area mobility occurs when the Mobile Host moves between Cellular 477 IP Networks. The Mobile Host can identify Cellular IP Networks by 478 the Cellular IP Network Identifier contained in the Base Stations' 479 beacon signals. The beacon signal also contains the IP address of 480 the Gateway. Technically, Cellular IP does not require that Mobile 481 Hosts register before using the Cellular IP Network. A Mobile Host 482 entering the service area can start transmitting Paging-update 483 packets configuring Paging Caches immediately. For security and 484 charging purposes, however, authentication and other user-related 485 information may need to be provided by the Mobile Host. This 486 information will be inserted in the payload of the first Paging- 487 update packet and may be repeated in a few following Paging-update 488 packets for reliability. Upon receiving the first Paging-update 489 packet, the Gateway performs admission control that may involve 490 technical and charging decisions. The Gateway's response is sent to 491 the Mobile Host in regular IP packet(s). If the request was 492 accepted, the response may also carry the required setting of 493 protocol parameters. The issues of authentication, billing and 494 security are for further study and are beyond the scope of this 495 Internet-Draft. 497 Once the registration is accepted, the Mobile Host can send a Mobile 498 IP registration message to its home agent, specifying the Gateway's 499 IP address as care-of-address. (Alternatively, the Gateway can 500 register at the Home Agent on behalf of the Mobile Host.) 502 The Mobile Host may leave the service area at any time without prior 503 notice. Mappings associated to the Host will be cleared after the 504 timeout. 506 2.5. Handling Wireless Channel Black-outs 508 Due to conditions in the wireless channel, Mobile Hosts may become 509 temporarily disconnected. A host that reappears after a black-out 510 can continue operation normally regardless of whether it reappeared 511 in the same cell or in another one. The first packets transmitted 512 (data or control) will configure or re-configure mappings in Routing 513 and/or Paging Caches. The network does not notice the black-out 514 except for the Base Station that discards packets addressed to the 515 unreachable Mobile Host. 517 3. Protocol Details 519 3.1. Protocol Parameters 521 The following parameters shall be set by network management. The 522 values listed here are for information only. Consideration of 523 selecting the proper values are discussed in Appendix B. 525 ------------------------------------------------------------------- 526 Name Meaning Typical Value 527 ------------------------------------------------------------------- 528 route-update-time Inter-arrival time 100 ms 529 of Route-update packets 530 route-timeout Validity of Routing 300 ms 531 Cache mappings 532 paging-update-time Inter-arrival time 1 min 533 of Paging-update packets 534 paging-timeout Validity of Paging 3 min 535 Cache mappings 536 active-state-timeout Time the Mobile Host 10 sec 537 remains in active state 538 without receiving data 539 ------------------------------------------------------------------- 541 3.2. Beacon Signal Structure 543 Cellular IP Base Stations must periodically transmit beacon signals 544 to allow for Mobile Hosts to identify an available Base Station. 545 Information elements carried by the beacon signal are: 547 - Layer2 parameters related to the Base Station; 548 - the Cellular IP Network Identifier; and 549 - the IP address of the Gateway. 551 3.3. Packet Formats 553 3.3.1. Data packet 555 Cellular IP forwards regular IP packets without modification, 556 segmentation, encapsulation or tunnelling. 558 3.3.2. Route-update packet 560 A Route-update packet is an IP packet of which 562 - the source address is the IP address of the sending Mobile Host; 563 - the destination address is the Gateway; and 564 - the protocol type is IPPROTO_CELLIPRU. 566 The payload of the Route-update packet may be empty. Optionally, 567 control information may be carried in the Route-update packet's 568 payload, encoded in the following Type-Length-Value format: 570 0 1 2 571 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 573 | Type | Length | Data ... | Type ... 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 576 Type Indicates the particular type of control information. 578 Length Indicates the length (in bytes) of the following data 579 field within. The length does not include the Type and 580 Length bytes. 582 Data This field may be zero or more bytes in length. The 583 meaning, format and length of the data field is 584 determined by the Type and Length fields. 586 Currently the following types of control information are defined 587 (details are for further study): 589 Registration request 590 Used when a Mobile Host enters the Cellular IP Network. 592 Authentication 593 Must be used when the Registration request field is present and 594 may be used at other times, too. For further study. 596 3.3.3. Paging-update packet 598 A Paging-update packet is an IP packet of which 600 - the source address is the IP address of the sending Mobile Host; 601 - the destination address is the Gateway; and 602 - the protocol type is IPPROTO_CELLIPPU. 604 The payload of the Paging-update packet may be empty. Optionally, 605 control information may be carried in the Paging-update packet's 606 payload, encoded in the following Type-Length-Value format: 608 0 1 2 609 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 611 | Type | Length | Data ... | Type ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- 614 Type Indicates the particular type of control information. 616 Length Indicates the length (in bytes) of the following data 617 field within. The length does not include the Type and 618 Length bytes. 620 Data This field may be zero or more bytes in length. The 621 meaning, format and length of the data field is 622 determined by the Type and Length fields. 624 Currently the following types of control information are defined 625 (details are for further study): 627 Registration request 628 Used when a Mobile Host enters the Cellular IP Network. 630 Authentication 631 Must be used when the Registration request field is present and 632 may be used at other times, too. For further study. 634 3.4. Addressing 636 Cellular IP requires no address space allocation beyond what is 637 present in IP. Mobile Hosts are identified by their home IP 638 addresses. 640 3.5. Cellular IP Routing 642 Cellular IP Nodes need only to implement the algorithm described in 643 this section. They do not need regular IP routing capability. This 644 section describes the routing algorithm in Cellular IP Nodes other 645 than the Gateway. The extra functions required only in the Cellular 646 IP Gateway are described in section 3.6. 648 In uplink direction (toward the Gateway), packets are routed in the 649 Cellular IP Network on a hop-by-hop basis. The interface through 650 which a Node will forward a packet toward the Gateway is referred to 651 as the Node's Uplink I/F. The Uplink I/F at each Node may be 652 designated by network management. Alternatively, a simplified 653 shortest path algorithm can select Uplink I/Fs. (A regular shortest 654 path algorithm is also applicable but is more complex than required 655 since it determines routes to all nodes in the network.) A simple 656 algorithm that configures Uplink I/Fs and automatically reconfigures 657 them if necessary after a topology change is described in Appendix E. 659 A Node's interfaces other than the Uplink I/F are called Downlink 660 I/Fs. A packet arriving to the Node through one of the Downlink I/Fs 661 is assumed to be coming from a Mobile Host. The packet is first used 662 to update the Node's Routing and Paging Caches and is then forwarded 663 through the Node's Uplink I/F. 665 To update the Caches, the Node reads the packet type (IPPROTO) and 666 the source IP address. Paging-update packets update the Paging Cache 667 only. Route-update and data packets update both Routing and Paging 668 Caches. Both types of caches consist of 670 { IP-address, interface, expiration time } 672 triplets, called mappings. To update the Routing Cache, the Node 673 creates the following triplet: 675 { the newly arrived packet's source IP address, 676 the interface through which it arrived, 677 current time + route-timeout 678 } 680 If a mapping existed in the Routing Cache with the same IP address 681 and the same interface, it is replaced by the new triplet. If such a 682 triplet did not exist, the new triplet is inserted in the cache. The 683 Paging Cache is updated in the same way, using paging-timeout instead 684 of route-timeout. If the Node has no Paging Cache then only the 685 Routing Cache is updated by Route-update and data packets and no 686 cache is updated by Paging-update packets. 688 A packet arriving to a Cellular IP Node through the Uplink I/F is 689 assumed to be addressed to a Mobile Host. The Node first checks if 690 the destination IP address has a valid mapping in the Routing Cache. 691 If such mapping(s) exist(s), the packet is forwarded to all 692 interfaces to which valid Routing Cache mappings were found. 694 If there are no valid Routing Cache mappings for the destination 695 address and the Node has a Paging Cache, the packet is routed 696 according to the Paging Cache as follows. It is forwarded to all 697 interfaces to which the destination IP address has valid Paging Cache 698 mapping. If the Node has Paging Cache but there are no valid 699 mappings, the packet is discarded. 701 If there are no valid Routing Cache mappings for the destination, and 702 the Node has no Paging Cache, the packet is forwarded to all Downlink 703 I/Fs. 705 3.6. Cellular IP Gateway 707 The following figure is a schematic view of a Cellular IP Gateway. 708 The Gateway can logically be divided into three building blocks: a 709 regular Cellular IP Node, a Gateway Packet Filter and a Gateway 710 Controller. 712 IP network 713 =================== 714 | 715 +------------------------------|--------+ 716 | | | 717 | +----------+ +-------------+ | 718 | | Gateway |__________| Gateway | | 719 | |Controller| |Packet Filter| | 720 | +----------+ +-------------+ | 721 | | _______|____Uplink I/F 722 | |/ | 723 | +-------------+ | 724 | Cellular IP | Cellular IP | | 725 | Gateway | Node | | 726 | +-------------+ | 727 | | | |\__|____Downlink I/Fs 728 +-------------------------|----|----|---+ 730 Uplink packets update the Routing and/or Paging Caches in the 731 Cellular IP Node block and are forwarded towards the Gateway filter. 732 The Gateway filter reads the destination IP address. If this is the 733 Gateway's address, the packet is forwarded to the Gateway controller. 734 Most of these packets are Route-update and Paging-update packets with 735 empty payload and are immediately dropped. If the packet carries 736 control information, for instance a registration request, it is 737 interpreted and processed by the Gateway controller. 739 If the destination address is not the Gateway's, the packet is 740 forwarded to the Internet. (This means that a packet sent from a 741 Mobile Host to another Mobile Host in the same Cellular IP Network 742 goes through the destination Home Agent. However, this is not the 743 case if route optimization is used. To operate efficiently even 744 without Mobile IP route optimization, the Gateway Packet Filter can 745 also check if the destination address of an uplink packet has a valid 746 mapping in any of the Gateway's caches. If a mapping is found, the 747 packet is "turned back" and is treated as a downlink packet.) 749 Packets arriving to the Gateway Packet Filter from the Internet can 750 be of the following types: 752 If the destination address is the Gateway and the packet is 753 tunnelled, it must be sent using Mobile IP. The packet is then 754 detunnelled and forwarded to the Cellular IP Node. 756 If the destination address is not the Gateway and the packet is an 757 IPv6 packet containing a routing header, it must be sent using 758 Mobile IP. The packet is then forwarded to the Cellular IP Node, 759 unchanged. 761 If the destination address is not the Gateway and the packet does 762 not contain a routing header, it is a regular IP packet addressed 763 to a Mobile Host of which this Cellular IP Network is the home 764 network. The packet is then forwarded to the Cellular IP Node, 765 unchanged. 767 The Gateway's Cellular IP Node block treats these packets as 768 determined by the Cellular IP Routing algorithm (section 3.5). The 769 packet is routed according to the Routing Cache if valid mapping(s) 770 exist(s) for the destination address and is routed according to the 771 Paging Cache otherwise. Though in Cellular IP Nodes it is optional 772 to have Paging Cache, it is recommended that the Gateway's Cellular 773 IP Node have one. This way, packets addressed to Hosts currently not 774 connected to the Cellular IP Network do not enter the network and 775 load it in vain but are immediately discarded in the Gateway when 776 neither Routing, nor Paging Cache mapping is found for the 777 destination address. (It may be advantageous to also generate a 778 warning message in this case and send it back to the packet's source 779 address.) 781 3.7. Cellular IP Mobile Host 783 While connected to a Cellular IP Network, a Mobile Host must be in 784 one of two states: 'active' or 'idle'. The Host moves from idle to 785 active state when it receives any IP packet. If it does not receive 786 more IP packets, it remains in active state for a time equal to 787 active-state-timeout. Any IP packet received in active state 788 restarts the active state timer. When the timer elapses, the Host 789 returns to idle state. 791 When the Host moves from idle to active state, it must transmit a 792 Route-update packet. At the same time, a timer is initiated from a 793 value equal to route-update-time. If the timer expires without any 794 data packet being transmitted from the Host, again a Route-update 795 packet is transmitted and the timer is re-initiated. Any IP packet 796 transmitted before the timer expires, resets the timer to route- 797 update-time. This ensures that while the Mobile Host is in active 798 state, the largest interval between two transmitted packets is never 799 longer than route-update-time. The mechanism also ensures that if 800 data packets are transmitted with sufficient frequency, no Route- 801 update packets will be generated. 803 In idle state, the Mobile Host must transmit Paging-update packets 804 periodically, at intervals of paging-update-time. Similarly to the 805 Route-update packet timer, the paging-update timer is reset if a data 806 packet is transmitted. (We recall that a transmitted IP packet does 807 not make the Mobile Host go to active state.) 809 Regardless of which state the Host is in, it must immediately 810 transmit an IP packet whenever it connects to a new base station. 811 This typically happens at migration, but is also the case after a 812 wireless channel black-out or when the Host enters the Cellular IP 813 Network. The packet transmitted this way is a Route-update packet if 814 the Host is active and a Paging-update packet if the Host is idle. 815 (If the Host has a data packet queued and ready for transmission, it 816 can send that packet instead of a control packet.) A packet 817 transmitted this way also resets the appropriate control packet 818 timer. 820 Appendix A. Security Issues 822 A Cellular IP Network is a single administrative domain. It is 823 connected to the Internet through a Gateway that may eventually also 824 serve as a firewall. Hence security issues only need to be 825 considered at the wireless interface. 827 The security of a Cellular IP system will be determined by the 828 wireless link. Cellular IP does not assume one specific wireless 829 link protocol. If the wireless link protocol does not include 830 encryption, a malicious user can listen to the traffic of other users 831 even without being connected to the Cellular IP network. By 832 transmitting packets with a false source address, a host can also 833 imitate another host and thus creating false traffic. These security 834 issues appear in all wireless IP systems and are not specific to 835 Cellular IP, however, they must also be dealt with in Cellular IP. 837 A security problem specific to Cellular IP is that a malicious host, 838 by transmitting packets with a false source address, can redirect 839 packets addressed to another user. In normal circumstances, this 840 will not prevent the real addressee from receiving the packet, since 841 the malicious host will only add new routing entries but not remove 842 existing route entries. However, this and other attacks will need to 843 be addressed in an operational Cellular IP Network. 845 The following is a list of possible security protection mechanisms. 847 Encrypted wireless link. 848 This is probably the only strategy that can give full 849 protection. For high security, the encryption code must be 850 user-specific. The code can be agreed upon when the Mobile 851 Host enters the network. This, however, allows malicious hosts 852 to listen to the code decision procedure. To prevent this, the 853 Gateway can obtain the code (or part of it) from the Mobile 854 Host's home agent. 856 Authentication 857 The Mobile Host can be required to provide authentication 858 information upon entering the Cellular IP Network. If it has 859 no security binding with the network, the Gateway will use the 860 Mobile Host's home agent to check the validity of the 861 authentication. 863 Packet filtering in Gateway 864 To ensure that Mobile Hosts that have not registered 865 successfully can not use the Cellular IP Network, the Gateway 866 can filter regular data packets and discard those that do not 867 belong to an authorized user. 869 Appendix B. Network Planning and Performance 871 To adapt the system to actual traffic and mobility characteristics, 872 the operator of a Cellular IP Cellular IP Network can set the 873 following system parameters: 875 route-timeout 876 Will typically be a small multiple of the route-update-time. 878 route-update-time 879 Will typically be on the packet time scale. Higher values 880 would result in less frequent Route-update packet 881 transmissions, but it also increases the route-timeout. This 882 extends the time a route is valid after the Mobile Host moves 883 away and hence increases network load. 885 paging-timeout 886 Will typically be a small multiple of the paging-update-time. 888 paging-update-time 889 Will typically be on the host mobility time scale. Higher 890 values would result in less frequent Paging-update packets, but 891 it also increases the paging-timeout. This extends the time 892 Paging Cache mappings associated with the old location remain 893 valid after the Mobile Host moves away and hence increases the 894 cost of paging. 896 active-state-timeout 897 The value should be such that short pauses between bursts do 898 not cause the Mobile Host to go idle. Too high a value would 899 result in transmitting Route-update packets in vain for a long 900 time. 902 Paging Cache population 903 Paging Caches need not be maintained in all nodes. The 904 operator is free to select the nodes that maintain Paging 905 Caches and will typically select nodes with many downlink I/Fs. 907 Appendix C. Multiple Gateway Systems 909 Cellular IP requires that a Mobile Host be using exactly one Gateway 910 at a time. This requirement comes from the fact that the Gateway 911 serves as the Mobile Host's Foreign Agent and it relays its packets 912 both up and downlink. It is also required to make uplink routing 913 unambiguous. The Cellular IP Network can have multiple Gateways as 914 long as a single Host still uses just one Gateway at any time. (The 915 Host can change Gateway, involving a Mobile IP location updating.) 916 In a Network with multiple Gateways, Nodes must be able to determine 917 which Gateway a given Mobile Host is using. Assignment of Gateways 918 can, for instance, be based on geographical partitioning of the 919 network, or on partitioning the Mobile Hosts' address space. This 920 issue is for further study. 922 Appendix D. Charging 924 Cellular IP Network providers can charge Cellular IP Mobile users for 925 connectivity or for transmitted data or both. Charging information 926 is best collected in the Gateway. The Gateway receives all control 927 packets and can determine the time a Mobile Host was connected to the 928 network. It can also measure through traffic in both directions. 930 Appendix E. Uplink I/F Selection 932 This algorithm selects Uplink I/Fs in all Nodes of a Cellular IP 933 Network and reconfigures them if necessary after a change of 934 topology. 936 The Gateway periodically creates a control packet called a 937 "Gateway broadcast packet". The Gateway broadcast packet contains 938 a sequence number increased each time by the Gateway. The Gateway 939 transmits the packet through all of its interfaces except those 940 connected to the Internet. A Cellular IP Node receiving a Gateway 941 broadcast packet sets as Uplink I/F the interface through which 942 the packet arrived and denotes all other interfaces as Downlink 943 I/Fs, including the air interface if there is one. The Node 944 stores the sequence number of the Gateway broadcast packet. After 945 a short random delay, the Node forwards the packet through all of 946 its Downlink I/Fs, except the air interface. The Node ignores 947 further Gateway broadcast packets with the same sequence number, 948 but repeats the procedure if one arrives with a higher sequence 949 number. 951 References 953 [1] "IP Mobility Support," C. Perkins, ed., IETF RFC 2002, October 954 1996. 956 Authors' Addresses 958 Andras G. Valko 959 Ericsson Traffic Analysis and Network Performance Laboratory 960 Center for Telecommunications Research, Columbia University 961 H-1300 Bp.3.P.O.Box 197, Hungary 962 phone: +36 1 437 7774 963 fax : +36 1 437 7219 964 email: andras.valko@lt.eth.ericsson.se, andras@comet.columbia.edu 966 Andrew T. Campbell, Javier Gomez 967 Department of Electrical Engineering, Columbia University 968 Rm. 801 Schapiro Research Building 969 530 W. 120th Street, New York, N.Y. 10027 970 phone: (212) 854 3109 971 fax : (212) 316 9068 972 email: [campbell,javierg]@comet.columbia.edu