Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft

From: [email-masked]
Date: Fri, 22 Feb 2002 17:06:51 -0600

Actually, Behcet has a point with respect to the the analysis of the requirements (4.7 and 4.8).  Also, from the solutions presented so far, we did not see an integrated protocol solution that satisfies both the simple IP (non-mobility)  and mobility-aware. Renker, the current base draft,  provides two modes but not as a single solution.  
 
An important question I would ask is if there is any interest in practical deployment of DMHA as an independent protocol (without mobility)?  

To me, DMHA is more applicable to mobile handheld terminals with limited battery life.  Dormancy will avoid frequent mobility (update) procedures to save the battery and also makes efficient radio spectrum usage. From all the existing proposals, it is very clear that when DMHA is used with a mobility protocol, DMHA extensions must be incorporated within mobility protocol. The point is, it would make sense to emphasize on the 4.8 (mobility aware) requirement.

From this point of view, I would nominate proposals that have base mobility support without any particular references to LMM. The approach would be to merge all good aspects of different mobility based proposals(MIP & MIPv6) from renker, sarikaya and koodli drafts (without the concept of a base draft).
 
Thanks,
Srini

-----Original Message-----
From: ext Behcet Sarikaya [mailto:[email-masked]]
Sent: 22 February, 2002 2:18 PM
To: [email-masked]
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft

Hello all,
  I think that this is the email I had posted before that is mentioned 
in the 3rd paragraph of James' email below, I just am reposting it 
(please note that after the discussions it became clearer that  
draft-ohba is mainly based on IPv4 was not correct):

  Contrary to the ordinary belief, I think (of course I may be wrong)
that there is no single IP Paging protocol, requirements 4.7 and 4.8 are
pointing to 4 different IP Paging protocols.

  If we may change Pat's question to which drafts to take as the base
then there are natural solutions:

- I hereby suggest draft-ohba as the base draft for mip independent IPv4
based solution.THis draft is mainly based on IPv4 and it does not
attempt to integrate with MIPv4. There are some problems in its
architecture but these can be addressed in the next version.

- I hereby suggest draft-guri as the base for mip independent IPv6 based
solution. This draft is based on IPv6 and no integration with MIPv6 is
attempted. However its architecture must be modified and streamlined
with modified draft-ohba.

For MIPv4 and MIPv6 based solutions, I have trouble in suggesting the
base drafts but the natural solution seems to suggest that

- draft-renker may be modified towards a MIPv4 based solution (please
consider LMM not home agent  based architecture).

-draft-sarikaya and draft-koodli may take a MIPv6 based solution, there
are already some similarities and taking in close consideration of :LMM
requirements and any follow up developments.

James Kempf wrote:

>Folks,
>
>The deadline for WG Last Call on the paging assessment,
>draft-ietf-seamoby-paging-protocol-assessment-01.txt, is Monday 4 PM
>Pacific Time. Please send in any comments by then. At the conclusion of
>WG Last Call, we will be submitting the paging assessment draft to the
>IESG after making any changes that have WG concensus.
>
>Since my last email on this topic, we have had two additional
>suggestions from the WG.
>
>An editorial suggestion was made to divide Section 4 into separate
>subsections. I'll take a look at the document next week and see if this
>makes sense. At first glance, the proposed subsections do look as if
>they would improve readability.
>
>A suggestion was made by another WG member that, instead of selecting a
>single draft as a starting point, the WG should select all drafts and
>have each draft focus on a different part of the paging problem. So far,
>there has been no further comment from the WG on this proposal and so it
>does not look like there is concensus for it at this time. If you are
>interested in commenting on this proposal, please review the email
>describing it at the Seamoby archives and post your comment.
>
>
>                        jak
>
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: [email-masked]
Phone: (972) 477 2794 Fax: (972) 519 2460

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Feb 2002 09:32:14 -0600

Dear all,
  Several mails have been sent over the weekend I'll try to give my 
views in one mail.
Regarding Srinivas' email, my understanding is that he is against 
Alternative 1 (one size fits all solution) and he is for the Alternative 
2. In that he is suggesting that we concentrate on Requirement 4.8 
rather than 4.7. As for the drafts, he seems to be inclined to home 
agent based architectures which is demonstrated in draft-renker. This is 
an architectural choice, I think that his choice of alternatives is clear.
  Besides, I think that the chairs would like to choose draft/drafts as 
soon as possible and ask people to submit their 01 drafts by March 1st 
and move on. We do not have a lot of time for doing this.

Regarding Yoshi's email, I am quoting the abstract of RFC 3103:

> This document presents a protocol with which to implement Realm
>    Specific IP (RSIP).  The protocol defined herein allows negotiation
>    of resources between an RSIP host and gateway, so that the host can
>    lease some of the gateway's addressing parameters in order to
>    establish a global network presence.  This protocol is designed to
>    operate on the application layer and to use its own TCP or UDP port.
>    In particular, the protocol allows a gateway to allocate addressing
>    and control parameters to a host such that a flow policy can be
>    enforced at the gateway.

Yoshi, I think that the functionalities summarized above of RSIP have 
nothing to do with IP Paging. Can we define a port specific to  IP 
Paging , if yes then how does IP Paging capture all packets to the 
dormant hosts?

Added to this, please see Pars' email,

>This is serious, because "paging" which is intended for
>optimizing bandwidth use, may become a bandwidth threat.
>IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.
>

Let us get motivated for IP Paging.

Regards,

[email-masked] wrote:

-- 
Behcet