[Seamoby] Paging Protocol Decision Description
"James Kempf" <kempf@docomolabs-usa.com> Wed, 16 January 2002 20:42 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20523 for <seamoby-archive@odin.ietf.org>; Wed, 16 Jan 2002 15:42:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17294; Wed, 16 Jan 2002 14:55:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17257 for <seamoby@optimus.ietf.org>; Wed, 16 Jan 2002 14:55:25 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19237 for <seamoby@ietf.org>; Wed, 16 Jan 2002 14:55:19 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GJsmS15753 for <seamoby@ietf.org>; Wed, 16 Jan 2002 11:54:48 -0800 (PST)
Message-ID: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: seamoby@ietf.org
Date: Wed, 16 Jan 2002 11:53:11 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Paging Protocol Decision Description
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit
As promised, here is a description of the decision process used to select the Seamoby paging protocol. After discussion and editing based on WG feedback, this will be incorporated into draft-ietf-seamoby-paging-protocol-assessment-00.txt. Comments please. jak ------------------------------------------------------------------------ ------------------------------------------ Assessment and Decision Process The assessment team spent three weeks reading through the protocol proposals. Each team member was assigned a proposal for assessment, with the exception of draft-sarikaya and draft-guri, which were both assigned to one team member because not enough people volunteered. 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. 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 as the basis of a harmonized protocol, in order to avoid further delay in starting on the process of desiging the Seamoby paging protocol. 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. The other proposals had varying degrees of support for time-slotted paging, but none was sufficient to recommend itself on this particular requirement. 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. 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. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
- [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- RE: [Seamoby] Paging Protocol Decision Description Pat R. Calhoun
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- RE: [Seamoby] Paging Protocol Decision Description Pat R. Calhoun
- Re: [Seamoby] Paging Protocol Decision Description Cedric Westphal
- RE: [Seamoby] Paging Protocol Decision Description Pat R. Calhoun
- RE: [Seamoby] Paging Protocol Decision Description Pat R. Calhoun
- RE: [Seamoby] Paging Protocol Decision Description Hesham Soliman (ERA)
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description Cedric Westphal
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- Re: [Seamoby] Paging Protocol Decision Description Cedric Westphal
- Re: [Seamoby] Paging Protocol Decision Description Vijay Devarapalli
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- RE: [Seamoby] Paging Protocol Decision Description Nakhjiri Madjid-MNAKHJI1
- Re: [Seamoby] Paging Protocol Decision Description Rajeev Koodli
- RE: [Seamoby] Paging Protocol Decision Description Nakhjiri Madjid-MNAKHJI1
- Re: [Seamoby] Paging Protocol Decision Description Muhammad Jaseemuddin
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- Re: [Seamoby] Paging Protocol Decision Description James Kempf
- Re: [Seamoby] Paging Protocol Decision Description Vijay Devarapalli
- RE: [Seamoby] Paging Protocol Decision Description Chitrapu, Prabhakar R
- RE: [Seamoby] Paging Protocol Decision Description Nakhjiri Madjid-MNAKHJI1
- RE: [Seamoby] Paging Protocol Decision Description Pat R. Calhoun
- Re: [Seamoby] Paging Protocol Decision Description Rajeev Koodli
- Re: [Seamoby] Paging Protocol Decision Description Behcet Sarikaya
- RE: [Seamoby] Paging Protocol Decision Description Hesham Soliman (ERA)
- RE: [Seamoby] Paging Protocol Decision Description Nakhjiri Madjid-MNAKHJI1