idnits 2.17.1 draft-ietf-seamoby-paging-protocol-assessment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '...ecified in th...' == Line 650 has weird spacing: '...s still in th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 739, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3132 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3154 (ref. '2') == Outdated reference: A later version (-01) exists of draft-koodli-paging-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Seamoby Working Group J. Kempf, 3 Internet Draft Editor 4 draft-ietf-seamoby-paging-protocol-assessment-01.txt P. Chitrapu 5 Expires: August, 2002 T. Pagtzis 6 S. 7 Sreemanthula 8 H. Wei 10 Dormant Mode Host Alerting (DMHA) Protocol Assessment 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Seamoby Working Group has been working toward specification of 35 an IP-level protocol for Dormant Mode Host Alerting (DMHA), 36 sometimes known as IP-paging or simply paging (the terms IP-DMHA, 37 DMHA, IP Paging, and Paging will be used interchangeably in this 38 document). A problem statement and requirements have been developed, 39 and in response to a request for protocol submissions, five 40 protocols were submitted. The submitted proposals were assessed by 41 comparing them to the requirements by a team of four volunteers from 42 the Seamoby Working Group. This document presents the results of 43 that assessment, describes the procedure by which a recommendation 44 for Working Group draft was selected after the assessment failed to 45 come up with a recommendation. 47 Table of Contents 49 1.0 Introduction 50 DMHA Protocol Assessment Feburary 2002 52 As part of its quest to foster standards for seamless mobility, the 53 Seamoby Working Group has been working toward specifying a Dormant 54 Mode Host Alerting (DMHA), or paging, protocol. A call for protocol 55 designs, based on a problem statement [1] and requirements [1] 56 resulted in five protocol submissions [3][4][5][6][7]. Of these, [6] 57 and [7] were from the same team and were treated as one contribution 58 for purposes of assessment. This document presents an assessment of 59 the protocols. 61 2.0 Assessment Procedure 63 A panel of four volunteers from the Seamoby Working Group was 64 recruited to perform the assessment. Three of the four panel members 65 were assigned one protocol, one panel member was assigned two 66 protocols because we did not get enough volunteers. Input for the 67 assessment was the requirements document, the protocol design 68 itself, and a comparison between the protocol and the requirements 69 which the authors of the protocol themselves were requested to 70 write. 72 The team members were asked to use a rating system to compare the 73 protocol they were assigned against the requirements. Each team 74 member wrote up the results of their assessment, and submitted it to 75 the assessment draft editor for assembly into this draft. A 76 teleconference was held to discuss the assessments and normalize 77 assessments between different team members. The assessment team did 78 not make a recommendation about which draft to pick; however, the 79 team did recommend that the next step should be to either go through 80 another round of design in which the authors would attempt to refine 81 their proposals, or to immediately begin the process of harmonizing 82 the protocols to come up with a working group draft. 84 The next section contains comments from the assessment team members 85 about where the protocols either under- or overspecified a 86 requirement, and a list of requirements which the protocols were 87 judged to unacceptably specify. 89 3.0 Comments on Requirements Match 91 3.1 draft-koodli-paging-00.txt 93 Unacceptable Requirements Match: 95 4.21, 4.22 97 Under- or Overspecification: 99 Requirement 4.2: Scalability 101 Location of the PF is ambiguous. A centralized PF is a hot spot for 102 contention and will not scale well. A distributed PF was mentioned, 103 but there is no indication on how they will interact and communicate 104 DMHA Protocol Assessment Feburary 2002 106 with each other. It may not scale well because of signaling 107 messages. 109 Requirement 4.4: Efficient Signaling for Inactive Mode 111 The ideas of explicit and implicit dormancy are good. However, in 112 the implicit mode the PF still has to page the MN after the 113 inactivity timer expires. If during that time, the MN has moved to a 114 different paging area, under a different PF, the draft does not 115 state how such cases should be handled. Need more detailed 116 information. 118 Requirement 4.6: Multiple Dormant Modes 120 Need more explicit information. 122 Requirement 4.11: Efficient Utilization of L2 124 The draft did not specify how exactly it will utilize L2, let alone 125 the efficient utilization. 127 Requirement 4.14: Robustness Against Failure of Network Elements 129 The protocol does not address how PF and MN learn about failure and 130 how to recover from network element failure. Since there is only one 131 centralized PF for one Paging area, once a PF or a critical link to 132 PF fail, paging areas need to rearranged. How is the rearrangement 133 achieved? 135 Requirement 4.17: Flexibility of Administration 137 This requirement is fulfilled since the centralized paging function, 138 thus the topology of paging function can be very flexible. However, 139 the down side is it is impossible to separate Tracking Agent, 140 Dormant Monitoring Agent and Paging Agent. The three functional 141 entities should be in charge of the same set of hosts. This reduces 142 the flexibility of administration. 144 Requirement 4.19: Availability of Security Support 146 For example, the protocol does not describe Public Key Cryptography 147 techniques. 149 Requirement 4.20: Authentication of Paging Location Registration 151 This proposal provides procedures for the Paging Function 152 (PF=PA+DMA+TA) to authenticate the MN before accepting the Paging 153 Area Update message from the MN. 155 However the procedures do not address authenticating the PF by the 156 MN. In this respect, the protocol is underspecifed, as it is an 157 incomplete solution. Thus, the rating is 2 in this regard. 159 DMHA Protocol Assessment Feburary 2002 161 Secondly, the procedure for the PF to authenticate the MN prior to 162 accepting a paging update message is overspecified in that a number 163 of options are described and may prevent interoperability depending 164 upon which option is implemented by a particular vendor. Thus the 165 rating is 3 in this regard. 167 Requirement 4.21: Authentication of Paging Area Information 169 The protocol does not explicitly provide for authentication of 170 Paging Area information. However, the self-evaluation refers to PAU 171 and PAR authentication as providing Paging Area Information 172 authentication. It is not clear as to how this is true. For, PAU 173 (not explained in the document / assumed to be Paging Area Update) 174 only enables the PF to authenticate the MN and does not enable the 175 MN to authenticate the PA information. Similarly, PAR (not explained 176 in the document / assumed to be Paging Request) authentication only 177 authenticates the sender of the Paging Request message and does not 178 authenticate the Paging Area Information. 180 Requirement 4.22: Authentication of Paging Messages 182 The Paging Messages sent by the Paging Agent (i.e. Paging Function) 183 to dormant mode Hosts are: Paging Area Information advertisement, 184 Paging request. (Paging response and Paging Area update are sent in 185 the opposite direction (MN -> PF) and hence not covered by this 186 requirement.) Paging Area Information advertisement is already 187 covered in 4.21. Therefore, this requirement only covers Paging 188 Request message. 190 The protocol provides an authentication procedure for the Paging 191 Request message and thus meets the requirement. However, the 192 document further talks about the use of sequence numbers etc to 193 prevent replay attacks. This is overspecification, leading to a 194 rating of 3. 196 The protocol does not address the use of L2 security mechanisms. 197 Rating is 1. 199 3.2 draft-renker-paging-ipv6-01.txt 201 Unacceptable Requirements Match: 203 4.4, 4.6, 4.19, 4.20, 4.21 205 Under- or Overspecification: 207 Requirement 4.2: Scalability 209 Several signaling messages are needed for in and out of idle 210 (dormant) state transitions, and this may lead to unacceptable 211 overhead in the network and over expensive low bandwidth acees 212 links. In addition, when used with paging strategies there may be 213 large amount of information stored for each host. 215 DMHA Protocol Assessment Feburary 2002 217 Requirement 4.4: Efficient Signaling While Inactive 219 There is no mechanism to inform the Paging Agent that the host will 220 be inactive or unreachable. 222 Requirement 4.6: Multiple Dormant Modes 224 Although, there is a discussion of "implicit" and "explicit" dormant 225 modes, they both involve signaling exchanges between the MN and the 226 network, in one case using with Mobile IPv6 and the other with new 227 messages. So, in conclusion, there is no support for multiple 228 dormant modes. 230 Requirement 4.7: Independence of Mobility Protocol 232 The independence of mobility protocol is valid for "explicit" case 233 only. The design specifies two separate protocols, one for Mobile IP 234 and one without Mobile IP. 236 Requirement 4.9: Dormant Mode Termination 238 The proposal does not completely define the dormant mode 239 termination. It explains how to de-register from the dormant mode 240 with BU(0) or Idle-Mode-Req(0) but when does the host perform BU 241 with a nCoA to HA and CN? When and how does the PA forward all the 242 packets to host, is it after receiving BU(0)? There must be some 243 correlation in order for this to work well. The signaling messages 244 and the entity's behavior after the paging request is sent are 245 missing in the draft. 247 Requirement 4.10: Network Updates 249 In Section 9.2.1, it is briefly mentioned that when host is roaming 250 into a new PA, it must send a Idle-State-Request to the Paging Agent 251 to update the new PA-id. But more description is needed. How does 252 it work with "implicit" case using BU. 254 Requirement 4.11: Efficient Utilization of L2 256 In some systems, th mobile hosts may go dormant at L2 based on some 257 L2-timers. But according to this proposal, since there is no support 258 for dormancy based on timeouts where the host can go dormant without 259 having to send any signaling to the network, the MN needs to wake up 260 from L2 dormancy to begin the L3 dormancy. This leads to inefficient 261 usage of L2 dormancy and paging mechanisms, worsening the power 262 saving with respect to L2 only dormancy. 264 Requirement 4.12: Orthogonality of PA and Subnets 266 In cellular technology, however, the TMSI (not the IMSI) is used to 267 page a particular host and the TMSI is assigned by the Access 268 Network upon registration (or updated during the Routing Area 269 Update). The host will not know the TMSI in advance. So in the 270 DMHA Protocol Assessment Feburary 2002 272 proposed draft, a host can not move from non-cellular to cellular 273 system except if the non cellular and the cellular system 274 (WCDMA/cdma2000) are in different paging areas where upon moving to 275 a new paging area, the host has to send a new BU and the sub-option 276 contain the TMSI. 278 Requirement 4.14: Robustness against Failures 280 The proposal recommends agent replication but does not specify the 281 details. 283 Requirement 4.15: Reliability of Packet Delivery 285 The proposal does not describe how the buffered packets at paging 286 agent are sent to host. 288 Requirement 4.20: Authentication of PA registration 290 The authentication of the registration messages is not described. 291 When relying on MIPv6 messages, the protocol relies on the 292 authentication data of the binding update, but is not mobility 293 protocol independent anymore. 295 Requirement 4.21: Authentication of PA Information 297 There is no mechanism described for authentication PA information 298 from the paging agent. It is left to the Access Routers in RtAdv, 299 but they are traditionally not authenticated. 301 Requirement 4.22: Authentication of PA Messages 303 There is no authentication mechanism described for paging requests. 304 There are probably several solutions possible. 306 Requirement 4.23: Paging Volume 308 After host receives paging request, it sends a high volume of L3 309 messages to de-register from idle state. This may introduce high 310 overhead in the network and hinder the ability of other MNs to 311 access to services, in particular over low bandwidth links. 313 Requirement 4.24: Parsimonious Security Messaging 315 There is no security definition in the Idle-State-Rqst/Rply 316 messages. Therefore, this is not applicable. 318 Requirement 4.25: Non-interference of Host's Security 320 Since the proposal does not describe how the messages are secured 321 (e.g. how the authentication data are sent - using AH, or a new 322 security sub-option), we can not know if this IP paging protocol 323 impose any limitations on a Host security policies. 325 Requirement 4.26: Non-interference of End-to-End Security 326 DMHA Protocol Assessment Feburary 2002 328 Same as above. 330 In addition, the following general concerns were expressed about the 331 protocol design: 333 1) How is the PA update performed when the host is in the idle 334 state and moving? 336 2) There is no description of how the mobility management is 337 completed after the paging request is received. There must be 338 some coordination on when the deregistration is sent to PA. 340 3) The proposal provides a solution independent of the mobile 341 protocols. A large number of L3 messages needs to be exchanged 342 in the following cases: 344 i) BU/BA to PA, all HA and CN when transitioning into the 345 idle state, 346 ii) BU/BA to PA, all HA and CN when transitioning out of the 347 idle state (entering active state), 348 iii) Registering with a new CoA for the idle state may be 349 undesirable, this forces BU to all CN. 351 4) Excessive signaling in the above cases could lead to too much 352 power consumption on host. 354 5) When Paging Area strategies are used, it is not clear how the 355 dynamic paging areas are defined for each user. This mode also 356 requires storage of a lot of state information leading to a 357 not-so scalable network. 359 6) Optimization with RH described in section 5.2.2 may not work 360 for security reasons. Binding update are authenticated thanks 361 to AH; but the authentication data carried in AH corresponds 362 to the one between the MN and the HA. How would the 363 authentication data between the MN and the PA be carried? 365 7) Unclear use of "implicit" and "explicit" terms. Both involve 366 messaging to indicate the idle state transition. 368 8) Use of paging-id to page the host in inter-system is not 369 clear. For exaample, when the host idle-registers in WLAN 370 coverage and then moves to a cellular system, how does the 371 paging agent know the L2 id of the cellular system? 373 3.3 draft-sarikaya-seamoby-mipv6hp-00.txt 375 Unacceptable Requirements Match: 377 4.4, 4.7, 4.22 379 Under- or Overspecification: 381 DMHA Protocol Assessment Feburary 2002 383 Requirement 4.2: Scalability 385 This proposal is heavily dependent on HMIPv6 for scalability. The 386 MAP is a bottleneck that could lead to scalability problems. 388 Requirement 4.4: Efficient Signaling for Inactive Mode 390 No comment. 392 Requirement 4.6: Multiple Dormant Modes 394 The protocol can support multiple dormant modes. It will become more 395 complete if more descriptions about operation with multiple nodes 396 are added 398 Requirement 4.7: Independence of Mobility Protocol 400 Basically, the protocol assumes Hierarchical MIPv6 as the underlying 401 mobility protocol. Extra efforts could be made to eliminate the 402 dependence of HMIPv6 and this protocol. 404 Requirement 4.8: Support for Existing Mobility Protocols 405 Support MIPv6. However, does not claim any support on MIPv4. 407 Requirement 4.10: Network Updates 409 Key aspects are missing for network update. 411 Requirement 4.14: Robustness against Failures 413 The proposal depends on MAP replication, which is, as yet not well 414 specified. 416 Requirement 4.18: Flexibility of Paging Area Design 418 No special limitation on paging area design. Support both L2 and L3 419 paging area. However, mechanism to support adaptive paging area 420 assignment needs to be further specified. 422 Requirement 4.19: Availability of Security Support 424 The protocol conducts a security analysis, but it is not clear that 425 it is deep enough. 427 Requirement 4.21: Authentication of Paging Area Information 429 Does not solve 'Bogus Paging Area' problem 431 Requirement 4.22: Authentication of PA Messages 433 No authentication is specified in HMIPv6, upon which this protocol 434 depends. 436 DMHA Protocol Assessment Feburary 2002 438 Requirement 4.23: Paging Volume 440 Currently handle paging request in per host basis. Future revision 441 about handling several request together is in progress. 443 Requirement 4.25: Non-interference of Host's Security 445 In the evaluator's judgement, there seems to be no interference, but 446 further analysis is necessary in case some interaction with IPSEC 447 may turn up. 449 Requirement 4.26: Non-interference with End to End Security 451 Same as 4.25. 453 3.4 draft-guri-seamoby-lahap-00.txt 455 Unacceptable Requirements Match: 457 4.6, 4.8, 4.14, 4.17, 4.27 459 Under- or Overspecification: 461 Requirement 4.2: Scalability 463 Not clearly stated. 465 Requirement 4.6: Multiple Dormant Modes 467 Is not specified. 469 Requirement 4.8: Support for Existing Mobility Protocols 471 Interaction with MIPv4 and MIPv6 are not specified 473 Requirement 4.14: Robustness Against Failure of Network Elements 475 No comment. 477 Requirement 4.17: Flexibility of Administration 479 Not specified. 481 Requirement 4.18: Flexibility of Paging Area Design 483 No special limitation on paging area design. Support both L2 and L3 484 paging area. However, mechanism to support adaptive paging area 485 assignment needs to be further specified. 487 Requirement 4.21: Authentication of Paging Area Information 489 Does not solve 'Bogus Paging Area' problem. 491 Requirement 4.25: Non-interference of Host's Security 492 DMHA Protocol Assessment Feburary 2002 494 In the evaluator's judgement, there seems to be no interference, but 495 further analysis is necessary in case some interaction with IPSEC 496 may turn up. 498 Requirement 4.26: Non-interference with End to End Security 500 Same as 4.25. 502 Requirement 4.27: Detection of Bogus Correspondent Nodes 504 No specification about authentication of CN. 506 3.5 draft-ohba-seamoby-last-hop-dmha-02.txt 508 Unacceptable Requirements Match: 510 4.18 512 Under- or Overspecification: 513 _ 514 Requirement 4.1: Power Consumption 516 Registration to the TA through the DMA may not be optimal in terms 517 of power consumption, since a DMA Reg-ACK cannot be returned to the 518 host until the TA acknowledges the proxy registration request. 519 However, since the author also specified the direct communication of 520 the host with the TA, this requirement is overspecified to the 521 degree that can detract from efficiency. 522 _ 523 Requirement 4.2: Scalability 525 The protocol tends to describe its operation with one DMA per link, 526 one TA (primarily) and multiple PAs, as shown in Figure 3. When the 527 protocol suggests that more than one TA can be present and each one 528 manages a specific set of hosts, it fails to specify how this is 529 achieved. 531 Requirement 4.4: Efficient Signaling Inactive Mode 533 The protocol underspecifies the requirement because it suggests that 534 successive paging operations are to follow a paging interval that 535 increases exponentially, but does not specify an initial and final 536 value that the exponential figure is allowed to reach. Is it 537 persistent in the paging retry? Does it time-out at all? 538 _ 539 Requirement 4.6: Multiple Dormant Modes 541 The type of dormant modes that the protocol attempts to support is 542 based on a particular technology, while the protocol does not affect 543 the operation of the MAC layer at all. While one can claim that the 544 protocol combines L2 power saving features that contribute to power 545 conservation, this is not owed to or couple with the proposed 546 protocol. It is simply a manifestation of power savings through 547 DMHA Protocol Assessment Feburary 2002 549 special forms of MPDU scheduling. Any protocol can claim such 550 cooperation. Important aspect of dormancy like slotted dormant for 551 non-L2 layer has not been considered by the protocol. 553 Requirement 4.12: Orthogonality of PA and Subnets 555 The description of the protocol, although it mentions paging areas, 556 does not specify clearly how this is achieved since there is no 557 specific description of how the page message diffuses over an 558 topology of multiple subnets that are controlled by a single PA. 559 _ 560 _ 561 Requirement 4.14: Robustness against Failures 563 While the protocol specifies keep-alive signals between the peer 564 agents, it does not specify a scheme that allows recovery from 565 failure. 566 _ 567 Requirement 4.15: Reliability of Packet Delivery 569 The transport used in this protocol is UDP. The protocol does not 570 describe how the packet is forwarded to the host. In particular, it 571 does not describe what is the situation when the packet received at 572 the DMA is TCP. 573 _ 574 Requirement 4.17: Administrative Flexibility 576 The configuration of the paging areas is not quite automatic as 577 claimed. In particular the protocol does not specify how the page 578 area identifiers are assigned/allocated such that they can be 579 distributed to the individual paging agents. 580 _ 581 Requirement 4.18: Flexibility of PA Design 583 With respect to the claimed flexibility, the design is not clear in 584 Fig. 3. The TA propagates paging requests, why? 585 _ 586 Requirement 4.19: Availability of Security Support 588 The protocol does not support encryption services. It only supports 589 authentication. For ESP security, it relies on mechanisms such as 590 IPsec. 592 In addition, the following general concerns were expressed about the 593 protocol design: 595 1) The protocol utilizes the DMA like the TA in the functional 596 architecture draft, but does not specify a method for the DMA 597 to discover an appropriate TA. The assumption seems to be that 598 there will be a single TA per administrative domain or multiple 599 TAs with the TA to DMA mapping manually configured. 601 2) The protocol assumes the dormant host can detect a paging area 602 change, which implies that time-slotted paging must be used if 603 DMHA Protocol Assessment Feburary 2002 605 there is no L2 paging channel support. However, the protocol 606 does not explicitly mention how it would support time-slotted 607 paging. 609 3) The proxy interactions between the DMA and TA on behalf of the 610 dormant host incur extraneous signaling and may lead to 611 inefficient power consumption. 613 4) The assumption that the DMA is located on the last hop subnet, 614 which is the foundation of the design, means that the PA is 615 unnecessary, and links the paging area directly to the subnet. 617 5) The protocol specifies heartbeat messages between agent peers. 618 This method can identify a failed agent, but it cannot specify 619 how to recover from failure. 621 6) The protocol does not specify how a host chooses between DMAs 622 nor how a DMA chooses between TAs. 624 4.0 Decision Process 626 Given that the assessment team's recommendation about which draft to 627 accept was indeterminate, a decision team was formed by the two 628 Working Group co-chairs, with the Area Director providing advice. 629 The decision team decided to proceed toward selecting a draft for 630 recommendation to the Working Group as the basis of a harmonized 631 protocol, in order to avoid further delay in starting on the process 632 of designing the Seamoby paging protocol. This procedure is entirely 633 consistent with RFC 2418 [8], since the Working Group co-chairs' 634 decision is subject to working group concensus, so the Working Group 635 has the final say on whether the selected draft actually becomes the 636 working group draft. 638 The decision about which draft to select was difficult, because each 639 draft had particular aspects that were well thought out and 640 recommended themselves for inclusion in the final result, but none 641 of the drafts exhibited the maturity of implementation and design 642 that immediately suggested it as the only possible candidate for 643 selection. Some drafts had particular aspects that mitigated 644 strongly against selection. A good example of this difficulty is 645 Requirement 4.6, Multiple Dormant Modes. This requirement was 646 intended to foster support for hosts that have no explicit L2 paging 647 support, basically time-slotted paging. Draft-sarikaya has an 648 excellent discussion of time-slotted paging mode, but the basis of 649 that draft is a protocol (HMIPv6) that has been proposed in another 650 working group for a problem that is still in the requirements 651 phase, and the proposed paging protocol supports only Mobile IPv6. 652 The other proposals had varying degrees of support for time-slotted 653 paging, but none was sufficient to recommend itself on this 654 particular requirement. 656 DMHA Protocol Assessment Feburary 2002 658 The assessment team's work allowed the decision team to reduce the 659 number of drafts under consideration from five to two. The decision 660 team quickly decided to rule out draft-koodli because the draft is 661 lacking in specifics and is vague on many requirements, as mentioned 662 in the assessment team's report. Draft-sarikaya was ruled out 663 because it is based on a protocol that is currently under evaluation 664 in another working group, setting up an unacceptable dependency 665 between the Seamoby paging protocol design and the other working 666 group's process. Also, draft-sarikaya exclusively supports Mobile 667 IPv6, and a primary requirement of all Seamoby work is that the 668 protocols be independent of mobility protocol. While the assessment 669 of draft-guri was positive, draft-guri is explicitly concerned with 670 utilizing Layer 2 support for paging, and was therefore not 671 sufficiently broad enough as a base for IP paging. However, the 672 ideas expressed in draft-guri were felt to be valuable and necessary 673 for including in the final Seamoby paging protocol for those cases 674 where Layer 2 paging support is available. 676 The decision between the remaining two drafts, draft-renker and 677 draft-ohba, was especially difficult because they were judged to be 678 about of equal quality. The decision team decided to focus on three 679 primary requirements that were thought to be crucial to the 680 successful acceptance of IP paging: independence of mobility 681 protocol, support for existing mobility protocols, and independence 682 of paging area from subnet topology. 684 Of these, both draft-renker and draft-ohba provided adequate support 685 for the first two, independence of mobility protocol and support for 686 existing mobility protocols. Draft-renker was judged by the 687 assessment team to be overspecific in these areas, in the sense that 688 it contained two modes, explicit mode and implicit mode, depending 689 on whether Mobile IP was supported or not. However, considering the 690 relatively immature state of the paging protocol design, the 691 decision team felt that providing the working group with choices, 692 where the benefits and drawbacks of each choice could be clearly 693 weighed, was preferable to providing a fixed decision, so draft- 694 renker was judged to be better in this regard. 696 On the requirement for independence of paging area from subnet 697 topology, the support described in draft-ohba was very sketchy and 698 did not provide the decision team with a clear idea about how this 699 could be achieved, particularly with regard to the movement of a 700 mobile host while the host is in dormant mode. Draft-renker has a 701 much clearer description of how this could be achieved, and was 702 judged to be better in this regard. 704 Additional aspects of draft-renker that recommended it as the 705 selection were attention to details of interaction with existing IP 706 routing, and a survey of paging strategies. While probably not 707 essential to the final protocol design, the material on paging 708 strategies showed that the authors had given some thought to 709 separating policy from mechanism, and were familiar with the 710 somewhat extensive academic literature on paging, and IP paging in 711 particular. 713 DMHA Protocol Assessment Feburary 2002 715 While draft-renker was selected by the decision team as the basis 716 for continued Seamoby paging protocol work, the decision team feels 717 that it is important to incorporate the outstanding contributions of 718 the other authors into the final protocol design, in particular, the 719 time-slotted paging discussion in draft-sarikaya, the Layer 2 720 interface work in draft-guri, the paging state machine discussion in 721 draft-koodli, and the security protocol work in draft-ohba. 722 Additional aspects of the other drafts that address issues which 723 were weakly addressed or not addressed at all in draft-renker should 724 also be incorporated, as well as ideas from other working group 725 members that address requirement which none of the draft addressed 726 particularly well. 728 5.0 Acknowledgements 730 The Working Group Chairs would like to thank Prabhakar Chitrapu, of 731 InterDigital, Theo Pagtzis, of UCL, Hung-yu Wei, of Columbia 732 University, and Sirinivas Sreemanthula, of the Nokia Dallas Research 733 Center, for helping perform the protocol assessment. 735 6.0 References 737 [1] Kempf, J., Editor, "Dormant Mode Host Alerting ("IP Paging") 738 Problem Statement," RFC 3132, June, 2001. 739 [2] Kempf, J., et. al. "Requirements and Functional Architecture 740 for an IP Host Alerting Protocol," RFC 3154, August, 2001. 741 [3] Faccin, S., et. al., "Dormant Mode Handover Support in Mobile 742 Networks," draft-koodli-paging-00.txt, a work in progress. 743 [4] Liebsch, M., Renker, G., and Schmitz, R., "Paging Concept for 744 IP based Networks," draft-renker-paging-ipv6-01.txt, a work in 745 progress. 746 [5] Ohba, Y., Nakajima, N., and Zhang, T., "LH-DMHA - Last Hop DMHA 747 (Dormant Mode Host Alerting) Protocol," draft-ohba-seamoby- 748 last-hop-dmha-02.txt, a work in progress. 749 [6] Sarikaya, B., et. al., "Mobile IPv6 Hierarchical Paging," 750 draft-sarikaya-seamoby-mipv6hp-00.txt, a work in progress. 751 [7] Gurivireddy, S., et. al., "Layer-2 aided mobility independent 752 dormant host alerting protocol," draft-guri-seamoby-lahap- 753 00.txt, a work in progress. 754 [8] Bradner, S., "IETF Working Group Guidelines and Procedures," 755 RFC 2418, September, 1998. 757 7.0 Authors' Address 759 James Kempf 760 DoCoMo Communications Labs USA 761 181 Metro Drive, Suite 300 762 San Jose, CA, 95110 763 USA 764 Phone: +1 408 451 4711 765 Email: kempf@docomolabs-usa.com 766 DMHA Protocol Assessment Feburary 2002 768 Prabhakar Chitrapu 769 InterDigital Communications Corp. 770 781 Third Avenue 771 King of Prussia, PA, 19406 772 USA 773 Phone: +1 610 878 5730 774 Email: Prabhakar.Chitrapu@InterDigital.com 776 Theo Pagtzis 777 Dept. of Computer Science 778 University College London 779 Gower Street 780 WC1E 6BT, London 781 UK 782 Phone: +44 (0) 20 7679 3666 783 Email: t.pagtzis@cs.ucl.ac.uk 785 Sirinivas Sreemanthula 786 Nokia Research Center 787 6000 Connection Drive 788 Irving, TX, 75039 789 USA 790 Phone: +1 972 894 4356 791 Fax: +1 972 894 4589 792 Email: srinivas.sreemanthula@nokia.com 794 Hung-yu Wei 795 Columbia University 796 Room 710, Schapiro Res 797 530 West 120th Street 798 New York, NY, 10027 799 USA 800 Phone: +1 212 854 7477 801 Email: hywei@ctr.columbia.edu