draft-ietf-mobileip-3gwireless-ext-01.txt   draft-ietf-mobileip-3gwireless-ext-02.txt 
Mobile IP Working Group Yingchun Xu (editor) Mobile IP Working Group Yingchun Xu (editor)
Internet Draft Rajesh Bhalla Internet Draft Rajesh Bhalla
November 1999 Ed Campbell January 2000 Ed Campbell
Karl Freter Karl Freter
3Com Corporation 3Com Corporation
Eileen McGrath Hadwen Eileen McGrath Hadwen
Alcatel Alcatel
Gopal Dommety Gopal Dommety
Kirit Joshi Kirit Joshi
Cisco Systems Cisco Systems
Parviz Yegani Parviz Yegani
Ericson Wireless Communication Inc. Ericson Wireless Communication Inc.
Takeo Matsumura Takeo Matsumura
skipping to change at line 51 skipping to change at line 51
Bill Semper Bill Semper
Samsung Telecommunications Samsung Telecommunications
Mark A. Lipford Mark A. Lipford
Frederic Leroudier Frederic Leroudier
Sprint PCS Sprint PCS
Jim Gately Jim Gately
USWest Advanced Technologies USWest Advanced Technologies
Mobile IP Based Micro Mobility Management Protocol in Mobile IP Based Micro Mobility Management Protocol in
The Third Generation Wireless Network The Third Generation Wireless Network
<draft-ietf-mobileip-3gwireless-ext-01.txt> <draft-ietf-mobileip-3gwireless-ext-02.txt>
Xu et al. Expires May 2000 1 Xu et al. Expires July 2000 1
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute and working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
skipping to change at line 107 skipping to change at line 107
1. Introduction 1. Introduction
This document defines extensions to the Mobile IP protocol [1] to This document defines extensions to the Mobile IP protocol [1] to
allow mobility management for the interface between a radio network allow mobility management for the interface between a radio network
and a packet data network in the third generation cdma2000 network. and a packet data network in the third generation cdma2000 network.
Mobile IP requires link layer connectivity between the Mobile Node Mobile IP requires link layer connectivity between the Mobile Node
and the Foreign Agent. This draft proposes a protocol for achieving and the Foreign Agent. This draft proposes a protocol for achieving
this when the physical layer terminates at a point distant from the this when the physical layer terminates at a point distant from the
Xu et al. Expires May 2000 2 Xu et al. Expires July 2000 2
FA. In particular, this protocol applies to cdma2000 networks where FA. In particular, this protocol applies to cdma2000 networks where
the physical layer terminates at a Radio Network Node (RNN) and the the physical layer terminates at a Radio Network Node (RNN) and the
FA resides inside a separate Packet Data Serving Node (PDSN). The FA resides inside a separate Packet Data Serving Node (PDSN). The
PDSN is responsible for establishing, maintaining, and terminating PDSN is responsible for establishing, maintaining, and terminating
the link layer to the Mobile Node. A RNN is responsible for relaying the link layer to the Mobile Node. A RNN is responsible for relaying
the link layer protocol between a Mobile Node and its corresponding the link layer protocol between a Mobile Node and its corresponding
PDSN. PDSN.
The interface between the RNN and the PDSN is called the RP The interface between the RNN and the PDSN is called the RP
interface. This interface requires mobility management for handling interface. This interface requires mobility management for handling
skipping to change at line 159 skipping to change at line 159
| |
| |
\|/ \|/
+--------+ +--------+
| Mobile | | Mobile |
| Node | | Node |
+--------+ +--------+
Figure 1: The Third Generation cdma2000 Network RP Interface Figure 1: The Third Generation cdma2000 Network RP Interface
Xu et al. Expires May 2000 3 Xu et al. Expires July 2000 3
In above figure 1, the PDSN will be responsible for establishing, In above figure 1, the PDSN will be responsible for establishing,
maintaining, and terminating the link layer to the Mobile Node. It maintaining, and terminating the link layer to the Mobile Node. It
initiates the authentication, authorization, and accounting for the initiates the authentication, authorization, and accounting for the
Mobile Node and optionally, securely tunnels to the Home Agent. Mobile Node and optionally, securely tunnels to the Home Agent.
The RNN is responsible for mapping the Mobile Node identifier The RNN is responsible for mapping the Mobile Node identifier
reference to a unique link layer identifier used to communicate with reference to a unique link layer identifier used to communicate with
the PDSN. RNN validates the Mobile Station for access service and the PDSN. RNN validates the Mobile Station for access service and
manages the physical layer connection to the Mobile Node. manages the physical layer connection to the Mobile Node.
skipping to change at line 213 skipping to change at line 213
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address | | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Identification + + Identification +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... | Extensions ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Xu et al. Expires May 2000 4 Xu et al. Expires July 2000 4
Type 1 (Registration Request) Type 1 (Registration Request)
G This bit MUST be set to 1 for GRE tunneling. G This bit MUST be set to 1 for GRE tunneling.
T This bit MUST be set to 1 for reverse T This bit MUST be set to 1 for reverse
tunneling. tunneling.
Home Address Home Address
The field is set to zero. The field is set to zero.
skipping to change at line 260 skipping to change at line 260
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key | | Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | MN Connection ID | | reserved | MN Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN ID Type | MN ID Length | MN ID | | MN ID Type | MN ID Length | MN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN ID ą | MN ID ą
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 39 (non-skippable). Type 39 (not-skippable).
Xu et al. Expires May 2000 5 Xu et al. Expires July 2000 5
Length This is a one octet field and it indicates the Length This is a one octet field and it indicates the
length (in bytes) of the extension, NOT length (in bytes) of the extension, NOT
including the Type and Length fields. including the Type and Length fields.
Protocol Type Protocol Type
This is a two octet field. It indicates the type This is a two octet field. It indicates the type
of the protocol to be tunneled across the RP of the protocol to be tunneled across the RP
interface. It is same as the Protocol Type field interface. It is same as the Protocol Type field
in the GRE header. in the GRE header.
skipping to change at line 299 skipping to change at line 299
MN ID Length MN ID Length
This is a one octet field and it indicates the This is a one octet field and it indicates the
length (in bytes) of the following Mobile Node length (in bytes) of the following Mobile Node
ID field. ID field.
MN ID This is the Mobile Node ID, which is globally MN ID This is the Mobile Node ID, which is globally
unique. It is used to uniquely identify a Mobile unique. It is used to uniquely identify a Mobile
Node. Node.
This extension MUST be included in the Registration Request and This extension MUST be included in the Registration Request,
Registration Update (see section 4.5) messages. It will be included Registration Reply, Registration Update and Registration Acknowledge
before the MN-HA Authentication extension in the Registration (see section 4.5) messages. It will be included before the MN-HA
Request message and before the Registration Update Authentication Authentication extension in the Registration Request and
Extension in the Registration Update message. 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 The MN ID and the MN Connection ID together will uniquely identify a
Mobile Session. Mobile Session.
4.3 Registration Reply 4.3 Registration Reply
The Registration Reply will be sent by a PDSN following the The Registration Reply will be sent by a PDSN following the
procedure as described in [1]. The Home Address field will be the procedure as described in [1]. The Home Address field will be the
same value as the Home Address field from the corresponding same value as the Home Address field from the corresponding
Registration Request message received by the PDSN. Registration Request message received by the PDSN.
Xu et al. Expires May 2000 6 Xu et al. Expires July 2000 6
4.4 Registration Update/Acknowledge 4.4 Registration Update/Acknowledge
Two new messages are defined to support PDSN initiated RP tunnel Two new messages are defined to support PDSN initiated RP tunnel
tear down and to speed up resource reclamation on the RNN. tear down and to speed up resource reclamation on the RNN.
The Registration Update message is used for notification of the The Registration Update message is used for notification of the
change of the registration associated with a call. It shall be sent 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. by the PDSN to the previous RNN when a RNN to RNN handoff happens.
skipping to change at line 367 skipping to change at line 369
A 64-bit number assigned by the node sending A 64-bit number assigned by the node sending
the Registration Update message. It is used to the Registration Update message. It is used to
assist in matching requests with replies, and assist in matching requests with replies, and
in protecting against replay attacks. in protecting against replay attacks.
Extensions Extensions
Both Registration Update Authentication Both Registration Update Authentication
Extension (see section 4.6) and Session Extension (see section 4.6) and Session
Specific Extension (see section 4.2) SHALL be Specific Extension (see section 4.2) SHALL be
included. included.
Xu et al. Expires July 2000 7
A Registration Update shall be sent by a PDSN to indicate the A Registration Update shall be sent by a PDSN to indicate the
closure of a RP session. The RNN may reclaim the resource associated closure of a RP session. The RNN may reclaim the resource associated
with that session. with that session.
Xu et al. Expires May 2000 7
A Registration Acknowledge message is used to acknowledge receipt of A Registration Acknowledge message is used to acknowledge receipt of
a Registration Update message. It MUST be sent by a node receiving a a Registration Update message. It MUST be sent by a node receiving a
Registration Update message. Registration Update message.
0 1 2 3 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 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 | Status | | Type | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | | Home Address |
skipping to change at line 415 skipping to change at line 417
being acknowledged. being acknowledged.
Care of Address Care of Address
The IP address of the RNN. The IP address of the RNN.
Identification Identification
Copied from the Registration Update message Copied from the Registration Update message
being acknowledged. being acknowledged.
Extensions Extensions
Registration Update Authentication Both Registration Update Authentication
Extension SHALL be included. Extension (see section 4.6) and Session
Specific Extension (see section 4.2) SHALL be
included.
Xu et al. Expires July 2000 8
Allowable values for the Status include: Allowable values for the Status include:
0 successful acknowledgement 0 successful acknowledgement
128 reason unspecified 128 reason unspecified
Xu et al. Expires May 2000 8
129 administratively prohibited 129 administratively prohibited
131 sending node failed authentication 131 sending node failed authentication
133 identification mismatch 133 identification mismatch
134 poorly formed Registration Update 134 poorly formed Registration Update
4.5 Registration Update Authentication Extension 4.5 Registration Update Authentication Extension
The Registration Update Authentication extension is used to The Registration Update Authentication extension is used to
authenticate the Registration Update and Registration Acknowledge authenticate the Registration Update and Registration Acknowledge
messages. It has the same format and default algorithm support messages. It has the same format and default algorithm support
skipping to change at line 448 skipping to change at line 451
the type and length of this extension, but not including the the type and length of this extension, but not including the
authenticator field itself nor the UDP header. The secret used for authenticator field itself nor the UDP header. The secret used for
computing the authenticator field is shared between the RN and PDSN. computing the authenticator field is shared between the RN and PDSN.
This extension is required in both Registration Update and This extension is required in both Registration Update and
Registration Acknowledge messages. Registration Acknowledge messages.
4.6 Summary 4.6 Summary
The extensions to Mobile IP include enabling the GRE encapsulation The extensions to Mobile IP include enabling the GRE encapsulation
and reverse tunneling during Registration. A new extension called and reverse tunneling during Registration. A new extension called
Session Specific Extension is defined and is mandatory in both Session Specific Extension is defined and is mandatory in the
Registration Request and Registration Update messages. The Home Registration Request, Registration Reply, Registration Update and
Address field MUST be set to zero in the Registration Request, Registration Acknowledge messages. The Home Address field MUST be
Registration Reply, Registration Update and Registration Acknowledge set to zero in the Registration Request, Registration Reply,
messages. Registration Update and Registration Acknowledge messages.
Two new messages (Registration Update/Acknowledge) are defined to Two new messages (Registration Update and Registration Acknowledge)
support the RP session disconnection in order to speed up resource are defined to support the RP session disconnection in order to
reclamation. speed up resource reclamation.
5.0 GRE Encapsulation 5.0 GRE Encapsulation
GRE encapsulation as described in [3] shall be supported during user GRE encapsulation as described in [3] shall be supported during user
data transmission. A new protocol type might be required to support data transmission. A new protocol type might be required to support
the link layer protocol defined for the third generation cdma2000 the link layer protocol defined for the third generation cdma2000
network. The Key field shall be required and its value shall be same network. The Key field shall be required and its value shall be same
as the one from the Session Specific Extension as described above. as the one from the Session Specific Extension as described above.
The sequence number may be required, depending on the requirement of The sequence number may be required, depending on the requirement of
the protocol encapsulated within the GRE frame. the protocol encapsulated within the GRE frame.
During traffic tunneling, the sender will insert the Key value from During traffic tunneling, the sender will insert the Key value from
the Registration Request message into the Key field of the GRE the Registration Request message into the Key field of the GRE
Xu et al. Expires July 2000 9
header. The receiver will use the Key value from the GRE header to header. The receiver will use the Key value from the GRE header to
decide where to forward the user data. decide where to forward the user data.
6.0 IANA Considerations 6.0 IANA Considerations
Xu et al. Expires May 2000 9 This document specifies two new messages and two new extensions to
The numbers for the Mobile IP Session Specific Extension (section Mobile IP protocol [1]. The numbers to be assigned to these messages
4.2)and Registration Update Authentication Extension (section 4.5) and extensions have been taken from the numbering space assigned to
are taken from the numbering space defined for Mobile IP extensions Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4].
defined in RFC 2002 [1] as extended in RFC 2356 [4]. The numbering
for the extensions SHOULD NOT conflict with values specified in the The Registration Update and Registration Acknowledge messages
Internet Draft for the Mobile IP Network Address Identifier defined in section 4.4 MUST be assigned the Type values of 20 and 21
Extension[5], the Internet Draft for Mobile IP Challenge/Response respectively.
Extensions[6] or the Internet Draft for Route Optimization [7]. The
values specified for Status field, listed in section 4.4, MUST NOT The Session Specific Extension defined in section 4.2 MUST be
conflict with any other code or status values listed in RFC 2002[1], assigned the Type value of 39, and the Registration Update
RFC2344[2], or RFC2356[4], or the above mentioned Internet Drafts Authentication Extension defined in section 4.5 MUST be assigned a
[5], [6] and [7]. They are to be taken from the space of error value of 40. The Status values defined in section 4.4 are the error
values conventionally associated with rejection by the home agent codes defined in RFC 2002 [1]. They correspond to the error values
(i.e. 128-255). conventionally associated with a rejection by a home agent (i.e.,
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 7.0 Security Considerations
The protocol presented in this draft is designed for use over a The protocol presented in this draft is designed for use over a
protected, private network between RNN and PDSN. Pre-arranged protected, private network between RNN and PDSN. Pre-arranged
security associations in the style of Mobile IPv4 are assumed to security associations in the style of Mobile IPv4 are assumed to
exist among every (RNN, PDSN) pair that will form an RP connection. exist among every (RNN, PDSN) pair that will form an RP connection.
Also, it is assumed that the session specific information is Also, it is assumed that the session specific information is
authenticated by means outside the scope of this draft. authenticated by means outside the scope of this draft.
skipping to change at line 513 skipping to change at line 526
there are no other end-to-end security mechanisms in place. Second, there are no other end-to-end security mechanisms in place. Second,
the Mobile IP control messages must be authenticated, to prevent the Mobile IP control messages must be authenticated, to prevent
tunnel setup and tear down by unauthorized parties. Mobile IP tunnel setup and tear down by unauthorized parties. Mobile IP
Authentication Extensions are used to provide this additional Authentication Extensions are used to provide this additional
protection for control messages. Finally, if session specific protection for control messages. Finally, if session specific
information is not authenticated, a denial-of-service attack is information is not authenticated, a denial-of-service attack is
possible if a RNN unknowingly sends a registration request to the possible if a RNN unknowingly sends a registration request to the
PDSN with a spoofed session specific extension. The PDSN would then PDSN with a spoofed session specific extension. The PDSN would then
send an explicit tunnel tear down to the previous RNN, causing user 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 traffic to be misdirected to the new RNN. This would cause a loss of
Xu et al. Expires July 2000 10
service and possibly interception of traffic, depending on what service and possibly interception of traffic, depending on what
other security measures are in place. other security measures are in place.
8.0 Acknowledgments 8.0 Acknowledgments
The authors of this draft would like to thank Charles E. Perkins and The authors of this draft would like to thank Charles E. Perkins and
David B. Johnson for the ideas presented in the Route Optimization David B. Johnson for the ideas presented in the Route Optimization
draft [7]. draft [7].
References References
[1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
1996. 1996.
Xu et al. Expires May 2000 10
[2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May
1998. 1998.
[3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic [3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[4] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for [4] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for
Mobile IP". RFC 2356, June 1998. Mobile IP". RFC 2356, June 1998.
[5] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network [5] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network
skipping to change at line 548 skipping to change at line 562
05.txt, October 1999. (work in progress). 05.txt, October 1999. (work in progress).
[6] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ [6] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/
Response Extensions". draft-ietf-mobileip-challenge-06.txt, Response Extensions". draft-ietf-mobileip-challenge-06.txt,
October 1999. (work in progress). October 1999. (work in progress).
[7] Charles E. Perkins and David B. Johnson. "Route Optimization in [7] Charles E. Perkins and David B. Johnson. "Route Optimization in
Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999.
(work in progress). (work in progress).
Xu et al. Expires May 2000 11 Xu et al. Expires July 2000 11
AuthorsĘ Addresses AuthorsĘ Addresses
Yingchun Xu Yingchun Xu
3Com Corporation 3Com Corporation
1800 West Central Road 1800 West Central Road
Mount Prospect, Mount Prospect,
USA 60056 USA 60056
Phone: (847) 342-6814 Phone: (847) 342-6814
Email: Yingchun_Xu@3com.com Email: Yingchun_Xu@3com.com
skipping to change at line 603 skipping to change at line 617
Phone: (408) 525-1404 Phone: (408) 525-1404
Email: gdommety@cisco.com Email: gdommety@cisco.com
Kirit Joshi Kirit Joshi
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: (408) 525 7367 Phone: (408) 525 7367
Email: kjoshi@cisco.com Email: kjoshi@cisco.com
Xu et al. Expires May 2000 12 Xu et al. Expires July 2000 12
Parviz Yegani Parviz Yegani
Ericson Wireless Communication Inc. Ericson Wireless Communication Inc.
6455 Lusk Blvd. 6455 Lusk Blvd.
San Diego, CA 92121 San Diego, CA 92121
Phone: (858) 332-6017 Phone: (858) 332-6017
Email: p.yeqani@ericsson.com Email: p.yeqani@ericsson.com
Takeo Matsumura Takeo Matsumura
FUJITSU FUJITSU
Kamiodanaka Kamiodanaka
skipping to change at line 658 skipping to change at line 672
Phone: +82-343-450-7199 Phone: +82-343-450-7199
Email: bklim@lgic.co.kr Email: bklim@lgic.co.kr
Peter J. McCann Peter J. McCann
Lucent Technologies Lucent Technologies
Rm 2Z-305 Rm 2Z-305
263 Shuman Blvd 263 Shuman Blvd
Naperville, IL 60566 Naperville, IL 60566
Phone: (630) 713 9359 Phone: (630) 713 9359
Xu et al. Expires May 2000 13 Xu et al. Expires July 2000 13
EMail: mccap@lucent.com EMail: mccap@lucent.com
Thomas Towle Thomas Towle
Lucent Technologies Lucent Technologies
Rm. 2D-225 Rm. 2D-225
263 Shuman Blvd 263 Shuman Blvd
Naperville, IL 60566 Naperville, IL 60566
Phone: 630-979-7303 Phone: 630-979-7303
Email: ttowle@lucent.com Email: ttowle@lucent.com
skipping to change at line 713 skipping to change at line 727
Samsung Electronics Ltd. Samsung Electronics Ltd.
11th Fl, Samsung Plaza Bldg, 11th Fl, Samsung Plaza Bldg,
263, Seohyeon-dong, Pundang-gu, 263, Seohyeon-dong, Pundang-gu,
Sungnam-shi, Kyunggi-do, Sungnam-shi, Kyunggi-do,
463-050 Pundang P.O. Box 32, Korea 463-050 Pundang P.O. Box 32, Korea
Phone: +82-342-779-8526 Phone: +82-342-779-8526
Email: keg@telecom.samsung.co.kr Email: keg@telecom.samsung.co.kr
Yong Chang Yong Chang
Xu et al. Expires May 2000 14 Xu et al. Expires July 2000 14
Samsung Electronics Ltd. Samsung Electronics Ltd.
11th Fl, Samsung Plaza Bldg, 11th Fl, Samsung Plaza Bldg,
263, Seohyeon-dong, Pundang-gu, 263, Seohyeon-dong, Pundang-gu,
Sungnam-shi, Kyunggi-do, Sungnam-shi, Kyunggi-do,
463-050 Pundang P.O. Box 32, Korea 463-050 Pundang P.O. Box 32, Korea
Phone: +82-342-779-6822 Phone: +82-342-779-6822
Email : yong@telecom.samsung.co.kr Email : yong@telecom.samsung.co.kr
Bill Semper Bill Semper
Samsung Telecommunications Samsung Telecommunications
skipping to change at line 757 skipping to change at line 771
Phone: 913-664-8350 Phone: 913-664-8350
Email: FLerou01@sprintspectrum.com Email: FLerou01@sprintspectrum.com
Jim Gately Jim Gately
USWest Advanced Technologies USWest Advanced Technologies
4001 Discovery Drive 4001 Discovery Drive
Boulder, CO 80303 Boulder, CO 80303
Phone: 303-541-6415 Phone: 303-541-6415
Email: jgately@uswest.com Email: jgately@uswest.com
Xu et al. Expires May 2000 15 Xu et al. Expires July 2000 15
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/