Subject: RE: [seamoby] L2/L3 Paging

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 16:27:27 -0800 (PST)

Martin, David P writes:
 > * Do we assume that location information is known to layer below IP?
 > _Yes_ implies that there could be a trigger or some other mechanism to give
 > hints or direction on how to contact the MN, and would greatly simplify the
 > work for an initial protocol.
 > 
 > _No_ implies that location state would have to be developed (at the network
 > layer since that is where the IETF lives) and would mean that some location
 > state engine would have to be developed to allow paging or packet delivery.
 > This will require a lot of work.

   I don't see what needs to be developed per se:
   we already have two candidate places where
   location information is already stored: the HA
   and the edge access router in visited network.
   Both know how the MN was last reachable (via
   home address in the HA case, via CoA for the
   AR).

 > <rant>
 > Now, all mobility based technologies that I know maintain the state
 > information below IP.  So for all existing technologies, we would be
 > designing a redundant location mechanism into the system.  This leads to
 > interesting issues ...
 > If you have to choose between optimizing the protocol for paging systems vs
 > non-paging systems, which do you choose?  Which location mechanism do you
 > use?  Do you have a choice?  You will probably be forced to at least use the
 > lower layer location mechanism.  If I have to use it, what added benefit is
 > an upper layer location mechanism?  

   How would you page a MN with an 802.11
   radio, say, if you don't have an 802.11
   interface? This seems like a pretty likely
   scenario with cellular base stations and
   dual mode cellular/802.11 widgets, even within
   a single provider's network.

   I look at this very simplistically: if you
   can't find the mobile on a local L2 and you
   have reason to believe that it still may be
   attached (pageable) elsewhere, you need a
   L3 mechanism to trigger the other routers
   to find it. That means that you're going to
   have to send out a page to some collection of
   neighboring routers (neighboring in the paging
   area sense) to find it. Conceptually, this 
   doesn't seem all that hard to me. How best to
   utilize bandwidth and avoid dumb flood fill
   kinds of searches, of course, will be a
   challenge. With some L2 hints, however the
   latter could certainly be helped.

		Mike

---

From: "Martin, David P" <[email-masked]>
Date: Mon, 26 Mar 2001 18:56:50 -0500

Since I started this, I feel some obligation to help reach closure ... 

First, I think we've reached consensus that in order to deliver a packet or
page that some type of location information must be maintained somewhere in
order to effect delivery. 

Second, is that location information is needed to support a delivery
mechanism (paging or direct delivery).

I think where we diverge is on whether should seamoby take on this problem
...

So this leads to the following questions:

I would think that it would be more efficient to focus on known mobility
systems, and solve the more esoteric cases later ... but will yield to the
group's consensus.

<rant>
Now, all mobility based technologies that I know maintain the state
information below IP.  So for all existing technologies, we would be
designing a redundant location mechanism into the system.  This leads to
interesting issues ...
If you have to choose between optimizing the protocol for paging systems vs
non-paging systems, which do you choose?  Which location mechanism do you
use?  Do you have a choice?  You will probably be forced to at least use the
lower layer location mechanism.  If I have to use it, what added benefit is
an upper layer location mechanism?  
My sense is that the problems/requirements/solutions for systems that
inherently support paging at layers below IP are more defined, and that work
could proceed more quickly in that space.  General IP paging would be a
complex solution to a problem of unknown proportions, and it will probably
take more time to scope.
</rant>

> 
> 
> Martin, David P writes:
>  > >    This doesn't seem to hard: suppose you have a
>  > >    beacon which all dormant nodes listen too. To
>  > >    find a node, the last attachment point performs
>  > >    a search in the local paging area. When the mobile
>  > >    wakes up, it establishes a link to its current AP,
>  > >    and a tunnel to the old AP to scoop up the
>  > >    packet(s).
>  > 
>  > I agree that a paging system can be designed that can work 
> with a technology
>  > that does not continually track a MN location.
>  > 
>  > However, a (working) paging system *cannot* be designed without a
>  > registration mechanism.
> 
>    Sure.
> 
>  > The purpose of a registration mechanism is to
>  > provide rough location state information on where a MN is 
> located in a
>  > network topology.  This location state can be of several 
> forms, specific
>  > access point, specific paging zone, specific network 
> (scalability issues),
>  > last known access point, last known access zone, etc.  But 
> the network has
>  > to have some type of location information to even begin to 
> guess on how to
>  > start paging.
> 
>    Correct.
> 
>  > In your example above, the mobile in effect registers upon
>  > wake up, giving the network location state to work with.  
> Of course a
>  > mechanism must exist (at one or more layers) to deal with 
> stale location
>  > information.
> 
>    Yup.
>  
>  > So, I'm trying to say that there must be some location 
> state maintained
>  > somewhere at layer 2, otherwise the entire network would 
> behave as one big
>  > LAN segment.
> 
>    I don't see this as having much to do with L2. If
>    I can route an IP packet to the last known point
>    of attachment, it could put out the dragnet by
>    sending out IP packets which eventually (or not)
>    find the mobile node. L2 location information may
>    or may not be involved. At a base level, I don't
>    think we should count on them being there though.
> 
> 	    Mike
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 28 Mar 2001 08:35:57 -0500

If the L2 knows where the node is, then all paging does is force a
wakeup, right? Seems like you could invoke whatever mechanism is needed
for the wakeup (which somehow *has* to have components below L3 it seems
to me) when IP packets arrive for the host.

If the L2 does not know where the node is, then it has to find it. Is
this the mechanism you say always has L2 state? It would be helpful if
we L3 babes-in-the-woods could get a better understanding of just what
this state is, how quickly it degrades, and how a L3 could conveivably
make use of it (e.g. to keep routing tables correct), rather than
arguing about whether the function belongs exclusively in L2 or L3.

Here's a puzzler though. Maybe it will help illuminate why us L3 crazies
keep raining on the paging-is-done-just-fine-at-L2 parade. Let's say I
have a host with two radios, an 802.11 and a WCDMA. At some time it is
reachable through both of them but is receiving IP traffic through the
802.11 radio. Then it goes to sleep. New traffic arrives for it. Which
radio gets paged? Both? What if after going to sleep it wanders into a
multipath null for the 802.11. What causes the WCDMA to decide it needs
to page the node and wake it up?

There's *got* to be an interaction with L3 here somewhere, at least for
routing.

Donning my asbestos suit...

Dave.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin, David P
> Sent: Monday, March 26, 2001 6:57 PM
> To: 'Michael Thomas'; Martin, David P
> Cc: [email-masked]
> Subject: RE: [seamoby] L2/L3 Paging
> 
> 
> First, I think we've reached consensus that in order to 
> deliver a packet or page that some type of location 
> information must be maintained somewhere in order to effect delivery. 
> 
> Second, is that location information is needed to support a 
> delivery mechanism (paging or direct delivery).
> 
> I think where we diverge is on whether should seamoby take on 
> this problem ...
> 
> * Do we assume that location information is known to layer 
> below IP? _Yes_ implies that there could be a trigger or some 
> other mechanism to give hints or direction on how to contact 
> the MN, and would greatly simplify the work for an initial protocol.
> 
> _No_ implies that location state would have to be developed 
> (at the network layer since that is where the IETF lives) and 
> would mean that some location state engine would have to be 
> developed to allow paging or packet delivery. This will 
> require a lot of work.
> 
> I would think that it would be more efficient to focus on 
> known mobility systems, and solve the more esoteric cases 
> later ... but will yield to the group's consensus.
> 
> 
> 
> <rant>
> Now, all mobility based technologies that I know maintain the 
> state information below IP.  So for all existing 
> technologies, we would be designing a redundant location 
> mechanism into the system.  This leads to interesting issues 
> ... If you have to choose between optimizing the protocol for 
> paging systems vs non-paging systems, which do you choose?  
> Which location mechanism do you use?  Do you have a choice?  
> You will probably be forced to at least use the lower layer 
> location mechanism.  If I have to use it, what added benefit 
> is an upper layer location mechanism?  
> My sense is that the problems/requirements/solutions for 
> systems that inherently support paging at layers below IP are 
> more defined, and that work could proceed more quickly in 
> that space.  General IP paging would be a complex solution to 
> a problem of unknown proportions, and it will probably take 
> more time to scope. </rant>
> 
> > 
> > 
> > Martin, David P writes:
> >  > In your example above, the mobile in effect registers 
> upon  > wake 
> > up, giving the network location state to work with.
> > Of course a

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Mar 2001 10:31:44 -0800

> to page the node and wake it up?

I am not sure I follow the argument here..perhaps you could illuminate a
little more here..

First a Mobile Node does not go to sleep. It is the interface that goes to
sleep. The timing between which 802.11 and WCDMA interfaces
will go to sleep if power control is effected will/must be different for
the two interfaces.

If traffic is being sent to the 802.11 the MAC protocol has got a period
over which it checks the NAV for pending traffic delivery

With respect to WCDMA the spec mentions that although it is possible to
trigger gated DPCCH transmission from a higher layer, the downlink
or uplink can operate at gated mode with either embedding DPDCH or with the
DPDCH always off and the DPCCH toggling between on/off states according to
the gating rate, so that the UE can check (by TPC commands) which timeslot
it need to turn on (DPDCH) and receive data frames on the DPDCH

I thus do not see why it would require an extra IP packet to be sent to
trigger L2 in both technologies so that the UE would get paged...

Traffic would always come on a particular interface so that interface need
wake up by its MAC upon pending traffic..

Don't you agree?

Theo

UCL / Mobile Systems