Subject: RE: [seamoby] To page, or not to page

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Fri, 30 Mar 2001 19:34:21 +0100

>But there is a disconnect here: if the mobile goes dormant, no way you can
>do
>a L3 thing, whatever you could do is a L2/L3 coordination. as such, this
>becomes
>a technology dependent work. 
>

There are a number of ways to handle this. The mobile node could
explicitly signal at L3 when it goes dormant. A timer in the network
could go off if the mobile doesn't periodically report, and send
an L3 message to the tracking agent. Neither of these involve
dependence on explicit L2, though they may involve an abstract L2
trigger (for example, a trigger on the mobile node that it is about
to go dormant).

Right, I think mobile IP can do this... Before you go to sleep, send an
update.
	
>The requirement should be: the IP location update protocol
>shall be efficient with respect to mobile Power use.
>

We can get into splitting hairs here about what we call it, but
I think there is broad concensus in the working group to call it paging.

I'd suggest there is quite a difference between location update
and paging. It is not splitting Hairs.

>That is acceptable, but I dont see the need for a paging protocol. Just
send
>data.
>the APs where the MN is not attached, will drop packet, and you are set.
>

So you want to handle a defect in the routing protocol by falling
back on TCP retransmission, or, if TCP isn't used, whatever application
specific UDP retransmit protocol happens to be there?

No.

 IHMO, it is
poor design practice to depend on error mechanisms to handle the
a defect in the routing design.

I think that the correct link selection will come with the location update
the node will send when it detects it is in the conditions to do so.
the routing protocol would stabilize quite quickly in the IP
based access net, upon reception of the location update...

>The requirement on the paging protocol I have are Non existent,
consistently
>with the fact that I do not recognize the need for such protocol.
>That req document is not really a requirement document, it is a document
>saying "we require paging, and here is why". However it steers clear from
>defining
>what paging is... Not much agreeable. It is a metarequirement documet on
>some
>Yet to be defined or conceived thing. 
>

May I quote from Section 2.0 of 
draft-ietf-seamoby-paging-problem-statement-02.txt:

      Paging - As a consequence of a mobile-bound packet destined for a
      mobile currently in dormant mode, signaling by the network through
      radio access points directed to locating the mobile and
      establishing a last hop connection. This messaging is in addition
      to simply delivering the packet to the mobile, i.e. last hop
      routing of packets is NOT considered to be paging.
      
This is our definition of paging. I suggest, if you want to throw bombs,
you take it up with the IESG.  

This cannot be used for both L2 and L3. I think you need two distinct
definitions.

alessio

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 15:20:14 -0800 (PST)

Alessio,

First, could I kindly request that you prefix your comments to Jim. It is very
difficult for me to figure out what you are saying since it is all mixed up.

Second, it appears to me as if the problem is not with paging, but the
requirements. Again, you stated that you haven't read the problem statement,
but seem to have lots of ideas on what is needed, and what is not. Could I
convince you to read the problem statement, and then provide comments on the
spec?

Lastly, could I also encourage you to work on the requirements, following e
normal IETF process, to make sure that your needs are met?

Thanks,

PatC