[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6574

Network Working Group                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                                  J. Arkko
Expires: January 12, 2012                                       Ericsson
                                                           July 11, 2011

   Report from the 'Interconnecting Smart Objects with the Internet'
                   Workshop, 25th March 2011, Prague


   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.

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 January 12, 2012.

Copyright Notice

   Copyright (c) 2011 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

Tschofenig & Arkko      Expires January 12, 2012                [Page 1]

Internet-Draft        Smart Object Workshop Report             July 2011

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Constrained Nodes and Networks . . . . . . . . . . . . . . . .  6
   3.  Workshop Structure . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  One Internet vs. Islands . . . . . . . . . . . . . . .  8
       3.1.2.  Domain Specific Stacks and Profiles  . . . . . . . . .  9
       3.1.3.  Which Layer? . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Sleep Modes  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.4.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Program Committee . . . . . . . . . . . . . . . . . . 29
   Appendix B.  Published Workshop Material . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35

Tschofenig & Arkko      Expires January 12, 2012                [Page 2]

Internet-Draft        Smart Object Workshop Report             July 2011

1.  Introduction

   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

   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 between the various end devices, but in
   general end devices participating in the Internet are considered to
   have high performance.

   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.

   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 enabling rich communications services.

   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.

Tschofenig & Arkko      Expires January 12, 2012                [Page 3]

Internet-Draft        Smart Object Workshop Report             July 2011

   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, economical incentives,
   power consumption, usability and security is often difficult, as
   illustrated by Clark, et al. in "Tussle in Cyberspace: Defining
   Tomorrow's Internet".

   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.

   The call for position paper suggested investigating the area of
   integration with the Internet in the following categories:

   o  Scalability

   o  Power efficiency

   o  Interworking between different technologies and network domains

   o  Usability and manageability

   o  Security and Privacy

   The goals of the workshop can be summarized as follows:

      As many deployed smart objects demonstrate running protocols, like
      IP, TCP, UDP, HTTP, etc., on constrained devices is clearly is
      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.

      Furthermore, the organizers were seeking to identify either issues
      where current implementers do not yet have solutions or where
      researchers predict potential issues.

      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).

   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

Tschofenig & Arkko      Expires January 12, 2012                [Page 4]

Internet-Draft        Smart Object Workshop Report             July 2011

   views and positions.

Tschofenig & Arkko      Expires January 12, 2012                [Page 5]

Internet-Draft        Smart Object Workshop Report             July 2011

2.  Constrained Nodes and Networks

   An observation that lead to the scheduling of the workshop was the
   presence of constrained devices that are more and more interconnected
   to the network.  So, 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.

   Energy constraints:

      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 being used also has a lot of impact
      on the overall energy consumption.  Sleeping periodically, and
      often aggressively, when 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 case of non-battery operated
      devices power is a constraint with respect to energy efficiency

   Bandwidth constraints:

      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).

   Memory constraints:

      Despite the overwhelming variety of Internet-connected devices
      that can be found in deployments it may be useful to consider a
      number of classes of constrained memory availability.  For example
      the following classes could be used:

               | Class   | Volatile Storage | Persistent Storage |
               | Class 1 | ~ 10 KByte       | ~ 100 KByte        |
               |         |                  |                    |
               | Class 2 | ~ 50 KByte       | ~ 250 KByte        |

   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

Tschofenig & Arkko      Expires January 12, 2012                [Page 6]

Internet-Draft        Smart Object Workshop Report             July 2011

   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 even.
   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 x 244 mm
   available in many PCs or the mini-ITX design typically found in home
   theater PCs with 170 x 170 mm, mainboard layouts for embedded systems
   are typically much smaller, such as the CoreExpress layout with 58 x
   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.

   The situation becomes more challenging when not only the hosts are
   constrained but also the network nodes themselves.

   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.

Tschofenig & Arkko      Expires January 12, 2012                [Page 7]

Internet-Draft        Smart Object Workshop Report             July 2011

3.  Workshop Structure

   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.

3.1.  Architecture

   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

3.1.1.  One Internet vs. Islands

   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 as well.  Controlled applications,
   like the fountains in front of the Bellagio hotel in Las Vegas which
   are operated as a distributed control system [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 the smart grid as well.  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?

   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

Tschofenig & Arkko      Expires January 12, 2012                [Page 8]

Internet-Draft        Smart Object Workshop Report             July 2011

   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.  Assuming everything will end up on the same network
   even if you initially plan to run it in separate networks."

   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,
   however, important is to make sure that these different deployment
   philosophies do not force loss of interoperability.

   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."

3.1.2.  Domain Specific Stacks and Profiles

   Imagine a home 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 (e.g., TCP) 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.

   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 PANA, a service discovery
   mechanism (multicast DNS with DNS-SD), an application layer protocol,
   for example, Constrained Application Protocol (CoAP) (which uses
   UDP), and the syntax and semantic for the light on/off functionality.

   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:

Tschofenig & Arkko      Expires January 12, 2012                [Page 9]

Internet-Draft        Smart Object Workshop Report             July 2011

   IPv4 and IPv6 on the network layer, various options at the transport
   layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices
   at the application layer with respect to communication protocols,
   data formats and data models.  Different requirements have lead to
   the development of a variety of communication protocols: client-
   server protocols in the style of the original HTTP, publish-subscribe
   protocols (like SIP or XMPP), 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.

   With the smart object constraints it feels natural to develop these
   stacks since each application domain (e.g., health-care, smart grids,
   home 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?

   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 like depends on how many layers
   it covers and how lightweight it has to be.

   From the decisions at the workshop it was clear that the available
   options are not ideal and further discussions are needed.

3.1.3.  Which Layer?

   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 lead 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

Tschofenig & Arkko      Expires January 12, 2012               [Page 10]

Internet-Draft        Smart Object Workshop Report             July 2011

   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).

   Two examples of functionality offered at the network layer discussed
   during the workshops were location, and name-based routing:


      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.

   Name-based Routing:

      With the work on recent clean slate architecture proposals, such
      as the named data networking, flexible naming concepts are being
      researched to allow application developer 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.

   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.

3.2.  Sleep Modes

   One limitation of smart objects is the available energy.  To extend
   battery life, for example of a watch battery or single AAA battery

Tschofenig & Arkko      Expires January 12, 2012               [Page 11]

Internet-Draft        Smart Object Workshop Report             July 2011

   for months, these small, low power devices have to sleep from 99% to
   99.5% of their time.  For example, a light sensor may wake up to
   check whether it is night-time to turn on light bulbs.  Most parts of
   the system are off-line most of the time and particularly
   communication components are put into a sleeping state (e.g., WLAN
   radio interface) and only very few components of an embedded system
   board, such as sensors, are triggered periodically.  When interesting
   events happen then these components wake-up other parts of the
   system, for example a radio interface to connect to the Internet.
   Every bit is precious, so is every round trip, and every millisecond
   of radio activity.

   Many IETF protocols implicitly assume that nodes in a network are
   always-on and respond to messages, i.e., to maintain a persistent
   presence on the network in order to respond to periodic messages that
   are required in order to maintain persistent sessions, connections,
   security associations, or state.  These protocols work well on
   networks with sufficient network bandwidth, where there is a low cost
   to receiving/sending messages, and nodes are persistently available
   on the network.

   In the early days a machine had gotten a specific IP address
   allocated and it could use it when it wanted to send an IP packet.
   You might need to execute an ARP exchange first before sending the
   packet but you could keep the mapping in the cache for 15 minutes.

   Nowadays we want to make sure that we are on the right network before
   we send an IP packet, we run neighbor discovery, we cannot keep
   neighbor discovery for 15 minutes and so when a node wakes up again
   it essentially has to re-do it to refresh the cache, we want to run
   Detecting Network Attachment (DNA) procedures to check that hosts are
   on the same network either by re-getting an address using the Dynamic
   Host Configuration Protocol (DHCP) or by noticing that the node is
   using the same default gateway because of a received Router
   Advertisement (RA).  Essentially, a number of steps have to be taken
   before sending a packet.

   However, these protocols do not work well, if at all, when the cost
   of sending/receiving those messages is high (in terms of bandwidth or
   battery life) or in cases where nodes sleep periodically and are not
   persistently available to receive those messages.  A number of issue
   arise from these almost-always-off nodes.

   Also a lot of our protocols are getting more chatty.  Keeping the
   receiver up for an additional roundtrip costs extra energy.  Protocol
   messages can also be lengthy, e.g., many protocols carry XML-based

Tschofenig & Arkko      Expires January 12, 2012               [Page 12]

Internet-Draft        Smart Object Workshop Report             July 2011

   There are a couple of ways to think about how to make the situation
   less worse:

   1.  The Always-On Assumption

       When designing a protocol that assumes that the nodes will always
       be there at least consider an alternative paradigm.  For example,
       with duplicate address detection an alternative would be not to
       use it.  There might be also the option to consider an
       architecture with a proxy node that these nodes can poll when
       they boot up to find out whether anyone tried to contact them or
       whether anything they care about has happened, or the proxy
       answers on behalf of another node.

   2.  High Cost to Rejoin the Network

       The goal of these things is to determine whether a wireless node
       is not moved to another network while it was asleep and that
       might be a viable thing to do.  Expecting a wirelss node to go
       through all these steps every time it wakes up before it is
       allowed to send an Ip packet could be considered rather

       Can we find ways to reduce the number of protocol interactions
       that have to be executed for network attachment, including
       determining whether a node has moved or the environment has
       changed otherwise?

   3.  Verbose Protocols

       Some protocols involve multiple roundtrips and/or lengthy
       messages.  As a result, low-powered nodes have to use more power
       in sending messages and have to stay powered on for a longer
       period of time as they wait for the protocol exchanges to
       complete.  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.  However, in some cases
       alternative encoding formats and compression may also help.

   One can argue that certain features are not useful in an environment
   where most nodes are sleeping.  The main focus of past investigations
   has been on IPv6 and ND but other protocols do also deserve a deeper
   investigation, such as DNS, and DHCP.

   During the protocol design phase certain protocols were assumed to be
   used in a human-to-device context and therefore it was argued that

Tschofenig & Arkko      Expires January 12, 2012               [Page 13]

Internet-Draft        Smart Object Workshop Report             July 2011

   the verbose encoding is helpful.  Examples are the Hypertext Transfer
   Protocol (HTTP), the Session Initiation Protocol (SIP), and
   Extensible Messaging and Presence Protocol (XMPP).  Nowadays these
   protocols are also being considered and used in device-to-device
   communication and the verbose nature is not helpful.

   While the principles seem to be most useful for low-power, battery
   powered devices they would also be useful for other devices as well.
   Energy efficiency is useful for normal devices as well, such as
   laptops and smart phones.

   For example, consider energy consumption in a home environment.  The
   question is whether it will save more energy than it uses and
   therefore one has to consider the overall energy consumption of the
   entire solution.  This is not always an easy question to answer.
   IEEE 802.11 nodes, for example, use a lot of power if they cannot be
   made to sleep most of the time.  A light bulb may use less power but
   there is also the device that controls the bulb that may consume a
   lot of energy all the time.  In total, more energy may be consumed
   when considering these two devices together.

3.3.  Security

   In the development of a 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 [RFC3552], and RFC 4101
   [RFC4101], apply also to the smart object space.

   While there are additional constraints, as described in Section 2,
   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.

   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)) as
   a building block for all cryptographic functions with the benefit of
   a smaller footprint of the overall solution.  Specifically the
   different hardware limitations (e.g., the hardware architecture of
   certain embedded devices prevents pipelining to be utilized).  In the

Tschofenig & Arkko      Expires January 12, 2012               [Page 14]

Internet-Draft        Smart Object Workshop Report             July 2011

   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 to find deployment can partially be
   attributed to the 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 (see Online Certificate Status Protocol (OCSP) in
   the Internet Key Exchange protocol version 2 (IKEv2) and in Transport
   Layer Security (TLS)).

   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 is seen in the privacy area where the ongoing work on
   smart grids could be mentioned where concerns regarding the ability
   of others to keep track of the user's energy usage consumption (and
   the associated conclusions) even in an aggregated form have been
   voiced.  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.

   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 adaption.

3.4.  Routing

   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 below at the link layer and

Tschofenig & Arkko      Expires January 12, 2012               [Page 15]

Internet-Draft        Smart Object Workshop Report             July 2011

   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) [I-D.ietf-roll-rpl], for example, belongs to the
   route-over category.

   From an architectural point of view there are several questions that
   arise from where routing is provided, for example:

   o  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?

   o  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.

   o  When path computations are done at the link layer as well as on
      the network layer then what coordination needs to take place?

   When multiple different link layer technologies are involved in a
   network design then routing at layer 3 has to be provided in any
   case.  [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.

   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 details (see [RFC5867], [RFC5826],
   [RFC5673], [RFC5548]), published a protocol survey looking at a

Tschofenig & Arkko      Expires January 12, 2012               [Page 16]

Internet-Draft        Smart Object Workshop Report             July 2011

   number of existing routing protocols
   [I-D.ietf-roll-protocols-survey], including Ad hoc On-Demand Distance
   Vector (AODV)-style of protocols [RFC3561].  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 [Clausen].

Tschofenig & Arkko      Expires January 12, 2012               [Page 17]

Internet-Draft        Smart Object Workshop Report             July 2011

4.  Conclusions and Next Steps

   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 (sleep nodes, energy
   consumption), to focus on some details of the protocol stack
   (neighbour discovery, security, routing) and to implementation

   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.


      A discussion of security is provided in Section 3.3.  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 how
      to accomplish performance improvements without sacrifying the
      overall security level taking the usability of the entire system
      into consideration.

      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.

      The discussion concluded with the following recommendations:

      *  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)' working group was established years ago to deal with
         this topic but was terminated prematurely due to lack of
         progress.  The email archive still exists and is available

Tschofenig & Arkko      Expires January 12, 2012               [Page 18]

Internet-Draft        Smart Object Workshop Report             July 2011

         [enroll] and may provide useful historical information.

      *  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 [I-D.kivinen-ipsecme-ikev2-minimal] and a
         suitable venue for discussion could be the recently established
         Light-Weight Implementation Guidance (LWIG) working group

      *  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.  A suitable forum for discussion is the IRTF
         Crypto Forum Research Group (CFRG) [CFRG].

      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.

   Energy Design Considerations:

      One part of the workshop was focused on the discussion of energy
      implications for IETF protocol design with proposals being made
      how to extend protocols to better support nodes that are mostly
      sleeping.  Discussion are encouraged to take place may take place
      at the RECIPE mailing list [RECIPE].  The workshop position paper
      [Wasserman] by Margaret Wasserman provides a good starting point
      for further investigations.

   Information/Content Centric Networking:

      Information/Content Centric Networking is about accessing named
      content and a number of research projects have emerged around this

Tschofenig & Arkko      Expires January 12, 2012               [Page 19]

Internet-Draft        Smart Object Workshop Report             July 2011

      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 [irtf-discuss].

   Architectural Guidelines:

      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 [I-D.baker-ietf-core].

   Network Management:

      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), on smart objects.  The following position
      papers may be useful as a starting point for further discussions
      [Ersue], [Schoenwaelde].  An IETF draft is also available

   Congestion Control:

      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
      [I-D.ietf-core-coap], the question of congestion control mechanism
      should be used at the underlying transport protocol or by the
      application protocol itself.  [I-D.eggert-core-congestion-control]
      is a starting point for the CoAP protocol but further work is

   Data Models:

      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
      [GEOPRIV] can be re-used the question was raised where the IETF
      should focus their standardization efforts on since domain
      expertise in each area will be needed.  As potential example
      energy pricing was discussed, with an example provided by

Tschofenig & Arkko      Expires January 12, 2012               [Page 20]

Internet-Draft        Smart Object Workshop Report             July 2011


      Additional extensions to developed discovery protocols (such as
      mDNS) may be needed for the smart object environment.

   Home Networking:

      Home network architectures should take into account the
      possibility of smart objects and dedicated subnetworks focusing on
      smart objects.  A new working group, Home Networking (HOMENET)
      [FUN], has been proposed after the workshop to look at this topic.


      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 [RFC4903] the
      Internet Architecture Board had looked into this topic already and
      provided pros and cons.

      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.

Tschofenig & Arkko      Expires January 12, 2012               [Page 21]

Internet-Draft        Smart Object Workshop Report             July 2011

5.  Security Considerations

   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.

   As described in this report part of the agenda was focused on the
   discussion of security, see Section 3.3.

Tschofenig & Arkko      Expires January 12, 2012               [Page 22]

Internet-Draft        Smart Object Workshop Report             July 2011

6.  Acknowledgements

   We would like to thank all the participants for their position
   papers.  The authors of the position papers were invited to the

   Big thanks to Elwyn Davies for helping us to fix language bugs.  We
   would also like to thank Andrei Robachevsky for his review comments.

   Additionally, we would like to thank Ericsson and Nokia Siemens
   Networks for their financial support.

Tschofenig & Arkko      Expires January 12, 2012               [Page 23]

Internet-Draft        Smart Object Workshop Report             July 2011

7.  IANA Considerations

   This document does not require actions by IANA.

Tschofenig & Arkko      Expires January 12, 2012               [Page 24]

Internet-Draft        Smart Object Workshop Report             July 2011

8.  Informative References

   [CFRG]     McGrew (Chair), D., "IRTF Crypto Forum Research Group
              (CFRG)", http://irtf.org/cfrg , June 2011.

   [Clausen]  Clausen, T. and U. Herberg, "Some Considerations on
              Routing in Particular and Lossy Environments", IAB
              Interconnecting Smart Objects with the Internet Workshop,
              Prague, Czech Republic, http://www.iab.org/wp-content/
              IAB-uploads/2011/03/Clausen.pdf, March 2011.

   [Dolin]    Dolin, B., "Application Communications Requirements for
              'The Internet of Things'", IAB Interconnecting Smart
              Objects with the Internet Workshop, Prague, Czech Republic
              , http://www.iab.org/wp-content/IAB-uploads/2011/03/
              Ersue.pdf, March 2011.

   [Ersue]    Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object
              Workshop Position Paper", IAB Interconnecting Smart
              Objects with the Internet Workshop, Prague, Czech Republic
              , http://www.iab.org/wp-content/IAB-uploads/2011/03/
              Ersue.pdf, March 2011.

   [FUN]      "FUture home Networking (FUN) Mailing List",
              https://www.ietf.org/mailman/listinfo/fun , June 2011.

   [GEOPRIV]  "IETF Geographic Location/Privacy Working Group",
              http://datatracker.ietf.org/wg/geopriv/ , June 2011.

              Baker, F. and D. Meyer, "Internet Protocols for the Smart
              Grid", draft-baker-ietf-core-15 (work in progress),
              April 2011.

              Eggert, L., "Congestion Control for the Constrained
              Application Protocol (CoAP)",
              draft-eggert-core-congestion-control-01 (work in
              progress), January 2011.

              Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP
              Optimizations for Constrained Devices",
              draft-hamid-6lowpan-snmp-optimizations-03 (work in
              progress), October 2010.

              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,

Tschofenig & Arkko      Expires January 12, 2012               [Page 25]

Internet-Draft        Smart Object Workshop Report             July 2011

              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-07 (work in progress), July 2011.

              Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview
              of Existing Routing Protocols for Low Power and Lossy
              Networks", draft-ietf-roll-protocols-survey-07 (work in
              progress), April 2009.

              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

              Jennings, C. and B. Nordman, "Communication of Energy
              Price Information", draft-jennings-energy-pricing-01 (work
              in progress), July 2011.

              Kivinen, T., "Minimal IKEv2",
              draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress),
              February 2011.

              Hui, J. and J. Vasseur, "Routing Architecture in Low-Power
              and Lossy Networks (LLNs)",
              draft-routing-architecture-iot-00 (work in progress),
              March 2011.

   [LWIG]     "IETF Light-Weight Implementation Guidance (LWIG) Working
              Group", http://datatracker.ietf.org/wg/lwig/charter/ ,
              June 2011.

   [RECIPE]   "Reducing Energy Consumption with Internet Protocols
              Exploration (RECIPE) Mailing List",
              https://www.ietf.org/mailman/listinfo/recipe , June 2011.

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,

Tschofenig & Arkko      Expires January 12, 2012               [Page 26]

Internet-Draft        Smart Object Workshop Report             July 2011

              July 2003.

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              July 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
              June 2005.

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              June 2007.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
              Framework", RFC 5582, September 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

              Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol
              Profiles for Constrained Devices", IAB Interconnecting
              Smart Objects with the Internet Workshop, Prague, Czech Re
              public, http://www.iab.org/wp-content/IAB-uploads/2011/03/
              Schoenwaelder.pdf, March 2011.

              Wasserman, M., "It's Not Easy Being "Green"", IAB
              Interconnecting Smart Objects with the Internet Workshop,
              Prague, Czech Republic, http://www.iab.org/wp-content/
              IAB-uploads/2011/03/Wasserman.pdf, March 2011.

Tschofenig & Arkko      Expires January 12, 2012               [Page 27]

Internet-Draft        Smart Object Workshop Report             July 2011

   [enroll]   "IETF Credential and Provisioning Working Group Mailing
              List", http://mailman.mit.edu/pipermail/ietf-enroll/ ,
              June 2011.

              "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http:
              msg00041.html , May 2011.

Tschofenig & Arkko      Expires January 12, 2012               [Page 28]

Internet-Draft        Smart Object Workshop Report             July 2011

Appendix A.  Program Committee

   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.

Tschofenig & Arkko      Expires January 12, 2012               [Page 29]

Internet-Draft        Smart Object Workshop Report             July 2011

Appendix B.  Published Workshop Material

   Information about the workshop can be found at the IAB webpage:

   71 position papers were submitted to the workshop:

   1.   Deployment Experience with Low Power Lossy Wireless Sensor
        Networks by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M.
        Philipp, and G. Wittenburg

   2.   CoAP improvements to meet embedded device hardware constraints
        by Davide Barbieri

   3.   Unified Device Networking Protocols for Smart Objects by Daniel
        Barisic and Anton Pfefferseder

   4.   Simplified neighbour cache implementation in RPL/6LoWPAN by
        Dominique Barthel

   5.   Home Control in a consumer's perspective by Anders Brandt

   6.   Authoring Place-based Experiences with an Internet of Things:
        Tussles of Expressive, Operational, and Participatory Goals by
        Jeff Burke

   7.   A Dynamic Distributed Federated Approach for the Internet of
        Things by Diego Casado Mansilla, Juan Ramon Velasco Perez, and
        Mario Lopez-Ramos

   8.   Quickly interoperable Internet of Things using simple
        transparent gateways by Angelo P. Castellani, Salvatore Loreto,
        Nicola Bui, and Michele Zorzi

   9.   Position Paper of the Brno University of Technology Department
        of Telecommunications by Vladimir Cervenka, Lubomir Mraz, Milan
        Simek, Karel Pavlata

   10.  Secure Access to IOT Network: An Application-based Group Key
        Approach by Samita Chakrabarti, and Wassim Haddad

   11.  Domain-Insulated Autonomous Network Architecture (DIANA) by W.

   12.  Yet Another Definition on Name, Address, ID, and Locator
        (YANAIL) by W. Chun

Tschofenig & Arkko      Expires January 12, 2012               [Page 30]

Internet-Draft        Smart Object Workshop Report             July 2011

   13.  The Challenge of Mobility in Low Power Networks by E. Davies

   14.  If the routing protocol is so smart, why should neighbour
        discovery be so dumb? by Nicolas Dejean

   15.  Making Smart Objects IPv6 Ready: Where are we? by M. Durvy and
        M. Valente

   16.  Position Paper on "Interconnecting Smart Objects with the
        Internet" by Mehmet Ersue, and Jouni Korhonen

   17.  The Real-time Enterprise: IoT-enabled Business Processes by
        Stephan Haller, and Carsten Magerkurth

   18.  Making Internet-Connected Objects readily useful by Manfred
        Hauswirth, Dennis Pfisterer, Stefan Decker

   19.  Some Considerations on Routing in Particular and Lossy
        Environments by Thomas Clausen, and Ulrich Herberg

   20.  A Security Protocol Adaptation Layer for the IP-based Internet
        of Things by Rene Hummen, Tobias Heer, and Klaus Wehrle

   21.  Simplified SIP Approach for the Smart Object by Ryota Ishibashi,
        Takumi Ohba, Arata Koike, and Akira Kurokawa

   22.  Mobility support for the small and smart Future Internet devices
        by Antonio J. Jara, and Antonio F. G. Skarmeta

   23.  The Need for Efficient Reliable Multicast in Smart Grid Networks
        by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk

   24.  Lightweight Cryptography for the Internet of Things by Masanobu
        Katagi, and Shiho Moriai

   25.  Thoughts on Reliability in the Internet of Things by James
        Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli

   26.  IKEv2 and Smart Objects by Tero Kivinen

   27.  Position Paper on Thing Name Service (TNS) for the Internet of
        Things (IoT) by Ning Kong, and Shuo Shen

   28.  Connecting Smart Objects to Wireless WANs by Suresh Krishnan

   29.  Towards an Information-Centric Internet with more Things by D.
        Kutscher, and S. Farrell

Tschofenig & Arkko      Expires January 12, 2012               [Page 31]

Internet-Draft        Smart Object Workshop Report             July 2011

   30.  Application of 6LoWPAN for the Real-Time Positioning of
        Manufacturing Assets by Jaacan Martinez and Jose L. M. Lastra

   31.  Lighting interface to wireless network by Jaroslav Meduna

   32.  Social-driven Internet of Connected Objects by Paulo Mendes

   33.  Protocols should go forward that are required by non IP based
        protocols by Tsuyoshi Momose

   34.  Web services for Wireless Sensor and Actuator Networks by Guido

   35.  Connecting BT-LE sensors to the Internet using Ipv6 by Markus
        Isomaeki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen,
        Basavaraj Patil, Teemu Savolainen, and Zach Shelby

   36.  Position Paper by Bruce Nordman by Bruce Nordman

   37.  Issues and Challenges in Provisioning Keys to Smart Objects by
        Yoshihiro Ohba, and Subir Das

   38.  Challenges and Solutions of Secure Smart Environments by Eila
        Ovaska and Antti Evesti

   39.  Research Experiences about Internetworking Mechanisms to
        Integrate Embedded Wireless Networks into Traditional Networks
        by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar

   40.  Scalable Video Coding in Networked Environment by Naeem Ramzan,
        Tomas Piatrik, and Ebroul Izquierdo

   41.  Challenges in Opportunistic Networking by Mikko Pitkaenen, and
        Teemu Kaerkkaeinen

   42.  Position Statement by Neeli R. Prasad, and Sateesh Addepalli

   43.  A Gateway Architecture for Interconnecting Smart Objects to the
        Internet by Akbar Rahman, Dorothy Gellert, Dale Seed

   44.  Routing Challenges and Directions for Smart Objects in Future
        Internet of Things by T. A. Ramrekha, E. Panaousis, and C.

   45.  6LoWPAN Extension for IPsec by Shahid Raza, Thiemo Voigt, and
        Utz Roedig

Tschofenig & Arkko      Expires January 12, 2012               [Page 32]

Internet-Draft        Smart Object Workshop Report             July 2011

   46.  Connected Vehicle as Smart Object(s) by Ryuji Wakikawa

   47.  Problem and possible approach of development and operation of
        Smart Objects by Shoichi Sakane

   48.  Connecting Passive RFID Tags to the Internet of Things by Sandra
        Dominikus, and Joern-Marc Schmidt

   49.  Protocol Profiles for Constrained Devices by Juergen
        Schoenwaelde, Tina Tsou, and Behcet Sarikaya

   50.  Multihoming for Sensor Networks by J. Soininen

   51.  Internet Objects for Building Control by Peter van der Stok, and
        Nicolas Riou

   52.  Optimal information placement for Smart Objects by Shigeya

   53.  Multi-National Initiative for Cloud Computing in Health Care
        (MUNICH) by Christoph Thuemmler

   54.  The time of the hourglass has elapsed by Laurent Toutain,
        Nicolas Montavont, and Dominique Barthel

   55.  Sensor and Actuator Resource Architecture by Vlasios Tsiatsis,
        Jan Hoeller, and Richard Gold

   56.  IT'S NOT EASY BEING "GREEN" by Margaret Wasserman

   57.  Trustworthy Wireless Industrial Sensor Networks by Markus
        Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis
        Olivereau, and Oualha Nouha

   58.  Interconnecting smart objects through an overlay networking
        architecture by Anastasios Zafeiropoulos, Athanassios
        Liakopoulos and Panagiotis Gouvas

   59.  Building trust among Virtual Interconnecting Smart Objects in
        the Future Internet by Theodore Zahariadic, Helen C. Leligou,
        Panagiotis Trakadas, and Mischa Dohler

   60.  Experience and Challenges of Integrating Smart Devices with the
        Mobile Internet by Zhen Cao, and Hui Deng

   61.  The "mesh-under" versus "route over" debate in IP Smart Objects
        Networks by JP Vasseur, and Jonathan Hui

Tschofenig & Arkko      Expires January 12, 2012               [Page 33]

Internet-Draft        Smart Object Workshop Report             July 2011

   62.  Identification and Authentication of IoT Devices by Alper Yegin

   63.  Security Challenges For the Internet of Things by Tim Polk, and
        Sean Turner

   64.  Application Communications Requirements for 'The Internet of
        Things' by Bob Dolin

   65.  Interoperability Concerns in the Internet of Things by Jari

   66.  Privacy in Ubiquitous Computing by Ivan Gudymenko, and Katrin

   67.  The 10 Laws of Smart Object Security Design by Hannes
        Tschofenig, and Bernard Aboba

   68.  Position Paper on "In-Network Object Cloud" Architecture and
        Design Goals by Alex Galis, and Stuart Clayman

   69.  Temptations and Difficulties of Protocols for Smart Objects and
        the Internet by Alexandru Petrescu

   70.  The Internet of Things - Challenge for a New Architecture from
        Problems by Gyu Myoung Lee, and Noel Crespi

   71.  Garrulity and Fluff by Carsten Bormann, and Klaus Hartke

   These papers can be retrieved from:

   The slides are available for download at the following webpage:

   Detailed meeting minutes are published here:

Tschofenig & Arkko      Expires January 12, 2012               [Page 34]

Internet-Draft        Smart Object Workshop Report             July 2011

Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Jari Arkko
   Jorvas  02420

   Email: jari.arkko@piuha.net

Tschofenig & Arkko      Expires January 12, 2012               [Page 35]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/