idnits 2.17.1 draft-shelby-cellularipv6-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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 13 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([3], [6], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 411 has weird spacing: '...shed by all...' == Line 417 has weird spacing: '...ed when movi...' == Line 752 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 (July 2001) is 8320 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1305 (ref. '2') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Zach D. Shelby 3 University of Oulu 4 Dionisios Gatzounas 5 Intracom 6 Andrew Campbell 7 Chieh-Yih Wan 8 Columbia University 9 July 2001 11 Cellular IPv6 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document updates Cellular IP [6] with IPv6 capability. This 38 protocol will inter operate fully with Mobile IPv6 [1]. The original 39 is improved with an alternative method for semi-soft handoff. The 40 implementation is freely available for Linux from [9]. 42 What's Changed 44 The following changes have been made to the original protocol 45 presented in : 47 - Control messages use IPv6 extension headers for control 48 information 49 - The Authentication Header is used for all authentication [3] 50 - IPv6 Stateless Auto configuration for obtaining care-of-address 51 - Alternative indirect semi-soft handoff method added (section 4.1.2) 53 In addition, the following minor changes have been made: 55 - Added definitions for registration request and semi-soft handoffs 56 - Mobile hosts are now identified by their IPv6 care-of-address 57 (section 3.4) 58 - Added active-state-timeout as parameter (section 3.1) 59 - Further clarification of paging cache placement (section 2.1) 60 - Misc. text corrections 62 1. Introduction 64 Hosts connecting to the Internet via a wireless interface are likely 65 to change their point of access frequently. A mechanism is required 66 that ensures that packets addressed to moving hosts are successfully 67 delivered with high probability. A change of access point during 68 active data transmission or reception is called a handoff. During or 69 immediately after a handoff, packet losses may occur due to the 70 delayed propagation of new location information. These losses should 71 be minimized in order to avoid a degradation of service quality as 72 handoff become more frequent. 74 This memo specifies Cellular IPv6, a protocol that provides mobility 75 and handoff support for frequently moving hosts. It is intended to be 76 used on a local level, for instance in a campus or metropolitan area 77 network. Cellular IPv6 can inter work with Mobile IPv6 [1] to sup- 78 port wide area mobility, that is, mobility between Cellular IPv6 Net- 79 works. 81 1.1. Applicability 83 Cellular IP supports local mobility, that is, mobility inside an 84 access network. To provide global mobility support, Mobile IPv6 [1] 85 should be used in conjunction. 87 It is designed to support frequently migrating, rarely moving or 88 static hosts as well. 90 It is assumed that a random access L2 protocol covers the air inter- 91 face. Optional support for non-random access wireless interfaces to 92 perform semi-soft handoff is described in 4.1.2. 94 Throughout the draft the term Base Station is used exclusively. This 95 also refers to the Access Point used in WLAN and WPAN networks. 97 1.2. New Architectural Entities 99 Cellular IP Node 100 A Cellular IP Network consists of interconnected Cellular IP 101 nodes. The role of nodes is twofold. They route IP packets 102 inside the Cellular IP Network and communicate with mobile 103 hosts via a wireless interface. Referring to the latter role, 104 a Cellular IP node that has a wireless interface is also called 105 a Base Station. 107 Cellular IP Base Station 108 See Cellular IP node. 110 Cellular IP Gateway 111 A Cellular IP node that is connected to a regular IP network by 112 at least one of its interfaces. 114 Cellular IP Mobile Host 115 A mobile host that implements the Cellular IP protocol. 117 1.3. Terminology 119 Active Mobile Host 120 A mobile host is in active state if it is transmitting or 121 receiving IP packets. (Exact definition is given in Section 122 3.8.) 124 Cellular IP Network Identifier 125 A unique identifier assigned to Cellular IP Networks. 127 Control packet 128 Paging-update, paging-teardown and route-update packet. 130 Data packet 131 An IP packet that is not a control packet. 133 Downlink 134 Directed to a mobile host. 136 Downlink neighbor 137 All neighbors of a Cellular IP node except its Uplink neighbor 138 are referred to as Downlink neighbors. 140 Idle Mobile Host 141 A mobile host is in idle state if it has not recently 142 transmitted or received IP packets. (Exact definition is given 143 in Section 3.8.) 145 Internet 146 A Cellular IP Network provides access to a regular IP network. 147 This IP network in this memo is referred to as "Internet", but 148 it can also be a corporate intranet, for example. 150 Neighbor 151 One Cellular IP node is said to be the neighbor of another if 152 they are connected directly. Neighbors are identified in a 153 Cellular IP node by interface and MAC address. 155 Paging Area 156 A set of Base Stations. Idle mobile hosts crossing cell 157 boundaries within a Paging Area do not need to transmit control 158 packets to update their position. (Exact definition is given in 159 Section 2.1.) 161 Paging Cache 162 A cache maintained by some Cellular IP nodes, used to route 163 packets to mobile hosts. 165 Paging-timeout 166 Validity time of mappings in Paging Caches. 168 Paging-update packet 169 A control packet transmitted by Cellular IP mobile hosts in 170 order to update Paging Cache. 172 Paging-update-time 173 Time between consecutive paging-update packets. 175 Paging-teardown packet 176 A control packet transmitted by Cellular IP mobile hosts in 177 order to explicitly disconnect from the Cellular IP Network. 179 Registration request 180 Type of control message used by a mobile host when it first 181 communicates with the Cellular IP network. 183 Route-timeout 184 Validity time of mappings in Route Cache. 186 Route-update packet 187 A control packet transmitted by Cellular IP mobile hosts in 188 order to update Route Cache. 190 Route-update-time 191 Time between consecutive route-update packets. 193 Route Cache 194 A cache maintained by all Cellular IP nodes, used to route 195 packets to mobile hosts. 197 Semi-soft handoff 198 Handoff method where traffic bound to a mobile host is bi-cast to 199 both the new and old BS simultaneously. 201 Update packet 202 Paging-update and route-update packet. 204 Uplink 205 Originated by a mobile host. 207 Uplink neighbor 208 The neighbor of a Cellular IP node which is the next hop on the 209 shortest path towards the Gateway. 211 1.4. Protocol Overview 213 The figure shown below presents a schematic view of multiple Cellular 214 IP Networks providing access to the Internet. 216 .............................................. 217 . . 218 . Internet Backbone with Mobile IPv6 . 219 . . 220 .............................................. 221 | | | 222 +--+ +--+ +--+ 223 |GW| |GW| |GW| 224 +--+ +--+ +--+ 225 | | | 226 +-------------+ +--------------------+ +-------------+ 227 | | | | | | 228 | Cellular IP | | Cellular IP | | Cellular IP | 229 | Network | | Network | | Network | 230 | | | __ __ __ | | | 231 +-------------+ +-|BS|---|BS|---|BS|-+ +-------------+ 232 -- -- -- 234 + ... + 235 MH MH 237 In what follows, we present an overview of the operation of Cellular 238 IP, followed by a figure illustrating the functional entities that 239 comprise Cellular IP. 241 Base Stations periodically emit beacon signals. Mobile hosts use 242 these beacon signals to locate the nearest Base Station. A mobile 243 host can transmit a packet by relaying it to the nearest Base Sta- 244 tion. 246 By default all IP packets transmitted by a mobile host are routed 247 from the Base Station to the Gateway by hop-by-hop shortest path 248 routing, regardless of the destination address. 250 Cellular IP nodes maintain a Route Cache. Packets transmitted by the 251 mobile host create and update entries in each node's Cache. An entry 252 maps the mobile host's IP address to the neighbor from which the 253 packet arrived to the node. 255 The chain of cached mappings referring to a single mobile host con- 256 stitutes a reverse path for downlink packets addressed to the same 257 mobile host. As the mobile host migrates, the chain of mappings 258 always points to its current location because its uplink packets 259 create new and change old mappings. 261 IP packets addressed to a mobile host are routed by the chain of 262 cached mappings associated with the said mobile host. 264 To prevent its mappings from timing out, a mobile host can periodi- 265 cally transmit control packets. Control packets are IPv6 packets 266 with Hop-by-Hop extension headers containing Cellular IP control 267 information. 269 Mobile hosts that are not actively transmitting data but want to be 270 reachable for incoming packets, let their Route Cache mappings time 271 out but maintain Paging Cache mappings. IP packets addressed to 272 these mobile hosts will be routed by Paging Caches. Paging Caches 273 have a longer timeout value than Route Caches and are not necessarily 274 maintained in every node. 276 +--------+ 277 |host in | 278 |Internet| 279 +--------+ 280 | Internet 281 | -------------------------- 282 +--------+ Cellular IP Network 283 |Cell. IP| 284 |Gateway | 285 +--------+ 286 | 287 - : 288 | : 289 | :___________ Uplink neighbor 290 A network of | | (=shortest path 291 | +--------+ toward Gateway) 292 Cellular IP | |Cellular| 293 | |IP node | 294 nodes | +--------+ 295 | | ___________ Downlink neighbors 296 | :/ (=all other 297 - : neighbors) 298 : 299 | 300 +--------+ 301 uplink |Cellular| 302 ^ |IP node | 303 | +--------+ 304 | air | 305 | interface| 306 V +--------+ 307 downlink | Mobile | 308 | host | 309 +--------+ 311 1.5. Location Management and Routing 313 Cellular IP uses two parallel cache systems to store the information 314 related to the location of mobile hosts. The two systems basically 315 operate in the same way. This section is intended to clarify why we 316 use two distinct caches. 318 When a mobile host is in active state, the network must follow its 319 movement from Base Station to Base Station to be able to deliver 320 packets without searching for the mobile host. As a consequence 321 active mobile hosts must notify the network about each handoff. For 322 idle mobile hosts exact location tracking is less important, instead 323 minimizing communication to save battery is of higher priority. By 324 deploying two caches, the granularity of location tracking can be 325 different for idle and active mobile hosts. 327 Separating the location tracking for idle and active mobile hosts 328 also has a performance benefit. Supposing there is just one set of 329 cache, for each downlink packet the entire cache must be searched to 330 find the destination mobile host. It is expected, however, that only 331 a portion of the hosts will be in active state at any given time and 332 that most of the packets are destined for active mobile hosts. Thus 333 by separating the caches for active and idle mobile hosts only a 334 smaller cache needs to be searched for most of the packets. This 335 results in faster lookups and better scalability [5]. 337 2. Cellular IP Functions 339 2.1. Location Management 341 Cellular IP allows idle mobile hosts to roam large geographic areas 342 without the need to transmit location update packets at cell borders. 343 The network operator can group cells into Paging Areas, each compris- 344 ing of an arbitrary number of (typically adjacent) cells. Each Pag- 345 ing Area has an identifier that is unique in the given Cellular IP 346 Network. Each Base Station transmits its Paging Area Identifier in 347 its periodic beacon signals, thus enabling mobile hosts to notice 348 when they move into a new Paging Area. 350 An idle mobile host that moves into a new Paging Area must transmit a 351 paging-update packet. Paging-update packets are routed from the Base 352 Station to the Gateway using hop-by-hop routing. Selected nodes of 353 the Cellular IP network are equipped with Paging Cache. These nodes 354 monitor passing paging-update packets and update Paging Cache 355 mappings to point toward the new Paging Area. Paging-update packets 356 reach the Gateway and are discarded there to isolate Cellular IP 357 specific operations from the Internet. 359 When the idle mobile host moves within a Paging Area, it transmits a 360 paging-update packet only when the system specific time, paging- 361 update-time expires. Outdated mappings of Paging Caches are cleared 362 if no update arrives before paging-timeout expires. 364 When an IP packet arrives at a Cellular IP node, addressed to a 365 mobile host for which no up-to-date Route Cache mapping is available, 366 the Paging Cache is used to route the packet. This is called "impli- 367 cit paging". If the node has no Paging Cache, it forwards the packet 368 to all Downlink neighbors. A node that has Paging Cache but has no 369 mapping in it for the destination mobile host discards the packet. 371 On the path from the gateway to the mobile host there may be Cellular 372 IP nodes with and without Paging Cache. After the paging packet 373 leaves the last node which has a Paging Cache it is effectively down- 374 link broadcast by all nodes it passes. The set of cells that are 375 reached by the paging packet forms a Paging Area. The number, size 376 and population of Paging Areas in a Cellular IP network are deter- 377 mined by the topology of the network and the placement of Paging 378 Caches. Each interface of the last downlink node with a paging cache 379 must belong to a separate paging area. Based on the configuration of 380 a Paging Area each base station (with Paging Cache configured) could 381 be considered an autonomous Paging Area. The other extreme case is 382 when a Cellular IP Network has no Paging Cache configured in which 383 case the complete network represents a Paging Area where paging 384 devolves to broadcasting throughout the network. 386 When the mobile host receives the paging packet, it moves to active 387 state and creates its Route Cache mappings by sending a route-update 388 packet. Subsequent IP packets addressed to the same host will be 389 routed by Route Caches as long as the mobile host keeps the Route 390 Caches updated. 392 2.2. Routing 394 Packets transmitted by mobile hosts are routed to the Gateway using 395 shortest path hop-by-hop routing. Cellular IP nodes monitor these 396 passing data packets and use them to create and update Route Cache 397 mappings. These map mobile host IP addresses to Downlink neighbors 398 of the Cellular IP node. Packets addressed to the mobile host are 399 routed along the reverse path, on a hop-by-hop basis, by these Route 400 Cache mappings. 402 The structure and basic operation of routing is similar to that of 403 location management. To clarify the duality between the two, we sum- 404 marize the operation of Paging Caches and Route Caches in the follow- 405 ing table. For the reasons of separating the two functions, see Sec- 406 tion 1.5. 408 --------------------------------------------------------------------- 409 Paging Caches Route Caches 410 --------------------------------------------------------------------- 411 refreshed by all uplink packets (data, data and 412 paging-update, route-update) route-update packets 414 updated by all update packets route-update packets 415 (paging-update, route-update) 417 updated when moving to a new Paging moving to a new 418 Area, or after cell, or after 419 paging-update-time route-update-time 421 scope both idle and active MHs active mobile hosts 423 purpose route downlink packets if route downlink 424 there is no Route Cache entry packets 425 --------------------------------------------------------------------- 427 The mobile host may keep receiving data packets without sending data 428 for possibly long durations. To keep its Route Cache mappings up to 429 date and to avoid repeated paging, mobile hosts in active state that 430 have no data to send must send periodic route-update packets. Like 431 uplink data packets, route-update packets update Route Caches and 432 ensure that the hop-by-hop route from the Gateway to the mobile host 433 does not time out. 435 In addition, active mobile hosts must transmit a route-update packet 436 when they cross cell borders. This is required because the Route 437 Cache mappings associated with the new Base Station can only be 438 created by authenticated route-update packets. Data packets are not 439 required to carry authentication information and hence can refresh, 440 but not modify Route Cache mappings. 442 For reliability and timeliness, Paging Caches also contain mobile 443 hosts that are contained by Route Caches. For this reason, Paging 444 Caches are updated by all uplink update packets and refreshed by all 445 uplink packets including data packets as well. 447 2.3. Handoff 449 Handoff is initiated by the mobile host. As an active host 450 approaches a new Base Station, it transmits a route-update packet and 451 redirects its packets from the old to the new Base Station. The 452 route-update packet will configure Route Caches along the way from 453 the new Base Station to the Gateway. (The paths leading to the old 454 and new Base Stations may overlap. In nodes where the two paths 455 coincide, the route-update packet simply refreshes the old mapping 456 and the handoff remains unnoticed.) 458 An idle mobile host, moving to a new Base Station, transmits a 459 paging-update packet only if the new Base Station is in a new Paging 460 Area. During handoffs between Base Stations within the same Paging 461 Area idle mobile hosts may remain silent, as paging is performed 462 within the entire Paging Area. 464 2.4. Wide Area Mobility 466 Wide area mobility occurs when the mobile host moves between Cellular 467 IP Networks. The mobile host can identify Cellular IP Networks by 468 the Cellular IP Network Identifier contained in the Base Stations' 469 beacon signals. The beacon signal also contains the IP address of 470 the Gateway. After successful authentication to the Cellular IP net- 471 work the mobile host will invoke the IPv6 Stateless Address Auto con- 472 figuration mechanism to generate a temporary Mobile IPv6 care-of 473 address in the visited Cellular IP network. This address will be 474 assembled by pre pending the IPv6 subnet prefix advertised by Cellu- 475 lar IP beacon signals to the mobile host's interface identifier [8]. 476 To ensure that the configured Mobile IPv6 care-of address is likely 477 to be unique, the mobile host may run a duplicate address detection 478 algorithm before assigning the new Mobile IPv6 address on its inter- 479 face. For security and charging purposes, authentication and other 480 user-related information may need to be provided by the mobile host, 481 when it first contacts a Cellular IP Network. 483 This information will be included in the first route-update or 484 paging-update packet and may be repeated in a few subsequent route- 485 update or paging-update packets for reliability. Upon receiving the 486 first route-update or paging-update packet, the Gateway performs 487 admission control that may involve technical and charging decisions. 489 The Gateway's response is sent to the mobile host in regular IP 490 packet(s). If the request was accepted, the response may also carry 491 the required setting for protocol parameters. Upon successful admis- 492 sion, the mobile host should send binding update messages to its Home 493 Agent and its correspondent nodes notifying them about its new point 494 of attachment [1]. 496 The mobile host may leave the service area at any time without prior 497 notice. Mappings associated to the host will be cleared after the 498 timeout. Alternatively, as a performance optimization the host may 499 send a paging-teardown packet to clear Cache mappings from both Route 500 and Paging Caches. 502 2.5. Security 504 Cellular IP control packets (paging-update, route-update and paging- 505 teardown packets) carry mandatory Authentication Headers [3]. This 506 prevents malicious mobile hosts from changing location information 507 related to other mobile hosts using a spoofed source address. 509 Data security issues are not discussed in this document. We note 510 that any further authentication or encryption can be performed in 511 addition to control packet authentication built into Cellular IP. 513 3. Protocol Details 515 3.1. Protocol Parameters 517 The following parameters shall be set by network management. The 518 values listed here are for information only. Note that in the most 519 typical case a mobile host that is in active state will regularly 520 transmit data packets and hence route-update packets will need to be 521 transmitted at handoffs only. 523 ------------------------------------------------------------------- 524 Name Meaning Typical Value 525 ------------------------------------------------------------------- 526 route-update-time Maximal inter-arrival time 3 sec 527 of packets updating the 528 Route Cache 530 route-timeout Validity of Route 9 sec 531 Cache mappings 533 paging-update-time Maximal inter-arrival time 3 min 534 of packets updating the 535 Paging Cache 537 paging-timeout Validity of Paging 9 min 538 Cache mappings 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. 546 Beacons are sent in an IPv6 packet with Destination Options header 547 [7]. This is multicast to FF02:0:0:0:0:0:0:1 (All nodes multicast). 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Next Header | Hdr Ext Len=1 | Option Type=B |Opt Data Len=? | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 + Subnet Prefix (8 octets) + 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | BS ID | Paging ID | Cellular IP Network ID | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 | | 560 | | 561 + Gateway IP Address (16 octets) + 562 | | 563 | | 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 + Layer 2 Parameters (Variable) + 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Option Type 572 8-bit type identifier. B=Beacon type. 574 Option Data Length 575 Length of extension header option. 577 Subnet Prefix 578 IPv6 subnet prefix advertisement. A 64 bit global IPv6 address 579 prefix must be used (not site or link-local since this would 580 result in the generation of a locally scoped care-of-address). 582 BS ID 583 Identifier of the advertising base station. 585 Paging Area ID 586 The ID of the current paging area. 588 Cellular IP Network ID 589 Unique ID of the current Cellular IP Network. 591 CU 592 Currently unused field. 594 Gateway IP 595 IP address of the Cellular IP network's Gateway. 597 Layer 2 Parameters 598 Variable length field using the type-length-value (TLV) format 599 for giving any needed L2 parameters to a MT. 601 All parameters can be configured by network management. 603 3.3. Packet Formats 605 3.3.1. Data packet 607 Cellular IP forwards regular IP packets without modification, segmen- 608 tation, encapsulation or tunneling. 610 3.3.2. Route-update packet 612 A route-update packet is an IPv6 packet with a Hop-by-Hop Options 613 extension header [7]. 615 - the source address is the IP address of the sending mobile host; 616 - the destination address is the Gateway; and 617 - the Hop-by-Hop option is of Route-update type. 619 The route-update fields will be held inside a type-length-value (TLV) 620 field inside the extension header. 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Next Header | Hdr Ext Len=1 | Option Type=R |Opt Data Len=? | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 + Timestamp (8 octets) + 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | CU |S|I| CU | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | | 632 | Control information (variable length) | 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Option Type 637 8-bit type identifier. R=Route-update type. 639 Option Data Length 640 Length of extension header option. 642 Timestamp 643 Contains a timestamp used to determine the order in which update 644 packets are sent. The timestamp field is formatted as specified 645 by the Network Time Protocol [2]. The low-order 32 bits of the 646 NTP format represent fractional seconds, and those bits which are 647 not available from a time source should be generated from a good 648 source of randomness. Mobile hosts must ensure that the 64 bit 649 value of timestamps is strictly increasing in consecutive control 650 packets. 652 CU 653 Currently Unused. Must be set to 0. 655 S flag 656 Set to 1 to indicate semi-soft handoff. Default value is 0. Any 657 Cellular IP node that does not support semi-soft handoffs may 658 ignore this bit. (See Section 4.1.1) 660 I flag 661 Used to indicate an indirect semi-soft handoff. Only a Base 662 Station will recognize this flag and act accordingly. 664 Control Information 665 This field uses the same TLV structure as the Hop-by-Hop options. 667 Currently only one is defined: 669 Registration request 670 Used when a mobile host enters the Cellular IP Network. 672 3.3.3. Paging-update packet 674 A paging-update packet is an IPv6 packet with a Hop-by-Hop Options 675 extension header where 677 - the source address is the IP address of the sending mobile host; 678 - the destination address is the Gateway; and 679 - the Hop-by-Hop option is of Paging-update type. 681 The option of the paging-update packet carries control information in 682 the same format as the route-update packet. The S and I flags must be 683 0 for paging-update packets. 685 3.3.4. Paging-teardown packet 687 A paging-teardown packet is an IPv6 packet with a Hop-by-Hop Options 688 extension header where 690 - the source address is the IP address of the sending mobile host; 691 - the destination address is the Gateway; and 692 - the Hop-by-Hop option is of Paging-teardown type. 694 The payload of the paging-teardown packet carries control information 695 in the same format as the route-update packet. The S and I flags must 696 be 0 for paging-teardown packets. 698 3.4. Addressing 700 Cellular IP requires no address space allocation beyond what is 701 present in IPv6. Mobile hosts are identified by their care-of 702 addresses. 704 3.5. Security 706 Each Cellular IP Network has a secret network key of arbitrary length 707 known to all Cellular IP nodes. The network key is kept secret from 708 mobile hosts and other nodes outside the Cellular IP Network, how- 709 ever. Upon initial registration the Gateway must authenticate and 710 possibly authorize the mobile host. This initial authentication and 711 authorization can be based on any known symmetric or asymmetric 712 method. After authentication the Gateway concatenates the key of the 713 network and the IP address of the mobile host and calculates the PID 714 of the mobile host by an MD5 Hash similarly as in [4]: 716 PID := MD5(network key, IP address of MH) 718 Then it acquires the public key of the mobile host from a trusted 719 party, encrypts the PID and sends it to the mobile host. This way 720 the mobile host and the Cellular IP network have a shared secret. The 721 PID remains the same during handoff and can be easily computed by 722 each Base Station. 724 The PID can be used to authenticate (and optionally to encrypt) IP 725 packets over the air interface. Authentication is performed by 726 creating a short hash from the (PID, timestamp, packet content) tri- 727 ple that is placed into the transmitted packets. The validity of 728 each packet can be easily checked by any Base Station even immedi- 729 ately after a handoff and without prior communication with the mobile 730 host or with the old Base Station. 732 In addition to authenticating control packets, PID can optionally 733 also be used to provide security for data packets transmitted over 734 the wireless link. To this avail, any known shared secret based 735 security mechanism can be used where PID serve as the shared secret. 737 3.6. Cellular IP Routing 739 Cellular IP nodes need only to implement the algorithm described in 740 this section. They do not need regular IP routing capability. This 741 section describes the routing algorithm in Cellular IP nodes other 742 than the Gateway. The extra functions required only in the Cellular 743 IP Gateway are described in Section 3.7. 745 3.6.1 Topology 747 In uplink direction (toward the Gateway), packets are routed in the 748 Cellular IP Network on a hop-by-hop basis. The neighbor to which a 749 node will forward a packet toward the Gateway is referred to as the 750 node's Uplink neighbor. The Uplink neighbor at each node may be 751 designated by network management. Alternatively, a simplified shor- 752 test path algorithm can select Uplink neighbors instead of manual 753 configuration. (A regular shortest path algorithm is also applicable 754 but is more complex than required since it determines routes to all 755 nodes in the network.) A simple algorithm that configures Uplink 756 neighbors and automatically reconfigures them if necessary after a 757 topology change is described in Appendix A. 759 A node's neighbors other than the Uplink neighbor are called Downlink 760 neighbors. 762 3.6.2 Uplink Routing 764 A packet arriving at a node from one of its Downlink neighbors is 765 assumed to be coming from a mobile host. The packet is first used to 766 update the node's Route and Paging Caches and is then forwarded to 767 the node's Uplink neighbor. 769 To update the Caches, the node reads the packet type, port number and 770 the source IP address. Paging-update packets update the Paging Cache 771 only. Route-update packets update both Route and Paging Caches. 772 Data packets only refresh the soft state of both caches, but do not 773 change it. Both types of caches consist of 775 { IPv6 address, interface, MAC address, expiration time, timestamp } 777 5-tuples, called mappings. The IPv6 address is the address of the 778 mobile host the mapping corresponds to. The interface and the MAC 779 address denote the Downlink neighbor toward the mobile host. The 780 timestamp field contains the timestamp of the control packet that has 781 established the mapping. 783 When a data packet arrives from a Downlink neighbor, the Route Cache 784 entry of the source IP address is searched first. If the data packet 785 is coming from the same neighbor as indicated by the cache entry then 786 it is sent from the direction where the mobile host was last seen. In 787 that case the mapping is only refreshed: the expiration time is set 788 to the current time + route-timeout. If the node has Paging Cache, 789 then the expiration time of the mapping in the Paging Cache is set to 790 current time + paging-timeout as well. 792 If the data packet arrived from a different neighbor than that is in 793 its mapping or no mapping exists for the IP address, then the packet 794 is dropped. 796 When an update packet arrives from a Downlink neighbor then the 797 authentication is first validated. Packets with invalid authentica- 798 tion must be dropped and the event should be logged as a potential 799 tampering attempt. For valid packets the node creates the following 800 5-tuple: 802 { the newly arrived packet's source IPv6 address, 803 the interface through which it arrived, 804 the source MAC address of the arrived packet, 805 current time + route-timeout, 806 the timestamp in the arrived update packet } 808 This mapping is used to update Route Cache, if the incoming packet is 809 a route-update packet. If a valid mapping for the source IPv6 810 address already exists, then it is replaced by the new 5-tuple, if 811 the timestamp is newer, otherwise the packet is dropped. If no map- 812 ping exists for the source IP address then the mapping is added to 813 the Route Cache. The Paging Cache is updated in the same way, but 814 using paging-timeout instead of route-timeout. If the node has no 815 Paging Cache then only the Route Cache is updated. If the incoming 816 packet is a paging-update, then only the Paging Cache is updated (if 817 any). 819 If the packet is a paging-teardown packet and the authentication 820 information is valid, then mappings of the mobile host with timestamp 821 earlier than the timestamp of the packet are removed from both the 822 Route and the Paging Cache. 824 After cache modifications the control packet is forwarded to the 825 Uplink neighbor. 827 3.6.3 Downlink Routing 829 A packet arriving to a Cellular IP node from the Uplink neighbor is 830 assumed to be addressed to a mobile host. The node first checks if 831 the destination IP address has a valid mapping in the Route Cache. 832 If such a mapping exists, the packet is forwarded to the Downlink 833 neighbor found in the mapping. 835 If the Route Cache contains no mapping for the destination IP address 836 and the node has no Paging Cache, then the packet is broadcast on all 837 interfaces of the node except the interface of the Uplink neighbor. 839 If the node has Paging Cache and there is a mapping for the destina- 840 tion IP address, then the packet is forwarded to the neighbor found 841 in that mapping. 843 If the node has Paging Cache, but there is no mapping for the desti- 844 nation IP address, then the packet is dropped. 846 3.7. Cellular IP Gateway 848 The following figure is a schematic view of a Cellular IP Gateway. 849 The Gateway can logically be divided into three building blocks: a 850 regular Cellular IP node, a Gateway Packet Filter and a Gateway Con- 851 troller. 853 IP network 854 =================== 855 | 856 +------------------------------|--------+ 857 | | | 858 | +----------+ +-------------+ | 859 | | Gateway |__________| Gateway | | 860 | |Controller| |Packet Filter| | 861 | +----------+ +-------------+ | 862 | |________|___Uplink neighbor 863 | | | 864 | +-------------+ | 865 | Cellular IP |Cellular IP | | 866 | Gateway | node | | 867 | +-------------+ | 868 | | | | | 869 +-------------------------|----|----|---+ 870 <----Downlink neighbors 872 Uplink packets update the Route and/or Paging Caches in the Cellular 873 IP node block and are forwarded towards the Gateway filter. The 874 Gateway filter reads the destination IP address. If this is the 875 Gateway's address, the packet is forwarded to the Gateway controller. 876 Most of these packets are control packets with empty control informa- 877 tion field and are immediately dropped. If the packet carries con- 878 trol information, for instance a registration request, it is inter- 879 preted and processed by the Gateway controller. 881 If the destination address is not the Gateway's, the packet is for- 882 warded to the Internet. (This means that a packet sent from a mobile 883 host to another mobile host in the same Cellular IP Network goes 884 through the destination Home Agent. However, this is not the case if 885 route optimization is used. To operate efficiently even without 886 Mobile IP route optimization, the Gateway Packet Filter can also 887 check if the destination address of an uplink packet has a valid map- 888 ping in any of the Gateway's caches. If a mapping is found, the 889 packet is "turned back" and is treated as a downlink packet.) 891 All packets arriving from the Internet are forwarded normally to the 892 Cellular IP node block. The Gateway's Cellular IP node block treats 893 these packets as determined by the Cellular IP Routing algorithm 894 (Section 3.6) according to the mappings in Route and Paging Cache. 895 It is optional whether Cellular IP Nodes have Paging Cache configured 896 or not. However, it is recommended that at least the Gateway's Cellu- 897 lar IP node has a Paging Cache configured. This ensures that packets 898 addressed to hosts currently not connected to the Cellular IP Network 899 do not enter the network and do not load it in vain but are 900 immediately discarded in the Gateway when neither Route, nor Paging 901 Cache mapping is found for the destination address. (It may be 902 advantageous to also generate an ICMP message in this case and send 903 it back to the packet's source address.) 905 3.8. Cellular IP Mobile Host 907 While connected to a Cellular IP Network, a mobile host must be in 908 one of two states: 'active' or 'idle'. The host moves from idle to 909 active state when it receives or wishes to send a data packet. 910 Active state is maintained as long as the host is transmitting or 911 receiving data packets. When the host has not received or transmit- 912 ted any data packets for some time (the value of this timer may be 913 implementation-specific) then it returns to idle state. 915 When the host moves from idle to active state, it must transmit a 916 route-update packet. At the same time, a timer is initiated from a 917 value equal to route-update-time. If the timer expires without any 918 data packet being transmitted from the host, again a route-update 919 packet is transmitted and the timer is re-initiated. Any IP packet 920 transmitted before the timer expires, resets the timer to route- 921 update-time. This ensures that while the mobile host is in active 922 state, the largest interval between two transmitted packets is never 923 longer than route-update-time. The mechanism also ensures that if 924 data packets are transmitted with sufficient frequency, no route- 925 update packets will be generated, which will probably be typical. 927 If the host is in active state, it must immediately transmit a 928 route-update packet whenever it connects to a new base station. This 929 typically happens at migration, but is also the case after a wireless 930 channel black-out or when the host enters the Cellular IP Network. A 931 packet transmitted this way also resets the route-update packet 932 timer. 934 In idle state, the mobile host must transmit paging-update packets 935 periodically, at intervals of paging-update-time. In addition, the 936 host must transmit a paging-update packet when it connects to a new 937 Base Station which has a different Paging Area ID from the previous 938 Base Station. (When connecting to a Base Station that belongs to the 939 same Paging Area as the previous one, the host need not transmit 940 paging-update packet.) Similarly to the route-update packet timer, 941 the paging-update timer is reset if a data packet is transmitted. 943 The mobile host must ensure that the 64 bit value of timestamps is 944 strictly increasing in consecutive control packets. 946 The mobile host processes all IPv6 packets which it receives. If an 947 IPv6 packet carries a Routing extension header then it is processed 948 normally to cause the packet to be delivered to the upper layers (the 949 home address of the mobile host is included in the Routing header as 950 the final destination of the packet). Alternatively, the packet is 951 received encapsulated into an IPv6 tunnel header. In this case the 952 mobile host performs IPv6 decapsulation to extract the original IPv6 953 packet and then sends a Mobile IPv6 binding update message to the 954 packet sender. 956 4. Extensions to Cellular IP 958 4.1. Handoff Extensions 960 4.1.1. Semi-soft Handoff 962 When a mobile host switches to a new Base Station it sends a route- 963 update packet to make the chain of cache bindings to point to the new 964 Base Station. Packets that are traveling on the old path will be 965 delivered to the old Base Station and will be lost. Although this 966 loss may be small it can potentially degrade TCP throughput. This 967 kind of handoff, when the mobile switches all at once to the new Base 968 Station is called "hard" handoff. For performance details of hard 969 handoff in a Cellular IP network see [5]. 971 To improve the performance of loss sensitive applications, another 972 type of handoff may be introduced, called "semi-soft" handoff. Dur- 973 ing semi-soft handoff a mobile host may be in contact with either of 974 the old and new Base Stations and receive packets from them. Packets 975 intended to the mobile host are sent to both Base Stations, so when 976 the mobile host eventually moves to the new location it can continue 977 to receive packets without interruption. 979 To initiate semi-soft handoff, the moving mobile host transmits a 980 route-update packet to the new Base Station and continues to listen 981 to the old one. The S flag is set in this route-update packet to 982 indicate semi-soft handoff. Semi-soft route-update packets create 983 new mappings in the Route and Paging Cache similarly to regular 984 route-update packets. When the semi-soft route-update packet reaches 985 the cross-over node where the old and new path meet (note that the 986 cross-over node already has a mapping for the mobile host), the new 987 mapping is added to the cache instead of replacing the old one. 988 Packets sent to the mobile host are transmitted to both Downlink 989 neighbors. When the mobile host eventually makes the move then the 990 packets will already be underway to the new Base Station and the 991 handoff can be performed with minimal packet loss. After migration 992 the mobile host sends a route-update packet to the new Base Station 993 with the S bit cleared. This route-update packet will remove all map- 994 pings in Route Cache except for the ones pointing to the new Base 995 Station. The semi-soft handoff is then complete. 997 If the path to the new Base Station is longer than to the old Base 998 Station or it takes non negligible time to switch to the new Base 999 Station, then some packets may not reach the mobile host. To over- 1000 come the problem, packets sent to the new Base Station can be delayed 1001 during the semi-soft handoff. This way a few packets may be 1002 delivered twice to the mobile host, but in many cases this results in 1003 better performance than a few packets lost. Introduction of packet 1004 delay can be best performed in the Cellular IP node that has multiple 1005 mappings for the mobile host as a result of a semi-soft route-update 1006 packet. Packets that belong to flows that require low delay but can 1007 tolerate occasional losses should not be delayed. For performance 1008 details of semi-soft handoff in a Cellular IP network see [5]. 1010 4.1.2. Indirect Semi-soft Handoff 1012 Not all wireless technologies have simultaneous connection capabil- 1013 ity. e.g. They cannot listen to the current BS while sending a 1014 route-update packet to the new BS (as required in 4.1.1). For this 1015 situation an alternative indirect technique is used. It is assumed 1016 the network can obtain the IP address of the new BS. This is the 1017 case in many cellular networks. 1019 When the mobile decides to make a handoff, instead of sending a 1020 route-update packet to the new BS directly (as it cannot), it sends 1021 the packet to the current BS. This packet will have as a destination 1022 IP address, the IP address of the new BS. Unlike in section 4.1.1. 1023 the I flag will be set to indicate indirect semi-soft handoff. The 1024 current BS will forward this uplink to the Gateway normally. The 1025 Gateway then uses normal IP routing to deliver the packet to the new 1026 BS. When the new BS receives the indirect handoff packet, a semi-soft 1027 route update packet is created with the IP address of the mobile 1028 host. It is then forwarded upstream. The algorithm then proceeds to 1029 work as in 4.1.1, just as if the packet had originated through the 1030 new BS. A security association is assumed for the new BS. 1032 4.2. Multiple Gateway Networks 1034 Cellular IP requires that a mobile host be using exactly one Gateway 1035 at a time. This requirement comes from the fact that the Gateway 1036 relays its packets both up and downlink. It is also required to make 1037 uplink routing unambiguous. The Cellular IP Network can have multi- 1038 ple Gateways as long as a single host still uses just one Gateway at 1039 any time. (The host can change Gateway, involving a Mobile IPv6 loca- 1040 tion updating.) In a Network with multiple Gateways, nodes must be 1041 able to determine which Gateway a given mobile host is using. 1042 Assignment of Gateways can, for instance, be based on geographical 1043 partitioning of the network, or on partitioning the mobile hosts' 1044 address space. This issue is for further study. 1046 4.3. Charging 1048 Cellular IP Network providers can charge Cellular IP Mobile users for 1049 connectivity or for transmitted data or both. Charging information 1050 is best collected in the Gateway. The Gateway receives all control 1051 packets and can determine the time a mobile host was connected to the 1052 network. It can also measure through traffic in both directions. 1054 5. Security Considerations 1056 A Cellular IP Network is a single administrative domain. It is con- 1057 nected to the Internet through a Gateway that may eventually also 1058 serve as a firewall. Hence security issues only need to be con- 1059 sidered at the wireless interface. 1061 The security of a Cellular IP system will be determined by the wire- 1062 less link. Security issues relating to wireless links are not 1063 specific to Cellular IP, and are out of the scope of Cellular IP, 1064 even though they must be dealt with in practical Cellular IP imple- 1065 mentations. 1067 A security problem specific to Cellular IP is the security of the 1068 control packets, which can be solved by the authentication mechanism 1069 described in Section 3.5. 1071 6. Intellectual Property Right Notice 1073 Ericsson has filed patent applications that might possibly become 1074 essential to the implementation of this contribution. 1076 References 1078 [1] "Mobility Support in IPv6," D. Johnson, C. Perkins, Work in 1079 Progress, , July 2000. 1081 [2] "Network Time Protocol (Version 3): Specification, Implementation 1082 and Analysis," D. Mills, IETF RFC 1305, March 1992. 1084 [3] "IP Authentication Header," S. Kent, R. Atkinson, IETF RFC 2402, 1085 November 1998. 1087 [4] "IP Authentication using Keyed MD5," P. Metzger, W. Simpson, IETF 1088 RFC 1828, August 1995. 1090 [5] A. T. Campbell, Gomez, J., Kim, S., Turanyi, Z., Wan, C-Y. and A, Valko 1091 "Design, Implementation and Evaluation of Cellular IP", IEEE Personal 1092 Communications, June/July 2000. 1094 [6] A. G. Valko, "Cellular IP - A New Approach to Internet Host Mobility," 1095 ACM Computer Communication Review, January 1999. 1097 [7] "Internet Protocol, Version 6 (IPv6) Specification," IETF RFC 1098 2460, December 1998. 1100 [8] "IPv6 stateless address autoconfiguration," Susan Thomson, Thomas 1101 Narten, IETF RFC 2462, December 1998. 1103 [9] "Cellular IPv6 home page", , Intracom Greece, 1104 July 2001. 1106 Authors' Addresses 1108 Zach D. Shelby 1109 University of Oulu 1110 Center for Wireless Communications 1111 PO Box 4500 1112 90014 Oulu, Finland 1113 phone: +358 40 779 6297 1114 email: zach.shelby@ee.oulu.fi 1116 Dionisios D. Gatzounas 1117 INTRACOM S.A. 1118 Development Programmes Department 1119 Panepistimiou 254 1120 26443 Patras 1121 GREECE 1122 phone: +30 61 465168 1123 fax: +30 61 465070 1124 email: dgat@intracom.gr 1126 Andrew T. Campbell, Chieh-Yih Wan 1127 Department of Electrical Engineering, Columbia University 1128 Rm. 801 Schapiro Research Building 1129 530 W. 120th Street, New York, N.Y. 10027 1130 phone: (212) 854 3109 1131 fax : (212) 316 9068 1132 email: {campbell,wan}@comet.columbia.edu 1134 Appendix A. Uplink Neighbor Selection 1136 This algorithm selects the Uplink neighbor of all nodes of a Cellular 1137 IPv6 Network and reconfigures them if necessary after a change of 1138 topology. An Uplink neighbor is identified by the interface through 1139 which it is accessible from the node and its corresponding MAC 1140 address. The algorithm also distributes the Cellular IP Network 1141 Identifier, the IP address of the Gateway and the Paging Area IDs to 1142 the Base Stations. 1144 The Gateway periodically creates a control packet called a "Gateway 1145 broadcast packet". Packet uses a hop-by-hop extension header. The 1146 Gateway broadcast packet contains 1148 - the Cellular IP Network Identifier; 1149 - the IP address of the Gateway; 1150 - a sequence number increased each time by the Gateway; 1151 - a Paging Area ID field initially set to the ID of the Gateway; and 1152 - the advertised IPv6 subnet prefix. 1154 The Gateway broadcasts the packet on all of its interfaces except 1155 those connected to the Internet. A Cellular IP node receiving a 1156 Gateway broadcast packet follows the steps below: 1158 1) It drops the packet if the sequence number is lower or equal to 1159 the sequence number of one of the previously received Gateway 1160 broadcast packets. In this case no further processing is needed. 1161 2) It stores the sequence number of the Gateway broadcast packet for 1162 later comparison. 1163 3) It stores the Cellular IP Network Identifier and the IP address of 1164 the Gateway. 1165 4) It stores the interface through which the packet arrived together 1166 with source MAC address of the packet (if any) to identify the 1167 Uplink neighbor. All other interface/MAC address combinations 1168 will denote Downlink neighbors. 1169 5) If the node has a Paging Cache, it overwrites the value of the 1170 Paging Area ID field in the packet by its own ID. 1171 6) The value of the (possibly overwritten) Paging Area ID field is 1172 stored as the Paging Area ID of the node. This value will be used 1173 in beacon signals if the node is a Base Station. 1174 7) It stores the Cellular IP Network Identifier and the IP address of 1175 the Gateway. These values will be used in beacon signals if the 1176 node is a Base Station. 1177 8) It stores the advertised IPv6 subnet prefix. This value will be 1178 used in beacon signals if the node is a Base Station. 1179 9) After a short random delay, the node broadcasts the packet through 1180 all of its interfaces, except the air interface(s) and the 1181 interface of the Uplink neighbor. 1183 Table of Contents 1185 1. Introduction ................................................... 2 1186 1.1. Applicability ................................................ 3 1187 1.2. New Architectural Entities ................................... 3 1188 1.3. Terminology .................................................. 3 1189 1.4. Protocol Overview ............................................ 5 1190 1.5. Location Management and Routing .............................. 8 1191 2. Cellular IP Functions .......................................... 8 1192 2.1. Location Management .......................................... 8 1193 2.2. Routing ...................................................... 9 1194 2.3. Handoff ...................................................... 11 1195 2.4. Wide Area Mobility ........................................... 11 1196 2.5. Security ..................................................... 12 1197 3. Protocol Details ............................................... 12 1198 3.1. Protocol Parameters .......................................... 12 1199 3.2. Beacon Signal Structure ...................................... 13 1200 3.3. Packet Formats ............................................... 15 1201 3.3.1. Data packet ................................................ 15 1202 3.3.2. Route-update packet ........................................ 15 1203 3.3.3. Paging-update packet ....................................... 16 1204 3.3.4. Paging-teardown packet ..................................... 17 1205 3.4. Addressing ................................................... 17 1206 3.5. Security ..................................................... 17 1207 3.6. Cellular IP Routing .......................................... 18 1208 3.6.1 Topology .................................................... 18 1209 3.6.2 Uplink Routing .............................................. 18 1210 3.6.3 Downlink Routing ............................................ 20 1211 3.7. Cellular IP Gateway .......................................... 20 1212 3.8. Cellular IP Mobile Host ...................................... 22 1213 4. Extensions to Cellular IP ...................................... 23 1214 4.1. Handoff Extensions ........................................... 23 1215 4.1.1. Semi-soft Handoff .......................................... 23 1216 4.1.2. Indirect Semi-soft Handoff ................................. 24 1217 4.2. Multiple Gateway Networks .................................... 25 1218 4.3. Charging ..................................................... 25 1219 5. Security Considerations ........................................ 25 1220 6. Intellectual Property Right Notice ............................. 26 1221 References ........................................................ 26 1222 Authors' Addresses ................................................ 26 1223 Appendix A. Uplink Neighbor Selection ............................. 27