[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Mobile IP Working Group                           Yingchun Xu (editor)
Internet Draft                                      WaterCove Networks
May, 2001                                                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-06.txt>



Xu et al.                 Expires Nov. 2001                         1

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001



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 Nov. 2001                         2

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


   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 Nov. 2001                         3

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


     | 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 Nov. 2001                         4

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


      |                        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 Nov. 2001                         5

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


      |        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 Nov. 2001                         6

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001



                       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 Nov. 2001                         7

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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 Nov. 2001                         8

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


   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 Nov. 2001                         9

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001



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

   The recommended message type value and extension type value have
   been used in 3GPP2 standard IOSv4.1. It is desirable to have the
   same type value assigned by IANA.

   The well-known UDP port number 699 used for the Registration Request
   and Registration Update Message was chosen from the unassigned port
   range. They were requested from and have been assigned by IANA and
   are listed at: ftp://ftp.isi.edu/in-notes/iana/assignments/port-
   numbers.

   The Registration Update and Registration Acknowledge messages
   defined in section 4.4 SHOULD be assigned the Type values of 20 and
   21 respectively.

   The Session Specific Extension defined in section 4.2 SHOULD be
   assigned the Type value of 39, and the Registration Update
   Authentication Extension defined in section 4.5 SHOULD 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 Nov. 2001                        10

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


   the values from the range 128-255). The IANA SHOULD 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 Nov. 2001                        11

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


   [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 Nov. 2001                        12

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


     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 Nov. 2001                        13

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001



     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 Nov. 2001                        14

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


     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 Nov. 2001                        15

             <draft-ietf-mobileip-3Gwireless-ext-06.txt>     May 2001


     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 Nov. 2001                        16


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/