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

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 28 Mar 2001 12:54:04 -0600

James,

I agree it is premature to discuss solutions. I just wanted to get across
some of the main approaches I have heard over the years.

Thanks,

Glenn

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 11:11 AM
To: [email-masked]; [email-masked]; [email-masked]; Morrow,
Glenn [RICH2:C330:EXCH]
Cc: [email-masked]
Subject: Paging Functional Architecture ( was: RE: [seamoby] L2/L3
Paging)

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