RE: [RSN] Update

"Anders Brandt" <abr@zen-sys.com> Wed, 06 June 2007 08:19 UTC

Return-path: <rsn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqkC-0002oV-7v; Wed, 06 Jun 2007 04:19:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqkB-0002oQ-Qk for rsn@ietf.org; Wed, 06 Jun 2007 04:19:51 -0400
Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvqkA-0005LQ-GO for rsn@ietf.org; Wed, 06 Jun 2007 04:19:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RSN] Update
Date: Wed, 06 Jun 2007 10:19:49 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local>
In-Reply-To: <4664D24E.2000803@saloits.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RSN] Update
thread-index: AcenHh9V3G2VjjRGSnetjqigWVkMpQA8fJ5A
References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com><46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> <4664D24E.2000803@saloits.com>
From: Anders Brandt <abr@zen-sys.com>
To: "Timothy J. Salo" <salo@saloits.com>, rsn@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc:
X-BeenThere: rsn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Sensor Networks <rsn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rsn>
List-Post: <mailto:rsn@ietf.org>
List-Help: <mailto:rsn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe>
Errors-To: rsn-bounces@ietf.org

-----Original Message-----
From: Timothy J. Salo [mailto:salo@saloits.com] 
Sent: 5. juni 2007 05:03

> (e.g., some nodes may sleep much of the time;

...

>  Should some nodes, such as power-rich or gateway nodes, act as
>  proxies (for some functions) for power constrained node?

...

>  - Should a link/subnet use both MAC addresses and network-addresses,
     or should only a single set of addresses be used for both purposes?

Operating nodes running on small batteries in very low bandwidth
environments
is at the heart of this initiative.

While awareness of sleeping nodes and the use of certain nodes as
proxies
is very much inside the scope of this group, I am a bit uncertain
whether
header and/or data compression is relevant on the routing layer.
It might be specific to the individual L2 implementations?

Concerning the proxy node topic, there are (at least) two situations to
consider:

A: Certain transmission mechanisms are asymmetrical, so that sending to
a 99% sleeping
requires a transmission activity from the sending part than from the
node waking up a
short while to detect traffic. This case may be considered a
_POWER_PROXY_.
Latency for the node response may not be higher than a few 100
milliseconds.

B: Water sensing nodes and other nodes may wake up extremely rarely, say
every 5 minutes.
They send a measurement report to a local proxy, that confirms the
receival.
Then the node goes back to sleep for the next 5 minutes.
The only way to change settings, e.g. the measument interval or the
target proxy
for such a node, is to provide a mailbox service, where instructions are
queued up,
waiting for the next time, the node makes contact.
We could call this a _TIME_PROXY_.

Anders Brandt

_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn