Seamoby Working Group J. Kempf,
Internet Draft Editor
draft-ietf-seamoby-paging-protocol-assessment-01.txt P. Chitrapu
Expires: August, 2002 T. Pagtzis
S.
Sreemanthula
H. Wei
Dormant Mode Host Alerting (DMHA) Protocol Assessment
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Seamoby Working Group has been working toward specification of
an IP-level protocol for Dormant Mode Host Alerting (DMHA),
sometimes known as IP-paging or simply paging (the terms IP-DMHA,
DMHA, IP Paging, and Paging will be used interchangeably in this
document). A problem statement and requirements have been developed,
and in response to a request for protocol submissions, five
protocols were submitted. The submitted proposals were assessed by
comparing them to the requirements by a team of four volunteers from
the Seamoby Working Group. This document presents the results of
that assessment, describes the procedure by which a recommendation
for Working Group draft was selected after the assessment failed to
come up with a recommendation.
Table of Contents
1.0 Introduction
Kempf,Editor Informational - Expires August, 2002 [Page 1]
DMHA Protocol Assessment Feburary 2002
As part of its quest to foster standards for seamless mobility, the
Seamoby Working Group has been working toward specifying a Dormant
Mode Host Alerting (DMHA), or paging, protocol. A call for protocol
designs, based on a problem statement [1] and requirements [1]
resulted in five protocol submissions [3][4][5][6][7]. Of these, [6]
and [7] were from the same team and were treated as one contribution
for purposes of assessment. This document presents an assessment of
the protocols.
2.0 Assessment Procedure
A panel of four volunteers from the Seamoby Working Group was
recruited to perform the assessment. Three of the four panel members
were assigned one protocol, one panel member was assigned two
protocols because we did not get enough volunteers. Input for the
assessment was the requirements document, the protocol design
itself, and a comparison between the protocol and the requirements
which the authors of the protocol themselves were requested to
write.
The team members were asked to use a rating system to compare the
protocol they were assigned against the requirements. Each team
member wrote up the results of their assessment, and submitted it to
the assessment draft editor for assembly into this draft. A
teleconference was held to discuss the assessments and normalize
assessments between different team members. The assessment team did
not make a recommendation about which draft to pick; however, the
team did recommend that the next step should be to either go through
another round of design in which the authors would attempt to refine
their proposals, or to immediately begin the process of harmonizing
the protocols to come up with a working group draft.
The next section contains comments from the assessment team members
about where the protocols either under- or overspecified a
requirement, and a list of requirements which the protocols were
judged to unacceptably specify.
3.0 Comments on Requirements Match
3.1 draft-koodli-paging-00.txt
Unacceptable Requirements Match:
4.21, 4.22
Under- or Overspecification:
Requirement 4.2: Scalability
Location of the PF is ambiguous. A centralized PF is a hot spot for
contention and will not scale well. A distributed PF was mentioned,
but there is no indication on how they will interact and communicate
Kempf, Editor Informational - Expires August, 2002 [Page 2]
DMHA Protocol Assessment Feburary 2002
with each other. It may not scale well because of signaling
messages.
Requirement 4.4: Efficient Signaling for Inactive Mode
The ideas of explicit and implicit dormancy are good. However, in
the implicit mode the PF still has to page the MN after the
inactivity timer expires. If during that time, the MN has moved to a
different paging area, under a different PF, the draft does not
state how such cases should be handled. Need more detailed
information.
Requirement 4.6: Multiple Dormant Modes
Need more explicit information.
Requirement 4.11: Efficient Utilization of L2
The draft did not specify how exactly it will utilize L2, let alone
the efficient utilization.
Requirement 4.14: Robustness Against Failure of Network Elements
The protocol does not address how PF and MN learn about failure and
how to recover from network element failure. Since there is only one
centralized PF for one Paging area, once a PF or a critical link to
PF fail, paging areas need to rearranged. How is the rearrangement
achieved?
Requirement 4.17: Flexibility of Administration
This requirement is fulfilled since the centralized paging function,
thus the topology of paging function can be very flexible. However,
the down side is it is impossible to separate Tracking Agent,
Dormant Monitoring Agent and Paging Agent. The three functional
entities should be in charge of the same set of hosts. This reduces
the flexibility of administration.
Requirement 4.19: Availability of Security Support
For example, the protocol does not describe Public Key Cryptography
techniques.
Requirement 4.20: Authentication of Paging Location Registration
This proposal provides procedures for the Paging Function
(PF=PA+DMA+TA) to authenticate the MN before accepting the Paging
Area Update message from the MN.
However the procedures do not address authenticating the PF by the
MN. In this respect, the protocol is underspecifed, as it is an
incomplete solution. Thus, the rating is 2 in this regard.
Kempf, Editor Informational - Expires August, 2002 [Page 3]
DMHA Protocol Assessment Feburary 2002
Secondly, the procedure for the PF to authenticate the MN prior to
accepting a paging update message is overspecified in that a number
of options are described and may prevent interoperability depending
upon which option is implemented by a particular vendor. Thus the
rating is 3 in this regard.
Requirement 4.21: Authentication of Paging Area Information
The protocol does not explicitly provide for authentication of
Paging Area information. However, the self-evaluation refers to PAU
and PAR authentication as providing Paging Area Information
authentication. It is not clear as to how this is true. For, PAU
(not explained in the document / assumed to be Paging Area Update)
only enables the PF to authenticate the MN and does not enable the
MN to authenticate the PA information. Similarly, PAR (not explained
in the document / assumed to be Paging Request) authentication only
authenticates the sender of the Paging Request message and does not
authenticate the Paging Area Information.
Requirement 4.22: Authentication of Paging Messages
The Paging Messages sent by the Paging Agent (i.e. Paging Function)
to dormant mode Hosts are: Paging Area Information advertisement,
Paging request. (Paging response and Paging Area update are sent in
the opposite direction (MN -> PF) and hence not covered by this
requirement.) Paging Area Information advertisement is already
covered in 4.21. Therefore, this requirement only covers Paging
Request message.
The protocol provides an authentication procedure for the Paging
Request message and thus meets the requirement. However, the
document further talks about the use of sequence numbers etc to
prevent replay attacks. This is overspecification, leading to a
rating of 3.
The protocol does not address the use of L2 security mechanisms.
Rating is 1.
3.2 draft-renker-paging-ipv6-01.txt
Unacceptable Requirements Match:
4.4, 4.6, 4.19, 4.20, 4.21
Under- or Overspecification:
Requirement 4.2: Scalability
Several signaling messages are needed for in and out of idle
(dormant) state transitions, and this may lead to unacceptable
overhead in the network and over expensive low bandwidth acees
links. In addition, when used with paging strategies there may be
large amount of information stored for each host.
Kempf, Editor Informational - Expires August, 2002 [Page 4]
DMHA Protocol Assessment Feburary 2002
Requirement 4.4: Efficient Signaling While Inactive
There is no mechanism to inform the Paging Agent that the host will
be inactive or unreachable.
Requirement 4.6: Multiple Dormant Modes
Although, there is a discussion of "implicit" and "explicit" dormant
modes, they both involve signaling exchanges between the MN and the
network, in one case using with Mobile IPv6 and the other with new
messages. So, in conclusion, there is no support for multiple
dormant modes.
Requirement 4.7: Independence of Mobility Protocol
The independence of mobility protocol is valid for "explicit" case
only. The design specifies two separate protocols, one for Mobile IP
and one without Mobile IP.
Requirement 4.9: Dormant Mode Termination
The proposal does not completely define the dormant mode
termination. It explains how to de-register from the dormant mode
with BU(0) or Idle-Mode-Req(0) but when does the host perform BU
with a nCoA to HA and CN? When and how does the PA forward all the
packets to host, is it after receiving BU(0)? There must be some
correlation in order for this to work well. The signaling messages
and the entity's behavior after the paging request is sent are
missing in the draft.
Requirement 4.10: Network Updates
In Section 9.2.1, it is briefly mentioned that when host is roaming
into a new PA, it must send a Idle-State-Request to the Paging Agent
to update the new PA-id. But more description is needed. How does
it work with "implicit" case using BU.
Requirement 4.11: Efficient Utilization of L2
In some systems, th mobile hosts may go dormant at L2 based on some
L2-timers. But according to this proposal, since there is no support
for dormancy based on timeouts where the host can go dormant without
having to send any signaling to the network, the MN needs to wake up
from L2 dormancy to begin the L3 dormancy. This leads to inefficient
usage of L2 dormancy and paging mechanisms, worsening the power
saving with respect to L2 only dormancy.
Requirement 4.12: Orthogonality of PA and Subnets
In cellular technology, however, the TMSI (not the IMSI) is used to
page a particular host and the TMSI is assigned by the Access
Network upon registration (or updated during the Routing Area
Update). The host will not know the TMSI in advance. So in the
Kempf, Editor Informational - Expires August, 2002 [Page 5]
DMHA Protocol Assessment Feburary 2002
proposed draft, a host can not move from non-cellular to cellular
system except if the non cellular and the cellular system
(WCDMA/cdma2000) are in different paging areas where upon moving to
a new paging area, the host has to send a new BU and the sub-option
contain the TMSI.
Requirement 4.14: Robustness against Failures
The proposal recommends agent replication but does not specify the
details.
Requirement 4.15: Reliability of Packet Delivery
The proposal does not describe how the buffered packets at paging
agent are sent to host.
Requirement 4.20: Authentication of PA registration
The authentication of the registration messages is not described.
When relying on MIPv6 messages, the protocol relies on the
authentication data of the binding update, but is not mobility
protocol independent anymore.
Requirement 4.21: Authentication of PA Information
There is no mechanism described for authentication PA information
from the paging agent. It is left to the Access Routers in RtAdv,
but they are traditionally not authenticated.
Requirement 4.22: Authentication of PA Messages
There is no authentication mechanism described for paging requests.
There are probably several solutions possible.
Requirement 4.23: Paging Volume
After host receives paging request, it sends a high volume of L3
messages to de-register from idle state. This may introduce high
overhead in the network and hinder the ability of other MNs to
access to services, in particular over low bandwidth links.
Requirement 4.24: Parsimonious Security Messaging
There is no security definition in the Idle-State-Rqst/Rply
messages. Therefore, this is not applicable.
Requirement 4.25: Non-interference of Host's Security
Since the proposal does not describe how the messages are secured
(e.g. how the authentication data are sent - using AH, or a new
security sub-option), we can not know if this IP paging protocol
impose any limitations on a Host security policies.
Requirement 4.26: Non-interference of End-to-End Security
Kempf, Editor Informational - Expires August, 2002 [Page 6]
DMHA Protocol Assessment Feburary 2002
Same as above.
In addition, the following general concerns were expressed about the
protocol design:
1) How is the PA update performed when the host is in the idle
state and moving?
2) There is no description of how the mobility management is
completed after the paging request is received. There must be
some coordination on when the deregistration is sent to PA.
3) The proposal provides a solution independent of the mobile
protocols. A large number of L3 messages needs to be exchanged
in the following cases:
i) BU/BA to PA, all HA and CN when transitioning into the
idle state,
ii) BU/BA to PA, all HA and CN when transitioning out of the
idle state (entering active state),
iii) Registering with a new CoA for the idle state may be
undesirable, this forces BU to all CN.
4) Excessive signaling in the above cases could lead to too much
power consumption on host.
5) When Paging Area strategies are used, it is not clear how the
dynamic paging areas are defined for each user. This mode also
requires storage of a lot of state information leading to a
not-so scalable network.
6) Optimization with RH described in section 5.2.2 may not work
for security reasons. Binding update are authenticated thanks
to AH; but the authentication data carried in AH corresponds
to the one between the MN and the HA. How would the
authentication data between the MN and the PA be carried?
7) Unclear use of "implicit" and "explicit" terms. Both involve
messaging to indicate the idle state transition.
8) Use of paging-id to page the host in inter-system is not
clear. For exaample, when the host idle-registers in WLAN
coverage and then moves to a cellular system, how does the
paging agent know the L2 id of the cellular system?
3.3 draft-sarikaya-seamoby-mipv6hp-00.txt
Unacceptable Requirements Match:
4.4, 4.7, 4.22
Under- or Overspecification:
Kempf, Editor Informational - Expires August, 2002 [Page 7]
DMHA Protocol Assessment Feburary 2002
Requirement 4.2: Scalability
This proposal is heavily dependent on HMIPv6 for scalability. The
MAP is a bottleneck that could lead to scalability problems.
Requirement 4.4: Efficient Signaling for Inactive Mode
No comment.
Requirement 4.6: Multiple Dormant Modes
The protocol can support multiple dormant modes. It will become more
complete if more descriptions about operation with multiple nodes
are added
Requirement 4.7: Independence of Mobility Protocol
Basically, the protocol assumes Hierarchical MIPv6 as the underlying
mobility protocol. Extra efforts could be made to eliminate the
dependence of HMIPv6 and this protocol.
Requirement 4.8: Support for Existing Mobility Protocols
Support MIPv6. However, does not claim any support on MIPv4.
Requirement 4.10: Network Updates
Key aspects are missing for network update.
Requirement 4.14: Robustness against Failures
The proposal depends on MAP replication, which is, as yet not well
specified.
Requirement 4.18: Flexibility of Paging Area Design
No special limitation on paging area design. Support both L2 and L3
paging area. However, mechanism to support adaptive paging area
assignment needs to be further specified.
Requirement 4.19: Availability of Security Support
The protocol conducts a security analysis, but it is not clear that
it is deep enough.
Requirement 4.21: Authentication of Paging Area Information
Does not solve 'Bogus Paging Area' problem
Requirement 4.22: Authentication of PA Messages
No authentication is specified in HMIPv6, upon which this protocol
depends.
Kempf, Editor Informational - Expires August, 2002 [Page 8]
DMHA Protocol Assessment Feburary 2002
Requirement 4.23: Paging Volume
Currently handle paging request in per host basis. Future revision
about handling several request together is in progress.
Requirement 4.25: Non-interference of Host's Security
In the evaluator's judgement, there seems to be no interference, but
further analysis is necessary in case some interaction with IPSEC
may turn up.
Requirement 4.26: Non-interference with End to End Security
Same as 4.25.
3.4 draft-guri-seamoby-lahap-00.txt
Unacceptable Requirements Match:
4.6, 4.8, 4.14, 4.17, 4.27
Under- or Overspecification:
Requirement 4.2: Scalability
Not clearly stated.
Requirement 4.6: Multiple Dormant Modes
Is not specified.
Requirement 4.8: Support for Existing Mobility Protocols
Interaction with MIPv4 and MIPv6 are not specified
Requirement 4.14: Robustness Against Failure of Network Elements
No comment.
Requirement 4.17: Flexibility of Administration
Not specified.
Requirement 4.18: Flexibility of Paging Area Design
No special limitation on paging area design. Support both L2 and L3
paging area. However, mechanism to support adaptive paging area
assignment needs to be further specified.
Requirement 4.21: Authentication of Paging Area Information
Does not solve 'Bogus Paging Area' problem.
Requirement 4.25: Non-interference of Host's Security
Kempf, Editor Informational - Expires August, 2002 [Page 9]
DMHA Protocol Assessment Feburary 2002
In the evaluator's judgement, there seems to be no interference, but
further analysis is necessary in case some interaction with IPSEC
may turn up.
Requirement 4.26: Non-interference with End to End Security
Same as 4.25.
Requirement 4.27: Detection of Bogus Correspondent Nodes
No specification about authentication of CN.
3.5 draft-ohba-seamoby-last-hop-dmha-02.txt
Unacceptable Requirements Match:
4.18
Under- or Overspecification:
_
Requirement 4.1: Power Consumption
Registration to the TA through the DMA may not be optimal in terms
of power consumption, since a DMA Reg-ACK cannot be returned to the
host until the TA acknowledges the proxy registration request.
However, since the author also specified the direct communication of
the host with the TA, this requirement is overspecified to the
degree that can detract from efficiency.
_
Requirement 4.2: Scalability
The protocol tends to describe its operation with one DMA per link,
one TA (primarily) and multiple PAs, as shown in Figure 3. When the
protocol suggests that more than one TA can be present and each one
manages a specific set of hosts, it fails to specify how this is
achieved.
Requirement 4.4: Efficient Signaling Inactive Mode
The protocol underspecifies the requirement because it suggests that
successive paging operations are to follow a paging interval that
increases exponentially, but does not specify an initial and final
value that the exponential figure is allowed to reach. Is it
persistent in the paging retry? Does it time-out at all?
_
Requirement 4.6: Multiple Dormant Modes
The type of dormant modes that the protocol attempts to support is
based on a particular technology, while the protocol does not affect
the operation of the MAC layer at all. While one can claim that the
protocol combines L2 power saving features that contribute to power
conservation, this is not owed to or couple with the proposed
protocol. It is simply a manifestation of power savings through
Kempf, Editor Informational - Expires August, 2002 [Page 10]
DMHA Protocol Assessment Feburary 2002
special forms of MPDU scheduling. Any protocol can claim such
cooperation. Important aspect of dormancy like slotted dormant for
non-L2 layer has not been considered by the protocol.
Requirement 4.12: Orthogonality of PA and Subnets
The description of the protocol, although it mentions paging areas,
does not specify clearly how this is achieved since there is no
specific description of how the page message diffuses over an
topology of multiple subnets that are controlled by a single PA.
_
_
Requirement 4.14: Robustness against Failures
While the protocol specifies keep-alive signals between the peer
agents, it does not specify a scheme that allows recovery from
failure.
_
Requirement 4.15: Reliability of Packet Delivery
The transport used in this protocol is UDP. The protocol does not
describe how the packet is forwarded to the host. In particular, it
does not describe what is the situation when the packet received at
the DMA is TCP.
_
Requirement 4.17: Administrative Flexibility
The configuration of the paging areas is not quite automatic as
claimed. In particular the protocol does not specify how the page
area identifiers are assigned/allocated such that they can be
distributed to the individual paging agents.
_
Requirement 4.18: Flexibility of PA Design
With respect to the claimed flexibility, the design is not clear in
Fig. 3. The TA propagates paging requests, why?
_
Requirement 4.19: Availability of Security Support
The protocol does not support encryption services. It only supports
authentication. For ESP security, it relies on mechanisms such as
IPsec.
In addition, the following general concerns were expressed about the
protocol design:
1) The protocol utilizes the DMA like the TA in the functional
architecture draft, but does not specify a method for the DMA
to discover an appropriate TA. The assumption seems to be that
there will be a single TA per administrative domain or multiple
TAs with the TA to DMA mapping manually configured.
2) The protocol assumes the dormant host can detect a paging area
change, which implies that time-slotted paging must be used if
Kempf, Editor Informational - Expires August, 2002 [Page 11]
DMHA Protocol Assessment Feburary 2002
there is no L2 paging channel support. However, the protocol
does not explicitly mention how it would support time-slotted
paging.
3) The proxy interactions between the DMA and TA on behalf of the
dormant host incur extraneous signaling and may lead to
inefficient power consumption.
4) The assumption that the DMA is located on the last hop subnet,
which is the foundation of the design, means that the PA is
unnecessary, and links the paging area directly to the subnet.
5) The protocol specifies heartbeat messages between agent peers.
This method can identify a failed agent, but it cannot specify
how to recover from failure.
6) The protocol does not specify how a host chooses between DMAs
nor how a DMA chooses between TAs.
4.0 Decision Process
Given that the assessment team's recommendation about which draft to
accept was indeterminate, a decision team was formed by the two
Working Group co-chairs, with the Area Director providing advice.
The decision team decided to proceed toward selecting a draft for
recommendation to the Working Group as the basis of a harmonized
protocol, in order to avoid further delay in starting on the process
of designing the Seamoby paging protocol. This procedure is entirely
consistent with RFC 2418 [8], since the Working Group co-chairs'
decision is subject to working group concensus, so the Working Group
has the final say on whether the selected draft actually becomes the
working group draft.
The decision about which draft to select was difficult, because each
draft had particular aspects that were well thought out and
recommended themselves for inclusion in the final result, but none
of the drafts exhibited the maturity of implementation and design
that immediately suggested it as the only possible candidate for
selection. Some drafts had particular aspects that mitigated
strongly against selection. A good example of this difficulty is
Requirement 4.6, Multiple Dormant Modes. This requirement was
intended to foster support for hosts that have no explicit L2 paging
support, basically time-slotted paging. Draft-sarikaya has an
excellent discussion of time-slotted paging mode, but the basis of
that draft is a protocol (HMIPv6) that has been proposed in another
working group for a problem that is still in the requirements
phase, and the proposed paging protocol supports only Mobile IPv6.
The other proposals had varying degrees of support for time-slotted
paging, but none was sufficient to recommend itself on this
particular requirement.
Kempf, Editor Informational - Expires August, 2002 [Page 12]
DMHA Protocol Assessment Feburary 2002
The assessment team's work allowed the decision team to reduce the
number of drafts under consideration from five to two. The decision
team quickly decided to rule out draft-koodli because the draft is
lacking in specifics and is vague on many requirements, as mentioned
in the assessment team's report. Draft-sarikaya was ruled out
because it is based on a protocol that is currently under evaluation
in another working group, setting up an unacceptable dependency
between the Seamoby paging protocol design and the other working
group's process. Also, draft-sarikaya exclusively supports Mobile
IPv6, and a primary requirement of all Seamoby work is that the
protocols be independent of mobility protocol. While the assessment
of draft-guri was positive, draft-guri is explicitly concerned with
utilizing Layer 2 support for paging, and was therefore not
sufficiently broad enough as a base for IP paging. However, the
ideas expressed in draft-guri were felt to be valuable and necessary
for including in the final Seamoby paging protocol for those cases
where Layer 2 paging support is available.
The decision between the remaining two drafts, draft-renker and
draft-ohba, was especially difficult because they were judged to be
about of equal quality. The decision team decided to focus on three
primary requirements that were thought to be crucial to the
successful acceptance of IP paging: independence of mobility
protocol, support for existing mobility protocols, and independence
of paging area from subnet topology.
Of these, both draft-renker and draft-ohba provided adequate support
for the first two, independence of mobility protocol and support for
existing mobility protocols. Draft-renker was judged by the
assessment team to be overspecific in these areas, in the sense that
it contained two modes, explicit mode and implicit mode, depending
on whether Mobile IP was supported or not. However, considering the
relatively immature state of the paging protocol design, the
decision team felt that providing the working group with choices,
where the benefits and drawbacks of each choice could be clearly
weighed, was preferable to providing a fixed decision, so draft-
renker was judged to be better in this regard.
On the requirement for independence of paging area from subnet
topology, the support described in draft-ohba was very sketchy and
did not provide the decision team with a clear idea about how this
could be achieved, particularly with regard to the movement of a
mobile host while the host is in dormant mode. Draft-renker has a
much clearer description of how this could be achieved, and was
judged to be better in this regard.
Additional aspects of draft-renker that recommended it as the
selection were attention to details of interaction with existing IP
routing, and a survey of paging strategies. While probably not
essential to the final protocol design, the material on paging
strategies showed that the authors had given some thought to
separating policy from mechanism, and were familiar with the
somewhat extensive academic literature on paging, and IP paging in
particular.
Kempf, Editor Informational - Expires August, 2002 [Page 13]
DMHA Protocol Assessment Feburary 2002
While draft-renker was selected by the decision team as the basis
for continued Seamoby paging protocol work, the decision team feels
that it is important to incorporate the outstanding contributions of
the other authors into the final protocol design, in particular, the
time-slotted paging discussion in draft-sarikaya, the Layer 2
interface work in draft-guri, the paging state machine discussion in
draft-koodli, and the security protocol work in draft-ohba.
Additional aspects of the other drafts that address issues which
were weakly addressed or not addressed at all in draft-renker should
also be incorporated, as well as ideas from other working group
members that address requirement which none of the draft addressed
particularly well.
5.0 Acknowledgements
The Working Group Chairs would like to thank Prabhakar Chitrapu, of
InterDigital, Theo Pagtzis, of UCL, Hung-yu Wei, of Columbia
University, and Sirinivas Sreemanthula, of the Nokia Dallas Research
Center, for helping perform the protocol assessment.
6.0 References
[1] Kempf, J., Editor, "Dormant Mode Host Alerting ("IP Paging")
Problem Statement," RFC 3132, June, 2001.
[2] Kempf, J., et. al. "Requirements and Functional Architecture
for an IP Host Alerting Protocol," RFC 3154, August, 2001.
[3] Faccin, S., et. al., "Dormant Mode Handover Support in Mobile
Networks," draft-koodli-paging-00.txt, a work in progress.
[4] Liebsch, M., Renker, G., and Schmitz, R., "Paging Concept for
IP based Networks," draft-renker-paging-ipv6-01.txt, a work in
progress.
[5] Ohba, Y., Nakajima, N., and Zhang, T., "LH-DMHA - Last Hop DMHA
(Dormant Mode Host Alerting) Protocol," draft-ohba-seamoby-
last-hop-dmha-02.txt, a work in progress.
[6] Sarikaya, B., et. al., "Mobile IPv6 Hierarchical Paging,"
draft-sarikaya-seamoby-mipv6hp-00.txt, a work in progress.
[7] Gurivireddy, S., et. al., "Layer-2 aided mobility independent
dormant host alerting protocol," draft-guri-seamoby-lahap-
00.txt, a work in progress.
[8] Bradner, S., "IETF Working Group Guidelines and Procedures,"
RFC 2418, September, 1998.
7.0 Authors' Address
James Kempf
DoCoMo Communications Labs USA
181 Metro Drive, Suite 300
San Jose, CA, 95110
USA
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com
Kempf, Editor Informational - Expires August, 2002 [Page 14]
DMHA Protocol Assessment Feburary 2002
Prabhakar Chitrapu
InterDigital Communications Corp.
781 Third Avenue
King of Prussia, PA, 19406
USA
Phone: +1 610 878 5730
Email: Prabhakar.Chitrapu@InterDigital.com
Theo Pagtzis
Dept. of Computer Science
University College London
Gower Street
WC1E 6BT, London
UK
Phone: +44 (0) 20 7679 3666
Email: t.pagtzis@cs.ucl.ac.uk
Sirinivas Sreemanthula
Nokia Research Center
6000 Connection Drive
Irving, TX, 75039
USA
Phone: +1 972 894 4356
Fax: +1 972 894 4589
Email: srinivas.sreemanthula@nokia.com
Hung-yu Wei
Columbia University
Room 710, Schapiro Res
530 West 120th Street
New York, NY, 10027
USA
Phone: +1 212 854 7477
Email: hywei@ctr.columbia.edu
Kempf, Editor Informational - Expires August, 2002 [Page 15]
