File: rfc3141.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 27,998 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                     T. Hiller, Lucent Technologies
Request for Comments: 3141                 P. Walsh, Lucent Technologies
Category: Informational                                 X. Chen, Alcatel
                                                               M. Munson
                                               G. Dommety, Cisco Systems
                        S. Sivalingham, Ericsson Wireless Communications
                           B. Lim, LG Information & Communications, Ltd.
                                          P. McCann, Lucent Technologies
                                          H. Shiino, Lucent Technologies
                                                  B. Hirschman, Motorola
                                       S. Manning, Award Solutions, Inc.
                                                  R. Hsu, Qualcomm, Inc.
                        H. Koo, Samsung Telecommunications America, Inc.
                                                  M. Lipford, Sprint PCS
                                      P. Calhoun, Sun Laboratories, Inc.
                                                         C. Lo, Vodafone
                                                     E. Jaques, Vodafone
                      E. Campbell, CommWorks Corporation, A 3Com Company
                                               Y. Xu, WaterCove Networks
                                 S. Baba, Toshiba America Research, Inc.
                                               T. Ayaki, DDI Corporation
                                                 T. Seki, DO Corporation
                                                      A. Hameed, Fujitsu
                                                               June 2001


              CDMA2000 Wireless Data Requirements for AAA

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo specifies cdma2000 wireless data AAA (Authentication,
   Authorization, Accounting) requirements associated with third
   generation wireless architecture that supports roaming among service
   providers for traditional PPP and Mobile IP services.







Hiller, et al.               Informational                      [Page 1]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


1.  Introduction

   The architecture is designed for use with a cellular network as an
   access medium.  Sections 1, 2, present a brief high level review of
   the cdma2000 wireless data architecture.  Section 3 presents cdma2000
   AAA requirements.

   This document specifies AAA requirements associated with a third
   generation cdma2000 wireless architecture that supports roaming among
   service providers for traditional PPP and Mobile IP services.  The
   architecture is designed for use with a cellular network as an access
   medium.

   Sections 1 and 2 present a brief, high level review of the cdma2000
   wireless  data architecture as an aid to interested AAA WG members.
   Section 3 presents cdma2000 AAA requirements, and is self contained
   relative to the architecture review.

1.1.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC2119].

   Please note that the requirements specified in this document are to
   be used in evaluating AAA protocol submissions.  As such, the
   requirements language refers to capabilities of these protocols; the
   protocol documents will specify whether these features are required,
   recommended, or optional.  For example, requiring that a protocol
   support confidentiality is NOT the same thing as requiring that all
   protocol traffic be encrypted.

   A protocol submission is not compliant if it fails to satisfy one or
   more of the MUST or MUST NOT requirements for the capabilities that
   it implements.  A protocol submission that satisfies all the MUST,
   MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
   said to be "unconditionally compliant"; one that satisfies all the
   MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
   requirements for its protocols is said to be "conditionally
   compliant."

1.2.  General Service Requirements

      o  Provide service during subscriber visiting between wireless
         networks systems while maintaining a formal customer-service
         provider relation with only one wireless service provider.

      o  Support Traditional PPP and Mobile IP services:



Hiller, et al.               Informational                      [Page 2]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


         o  Support dynamic and static home address assignments for
            Mobile IP
         o  Support a Home Agent in the mobile's home wireless network,
            home ISP, or private network.
         o  Support IP Security on the Mobile IP tunnel between Foreign
            Agent and Home Agent, in order to avoid the overhead of a
            voluntary tunnel on the radio interface.

      o  Provide robust authentication, authorization and accounting
         services (AAA):

         o  Provide separation of airlink resource AAA services and data
            resource AAA services.
         o  Authenticate and authorize a mobile based on an IMSI and an
            NAI.  The architecture allows for a carrier to determine if
            billing is based on the IMSI or the NAI.
         o  Support optional AAA broker services between wireless
            carriers and between wireless carriers and other external
            data networks.
         o  Allow for distribution of specific Mobile IP security key
            information to support home agent assignment, fast handoff,
            and fast HA-FA authentication assignment during
            registration.

      o  Provide QoS


























Hiller, et al.               Informational                      [Page 3]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


2.  High Level Architecture

   The high level architecture is shown in Figure 1.  The six major
   entities that compose the network are the Home Agent, the PDSN, the
   AAA Server, the Radio Network, the HLR/VLR, and Mobile Client.

            Visited Access              Home Access
            Provider Network           Provider Network
              +--------+                 +--------+
              |        |      SS7        |        |
              |  VLR   |-----------------|  HLR   |
              |        |                 |        |
              +--------+                 +--------+
                  |
                  |
                  |  Visited Access      Broker        Home IP
                  |  Provider Network    Network       Network
                  |     +--------+      +--------+   +--------+
                  |     |        |      |        |   |        |
                  |     |  AAA   |------|  AAA   |---|  AAA   |
                  |     |        |      |        |   |        |
                  |     +--------+      +--------+   +--------+
                  |             \                \       |
                  |              \                \      |
                  |               \                \     |
                  |                \                \    |
                  |                 \                \   |
              +---------+       +---------+       +---------+
              |         |       |         |       |         |
              |   RN    |-------|  PDSN   |-------|  HA     |
              |         |       |         |       |         |
              +---------+       +---------+       +---------+
                  |
                  |   Visited Access            Home Network
                  |  Provider Network           -Private
            Mobile|                             -Visited Provider
              IP  |                             -Home Provider
                  |                             -Home ISP
               +--------+
               | Mobile |
               | Node   |
               +--------+

            Figure 1: General cdma2000 Wireless IP Architecture







Hiller, et al.               Informational                      [Page 4]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


2.1.  PDSN

      o  Acts as a Foreign Agent;
      o  Establish, maintain, and terminate link layer to the mobile
         client;
      o  Initiate the authentication, authorization and accounting for
         the mobile client;
      o  Optionally, securely tunnel using IP security to the Home
         Agent;
      o  Receives service parameters from AAA for mobile client;
      o  Collect usage data for accounting purposes to be relayed to
         AAA;
      o  Routes packets to external packet data networks or to the HA in
         the case of reverse tunneling;
      o  Maps home address and Home Agent address to a unique link layer
         identifier used to communicate with Radio Network.

2.2.  Authentication, Authorization, and Accounting Server

      o  Interact with the Foreign Agent and other AAA servers to
         authorize, authenticate and perform accounting for the mobile
         client;
      o  Provides mechanism to support security association between
         PDSN/FA and HA and between the MN and PDSN/FA;
      o  For dynamic Home Agent assignment, dynamically identify an HA
         and assign a MN on that HA, and provide the security
         association between the MN and HA;
      o  Provide QoS information to the PDSN;
      o  Optionally, assign dynamic home address.

2.3.  Radio Network

      o  Maps Mobile Client identifier reference to a unique link layer
         identifier used to communicate with PDSN;
      o  Validates Mobile Station for access service;
      o  Manages physical layer connection to the Mobile Client;
      o  Maintain state of reachability for packet service between the
         access radio network and the mobile station;
      o  Buffers packets arriving from the PDSN, when radio resources
         are not in place or are insufficient to support the flow from
         the PDSN;
      o  Relays packets between the mobile station and the PDSN.

2.4.  Location Registers (VLR/HLR)

      o  Stores authentication and authorization information for the
         radio network.




Hiller, et al.               Informational                      [Page 5]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


2.5.  Home Agent

      o  Maintains user registration and redirects packets to the PDSN;
      o  Optionally, establish an IP secure tunnel to the PDSN/FA;
      o  Supports the dynamic Home Agent assignment;
      o  Optionally, assigns dynamic home address;
      o  Support reverse tunneling.

2.6.  Mobile Node

      o  Support PPP;
      o  Can act as a Mobile IP Node; and support Foreign Agent
         Challenge and NAI;
      o  Interacts with the Radio Network to obtain appropriate radio
         resources from the network for the exchange of packets;
      o  Maintains knowledge of status of radio resources (e.g., active,
         standby, dormant);
      o  Buffers packets when radio resources are not in place or are
         insufficient to support the flow to the network.

3.  AAA Requirements

3.1.  Core AAA Requirements

   The following is a summary of cdma2000 AAA specific requirements.  In
   these requirements, the serving network and home network may or may
   not have a direct business relationship.  In such cases in which
   there is not a direct business relationship, service may be supported
   indirectly via broker.

      o  Authenticate and authorize a user NAI in a roaming environment.
         The NAI is obtained via CHAP (for traditional PPP service) or a
         Foreign Agent Challenge (for Mobile IP service).  A shared
         secret exists between the mobile and its HAAA.  The FAC will
         typically be computed in a manner  consistent with CHAP.
      o  Transport wireless data attributes from the home network to the
         Serving network.  This may often take the form of a user
         profile.
      o  Encrypt or sign one or more AVPs in an AAA message between
         home, serving network, or some broker across multiple AAA
         server hops.
      o  Support a reliable AAA transport mechanism.
         o  This transport mechanism will be able indicate to an AAA
            application that a message was delivered to the next peer
            AAA application or that a time out occurred.
         o  Retransmission is controlled by the reliable AAA transport
            mechanism, and not by lower layer protocols such as TCP.




Hiller, et al.               Informational                      [Page 6]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


         o  Even if the AAA message is to be forwarded, or the message's
            options or semantics do not conform with the AAA protocol,
            the transport mechanism will acknowledge that the peer
            received the AAA message.  However, if the message fails to
            pass authentication, it will not be acknowledged.
         o  Acknowledgements should be allowed to be piggybacked in AAA
            messages
         o  The reliable transport mechanism features shall have the
            capability to detect silent failures of the AAA peer or path
            to the AAA peer, to manage failure on a proactive basis.
         o  Transport a digital certificate in an AAA message, in order
            to minimize the number of round trips associated with AAA
            transactions.  Note: This requirement applies to AAA
            applications and not mobile stations.
         o  Support both proxy and non-proxy brokers, where non-proxy
            brokers imply the broker terminates an entire request and
            initiates a new request.  AAA brokers should have the
            capability to modify certain parts of AAA messages whereby
            to operate to in non-proxy or proxy environments.
         o  Provide message integrity and identity authentication on a
            per hop (AAA node) basis.
         o  Support replay protection and optional non-repudiation
            capabilities for all authorization and accounting messages.
            The AAA protocol must provide the capability for accounting
            messages to be matched with prior authorization messages.
         o  Support accounting via both bilateral arrangements and via
            broker AAA servers providing accounting clearinghouse and
            reconciliation between serving and home networks.  There is
            an explicit agreement that if the private network or home
            ISP authenticates the mobile station requesting service,
            then the private network or home ISP network also agrees to
            reconcile charges with the home service provider or broker.
            Real time accounting must be supported.
         o  Provides security between AAA servers, and between AAA
            server and PDSN or HA via IP security.

3.2.  Mobile IP Specific Requirements and AAA

3.2.1.  Mobile IP Security Discussion

   Three Mobile IP security extensions are defined in RFC 2002:

        . HA - FA
        . MN - FA
        . HA - MN






Hiller, et al.               Informational                      [Page 7]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Therefore, Mobile IP and IPsec security models differ in that Mobile
   IP provides its own authentication mechanisms calculated within the
   Mobile IP registration procedures whereas IPsec uses IPsec AH.

   The keys and SPIs associated with the MN-FA and HA-FA extensions need
   to be dynamically established in a roaming wireless carrier
   environment.  The MN-FA extension is useful for allowing a new FA
   (PDSN) to quickly authenticate a mobile using the previous foreign
   agent extension.  The HA-FA extension is useful for the HA to ensure
   that only FAs from carrier's with roaming agreements access the HA.
   The MN-HA is usually provisioned, but for dynamic Home Agent
   assignment, this security association must be dynamically created.

   It is possible to use IPsec AH between MN and FA, FA and HA, and MN
   and HA.  IKE may be used to establish security associations between
   these entities.  However, use of IKE may pose a problem for smaller
   mobiles and may introduce unacceptable delays for certain
   applications (e.g., Voice Over IP).  The following three sections
   outline Mobile IP specific functions that benefit from AAA based key
   distribution.

3.2.2.  Dynamic Home Agent Assignment

   A visited or home AAA server will optionally be able perform dynamic
   HA assignment.  For dynamically assigned HA, the visited AAA server
   will indicate to the home AAA server whether it supports dynamic HA
   assignment in those cases in which the mobile node requests dynamic
   assignment.  If so indicated, the home AAA server may choose to allow
   the visited AAA server to perform the HA assignment.  Otherwise, the
   home AAA assigns the HA.

3.2.3.  Fast Handoff

   To achieve a faster handoff, the mobile may attempt to avoid an AAA
   transaction with the home AAA server.  To accomplish this, the mobile
   may send the PDSN the Previous FA address in the RRQ message from the
   mobile, along with the MN-FA authentication extension.  The new PDSN
   passes the Previous FA address and MN-FA authentication extension to
   the visited AAA server.  If the visited AAA server is able
   authenticate the MN-FA authentication extension for the mobile, then
   the visited AAA may be able to avoid an actual transaction to the
   home AAA server.









Hiller, et al.               Informational                      [Page 8]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


3.2.4.  HA-FA Authentication

   To achieve a fast registration for the case of a mobile station with
   a Home Agent, the PDSN and HA may receive from the AAA mechanism a
   HA-FA key and SPI that is used to authenticate the PDSN and the HA to
   each other.

3.2.5.  Key Distribution

   These functions are primarily useful in a wireless environment in
   which handoffs may occur rapidly (implying a need for low latency),
   or where mobile devices have limited computing power.  To achieve
   these functions, AAA will be used to securely pass keys and SPIs
   between the serving network and target network in encrypted form.
   These keys are then used for the specific functions outlined in this
   document.

3.3.  IKE and AAA

   The use of IKE in the cdma2000 wireless architecture requires the use
   of certificates.  However, the AAA servers may be able to distribute
   a pre- shared key to the Mobile IP Agents for use during Phase 1
   ISAKMP exchanges.  This may lessen the need for on-line revocation
   checks.

3.4.  Interoperability with RADIUS

   Users with a home AAA server based on RADIUS may desire to roam into
   a wireless carrier network that uses "new" AAA servers based on the
   requirements in this document, and vice verse.  The AAA protocol
   should be designed in a way so as to make conversions to and from
   RADIUS messages straight forward.  This will allow for the
   development of gateway processes to aid in interoperability.  Note:
   The features of the new AAA protocols which are beyond the feature
   set of the RADIUS protocol will not be available for users while on
   home or serving networks based on RADIUS.

4.  References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

5.  Security Considerations

   This document is very much about security.  These requirements do not
   require the serving and home networks to not be in the same domain
   nor must they have a direct relationship.  The serving network
   requires authorization from the home network so that the serving



Hiller, et al.               Informational                      [Page 9]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   network obtains proof it will get paid for services rendered to the
   mobile.  This implies the home network must authenticate the user.
   AAA functions must be performed in a secure manner.  The requirements
   contained in section 2 outline the security required.

   Mobile IP supports authentication mechanisms outside IP Security.
   These mechanism may be enhanced in a cellular wireless environment by
   allowing a home AAA server to distribute keys to the serving network.
   Additionally, the home AAA server may be able to send a pre-shared
   key to be used in Phase 1 ISAKMP security association establishment
   between FA and HA.  These keys would sent in encrypted form from the
   home network to the serving network.  As supported in the
   requirements contained in section 2, the encryption could be handled
   via public cryptography and certificates.

6.  IANA Considerations

   This document does not create any new number spaces for IANA
   administration.

7.  Acknowledgements

   The authors are active members of the TIA TR45.6 committee.

8.  Authors' Addresses

   Pat R. Calhoun
   Network and Security Research Center, Sun Labs
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, CA 94025
   USA

   Phone: (650) 786-7733
   EMail: pcalhoun@eng.sun.com


   Ed Campbell
   CommWorks Corporation, A 3Com Company
   3800 Golf Road
   Rolling Meadows, IL 60008

   Phone: (847)262-2325
   E-Mail: ed_campbell@commworks.com







Hiller, et al.               Informational                     [Page 10]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   USA

   EMail: gdommety@cisco.com


   Tom Hiller
   Rm 2F-218
   263 Shuman Dr.
   Lucent Technologies
   Naperville, IL
   USA

   Phone: (630) 979-7673
   EMail: tom.hiller@lucent.com


   Raymond T. Hsu
   Qualcomm Inc.
   6455 Lusk Blvd.
   San Diego, CA 92121
   USA

   Phone: (619) 651-3623
   EMail: rhsu@qualcomm.com


   Mark A. Lipford
   Sprint PCS
   15405 College Blvd.
   Lenexa, KS  66219

   Phone:  (913) 890-4248
   EMail: mlipfo01@sprintspectrum.com


   Serge Manning
   Award Solutions, Inc.
   800 E. Campbell Rd., Suite 120
   Richardson, TX  75081

   Phone: (972) 664-0727 x350
   EMail: serge@awardsolutions.com





Hiller, et al.               Informational                     [Page 11]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Peter J. McCann
   Lucent Technologies
   Rm 2Z-305
   263 Shuman Blvd
   Naperville, IL 60566
   USA

   Phone: (630) 713 9359
   EMail: mccap@lucent.com


   Mark Munson
   1371 Winding Branch Circle
   Atlanta, Georgia 30338
   USA

   Phone: (678) 339-4439
   EMail: mmunson@gte.net


   Haeng Koo
   Samsung Telecommunications America, Inc.
   1130 E. Arapaho Road
   Richardson, TX 75081
   USA

   Phone: (972)761-7755
   EMail: hskoo@sta.samsung.com


   Pat Walsh
   Lucent Technologies
   263 Shuman Blvd.
   1F-545
   Naperville, IL

   Phone: +1 630-713-5063
   EMail: walshp@lucent.com













Hiller, et al.               Informational                     [Page 12]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Yingchun Xu
   WaterCove Networks
   One Century Centre, Suite 550
   1750 E. Golf Road
   Schaumburg, IL

   Phone: +1 847-477-9280
   EMail: yxu@watercove.com


   Brent Hirschman
   1501 Shure Dr.
   Arlington Heights, IL 60006
   USA

   Phone: (847) 632-1563
   EMail: qa4053@email.mot.com


   Eric Jaques
   Vodafone
   2999 Oak Road, MS-750
   Walnut Creek, CA 94596
   USA

   Phone: +1-925-210-3900
   EMail: ejaques@akamail.com


   Sanjeevan Sivalingham
   Ericsson Wireless Communications Inc.,
   Rm Q-356C
   6455 Lusk Blvd
   San Diego, CA 92126
   USA

   Phone: (858) 332-5670
   EMail:  s.sivalingham@ericsson.com













Hiller, et al.               Informational                     [Page 13]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Xing Chen
   Alcatel USA
   1000 Coit Road
   Plano, TX 75075
   USA

   Phone: 972-519-4142
   Fax:   +1 972-519-3300
   EMail: xing.chen@usa.alcatel.com


   Byung-Keun Lim
   LG Electronics Inc.
   533, Hogye-dong, Donan-Ku, Anyang-shi, Kyungki-do, 431-080,
   Korea

   Phone: +82-31-450-7199
   Fax:   +82-31-450-7050
   EMail: bklim@lge.com


   Hajime Shiino
   Lucent Technologies Japan Ltd.
   25 Mori Bldg. 1-4-30 Roppongi,
   Minato-ku Tokyo
   Japan

   Phone: +81-3-5561-3695
   EMail: hshiino@lucent.com


   Shinichi Baba
   Toshiba America Research, Inc.
   PO Box 136,
   Convent Station, NJ 07961-0136
   USA

   Phone: (973) 829-4795
   EMail: sbaba@tari.toshiba.com












Hiller, et al.               Informational                     [Page 14]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


   Takahiro Ayaki
   DDI corporation
   Ichibancho FS Bldg.
   8, Ichibancho, Chiyoda-ku Tokyo
   Japan

   Phone: +81-3-3221-9682
   EMail: ayaki@ddi.co.jp


   Alan Hameed
   Fujitsu
   2801 Telecom Parkway
   Richardson, Texas 75082
   USA

   Phone: (972) 479-2089


   Charles N. Lo
   Vodafone AirTouch
   2999 Oak Rd
   Walnut Creek, CA  94596
   USA

   Phone: (925) 210-3460
   EMail: Charles.Lo@vodafone-us.com


   Takuo Seki
   IDO Corporation
   Gobancho YS Bldg.
   12-3, Gobancho, Chiyoda-ku Tokyo
   Japan

   Phone: +81-3-3263-9660
   EMail: t-seki@kddi.com














Hiller, et al.               Informational                     [Page 15]

RFC 3141          CDMA2000 Wireless Data Requirements          June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hiller, et al.               Informational                     [Page 16]