File: rfc3154.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-- 31,534 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                                           J. Kempf
Request for Comments: 3154                               C. Castelluccia
Category: Informational                                         P. Mutaf
                                                             N. Nakajima
                                                                 Y. Ohba
                                                               R. Ramjee
                                                            Y. Saifullah
                                                             B. Sarikaya
                                                                   X. Xu
                                                             August 2001


              Requirements and Functional Architecture for
                     an IP Host Alerting Protocol

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 document develops an architecture and a set of requirements
   needed to support alerting of hosts that are in dormant mode.  The
   architecture and requirements are designed to guide development of an
   IP protocol for alerting dormant IP mobile hosts, commonly called
   paging.



















Kempf, et al.                Informational                      [Page 1]

RFC 3154                  Paging Requirements                August 2001


Table of Contents

   1. Introduction ...................................................3
   2. Terminology ....................................................3
   3. Security Considerations ........................................3
    3.1.   DoS Amplification .........................................3
    3.2.   Queue Overflow ............................................4
    3.3.   Selective DoS against Hosts ...............................4
   4. Requirements ...................................................5
    4.1.   Impact on Power Consumption ...............................5
    4.2.   Scalability ...............................................5
    4.3.   Control of Broadcast/Multicast/Anycast ....................5
    4.4.   Efficient Signaling for Inactive Mode .....................6
    4.5.   No Routers ................................................6
    4.6.   Multiple Dormant Modes ....................................6
    4.7.   Independence of Mobility Protocol .........................6
    4.8.   Support for Existing Mobility Protocols ...................6
    4.9.   Dormant Mode Termination ..................................6
    4.10.  Network Updates ...........................................6
    4.11.  Efficient Utilization of L2 ...............................7
    4.12.  Orthogonality of Paging Area and Subnets ..................7
    4.13.  Future L3 Paging Support ..................................7
    4.14.  Robustness Against Failure of Network Elements ............7
    4.15.  Reliability of Packet Delivery ............................7
    4.16.  Robustness Against Message Loss ...........................7
    4.17.  Flexibility of Administration .............................7
    4.18.  Flexibility of Paging Area Design .........................8
    4.19.  Availability of Security Support ..........................8
    4.20.  Authentication of Paging Location Registration ............8
    4.21.  Authentication of Paging Area Information .................8
    4.22.  Authentication of Paging Messages .........................8
    4.23.  Paging Volume .............................................8
    4.24.  Parsimonious Security Messaging ...........................8
    4.25.  Noninterference with Host's Security Policy ...............8
    4.26.  Noninterference with End-to-end Security ..................9
    4.27.  Detection of Bogus Correspondent Nodes ....................9
   5. Functional Architecture ........................................9
    5.1.   Functional Entities .......................................9
    5.2.   Interfaces ...............................................10
    5.3.   Functional Architecture Diagram ..........................12
   6. Acknowledgements ..............................................12
   7. References ....................................................13
   8. Authors' Addresses ............................................13
   9. Full Copyright Statement ......................................16







Kempf, et al.                Informational                      [Page 2]

RFC 3154                  Paging Requirements                August 2001


1.   Introduction

   In [1], a problem statement was developed to explain why an IP
   protocol was desirable for alerting hosts in dormant mode, commonly
   called paging.  In this document, a set of requirements is developed
   for guiding the development of an IP paging protocol.  Based on the
   requirements, an architecture is developed to represent the
   functional relationships between logical functional entities
   involved.

2.   Terminology

   Please see [1] for definition of terms used in describing paging.  In
   addition, this document defines the following terms:

      Wide Casting - Either broadcasting or multicasting.

         Inactive Mode - The host is no longer listening for any
         packets, not even periodically, and not sending packets.  The
         host may be in a powered off state, it may have shut down all
         interfaces to drastically conserve power, or it may be out of
         range of a radio access point.

3.   Security Considerations

   An IP paging protocol introduces new security issues.  In this
   section, security issues with relevance to formulating requirements
   for an IP paging protocol are discussed.

3.1. DoS Amplification

   A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack generally
   consists of flooding a target network with bogus IP packets in order
   to cause degraded network performance at victim nodes and/or routers.
   Performance can be degraded to the point that the network cannot be
   used.  Currently, there is no preventive solution against these
   attacks, and the impacts can be very important.

   In general a DoS attacker profits from a so-called "amplifier" in
   order to increase the damage caused by his attack.  Paging can serve
   for an attacker as a DoS amplifier.

   An attacker (a malicious correspondent node) can send large numbers
   of packets pretending to be sent from different (bogus) correspondent
   nodes and destined for large numbers of hosts in inactive and dormant
   modes.  This attack, in turn, will be amplified by the paging agent
   which wide casts paging messages over a paging area, resulting in
   more than one networks being flooded.  Clearly, the damage can be



Kempf, et al.                Informational                      [Page 3]

RFC 3154                  Paging Requirements                August 2001


   more important in wireless networks that already suffer from scarce
   radio bandwidth.

   Alternatively, an attacker can sort out a host which:

      1. sends periodic messages declaring that it is in dormant mode,

      2. never replies to paging requests.

   Such a node may be the attacker's node itself, or a second node
   participating in the attack.

   That node is never in inactive mode because of behavior 1 above.  In
   this case, the attacker can send large numbers of packets destined
   for that host which periodically declares that it is in dormant mode
   but never replies to paging messages.  The impact will be the same as
   above however in this case the attack will be amplified indefinitely.

3.2. Queue Overflow

   For reliability reasons, the paging protocol may need to make
   provisions for a paging queue where a paging request is buffered
   until the requested host replies by sending a location registration
   message.

   An attacker can exploit that by sending large numbers of packets
   having different (bogus) correspondent node addresses and destined
   for one or more inactive hosts.  These packets will be buffered in
   the paging queue.  However, since the hosts are inactive, the paging
   queue may quickly overflow, blocking the incoming traffic from
   legitimate correspondent nodes.  As a result, all registered dormant
   hosts may be inaccessible for a while.  The attacker can re-launch
   the attack in a continuous fashion.

   An attacker together with a bogus host that fails to respond to pages
   can overflow the buffering provided to hold packets for dormant mode
   hosts.  If the attacker keeps sending packets while the dormant mode
   host fails to reply, the buffer can overflow.

3.3. Selective DoS against Hosts

   The following vulnerabilities already exist in the absence of IP
   paging.  However, they are included here since they can affect the
   correct operation of the IP paging protocol.

   These vulnerabilities can be exploited by an attacker in order to
   eliminate a particular host.  This, in turn, can be used by an
   attacker as a stepping stone to launch other attacks.



Kempf, et al.                Informational                      [Page 4]

RFC 3154                  Paging Requirements                August 2001


   Forced Battery Consumption

   An attacker can frequently send packets to a host in order to prevent
   that host from switching to dormant mode.  As a result the host may
   quickly run out of battery.

   Bogus Paging Areas

   An attacker can periodically emit malicious packets in order to
   confuse one or more hosts about their actual locations.  Currently,
   there is no efficient way to authenticate such packets.

   In the case of IP paging, these packets may also contain bogus paging
   area information.  Upon receipt of such a packet, a host may move and
   send a location registration message pointing to a non-existing or
   wrong paging area.  The functional entities of the IP paging protocol
   may loose contact with the host.

   More importantly, this attack can serve for sorting out a host which
   shows the behaviors 1 and 2 described in Section 3.1.

   Bogus Paging Agents

   An attacker can wide cast fake paging messages pretending to be sent
   by a paging agent.  The impacts will be similar to the ones described
   in Sections 4.1 and 4.3.1.  However, depending on how the IP paging
   protocol is designed, additional harm may be caused.

4.   Requirements

   The following requirements are identified for the IP paging protocol.

4.1. Impact on Power Consumption

   The IP paging protocol MUST minimize impact on the Host's dormant
   mode operation, in order to minimize excessive power drain.

4.2. Scalability

   The IP paging protocol MUST be scalable to millions of Hosts.

4.3. Control of Broadcast/Multicast/Anycast

   The protocol SHOULD provide a filter mechanism to allow a Host prior
   to entering dormant mode to filter which broadcast/multicast/anycast
   packets active a page.  This prevents the Host from awakening out of
   dormant mode for all broadcast/multicast/anycast traffic.




Kempf, et al.                Informational                      [Page 5]

RFC 3154                  Paging Requirements                August 2001


4.4. Efficient Signaling for Inactive Mode

   The IP paging protocol SHOULD provide a mechanism for the Tracking
   Agent to determine whether the Host is in inactive mode, to avoid
   paging when a host is completely unreachable.

4.5. No Routers

   Since the basic issues involved in handling mobile routers are not
   well understood and since mobile routers have not exhibited a
   requirement for paging, the IP paging protocol MAY NOT support
   routers.  However, the IP paging protocol MAY support a router acting
   as a Host.

4.6. Multiple Dormant Modes

   Recognizing that there are multiple possible dormant modes on the
   Host, the IP paging protocol MUST work with different implementations
   of dormant mode on the Host.

4.7. Independence of Mobility Protocol

   Recognizing that IETF may support multiple mobility protocols in the
   future and that paging may be of value to hosts that do not support a
   mobility protocol, the IP paging protocol MUST be designed so there
   is no dependence on the underlying mobility protocol or on any
   mobility protocol at all.  The protocol SHOULD specify and provide
   support for a mobility protocol, if the Host supports one.

4.8. Support for Existing Mobility Protocols

   The IP paging protocol MUST specify the binding to the existing IP
   mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3].  The
   IP paging protocol SHOULD make use of existing registration support.

4.9. Dormant Mode Termination

   Upon receipt of a page (either with or without an accompanying L3
   packet), the Host MUST execute the steps in its mobility protocol to
   re-establish a routable L3 link with the Internet.

4.10.   Network Updates

   Recognizing that locating a dormant mode mobile requires the network
   to have a rough idea of where the Host is located, the IP paging
   protocol SHOULD provide the network a way for the Paging Agent to
   inform a dormant mode Host what paging area it is in and the IP
   paging protocol SHOULD provide a means whereby the Host can inform



Kempf, et al.                Informational                      [Page 6]

RFC 3154                  Paging Requirements                August 2001


   the Target Agent when it changes paging area.  The IP paging protocol
   MAY additionally provide a way for the Host to inform the Tracking
   Agent what paging area it is in at some indeterminate point prior to
   entering dormant mode.

4.11.   Efficient Utilization of L2

   Recognizing that many existing wireless link protocols support paging
   at L2 and that these protocols are often intimately tied into the
   Host's dormant mode support, the IP paging protocol SHOULD provide
   support to efficiently utilize an L2 paging protocol if available.

4.12.   Orthogonality of Paging Area and Subnets

   The IP paging protocol MUST allow an arbitrary mapping between
   subnets and paging areas.

4.13.   Future L3 Paging Support

   Recognizing that future dormant mode and wireless link protocols may
   be designed that more efficiently utilize IP, the IP paging protocol
   SHOULD NOT require L2 support for paging.

4.14.   Robustness Against Failure of Network Elements

   The IP paging protocol MUST be designed to be robust with respect to
   failure of network elements involved in the protocol.  The self-
   healing characteristics SHOULD NOT be any worse than existing routing
   protocols.

4.15.   Reliability of Packet Delivery

   The IP paging protocol MUST be designed so that packet delivery is
   reliable to a high degree of probability.  This does not necessarily
   mean that a reliable transport protocol is required.

4.16.   Robustness Against Message Loss

   The IP paging protocol MUST be designed to be robust with respect to
   loss of messages.

4.17.   Flexibility of Administration

   The IP paging protocol SHOULD provide a way to flexibly auto-
   configure Paging Agents to reduce the amount of administration
   necessary in maintaining a wireless network with paging.





Kempf, et al.                Informational                      [Page 7]

RFC 3154                  Paging Requirements                August 2001


4.18.   Flexibility of Paging Area Design

   The IP paging protocol MUST be flexible in the support of different
   types of paging areas.  Examples are fixed paging areas, where a
   fixed set of bases stations belong to the paging area for all Hosts,
   and customized paging areas, where the set of base stations is
   customized for each Host.

4.19.   Availability of Security Support

   The IP paging protocol MUST have available authentication and
   encryption functionality at least equivalent to that provided by
   IPSEC [5].

4.20.   Authentication of Paging Location Registration

   The IP paging protocol MUST provide mutually authenticated paging
   location registration to insulate against replay attacks and to avoid
   the danger of malicious nodes registering for paging.

4.21.   Authentication of Paging Area Information

   The IP paging protocol MUST provide a mechanism for authenticating
   paging area information distributed by the Paging Agent.

4.22.   Authentication of Paging Messages

   The IP paging protocol MUST provide a mechanism for authenticating L3
   paging messages sent by the Paging Agent to dormant mode Hosts. The
   protocol MUST support the use of L2 security mechanisms so
   implementations that take advantage of L2 paging can also be secured.

4.23.   Paging Volume

   The IP paging protocol SHOULD be able to handle large numbers of
   paging requests without denying access to any legitimate Host nor
   degrading its performance.

4.24.   Parsimonious Security Messaging

   The security of the IP paging protocol SHOULD NOT call for additional
   power consumption while the Host is in dormant mode, nor require
   excessive message exchanges.

4.25.   Noninterference with Host's Security Policy

   The IP paging protocol MUST NOT impose any limitations on a Host's
   security policies.



Kempf, et al.                Informational                      [Page 8]

RFC 3154                  Paging Requirements                August 2001


4.26.   Noninterference with End-to-end Security

   The IP paging protocol MUST NOT impose any limitations on a Host's
   ability to conduct end-to-end security.

4.27.   Detection of Bogus Correspondent Nodes

   The IP paging protocol SHOULD make provisions for detecting and
   ignoring bogus correspondent nodes prior to paging messages being
   wide cast on behalf of the correspondent node.

5.   Functional Architecture

   In this section, a functional architecture is developed that
   describes the logical functional entities involved in IP paging and
   the interfaces between them.  Please note that the logical
   architecture makes absolutely no commitment to any physical
   implementation of these functional entities whatsoever.  A physical
   implementation may merge particular functional entities.  For
   example, the Paging Agent, Tracking Agent, and Dormant Monitoring
   Agent may all be merged into one in a particular physical
   implementation.  The purpose of the functional architecture is to
   identify the relevant system interfaces upon which protocol
   development may be required, but not to mandate that protocol
   development will be required on all.

5.1. Functional Entities

   The functional architecture contains the following elements:

      Host - The Host (H) is a standard IP host in the sense of [4]. The
      Host may be connected to a wired IP backbone through a wireless
      link over which IP datagrams are exchanged (mobile usage pattern),
      or it may  be connected directly to a wired IP network, either
      intermittently (nomadic usage pattern) or constantly (wired usage
      pattern).  The Host may support some type of IP mobility protocol
      (for example, mobile IP [2] [3]).  The Host is capable of entering
      dormant mode in order to save power (see [1] for a detailed
      discussion of dormant mode).  The Host also supports a protocol
      allowing the network to awaken it from dormant mode if a packet
      arrives.  This protocol may be a specialized L2 paging channel or
      it may be a time-slotted dormant mode in which the Host
      periodically wakes up and listens to L2 for IP traffic, the
      details of the L2 implementation are not important.  A dormant
      Host is also responsible for determining when its paging area has
      changed and for responding to changes in paging area by directly





Kempf, et al.                Informational                      [Page 9]

RFC 3154                  Paging Requirements                August 2001


      or indirectly informing the Tracking Agent about its location.
      Since routers are presumed not to require dormant mode support, a
      Host is never a router.

      Paging Agent - The Paging Agent is responsible for alerting the
      Host when a packet arrives and the Host is in dormant mode.
      Alerting of the Host proceeds through a protocol that is peculiar
      to the L2 link and to the Host's dormant mode implementation,
      though it may involve IP if supported by the L2.  Additionally,
      the Paging Agent maintains paging areas by periodically wide
      casting information over the Host's link to identify the paging
      area.  The paging area information may be wide cast at L2 or it
      may also involve IP.  Each paging area is served by a unique
      Paging Agent.

      Tracking Agent - The Tracking Agent is responsible for tracking a
      Host's location while it is in dormant mode or active mode, and
      for determining when Host enters inactive mode.  It receives
      updates from a dormant Host when the Host changes paging area.
      When a packet arrives for the Host at the Dormant Monitoring
      Agent, the Tracking Agent is responsible for notifying the Dormant
      Monitoring Agent, upon request, what Paging Agent is in the Host's
      last reported paging area.  There is a one to one mapping between
      a Host and a Tracking Agent.

      Dormant Monitoring Agent - The Dormant Monitoring Agent detects
      the delivery of packets to a Host that is in Dormant Mode (and
      thus does not have an active L2 connection to the Internet).  It
      is the responsibility of the Dormant Monitoring Agent to query the
      Tracking Agent for the last known Paging Agent for the Host, and
      inform the Paging Agent to page the Host.  Once the Paging Agent
      has reported that a routable connection to the Internet exists to
      the Host, the Dormant Monitoring Agent arranges for delivery of
      the packet to the Host.  In addition, the Host or its Tracking
      Agent may select a Dormant Monitoring Agent for a Host when the
      Host enters dormant mode, and periodically as the Host changes
      paging area.

5.2. Interfaces

   The functional architecture generates the following list of
   interfaces.  Note that the interfaces between functional entities
   that are combined into a single network element will require no
   protocol development.

      Host - Paging Agent (H-PA) - The H-PA interface supports the
      following types of traffic:




Kempf, et al.                Informational                     [Page 10]

RFC 3154                  Paging Requirements                August 2001


         -  Wide casting of paging area information from the Paging
            Agent.

         -  The Paging Agent alerting the Host when informed by the
            Dormant Monitoring Agent that a packet has arrived.

      Host - Tracking Agent (H-TA) - The H-TA interface supports the
      following types of traffic:

         -  The Host informing the Tracking Agent when it has changed
            paging area, and, optionally, prior to entering dormant
            mode, in what paging area it is located.

         -  Optionally, the Host informs the Tracking Agent at a planned
            transition to inactive mode.

      Dormant Monitoring Agent - Tracking Agent (DMA-TA) - The DMA-TA
      interface supports the following types of traffic:

         -  A report from the Dormant Monitoring Agent to the Tracking
            Agent that a packet has arrived for a dormant Host for which
            no route is available.

         -  A report from the Tracking Agent to the Dormant Monitoring
            Agent giving the Paging Agent to contact in order to page
            the Host.

         -  A report from the Tracking Agent to the Dormant Monitoring
            Agent that a Host has entered inactive mode, if not provided
            directly by the Host

         -  A report from the Tracking Agent to the Dormant Monitoring
            Agent that a Host has entered dormant mode, if not provided
            directly by the Host.

      Dormant Monitoring Agent - Paging Agent (DMA-PA) - The DMA-PA
      interface supports the following types of traffic:

         -  A request from the Dormant Monitoring Agent to the Paging
            Agent to page a particular Host in dormant mode because a
            packet has arrived for the Host.

         -  Negative response indication from the Paging Agent if the
            Host does not respond to a page.

         -  Positive response from the Paging Agent indication if the
            Host does respond to a page.




Kempf, et al.                Informational                     [Page 11]

RFC 3154                  Paging Requirements                August 2001


         -  Delivery of the packet to the Host.

      Host - Dormant Monitoring Agent (H-DMA) - The H-DMA interface
      supports the following types of traffic:

         -  The Host registers to the Dormant Monitoring Agent prior to
            entering dormant mode, (if needed) with filtering
            information on which broadcast/multicast/anycast packets
            trigger a page.

         -  The Host informs the Dormant Monitoring Agent, when it
            directly deregisters from the Dormant Monitoring Agent due
            to a change from dormant mode to active or inactive mode.

5.3. Functional Architecture Diagram

   The functional architecture and interfaces lead to the following
   diagram.

            +------+          H-TA            +----------+
            | Host | <----------------------> | Tracking |
            +------+                          |   Agent  |
                ^ ^                           +----------+
                | |           H-DMA                 ^
                | +------------------------------+  |
                |                                |  | DMA-TA
                |                                |  |
                | H-PA                           |  |
                v                                v  v
            +--------+         DMA-PA         +------------+
            | Paging | <--------------------> |  Dormant   |
            | Agent  |                        | Monitoring |
            +--------+                        |   Agent    |
                                              +------------+


                Figure 1 - Paging Functional Architecture

6.   Acknowledgements

   The authors would like to thank Arthur Ross for helpful comments on
   this memo.









Kempf, et al.                Informational                     [Page 12]

RFC 3154                  Paging Requirements                August 2001


7.   References

   [1]   Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
         Statement", RFC 3132, June 2001.

   [2]   Perkins, C., ed., "IP Mobility Support", RFC 2002, October,
         1996.

   [3]   Johnson, D., and Perkins, C., "Mobility Support in Ipv6", Work
         in Progress.

   [4]   Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.

   [5]   Kent, S., and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

8.   Authors' Addresses

   James Kempf
   Sun Microsystems Laboratories
   901 San Antonio Rd.
   UMTV29-235
   Palo Alto, CA
   95303-4900
   USA

   Phone: +1 650 336 1684
   Fax:   +1 650 691 0893
   EMail: James.Kempf@Sun.COM


   Pars Mutaf
   INRIA Rhone-Alpes
   655 avenue de l'Europe
   38330 Montbonnot Saint-Martin
   FRANCE

   Phone:
   Fax:   +33 4 76 61 52 52
   EMail: pars.mutaf@inria.fr










Kempf, et al.                Informational                     [Page 13]

RFC 3154                  Paging Requirements                August 2001


   Claude Castelluccia
   INRIA Rhone-Alpes
   655 avenue de l'Europe
   38330 Montbonnot Saint-Martin
   FRANCE

   Phone: +33 4 76 61 52 15
   Fax:   +33 4 76 61 52 52
   EMail: claude.castelluccia@inria.fr


   Nobuyasu Nakajima
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ
   07961-0136
   USA

   Phone: +1 973 829 4752
   EMail: nnakajima@tari.toshiba.com


   Yoshihiro Ohba
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ
   07961-0136
   USA

   Phone: +1 973 829 5174
   Fax:   +1 973 829 5601
   EMail: yohba@tari.toshiba.com


   Ramachandran Ramjee
   Bell Labs, Lucent Technologies
   Room 4g-526
   101 Crawfords Corner Road
   Holmdel, NJ
   07733
   USA

   Phone: +1 732 949 3306
   Fax:   +1 732 949 4513
   EMail: ramjee@bell-labs.com






Kempf, et al.                Informational                     [Page 14]

RFC 3154                  Paging Requirements                August 2001


   Yousuf Saifullah
   Nokia Research Center
   6000 Connection Dr.
   Irving, TX
   75039
   USA

   Phone: +1 972 894 6966
   Fax:   +1 972 894 4589
   EMail:  Yousuf.Saifullah@nokia.com


   Behcet Sarikaya
   Alcatel USA, M/S CT02
   1201 Campbell Rd.
   Richardson, TX
   75081-1936
   USA

   Phone: +1 972 996 5075
   Fax:   +1 972 996 5174
   EMail: Behcet.Sarikaya@usa.alcatel.com


   Xiaofeng Xu
   Alcatel USA, M/S CT02
   1201 Campbell Rd.
   Richardson, TX
   75081-1936
   USA

   Phone: +1 972 996 2047
   Fax:     +1 972 996 5174
   Email:  xiaofeng.xu@usa.alcatel.com

















Kempf, et al.                Informational                     [Page 15]

RFC 3154                  Paging Requirements                August 2001


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



















Kempf, et al.                Informational                     [Page 16]