idnits 2.17.1 draft-ietf-mobileip-3gwireless-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 11) being 60 lines 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 561 has weird spacing: '...rks.com bec...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 99 == Unused Reference: '2' is defined on line 487, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2344 (ref. '2') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') -- No information found for draft-ietf-mobileip-vendor-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Yingchun Xu (editor) 2 Internet Draft Rajesh Bhalla 3 October 1999 Ed Campbell 4 Karl Freter 5 3Com Corporation 6 Eileen McGrath Hadwen 7 Alcatel 8 Gopal Dommety 9 Kirit Joshi 10 Cisco Systems 11 Parviz Yegani 12 Ericson Wireless Communication Inc. 13 Byung-Keun Lim 14 LG Information & Communications, Ltd 15 Peter J. McCann 16 Thomas Towle 17 Lucent Technologies 18 Jay Jayapalan 19 Motorola Inc. 20 Peter W. Wenzel 21 Carey B. Becker 22 Nortel Networks 23 Mark A. Lipford 24 Sprint PCS 26 Mobile IP Based Micro Mobility Management Protocol in 27 The Third Generation Wireless Network 28 30 Status of this Memo 32 This document is an Internet Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026. Internet Drafts are working 34 documents of the Internet Engineering Task Force (IETF), its areas, 35 and working groups. Note that other groups may also distribute 36 working documents as Internet Drafts. 38 Internet Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsolete by other documents 40 at anytime. It is inappropriate to use Internet Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Xu et al. Expires 22 April 2000 1 50 Abstract 52 This document defines extensions to the Mobile IP protocol [1] to 53 allow mobility management for the interface between a radio network 54 and a packet data network in the third generation cdma2000 network. 56 Mobile IP requires link layer connectivity between the Mobile Node 57 and the Foreign Agent. This draft proposes a protocol for achieving 58 this when the physical layer terminates at a point distant from the 59 FA. In particular, this protocol applies to cdma2000 networks where 60 the physical layer terminates at a Radio Network Node (RNN) and the 61 FA resides inside a separate Packet Data Serving Node (PDSN). The 62 PDSN is responsible for establishing, maintaining, and terminating 63 the link layer to the Mobile Node. A RNN is responsible for relaying 64 the link layer protocol between a Mobile Node and its corresponding 65 PDSN. 67 The interface between the RNN and the PDSN is called the RP 68 interface. This interface requires mobility management for handling 69 handoff from one RNN to another without interrupting end to end 70 communication. It also requires the support of the link layer 71 protocol encapsulation. 73 1. Introduction 75 This document defines extensions to the Mobile IP protocol [1] to 76 allow mobility management for the interface between a radio network 77 and a packet data network in the third generation cdma2000 network. 79 Mobile IP requires link layer connectivity between the Mobile Node 80 and the Foreign Agent. This draft proposes a protocol for achieving 81 this when the physical layer terminates at a point distant from the 82 FA. In particular, this protocol applies to cdma2000 networks where 83 the physical layer terminates at a Radio Network Node (RNN) and the 84 FA resides inside a separate Packet Data Serving Node (PDSN). The 85 PDSN is responsible for establishing, maintaining, and terminating 86 the link layer to the Mobile Node. A RNN is responsible for relaying 87 the link layer protocol between a Mobile Node and its corresponding 88 PDSN. 90 The interface between the RNN and the PDSN is called the RP 91 interface. This interface requires mobility management for handling 92 handoff from one RNN to another without interrupting end to end 93 communication. It also requires the support of the link layer 94 protocol encapsulation. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in [RFC-2119]. 100 Xu et al. Expires 22 April 2000 2 101 2. Glossary 103 CDMA Code Division Multiple Access 104 FA Foreign Agent 105 HA Home Agent 106 MN Mobile Node 107 PDSN Packet Data Serving Node 108 RNN Radio Network Node 109 RP Interface between the RNN and the PDSN 111 3. cdma2000 Network RP Interface Overview 113 The high level architecture of a third generation cdma2000 network 114 RP interface is shown in Figure 1. 116 +---------+ +---------+ +---------+ 117 | | | | | | 118 | RNN |----RP------| PDSN |---------| HA | 119 | | Interface | | | | 120 +---------+ +---------+ +---------+ 121 /|\ 122 | Visited Access Home Network 123 | Provider Network 124 | 125 | 126 \|/ 127 +--------+ 128 | Mobile | 129 | Node | 130 +--------+ 132 Figure 1: The Third Generation cdma2000 Network RP Interface 134 In above figure 1, the PDSN will be responsible for establishing, 135 maintaining, and terminating the link layer to the Mobile Node. It 136 initiates the authentication, authorization, and accounting for the 137 Mobile Node and optionally, securely tunnels to the Home Agent. 139 The RNN is responsible for mapping the Mobile Node identifier 140 reference to a unique link layer identifier used to communicate with 141 the PDSN. RNN validates the Mobile Station for access service and 142 manages the physical layer connection to the Mobile Node. 144 4. Mobile IP Extensions 146 This section describes extensions to the Mobile IP protocol for the 147 RP interface within the third generation cdma2000 network. 149 4.1 Registration Request 151 Xu et al. Expires 22 April 2000 3 152 In a cdma2000 network, the mobile node initiates a connection by 153 sending a call setup indication to the RNN across the radio network. 154 When this indication is received by a RNN, a Registration Request 155 will be sent from the RNN to the PDSN to setup a new RP session. 157 A RNN MUST send a Registration Request with the GRE encapsulation 158 and the reverse tunneling bit set. The Home Address field is set to 159 zero. The Home Agent field will be assigned to the IP address of the 160 PDSN and the Care-of Address field will be assigned to the IP 161 address of RNN. 163 When a Registration Request is received by a PDSN, the information 164 from the Session Specific Extension (see next section) will be used 165 to identify a RP session. When a registration is accepted, a GRE 166 tunnel will be created for this Mobile Node. 168 The fields of the Registration Request message are shown below: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type |S|B|D|M|G|V|T| | Lifetime | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Home Address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Home Agent | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Care-of Address | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 + Identification + 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Extensions ... 186 +-+-+-+-+-+-+-+- 188 Type 1 (Registration Request) 190 G This bit MUST be set to 1 for GRE tunneling. 192 T This bit MUST be set to 1 for reverse 193 tunneling. 195 Home Address 196 The field is set to zero. 198 Home Agent 199 This field is assigned to the IP address of the 200 PDSN. 202 Care-of Address 203 This field is assigned to the IP address of RNN. 205 Xu et al. Expires 22 April 2000 4 206 Extensions 207 The Session Specific Extension as described in 208 the next section MUST be included along with 209 the ones described in RFC2002. Specifically, 210 the MN-HA Authentication extension as described 211 in RFC2002 MUST be included along with this 212 extension. 214 4.2 Session Specific Extension 216 This extension is defined to carry information related to the 217 session between a Mobile Node and its serving PDSN. 219 The detailed format of the extension is shown as follows. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | Protocol Type | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Key | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | reserved | MN Connection ID | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | MN ID Type | MN ID Length | MN ID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | MN ID ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type TBD. Its value shall be in the range of 0 to 236 127. 238 Length This is a one octet field and it indicates the 239 length (in bytes) of the extension, NOT 240 including the Type and Length fields. 242 Protocol Type 243 This is a two octet field. It indicates the type 244 of the protocol to be tunneled across the RP 245 interface. It is same as the Protocol Type field 246 in the GRE header. 248 Key This is a four octet value assigned by the RNN 249 and inserted in every GRE frame across the RP 250 interface during user data tunneling. 252 Reserved This is a two octet field. It is not used and is 253 set to zero. 255 MN Connection ID 257 Xu et al. Expires 22 April 2000 5 258 This is a two octet field and it is used to 259 differentiate the multiple sessions from the 260 same Mobile Node. It is locally unique to a 261 Mobile Node. 263 MN ID Type 264 This is a two octet field and it indicates the 265 type of the following Mobile Node ID value. For 266 example, value 1 defines IMSI (International 267 Mobile Serial Identifier) and 2 Ethernet MAC 268 address. 270 MN ID Length 271 This is a one octet field and it indicates the 272 length (in bytes) of the following Mobile Node 273 ID field. 275 MN ID This is the Mobile Node ID, which is globally 276 unique. It is used to uniquely identify a Mobile 277 Node. 279 This extension MUST be included in the Registration Request and 280 Registration Update (see section 4.5) messages. It will be included 281 before the MN-HA Authentication extension in the Registration 282 Request message and before the Registration Update Authentication 283 Extension in the Registration Update message. 285 The MN ID and the MN Connection ID together will uniquely identify a 286 Mobile Session. 288 4.3 Registration Reply 290 The Registration Reply will be sent by a PDSN following the 291 procedure as described in [1]. The Home Address field will be the 292 same value as the Home Address field from the corresponding 293 Registration Request message received by the PDSN. 295 4.4 Vendor/Organization Specific Extensions 297 Dommety [4] proposes two types of Vendor/Organization Specific 298 extensions. These extensions will be used for carrying any third 299 generation cdma2000 network specific information. They may appear in 300 the Registration Request and Registration Update messages as needed. 302 4.5 Registration Update/Acknowledge 304 Two new messages are defined to support PDSN initiated RP tunnel 305 tear down and to speed up resource reclamation on the RNN. 307 The Registration Update message is used for notification of the 308 change of the registration associated with a call. It shall be sent 309 by the PDSN to the previous RNN when a RNN to RNN handoff happens. 311 Xu et al. Expires 22 April 2000 6 312 Both messages are sent with UDP using well-known port number 434. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Home Address | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Home Agent Address | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 + Identification + 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Extensions ... 328 +-+-+-+-+-+-+-+- 330 The format of the Registration Update message is illustrated above, 331 and contains the following fields: 333 Type TBD 335 Reserved Sent as 0; ignored on reception. 337 Home Address Sent as 0; 339 Home Agent Address 340 The IP Address of the PDSN. 342 Identification 343 A 64-bit number assigned by the node sending 344 the Registration Update message. It is used to 345 assist in matching requests with replies, and 346 in protecting against replay attacks. 347 Extensions 348 Both Registration Update Authentication 349 Extension (see section 4.6) and Session 350 Specific Extension (see section 4.2) SHALL be 351 included. 353 A Registration Update shall be sent by a PDSN to indicate the 354 closure of a RP session. The RNN may reclaim the resource associated 355 with that session. 357 A Registration Acknowledge message is used to acknowledge receipt of 358 a Registration Update message. It MUST be sent by a node receiving a 359 Registration Update message. 361 Xu et al. Expires 22 April 2000 7 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Reserved | Status | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Home Address | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Care Of Address | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 + Identification + 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Extensions ... 376 +-+-+-+-+-+-+-+- 378 The format of the Registration Acknowledge message is illustrated 379 above, and contains the following fields: 381 Type TBD 383 Status If the Status is nonzero, this acknowledgment is 384 negative. 386 Reserved 387 Sent as 0; ignored on reception. 389 Home Address 390 Copied from the Registration Update message 391 being acknowledged. 393 Care of Address 394 The IP address of the RNN. 396 Identification 397 Copied from the Registration Update message 398 being acknowledged. 400 Extensions 401 Registration Update Authentication 402 Extension SHALL be included. 404 Allowable values for the Status include: 406 0 successful acknowledgement 407 128 reason unspecified 408 129 administratively prohibited 409 133 identification mismatch 410 134 poorly formed Registration Update 412 4.6 Registration Update Authentication Extension 414 Xu et al. Expires 22 April 2000 8 415 The Registration Update Authentication extension is used to 416 authenticate the Registration Update and Registration Acknowledge 417 messages. It has the same format and default algorithm support 418 requirements as the authentication extension defined for Mobile IP 419 protocol [1], but with a different type (TBD). The authenticator 420 value is computed from the stream of bytes including the shared 421 secret, the UDP payload all prior extensions in their entirety, and 422 the type and length of this extension, but not including the 423 authenticator field itself nor the UDP header. The secret used for 424 computing the authenticator field is shared between the RN and PDSN. 425 This extension is required in both Registration Update and 426 Registration Acknowledge messages. 428 4.7 Summary 430 The extensions to Mobile IP include enabling the GRE encapsulation 431 and reverse tunneling during Registration. A new extension called 432 Session Specific Extension is defined and is mandatory in both 433 Registration Request and Registration Update messages. The Home 434 Address field MUST be set to zero in the Registration Request, 435 Registration Reply, Registration Update and Registration Acknowledge 436 messages. 438 Two new messages (Registration Update/Acknowledge) are defined to 439 support the RP session disconnection in order to speed up resource 440 reclamation. 442 5.0 GRE Encapsulation 444 GRE encapsulation as described in [3] shall be supported during user 445 data transmission. A new protocol type might be required to support 446 the link layer protocol defined for the third generation cdma2000 447 network. The Key field shall be required and its value shall be same 448 as the one from the Session Specific Extension as described above. 449 The sequence number may be required, depending on the requirement of 450 the protocol encapsulated within the GRE frame. 452 During traffic tunneling, the sender will insert the Key value from 453 the Registration Request message into the Key field of the GRE 454 header. The receiver will use the Key value from the GRE header to 455 decide where to forward the user data. 457 6.0 Security Considerations 459 The protocol presented in this draft is designed for use over a 460 protected, private network between RNN and PDSN. Pre-arranged 461 security associations in the style of Mobile IPv4 are assumed to 462 exist among every (RNN, PDSN) pair that will form an RP connection. 463 Also, it is assumed that the session specific information is 464 authenticated by means outside the scope of this draft. 466 Xu et al. Expires 22 April 2000 9 467 Several potential vulnerabilities exist if these assumptions are not 468 met. First, if the network connecting the RNN and PDSN is accessible 469 to an attacker, user traffic may be intercepted and/or spoofed if 470 there are no other end-to-end security mechanisms in place. Second, 471 the Mobile IP control messages must be authenticated, to prevent 472 tunnel setup and tear down by unauthorized parties. Mobile IP 473 Authentication Extensions are used to provide this additional 474 protection for control messages. Finally, if session specific 475 information is not authenticated, a denial-of-service attack is 476 possible if a RNN unknowingly sends a registration request to the 477 PDSN with a spoofed session specific extension. The PDSN would then 478 send an explicit tunnel tear down to the previous RNN, causing user 479 traffic to be misdirected to the new RNN. This would cause a loss of 480 service and possibly interception of traffic, depending on what 481 other security measures are in place. 483 References 485 [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 486 1996. 487 [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 488 1998. 489 [3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic 490 Routing Encapsulation (GRE)", RFC 1701, October 1994. 491 [4] Dommety, Leung, "Mobile IP Vendor/Organization-Specific 492 Extensions", draft-ietf-mobileip-vendor-ext-00.txt, August 493 1999. 495 Authors Addresses 497 Yingchun Xu Rajesh Bhalla 498 3Com Corporation 3Com Corporation 499 1800 West Central Rd. 1800 W. Central Road 500 Mount Prospect, Mt. Prospect, 501 USA 60056 IL 60056 502 Phone: (847) 342-6814 Phone: (847) 797-2618 503 Email: Yingchun_Xu@3com.com Email: rajesh_bhalla@3com.com 505 Karl Freter Ed Campbell 506 3Com Corporation 3Com Corporation 507 1800 W. Central Road 1800 W. Central Road 508 Mt. Prospect, IL 60056 Mt. Prospect, IL 60056 509 Phone: (847) 222-2268 Phone: (847) 342-6769 510 Email: karl_freter@3com.com Email: ed_campbell@3com.com 512 Xu et al. Expires 22 April 2000 10 513 Eileen McGrath Hadwen 514 Alcatel 515 PO Box 4442, Boulder CO 80306 516 Phone: 303 499 1496 517 Mobile: 303 517 0407 518 Email: mcgrath.hadwen@worldnet.att.net 520 Gopal Dommety Kirit Joshi 521 Cisco Systems Cisco Systems 522 170 West Tasman Drive 170 West Tasman Drive 523 San Jose, CA 95134 San Jose, CA 95134 524 Phone: (408) 525-1404 Phone: (408) 525 7367 525 Email: gdommety@cisco.com Email: kjoshi@cisco.com 527 Parviz Yegani 528 Ericson Wireless Communication Inc. 529 6455 Lusk Blvd. 530 San Diego, CA 92121 531 Phone: (858) 332-6017 532 Email: p.yeqani@ericsson.com 534 Byung-Keun Lim, 535 LG Information & Communications, Ltd. 536 533, Hogye-dong, Dongan-ku, Anyang-shi, 537 Kyungki-do,431-080, Korea 538 Phone: +82-343-450-7199 539 Email: bklim@lgic.co.kr 541 Peter J. McCann Thomas Towle 542 Lucent Technologies Lucent Technologies 543 Rm 2Z-305 Rm. 2D-225 544 263 Shuman Blvd 263 Shuman Blvd 545 Naperville, IL 60566 Naperville, IL 60566 546 Phone: (630) 713 9359 Phone: 630-979-7303 547 EMail: mccap@lucent.com Email: ttowle@lucent.com 549 Jay Jayapalan 550 Motorola Inc. 551 1501 W Shure Drive 552 Arlington Heights,IL 60004 553 Phone: (847) 642-4031 554 Email: jayapal@cig.mot.com 556 Peter W. Wenzel Carey B. Becker 557 Nortel Networks Nortel Networks 558 2201 Lakeside Blvd. 2201 Lakeside Blvd. 559 Richardson, TX 75082, USA Richardson, TX 75082, USA 560 Phone: (972) 684-7134 (972) 685-0560 561 wenzel@nortelnetworks.com becker@nortelnetworks.com 563 Mark A. Lipford 564 Sprint PCS 565 8001 College Blvd. Suite 210 567 Xu et al. Expires 22 April 2000 11 568 KSOPKZ0101 569 Overland Park, KS 66210 570 Phone: 913-664-8335 571 PCS: 913-226-9060 572 Email: Mlipfo01@sprintspectrum.com 574 Xu et al. Expires 22 April 2000 12