Subject: Paging Functional Architecture ( was: RE: [seamoby] L2/L3 Paging)

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 09:11:11 -0800 (PST)

Glenn,

Your note follows along some of what I have been thinking about, except
in a more functional architectural way, which is more appropriate
for the requirements phase, I think.

Basically, the idea is to have 4 functional entities:

	- A paging agent at the edge which handles paging interaction
	between the mobile node and the network and between the tracking
	agent and mobile node (if necessary). This would also be the
	place for any interaction between L2 paging and L3 paging.
	
	- A tracking agent which is keeping track of the mobile node
	as it moves in dormant mode across areas controlled by
	paging agents.
	
	- An access router which is the last hop router before the air
	link.
	
	- The mobile node.
	
Note that these are functional entities, there is *absolutely no* committment
in their definition to any physical representation. For example, it is
entirely concevable that the paging agent and access router may be fused
in a final physical implementation. 

I have yet to fully think out what the functions are that each of these
entities would have in a paging architecture, but I am planning on
coming up with a section for the requirements draft that contains this
material, unless somebody else beats me to it. :-)

I find this kind of functional architectural process to be extremely helpful in
teasing out the basic issues without committing early to an implementation.
Much of the discussion on this thread has assumed various implementations,
which I think is entirely premature.

		jak
		
>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.
>
>> -----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
>> 
>> 
>> 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 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:
>> >  > >    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: Erik Anderlind <[email-masked]>
Date: Wed, 28 Mar 2001 14:23:08 -0500

Glenn,
We need to be careful in defining functional entities such as the paging
and 
tracking agent - we do not want to preclude that these functions could
be 
provided in a distributed way (e.g. a subset of routers all implement
the function.)

I also disagree that it is a requirement that the paging agent has to be
at 
the "last hop" edge in all cases.

Another useful entity is correspondent node/application that initiates
the higher level 
need for paging. It will help identify requiremnts around how the other
different 
entities are located and addressed (if needed).
..Erik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Mar 2001 11:40:23 -0800 (PST)

> entities are located and addressed (if needed).

   Can you describe a use for such a user controlled
   paging mechanism? I can see a lot of security 
   problems inherent with allowing that; it would
   be nice to know what useful things that can't
   be done with a more controlled form of paging
   before we make it a requirement and hence have
   to tackle the harder security requirements.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Mar 2001 11:43:41 -0800 (PST)

> the "last hop" edge in all cases.

   One thing that I would attach to this requirement is
   that routers must be able to recognize that a page
   is necessary without having to rely on packet
   inspection. Ie, it must use the ordinary
   routing infrastructure (its FIB typically) to
   determine that a page is necesasry.

		  Mike

---

From: Erik Anderlind <[email-masked]>
Date: Wed, 28 Mar 2001 15:17:02 -0500

Hi Mike,

>    to tackle the harder security requirements.

The IP traffic that eventually results in a page has to be initiated
from somewhere. (Just like a voice call in cellular eventually causes
the HLR to initiate a paging action that is executed by the MSC and one
or several 
base stations.) We need to properly abstract this entity and see it as
an IP packet source.
Is it always the MIP HA? (Don't think so.)

Imagine a SIP call - we want to ensure the INVITE (I think this is the
msg name) 
is forwarded to the mobile in a 
timely manner. For other types of traffic, timeliness is not an issue
and 
a page perhaps shouldn't be sent. (The policy itself is of course out of
scope 
from protocol design, but I feel being able to implement a policy
somewhere otside of 
the mobile should be a requirement.) Paging a mobile vending machine to
update its 
SW probably doesn't need as timely delivery of the page. Polling of
reachability
using ICMP doesn't seem like a good solution, so I think there is
something to do.

Any paging brings out the security issue of who may use it. Simple
approaches
are to use e.g. firewalls to filter all but certain source addresses.
Anything
beyond that we probably need to look at security mechnisms. (Use one 
of the available security mechanisms - don't design a new one.) Except
for
802.11, most wireless networks charge per minute or per packet for
access - it wouldn't
be acceptable if anyone could run down a user's account by sending
spurious
packets that result in pages.

User control over this mechanism is a seperate requirement. Not sure yet
that it 
needs to be part of the protocol (e.g. having an HTTP config interface
seems like a 
better alternative.)
...Erik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Mar 2001 12:35:57 -0800 (PST)

[I wanted to break out this out because there are
 some important requirements you've touched on]

 > packets that result in pages.

   Yes, indeed. In fact there is fairly trivial
   DoS attack to drain somebody's battery or wallet
   just by sending a slow trickle of IP packets to
   the mobile node. To some extent these may be
   unavoidable for a determined attacker, but it
   seems to me that a useful requirement for paging
   is that the mobile be able to set up access control
   lists at some inside router -- I think it must be at
   the access router -- to prevent spurious or malicious
   packets to cause the mobile node to wake and possibly
   bring up a traffic channel.

   I'm conflicted how this should be announced by the
   mobile node to the AR and/or Pager. My gut level
   feeling is that this really ought to be dealt
   with by BURP, as in we feed our requirements to
   them for paging, but not try to solve this part 
   of the problem in isolation.

	  Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Mar 2001 14:41:23 -0800

Mike

   In the case of spurious packets/ or spurious paging packets, why couldn't
there be a one time nonce,
  generated by the MN  and effected at the domain during registration   (one
time per realm/zone/domain registration)
that is encrypted in the page message when effected by the network.

Any message that does not have the correct nonce is discarded

Incoming signalling packets should be marked for no charging. There must be
some distinctive for signalling as opposed to data.
So the some packet market at the edge router should do that.
Or even set a packet classifier to do the check on behalf of the MN so that
the packet is set into a no-go queue (penalised) if the nonce does not come
clean

The nonce is made available by the MN only for specific connection requests
(chargeable accurately)

I don't think that signalling packets should be chargeable...but probably a
fixed cost of the service. Data packet should be chargeable...

If it happens that you move too often so you upset you signalling load curve
profile...just  ensure that the packt classifier penalizes your flows to
compensate for the extra operational charges
(somewhat proportional fairness.... that is a measure of mobility.... :)

Theo

UCL/ Mobile Systems

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Mar 2001 21:56:41 -0500

Hi,

At Wed, 28 Mar 2001 12:35:57 -0800 (PST),
>    of the problem in isolation.

It may be possible to use BURP for such purpose if the attacker and
mobile node are not in the same subnet.  On the other hand, attacks
from the same subnet may be more likely for network access in public
area, but I'm not sure how BURP could be used in that case.

Regards,
Yoshihiro Ohba

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Mar 2001 07:39:59 -0800 (PST)

> area, but I'm not sure how BURP could be used in that case.

   If you have a true bus-like L1, this is correct;
   otherwise, the AP/AR can do filtering regardless
   of whether it's in the same subnet.
   However, I don't know of any wireless L1's that
   actually are buses, nor am I sure that there will
   be any soon given the inherent issues with 
   spectrum efficiency and QoS.

		       Mike