[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

   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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/