One document matched: draft-iab-smart-object-workshop-10.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2617 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY rfc5222 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC5582 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5582.xml'>
<!ENTITY RFC3023 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml'>
<!ENTITY RFC4288 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
<!ENTITY RFC2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC2818 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
<!ENTITY RFC3552 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml'>
<!ENTITY RFC4101 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4101.xml'>
<!ENTITY RFC3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC2743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY RFC2222 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2222.xml'>
<!ENTITY RFC6272 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6272.xml'>
<!ENTITY I-D.kivinen-ipsecme-ikev2-minimal PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kivinen-ipsecme-ikev2-minimal.xml'>
<!ENTITY I-D.hamid-6lowpan-snmp-optimizations PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hamid-6lowpan-snmp-optimizations.xml'>
<!ENTITY I-D.eggert-core-congestion-control PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eggert-core-congestion-control.xml'>
<!ENTITY I-D.jennings-energy-pricing PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-energy-pricing.xml'>
<!ENTITY I-D.ietf-core-coap PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml'>
<!ENTITY I-D.ietf-roll-rpl PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-rpl.xml'>
<!ENTITY RFC3561 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3561.xml'>
<!ENTITY I-D.routing-architecture-iot PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.routing-architecture-iot.xml'>
<!ENTITY RFC5867 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5867.xml'>
<!ENTITY RFC5826 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5826.xml'>
<!ENTITY RFC5673 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5673.xml'>
<!ENTITY RFC5548 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5548.xml'>
<!ENTITY I-D.ietf-roll-protocols-survey PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-protocols-survey.xml'>
<!ENTITY RFC4903 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4903.xml'>
<!ENTITY RFC5191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml'>
<!ENTITY I-D.cheshire-dnsext-dns-sd PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml'>
<!ENTITY RFC3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3921 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3921.xml'>
<!ENTITY RFC4436 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4436.xml'>
<!ENTITY RFC6059 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6059.xml'>
<!ENTITY RFC3546 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3546.xml'>
<!ENTITY RFC4806 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4806.xml'>
<!ENTITY RFC6241 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml'>
<!ENTITY RFC4960 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
<!ENTITY RFC4340 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml'>
<!ENTITY RFC0768 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>
<!ENTITY RFC0793 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
<!ENTITY RFC0791 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml'>
<!ENTITY RFC2460 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902" category="info" docName="draft-iab-smart-object-workshop-10.txt">
<front>
<title abbrev="Smart Object Workshop Report">Report from the 'Interconnecting Smart Objects with the Internet' Workshop, 25th March 2011, Prague</title>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<date year="2012"/>
<area></area>
<workgroup></workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Smart Objects</keyword>
<keyword>Internet of Things</keyword>
<abstract>
<t>This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'.
The workshop took place in Prague on March, 25th. The main goal of the workshop was to
solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report
summarizes the discussions and lists the conclusions and
recommendations to the Internet Engineering Task Force (IETF)
community.</t>
<t>Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************************** -->
<section title="Introduction">
<t>
The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF), under the
leadership of the Internet Engineering Steering Group (IESG) and area
directorates.
</t>
<t>
Today's Internet is experienced by users as a set of applications, such as email, instant messaging, and services on the Web. While these applications do not require users to be present at the time of service execution, in many cases they are. There are also substantial differences in performance among the various end devices, but in general end devices participating in the Internet are considered to have high performance.
</t>
<t>
There are, however, a large number of deployed embedded devices and there is substantial value in interconnecting them with the Internet. The term "Internet of Things" denotes a trend where a large number of devices employ communication services offered by the Internet Protocols. Many of these devices are not directly operated by humans, but exist as components in buildings, vehicles, and the environment. There is a large variation in the computing power, available memory, (electrical) power, and communications bandwidth between different types of devices.
</t>
<t>
Many of these devices offer a range of new possibilities or provide additional value for previously unconnected devices. Some devices have been connected using proprietary communication networks in the past but are now migrating to the use of the Internet Protocol suite in order to share the same communication network between all applications and to enable rich communications services.
</t>
<t>
Much of this development can simply run on existing Internet protocols. For instance, home entertainment and monitoring systems often offer a web interface to the end user. In many cases the new, constrained environments can benefit from additional protocols and protocol extensions that help optimize the communications and lower the computational requirements. Examples of currently ongoing standardization efforts targeted for these environments include the "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and the "Light-Weight Implementation Guidance (LWIG)" working groups at the IETF.
</t>
<t>
This workshop explored the experiences of researchers and developers when considering the characteristics of constrained devices. Engineers know that many design considerations need to be taken into account when developing protocols and architecture. Balancing between the conflicting goals of code size, economic incentives, power consumption, usability and security is often difficult, as illustrated by Clark, et al. in "Tussle in Cyberspace: Defining Tomorrow's Internet" <xref target="Tussle"/>.
</t>
<t>
Participants at the workshop discussed the experience and approaches taken when designing protocols and architectures for interconnecting smart objects to the Internet. The scope of the investigations included constrained nodes as well as constrained networks.
</t>
<t>
The call for position papers suggested investigating the area of integration with the Internet in the following categories:<list style="symbols">
<t>Scalability</t>
<t>Power efficiency</t>
<t>Interworking between different technologies and network domains</t>
<t>Usability and manageability</t>
<t>Security and Privacy</t>
</list>
</t>
<t>The goals of the workshop can be summarized as follows:
<list style="empty">
<t>As many deployed smart objects demonstrate, running protocols like the Internet Protocol Version 4 <xref target="RFC0791"/> and Version 6 <xref target="RFC2460"/>, the User Datagram Protocol (UDP) <xref target="RFC0768"/>, the Transmission Control Protocol (TCP) <xref target="RFC0793"/>, the Hypertext Transfer Protocol (HTTP) <xref target="RFC2616"/>, etc., on constrained devices is clearly possible. Still, protocol designers, system architects and developers have to keep various limitations in mind. The organizers were interested to discuss the experience with deploying IETF protocols in different constrained environments.</t>
<t>
Furthermore, the organizers were seeking to identify either issues where current implementers do not yet have solutions or where researchers predict potential issues.
</t>
<t>
The workshop served as a venue to identify problems and to discover common interests that may turn into new work or into changes in direction of already ongoing work at the IETF and or the Internet Research Task Force (IRTF).
</t>
</list>
</t>
</section>
<!-- ******************************************************************************** -->
<section anchor="constraint" title="Constrained Nodes and Networks">
<t>
The workshop was spurred by the increasing presence of constrained devices on the network. It is quite natural to ask how these limitations impact the design of the affected nodes. Note that not all nodes suffer from the same set of limitations.
</t>
<t><list style="hanging">
<t hangText="Energy constraints:"><vspace blankLines="1"/>
Since wireless communication can be a large portion of the power-budget for wireless devices, reducing unnecessary communication can significantly increase the battery life of a low-end device. The choice of low-power radio can also significantly impact the overall energy consumption, as can sleeping periodically, when the device is not in use. In some cases, these nodes will only wake periodically to handle needed communications. This constraint is quite in contrast to the “always on” paradigm found in regular Internet hosts. Even in the case of non-battery operated devices, power is a constraint with respect to energy efficiency goals.</t>
<t hangText="Bandwidth constraints:"><vspace blankLines="1"/>
Various low power radio networks offer only ~100 kbit/s or even only a few KBits/s, and show high packet loss as well as high link quality variability. Nodes may be used in usually highly unstable radio environments. The physical layer packet size may be limited (~100 bytes).</t>
<t hangText="Memory constraints:"><vspace blankLines="1"/>The amount of volatile and persistent storage impacts the program execution has important implications for the functionality of the protocol stack. The Arduino UNO board, for example, provides a developer with 2 KByte RAM and 32 KByte flash memory (without any extensions, such as microSD cards).</t>
</list>
</t>
<t>A system designer also needs to consider CPU constraints, which often relate to energy constraints: a processor with lower performance consumes less energy. As described later in this document, the design of the mainboard may allow certain components to be put to sleep to further lower energy consumption. In general, embedded systems are often purpose built with only the hardware components needed for the given task while general purpose personal computers are less constrained with regard to their mainboard layout and typically offer a huge number of optional plug-in peripherals to be connected. A factor that also has to be taken into consideration is the intended usage environment. For example, a humidity sensor deployed outside a building may need to deal with temperatures from -50 C to +85 C.
There are often physical size limitations for smart objects. While traditional mainboards are rather large, such as the Advanced Technology eXtended (ATX) design with a board size of 305 × 244 mm available in many PCs or the mini-ITX design typically found in home theater PCs with 170 × 170 mm, mainboard layouts for embedded systems are typically much smaller, such as the CoreExpress layout with 58 × 65 mm, or even smaller. In addition to the plain mainboard additional sensors, peripherals, a power adapter/battery, and a case have to be taken into consideration. Finally, there are cost restrictions as well.
</t>
<t>
The situation becomes more challenging when not only the hosts are constrained but also the network nodes themselves.
</t>
<t>While there are constantly improvements being made, Moore's law tends to
be less effective in the embedded system space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power.
</t>
</section>
<!-- ******************************************************************************** -->
<section title="Workshop Structure">
<t>With the ongoing work on connecting smart objects to the Internet there are many challenges the workshop participants raised in more than 70 accepted position papers. With a single workshop day discussions had to be focused and priority was given to those topics that had been raised by many authors. A summary of the identified issues are captured in the subsections below.</t>
<section title="Architecture">
<t>A number of architectural questions were brought up in the workshop. This is natural, as the architectural choices affect the required technical solutions and the need for standards. At this workshop questions regarding the separation of traffic, the need for profiling for application specific domains, the demand for data model specific standardization, as well as the design choices of the layer at which functionality should be put were discussed and are briefly summarized below. </t>
<section title="One Internet vs. Islands">
<t>Devices that used to be in proprietary or application-specific networks are today migrating to IP networks.
There is, however, the question of whether these smart objects are now on the same IP network as any other application. Controlled applications, like the fountains in front of the Bellagio hotel in Las Vegas that are operated as a distributed control system <xref target="Dolin"/>, probably are not exchanging their control messages over the same network that is also used by hotel guests for their Internet traffic. The same had been argued for smart grids, which are described as "A smart grid is a digitally enabled electrical grid that gathers, distributes, and acts on information about the behavior of all participants (suppliers and consumers) in order to improve the efficiency, reliability, economics, and sustainability of electricity services." <xref target="SmartGrid"/>. The question that was raised during the workshop is therefore in what sense are we talking about one Internet or about using IP technology for a separate, walled garden network that is independent of the Internet?</t>
<t>Cullen Jennings compared the current state of smart object deployment with the evolution of voice-over-IP: "Initially, many vendors recommended to run VoIP over a separate VLAN or a separate infrastructure. Nobody could imagine how to make the type of real-time guarantees, how to debug it, and how to get it to work because the Internet is not ideally suited for making any types of guarantees for real-time systems. As time went on people got better at making voice work across that type of IP network. They suddenly noticed that having voice running on a separate virtual network than their other applications was a disaster. They couldn't decide if a PC was running a softphone and whether it went on a voice or a data network. At that point people realized that they needed a converged network and all moved to one. I wouldn't be surprised to see the same happens here. Initially, we will see very separated networks. Then, those will be running over the same hardware to take advantage of the cost benefits of not having to deploy multiple sets of wires around buildings. Over time there will be strong needs to directly communicate with each other. We need to be designing the system for the long run. Assume everything will end up on the same network even if you initially plan to run it in separate networks."</t>
<t>It is clearly possible to let sensors in a building communicate through the wireless access points and through the same infrastructure used for Internet access, if you want to. Those who want separation at the physical layer can do so as well. What is important is to make sure that these different deployment philosophies do not force loss of interoperability.</t>
<t>The level of interoperability that IP accomplished fostered innovation at the application layer. Ralph Droms reinforced this message by saying: "Bright people will take a phone, build an application and connect it, with the appropriate security controls in place, to the things in my house in ways we have never thought about before. Otherwise we are just building another telephone network."</t>
</section>
<section title="Domain Specific Stacks and Profiles">
<t>Imagine a building network scenario where a new light bulb is installed that should, out of the box without further configuration, interoperate with the already present light switch from a different vendor in the room. For many this is the desired level of interoperability in the area of smart object design. To accomplish this level of interoperability it is not sufficient to provide interoperability only at the network layer. Even running the same transport protocol and application layer protocol (e.g., HTTP) is insufficient since both devices need to understand the semantics of the payloads for "Turn the light on" as well.</t>
<t>Standardizing the entire protocol stack for this specific "light switch/light bulb" scenario is possible. A possible stack would, for example, use IPv6 with a specific address configuration mechanism (such as stateless address autoconfiguration), a network access authentication security mechanism such as Protocol for carrying Authentication for Network Access (PANA) <xref target="RFC5191"/>, a service discovery mechanism (e.g., multicast DNS with DNS-SD <xref target="I-D.cheshire-dnsext-dns-sd"/>), an application layer protocol, for example, Constrained Application Protocol (CoAP) <xref target="I-D.ietf-core-coap"/> (which uses UDP), and the syntax and semantic for the light on/off functionality.</t>
<t>As this list shows there is already some amount of protocol functionality that has to be agreed on by various stakeholders to make this scenario work seamlessly. As we approach more complex protocol interactions the functionality quickly becomes more complex: IPv4 and IPv6 on the network layer, various options at the transport layer (such as UDP, TCP, the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/>, and the Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"/>), and there are plenty of choices at the application layer with respect to communication protocols, data formats and data models. Different requirements have led to the development of a variety of communication protocols: client-server protocols in the style of the original HTTP, publish-subscribe protocols (like Session Initiation Protocol (SIP) <xref target="RFC3261"/> or Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC3921"/>), store-and-forward messaging (borrowed from the delay tolerant networking community). Along with the different application layer communication protocols come various identity and security mechanisms.</t>
<t>With the smart object constraints it feels natural to develop these stacks since each application domain (e.g., health-care, smart grids, building networking) will have their unique requirements and their own community involved in the design process. How likely are these profiles going to be the right match for the future, specifically for the new innovations that will come? How many of these stacks are we going to have? Will the differences in the profiles purely be the result of different requirements coming from the individual application domains or will these mismatches reflect the spirit, understanding and preferences of the community designing them? How many stacks will multi-purpose devices have to implement?</t>
<t>Standardizing profiles independently for each application is not the only option. Another option is to let many different applications utilize a common foundation, i.e., a protocol stack that is implemented and utilized by every device. This, however, requires various application domains to be analyzed for their common characteristics and to identify requirements that are common across all of them. The level of difficulty for finding an agreement of how such a foundation stack should look depends on how many layers it covers and how lightweight it has to be.</t>
<t>From the discussions at the workshop it was clear that the available options are not ideal and further discussions are needed.</t>
</section>
<section title="Which Layer?">
<t>The end-to-end principle states that functionality should be put into the end points instead of into the networks. An additional recommendation, which is equally important, is to put functionality higher up in the protocol stack. While it is useful to make common functionality available as building blocks to higher layers the wide range of requirements by different applications led to a model where lower layers provide only very basic functionality and more sophisticated features were made available by various applications. Still, there has been the desire to put application layer functionality into the lower layers of the networking stack. A common belief is that performance benefits can be gained if functionality is placed at the lower layers of the protocol stack. This new functionality may be offered in the form of a gateway, which bridges different communication technologies, acts on behalf of other nodes, and offers more generic functionality (such as name-based routing and caching).</t>
<t>Two examples of functionality offered at the network layer discussed during the workshops were location and name-based routing:
<list style="hanging">
<t hangText="Location:"><vspace blankLines="1"/> The notion of location gives each network node the understanding of proximity (e.g., 'I am a light bulb and in the same room as the light switch.'). Today, a router may provide information as to whether other nodes belong to the same subnet or they may provide location information (for example, in the form of GPS based coordinates). However, providing a sense of the specific environment (e.g., a room, building, campus, etc.) is not possible without manual configuration. While it has been a desirable feature for many ubiquitous computing applications to know this type of information and to use it for richer application layer interactions, widespread deployment has not happened yet.
<vspace blankLines="1"/> </t>
<t hangText="Name-based Routing:"><vspace blankLines="1"/>
With the work on recent clean slate architecture proposals, such as named data networking, flexible naming concepts are being researched to allow application developers to express their application layer concepts in a way that they can be used natively by the underlying networking stack without translation. For example, Jeff Burke provided the example of his work in a theater with a distributed control system of technical equipment (such as projectors, dimmers, and light systems). Application developers name their equipment with human readable identifiers, which may change after the end of a rehearsal, and address them using these names. These variable length based naming concepts raise questions regarding scalability.</t>
</list>
</t>
<t>The workshop participants were not able to come to an agreement about what functionality should be moved from the application layer to the network layer.</t>
</section>
</section>
<section title="Sleeping Nodes">
<t>One limitation of smart objects is their available energy. To extend
battery life, for example of a watch battery or single AAA battery
for months, these low power devices have to sleep 99% to
99.5% of their time. For example, a light sensor may only wake up
to check whether it is night-time to turn on light bulbs.
Most parts of
the system, particularly communication components, are put into a
sleeping state (e.g., WLAN radio interface) and selected components,
such as sensors, periodically check for relevant events
and, if necessary, turn on other hardware modules. Every bit
is precious, as is every round trip, and every millisecond of radio
activity.
</t>
<t>
Many IETF protocols are implicitly designed to be always-on, i.e.,
the protocol implementation waits for and reacts to incoming messages, and
may maintain session state (at various layers of the stack). These
protocols work well when energy consumption is not a concern and
where receiving and sending messages happens at a low cost.
It should
be understood that energy is consumed both in transmitting
messages (and often more importantly) in keeping the receiver
awake. Allowing devices to sleep most of the time preserves energy but creates
challenges for protocol designs.
</t>
<t>The inherent issue encountered by a stationary node resuming from
sleep is that another node may have chosen the same address while
the node was asleep. A number of steps have to be taken before sending
a packet. A new address may have to be obtained, for example using the
Dynamic Host Configuration Protocol (DHCP) or stateless
address autoconfiguration. Optionally, Detecting Network Attachment (DNA)
procedures (see <xref target="RFC4436"/> and <xref target="RFC6059"/>) can be used to
shorten the setup time by noticing that the node is using the same
default gateway.
</t>
<t>
The issue with a mobile node that is sleeping is that the node may
have been moved to another network (e.g., a sleeping laptop being
transported to a new environment) where on resumption it may discover
that its address has become invalid.
</t>
<t>The following design considerations should be taken into account when
energy efficiency is a concern:
<list style="numbers">
<t>Rethink the Always-On Assumption<vspace blankLines="1"/>
When designing a protocol that assumes that the nodes are always
on, alternatives need to be considered. This could involve
eliminating functionality (e.g., not implementing DNA or duplicate
address detection) or considering the use of a sleep proxy.
While sleep proxies (e.g., proxZzzy <xref target="proxZzzy"/>) enable periodic messages
to be sent on behalf of sleeping nodes, this approach assumes that
that energy management constraints do not apply to the sleep proxy,
which may not always be the case (e.g., if the entire network is
deployed in the field without access to power). Yet another option
is for devices to explicitly communicate sleep cycles so that they
can only check for messages periodically (be it measured in msec,
sec, or hours). This is the approach taken in IEEE 802.11, which
supports multiple energy conservation mechanisms designed to enable
a station to spend a large fraction of the time sleeping.
</t>
<t>Reduce Network Attachment Costs<vspace blankLines="1"/>
As noted above, the procedures for obtaining an address and
assuring its uniqueness can be costly. In a network where
nodes spend a large fraction of the time sleeping, but are
not necessarily mobile, are all of these procedures really
necessary?<vspace blankLines="1"/>
Can we find ways to reduce the number of protocol interactions
without sacrificing correctness? The main focus of past
investigations has been on IPv6 and neighbor discovery but other protocols do
also deserve a deeper investigation, such as DNS, and DHCP.
</t>
<t>Avoid Verbose Protocols<vspace blankLines="1"/>
Protocols involving multiple roundtrips and/or
lengthy messages with verbose encodings (e.g., XML) are not always well
suited for constrained environments. Low-power nodes utilizing
verbose protocols have to use more energy in sending messages and
have to stay powered on for a longer period of time as they wait
for the multi-roundtrip protocol exchanges to complete.
<vspace blankLines="1"/>
The best way to address these problems is to ensure
that the simplest possible protocol exchanges are used when the
protocols in question are designed. In some cases
alternative encoding formats and compression may also help.
</t>
<t>Think about System-Wide Efficiency<vspace blankLines="1"/>
While energy efficiency is critical for low-power devices running on
batteries, it is also beneficial for other devices
as well, including notebooks, desktops and smartphones. However,
if the goal is energy efficiency as opposed to battery life
extension for low-power devices, then it is important to consider
the total energy consumption of all the elements of the system.
<vspace blankLines="1"/>
For example, consider energy consumption in a home environment.
In these scenarios it is important to evaluate the energy usage
of the entire system. A light bulb utilizing Internet technology
described in this document may use less power but
there is also the device that controls the bulb that may consume
a lot of energy. If the goal is to reduce overall energy usage,
then it is important to consider these two devices (and potentially
many others) together.
</t>
</list>
</t>
</section>
<section anchor="security" title="Security">
<t>In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 <xref target="RFC3552"/>, and RFC 4101 <xref target="RFC4101"/>, apply also to the smart object space.</t>
<t>While there are additional constraints, as described in <xref target="constraint"/>, security has to be a mandatory part of the solution. The hope is that this will lead to implementations that provide security features, deployments that utilize these, and finally that this leads to use of better security mechanisms. It is important to point out that the lack of direct user interaction will place hard requirements on deployment models, configuration mechanisms, and software upgrade/crypto agility mechanisms. <!-- Today, IETF protocols offer ways to enhance existing algorithms with new cryptographic primitives to allow swapping an old algorithm against a new one. This flexibility often also comes hand-in-hand with a more comprehensive authentication and key exchange framework that allows negotiation of pluggable mechanisms and therefore enables a single application to be used in environments with diverse security requirements. An example of such an flexible framework is offered with the Extensible Authentication Protocol (EAP) - RFC 3748 <xref target="RFC3748"/>, the Simple Authentication and Security Layer (SASL) - RFC 2222 <xref target="RFC2222"/>, or the Generic Security Service Application Program Interface (GSS-API) - RFC2743 <xref target="RFC2743"/>. -->
</t>
<t>Since many of the security mechanisms allow for customization, particularly with regard to the cryptographic primitives utilized, many believe that IETF security solutions are usable without modifications in a large part of the smart object domain. Others call for new work on cryptographic primitives that make use of a single primitive (such as the Advanced Encryption Standard (AES) <xref target="AES"/>) as a building block for all cryptographic functions with the benefit of a smaller footprint of the overall solution, specifically with respect to hardware limitations (e.g., the hardware architecture of certain embedded devices prevents pipelining from being used). In the excitement for new work on optimizations of cryptograhpic primitives other factors have to be taken into consideration that influence successful deployment, such as widespread support in libraries, as well as intellectual property rights (IPR). As an example of the latter aspect, the struggle of Elliptic Curve Cryptography (ECC)-based cryptographic algorithms <xref target="ECC"/> to find deployment can partially be attributed to its IPR situation. The reuse of libraries providing cryptographic functions is clearly an important way to use available memory resources in a more efficient way. To deal with the performance and footprint concerns investigations into offloading certain resource-hungry functions to parties that possess more cryptographic power have been considered. For example, the ability to delegate certificate validation to servers has been standardized in the IETF before; for the support of the Online Certificate Status Protocol (OCSP) in the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Layer Security (TLS), see <xref target="RFC4806"/> and <xref target="RFC3546"/>, respectively.
</t>
<t>Focusing only on the cryptographic primitives would be shortsighted; many would argue that this is the easy part of a smart object security solution. Key management and credential enrollment, however, are considered a big challenge by many particularly when usability requirements have to be taken into account. Another group
of challenges concern privacy; with smart grids, for example, some have voiced concerns
regarding the ability of third parties to keep track of an individual's energy consumption (and
draw associated conclusions). As another example, it is easy to see how a scale that is connected to the Internet for uploading weight information to a social network could lead to privacy concerns. While security mechanisms used to offer protection of the communication between different parties also provide a certain degree of privacy protection they are clearly not enough to address all concerns. Even with the best communication security and access control mechanisms in place one still needs additional safeguards against the concerns mentioned in the examples.</t>
<t>While a lot can be said about how desirable it would be to deploy more security protocols on the entire Internet, practical considerations regarding usability and the incentives of the stakeholders involved have often lead to slower adoption.</t>
</section>
<section title="Routing">
<t>A smart object network environment may also employ routers under similar constraints as the end devices. Currently two approaches to routing in these low power and lossy networks are under consideration, namely mesh-under and route-over. The so-called mesh-under approach places routing functions at the link layer and consequently all devices appear as immediate neighbors at the network layer. With the route-over approach routing is done at the IP layer and none in the link layer. Each physical hop appears as a single IP hop (ignoring devices that just extend the physical range of signaling, such as repeaters). Routing in this context means running a routing protocol. IPv6 Routing Protocol for Low power and Lossy Networks (RPL) <xref target="I-D.ietf-roll-rpl"/>, for example, belongs to the route-over category. <!-- Trill is an example of a mesh-under approach. -->
</t>
<t>From an architectural point of view there are several questions that arise from where routing is provided, for example:
<list style="symbols">
<t>Protocols often assume that link characteristics are predictable when communicating with any device attached to the same link. Latency, throughput, and reliability may vary considerably between different devices that are multiple link layer hops away. What timeout should be used? What happens if a device is unreachable? In case of default router selection two advertised routers may be a different number of hops away. Should a device have visibility into the path to make a decision and what path characteristics would be useful to have?</t>
<t>Scoped message delivery to a neighboring IP hop (via link-local addressing) allows certain types of IP protocols to communicate with their immediate neighbors and to therefore scope their recipients. A link-local multicast message will be received by all nodes in the same IP link local realm unless some special optimizations are provided by the link layer.</t>
<t>When path computations are done at the link layer as well as on the network layer then what coordination needs to take place? </t>
</list>
</t>
<t>When multiple different link layer technologies are involved in a network design, routing at layer 3 has to be provided in any case. <xref target="I-D.routing-architecture-iot"/> talks about these tradeoffs between route-over and mesh-under in detail. Furthermore, those who decide about the deployment have to determine how to connect smart objects to the Internet infrastructure and a number of wired and wireless technologies may be suitable for a specific deployment. Depending on the chosen technologies the above-mentioned mesh-under vs. route-over approach will have to be decided and further decisions will have to be made about the choice of a specific routing protocol.</t>
<t>
In 2008 the IETF formed the Routing Over Low power and Lossy networks (ROLL) working group to specify a routing solution for smart object environments. During its first year of existence, the working group studied routing requirements in detail (see <xref target="RFC5867"/>, <xref target="RFC5826"/>, <xref target="RFC5673"/>, <xref target="RFC5548"/>), worked on a protocol survey comparing a number of existing routing protocols, including Ad hoc On-Demand Distance Vector (AODV)-style of protocols <xref target="RFC3561"/>, against the identified requirements. The protocol survey <xref target="I-D.ietf-roll-protocols-survey"/> was inconclusive and abandoned without giving rise to publication of
an RFC.</t>
<t>The ROLL WG concluded that a new routing protocol satisfying the documented requirements has to be developed and the work on the RPL was started as the IETF routing protocol for smart object networks. Nevertheless, controversial discussions at the workshop about which routing protocols is best in a given environment are still ongoing. Thomas Clausen, for example, argued for using an AODV-like routing protocol in <xref target="Clausen"/>.</t>
</section>
</section>
<!--
Quotes:
- Everything that benefits from networking will eventually be networked.
- Not a future thing – we're already there. Scale, toaster, laundry that sends messages.
More an evolutation. We don't need to change the entire internet to connect things.
Use lots of basic technology. There are still a bunch of new things: RPL, CoAP, new link layers, ...
Many applications being developed out - largely
Why is there an interoperability challenge: Perceived capability mismatch / processing / bandwidth
No human involved - not just displaying something. We need to agree on semantics.
Interworking challenges when interfacing legacy technology
Certain solutions only optimized for one type of network
Capability differences: MTU different, entire protocol stack is different.
dual stack in PCs today.
Devices sleeping most of the time. You cannot talk to them all the time.
We may not be able to implement all the security protocols.
Are there true capability differences? Did we create these capability differences ourselfs by developing a set of incompatible standards?
Semantical differences: light bulb & switch. IP as transport network is not the full interoperable IoT. Just having this would not allow the bulb and the switch to work together. define on=1 and off=2. other options possible as well.
What is the right approach?
Authorization problems may prevent different devices from working together. Imagine different devices using different trust anchors.
Dedicated domains solutions: Specific solution that works fine in a specific environment (with certain low power requirements).
If we have multiple different applications how do we make sure that these work in the same network.
Example: RPL using different modes
Where should the application standards (including data formats) to be developed?
How do we create "freedom" into the architecture?
Internet became successful not because it was extremely optimized for the hardware at that time. Instead, it was scalable, it was usable and easy to use.
What are the success criteria here? Probably not the optimizations. More useful to have a general version.
Jari: Gateway's required
Ralph: Do we really need this?
Jari: Fundamentally required. If you have a sensor that is only aware one seconds a day.
-->
<!-- ******************************************************************************** -->
<section title="Conclusions and Next Steps">
<!--
<t>In drawing conclusions from this workshop it is useful to look back at the criteria for success of the Internet. Previous IAB publications provide valuable insight into the history and many of the statements are still very much applicable today and to the discussion on smart objects as well.</t>
<t>RFC 1958 says: "The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan."</t>
<t>"A good analogy for the development of the Internet is that of constantly renewing the individual streets and buildings of a city, rather than razing the city and rebuilding it.” It is difficult to resist the temptation to re-design everything from scratch and not to worry about incremental deployability. We see the attempt for re-design in many places; sometimes only at the marketing level but often also in ignorance of what had been developed in the past. </t>
<t>RFC 1958 also states that "... the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.” This statement is challenged more than ever with the perceived need to develop clever intermediaries interacting with dump end devices but we have to keep in mind what RFC 3724 has to say about this crutial aspect: "One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes.” RFC 4924 adds that a network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet’s most essential characteristic as well as one of the most important contributors to its success. </t>
-->
<t>The workshop allowed the participants to get exposed to interesting applications and their requirements (buildings, fountains, theater, etc.), to have discussions about radically different architectures and their issues (e.g., information centric networking), to look at existing technology from a new angle (sleeping nodes, energy consumption), to focus on some details of the protocol stack (neighbor discovery, security, routing) and to learn about implementation experience. </t>
<t>One goal of the workshop was to identify areas that require further investigation. The list below reflects the thoughts of the workshop participants as expressed on the day of the workshop. Note that the suggested items concern potential work by the IETF and the IRTF and the order does not imply a particular preference.</t>
<t> <list style="hanging">
<t hangText="Security:"><vspace blankLines="1"/>
A discussion of security is provided in <xref target="security"/>. In general, security related protocol exchanges and the required amount of computational resource requirements can contribute significantly to the overall processing. Therefore, it remains a challenge to accomplish performance improvements without sacrificing the overall security level, taking the usability of the entire system into consideration.
<vspace blankLines="1"/>
Another challenge is how to balance the security and
performance needs of smart objects with the interoperability
requirements of hosts on the Internet since different suites
of algorithms may tend to be chosen for these different
environments. This involves trade-offs between performance on
the smart objects versus end-to-end security. Solutions
that mandate a "trusted" middlebox whose only role is to
terminate security associations tend to be frowned upon
from the security perspective, especially since end-users of
challenged devices (where those exist) are unlikely to
understand the security consequences of such middleboxes.
<vspace blankLines="1"/>
The discussion concluded with the following recommendations:
<list style="symbols">
<t>Investigate usability in cryptographic protocol design with regard to credential management. As an example, the Bluetooth pairing mechanism was mentioned as a simple and yet reasonably secure method of introducing devices into a new environment. In fact, the IETF working group 'Credential and Provisioning (ENROLL)' was established years ago to deal with residential networks but was terminated prematurely due to lack of progress. The email archive still exists and is available <xref target="enroll"/> and may provide useful historical information.</t>
<t>Standardized authentication and key exchange mechanisms should be surveyed for suitability in smart object environments with respect to message size, computational performance, number of messages, codesize, and main memory requirements. A starting point of such an investigation (in case of IKEv2) was provided by Tero Kivinen with <xref target="I-D.kivinen-ipsecme-ikev2-minimal"/> and a suitable venue for discussion could be the recently established Light-Weight Implementation Guidance (LWIG) working group <xref target="LWIG"/>.</t>
<t>Research has to be done in the area of lightweight cryptographic primitives, namely block ciphers, stream ciphers, and cryptographic hash functions. Worthwhile to mention is early work with the National Institute of Standards and Technology (NIST) new cryptographic hash algorithm 'SHA-3' competition <xref target="SHA3"/>. A suitable forum for discussion is the IRTF Crypto Forum Research Group (CFRG) <xref target="CFRG"/>.</t>
</list>
The difficulty and impact of choosing specialised algorithms for
smart objects should not be underestimated. Issues that arise
include the additional specification complexity (e.g., TLS already
has 100's of ciphersuites defined, most of which are unused in
practice), the long latency in terms of roll out (many hosts are
still using deprecated algorithms 5-10 years after those algorithms
were deprecated) and the barriers that IPR-encumbered schemes
present to widespread deployment. While research on this topic
within CFRG and the cryptographic research community is a very
worthwhile goal, any such algorithms will likely have to offer
very significant benefits before they will be broadly adopted.
20% less CPU is unlikely to be a winning argument no matter what
an algorithm inventor believes.
</t>
<t hangText="Energy Design Considerations:"><vspace blankLines="1"/>
One part of the workshop was focused on the discussion of energy implications for IETF protocol design with proposals being made about how to extend protocols to better support nodes that are mostly sleeping. Discussion are encouraged to take place at the RECIPE mailing list <xref target="RECIPE"/>. The workshop position paper <xref target="Wasserman"/> by Margaret Wasserman provides a good starting point for further investigations.</t>
<t hangText="Information/Content Centric Networking:"><vspace blankLines="1"/>
Information/Content Centric Networking is about accessing named content and a number of research projects have emerged around this theme. At this point in time the work is not yet ready for standardization in the IETF. Instead, the formation of an IRTF research group has been proposed and more details are available on the IRTF DISCUSS mailing list <xref target="irtf-discuss"/>.
</t>
<t hangText="Architectural Guidelines:"><vspace blankLines="1"/>
Participants suggested developing an architectural write-up about what can be done with the IETF protocols we have today and how these different elements may be combined to offer an explanation for the broader community. This would be a task for the Internet Architecture Board (IAB). An example of prior work that serves as input is <xref target="RFC6272"/>.</t>
<t hangText="Network Management:"><vspace blankLines="1"/>
While this topic did not make it onto the workshop agenda it was considered useful to start a discussion about how to implement network management protocols, such as Network Configuration Protocol (NETCONF) <xref target="RFC6241"/>, on smart objects. The following position papers may be useful as a starting point for further discussions <xref target="Ersue"/>, <xref target="Schoenwaelde"/>. An IETF draft is also available <xref target="I-D.hamid-6lowpan-snmp-optimizations"/>.</t>
<t hangText="Congestion Control:"><vspace blankLines="1"/>
When smart objects transmit sensor readings to some server on the Internet then these protocol interactions often carry a small amount of data and happen infrequently, although regularly. With the work on new application protocols, like the CoAP <xref target="I-D.ietf-core-coap"/>, the question of whether a congestion control mechanism should be used at the underlying transport protocol or by the application protocol itself arises. <xref target="I-D.eggert-core-congestion-control"/> is a starting point for the CoAP protocol but further work is needed.</t>
<t hangText="Data Models:"><vspace blankLines="1"/>
Standardization of application layer protocols is important but does not ensure that, for example, a light switch and a light bulb are able to interact with each other. One area where participants saw the need for further work was in the area of data models. While prior IETF standardization work on, for example, location <xref target="GEOPRIV"/> can be re-used the question was raised where the IETF should focus its standardization efforts since domain expertise in each area will be needed. As a potential example, energy pricing was discussed, with an example provided by <xref target="I-D.jennings-energy-pricing"/>.</t>
<t hangText="Discovery:"><vspace blankLines="1"/>
Additional extensions to developed discovery protocols (such as mDNS) may be needed for the smart object environment.</t>
<t hangText="Building Networking:"> <vspace blankLines="1"/>
Network architectures in residential as well as commercial buildings should take the presence of
smart objects and dedicated subnetworks focusing on smart objects into account. A new working group, Home Networking (HOMENET) <xref target="FUN"/>, has been created after the workshop to look at this topic.</t>
<t hangText="Routing:"><vspace blankLines="1"/>
Changing radio conditions and link fluctuation may lead to the need for re-numbering. Workshop participants argued that work should be started on the multi-link subnetworks to mitigate this problem, i.e., to extend the notion of a subnet to be able to span multiple links. With the publication of RFC 4903 <xref target="RFC4903"/> the Internet Architecture Board had looked into this topic already and provided pros and cons.
<vspace blankLines="1"/>
The applicability of specific routing protocols designed for smart object networks needs further investigation. The ROLL working group is chartered with the task of constructing an applicability document for the RPL protocol, for instance.
<!--
Layer 3 VLAN is so far only available with specific layer 2 technologies (for example Ethernet but not with Wifi). MPLS on the other hand covers the wide-area network environment. Multi Topology Routing, and RPL provide certain solution attempts but these solutions need to scale. The proposal to generalize the concept and to provide layer 3 VLAN functionality for IPv6 has been made.--></t>
</list>
</t>
</section>
<!-- ******************************************************************************** -->
<section title="Security Considerations">
<t>
The workshop discussions covered a range of potential engineering
activities, each with its own security considerations. As the IETF
community begins to pursue specific avenues arising out of this
workshop, addressing relevant security requirements will be crucial.
</t>
<t>As described in this report part of the agenda was focused on the
discussion of security, see <xref target="security"/>.</t>
</section>
<!-- ******************************************************************************** -->
<section title="Acknowledgements">
<t>We would like to thank all the participants for their position papers.
The authors of the accepted position papers were invited to the workshop.</t>
<t>Big thanks to Elwyn Davies for helping us to fix language bugs. We would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, and Henning Schulzrinne for their review comments.
</t>
<t>Additionally, we would like to thank Ericsson and Nokia Siemens Networks for their financial support.</t>
</section>
<!-- ******************************************************************************** -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ******************************************************************************** -->
</middle>
<back>
<!-- <references title="Normative References">
</references>
-->
<references title="Informative References">
&RFC5582; &RFC3552; &RFC4101; &RFC3748; &RFC2743; &RFC2222;
&RFC4903;
&RFC6272; &I-D.kivinen-ipsecme-ikev2-minimal;
&I-D.hamid-6lowpan-snmp-optimizations; &I-D.eggert-core-congestion-control;
&I-D.jennings-energy-pricing; &I-D.ietf-core-coap;
&I-D.ietf-roll-rpl; &RFC3561; &I-D.routing-architecture-iot;
&RFC5867; &RFC5826; &RFC5673; &RFC5548; &I-D.ietf-roll-protocols-survey;
<reference anchor="CFRG">
<front>
<title>IRTF Crypto Forum Research Group (CFRG)</title>
<author initials="D." surname="McGrew (Chair)" fullname="David McGrew (Chair)">
<organization/>
</author>
<date month="June" day="11" year="2011"/>
</front>
<seriesInfo name="http://irtf.org/cfrg"
value=""/>
<format type="HTML" target="http://irtf.org/cfrg"/>
</reference>
<reference anchor="LWIG">
<front>
<title>IETF Light-Weight Implementation Guidance (LWIG) Working Group </title>
<author>
<organization/>
</author>
<date month="June" day="11" year="2011"/>
</front>
<seriesInfo name="http://datatracker.ietf.org/wg/lwig/charter/"
value=""/>
<format type="HTML" target="http://datatracker.ietf.org/wg/lwig/charter/"/>
</reference>
<reference anchor="enroll">
<front>
<title>IETF Credential and Provisioning Working Group Mailing List </title>
<author>
<organization/>
</author>
<date month="June" day="11" year="2011"/>
</front>
<seriesInfo name="http://mailman.mit.edu/pipermail/ietf-enroll/"
value=""/>
<format type="HTML" target="http://mailman.mit.edu/pipermail/ietf-enroll/"/>
</reference>
<reference anchor="RECIPE">
<front>
<title>Reducing Energy Consumption with Internet Protocols Exploration (RECIPE) Mailing List</title>
<author>
<organization/>
</author>
<date month="June" day="11" year="2011"/>
</front>
<seriesInfo name="https://www.ietf.org/mailman/listinfo/recipe"
value=""/>
<format type="HTML" target="https://www.ietf.org/mailman/listinfo/recipe"/>
</reference>
<reference anchor="FUN">
<front>
<title>FUture home Networking (FUN) Mailing List</title>
<author>
<organization/>
</author>
<date month="June" day="30" year="2011"/>
</front>
<seriesInfo name="https://www.ietf.org/mailman/listinfo/fun"
value=""/>
<format type="HTML" target="https://www.ietf.org/mailman/listinfo/fun"/>
</reference>
<reference anchor="GEOPRIV">
<front>
<title>IETF Geographic Location/Privacy Working Group</title>
<author>
<organization/>
</author>
<date month="June" day="11" year="2011"/>
</front>
<seriesInfo name="http://datatracker.ietf.org/wg/geopriv/"
value=""/>
<format type="HTML" target="http://datatracker.ietf.org/wg/geopriv/"/>
</reference>
<reference anchor="Ersue">
<front>
<title>Ersue / Korhonen Smart Object Workshop Position Paper </title>
<author initials="M." surname="Ersue" fullname="Mehmet Ersue">
<organization/>
</author>
<author initials="J." surname="Korhonen" fullname="Jouni Korhonen">
<organization/>
</author>
<date month="March" day="25" year="2011"/>
</front>
<seriesInfo name="IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic,"
value="http://www.iab.org/wp-content/IAB-uploads/2011/03/Ersue.pdf"/>
<format type="PDF" target="http://www.iab.org/wp-content/IAB-uploads/2011/03/Ersue.pdf"/>
</reference>
<reference anchor="Dolin">
<front>
<title>Application Communications Requirements for ‘The Internet of Things’</title>
<author initials="B." surname="Dolin" fullname="Bob Dolin">
<organization/>
</author>
<date month="March" day="25" year="2011"/>
</front>
<seriesInfo name="IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic,"
value="http://www.iab.org/wp-content/IAB-uploads/2011/03/Ersue.pdf"/>
<format type="PDF" target="http://www.iab.org/wp-content/IAB-uploads/2011/03/Dolin.pdf"/>
</reference>
<reference anchor="Clausen">
<front>
<title>Some Considerations on Routing in Particular and Lossy Environments</title>
<author initials="T." surname="Clausen" fullname="Thomas Clausen">
<organization/>
</author>
<author initials="U." surname="Herberg" fullname="Ulrich Herberg">
<organization/>
</author>
<date month="March" day="25" year="2011"/>
</front>
<seriesInfo name="IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic,"
value="http://www.iab.org/wp-content/IAB-uploads/2011/03/Clausen.pdf"/>
<format type="PDF" target="http://www.iab.org/wp-content/IAB-uploads/2011/03/Clausen.pdf"/>
</reference>
<reference anchor="Schoenwaelde">
<front>
<title>Protocol Profiles for Constrained Devices</title>
<author initials="J." surname="Schoenwaelde" fullname="Juergen Schoenwaelde">
<organization/>
</author>
<author initials="T." surname="Tsou" fullname="Tina Tsou">
<organization/>
</author>
<author initials="B." surname="Sarikaya" fullname="Behcet Sarikaya">
<organization/>
</author>
<date month="March" day="25" year="2011"/>
</front>
<seriesInfo name="IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic,"
value="http://www.iab.org/wp-content/IAB-uploads/2011/03/Schoenwaelder.pdf"/>
<format type="PDF" target="http://www.iab.org/wp-content/IAB-uploads/2011/03/Schoenwaelder.pdf"/>
</reference>
<reference anchor="Wasserman">
<front>
<title>It's Not Easy Being "Green"</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization/>
</author>
<date month="March" day="25" year="2011"/>
</front>
<seriesInfo name="IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic,"
value="http://www.iab.org/wp-content/IAB-uploads/2011/03/Wasserman.pdf"/>
<format type="PDF" target="http://www.iab.org/wp-content/IAB-uploads/2011/03/Wasserman.pdf"/>
</reference>
<reference anchor="Tussle">
<front>
<title>Tussle in Cyberspace: Defining Tomorrow's Internet</title>
<author fullname="David Clark" initials="D." surname="Clark">
</author>
<author fullname="John Wroslawski" initials="J." surname="Wroslawski">
</author>
<author fullname="Karen Sollins" initials="K." surname="Sollins">
</author>
<author fullname="Robert Braden" initials="R." surname="Braden">
</author>
<date year="2002"/>
</front>
<seriesInfo
name="In Proc. ACM SIGCOMM"
value=", http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html"/>
<format target="http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html" type="HTML"/>
</reference>
<reference anchor="irtf-discuss">
<front>
<title>Draft ICN RG Charter on IRTF DISCUSS Mailing List</title>
<author>
<organization/>
</author>
<date month="May" day="23" year="2011"/>
</front>
<seriesInfo name="http://www.ietf.org/mail-archive/web/irtf-discuss/current/msg00041.html"
value=""/>
<format type="HTML" target="http://www.ietf.org/mail-archive/web/irtf-discuss/current/msg00041.html"/>
</reference>
<reference anchor="SmartGrid">
<front>
<title>Wikipedia Entry for 'Smart Grid'</title>
<author>
<organization/>
</author>
<date month="Dec" day="28" year="2011"/>
</front>
<seriesInfo name="http://en.wikipedia.org/wiki/Smart_grid"
value=""/>
<format type="HTML" target="http://en.wikipedia.org/wiki/Smart_grid"/>
</reference>
<reference anchor="AES">
<front>
<title>Wikipedia Entry for 'Advanced Encryption Standard'</title>
<author>
<organization/>
</author>
<date month="Dec" day="28" year="2011"/>
</front>
<seriesInfo name="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard"
value=""/>
<format type="HTML" target="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard"/>
</reference>
<reference anchor="ECC">
<front>
<title>Wikipedia Entry for 'Elliptic Curve Cryptography'</title>
<author>
<organization/>
</author>
<date month="Dec" day="28" year="2011"/>
</front>
<seriesInfo name="http://en.wikipedia.org/wiki/Elliptic_curve_cryptography"
value=""/>
<format type="HTML" target="http://en.wikipedia.org/wiki/Elliptic_curve_cryptography"/>
</reference>
<reference anchor="SHA3">
<front>
<title>NIST Cryptographic Hash Algorithm Competition</title>
<author>
<organization/>
</author>
<date month="Dec" day="28" year="2011"/>
</front>
<seriesInfo name="http://csrc.nist.gov/groups/ST/hash/sha-3/index.html"
value=""/>
<format type="HTML" target="http://csrc.nist.gov/groups/ST/hash/sha-3/index.html"/>
</reference>
<reference anchor="proxZzzy">
<front>
<title>proxZZZyTM for sleeping hosts, ECMA-393</title>
<author>
<organization>ECMA</organization>
</author>
<date month="Feb" year="2010"/>
</front>
<seriesInfo name="http://www.ecma-international.org/publications/standards/Ecma-393.htm"
value=""/>
<format type="HTML" target="http://www.ecma-international.org/publications/standards/Ecma-393.htm"/>
</reference>
&RFC5191;
&I-D.cheshire-dnsext-dns-sd;
&RFC3261;
&RFC3921;
&RFC4436;
&RFC6059;
&RFC3546;
&RFC4806;
&RFC4960;
&RFC4340;
&RFC0768;
&RFC0793;
&RFC0791;
&RFC2460;
&RFC6241;
&RFC2616;
</references>
<section title="Program Committee">
<t>The following persons are responsible for the organization of the associated workshop and are responsible also for this event: Jari Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Jennings, Manfred Hauswirth, and Lukas Kencl.</t>
</section>
<section title="Workshop Materials">
<t>Information about the workshop can be found at the IAB webpage:
http://www.iab.org/about/workshops/smartobjects/
</t>
<t>
The position papers can be retrieved from:
http://www.iab.org/about/workshops/smartobjects/papers/
</t>
<t>
The slides are available for download at the following webpage:
http://www.iab.org/about/workshops/smartobjects/agenda.html
</t>
<t>
Detailed meeting minutes are published here:
http://www.iab.org/about/workshops/smartobjects/minutes.html
</t>
</section>
<section title="Accepted Position Papers">
<t>
<list style="numbers">
<t>Deployment Experience with Low Power Lossy Wireless Sensor Networks
by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. Philipp, and G. Wittenburg
</t>
<t>CoAP improvements to meet embedded device hardware constraints
by Davide Barbieri
</t>
<t> Unified Device Networking Protocols for Smart Objects
by Daniel Barisic and Anton Pfefferseder
</t>
<t> Simplified neighbour cache implementation in RPL/6LoWPAN
by Dominique Barthel
</t>
<t> Home Control in a consumer’s perspective
by Anders Brandt
</t>
<t> Authoring Place-based Experiences with an Internet of Things: Tussles of Expressive, Operational, and Participatory Goals
by Jeff Burke
</t>
<t> A Dynamic Distributed Federated Approach for the Internet of Things
by Diego Casado Mansilla, Juan Ramón Velasco Pérez, and Mario López-Ramos
</t>
<t> Quickly interoperable Internet of Things using simple transparent gateways
by Angelo P. Castellani, Salvatore Loreto, Nicola Bui, and Michele Zorzi
</t>
<t> Position Paper of the Brno University of Technology Department of Telecommunications
by Vladimir Cervenka, Lubomir Mraz, Milan Simek, Karel Pavlata
</t>
<t> Secure Access to IOT Network: An Application-based Group Key Approach
by Samita Chakrabarti, and Wassim Haddad
</t>
<t> Domain-Insulated Autonomous Network Architecture (DIANA)
by W. Chun
</t>
<t> Yet Another Definition on Name, Address, ID, and Locator (YANAIL)
by W. Chun
</t>
<t> The Challenge of Mobility in Low Power Networks
by E. Davies
</t>
<t> If the routing protocol is so smart, why should neighbour discovery be so dumb?
by Nicolas Déjean
</t>
<t> Making Smart Objects IPv6 Ready: Where are we?
by M. Durvy and M. Valente
</t>
<t> Position Paper on “Interconnecting Smart Objects with the Internet”
by Mehmet Ersue, and Jouni Korhonen
</t>
<t> The Real-time Enterprise: IoT-enabled Business Processes
by Stephan Haller, and Carsten Magerkurth
</t>
<t> Making Internet-Connected Objects readily useful
by Manfred Hauswirth, Dennis Pfisterer, Stefan Decker
</t>
<t> Some Considerations on Routing in Particular and Lossy Environments
by Thomas Clausen, and Ulrich Herberg
</t>
<t> A Security Protocol Adaptation Layer for the IP-based Internet of Things
by René Hummen, Tobias Heer, and Klaus Wehrle
</t>
<t> Simplified SIP Approach for the Smart Object
by Ryota Ishibashi, Takumi Ohba, Arata Koike, and Akira Kurokawa
</t>
<t> Mobility support for the small and smart Future Internet devices
by Antonio J. Jara, and Antonio F. G. Skarmeta
</t>
<t> The Need for Efficient Reliable Multicast in Smart Grid Networks
by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk
</t>
<t> Lightweight Cryptography for the Internet of Things
by Masanobu Katagi, and Shiho Moriai
</t>
<t> Thoughts on Reliability in the Internet of Things
by James Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli
</t>
<t> IKEv2 and Smart Objects
by Tero Kivinen
</t>
<t> Position Paper on Thing Name Service (TNS) for the Internet of Things (IoT)
by Ning Kong, and Shuo Shen
</t>
<t> Connecting Smart Objects to Wireless WANs
by Suresh Krishnan
</t>
<t> Towards an Information-Centric Internet with more Things
by D. Kutscher, and S. Farrell
</t>
<t> Application of 6LoWPAN for the Real-Time Positioning of Manufacturing Assets
by Jaacán Martinez and José L. M. Lastra
</t>
<t> Lighting interface to wireless network
by Jaroslav Meduna
</t>
<t> Social-driven Internet of Connected Objects
by Paulo Mendes
</t>
<t> Protocols should go forward that are required by non IP based protocols
by Tsuyoshi Momose
</t>
<t> Web services for Wireless Sensor and Actuator Networks
by Guido Moritz
</t>
<t> Connecting BT-LE sensors to the Internet using Ipv6
by Markus Isomäki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, and Zach Shelby
</t>
<t> Building Networks
by Bruce Nordman
</t>
<t> Issues and Challenges in Provisioning Keys to Smart Objects
by Yoshihiro Ohba, and Subir Das
</t>
<t> Challenges and Solutions of Secure Smart Environments
by Eila Ovaska and Antti Evesti
</t>
<t> Research Experiences about Internetworking Mechanisms to Integrate Embedded Wireless Networks into Traditional Networks
by José F. Martínez, Iván Corredor, and Miguel S. Familiar
</t>
<t> Scalable Video Coding in Networked Environment
by Naeem Ramzan, Tomas Piatrik, and Ebroul Izquierdo
</t>
<t> Challenges in Opportunistic Networking
by Mikko Pitkänen, and Teemu Kärkkäinen
</t>
<t> Position Statement
by Neeli R. Prasad, and Sateesh Addepalli
</t>
<t> A Gateway Architecture for Interconnecting Smart Objects to the Internet
by Akbar Rahman, Dorothy Gellert, Dale Seed
</t>
<t> Routing Challenges and Directions for Smart Objects in Future Internet of Things
by T. A. Ramrekha, E. Panaousis, and C. Politis
</t>
<t> 6LoWPAN Extension for IPsec
by Shahid Raza, Thiemo Voigt, and Utz Roedig
</t>
<t> Connected Vehicle as Smart Object(s)
by Ryuji Wakikawa
</t>
<t> Problem and possible approach of development and operation of Smart Objects
by Shoichi Sakane
</t>
<t> Connecting Passive RFID Tags to the Internet of Things
by Sandra Dominikus, and Joern-Marc Schmidt
</t>
<t> Protocol Profiles for Constrained Devices
by Juergen Schoenwaelde, Tina Tsou, and Behcet Sarikaya
</t>
<t> Multihoming for Sensor Networks
by J. Soininen
</t>
<t> Internet Objects for Building Control
by Peter van der Stok, and Nicolas Riou
</t>
<t> Optimal information placement for Smart Objects
by Shigeya Suzuki
</t>
<t> Multi-National Initiative for Cloud Computing in Health Care (MUNICH)
by Christoph Thuemmler
</t>
<t> The time of the hourglass has elapsed
by Laurent Toutain, Nicolas Montavont, and Dominique Barthel
</t>
<t> Sensor and Actuator Resource Architecture
by Vlasios Tsiatsis, Jan Höller, and Richard Gold
</t>
<t> IT’S NOT EASY BEING “GREEN”
by Margaret Wasserman
</t>
<t> Trustworthy Wireless Industrial Sensor Networks
by Markus Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis Olivereau, and Oualha Nouha
</t>
<t> Interconnecting smart objects through an overlay networking architecture
by Anastasios Zafeiropoulos, Athanassios Liakopoulos and Panagiotis Gouvas
</t>
<t> Building trust among Virtual Interconnecting Smart Objects in the Future Internet
by Theodore Zahariadic, Helen C. Leligou, Panagiotis Trakadas, and Mischa Dohler
</t>
<t> Experience and Challenges of Integrating Smart Devices with the Mobile Internet
by Zhen Cao, and Hui Deng
</t>
<t> The “mesh-under” versus “route over” debate in IP Smart Objects Networks
by JP Vasseur, and Jonathan Hui
</t>
<t> Identification and Authentication of IoT Devices
by Alper Yegin
</t>
<t> Security Challenges For the Internet of Things
by Tim Polk, and Sean Turner
</t>
<t> Application Communications Requirements for ‘The Internet of Things’
by Bob Dolin
</t>
<t> Interoperability Concerns in the Internet of Things
by Jari Arkko
</t>
<t> Privacy in Ubiquitous Computing
by Ivan Gudymenko, and Katrin Borcea-Pfitzmann
</t>
<t> The 10 Laws of Smart Object Security Design
by Hannes Tschofenig, and Bernard Aboba
</t>
<t> Position Paper on “In-Network Object Cloud” Architecture and Design Goals
by Alex Galis, and Stuart Clayman
</t>
<t> Temptations and Difficulties of Protocols for Smart Objects and the Internet
by Alexandru Petrescu
</t>
<t> The Internet of Things – Challenge for a New Architecture from Problems
by Gyu Myoung Lee, and Noel Crespi
</t>
<t> Garrulity and Fluff
by Carsten Bormann, and Klaus Hartke
</t>
</list>
</t>
</section>
<section title="Workshop Participants">
<t>We would like to than the following workshop participants for attending the workshop:
<figure>
<artwork>
<![CDATA[
Adrian Farrel
Akbar Rahman
Alissa Cooper
Alper Yegin
Anastasios Zafeiropoulos
Anders Brandt
Angelo P. Castellani
Antonio F. G. Skarmeta
Antonio Jara
Arvind Ramrekha
Behcet Sarikaya
Bernard Aboba
Bruce Nordman
Carsten Bormann
Cullen Jennings
Daniel Barisic
Dave Thaler
Davide Barbieri
Diego Casado Mansilla
Dirk Kutscher
Dominique Barthel
Dorothy Gellert
Elwyn Davis
Emmanuel Baccelli
Fred Baker
Guido Moritz
Gyu Myoung Lee
Hannes Tschofenig
Hui Deng
Ivan Gudymenko
Jaacan Martinez
Jari Arkko
Jaroslav Meduna
Jeff Burke
Johanna Nieminen
Jonathan Hui
Jonne Soininen
Jouni Korhonen
JP Vasseur
Karel Pavlata
Klaus Hartke
Lars Eggert
Laura Gheorghe
Laurent Toutain
Lukas Kencl
Marcelo Bagnulo
Marco Valente
Margaret Wasserman
Markus Isomaki
Markus Wehner
Masanobu Katagi
Mathilde Durvy
Mehmet Ersue
Mikko Pitkänen
Milan Simek
Neeli R. Prasad
Nicolas Dejean
Ning Kong
Pascal Thubert
Paulo Mendes
Pete Resnick
Peter van der Stok
Ralph Droms
Rene Hummen
Ross Callon
Ruediger Martin
Russ Housley
Ryota Ishibashi
Ryuji Wakikawa
Samita Chakrabarti
Sandra Dominikus
Sean Shen
Sean Turner
Shahid Raza
Shoichi Sakane
Spencer Dawkins
Stephan Haller
Stephen Farrell
Stewart Bryant
Subir Das
Suresh Krishnan
Tea Sang Choi
Tero Kivinen
Theodore Zahariadis
Thomas Clausen
Tim Polk
Tina Tsou
Tsuyoshi Momose
Vladimir Cervenka
Wassim Haddad
Woojik Chun
Zach Shelby
]]>
</artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:30 |