Subject: ICMPv6 Destination at Sleep

From: <[email-masked]>
Date: Tue, 10 Sep 2013 09:41:36 +0000

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 11 Sep 2013 18:47:50 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, September 10, 2013 5:42 AM
> To: [email-masked]
> 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).
> 
> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 12 Sep 2013 10:33:31 +0000

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-masked]] 
Sent: 11. syyskuuta 2013 21.48
To: Savolainen Teemu (Nokia-NRC/Tampere); [email-masked]
Subject: RE: ICMPv6 Destination at Sleep

Hi Teemu,

Alternate approaches:

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> 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).
> 
> 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

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Sep 2013 12:11:39 +0100

> 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 t…

I think there are service discovery and security aspects to this that are very relevant to homenet.  But to other domains as well of course.

Tim