## 1 Introduction
It is a common opinion that in the near future IP will be the base common network protocol for the IoT. This does not imply that all objects will be able to run IP. At the opposite, there will always be tiny devices, such as tiny sensors or Radio-Frequency IDentification (RFID) tags, that will be organized in closed networks implementing very simple and application-specific communication protocols and that eventually will be connected to an external network through a proper gateway. However, it is foreseen that all remaining small networked objects will exploit the benefits of IP and corresponding protocol suite. In [4], the author tries to define the following pair of classes for constrained devices, in terms of memory capacity, in order to be used as a rough indication of device capabilities:  
* class 1: RAM size = \(\sim\)10 KB, Flash size = \(\sim\)100 KB;
* class 2: RAM size = \(\sim\)50 KB, Flash size = \(\sim\)250 KB;  
Some of these networked objects, with enough memory, computational power, and power capacity, will simply run existing IP-based protocol suite implementations. Some others will still run standard Internet protocols, but may benefit from specific implementations that try to achieve better performance in terms of memory size, computational power, and power consumption. Instead, in other constrained networked scenarios, smart objects may require additional protocols and some protocol adaptations in order to optimize Internet communications and lower memory, computational, and power requirements. There is currently a large effort within the IETF in the direction of extending existing protocols for resource-constrained networked environments. Some of the current IETF working groups targeted to these environments are: the Constrained RESTful Environments (CoRE) [5], IPv6 over Low power WPAN (6 LoWPAN) [6], Routing Over Low power and Lossy networks (ROLL) [7], and the Light-Weight Implementation Guidance (LWIG) [8] working groups. In Figure 1, a typical IP-based IoT protocol stack is depicted and compared with the classical Internet protocol stack used by standard non-constrained nodes for accessing the World Wide Web. At application layer, the HTTP [9] protocol is replaced by the Constrained Application Protocol (CoAP) [10], which is an application layer protocol to be used by resource-constrained devices, offering a REpresentational State Transfer (REST) service for Machine-to-Machine (M2M) communications, that can be easily translated to/from HTTP. Significant reasons for proper protocol optimizations and adaptations for resource-constrained objects can be summarized as follows. * Smart objects typically use, at physical and link layers, communication protocols (such as IEEE 802.15.4) that are characterized by small Maximum Transmission Units (MTUs), thus leading to packet fragmentation. In this case, the use of compressed protocols can significantly reduce the need for packet fragmentation and postponed transmissions. * Processing larger packets likely leads to higher energy consumption, which can be a critical issue in battery-powered devices. * Minimized versions of protocols (at all layers) can reduce the number of exchanged messages. Protocol compression is especially relevant when dealing with security protocols, which typically introduce higher overhead and increase the size of transmitted data packets. Besides protocol compression, cross-layer interaction between protocols plays a crucial role. This aspect is particularly important in order to avoid useless duplication of security features, which might have a detrimental impact on the computation and transmission performance. For instance, end-to-end security can be guaranteed by adopting IPSec at the network layer or TLS/DTLS at the transport layer. Combining these two security protocols results in a very expensive processing both at the secure channel setup phase and during packet transmission/reception. Another important issue regarding the introduction of security protocols is interoperability.