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