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]