Internet DRAFT - draft-hong-lwig-sleepynode-problem-statement
draft-hong-lwig-sleepynode-problem-statement
Network Working Group Y. Hong
Internet-Draft ETRI
Intended status: Informational J. Youn
Expires: April 24, 2014 DONG-EUI Univ.
October 21, 2013
Problem statement and Use cases of Sleepy node in Constrained node
networks
draft-hong-lwig-sleepynode-problem-statement-01
Abstract
This document describes the use cases of communication considering
sleepy nodes and the problems of connecting to sleepy nodes in
constrained node networks. The use cases of communications between
sleepy nodes and non-sleepy nodes are classified by the end-to-end
communication and the network topology. The adopt of power saving in
constrained nodes raises compelling problems in network layer/
transport/application layer. In this document, problems of each
layer in a sleepy node are described.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Hong & Youn Expires April 24, 2014 [Page 1]
Internet-Draft Problem statement of Sleepy nodes October 2013
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Related Work and Background . . . . . . . . . . . . . . . . . 3
4. Use Cases of communication of a sleepy node . . . . . . . . . 4
4.1. Communication between a sleepy node and a non-sleepy node 4
4.2. Communication between sleepy nodes . . . . . . . . . . . 5
4.3. Communication in ad-hoc network . . . . . . . . . . . . . 6
5. Problem statement of communication of a sleepy node . . . . . 6
5.1. Problems of a sleepy node in Network layer . . . . . . . 6
5.2. Problems of a sleepy node in Transport layer . . . . . . 7
5.3. Problems of a sleepy node in Application layer . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Until now, it seems that the Internet protocol (e.g., TCP/IP protocol
suite) is not directly related to power management, because it is
assumed that network nodes are always connected to main-power. Even
though, the network nodes are moving and the network nodes are not
connected to main power (e.g., the network nodes may use battery or
energy harvesting), the power management has been focused on PHY/MAC
layer. Recently, as constrained nodes in constrained node networks
become connected to the Internet, it is required to consider power
management in Internet protocol in the IETF scape.
The goals for power management may be different by the conditions of
device and environment. The general strategies for power management
of various conditions are depicted as always-on, always-off, and low-
power [I-D.arkko-lwig-cellular]. A constrained node, creating
constrained node networks, may occasionally go into sleep mode
according to strategies of using power for communication
[I-D.ietf-lwig-terminology]. In [I-D.ietf-lwig-terminology], a
device is divided into four classes according to energy limitation of
a device. Here, the constrained nodes classed such as class E1 and
E2 in classes of energy limitation may occasionally go into sleepy
Hong & Youn Expires April 24, 2014 [Page 2]
Internet-Draft Problem statement of Sleepy nodes October 2013
mode. Thus, in constrained node networks, there can exist the end-
to-end communications between a sleep mode node and a non-sleep mode
node.
Some Internet protocols in the IEFT scape assume that the state of a
node is always-on mode, such as a non-sleep mode, of a node. While
in constrained node networks the state of a node can be divided into
a non-sleep mode and sleep mode. Thus, at end-to-end communication
perspective, a sleepy node make various problems when Neighbor
Discovery is operated and message or data is transmitted between
constrained nodes through Internet protocols in the IEFT. In
particular, because the operation of Neighbor Discovery is done with
the assumption that the network node is always-on connected, the
operation of Neighbor Discovery of sleepy node may make operational
problem. And, sleepy node may affect the performance negatively at
application layer and transport layer. First at all, in end-to-end
communication perspective, sleepy node can generate unnecessary
message/data transmission at application layer and transport layer.
In other word, without the state information of a destination node, a
source node transmits the message or data to a destination node that
goes into sleep mode. This point will affect a constrained node with
the limit power negatively in terms of energy efficient of a
constrained node.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Related Work and Background
Power saving in wireless networks is mainly accomplished in PHY/MAC
layer. The basic idea of power saving in PHY/MAC layer is to
minimize the time of transmission/receipt. In IEEE 802.11 WLAN, the
feature of power saving is Power Save Mode (PSM) that is available
for nodes existing in an infrastructure based IEEE 802.11 WLAN. PSM
is based on a synchronous sleep scheduling policy, in which wireless
nodes are able to alternate between an active mode and a sleep mode
[PowerMgmt].
Recently, the consideration of power saving is moved to network
layer, too. In 6lowpan, the Neighbor Discovery operations must
consider the low-power wireless personal area networks such as IEEE
802.15.4. Because the usage of multicast signaling raises severe
energy consumption, the Neighbor Discovery optimization for 6lowpan
has limited the usage of multicast signaling [I-D.ietf-6lowpan-nd].
Hong & Youn Expires April 24, 2014 [Page 3]
Internet-Draft Problem statement of Sleepy nodes October 2013
In application layer, the CoAP has two functions such as proxy and
cache. The proxy function in the CoAP can cache and service requests
for sleepy servers. Thus, a client sends a CoAP request to a proxy
on behalf of an origin server of sleep mode and then it respond
directly to the client through the proxy. Otherwise if the proxy has
an invalid representation of the resource in its cache, the proxy has
to attempt to get the valid resource from an origin server of sleep
mode. The attempt may or may not be successful according to the
state of the origin server [I-D.ietf-core-coap].
4. Use Cases of communication of a sleepy node
To describe the problem of sleepy node in constrained node networks,
this clause describes the use cases of communication of sleepy nodes.
The use case of communication of sleepy nodes looks like that of
normal Internet nodes. The difference from the communication between
normal Internet nodes is that there are definitely different two
types of network nodes : sleepy node and non-sleepy nodes
[I-D.ietf-lwig-terminology]. So, the communication of sleepy nodes
can be classified into communication between sleepy node and non-
sleepy node and communication between sleepy nodes. And by the
topology of networks, the communication can be classified into
communication across router, communication within a router, and
communication in ad-hoc network.
4.1. Communication between a sleepy node and a non-sleepy node
This use case shows the communication between one network node with
always-on network connectivity (non-sleepy node) and one network node
with sleepy node network capabilities. In this use case, to provide
the communication between a non-sleepy node and a sleepy node, it may
require new purpose server such as a Proxy server to handle the
request of different node with different capabilities. In this case,
the new purpose server will be located at the interface of network
[I-D.jeong-eman-network-proxy-protocol].
+--------------------+
+---------------+ | | +---------------+
| +---------+ | | | | +----------+ |
| | Sleepy +--+----+ Internet +---+--+Non-Sleepy| |
| | node | | | | | | node | |
| +---------+ | | | | +----------+ |
+---------------+ | | +---------------+
Hong & Youn Expires April 24, 2014 [Page 4]
Internet-Draft Problem statement of Sleepy nodes October 2013
Constrained +--------------------+ General
networks networks
Figure 1: Communication between sleepy node and non-sleepy node
4.2. Communication between sleepy nodes
This use case can be classified into the communication between sleepy
nodes in same constrained networks and the communication between
sleepy nodes in constrained networks connected through Internet. The
first use case shows the communication between sleepy nodes within a
router. In this use case, the sleepy nodes may use same power saving
mechanism and energy efficient technique. And, in this use case, the
layer 3 entities such as routers and gateways may benefits from the
layer 2 entities such as Access Point and Base Station to keep
synchronous sleep scheduling.
+------------------------------+
| |
| +--------+ | +---------------+
| | Sleepy +------+ +----+---+ | |
| | node | +------+ | | |
| +--------+ | Router +---------+ Internet |
| +------+ | | |
| +--------+ | +----+---+ | |
| | Sleepy +------+ | +---------------+
| | node | |
| +--------+ |
| |
+------------------------------+
Figure 2: Communication between sleepy nodes in same constrained
network
The other use case shows the communication between sleepy nodes in
different constrained network in which different power saving
mechanism and energy efficient technique is used. Similar to the
case of clause 4.1, a node do not know information about sleep state
of target node. Thus, constrained network must have new purpose
server such as a Proxy server to handle and manage sleepy node.
+---------------+
+---------------+ | | +-----------------+
|+------+ +------+ | | +------+ +--- ---+ |
Hong & Youn Expires April 24, 2014 [Page 5]
Internet-Draft Problem statement of Sleepy nodes October 2013
||Sleepy|--|Router|---+ Internet +---|Router|--| Sleepy| |
|| node | +------+ + | +------+ | node | |
|+------+ | + | | +-------+ |
+---------------+ | | +-----------------+
Constrained +---------------+ Constrained
networks networks
Figure 3: Communication between sleepy nodes in different constrained
network
4.3. Communication in ad-hoc network
This use case can be happen when it is impossible to implement an
infrastructure based wireless network and an infra-less wireless
network is constructed. Although there is no explicit a router, it
may be possible to select a master and slaves and make the selected
master do as a router to provide power saving mechanisms between
sleepy nodes. The efficiency of infra-less power saving may be worse
than infrastructure-based power saving mechanism. So, it may require
to hybrid the infra-less power saving and infrastructure-based power
saving.
+--------+ +---------+
| Sleepy +-----------+------------+ Sleepy |
| node + | + node |
+--------+ | +---------+
|
+----+----+
| Sleepy |
| node |
+---------+
Figure 4: Communication in ad-hoc network
5. Problem statement of communication of a sleepy node
5.1. Problems of a sleepy node in Network layer
The main problems of a sleepy node are related to neighbor discovery
[RFC4861]. Among neighbor discovery operations, the operations
related to multicast signaling affects severely energy efficiency.
So, in 6lowpan-nd, the usage of multicast Neighbor Discovery messages
has the limitation with some exception such as initial set of default
routers. Because of the limitation of multicast Neighbor Discovery
messages, new address assignment with Address Registration Option
Hong & Youn Expires April 24, 2014 [Page 6]
Internet-Draft Problem statement of Sleepy nodes October 2013
(ARO) and different Duplicate Address Detection (DAD) mechanisms are
used in 6lowpan-nd [I-D.ietf-6lowpan-nd].
Another problem of a sleepy node in network layer is the choosing the
proper a sleep time appropriate for its energy characteristics. Even
though the corresponding node is not down or the route path to the
corresponding node is not broken, an inappropriate sleep time leads
wrong operations. If the modification of Neighbor Discovery such as
6lowpan-nd is applied to network layer in all network nodes, the
problems of a sleepy node in network layer may be decreased. In
realistic, this modification of Neighbor Discovery such as 6lowpan-nd
seems that impossible because there are various wireless networks.
5.2. Problems of a sleepy node in Transport layer
The most constrained environments consist of interoperable IP-capable
devices. Thus, a constrained node needs UDP/TCP of transport layer
for an end-to-end data transmission service. However a constrained
node, creating constrained node networks, is a small device such as
sensor device with limited CPU, memory, and power resources. In
addition, implementing the whole functionality of the UDP/TCP in a
small device becomes a burden. Thus, constrained nodes must
implement a minimal functionality for transport service demanded by
application in constrained node.
In [I-D.ietf-lwig-guidance], light-weight implementation of transport
layer must be considered in a constrained node. Also, the analysis
of functionality of the transport protocol is needed to support an
end-to-end communication between a non-sleepy node and a sleepy node.
As transport protocol in constrained node with the limit memory, UDP
has many advantages. In particular, UDP has a very low overhead for
both header size and protocol procedure. This means that UDP will be
used as the transport protocol of constrained node in constrained
node networks because the packet transmissions and receptions consume
less energy and the small space of memory for UDP is needed. This
is, the reason is that the CoAP uses UDP as transport protocol to
transmit the message of the CoAP. Nevertheless, UDP has drawback
that is UDP does not provide any recovery mechanism for lost data.
Also, UDP does not have any functionality to support a sleepy node.
Thus, source node does not know that data may or may not be
successful to the destination node.
TCP has more overhead for both header size and protocol procedure
than UDP to be implemented as transport protocol in constrained node.
Thus, TCP implementation with the whole functionality in a small
device occurs several compelling problems. And it also is not aware
to the sleep mode of destination node. TCP protocol is a complex
Hong & Youn Expires April 24, 2014 [Page 7]
Internet-Draft Problem statement of Sleepy nodes October 2013
protocol that has a reliable mechanism and the mechanisms such as the
sliding window algorithm and congestion control for high throughput.
However, the core of TCP is quite simple because many of the complex
mechanisms are to improve high-throughput performance. Thus, because
high throughput is not a requirement of any end-to-end communication
in most constrained environments, several mechanisms in TCP are not
needed TCP mechanism, such as the sliding window algorithm and
congestion control, for high throughput. As UDP, TCP also does not
have any functionality to support a sleepy node. This is, TCP
mistakes data loss generated by sleepy node as data loss over end-to-
end transmission. Thus. TCP can perform unnecessary retransmission.
This situation can occur in most constrained environments.
If Proxy server, mentioned in clause 4.1 and clause 4.2, does not
exist on constrained network, TCP may be able to perform unnecessary
retransmission. Thus, in order to overcome the above problem, TCP
must perform connection-oriented service in basic functionality of
TCP before data transmission. Thus, TCP does not perform unnecessary
retransmission.
5.3. Problems of a sleepy node in Application layer
As the CoAP, it is up to the application to support sleepy node to
end-to-end transport service, which also increases the complexity in
constrained node. Also there is still no standard transport protocol
that can support sleepy node. Thus, to support an end-to-end
transport service between a sleep mode node and a non-sleep mode
node, the analysis of transport protocols is needed.
6. Security Considerations
TBD.
7. IANA Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Hong & Youn Expires April 24, 2014 [Page 8]
Internet-Draft Problem statement of Sleepy nodes October 2013
8.2. Informative References
[I-D.arkko-lwig-cellular]
Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
Efficient CoAP Devices for Cellular Networks", ID draft-
arkko-lwig-cellular-00, February 2013.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabartiy, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", ID draft-ietf-6lowpan-nd-21, August 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", ID draft-ietf-core-coap-18,
June 2013.
[I-D.ietf-lwig-guidance]
Bormann, C., "Guidance for Light-Weight Implementations of
the Internet Protocol Suite ", ID draft-ietf-lwig-
guidance-03, February 2013.
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", ID draft-ietf-lwig-
terminology-05, July 2013.
[I-D.jeong-eman-network-proxy-protocol]
Jeong, S., "Network Proxy Protocol", ID draft-jeong-eman-
network-proxy-protocol-01, February 2013.
[PowerMgmt]
Klues, K., "Power Management in Wireless Networks",
Report, for Advanced Topics in Networking: Wireless and
Mobile Networking by R. Jain, Wash. Univ. in St. Louis, ,
2006.
Authors' Addresses
Yong-Geun Hong
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 6557
Email: yghong@etri.re.kr
Hong & Youn Expires April 24, 2014 [Page 9]
Internet-Draft Problem statement of Sleepy nodes October 2013
JooSang Youn
DONG-EUI Univ.
Busan
Korea
Phone: +82 51 890 1993
Email: joosang.youn@gmail.com
Hong & Youn Expires April 24, 2014 [Page 10]
