Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 25 Feb 2002 10:21:33 -0800

Perhaps this is pure ignorance, but I fail to see why this must be
handled in the kernel. Is there an assumption that kernel code may be
run when in power saving mode, or is there some other assumption here
that I missed?

PatC
- -----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Monday, February 25, 2002 9:51 AM
To: [email-masked]
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues

Jim,
  An IP level IP Paging protocol must be implemented as a kernel mode
program like HUT Mipv6 implementation (I think now it is called
MIPL). Sometimes user level implementations are also tried.
  In fact about a year ago we had tried to prototype an earlier
version of draft-sarikaya extending MIPL. The (undergraduate)
students had failed because MIPL at that time was not allowing
sub-options to be defined with binding updates. 
  MIPv4/v6 based IP Paging can easily be implemented extending
present implementations, this was the conclusion of our project. In
fact there are other prototyping efforts documented in literature.

  Hope this helps,

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Feb 2002 11:51:25 -0800

Behcet,

> fact there are other prototyping efforts documented in literature.

Right, I can see where you might want to keep the implementation
in the kernel if the last hop paging message is an IP message instead
of a L2 paging message. If you don't have a specialized L2 paging
channel, you have to use multicast to send out the paging message
since the MN doesn't have valid routing at that point. Probably
in IPv6 it would be done on a link local address. To minimize
battery consumption for messages that aren't for this particular
mobile node, you would want to filter out messages that aren't
to that MN before coming out of the kernel. A context switch
would be more expensive in terms of power. If there is
L2 paging support, however, this would be done in the driver
and IP would not even see it.

I think there are other parts of paging that would
be easier to do at user level, like paging area registration
and perhaps even dormant mode registration. So I think
that there is a fairly limited, narrow set of functions that
would make sense to implement in the kernel.

I'm still not convinced that header options are the right way to
go, however. It could just as well be an ICMP message.

But these are implementation details. We are a long way away
from this. We still need to figure out what the right architecture
is.

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Feb 2002 14:46:09 -0600

Hi Pat,
  I was referring to public domain implementations of MIPv4/v6.
Only kernel code can be executed in  power saving mode could as well be 
correct, but it is out of my reach to make such a statement.

  If paging is defined as an extension to MIPv4/v6 and its LMM 
extensions, another advantage is to inherit the packet forwarding 
mechanisms rather than defining new mechanisms.
 
  Regards,

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> From: Behcet Sarikaya [ mailto:[email-masked] ]
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >
>
> iQA/AwUBPHqArjN1fXKoxmisEQKAHQCfbPHwIxIFhYx5cviMWo6IZIVuZEsAoKfC
> g7nltZhFvku4lNWQ+YNYQ5+b
> =N20v
> -----END PGP SIGNATURE-----
>

-- 
Behcet

---

From: Vinod Kumar Choyi <[email-masked]>
Date: Mon, 25 Feb 2002 17:49:38 -0600

Hi James,

Sorry for the delay. I went throught draft-renker...., and realized that 
in case of MIP, the HA keeps track of the PA. Each time the MN moves to 
a different paging area, it registers the PA@ with the HA. When 
local-mobility management protocols/intra-domain protocols (RegReg6 or 
HMIP or...) are implemented at the foreign network, and if there are 
multiple PAs present within a foreign domain (which is likely to be the 
case) then changing a PA would cause the sending of binding update 
messages to the HA. Intra-domain protocols were developed (even though 
not standardized yet) one of the reasons being to reduce the binding 
messages sent by the MN (apart from from other advantages). Depending 
upon the size of the PAs (if small), then the advantage of using 
HMIP/RegReg6 is reduced remarkably.
IMO, having paging information known to HA, when MN is in a foreign 
network is not such a good idea, it should be dealt with locally and the 
HA should be agnostic to paging.
The other thing about the draft is that eventhough it does talk about 
various scenarios and possible solutions it ends up looking more like 
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.

regards
vinod

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Feb 2002 15:17:17 -0800

Vinod,

> messages to the HA.

I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.

> Intra-domain protocols were developed (even though

HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.

> HA should be agnostic to paging.

Why is it any different than having the HA know the CoA?

> I am not in favor of this draft being adopted as the base draft.

Noted.

            jak

---

From: Vinod Kumar Choyi <[email-masked]>
Date: Mon, 25 Feb 2002 18:41:26 -0600

James,

I don't think you understood what I mentioned, changing of paging area 
would cause sending of BUs to HA even when MN is within the same domain. 
So if you have smaller paging areas within a domain, MN sends a BU to HA 
each time it changes an area and HMIP/RegReg were developed to reduce 
the signaling. , I am not talking about HMIP/RegReg signalling. Kindly 
read my message again.
regards
vinod

James Kempf wrote:

>Vinod,
>
>>Sorry for the delay. I went throught draft-renker...., and realized
>>
>that
>
>>in case of MIP, the HA keeps track of the PA. Each time the MN moves
>>
>to
>
>>multiple PAs present within a foreign domain (which is likely to be
>>
>the
>
>>network is not such a good idea, it should be dealt with locally and
>>
>the
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Feb 2002 16:29:33 -0800

I understood what you said. What I was saying is that the delay of
signaling isn't a problem when the MN is in dormant mode because there
is no user traffic waiting on the signaling to complete. I think most
proposals for LMM are to control the delay involved in handing over an
active MN, so that the MN doesn't have to wait on the rtt of a BU to the
HA and various CNs.

As for the amount of signaling, of course, the size of the paging areas
needs to be regulated so that a BU isn't getting sent every time a
dormant mode MN moves from one subnet to another. Otherwise, yes, it
would be expensive.

It sounds to me that you are in favor of a VLR-like solution, in which
paging information is maintained in the foreign network. Is that so?

            jak

----- Original Message -----
From: "Vinod Kumar Choyi" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 25, 2002 4:41 PM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 26 Feb 2002 10:41:48 +0100

Hi,

I just want to clarify what has been not understood and addressed
misleadingly more than once.

The concept described in draft-renker does 'not' push tracking function
to the HA! Again: The Paging Agent node implements a TA functionality,
taking care of paging areas the mobile terminal is roaming in. The
mobile terminal (or PA assistant functional entities in ARs) keeps the
TA updated when entering a new paging area. This does 'not' include
registration update at a mobility agent (which is the HA in case of
MIPv6). A respective Paging Agent node (there are multiple in an admin.
domain, for load sharing as well as to introduce redundancy for failover
handling) is repsonsible for more than one paging area. The registration
at the HA addresses requirement 4.8 and allows reception of paging
trigger packets at the DMA functional entity for a registered idle
mobile terminal. How should the following requirement 4.8 be interpreted
in a different way as described in draft-renker:

'... The IP paging protocol should make use of existing registration
support...'

For other mobility platforms (e.g. routing based ones), packet capturing
at distributed DMAs (which could be located close to border routers)
might be necessary, since explicit registration of a respective DMA
might be not possible.

Regards,

Marco

Vinod Kumar Choyi wrote:

> that in case of MIP, the HA keeps track of the PA. Each time the MN
> moves to a different paging area, it registers the PA@ with the HA.
> When local-mobility management protocols/intra-domain protocols
> (RegReg6 or HMIP or...) are implemented at the foreign network, and if
> there are multiple PAs present within a foreign domain (which is
> likely to be the case) then changing a PA would cause the sending of
> binding update messages to the HA. Intra-domain protocols were
> developed (even though not standardized yet) one of the reasons being
> to reduce the binding messages sent by the MN (apart from from other
> advantages). Depending upon the size of the PAs (if small), then the
> advantage of using HMIP/RegReg6 is reduced remarkably.
> the HA should be agnostic to paging.
>> that there is a f
>> airly limited, narrow set of functions that

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 26 Feb 2002 10:59:07 +0100

Hi again, Vinod,

> would cause sending of BUs to HA even when MN is within the same

sorry, but I think you did not understand what's written in the draft.
Please be referred to my previous reply to your concern on the concept.
again: In case of MIPv6, HA is only involved in forwarding paging
trigger packets to a DMA. This registration might be long-term and is
indpendent of paging areas, which are managed by TA functional entity.
By the way, DMA does not change when entering a new paging area.

Marco

> So if you have smaller paging areas within a domain, MN sends a BU to
> HA each time it changes an area and HMIP/RegReg were developed to
> reduce the signaling. , I am not talking about HMIP/RegReg signalling.
> Kindly read my message again.
> regards
> vinod
>
> James Kempf wrote:
>
>> Vinod,
>>
>>

---

From: Vinod Kumar Choyi <[email-masked]>
Date: Tue, 26 Feb 2002 10:42:09 -0600

James,

Yes, I am in favour of paging info maintained in the foreign network.

regards
vinod

James Kempf wrote:

>>would cause sending of BUs to HA even when MN is within the same
>>
>domain.
>
>HA
>>>>local-mobility management protocols/intra-domain protocols (RegReg6
>>>>
>or
>
>>>stack, send the BU, then go back into dormant mode. This is
>>>
>considerably
>
>>>expensive in terms of power than what typically is the case with
>>>
>mobile
>
>>>So the architectural question is whether it is possible to architect
>>>
>the
>
>>>system
>>>such that the MN can avoid having to come completely out of dormant
>>>
>mode
>
>>>if L2 paging support is available (of course, if there is no L2
>>>
>paging
>
>>>support,
>>>(in this case MIPv6) to maintain location information even while the
>>>
>MN
>
>>>>messages sent by the MN (apart from from other advantages).
>>>>
>Depending
>
>>>>The other thing about the draft is that eventhough it does talk
>>>>
>about
>
>>>>various scenarios and possible solutions it ends up looking more
>>>>
>like
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Feb 2002 09:51:05 -0800

Vinod,

> Yes, I am in favour of paging info maintained in the foreign network.

So one argument you've made in favor of that architecture is that it
reduces the amount of signaling for smaller sized (like one subnet
sized) paging areas, right?  Any other issues?

Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
Mobile IP"? He has some measurements to show that even if you have one
paging area per subnet, paging signaling volume is less (and in some
cases, substantially less) than MIP signaling for a wide range of cells
per subnet. His design (for MIPv4) maintains the mobile node's location
information in the HA. I'm not advocating that we adopt his architecture
(for example, the architecture maintains the one to one mapping between
paging areas and subnets that we are trying to get rid of) but the
measurements seem convincing.

The other issues I have with maintaining the TA in the foreign network
are the following:

1) Duplicate mobile node location information between the mobility
protocol and the paging protocol. This requires explicit
"deregistration" by the MN with the mobility protocol and "registration"
with the paging when  the MN goes into dormant mode, and the opposite
when it comes out of dormant mode. It would be desirable for the MN to
simply be able to time out and go to sleep.

2) Possibility of race conditions between the mobility protocol location
update and the paging protocol update. For example, what happens if a
packet comes in for the MN between the completion of "deregistration"
with the mobility protocol and "registration" with the paging protocol?

3) TA must maintain state associated with the MN. This leads to
expensive, large, stateful nodes that must be designed to be five 9's
reliable, instead of cheap, redundant nodes like routers are for
routing. In short, a telephony style node rather than an IP style node.

There are some issues which I think having the TA in the foreign network
have in common with having it as part of the mobility protocol which
might be easier to solve:

1) Security. If the TA is part of the mobility protocol, it may require
the host to send any paging area updates to the HA for MIPv6 when it
moves paging area. This may increase power use on the host, and may not
maximally utilize L2 support. If the TA is part of the foreign network,
then the MN could set up a trust relationship with the TA initially
which allows the foreign network ARs to perform the paging area updates
so the MN doesn't have to wake up. This could maximize power saving and
increase use of L2 paging support.

There are some issues which I think having the TA in the foreign network
is better:

1) Paging area update signaling can be confined to the network if L2
support w.o. IP information is available, provided the necessary trust
relationships are in place. This is linked to the security problem
above.

And finally, there are some issues that bother me, but I can't quite put
my finger on how they might be a problem:

1) If the TA is in the foreign network and it goes down, then the
location information is lost. I think, using dynamic paging area
reconfiguration, that the MNs could be forced to reregister when this is
detected, but I'm not sure there isn't some other catch here.

Comments?

                    jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Feb 2002 11:59:09 -0600

Hi Marco,
  DMA in draft-renker is on page 51 only which is Appendix C, not the 
main text which is supposed to provide the solution.
  It is difficult to understand whether what you are saying now was what 
you said or had in your original draft. Maybe this is what you wish to 
have in a future draft. Then we first see the draft and then comment on it.
  Also it is not clear from the figure and the text on Page 51 of 
draft-renker how TA, PA and DMA take their places in a simple IP 
architecture, which takes me back to the fact that Requirements 4.7 and 
4.8 can not be satisfied in a single one size fits all solution.
  Hope you come to agree with this.

Regards,

Marco Liebsch wrote:

> Hi again, Vinod,
>
> Vinod Kumar Choyi wrote:
>
>> James,
>>
>> I don't think you understood what I mentioned, changing of paging 
>> area would cause sending of BUs to HA even when MN is within the same 
>> domain.
>>
>> reduce the signaling. , I am not talking about HMIP/RegReg 
>> signalling. Kindly read my message again.
>> regards
>> vinod
>>
>> James Kempf wrote:
>>
>>>Vinod,
>>>

-- 
Behcet

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 26 Feb 2002 19:40:36 +0100

Hi Behcet,

Behcet Sarikaya wrote:

>   It is difficult to understand whether what you are saying now was
> what you said or had in your original draft. Maybe this is what you
> wish to have in a future draft. Then we first see the draft and then
> comment on it.
> architecture, which takes me back to the fact that Requirements 4.7
> and 4.8 can not be satisfied in a single one size fits all solution.

Not really. Location of the DMA is described on some pages in the draft.
As we have already discovered in a discussion that for some IP moblity
management systems distributed DMAs with respective capturing support
might be reasonable. For this, the coposite architecture described in
the draft might require separating the DMA functional entity from the
paging agent node. The concept as it is also separates generic IP paging
from access link specifics, allowing attendant paging agent functional
entities on access routers to map a generic IP paging request to
technology specifics. For a MIPv6 system, if you could make use of
available registration support, wouldn't you do it, if you expect a
benefit from this? That's what the draft-renker concept describes from
the 00 draft. Having (and keeping) a DMA while roaming within a paging
area as well as changing the paging area would not require registration
of a different DMA with a mobility agent.

Hope this clarifies a bit.

Regards,

Marco

>> > area would cause sending of BUs to HA even when MN is within the
>> > same domain.
>>
>> trigger packets to a DMA. This registration might be long-term and
>> is indpendent of paging areas, which are managed by TA functional
>> entity. By the way, DMA does not change when entering a new paging
>> area.
>>
>> Marco
>>
>>
>> > So if you have smaller paging areas within a domain, MN sends a BU
>> > to HA each time it changes an area and HMIP/RegReg were developed
>> > to reduce the signaling. , I am not talking about HMIP/RegReg

---

From: Xiaofeng Xu <[email-masked]>
Date: Tue, 26 Feb 2002 13:56:09 -0800

Design of Paging Area size and placement of TA shall consider:
1) balance of registration sigalling load and paging signalling load
2) mobile node's mobility behaviour model
3) mobile node's originated and terminated traffic model
4) visited network distribution and configuration model
5) layer 2 technology characteristics
.....

There have been many studies on similar topic in cellular networks.

Regards,
Xiaofeng

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Feb 2002 14:21:53 -0600

Hi Marco,
  In case of simple IP,  the entities such as DMA, TA and PA need to be 
deployed along with the host software implemented in Simple IP hosts
in order to have IP Paging support. Again things would be different if 
IPv4 or IPv6 were to be used for transport.
  If on the other hand Mobile IP is deployed  with its entities of HA, 
FA and GFAs for MIPv4 or AR and MAP (or other) entities for MIPv6 and in 
use at the mobile nodes then we would only add PAs with an extension 
software at the mobile nodes
in order to have IP Paging support.
  The way interoperability is tested would be completely different for 
these two (more correctly 4) different deployment scenarios.
 
  Therefore we do need to define every distinct case in distinct drafts.

  How would the scenario you talk about, assuming Simple IP, and then I 
find MIP infrastructure available so let me do the registration using MIP
fit into this? If there is MIP deployed and it supports paging I do not 
need DMAs and TAs.

  One can question the investment in Simple IP architecture which to a 
large extend duplicates Mobile IP entities. This is what Srinivas was 
talking about. I think that it is a valid concern.

  These are my views.

Regards,

Marco Liebsch wrote:

> Not really. Location of the DMA is described on some pages in the 
> draft. As we have already discovered in a discussion that for some IP 
> moblity management systems distributed DMAs with respective capturing 
> support might be reasonable. For this, the coposite architecture 
> described in the draft might require separating the DMA functional 
> entity from the paging agent node. The concept as it is also separates 
> generic IP paging from access link specifics, allowing attendant 
> paging agent functional entities on access routers to map a generic IP 
> paging request to technology specifics. For a MIPv6 system, if you 
> could make use of available registration support, wouldn't you do it, 
> if you expect a benefit from this? That's what the draft-renker 
> concept describes from the 00 draft. Having (and keeping) a DMA while 
> roaming within a paging area as well as changing the paging area would 
> not require registration of a different DMA with a mobility agent.
>

-- 
Behcet

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 27 Feb 2002 09:45:05 +0100

Hello,
This is not really new ...
FYI you've been working on this Paging Area size issue for IP Paging for some
time
now (wou can retrieve some papers/drafts on my web page)...
i am glad to see that people starts to understand how important this issue
is...

regards,

Claude.

Xiaofeng Xu wrote:

> ......

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 27 Feb 2002 09:57:53 +0100

Claude Castelluccia wrote:

> FYI you've been working on this Paging Area size issue for IP Paging
> for some time

oups i meant "we've been working..."...sorry about that ;-)

> i am glad to see that people starts to understand how important this
> issue is...
>
> regards,
>
> Claude.
>
> Xiaofeng Xu wrote:
>

--

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Feb 2002 08:53:24 -0800

> FYI you've been working on this Paging Area size issue for IP Paging
for some
> i am glad to see that people starts to understand how important this
issue
> is...

Yes, and I think this is orthogonal to the architectural issue of where
to put the TA. There are two meta-choices:

1) Have the paging protocol manage the mobile's location information in
dormant mode, so there is a separate, stateful TA for paging,
2) Have the mobility protocol manage the mobile's location in dormant
mode, so the TA is bundled with and dependent on the mobility protocol.

How paging areas are maintained is a policy question, not an
architectural question (though the architecture will influence the
mechanism used to maintain paging areas).

The original list of concerns I posted was relevant to picking one of
the two choices above.

            jak