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]