One document matched: draft-ietf-mobileip-3gwireless-ext-05.txt
Differences from draft-ietf-mobileip-3gwireless-ext-04.txt
Mobile IP Working Group Yingchun Xu (editor)
Internet Draft WaterCove Networks
November, 2000 Rajesh Bhalla
Ed Campbell
Karl Freter
3Com Corporation
Eileen McGrath Hadwen
Alcatel
Gopal Dommety
Kirit Joshi
Cisco Systems
Parviz Yegani
Ericson Wireless Communication Inc
Takeo Matsumura
FUJITSU
Atsushi Teshima
HITACHI Ltd.
Lee Dong Hyun
HYUNDAI Electronics
Naoto Itoh
IDO Corporation
Kimihiro Ohki
KDD Corporation
Byung-Keun Lim
LG Information & Communications,Ltd
Peter J. McCann
Thomas Towle
Lucent Technologies
Jay Jayapalan
Motorola Inc.
Peter W. Wenzel
Carey B. Becker
James Jiang
Nortel Networks
Shota Shikano
Oki Electric Industry Co., Ltd.
Woojune Kim
Yong Chang
Bill Semper
Samsung Electronics Ltd.
Jun Mo Koo
SK Telecom
Mark A. Lipford
Frederic Leroudier
Sprint PCS
Jim Gately
USWest Advanced Technologies
Mobile IP Based Micro Mobility Management Protocol in
The Third Generation Wireless Network
<draft-ietf-mobileip-3gwireless-ext-05.txt>
Xu et al. Expires April 2001 1
<draft-ietf-mobileip-3gwireless-ext-05.txt> Nov. 2000
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at anytime. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines extensions to the Mobile IP protocol [1] to
allow mobility management for the interface between a radio network
and a packet data network in the third generation cdma2000 network.
Mobile IP requires link layer connectivity between the Mobile Node
and the Foreign Agent. This draft proposes a protocol for achieving
this when the physical layer terminates at a point distant from the
FA. In particular, this protocol applies to cdma2000 networks where
the physical layer terminates at a Radio Network Node (RNN) and the
FA resides inside a separate Packet Data Serving Node (PDSN). The
PDSN is responsible for establishing, maintaining, and terminating
the link layer to the Mobile Node. A RNN is responsible for relaying
the link layer protocol between a Mobile Node and its corresponding
PDSN.
The interface between the RNN and the PDSN is called the RP
interface. This interface requires mobility management for handling
handoff from one RNN to another without interrupting end to end
communication. It also requires the support of the link layer
protocol encapsulation.
1. Introduction
This document defines extensions to the Mobile IP protocol [1] to
allow mobility management for the interface between a radio network
and a packet data network in the third generation cdma2000 network.
Mobile IP requires link layer connectivity between the Mobile Node
and the Foreign Agent. This draft proposes a protocol for achieving
Xu et al. Expires April 2001 2
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
this when the physical layer terminates at a point distant from the
FA. In particular, this protocol applies to cdma2000 networks where
the physical layer terminates at a Radio Network Node (RNN) and the
FA resides inside a separate Packet Data Serving Node (PDSN). The
PDSN is responsible for establishing, maintaining, and terminating
the link layer to the Mobile Node. A RNN is responsible for relaying
the link layer protocol between a Mobile Node and its corresponding
PDSN.
The interface between the RNN and the PDSN is called the RP
interface. This interface requires mobility management for handling
handoff from one RNN to another without interrupting end to end
communication. It also requires the support of the link layer
protocol encapsulation.
The messages used for mobility management across the RP interface
include Registration Request, Registration Reply, Registration
Update and Registration Acknowledge. Both Registration Request and
Registration Update messages MUST be sent with UDP using well-known
port number 699.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
2. Glossary
CDMA Code Division Multiple Access
FA Foreign Agent
HA Home Agent
MN Mobile Node
PDSN Packet Data Serving Node
RNN Radio Network Node
RP Interface between the RNN and the PDSN
3. cdma2000 Network RP Interface Overview
The high level architecture of a third generation cdma2000 network
RP interface is shown in Figure 1.
+---------+ +---------+ +---------+
| | | | | |
| RNN |----RP------| PDSN |---------| HA |
| | Interface | | | |
+---------+ +---------+ +---------+
/|\
| Visited Access Home Network
| Provider Network
|
|
\|/
+--------+
Xu et al. Expires April 2001 3
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
| Mobile |
| Node |
+--------+
Figure 1: The Third Generation cdma2000 Network RP Interface
In above figure 1, the PDSN will be responsible for establishing,
maintaining, and terminating the link layer to the Mobile Node. It
initiates the authentication, authorization, and accounting for the
Mobile Node and optionally, securely tunnels to the Home Agent.
The RNN is responsible for mapping the Mobile Node identifier
reference to a unique link layer identifier used to communicate with
the PDSN. RNN validates the Mobile Station for access service and
manages the physical layer connection to the Mobile Node.
4. Mobile IP Extensions
This section describes extensions to the Mobile IP protocol for the
RP interface within the third generation cdma2000 network.
4.1 Registration Request
In a cdma2000 network, the mobile node initiates a connection by
sending a call setup indication to the RNN across the radio network.
When this indication is received by a RNN, a Registration Request
will be sent from the RNN to the PDSN to setup a new RP session.
A RNN MUST send a Registration Request with the GRE encapsulation
and the reverse tunneling bit set. The Home Address field is set to
zero. The Home Agent field will be assigned to the IP address of the
PDSN and the Care-of Address field will be assigned to the IP
address of RNN.
When a Registration Request is received by a PDSN, the information
from the Session Specific Extension (see next section) will be used
to identify a RP session. When a registration is accepted, a GRE
tunnel will be created for this Mobile Node.
The message is sent with UDP using well-known port number 699.
The fields of the Registration Request message are shown below:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|V|T| | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xu et al. Expires April 2001 4
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
G This bit MUST be set to 1 for GRE tunneling.
T This bit MUST be set to 1 for reverse
tunneling.
Home Address
The field is set to zero.
Home Agent
This field is assigned to the IP address of the
PDSN.
Care-of Address
This field is assigned to the IP address of
RNN.
Extensions
The Session Specific Extension as described in
the next section MUST be included along with
the ones described in RFC2002. Specifically,
the MN-HA Authentication extension as described
in RFC2002 MUST be included along with this
extension.
4.2 Session Specific Extension
This extension is defined to carry information related to the
session between a Mobile Node and its serving PDSN.
The detailed format of the extension is shown as follows.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MN Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xu et al. Expires April 2001 5
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
| MN ID Type | MN ID Length | MN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 39 (not-skippable).
Length This is a one octet field and it indicates the
length (in bytes) of the extension, NOT
including the Type and Length fields.
Protocol Type
This is a two octet field. It indicates the
type of the protocol to be tunneled across the
RP interface. It is same as the Protocol Type
field in the GRE header.
Key
This is a four octet value assigned by the RNN
and inserted in every GRE frame across the RP
interface during user data tunneling.
Reserved
This is a two octet field. It is not used and is
set to zero.
MN Connection ID
This is a two octet field and it is used to
differentiate the multiple sessions from the
same Mobile Node. It is locally unique to a
Mobile Node.
MN ID Type
This is a two octet field and it indicates the
type of the following Mobile Node ID value.
Type value 1 will be reserved for International
Mobile Station Identity (IMSI) encoded in ASCII
format. For detailed description of the IMSI,
see reference [8].
MN ID Length
This is a one octet field and it indicates the
length (in bytes) of the following Mobile Node
ID field. For IMSI MN ID encoded in ASCII
format, the length field value ranges from 10
to 15 bytes.
MN ID
This is the Mobile Node ID, which is globally
unique. It is used to uniquely identify a Mobile
Node.
Xu et al. Expires April 2001 6
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
For Type 1 MN ID, the most significant digit of
IMSI will be coded in ASCII and stored as the
most significant byte of the MN ID.
This extension MUST be included in the Registration Request,
Registration Reply, Registration Update and Registration Acknowledge
(see section 4.5) messages. It will be included before the MN-HA
Authentication extension in the Registration Request and
Registration Reply messages and before the Registration Update
Authentication Extension in the Registration Update and Registration
Acknowledge messages.
The MN ID and the MN Connection ID together will uniquely identify a
Mobile Session.
4.3 Registration Reply
The Registration Reply will be sent by a PDSN following the
procedure as described in [1]. The Home Address field will be the
same value as the Home Address field from the corresponding
Registration Request message received by the PDSN.
The message is sent with UDP to the source port of the received
Registration Request message.
4.4 Registration Update/Acknowledge
Two new messages are defined to support PDSN initiated RP tunnel
tear down and to speed up resource reclamation on the RNN.
The Registration Update message is used for notification of the
change of the registration associated with a call. It shall be sent
by the PDSN to the previous RNN when a RNN to RNN handoff happens.
The Registration Update message is sent with UDP using well-known
port number 699. And the Registration Acknowledge message is sent
with UDP to the source port from the received correspondent
Registration Update message.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
Xu et al. Expires April 2001 7
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The format of the Registration Update message is illustrated above,
and contains the following fields:
Type 20
Reserved Sent as 0; ignored on reception.
Home Address Sent as 0;
Home Agent Address
The IP Address of the PDSN.
Identification
A 64-bit number assigned by the node sending
the Registration Update message. It is used to
assist in matching requests with replies, and
in protecting against replay attacks.
Extensions
Both Registration Update Authentication
Extension (see section 4.6) and Session
Specific Extension (see section 4.2) SHALL be
included.
A Registration Update shall be sent by a PDSN to indicate the
closure of a RP session. The RNN may reclaim the resource associated
with that session.
A Registration Acknowledge message is used to acknowledge receipt of
a Registration Update message. It MUST be sent by a node receiving a
Registration Update message.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care Of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Xu et al. Expires April 2001 8
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
The format of the Registration Acknowledge message is illustrated
above, and contains the following fields:
Type 21
Status If the Status is nonzero, this acknowledgment is
negative.
Reserved
Sent as 0; ignored on reception.
Home Address
Copied from the Registration Update message
being acknowledged.
Care of Address
The IP address of the RNN.
Identification
Copied from the Registration Update message
being acknowledged.
Extensions
Both Registration Update Authentication
Extension (see section 4.6) and Session
Specific Extension (see section 4.2) SHALL be
included.
Allowable values for the Status include:
0 successful acknowledgement
128 reason unspecified
129 administratively prohibited
131 sending node failed authentication
133 identification mismatch
134 poorly formed Registration Update
4.5 Registration Update Authentication Extension
The Registration Update Authentication extension is used to
authenticate the Registration Update and Registration Acknowledge
messages. It has the same format and default algorithm support
requirements as the authentication extension defined for Mobile IP
protocol [1], but with a different type (40). The authenticator
value is computed from the stream of bytes including the shared
secret, the UDP payload all prior extensions in their entirety, and
the type and length of this extension, but not including the
authenticator field itself nor the UDP header. The secret used for
computing the authenticator field is shared between the RN and PDSN.
This extension is required in both Registration Update and
Registration Acknowledge messages.
Xu et al. Expires April 2001 9
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
4.6 Summary
The extensions to Mobile IP include enabling the GRE encapsulation
and reverse tunneling during Registration. A new extension called
Session Specific Extension is defined and is mandatory in the
Registration Request, Registration Reply, Registration Update and
Registration Acknowledge messages. The Home Address field MUST be
set to zero in the Registration Request, Registration Reply,
Registration Update and Registration Acknowledge messages.
Two new messages (Registration Update and Registration Acknowledge)
are defined to support the RP session disconnection in order to
speed up resource reclamation.
5.0 GRE Encapsulation
GRE encapsulation as described in [3] shall be supported during user
data transmission. A new protocol type might be required to support
the link layer protocol defined for the third generation cdma2000
network. The Key field shall be required and its value shall be same
as the one from the Session Specific Extension as described above.
The sequence number may be required, depending on the requirement of
the protocol encapsulated within the GRE frame.
During traffic tunneling, the sender will insert the Key value from
the Registration Request message into the Key field of the GRE
header. The receiver will use the Key value from the GRE header to
decide where to forward the user data.
6.0 IANA Considerations
This document specifies two new messages and two new extensions to
Mobile IP protocol [1]. The numbers to be assigned to these messages
and extensions have been taken from the numbering space assigned to
Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4].
The Registration Request and Registration Update messages MUST be
sent with UDP using well-known port number 699. This port number is
chosen from the unassigned port range as specified in RFC1700 [9].
The Registration Update and Registration Acknowledge messages
defined in section 4.4 MUST be assigned the Type values of 20 and 21
respectively.
The Session Specific Extension defined in section 4.2 MUST be
assigned the Type value of 39, and the Registration Update
Authentication Extension defined in section 4.5 MUST be assigned a
value of 40. The Status values defined in section 4.4 are the error
codes defined in RFC 2002 [1]. They correspond to the error values
conventionally associated with a rejection by a home agent (i.e.,
Xu et al. Expires April 2001 10
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
the values from the range 128-255). The IANA MUST record the Status
values as defined in section 4.4 of this document.
With these assignments, the Type values assigned to the two new
messages and to two new extensions, and the error values for the
Status field, have been identified as not conflicting with any
numbers defined for Mobile IP to date and documented at
http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.
7.0 Security Considerations
The protocol presented in this draft is designed for use over a
protected, private network between RNN and PDSN. Pre-arranged
security associations in the style of Mobile IPv4 are assumed to
exist among every (RNN, PDSN) pair that will form an RP connection.
Also, it is assumed that the session specific information is
authenticated by means outside the scope of this draft.
Several potential vulnerabilities exist if these assumptions are not
met. First, if the network connecting the RNN and PDSN is accessible
to an attacker, user traffic may be intercepted and/or spoofed if
there are no other end-to-end security mechanisms in place. Second,
the Mobile IP control messages must be authenticated, to prevent
tunnel setup and tear down by unauthorized parties. Mobile IP
Authentication Extensions are used to provide this additional
protection for control messages. Finally, if session specific
information is not authenticated, a denial-of-service attack is
possible if a RNN unknowingly sends a registration request to the
PDSN with a spoofed session specific extension. The PDSN would then
send an explicit tunnel tear down to the previous RNN, causing user
traffic to be misdirected to the new RNN. This would cause a loss of
service and possibly interception of traffic, depending on what
other security measures are in place.
8.0 Acknowledgments
The authors of this draft would like to thank Charles E. Perkins and
David B. Johnson for the ideas presented in the Route Optimization
draft [7].
References
[1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
1996.
[2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May
1998.
Xu et al. Expires April 2001 11
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
[3] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for
Mobile IP". RFC 2356, June 1998.
[4] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network
Address Identifier Extension". RFC2794, March 2000.
[5] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/
Response Extensions". draft-ietf-mobileip-challenge-06.txt,
October 1999. (work in progress).
[6] Charles E. Perkins and David B. Johnson. "Route Optimization in
Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999.
(work in progress).
[7] TIA/EIA/IS-95-B
[8] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October
1994.
[9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P.,
"Generic Routing Encapsulation (GRE)," RFC 2784, March 2000.
[10] Gopal Dommety. "Key and Sequence Number Extensions to GRE".
RFC2890, September 2000.
Author's Addresses
Yingchun Xu
WaterCove Networks
285 Billerica Road
Chelmsford, MA,
USA 01824
Phone: (847) 477-9280
Email: yxu@watercove.com
Rajesh Bhalla
3Com Corporation
1800 West Central Road
Mount Prospect,
USA 60056
Phone: (847) 797-2618
Email: rajesh_bhalla@3com.com
Karl Freter
3Com Corporation
1800 W. Central Road
Mount Prospect, IL 60056
Phone: (847) 222-2268
Email: karl_freter@3com.com
Xu et al. Expires April 2001 12
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
Ed Campbell
3Com Corporation
1800 W. Central Road
Mount Prospect, IL 60056
Phone:(847) 342-6769
Email: ed_campbell@3com.com
Eileen McGrath Hadwen
Alcatel
PO Box 4442,
Boulder CO 80306
Phone: 303 499 1496
Email: mcgrath.hadwen@worldnet.att.net
Gopal Dommety
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 525-1404
Email: gdommety@cisco.com
Kirit Joshi
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 525 7367
Email: kjoshi@cisco.com
Parviz Yegani
Ericson Wireless Communication Inc.
6455 Lusk Blvd.
San Diego, CA 92121
Phone: (858) 332-6017
Email: p.yeqani@ericsson.com
Takeo Matsumura
FUJITSU
Kamiodanaka
Nakahara-ku, Kawasaki-City
Phone: +81-44-740-8109
Email: matumura@mcs.ts.fujitsu.co.jp
Atsushi Teshima
HITACHI Ltd.
216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567
Phone:+81-45-865-7003
Email: atsushi_teshima@cm.tcd.hitachi.co.jp
Lee Dong Hyun
HYUNDAI Electronics Industry
KOREA Kyungkido Icheonsi 435-050
Phone: 82-336-630-2756
Email: jihs@hei.co.kr
Xu et al. Expires April 2001 13
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
Naoto Itoh
IDO Corporation
Gobancho YS building
12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361
Phone: +81-3-3263-9660
Email: nao-itoh@ido.co.jp
Kimihiro Ohki
KDD Corporation
3-2, Nishi-Shinjuku 2-chome,
Shinjuku-ku, Tokyo 163-8003, Japan
Phone: +81-3-3347-5477
Email: ki-ohki@kdd.co.jp
Byung-Keun Lim,
LG Information & Communications, Ltd.
533, Hogye-dong, Dongan-ku, Anyang-shi,
Kyungki-do,431-080, Korea
Phone: +82-343-450-7199
Email: bklim@lgic.co.kr
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566
Phone: (630) 713 9359
EMail: mccap@lucent.com
Thomas Towle
Lucent Technologies
Rm. 2D-225
263 Shuman Blvd
Naperville, IL 60566
Phone: 630-979-7303
Email: ttowle@lucent.com
Jay Jayapalan
Motorola Inc.
1501 W Shure Drive
Arlington Heights,IL 60004
Phone: (847) 642-4031
Email: jayapal@cig.mot.com
Peter W. Wenzel
Nortel Networks
2201 Lakeside Blvd.
Richardson, TX 75082, USA
Phone: (972) 684-7134
Email: wenzel@nortelnetworks.com
Carey B. Becker
Xu et al. Expires April 2001 14
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
Nortel Networks
2201 Lakeside Blvd.
Richardson, TX 75082, USA
Phone: (972) 685-0560
Email: becker@nortelnetworks.com
James Jiang
Nortel Networks
2201 Lakeside Blvd.
Richardson, TX 75082, USA
Phone: (972)684-5885
Email: jjiang@nortelnetworks.com
Shota Shikano
Oki Electric Industry Co., Ltd.
Phone:+81-3-3454-2111
Email: shikano471@oki.co.jp
Woojune Kim
Samsung Electronics Ltd.
11th Fl, Samsung Plaza Bldg,
263, Seohyeon-dong, Pundang-gu,
Sungnam-shi, Kyunggi-do,
463-050 Pundang P.O. Box 32, Korea
Phone: +82-342-779-8526
Email: keg@telecom.samsung.co.kr
Yong Chang
Samsung Electronics Ltd.
11th Fl, Samsung Plaza Bldg,
263, Seohyeon-dong, Pundang-gu,
Sungnam-shi, Kyunggi-do,
463-050 Pundang P.O. Box 32, Korea
Phone: +82-342-779-6822
Email : yong@telecom.samsung.co.kr
Bill Semper
Samsung Telecommunications
1130 Arapaho Rd
Richardson, TX 75082
Phone: 972-761-7996
Email: bsemper@telecom.samsung.com
Jun Mo Koo
SK Telecom
Phone: 650-568-5762
Email: jmkoo@sktelecom.com
Mark A. Lipford
Sprint PCS
8001 College Blvd. Suite 210
KSOPKZ0101
Overland Park, KS 66210
Xu et al. Expires April 2001 15
<draft-ietf-mobileip-3Gwireless-ext-05.txt> Nov. 2000
Phone: 913-664-8335
Email: Mlipfo01@sprintspectrum.com
Frederic Leroudier
Sprint PCS
8001 College Blvd. Suite 210
KSOPKZ0101
Overland Park, KS 66210
Phone: 913-664-8350
Email: FLerou01@sprintspectrum.com
Jim Gately
USWest Advanced Technologies
4001 Discovery Drive
Boulder, CO 80303
Phone: 303-541-6415
Email: jgately@uswest.com
Xu et al. Expires April 2001 16
| PAFTECH AB 2003-2026 | 2026-04-21 08:18:50 |