Subject: RE: [seamoby] L2/L3 Paging

From: "Martin, David P" <[email-masked]>
Date: Wed, 28 Mar 2001 18:27:58 -0500

I am trying to understand the scope of the first recommended charter item in
the problem statement (I should have made that clear earlier in this
thread).  It states ...

      1) Since the design group has identified several network
      deployment scenerios where existing Mobile IP technology cannot
      find a mobile in dormant mode, protocol work is necessary to
      define a way for the network to find a mobile that is currently in
      dormant mode.

I'm trying to understand which non-reachability problems we will attempt to
address.  If the only problem we are trying to solve is reaching a dormant
mode, I am in full agreement with the problem statement.  

However, if we want a protocol that we deal with *all* non-reachability
issues (link failures, mobile left town, battery died, etc) then I think
that is two distinct problems.  One problem is which interface(s) to deliver
packets to, the other problem is what to do if the mobile doesn't respond in
a timely fashion.

The problem of which interface to deliver packets is the problem that has to
be solved regardless, and I a fully agree that should be part of the
charter.

The second problem of what to do if the mobile is not reachable is a
separate issue.  I feel that it probably *is* a worthwhile problem to solve.
However, the reachability issue is usually dealt with at a lower layers and
(if the lower layer solutions can be any guide) the appropriate solution
will be dependent upon a host of factors.  Which may lead to this particular
problem requiring the vast majority of the effort of the group.

If we want to include the general case of non-reachability in the WG scope,
my recommendation would be to at least update the problem statement to
reflect the two different problems.

A later step would be to see if it makes sense to develop one protocol
solving both issues, or two protocols each solving the respective problem.

> 
> I hate to keep harping on this, but this sure
> seems to me to be familar ground. The problems you
> point out also would come up with a demand dialer
> type of interface, like say an ISDN line which
> isn't up all of the time. While the solutions may
> not be entirely algorithmic, the parameters are
> certainly well understood by now.
> 
The solutions for this problem to date have been optimized for particular
applications that were likely to be running (i.e. phone calls).  Different
applications would have different optimizations.  If its any consolation, I
have been convinced that it would be possible to solve this problem on an
application by application basis ... but I still think a good solution will
take a lot of work.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Mar 2001 13:57:50 -0800 (PST)

> mode, I am in full agreement with the problem statement.  

   As far as I know, this is all we're trying to
   address.
 
 > packets to, the other problem is what to do if the mobile doesn't respond in

   I believe that any paging protocol needs to face
   this possibility though.

 > separate issue.  I feel that it probably *is* a worthwhile problem to solve.

   I dunno. Nothing extrordinary happens when my
   DSL line goes down right now. Do we really need
   to figure out a way backhaul my annoyance
   dotted with four letter words when that
   happens? :-)

 > application by application basis ... but I still think a good solution will

   Hmm. Application by application usually sets
   of the boil-the-ocean klaxon in my head. Would
   it be sufficient to set up an access control
   list on the access router to block all but, 
   say, SIP and whatever other protocols you
   wanted to listen for while you're dormant?

	     Mike