Subject: Re: [seamoby] L2/L3 Paging

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 26 Mar 2001 19:28:23 +0100

At the meeting in Minnesota, there was a question that basically asked
"Should seamoby paging *require* L2 Paging be present".  Consensus was "no"

L2 paging is a L2 requirement (not driven by
upper layers, rather by other considerations of 
a different nature).

...  I think a better question to ask would be "Should seamoby *assume* that
layer 2 has knowledge of the location of the MN".  I think (perhaps I'm
wrong), that the answer to the latter question would be yes.

The L2 performs L3 delivery functions. This entails knowledge of the link(s)
onto which to forward the L3 PDU in Non broadcast media, or the L2 (MAC)
address in 
broadcast media. Some degree of location knowledge does come with it.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 26 Mar 2001 20:16:45 +0100

Martin, David P writes:
 > "Should seamoby paging *require* L2 Paging be present".  Consensus was no

   I don't see why we should assume that. If a mobile
   is dormant, we probably know its last attachment 
   point, but that doesn't mean that the L2 must 
   track its movement accurately. In fact, I'd say
   that that should be an explicit *non-goal* as it
   would allow the MN to sleep for longer periods.

The mobile can "L2-sleep" until it gets alerted of the fact L2 would loose
track of it. Then, it sort of "L2-wakes up" (on the L2 C-Plane), 
updates the L2 about its new location
and then it can "L2-sleep" again. 

 > I'm not sure how you can have a link without knowing where you are
sending
 > stuff.  I am a little concerned that the paging team may be attempting to
 > solve a very difficult problem that will never exist.

   This doesn't seem to hard: suppose you have a
   beacon which all dormant nodes listen too. 

No L2 dormant node can listen to L3 beacons.
Unless dormant means something else here (or the beacons are not L3).

   To find a node, the last attachment point performs
   a search in the local paging area.

What if the mobile is not in that L3 paging area anymore?
Or, how would a dormant mobile know it has crossed
a L3 Paging area? L3
paging needs its applicability to be specified
with this respect (and put requirements on L2/L3 coordination,
I guess).

alessio

---

From: James Kempf <[email-masked]>
Date: Mon, 26 Mar 2001 11:47:32 -0800 (PST)

I think the wording should capture a requirement to MUST use L2 paging
if available, but that it SHOULD NOT be required to be available.

		jak

>From: Michael Thomas <[email-masked]>
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Date: Mon, 26 Mar 2001 11:41:19 -0800 (PST)
>To: James Kempf <[email-masked]>
>Cc: [email-masked], [email-masked], [email-masked]
>Subject: Re: [seamoby] L2/L3 Paging
>X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk 
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd 
bUcI'1!
>
>James Kempf writes:
> > I'd like to suggest that the requirement read something like:
> > 
> > 	The IP paging protocol shall utilize L2 paging support if available,
> > 	but shall not require L2 paging. 
>
>   I'm hair splitting here, but we MUST use it? It 
>   seems to me that what we really want is that 
>   IP paging not inhibit the use of L2 paging 
>   mechanisms as appropriate for that L2. Otherwise,
>   we might be inhibiting the ability to develop
>   native IP paging mechanisms in the future, which
>   I'll guess is not your intent.
>
>	      Mike

---

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 26 Mar 2001 23:43:27 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, March 26, 2001 7:27 PM
> To: Martin, David P
> Cc: 'Michael Thomas'; [email-masked]
> Subject: RE: [seamoby] L2/L3 Paging
> 
> 
> 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.

What if the MN registers its interfaces with the COA router.
If an AR/AP is unable to route on its interface, it can forward to the COA
router.
The COA router can check its MN registery for other intefaces and route
accordingly.

- Kulwinder.

> 
>    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: Tue, 27 Mar 2001 12:27:31 -0500

<snip> 
>    home address in the HA case, via CoA for the

Agree that location information exists at the network layer, but how do you
use this information to get to the MN? Say a packet comes in to the edge
access router destined for a dormant MN (via the COA) that was last
associated with that router.  A mechanism must exist to deliver the packet
to the MN.  One avenue is to assume a lower layer system exists to resolve
this, and a trigger is used to kick off this system, this is the easy case.
For the case where the lower layer system does not have a mechanism for
finding the MN, a mechanism must be built.  So how could one do this?

One option would be to put the packet on the last known interface, but the
mobile is dormant, how does the mobile know to listen to this interface?  

Another option is to broadcast to the mobiles on a specific broadcast
channel (to save power, but this requires lower layer modifications to the
mobile) a list of MN addresses that need to wake up because they have
traffic, for this case you need mobiles that need to understand how to
listen to broadcast traffic ... in other words you have a system that
supports paging such that a packet arriving at a router can trigger a page
(see first option).  However, since broadcasting a list of all mobiles does
not scale, a mechansim must be built to partition the list (via time,
geography, or some other method) to allow the broadcast channel to scale.
So you either have to scale the edge routers to accommodate the broadcast
channel, or you have to develop a location mechanism "underneath" the edge
router.  In my mind this system is nothing more than designing a paging
system that lives below the network layer, and if I have to design this type
of system, doesn't this mean we can assume that a mechanism exists at a
layer below IP for delivering packets (and a seperate effort can actually
design the mechanism, sort of like the PPP work in IETF).  

Additionally, thought has to be given for the case where the mobile is
unreachable at the current interface, either the packets have to be dropped,
or mechanisms have to be developed to try and find where the mobile might
be.

<<Snipped rant>

>    a single provider's network.

I think your question is I have a cellular base station and I want to reach
a MN with dual mode cellular/802.11 access, and I assume by the question
that there is no mechanism to indicate when the MN has switched access
networks.  The edge router would have to send a packet to the "right"
interface, so in the context of paging, I can page the mobile on both
interfaces.  But I am assuming that a mechanism exists below the network to
deliver these pages.  802.11 and cellular both have (different) location
determination mechanisms below (unseen by) IP, it would be useful for an IP
paging protocol to leverage off of this information.

>    to find it.

I agree.

>    That means that you're going to

I agree here as well, but sending network pages to routers is orthogonal to
whether a L2 mechanism exists to deliver those packets to the mobile.

It is not clear to me how to develop a paging design at the network layer,
without support from an underlying protocol ... and I see these as two
distinct issues.

---

From: James Kempf <[email-masked]>
Date: Tue, 27 Mar 2001 14:04:07 -0800 (PST)

Dave,

>
>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:
>* 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
>_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.

The issue isn't this simple. The location information available at L2
may not be sufficient to effect location. Or there may be more L2
involved. In either case, location information available at L3
may be important in making the connection with a dormant mode mobile
node that will allow routing to be updated and the packet to be delivered.

I also don't think it is as much work as you may think. There are
already several prototypes (Cellular IP, Hawaii, the Columbia MIPv4
paging protocol, etc.) that have examined this issue. I think it is
primarily a matter of getting the architecture and requirements sorted
out, then getting the people with some design and implementation expertise
in the same room to agree on a protocol.

>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>
>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

I guess I don't follow this. L2 mechanisms are used for intrasubnet movement
but that doesn't preclude the need for something at L3 to track mobility,
mobile IP being the current solution. L2 mechanisms only work for a
particular L2. And, as the problem statement states (clearly I hope),
even for the same L2 there are difficulties depending on the mapping
between paging areas and subnets.

>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>
>

Actually, I think it is just good design to try to factor the problem into
the part that is independent of L2 and the part that is not. IPv6
does this quite nicely. There is a requirement for a minimum frame
size from L2,  if the L2 doesn't supply it, then a shim layer needs to
be written to do segmentation and reassembly. Granted, this requirement
is considerably simpler than paging, but I suspect the people who have
had experience doing prototypes will have some idea about where to 
cut the design.

		jak

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 28 Mar 2001 09:48:02 -0600

Actually these are some good points and questions. Here are some of my
thoughts on this concept. Currently there is no method of representing the
concept of "paging areas/zones" in the IETF world. It seems evident to me
that L2 has to be involved in paging as the benefits in terms of reduced
power consumption is dependent on the L1/L2 as well. So if one did somehow
change IP routing to include the concept of a "paging zone" that could cross
subnets, sites, autonomous systems (roaming agreements) etc.. one could
conceivably create some sort of access independent L3 paging signaling that
each L2 could pay attention to i.e. wake up the mobile nodes via L2
mechanisms. 

Now in terms of "what that signaling should be" I see two possibilities.
Re-invent the wheel i.e. do something similar to what is done for cellular
today or just deliver multiple copies of IP packets to the subnets in this
new concept of a paging area/zone. Note: some cellular technologies call
this a routing area but please do not confuse this with the IETF concept of
routing area. The next paragraph explains how one might go about doing it
with multiple copies.

A set of COAs could be used by say a mobile's home subnet to perhaps tunnel
multiple copies of packets received to each subnet address indicated via
each COA the mobile had recently visited and binded with.

These recently visited subnets themselves may have configured routing
information indicating adjacent subnets for the "paging area/zone". This
would allow each subnet indicated via the COA to furthur copy and send the
packet to these adjacent subnets. Once received on each copied subnet the L2
mechanisms of paging that are access specific can attempt to "wake up" the
mobile and diliver the packet. In some cases the packet can be delivered at
the same time as the wakeup. We should probably change this home subnet
forwarding function to enable the smarts to know when the send an ICMP
unreachable message. I do not see a need to have the visited subnets to send
unreachables back to the home subnet's if they cannot deliver the packet or
successfully page the mobile. This approach simply relies on the delivery of
the packets as the L3 paging mechanism.

I'm sure there are other approaches as well with more detail of each level
or macro/micro point of view. The micros will tend to employ an anchor. 

The reinvention method would tend to employ SIP or something similar for
this function. I can definitely understand the pull in this direction as
well - i.e. that's how cellular works for circuit-based calls today. To
achieve the general solution, SIP will have to be built into every router
and SIP must begin paying attention to PIBs, FIBs, AS boundaries (roaming
agreements) etc.. IMHO. A counter argument to this might be that this stuff
will likely have to change with the other approach as well - some things to
think about as we forge forward. I believe both mechanisms would work. 

I think the "babes-in-the-woods" as you say should definitely understand
these issues and help make the decisions as we move forward. They have some
good experience and insight into "changing the IP world". 

I'm hoping these "babes" as you say are not bellheads in disguise posing as
IP fanatics (this is not directed to anyone personally. The motivation of
this "shock treatment" is to make people set back and really take a hard
look at how it should work for the long term).

Anyway these are my thoughts on the L2/L3 ying and yang and the upcoming
battle of approaches or rather assumptions. Hope this helps illuminate, at
least, some of the differing points of view.

Glenn

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 7:36 AM
To: 'Martin, David P'; 'Michael Thomas'
Cc: seamoby
Subject: RE: [seamoby] L2/L3 Paging

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.

> 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]
> 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 ...
> 
> 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:
> >  > >    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: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 28 Mar 2001 17:36:43 +0100

802.11 radio. 

IP reachability on 2 interfaces: Same IP address? Or not?

If "Yes" then I assume you are using a mobile IP arrangement which
allows for simultaneous transmission to the 2 distinct APs (I'm not
considering/implying the case the 2 APs advertise the same (host)routes-
in which case similar things would hold). 

If "Not", the answer to the following is obvious.

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. 

I assume, in the ensuing discussion, the answer 
was "yes".
So, what happens when traffic comes in? Bot interfaces will deliver
so WCDMA will page, and 802.11 will do the equivalent thing.
If on one of the two or none there is no coverage, then packets
will be lost (and ICMP dest unreachable maybe sent back )
on the AP that has lost the MN connectivity.

We also don't need L3 paging.

What causes the WCDMA to decide it needs
to page the node and wake it up?

Incoming packets.

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 29 Mar 2001 01:55:48 -0500

> Sent: Wednesday, March 28, 2001 8:36 AM

I would think End-User Preferences would guide the network decision making
as stated in a Paging Policy.  Similiar to a Calling Forwarding Policy for a
landline phone. 

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 30 Mar 2001 20:38:02 -0500

> Sent: Friday, March 30, 2001 4:58 PM
> To: Martin, David P
> Cc: 'Michael Thomas'; 'David R. Oran'; [email-masked]
>  > 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.  
> 
>    As far as I know, this is all we're trying to
>    address.
>  
>  > 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.
> 

Mobile left town, battery died, ... all fall under the catagory: link
failure.

It can be resolved with an implementation specific Link Timeout Timer, where
if no packets are transferred for Link Timeout seconds link failure is
assumed.  Link reliability is an L2 issue.

- Kulwinder.

>    I believe that any paging protocol needs to face
>    this possibility though.
> 
>  > 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.
> 
>    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? :-)
> 
>  > > 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.
> 
>    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
>