Hi Barbara and thank you for your detailed reply.
One use case I have thought about is this: some hosts already utilize ARP and
NS offloading techniques, which means that the network adapter replies to
ARP/NS messages without waking up the IP stack of the host. See for example
(~first hits of search, but there are plenty more):
http://alliedtelesis.com/manuals/2911_IG_UG_Rev_A/Setting_Advanced_Properties.html#Rad31406
http://technet.microsoft.com/en-us/library/ee617165(v=ws.10).aspx
For non-ARP/NS messages destined to the host the IP stack can then be woken up.
In this scenario host retains its addresses during sleep. Now what if the
(battery powered) host knows better and does not want to be woken up? The host
could request adapter to turn on ICMPv6 Sleeping autoreplies (the adapter
potentially already being able to send ICMPv6 NA messages).
This information would assist the sending device to better choose its next
course of action (e.g. ask user to go and kick the device). I may poke homenet
as well, but I have been in understanding that homenet is focused on routing
and related problematics..
I agree that for a separate entity, such as router, it may not be possible to
know for sure whether the sleeping host has disappeared or not. In the case of
Bluetooth Low-Energy the duty cycle can be even 4 seconds, and in such a case
it might be useful to indicate sender about destination being sleeping ..
Thank you for the pointer to the UPnP forum document, I was unaware of it and
will check it out. And I would like to follow and possibly also contribute to
the discovery work. Is the XML the best format, considering IoT and constrained
devices?-)
Best regards,
Teemu
-----Original Message-----
From: ext STARK, BARBARA H [mailto:[email protected]]
Sent: 11. syyskuuta 2013 21.48
To: Savolainen Teemu (Nokia-NRC/Tampere); [email protected]
Subject: RE: ICMPv6 Destination at Sleep
Hi Teemu,
I read your proposal and have been thinking about it. I'd like to share some of
my thoughts as feedback for you.
My thoughts are a bit random and not well-organized.
They are also many in number. Sorry about that.
First let me say that I do see increased prevalence of network interfaces,
entire physical devices, and other device resources that have "sleep modes".
This is largely driven by regulatory requirements around the world to save
energy, as well as increased energy costs causing consumers to want more energy
efficient devices.
The main reason I hear from vendors who try to avoid implementing or defaulting
to these energy saving modes is that of usability and user experience. People
don't like it when devices just disappear from the network and they don't know
why it's not reachable any longer.
So I think the problem you're trying to address is quite real.
Providing awareness that the cause of unreachability may be due to a sleeping
interface is, IMO, a very useful way of lessening the usability problem.
But, I'm not convinced yet that this ICMPv6 code proposal will be able to
provide such information reliably in enough instances, to make it worth the
effort. Part of what I think I'd need to understand would be the use cases
you're considering, where you believe this would be effective.
I mostly think of this problem in the context of Consumer Electronics devices
and usability inside the home network. So it's in the context of that use case
that I'm unsure of how useful this would be.
If this is part of the use case you're considering, you might want to include
homenet in your list of IETF WGs to consider. My experience with homenet
suggests it has a number of individuals who know about physical CE devices, and
the physical layer technologies of network interfaces used by CE devices. These
are very good characteristics for people to have wrt this particular issue.
Some underlying complexities that make this issue hard (not exhaustively
thought through):
- For the router to know that the network interface of a host has entered sleep
mode, there must be some signaling that happens just before the network
interface enters sleep mode. A number of physical layer technologies (PHYs)
have defined such signaling, at PHY/link layer. The messages are PHY-specific,
and do not get forwarded across PHY boundaries. For a router to see one of
these messages, the router must have an interface on the same PHY as the host
interface. If there is an intermediary bridge (e.g., from PHY to Ethernet)
between the router and the PHY, the router will never see the message.
- Many interfaces enter sleep modes without sending any messages. This is
particularly true of Ethernet interfaces and PHYs that have based their sleep
mode behaviors on Ethernet. Routers know nothing about these interfaces being
in sleep modes.
- Wi-Fi has great signaling for entering sleep modes. But the duration is
usually ~200ms and the IP messages are buffered, so this ICMPv6 mechanism
wouldn't be needed in this case.
- Interfaces that do longer sleep modes often take down their IP stack. They
re-acquire IP addresses when re-awakening. If the IP address of interest
happens to be based on info that changes with every IP address re-acquisition
(e.g., temporary or "privacy" addresses), they will not be using the same IP
address when they come back up. It would be undesirable in this case for the
router to respond to ICMP messages for the old address with an indication that
the interface is asleep.
- It's possible that the interface did initially enter a sleep mode, but that
the device was subsequently totally powered down and removed from the network.
At some point, the router would need to stop saying the IP interface was asleep
and would need to say the IP address was unreachable. It's not clear at what
point or how the router decides its info about the interface sleep state is
stale.
Alternate approaches:
There are other possibilities for achieving the goal, but they require higher
layer protocol activity, higher layer apps, and a more stateful awareness on
the part of these apps.
For example, UPnP just published a new DCP
(http://upnp.org/specs/lp/energymanagement1/) that allows devices to get info
about a host's network interfaces, such as whether or not the interface is
configured to enter a sleep mode, whether such an interface is externally
wakeable when it's sleeping, what bit pattern might succeed in waking it, how
long it might take for the device to be reachable on that interface after the
bit pattern is received, whether the interface is set to automatically
re-awaken, how long the interface sleeps before auto-awakening, IP addresses
and MAC address associated with the interface [if the IP stack is currently
up], and some other stuff. The DCP also allows for this info to be proxied by
other devices, so when the host is unreachable, it's still possible to discover
this info.
The intent is to give an application the ability to recognize that there is a
strong possibility that a host's unreachability is due to a sleep mode, because
the network interface was known to be configured to enter one. Knowledge of a
wake-up bit pattern might also prove useful.
It would be possible to make this same xml info available using DNS-SD and/or
mDNS to discover that a device has this info available.
But this may only be useful inside an intranet (e.g., home network, SOHO net)
and not a good approach across the Internet.
BTW, if you're interested in pursuing this alternative approach, I've already
had discussions with some people about maybe starting a homenet activity to
define what would be needed for a usable industry-common approach for "how to
get various device info, from other devices inside the 'home' network,
expressed in xml". I've even started a draft outline, and was hoping to flesh
it out and upload it in the not too distant future. I hadn't been thinking
about including this sort of interface info in my first iteration, but would be
happy to add it. So if you are interested in this alternate approach, let me
know.
Barbara
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of [email protected]
> Sent: Tuesday, September 10, 2013 5:42 AM
> To: [email protected]
> Subject: ICMPv6 Destination at Sleep
>
> Hi,
>
> I have drafted an I-D about ICMPv6 code for explicitly indicating
> destination node to be at sleep ("Destination at sleep") and thus
> being unreachable (sleep lasting longer than is practical to buffer a
> packet). The intent is to allow upper layers (such as TCP) and
> applications to behave more wisely than if receiving only ICMPv6 Code
> "address unreachable" (or nothing, if packet is silently dropped due sleep).
>
> I would like to solicit 6man for feedback.
>
> This might be something for 6lo as well, but I have not intended this
> for very low power use-cases only, but for any kind of case where
> destination is in some kind of sleep mode and thus unable to receive packets.
>
> The I-D itself is here:
> http://tools.ietf.org/id/draft-savolainen-6man-icmp-
> destination-sleeping-00.txt
>
> Best regards,
>
> Teemu
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
