Subject: [seamoby] To page, or not to page

From: Patrice Calhoun <[email-masked]>
Date: Wed, 28 Mar 2001 15:07:23 -0800 (PST)

All,

At the IETF meeting, there were some agreements on wether paging is a useful
Layer 3 function. There seemed to be some concensus that it was, however I am
now seeing quite a bit of controversy, even though the problem statement has
passed last call (yes, last call expired on March 12th). The document is about
to go to IESG for IETF last call and publication.

So I am now confused that there seems to be so much going on in this area, now
that the time is past. Could someone enlighten me? (btw, please do not bother
responding if you haven't read the I-D).

Thanks,

PatC

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 28 Mar 2001 20:49:14 -0500

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 6:29 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [seamoby] To page, or not to page
> 
> 
> Pat,
> 
> My interpretation of the traffic on the list regarding paging 
> is the following:
> 
> 1) Some people haven't read the problem statement and therefore don't
> have an understanding of what led the design team to conclude that
> support for L3 paging was desirable and even necessary in the 
> multitechnology
> case.
> 
> 2) There is a disagreement with the working group concensus 
> expressed at IETF 50
> that the design team should not require L2 paging. This seems to
> break down into the following areas:
> 
> 	a) Some people seem to feel that it is simply not possible to
> 	define an L3 paging protocol without L2 support, and want the
> 	requirements to reflect that.

How does a Paging Area differ from an IP Multicast Group?
For Paging optimized technologies would IP Multicast not suffice?

- Kulwinder.

> 	
> 	b) Some people want to make sure that saying that L2 is not
> 	required does not rule out using L2 support when you have it
> 	and want the requirements to reflect that.
> 	
> 	c) Some people would like to define an L3 paging 
> protocol completely
> 	independent of L2, and therefore say nothing about L2 in the
> 	requirements or in the design.
> 	
> Did I miss anything?
> 
> 		jak
> 		
> 
> >X-Authentication-Warning: charizard.diameter.org: majordomo 
> set sender to 
> [email-masked] using -f
> >Date: Wed, 28 Mar 2001 15:07:23 -0800 (PST)
> >From: Patrice Calhoun <[email-masked]>
> >Subject: [seamoby] To page, or not to page
> >To: [email-masked]
> >MIME-Version: 1.0
> >
> >All,
> >

---

From: "Martin, David P" <[email-masked]>
Date: Thu, 29 Mar 2001 08:19:53 -0500

Before the Minneapolis meeting I was in agreement with the problem
statement, however some statements were made at the meeting that concerned
me (if you trace back the thread I started you will see my original post
occurred just after the meeting in Minneapolis).

I interpreted the problem statement to mean that our charter would be to
utilize paging if it existed in layer 2, and if not, that a best-effort IP
paging type of protocol would be developed to try and deliver packets for
those cases where paging was not supported at layer 2.  What I heard at the
meeting and later is that there is a strong desire to build a layer 3
protocol that incorporates substantial layer 2 functionality.  I am not
against this, I just want clarity on the scope of the problem that we are
going to solve.  If as a group we feel that we want to take on all or a
majority of layer 2 functionality (because no assumptions are being made
about what exists at layer 2), I would like to see this as a seperate effort
(at least initially) than the case where we can (or do) make assumptions
about layer 2.  Maybe the effort becomes the same protocol, but then again
there may be good reasons to have two different (but complimentary,
non-overlapping protocols).  I don't know what the best solution is, but I
feel it is premature to assume that one protocol may be the answer, which
was where the discussion in Minneapolis, and some of the discussion on the
list seemed to lead.

Again, my concerns arise because my interpretation of the problem statement
differed from others, perhaps I am the only one, if so I apologize for not
catching on to the subtleties until now.

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 6:07 PM

---

From: "Martin, David P" <[email-masked]>
Date: Thu, 29 Mar 2001 08:24:14 -0500

> > This seems to
> ok. Can we agree that these issues can be addressed during 
> the requirements
> phase?
> 

I essentially agree with all the above statements, and agree that these can
be done during the requirments phase.

However, I do have clarifying question on c) - When we say nothing about
layer 2, does this mean that we will 1) Not deal with layer 2 issues, or 2)
Attempt to solve layer 2 issues in the protocol.

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 08:05:31 -0800 (PST)

Kulwinder,

>For Paging optimized technologies would IP Multicast not suffice?

That's a possible implementation, not a requirement. We are currently in
the requirements/architecture phase.

		jak

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 29 Mar 2001 18:19:40 +0100

I did bother (yesterday) to read the draft.
So I'm not sure any of my comments might be used to 
gauge consensus.
What bothers me is that people decide that L3
paging is required without saying what it is
(unless I missed something):

Is it based on multicast? is it unicast? These two
options make it a completely different thing

Multicast would more fit what today's L2 paging definition is,
however this would imply that a paging would wake up all the
terminals (not acceptable). 
On the other hand, if it is unicast, the page would be replaced most 
conveniently by user data. the link over which data are received
will tell where to send any agent solicitation... If more than one link,
guess what, pick one you like most. What would be nedeed is only
a location update protocol. A location update protocol is
already available and it is mobile IP (or an extention of it,
if at all needed).

as such, I'd support to take a step back and
re-consider the soundness of the reqs (OK, the IESG may do that instead,
if we want an analogy with what has happened with MIPv6 ;).

Also, maybe what I described now cannot quite be defined as paging
(although I truly believe paging may gain more cookie points,
in a marketing setting).

alessio

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: 29 March 2001 02:03
To: James Kempf
Cc: [email-masked]; [email-masked]
Subject: Re: [seamoby] To page, or not to page

> My interpretation of the traffic on the list regarding paging is the
> following:
> 
multitechnology
> case.

ok. So I will not attempt to gauge concensus from people that haven't
bothered
to read the draft.

> 
> 2) There is a disagreement with the working group concensus expressed at
> IETF 50 that the design team should not require L2 paging.

which is ok because we need to gauge concensus on the list, regardless of
what
happened at the meeting.

> 	c) Some people would like to define an L3 paging protocol completely

ok. Can we agree that these issues can be addressed during the requirements
phase?

PatC

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 08:21:38 -0800 (PST)

Dave,

>Attempt to solve layer 2 issues in the protocol.

The protocol design should reflect whatever the requirements say, because
the requirements guide the protocol design. So if the requirements
say something about layer 2, then the design should reflect those
requirements, and vice versa.

In any case, I don't think a layer 3 protocol can solve any layer 2 issues.
The best we could do is require layer 2 support be used
when available, and have the protocol structured to reflect that. 
Assuming, of course, concensus is there for using layer 2 support
when available.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 12:19:46 -0800 (PST)

Alessio,

>(unless I missed something):

Well, the requirements (which we are currently defining) should
do that.

>already available and it is mobile IP (or an extention of it,

You are talking here about what goes over the air, correct? That is only
one small part of what is needed for paging.

If the L2 paging protocol is used over the air, then all  that is needed
is for a wired backbone protocol to handle location updating when
the mobile goes into dormant mode and crosses paging area boundaries,
and to trigger a page when a packet comes in. As you indicate, it
will need to be integrated with mobile IP, but it should not be
bound exclusively to mobile IP because the IRTF will be working on
a micromobility routing protocol and the wired backbone part may
be useful for that as well. 

And, I think we should also be clear that something in addition to mobile IP as 
it exists today is needed. The way 3GPP2 handles mobile IP location updating for
dormant mode mobiles today is the mobile comes out of dormant mode,
brings up a traffic channel, does a mobile IP registration, and goes
back into dormant mode. This is not very efficient.

Of course, this is all implementation. The requirements that would come
out of this are:

	The IP paging protocol shall be efficient with respect to
	mobile power use.
	
	The IP paging protocol shall be designed to allow a binding
	with mobility protocols for location update purposes, including
	mobile IP.
	
	The IP paging protocol shall utiliize L2 paging support if
	available, but shall not require such support.

>if we want an analogy with what has happened with MIPv6 ;).

Actually, Alissio, that is precisely what we are doing. If you have
some requirements you would like to propose, please, by all means,
propose them.

>(although I truly believe paging may gain more cookie points,

IS-41 has messages associated with paging and it goes over the SS7 backbone.
So I don't see any problem calling support for paging in the wired
network as paging. Paging isn't only about what goes over the air, IMHO.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 12:07:38 -0800 (PST)

Dave,

>against this, I just want clarity on the scope of the problem that we are

I disagree with this analysis. My interpretation of the WG concensus probe
is that the WG doesn't want the protocol to be designed with a requirement
for L2 paging. This does not preclude using L2 paging when available.

That said, the problem statement addresses the issue of systems such
as 802.11 that use reassociation at L2, and how they will not benefit from
L3 paging.

>was where the discussion in Minneapolis, and some of the discussion on the

The issue here is a hypothetical dormant mode (or maybe not so hypothetical, 
Kluwinder's comments on Bluetooth lead me to believe that Bluetooth may behave 
this way) where the mobile node periodically comes out of dormant mode to listen
to L2, but it does NOT reassociate with an access point. For this kind
of an L2, a periodically broadcast paging message at L3 would work like
an L2 page in a cellular system.

I don't think we need to have two protocols, I think we need to firstly
agree what the requirements should say, then secondly, make sure the 
protocol reflects the requirements. 

Can you tell me what you think the requirements should say? I put out
a list of possible requirements regarding L2 (duplicated below), which
do you think should be included?

		jak

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 29 Mar 2001 15:50:05 -0500

> From: Casati, Alessio (Alessio) [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 12:20 PM
> To: 'Patrice Calhoun'; James Kempf
> Cc: [email-masked]
> Subject: RE: [seamoby] To page, or not to page
> 
> 

First, I agree that a paging protocol is not neccesary.

What I was suggesting is:

1. Timely Message enters Paging Area.
2. An AR takes Message places it in a Multicast packet destined for all
AP/ARs in the Paging Area.
3. Upon an AP/AR recieving the Multicast packet it removes the unicast
message and sends it over the air to the one intended Mobile. 

- Kulwinder.

> expressed at

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 14:27:37 -0800 (PST)

Kulwinder,

>message and sends it over the air to the one intended Mobile. 

What you have defined here is a paging protocol, regardless
of whether there are special messages or not. Also, it may not
be sufficient for all radio L2, IHMO.

		jak

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 29 Mar 2001 21:23:41 -0500

> Sent: Thursday, March 29, 2001 5:28 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

Creation is not endorsement.  I still don't think it is a _neccesary_
protocol.  A router based location update protocol, I believe is a
_necessary_ protocol.  If a Paging protocol is meant to serve as a drop-in
replacement in a leagacy GSM system it should be stated as a requirement.

- Kulwinder.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Fri, 30 Mar 2001 12:20:52 +0100

Maybe it is a small part of what is needed to send data to the MN

But there is a disconnect here: if the mobile goes dormant, no way you can
do
a L3 thing, whatever you could do is a L2/L3 coordination. as such, this
becomes
a technology dependent work. 

And, I think we should also be clear that something in addition to mobile IP
as 
it exists today is needed. The way 3GPP2 handles mobile IP location updating
for
dormant mode mobiles today is the mobile comes out of dormant mode,
brings up a traffic channel, does a mobile IP registration, and goes
back into dormant mode. This is not very efficient.

 it depends on what you want to do. If you do that to handle the 
100m coverage radius antennas in licenced spectrum, that may be a problem.
If it is only
for inter RAN handoff, it may not be a problem, depending on the size of the
RAN.

	
The requirement should be: the IP location update protocol
shall be efficient with respect to mobile Power use.

That is acceptable, but I dont see the need for a paging protocol. Just send
data.
the APs where the MN is not attached, will drop packet, and you are set.

This is a seamoby centric view of the world... No matter what,
you will do what the L2 is expected to work. More acceptable statement
would be " the protocol location update protocol shall work withhout
requiring
L2 operation changes" Or something along the lines of this.

The requirement on the paging protocol I have are Non existent, consistently
with the fact that I do not recognize the need for such protocol.
That req document is not really a requirement document, it is a document
saying "we require paging, and here is why". However it steers clear from
defining
what paging is... Not much agreeable. It is a metarequirement documet on
some
Yet to be defined or conceived thing. 

In my opinon, paging is over the air, the rest is call set-up or
session managenet, or user traffic...

regards.

alessio