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

From: [email-masked]
Date: Fri, 1 Mar 2002 18:12:06 -0600

>Can you explain why? If the host is fixed, all that is required is some
signal at L2 that causes the power management hardware to spin up the
disk and turn on the CPU.

It will certainly work to wake up the host. Anyway, if you feel that such problems are within the Seamoby charter then it is fine. However, I woould like to bring the following charter item description for DMHA.

Dormant Mode Host Alerting 

Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. 

All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. 

The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. 

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 4 Mar 2002 09:24:06 -0800

Srini,

> Third, the Working Group will define the requirements for Dormant Mode
Host Alerting (DMHA) at the IP layer (also known as IP Paging) in
networks, and a protocol will be developed to tackle this problem. DMHA
is typically used in networks that support mobile devices that
periodically enter dormant mode to reduce power consumption. DMHA enable
network devices to track a mobile that has moved from its last point of
attachment, while in dormant mode, allowing the mobile's packets to be
delivered.
>
> All work produced by the Working Group will support both IPv4 and
IPv6, will follow the congestion control principles in RFC2914 (BCP41),
and will undergo a security review prior to WG last call. Protocols
developed will be accompanied by MIBs.
> The Working Group will coordinate closely with the aaa, mobileip,
pilc, and rohc working groups.

So I guess I don't see any conflict between this and accommodating fixed
hosts. Is the concern that we may need to specify something at L2? If
so, then be assured that we won't. There is a move afoot to start some
work on defining abstract L2 triggers, but this will not involve
explicit L2s and it will not be done in Seamoby.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 4 Mar 2002 09:24:06 -0800

Srini,

            jak

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 04 Mar 2002 19:33:23 +0100

Hi all,

talking about reducing drainage of battery energy for mobile terminals or even saving power on a stationary host, I would like to refer to another aspect where 'idle mode support' and 'paging' brings in a benefit. Of course, saving energy on a terminal's side is an important issue, but from network design point of view, paging mechanisms, especially when deploying advanced paging strategies, can improve scalability in mobile networks. This is mainly for mobile terminals, of course, but this aspect
should not be ignored.

My understanding is that the Seamoby WG protocol on DMHA should 'allow' different access technologies (and their different lower layer power saving modes) to be deployed, but the group's 'focus' should be on the network side and the design of a flexible architecture as well as IP protocol specifics. So, we should have L2 specifics in mind, but should mainly take care of that the architecture and the protocol allows efficient deployment of IP paging and paging strategies for 'signaling cost'
reasons.

Marco

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 04 Mar 2002 19:33:23 +0100

Hi all,

Marco