Re: [Seamoby] IP paging question
Marco Liebsch <Marco.Liebsch@ccrle.nec.de> Mon, 14 January 2002 14:29 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03067 for <seamoby-archive@odin.ietf.org>; Mon, 14 Jan 2002 09:29:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07973; Mon, 14 Jan 2002 09:16:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07949 for <seamoby@optimus.ietf.org>; Mon, 14 Jan 2002 09:16:19 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02886 for <seamoby@ietf.org>; Mon, 14 Jan 2002 09:16:17 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0EEGFH39949; Mon, 14 Jan 2002 15:16:15 +0100 (CET)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA04716; Mon, 14 Jan 2002 15:15:48 +0100
Message-ID: <3C42E814.FDDAEAD1@ccrle.nec.de>
Date: Mon, 14 Jan 2002 15:15:48 +0100
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pars MUTAF <pars.mutaf@inrialpes.fr>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP paging question
References: <3C3F0AC6.C064979@inrialpes.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit
Hello Pars, of course, from power saving point of view, the MN intends to enter dormant mode as early as possible. But I think more parameters have to be considered for this issue. This is, as an example, the systems characteristics (e.g. mobility management) as well as network protocol characteristics. For IPv6, characteristics of Neighbour Cache maintenance should be considered in order to avoid 'black hole' behaviour of the system (packet addresses a MN's link address, taken from cache, although the MN has entered dormant mode already). In case of IPv6, the RachableTime value is 30 sec. Of course, more system characteristics affect the degree of sensitivity for black holes. This is for example having Mobile IPv6 with Route Optimization, allowing direct addressing of MNs from CN point of view (if a valid binding cache entry is available). If the oAR would have a valid cache entry in its table, the packet could be lost. In my opinion, the timer you referred to should be configurable, dependent on the platform's characteristics. Regards, marco Pars MUTAF wrote: > Hello, > > I have a question concerning IP paging: > > What will be the order of magnitude of the "dormant mode timer" > i.e. the time a host waits before making a dormant mode registration > (when it is not in active communication). > > I'm not asking (of course) for an exact value. It will be in > milliseconds or seconds? > > I would say in milliseconds, or "register as quickly as possible" but > I'm not sure. > > Thanks in advance for your help. > > Regards, > pars > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
- [Seamoby] IP paging question Pars MUTAF
- Re: [Seamoby] IP paging question James Kempf
- Re: [Seamoby] IP paging question Marco Liebsch