Seamoby Working Group J. Kempf, Internet Draft Editor draft-ietf-seamoby-paging-protocol-assessment-00.txt P. Chitrapu Expires: May, 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. Two of the five were submitted by the same design team, and were treated as one protocol for purposes of assessment, since one of the two deals strictly with interfacing an IP paging protocol with L2 paging. 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, and makes a recommendation to the Working Group about how to proceed with the design and standardization of an IP DHMA protocol. Table of Contents Kempf,Editor Informational - Expires May, 2002 [Page 1] DMHA Protocol Assessment November 2001 1.0 Introduction 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. Each panel member was assigned one protocol. 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 panel members were requested to assign a rating to their assigned protocol for each requirement. The rating was as follows: 1) The protocol does not meet the requirement. 2) The protocol underspecifies the requirement, to the extent that it would not be possible to interoperably implement the protocol and still satisfy the requirement. 3) The protocol overspecifies this requirement to the extent that there are multiple possible solutions proposed and further work will be required to whittle them down to a specific solution or set of solutions with specification about how to achieve interoperability. 4) The protocol exactly specifies this requirement to the extent that an implementation with reasonable chance of interoperability should result from the design. If a rating of 2 or 3 was assigned to the protocol, the panel members were requested to provide a short paragraph explaining why the assessment was made. The assumption was that reasons for a rating of 1 or 4 would be obvious. 3.0 Summary of Results The following table summarizes the results of the assessment. Kempf, Editor Informational - Expires May, 2002 [Page 2] DMHA Protocol Assessment November 2001 |------------|------------|-------------|-------------|------------| | | Ref. [3] | Ref. [4] | Refs. | Ref. [5] | | | | |-------------| | | | | | [6] [7] | | |------------|------------|-------------|-------------|------------| | 4.1 | | | | | | Power | 4 | 4 | 4 4 | 3 | | Consumption| | | | | |------------|------------|-------------|-------------|------------| | 4.2 | | | | | | Scalabi- | 2 | 2 | 2 2 | 2 | | lity | | | | | |------------|------------|-------------|-------------|------------| | 4.3 | | | | | | Filter | 4 | 4 | 4 4 | 4 | | Control | | | | | |------------|------------|-------------|-------------|------------| | 4.4 | | | | | |Efficient S-| | | 1 4 | | |ignaling wh-| 2 | 1 | | 2 | |ile inactive| | | | | |------------|------------|-------------|-------------|------------| | 4.5 | | | | | | No Mobile | 4 | 4 | 4 4 | 4 | | Routers | | | | | |------------|------------|-------------|-------------|------------| | 4.6 | | | | | | Multiple | | | 4/2 1 | | | Dormant | 2 | 1 | | 2 | | Modes | | | | | |------------|------------|-------------|-------------|------------| | 4.7 | | | | | |Independence| | | 1 4 | | | of Mobility| 4 | 3 | | 4 | | Protocols | | | | | |------------|------------|-------------|-------------|------------| | 4.8 | | | | | | Support | | | | | | of Mobility| 4 | 4 | 2 1 | 4 | | Protocols | | | | | |------------|------------|-------------|-------------|------------| | 4.9 | | | | | | Dormant | | | 4 4 | | | mode | 4 | 2 | | 4 | | Termination| | | | | |------------|------------|-------------|-------------|------------| | 4.10 | | | 2 4 | | | Network | 4 | 4 | | 4 | | Updates | | | | | |------------|------------|-------------|-------------|------------| | 4.11 | | | | | | Utlization | 2 | 2 | 4 4 | 4 | | of L2 | | | | | |------------|------------|-------------|-------------|------------| Kempf, Editor Informational - Expires May, 2002 [Page 3] DMHA Protocol Assessment November 2001 |------------|------------|-------------|-------------|------------| | 4.12 | | | | | | Orthogonal-| | | 4 4 | | | ity of PA | 4 | 1 | | 2 | | and subnets| | | | | |------------|------------|-------------|-------------|------------| | 4.13 | | | | | | Future | | | | | | L3 Paging | 4 | 4 | 4 4 | 4 | | Support | | | | | |------------|------------|-------------|-------------|------------| | 4.14 | | | | | | Robustness | | | 2 1 | | | against | 2 | 2 | | 2 | | Failures | | | | | |------------|------------|-------------|-------------|------------| | 4.15 | | | | | | Reliability| | | 4 4 | | | of Packet | 4 | 2 | | 2 | | Delivery | | | | | |------------|------------|-------------|-------------|------------| | 4.16 | | | | | | Robustness | | | 4 4 | | | against | 4 | 4 | | 4 | | Packet Loss| | | | | |------------|------------|-------------|-------------|------------| | 4.17 | | | | | | Administra-| | | 4 1 | | | ive Flexib-| 2 | 4 | | 2 | | ility | | | | | |------------|------------|-------------|-------------|------------| | 4.18 | | | | | | Flexibilty | 4 | 4 | 4/2 4/2 | 1 | |of PA Design| | | | | |------------|------------|-------------|-------------|------------| | 4.19 | | | | | |Availability| | | 4/2 4 | | | of Security| 2 | 1 | | 4/2 | | Support | | | | | |------------|------------|-------------|-------------|------------| | 4.20 | | | | | | Authentica-| | | | | | ion of PA | 2/3 | 1 | 4 4 | 4 | |Registration| | | | | |------------|------------|-------------|-------------|------------| | 4.21 | | | | | | Authentica-| | | | | | ion of PA | 1 | 1 | 2 2 | 4 | | Information| | | | | |------------|------------|-------------|-------------|------------| Kempf, Editor Informational - Expires May, 2002 [Page 4] DMHA Protocol Assessment November 2001 |------------|------------|-------------|-------------|------------| | 4.22 | | | | | | Authentica-| | | | | | ion of PA | 1/3 | 3 | 1 4/2 | 4 | | Messages | | | | | |------------|------------|-------------|-------------|------------| | 4.23 | | | | | | Paging | 4 | 2 | 2 4/2 | 4 | | Volume | | | | | |------------|------------|-------------|-------------|------------| | 4.24 | | | | | |Parsimonious| | | 4 4 | | | Security | 4 | NA | | 4 | | Messaging | | | | | |------------|------------|-------------|-------------|------------| | 4.25 | | | | | |Non-interfe-| | | 4/2 4/2 | | |rence of Hos| 4 | 4 | | 4 | |t's Security| | | | | |------------|------------|-------------|-------------|------------| | 4.26 | | | | | |Non-interfe-| | 4 | 4/2 4/2 | | |rence with | 4 | | | 4 | |e2e Security| | | | | |------------|------------|-------------|-------------|------------| | 4.27 | | | | | |Detection of| 4 | 4 | 4 1 | 4 | | bogus CNs | | | | | |------------|------------|-------------|-------------|------------| 4.0 Discussion This section contains a discussion of the results for those cases where a rating of 2 or 3 was given. 4.1 draft-koodli-paging-00.txt 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 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 Kempf, Editor Informational - Expires May, 2002 [Page 5] DMHA Protocol Assessment November 2001 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. 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 Kempf, Editor Informational - Expires May, 2002 [Page 6] DMHA Protocol Assessment November 2001 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. 4.2 draft-renker-paging-ipv6-01.txt 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. 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 Kempf, Editor Informational - Expires May, 2002 [Page 7] DMHA Protocol Assessment November 2001 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 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. Kempf, Editor Informational - Expires May, 2002 [Page 8] DMHA Protocol Assessment November 2001 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 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: Kempf, Editor Informational - Expires May, 2002 [Page 9] DMHA Protocol Assessment November 2001 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? 4.3 draft-sarikaya-seamoby-mipv6hp-00.txt, draft-guri-seamoby- lahap-00.txt The following requirements were not fully met by draft-sarikaya- seamoby-mipv6hp-00.txt: 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 Kempf, Editor Informational - Expires May, 2002 [Page 10] DMHA Protocol Assessment November 2001 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. 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. The following requirements were not fully met by draft-guri-seamoby- lahap-00.txt: Kempf, Editor Informational - Expires May, 2002 [Page 11] DMHA Protocol Assessment November 2001 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 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. 4.4 draft-ohba-seamoby-last-hop-dmha-02.txt The following requirements were not fully met by draft-ohba-seamoby- last-hop-dmha-02.txt: _ 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 Kempf, Editor Informational - Expires May, 2002 [Page 12] DMHA Protocol Assessment November 2001 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 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. _ Kempf, Editor Informational - Expires May, 2002 [Page 13] DMHA Protocol Assessment November 2001 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 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. 5.0 Acknowledgements The Working Group Chairs would like to thank Prabhakar Chitrapu, of InterDigital, Theo Pagtzis, of UCL, Hung-yu Wei, of Columbia Kempf, Editor Informational - Expires May, 2002 [Page 14] DMHA Protocol Assessment November 2001 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. 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 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 Kempf, Editor Informational - Expires May, 2002 [Page 15] DMHA Protocol Assessment November 2001 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 May, 2002 [Page 16]