idnits 2.17.1 draft-iab-smart-object-workshop-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2222' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC5582' is defined on line 1012, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational J. Arkko 5 Expires: April 26, 2012 Ericsson 6 October 24, 2011 8 Report from the 'Interconnecting Smart Objects with the Internet' 9 Workshop, 25th March 2011, Prague 10 draft-iab-smart-object-workshop-05.txt 12 Abstract 14 This document provides an overview of a workshop held by the Internet 15 Architecture Board (IAB) on 'Interconnecting Smart Objects with the 16 Internet'. The workshop took place in Prague on March, 25th. The 17 main goal of the workshop was to solicit feedback from the wider 18 community on their experience with deploying IETF protocols in 19 constrained environments. This report summarizes the discussions and 20 lists the conclusions and recommendations to the Internet Engineering 21 Task Force (IETF) community. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 26, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 6 59 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 8 62 3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 9 63 3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10 64 3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 71 8. Informative References . . . . . . . . . . . . . . . . . . . . 25 72 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29 73 Appendix B. Published Workshop Material . . . . . . . . . . . . . 30 74 Appendix C. Workshop Participants . . . . . . . . . . . . . . . . 35 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 77 1. Introduction 79 The Internet Architecture Board (IAB) holds occasional workshops 80 designed to consider long-term issues and strategies for the 81 Internet, and to suggest future directions for the Internet 82 architecture. This long-term planning function of the IAB is 83 complementary to the ongoing engineering efforts performed by working 84 groups of the Internet Engineering Task Force (IETF), under the 85 leadership of the Internet Engineering Steering Group (IESG) and area 86 directorates. 88 Today's Internet is experienced by users as a set of applications, 89 such as email, instant messaging, and services on the Web. While 90 these applications do not require users to be present at the time of 91 service execution in many cases they are. There are also substantial 92 differences in performance among the various end devices, but in 93 general end devices participating in the Internet are considered to 94 have high performance. 96 There are, however, a large number of deployed embedded devices and 97 there is substantial value in interconnecting them with the Internet. 98 The term "Internet of Things" denotes a trend where a large number of 99 devices employ communication services offered by the Internet 100 Protocols. Many of these devices are not directly operated by 101 humans, but exist as components in buildings, vehicles, and the 102 environment. There is a large variation in the computing power, 103 available memory, (electrical) power, and communications bandwidth 104 between different types of devices. 106 Many of these devices offer a range of new possibilities or provide 107 additional value for previously unconnected devices. Some devices 108 have been connected using proprietary communication networks in the 109 past but are now migrating to the use of the Internet Protocol suite 110 in order to share the same communication network between all 111 applications and enabling rich communications services. 113 Much of this development can simply run on existing Internet 114 protocols. For instance, home entertainment and monitoring systems 115 often offer a web interface to the end user. In many cases the new, 116 constrained environments can benefit from additional protocols and 117 protocol extensions that help optimize the communications and lower 118 the computational requirements. Examples of currently ongoing 119 standardization efforts targeted for these environments include the 120 "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN 121 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 122 the "Light-Weight Implementation Guidance (LWIG)" working groups at 123 the IETF. 125 This workshop explored the experiences of researchers and developers, 126 when considering the characteristics of constrained devices. 127 Engineers know that many design considerations need to be taken into 128 account when developing protocols and architecture. Balancing 129 between the conflicting goals of code size, economical incentives, 130 power consumption, usability and security is often difficult, as 131 illustrated by Clark, et al. in "Tussle in Cyberspace: Defining 132 Tomorrow's Internet". 134 Participants at the workshop discussed the experience and approaches 135 taken when designing protocols and architectures for interconnecting 136 smart objects to the Internet. The scope of the investigations 137 included constrained nodes as well as constrained networks. 139 The call for position paper suggested investigating the area of 140 integration with the Internet in the following categories: 142 o Scalability 144 o Power efficiency 146 o Interworking between different technologies and network domains 148 o Usability and manageability 150 o Security and Privacy 152 The goals of the workshop can be summarized as follows: 154 As many deployed smart objects demonstrate running protocols, like 155 IP, TCP, UDP, HTTP, etc., on constrained devices is clearly is 156 possible. Still, protocol designers, system architects and 157 developers have to keep various limitations in mind. The 158 organizers were interested to discuss the experience with 159 deploying IETF protocols in different constrained environments. 161 Furthermore, the organizers were seeking to identify either issues 162 where current implementers do not yet have solutions or where 163 researchers predict potential issues. 165 The workshop served as a venue to identify problems and to 166 discover common interests that may turn into new work or into 167 changes in direction of already ongoing work at the IETF and or 168 the Internet Research Task Force (IRTF). 170 Note that this document is a report on the proceedings of the 171 workshop. The views and positions documented in this report are 172 those of the workshop participants and do not necessarily reflect IAB 173 views and positions. 175 2. Constrained Nodes and Networks 177 An observation that lead to the scheduling of the workshop was the 178 presence of constrained devices that are more and more interconnected 179 to the network. So, it is quite natural to ask how these limitations 180 impact the design of the affected nodes. Note that not all nodes 181 suffer from the same set of limitations. 183 Energy constraints: 185 Since wireless communication can be a large portion of the power- 186 budget for wireless devices, reducing unnecessary communication 187 can significantly increase the battery life of a low-end device. 188 The choice of low-power radio being used also has a lot of impact 189 on the overall energy consumption. Sleeping periodically, and 190 often aggressively, when not in use. In some cases, these nodes 191 will only wake periodically to handle needed communications. This 192 constraint is quite in contrast to the "always on" paradigm found 193 in regular Internet hosts. Even in case of non-battery operated 194 devices power is a constraint with respect to energy efficiency 195 goals. 197 Bandwidth constraints: 199 Various low power radio networks offer only ~100 kbit/s or even 200 only a few KBits/s, and show high packet loss as well as high link 201 quality variability. Nodes may be used in usually highly unstable 202 radio environments. The physical layer packet size may be limited 203 (~100 bytes). 205 Memory constraints: 207 The amount of volatile and persistent storage impacts the program 208 executtion has important implications for the functionality of the 209 protocol stack. The Arduino UNO board, for example, provides a 210 developer with 2 KByte RAM and 32 KByte flash memory (without any 211 extensions, such as microSD cards). 213 A system designer also needs to consider CPU constraints, which often 214 relate to energy constraints: a processor with lower performance 215 consumes less energy. As described later in this document the design 216 of the mainboard may allow certain components to be put to sleep to 217 further lower energy consumption. In general, embedded systems are 218 often purpose built with only the hardware components needed for the 219 given task while general purpose personal computers are less 220 constrained with regard to their mainboard layout and typically offer 221 a huge number of optional plug-in peripherals to be connected. A 222 factor that also has to be taken into consideration is the intended 223 usage environment. For example, a humidity sensor deployed outside a 224 building may need to deal with temperatures from -50 C to +85 C even. 225 There are often physical size limitations for smart objects. While 226 traditional mainboards are rather large, such as the Advanced 227 Technology eXtended (ATX) design with a board size of 305 x 244 mm 228 available in many PCs or the mini-ITX design typically found in home 229 theater PCs with 170 x 170 mm, mainboard layouts for embedded systems 230 are typically much smaller, such as the CoreExpress layout with 58 x 231 65 mm, or even smaller. In addition to the plain mainboard 232 additional sensors, peripherals, a power adapter/battery, and a case 233 have to be taken into consideration. Finally, there are cost 234 restrictions as well. 236 The situation becomes more challenging when not only the hosts are 237 constrained but also the network nodes themselves. 239 While there are constantly improvements being made, Moore's law tends 240 to be less effective in the embedded system space than in personal 241 computing devices: Gains made available by increases in transistor 242 count and density are more likely to be invested in reductions of 243 cost and power requirements than into continual increases in 244 computing power. 246 3. Workshop Structure 248 With the ongoing work on connecting smart objects to the Internet 249 there are many challenges the workshop participants raised in more 250 than 70 accepted position papers. With a single workshop day 251 discussions had to be focused and priority was given to those topics 252 that had been raised by many authors. A summary of the identified 253 issues are captured in the subsections below. 255 3.1. Architecture 257 A number of architectural questions were brought up in the workshop. 258 This is natural, as the architectural choices affect the required 259 technical solutions and the need for standards. At this workshop 260 questions regarding the separation of traffic, the need for profiling 261 for application specific domains, the demand for data model specific 262 standardization as well as the design choices of the layer at which 263 functionality should be put were discussed and are briefly summarized 264 below. 266 3.1.1. One Internet vs. Islands 268 Devices that used to be in proprietary or application-specific 269 networks are today migrating to IP networks. There is, however, the 270 question of whether these smart objects are now on the same IP 271 network as any other application as well. Controlled applications, 272 like the fountains in front of the Bellagio hotel in Las Vegas which 273 are operated as a distributed control system [Dolin], probably are 274 not exchanging their control messages over the same network that is 275 also used by hotel guests for their Internet traffic. The same had 276 been argued for the smart grid as well. The question that was raised 277 during the workshop is therefore in what sense are we talking about 278 one Internet or about using IP technology for a separate, walled 279 garden network that is independent of the Internet? 281 Cullen Jennings compared the current state of smart object deployment 282 with the evolution of voice-over-IP: "Initially, many vendors 283 recommended to run VoIP over a separate VLAN or a separate 284 infrastructure. Nobody could imagine how to make the type of real- 285 time guarantees, how to debug it, and how to get it to work because 286 the Internet is not ideally suited for making any types of guarantees 287 for real-time systems. As time went on people got better at making 288 voice work across that type of IP network. They suddenly noticed 289 that having voice running on a separate virtual network than their 290 other applications was a disaster. They couldn't decide if a PC was 291 running a softphone and whether it went on a voice or a data network. 292 At that point people realized that they needed a converged network 293 and all moved to one. I wouldn't be surprised to see the same 294 happens here. Initially, we will see very separated networks. Then, 295 those will be running over the same hardware to take advantage of the 296 cost benefits of not having to deploy multiple sets of wires around 297 buildings. Over time there will be strong needs to directly 298 communicate with each other. We need to be designing the system for 299 the long run. Assuming everything will end up on the same network 300 even if you initially plan to run it in separate networks." 302 It is clearly possible to let sensors in a building communicate 303 through the wireless access points and through the same 304 infrastructure used for Internet access, if you want to. Those who 305 want separation at the physical layer can do so as well. What is, 306 however, important is to make sure that these different deployment 307 philosophies do not force loss of interoperability. 309 The level of interoperability that IP accomplished fostered 310 innovation at the application layer. Ralph Droms reinforced this 311 message by saying: "Bright people will take a phone, build an 312 application and connect it, with the appropriate security controls in 313 place, to the things in my house in ways we have never thought about 314 before. Otherwise we are just building another telephone network." 316 3.1.2. Domain Specific Stacks and Profiles 318 Imagine a building network scenario where a new light bulb is 319 installed that should, out of the box without further configuration, 320 interoperate with the already present light switch from a different 321 vendor in the room. For many this is the desired level of 322 interoperability in the area of smart object design. To accomplish 323 this level of interoperability it is not sufficient to provide 324 interoperability only at the network layer. Even running the same 325 transport protocol (e.g., TCP) and application layer protocol (e.g., 326 HTTP) is insufficient since both devices need to understand the 327 semantics of the payloads for "Turn the light on" as well. 329 Standardizing the entire protocol stack for this specific "light 330 switch/light bulb" scenario is possible. A possible stack would, for 331 example, use IPv6 with a specific address configuration mechanism 332 (such as stateless address autoconfiguration), a network access 333 authentication security mechanism such as PANA, a service discovery 334 mechanism (multicast DNS with DNS-SD), an application layer protocol, 335 for example, Constrained Application Protocol (CoAP) (which uses 336 UDP), and the syntax and semantic for the light on/off functionality. 338 As this list shows there is already some amount of protocol 339 functionality that has to be agreed on by various stakeholders to 340 make this scenario work seamlessly. As we approach more complex 341 protocol interactions the functionality quickly becomes more complex: 343 IPv4 and IPv6 on the network layer, various options at the transport 344 layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices 345 at the application layer with respect to communication protocols, 346 data formats and data models. Different requirements have lead to 347 the development of a variety of communication protocols: client- 348 server protocols in the style of the original HTTP, publish-subscribe 349 protocols (like SIP or XMPP), store-and-forward messaging (borrowed 350 from the delay tolerant networking community). Along with the 351 different application layer communication protocols come various 352 identity and security mechanisms. 354 With the smart object constraints it feels natural to develop these 355 stacks since each application domain (e.g., health-care, smart grids, 356 building networking) will have their unique requirements and their 357 own community involved in the design process. How likely are these 358 profiles going to be the right match for the future, specifically for 359 the new innovations that will come? How many of these stacks are we 360 going to have? Will the differences in the profiles purely be the 361 result of different requirements coming from the individual 362 application domains or will these mismatches reflect the spirit, 363 understanding and preferences of the community designing them? How 364 many stacks will multi-purpose devices have to implement? 366 Standardizing profiles independently for each application is not the 367 only option. Another option is to let many different applications 368 utilize a common foundation, i.e., a protocol stack that is 369 implemented and utilized by every device. This, however, requires 370 various application domains to be analyzed for their common 371 characteristics and to identify requirements that are common across 372 all of them. The level of difficulty for finding an agreement of how 373 such a foundation stack should look like depends on how many layers 374 it covers and how lightweight it has to be. 376 From the decisions at the workshop it was clear that the available 377 options are not ideal and further discussions are needed. 379 3.1.3. Which Layer? 381 The end-to-end principle states that functionality should be put into 382 the end points instead of into the networks. An additional 383 recommendation, which is equally important, is to put functionality 384 higher up in the protocol stack. While it is useful to make common 385 functionality available as building blocks to higher layers the wide 386 range of requirements by different applications lead to a model where 387 lower layers provide only very basic functionality and more 388 sophisticated features were made available by various applications. 389 Still, there has been the desire to put application layer 390 functionality into the lower layers of the networking stack. A 391 common belief is that performance benefits can be gained if 392 functionality is placed at the lower layers of the protocol stack. 393 This new functionality may be offered in the form of a gateway, which 394 bridges different communication technologies, acts on behalf of other 395 nodes, and offers more generic functionality (such as name-based 396 routing and caching). 398 Two examples of functionality offered at the network layer discussed 399 during the workshops were location, and name-based routing: 401 Location: 403 The notion of location gives each network node the understanding 404 of proximity (e.g., 'I am a light bulb and in the same room as the 405 light switch.'). Today, a router may provide information as to 406 whether other nodes belong to the same subnet or they may provide 407 location information (for example, in the form of GPS based 408 coordinates). However, providing a sense of the specific 409 environment (e.g., a room, building, campus, etc.) is not possible 410 without manual configuration. While it has been a desirable 411 feature for many ubiquitous computing applications to know this 412 type of information and to use it for richer application layer 413 interactions, widespread deployment has not happened yet. 415 Name-based Routing: 417 With the work on recent clean slate architecture proposals, such 418 as the named data networking, flexible naming concepts are being 419 researched to allow application developer to express their 420 application layer concepts in a way that they can be used natively 421 by the underlying networking stack without translation. For 422 example, Jeff Burke provided the example of his work in a theater 423 with a distributed control system of technical equipment (such as 424 projectors, dimmers, and light systems). Application developers 425 name their equipment with human readable identifiers, which may 426 change after the end of a rehearsal, and address them using these 427 names. These variable length based naming concepts raise 428 questions regarding scalability. 430 The workshop participants were not able to come to an agreement about 431 what functionality should be moved from the application layer to the 432 network layer. 434 3.2. Sleep Modes 436 One limitation of smart objects is the available energy. To extend 437 battery life, for example of a watch battery or single AAA battery 438 for months, these small, low power devices have to sleep from 99% to 439 99.5% of their time. For example, a light sensor may wake up to 440 check whether it is night-time to turn on light bulbs. Most parts of 441 the system are off-line most of the time and particularly 442 communication components are put into a sleeping state (e.g., WLAN 443 radio interface) and only very few components of an embedded system 444 board, such as sensors, are triggered periodically. When interesting 445 events happen then these components wake-up other parts of the 446 system, for example a radio interface to connect to the Internet. 447 Every bit is precious, so is every round trip, and every millisecond 448 of radio activity. 450 Many IETF protocols implicitly assume that nodes in a network are 451 always-on and respond to messages, i.e., to maintain a persistent 452 presence on the network in order to respond to periodic messages that 453 are required in order to maintain persistent sessions, connections, 454 security associations, or state. These protocols work well on 455 networks with sufficient network bandwidth, where there is a low cost 456 to receiving/sending messages, and nodes are persistently available 457 on the network. 459 In the early days a machine had gotten a specific IP address 460 allocated and it could use it when it wanted to send an IP packet. 461 You might need to execute an ARP exchange first before sending the 462 packet but you could keep the mapping in the cache for 15 minutes. 464 Nowadays we want to make sure that we are on the right network before 465 we send an IP packet, we run neighbor discovery, we cannot keep 466 neighbor discovery for 15 minutes and so when a node wakes up again 467 it essentially has to re-do it to refresh the cache, we want to run 468 Detecting Network Attachment (DNA) procedures to check that hosts are 469 on the same network either by re-getting an address using the Dynamic 470 Host Configuration Protocol (DHCP) or by noticing that the node is 471 using the same default gateway because of a received Router 472 Advertisement (RA). Essentially, a number of steps have to be taken 473 before sending a packet. 475 However, these protocols do not work well, if at all, when the cost 476 of sending/receiving those messages is high (in terms of bandwidth or 477 battery life) or in cases where nodes sleep periodically and are not 478 persistently available to receive those messages. A number of issue 479 arise from these almost-always-off nodes. 481 Also a lot of our protocols are getting more chatty. Keeping the 482 receiver up for an additional roundtrip costs extra energy. Protocol 483 messages can also be lengthy, e.g., many protocols carry XML-based 484 payloads. 486 There are a couple of ways to think about how to make the situation 487 less worse: 489 1. The Always-On Assumption 491 When designing a protocol that assumes that the nodes will always 492 be there at least consider an alternative paradigm. For example, 493 with duplicate address detection an alternative would be not to 494 use it. There might be also the option to consider an 495 architecture with a proxy node that these nodes can poll when 496 they boot up to find out whether anyone tried to contact them or 497 whether anything they care about has happened, or the proxy 498 answers on behalf of another node. Yet another option is to 499 allow devices to expose their sleep cycles so that a device could 500 go into a mode in which it only checks for messages periodically 501 (be it measured in msec, sec, or hours) and let other devices 502 know what sorts of delays there may be. 504 2. High Cost to Rejoin the Network 506 The goal of these things is to determine whether a wireless node 507 is not moved to another network while it was asleep and that 508 might be a viable thing to do. Expecting a wirelss node to go 509 through all these steps every time it wakes up before it is 510 allowed to send an Ip packet could be considered rather 511 excessive. 513 Can we find ways to reduce the number of protocol interactions 514 that have to be executed for network attachment, including 515 determining whether a node has moved or the environment has 516 changed otherwise? 518 3. Verbose Protocols 520 Some protocols involve multiple roundtrips and/or lengthy 521 messages. As a result, low-powered nodes have to use more power 522 in sending messages and have to stay powered on for a longer 523 period of time as they wait for the protocol exchanges to 524 complete. The best way to address these problems is to ensure 525 that the simplest possible protocol exchanges are used when the 526 protocols in question are designed. However, in some cases 527 alternative encoding formats and compression may also help. 529 One can argue that certain features are not useful in an environment 530 where most nodes are sleeping. The main focus of past investigations 531 has been on IPv6 and ND but other protocols do also deserve a deeper 532 investigation, such as DNS, and DHCP. 534 During the protocol design phase certain protocols were assumed to be 535 used in a human-to-device context and therefore it was argued that 536 the verbose encoding is helpful. Examples are the Hypertext Transfer 537 Protocol (HTTP), the Session Initiation Protocol (SIP), and 538 Extensible Messaging and Presence Protocol (XMPP). Nowadays these 539 protocols are also being considered and used in device-to-device 540 communication and the verbose nature is not helpful. 542 While the principles seem to be most useful for low-power, battery 543 powered devices they would also be useful for other devices as well. 544 Energy efficiency is useful for normal devices as well, such as 545 notebooks, desktops and smart phones. 547 For example, consider energy consumption in a home environment. The 548 question is whether it will save more energy than it uses and 549 therefore one has to consider the overall energy consumption of the 550 entire solution. This is not always an easy question to answer. 551 IEEE 802.11 nodes, for example, use a lot of power if they cannot be 552 made to sleep most of the time. A light bulb may use less power but 553 there is also the device that controls the bulb that may consume a 554 lot of energy all the time. In total, more energy may be consumed 555 when considering these two devices together. 557 3.3. Security 559 In the development of a smart object applications, as with any other 560 protocol application solution, security has to be considered early in 561 the design process. As such, the recommendations currently provided 562 to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 563 [RFC4101], apply also to the smart object space. 565 While there are additional constraints, as described in Section 2, 566 security has to be a mandatory part of the solution. The hope is 567 that this will lead to implementations that provide security 568 features, deployments that utilize these, and finally that this leads 569 to use of better security mechanisms. It is important to point out 570 that the lack of direct user interaction will place hard requirements 571 on deployment models, configuration mechanisms, and software upgrade/ 572 crypto agility mechanisms. 574 Since many of the security mechanisms allow for customization, 575 particularly with regard to the cryptographic primitives utilized, 576 many believe that IETF security solutions are usable without 577 modifications in a large part of the smart object domain. Others 578 call for new work on cryptographic primitives that make use of a 579 single primitive (such as the Advanced Encryption Standard (AES)) as 580 a building block for all cryptographic functions with the benefit of 581 a smaller footprint of the overall solution. Specifically the 582 different hardware limitations (e.g., the hardware architecture of 583 certain embedded devices prevents pipelining to be utilized). In the 584 excitement for new work on optimizations of cryptograhpic primitives 585 other factors have to be taken into consideration that influence 586 successful deployment, such as widespread support in libraries, as 587 well as intellectual property rights (IPR). As an example of the 588 latter aspect the struggle of Elliptic Curve Cryptography (ECC)-based 589 cryptographic algorithms to find deployment can partially be 590 attributed to the IPR situation. The reuse of libraries providing 591 cryptographic functions is clearly an important way to use available 592 memory resources in a more efficient way. To deal with the 593 performance and footprint concerns investigations into offloading 594 certain resource-hungry functions to parties that possess more 595 cryptographic power have been considered. For example, the ability 596 to delegate certificate validation to servers has been standardized 597 in the IETF before (see Online Certificate Status Protocol (OCSP) in 598 the Internet Key Exchange protocol version 2 (IKEv2) and in Transport 599 Layer Security (TLS)). 601 Focusing only on the cryptographic primitives would be shortsighted; 602 many would argue that this is the easy part of a smart object 603 security solution. Key management and credential enrollment, 604 however, are considered a big challenge by many particularly when 605 usability requirements have to be taken into account. Another group 606 of challenges is seen in the privacy area where the ongoing work on 607 smart grids could be mentioned where concerns regarding the ability 608 of others to keep track of the user's energy usage consumption (and 609 the associated conclusions) even in an aggregated form have been 610 voiced. As another example, it is easy to see how a scale that is 611 connected to the Internet for uploading weight information to a 612 social network could lead to privacy concerns. While security 613 mechanisms used to offer protection of the communication between 614 different parties also provide a certain degree of privacy protection 615 they are clearly not enough to address all concerns. Even with the 616 best communication security and access control mechanisms in place 617 one still needs additional safeguards against the concerns mentioned 618 in the examples. 620 While a lot can be said about how desirable it would be to deploy 621 more security protocols on the entire Internet, practical 622 considerations regarding usability and the incentives of the 623 stakeholders involved have often lead to slower adaption. 625 3.4. Routing 627 A smart object network environment may also employ routers under 628 similar constraints as the end devices. Currently two approaches to 629 routing in these low power and lossy networks are under 630 consideration, namely mesh-under and route-over. The so-called mesh- 631 under approach places routing functions below at the link layer and 632 consequently all devices appear as immediate neighbors at the network 633 layer. With the route-over approach routing is done at the IP layer 634 and none in the link layer. Each physical hop appears as a single IP 635 hop (ignoring devices that just extend the physical range of 636 signaling, such as repeaters). Routing in this context means running 637 a routing protocol. IPv6 Routing Protocol for Low power and Lossy 638 Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the 639 route-over category. 641 From an architectural point of view there are several questions that 642 arise from where routing is provided, for example: 644 o Protocols often assume that link characteristics are predictable 645 when communicating with any device attached to the same link. 646 Latency, throughput, and reliability may vary considerably between 647 different devices that are multiple link layer hops away. What 648 timeout should be used? What happens if a device is unreachable? 649 In case of default router selection two advertised routers may be 650 a different number of hops away. Should a device have visibility 651 into the path to make a decision and what path characteristics 652 would be useful to have? 654 o Scoped message delivery to a neighboring IP hop (via link-local 655 addressing) allows certain types of IP protocols to communicate 656 with their immediate neighbors and to therefore scope their 657 recipients. A link-local multicast message will be received by 658 all nodes in the same IP link local realm unless some special 659 optimizations are provided by the link layer. 661 o When path computations are done at the link layer as well as on 662 the network layer then what coordination needs to take place? 664 When multiple different link layer technologies are involved in a 665 network design then routing at layer 3 has to be provided in any 666 case. [I-D.routing-architecture-iot] talks about these tradeoffs 667 between route-over and mesh-under in detail. Furthermore, those who 668 decide about the deployment have to determine how to connect smart 669 objects to the Internet infrastructure and a number of wired and 670 wireless technologies may be suitable for a specific deployment. 671 Depending on the chosen technologies the above-mentioned mesh-under 672 vs. route-over approach will have to be decided and further decisions 673 will have to be made about the choice of a specific routing protocol. 675 In 2008 the IETF formed the Routing Over Low power and Lossy networks 676 (ROLL) working group to specify a routing solution for smart object 677 environments. During its first year of existence, the working group 678 studied routing requirements in details (see [RFC5867], [RFC5826], 679 [RFC5673], [RFC5548]), worked on a protocol survey comparing a number 680 of existing routing protocols, including Ad hoc On-Demand Distance 681 Vector (AODV)-style of protocols [RFC3561], against the identified 682 requirements. The protocol survey [I-D.ietf-roll-protocols-survey] 683 was inconclusive and abandoned without giving rise to publication of 684 an RFC. 686 The ROLL WG concluded that a new routing protocol satisfying the 687 documented requirements has to be developed and the work on the RPL 688 was started, as the IETF routing protocol for smart object networks. 689 Nevertheless, controversial discussions at the workshop about which 690 routing protocols is best in a given environment are still ongoing. 691 Thomas Clausen, for example, argued for using an AODV-like routing 692 protocol in [Clausen]. 694 4. Conclusions and Next Steps 696 The workshop allowed the participants to get exposed to interesting 697 applications and their requirements (buildings, fountains, theater, 698 etc.), to have discussions about radically different architectures 699 and their issues (e.g., information centric networking), to look at 700 existing technology from a new angle (sleep nodes, energy 701 consumption), to focus on some details of the protocol stack 702 (neighbour discovery, security, routing) and to implementation 703 experience. 705 One goal of the workshop was to identify areas that require further 706 investigation. The list below reflects the thoughts of the workshop 707 participants as expressed on the day of the workshop. Note that the 708 suggested items concern potential work by the IETF and the IRTF and 709 the order does not imply a particular preference. 711 Security: 713 A discussion of security is provided in Section 3.3. In general, 714 security related protocol exchanges and the required amount of 715 computational resource requirements can contribute significantly 716 to the overall processing. Therefore, it remains a challenge how 717 to accomplish performance improvements without sacrifying the 718 overall security level taking the usability of the entire system 719 into consideration. 721 Another challenge is how to balance the security and performance 722 needs of smart objects with the interoperability requirements of 723 hosts on the Internet since different suites of algorithms may 724 tend to be chosen for these different environments. This involves 725 trade-offs between performance on the smart objects versus end-to- 726 end security. Solutions that mandate a "trusted" middlebox whose 727 only role is to terminate security associations tend to be frowned 728 upon from the security perspective, especially since end-users of 729 challenged devices (where those exist) are unlikely to understand 730 the security consequences of such middleboxes. 732 The discussion concluded with the following recommendations: 734 * Investigate usability in cryptographic protocol design with 735 regard to credential management. As an example, the Bluetooth 736 pairing mechanism was mentioned as a simple and yet reasonably 737 secure method of introducing devices into a new environment. 738 In fact, the IETF working group 'Credential and Provisioning 739 (ENROLL)' working group was established years ago to deal with 740 this topic but was terminated prematurely due to lack of 741 progress. The email archive still exists and is available 743 [enroll] and may provide useful historical information. 745 * Standardized authentication and key exchange mechanisms should 746 be surveyed for suitability in smart object environments with 747 respect to message size, computational performance, number of 748 messages, codesize, and main memory requirements. A starting 749 point of such an investigation (in case of IKEv2) was provided 750 by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a 751 suitable venue for discussion could be the recently established 752 Light-Weight Implementation Guidance (LWIG) working group 753 [LWIG]. 755 * Research has to be done in the area of lightweight 756 cryptographic primitives, namely block ciphers, stream ciphers, 757 and cryptographic hash functions. Worthwhile to mention is 758 early work with the National Institute of Standards and 759 Technology (NIST) new cryptographic hash algorithm 'SHA-3' 760 competition. A suitable forum for discussion is the IRTF 761 Crypto Forum Research Group (CFRG) [CFRG]. 763 The difficulty and impact of choosing specialised algorithms for 764 smart objects should not be underestimated. Issues that arise 765 include the additional specification complexity (e.g., TLS already 766 has 100's of ciphersuites defined, most of which are unused in 767 practice), the long latency in terms of roll out (many hosts are 768 still using deprecated algorithms 5-10 years after those 769 algorithms were deprecated) and the barriers that IPR-encumbered 770 schemes present to widespread deployment. While research on this 771 topic within CFRG and the cryptographic research community is a 772 very worthwhile goal, any such algorithms will likely have to 773 offer very significant benefits before they will be broadly 774 adopted. 20% less CPU is unlikely to be a winning argument no 775 matter what an algorithm inventor believes. 777 Energy Design Considerations: 779 One part of the workshop was focused on the discussion of energy 780 implications for IETF protocol design with proposals being made 781 how to extend protocols to better support nodes that are mostly 782 sleeping. Discussion are encouraged to take place at the RECIPE 783 mailing list [RECIPE]. The workshop position paper [Wasserman] by 784 Margaret Wasserman provides a good starting point for further 785 investigations. 787 Information/Content Centric Networking: 789 Information/Content Centric Networking is about accessing named 790 content and a number of research projects have emerged around this 791 theme. At this point in time the work is not yet ready for 792 standardization in the IETF. Instead, the formation of an IRTF 793 research group has been proposed and more details are available on 794 the IRTF DISCUSS mailing list [irtf-discuss]. 796 Architectural Guidelines: 798 Participants suggested developing an architectural write-up about 799 what can be done with the IETF protocols we have today and how 800 these different elements may be combined to offer an explanation 801 for the broader community. This would be a task for the Internet 802 Architecture Board (IAB). An example of prior work that serves as 803 input is [I-D.baker-ietf-core]. 805 Network Management: 807 While this topic did not make it onto the workshop agenda it was 808 considered useful to start a discussion about how to implement 809 network management protocols, such as Network Configuration 810 Protocol (NETCONF), on smart objects. The following position 811 papers may be useful as a starting point for further discussions 812 [Ersue], [Schoenwaelde]. An IETF draft is also available 813 [I-D.hamid-6lowpan-snmp-optimizations]. 815 Congestion Control: 817 When smart objects transmit sensor readings to some server on the 818 Internet then these protocol interactions often carry a small 819 amount of data and happen infrequently, although regularly. With 820 the work on new application protocols, like the CoAP 821 [I-D.ietf-core-coap], the question of congestion control mechanism 822 should be used at the underlying transport protocol or by the 823 application protocol itself. [I-D.eggert-core-congestion-control] 824 is a starting point for the CoAP protocol but further work is 825 needed. 827 Data Models: 829 Standardization of application layer protocols is important but 830 does not ensure that, for example, a light switch and a light bulb 831 are able to interact with each other. One area where participants 832 saw the need for further work was in the area of data models. 833 While prior IETF standardization work on, for example, location 834 [GEOPRIV] can be re-used the question was raised where the IETF 835 should focus their standardization efforts on since domain 836 expertise in each area will be needed. As potential example 837 energy pricing was discussed, with an example provided by 838 [I-D.jennings-energy-pricing]. 840 Discovery: 842 Additional extensions to developed discovery protocols (such as 843 mDNS) may be needed for the smart object environment. 845 Building Networking: 847 Network architectures in residential as well as commercial 848 buildings should take the presence of smart objects and dedicated 849 subnetworks focusing on smart objects into account. A new working 850 group, Home Networking (HOMENET) [FUN], has been proposed after 851 the workshop to look at this topic. 853 Routing: 855 Changing radio conditions and link fluctuation may lead to the 856 need for re-numbering. Workshop participants argued that work 857 should be started on the multi-link subnetworks to mitigate this 858 problem, i.e., to extend the notion of a subnet to be able to span 859 multiple links. With the publication of RFC 4903 [RFC4903] the 860 Internet Architecture Board had looked into this topic already and 861 provided pros and cons. 863 The applicability of specific routing protocols designed for smart 864 object networks needs further investigation. The ROLL working 865 group is chartered with the task of constructing an applicability 866 document for the RPL protocol, for instance. 868 5. Security Considerations 870 The workshop discussions covered a range of potential engineering 871 activities, each with its own security considerations. As the IETF 872 community begins to pursue specific avenues arising out of this 873 workshop, addressing relevant security requirements will be crucial. 875 As described in this report part of the agenda was focused on the 876 discussion of security, see Section 3.3. 878 6. Acknowledgements 880 We would like to thank all the participants for their position 881 papers. The authors of the position papers were invited to the 882 workshop. 884 Big thanks to Elwyn Davies for helping us to fix language bugs. We 885 would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas 886 Clausen, Bruce Nordman, and Henning Schulzrinne for their review 887 comments. 889 Additionally, we would like to thank Ericsson and Nokia Siemens 890 Networks for their financial support. 892 7. IANA Considerations 894 This document does not require actions by IANA. 896 8. Informative References 898 [CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group 899 (CFRG)", http://irtf.org/cfrg , June 2011. 901 [Clausen] Clausen, T. and U. Herberg, "Some Considerations on 902 Routing in Particular and Lossy Environments", IAB 903 Interconnecting Smart Objects with the Internet Workshop, 904 Prague, Czech Republic, http://www.iab.org/wp-content/ 905 IAB-uploads/2011/03/Clausen.pdf, March 2011. 907 [Dolin] Dolin, B., "Application Communications Requirements for 908 'The Internet of Things'", IAB Interconnecting Smart 909 Objects with the Internet Workshop, Prague, Czech Republic 910 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 911 Ersue.pdf, March 2011. 913 [Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object 914 Workshop Position Paper", IAB Interconnecting Smart 915 Objects with the Internet Workshop, Prague, Czech Republic 916 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 917 Ersue.pdf, March 2011. 919 [FUN] "FUture home Networking (FUN) Mailing List", 920 https://www.ietf.org/mailman/listinfo/fun , June 2011. 922 [GEOPRIV] "IETF Geographic Location/Privacy Working Group", 923 http://datatracker.ietf.org/wg/geopriv/ , June 2011. 925 [I-D.baker-ietf-core] 926 Baker, F. and D. Meyer, "Internet Protocols for the Smart 927 Grid", draft-baker-ietf-core-15 (work in progress), 928 April 2011. 930 [I-D.eggert-core-congestion-control] 931 Eggert, L., "Congestion Control for the Constrained 932 Application Protocol (CoAP)", 933 draft-eggert-core-congestion-control-01 (work in 934 progress), January 2011. 936 [I-D.hamid-6lowpan-snmp-optimizations] 937 Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP 938 Optimizations for Constrained Devices", 939 draft-hamid-6lowpan-snmp-optimizations-03 (work in 940 progress), October 2010. 942 [I-D.ietf-core-coap] 943 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 944 "Constrained Application Protocol (CoAP)", 945 draft-ietf-core-coap-07 (work in progress), July 2011. 947 [I-D.ietf-roll-protocols-survey] 948 Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview 949 of Existing Routing Protocols for Low Power and Lossy 950 Networks", draft-ietf-roll-protocols-survey-07 (work in 951 progress), April 2009. 953 [I-D.ietf-roll-rpl] 954 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 955 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 956 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 957 Lossy Networks", draft-ietf-roll-rpl-19 (work in 958 progress), March 2011. 960 [I-D.jennings-energy-pricing] 961 Jennings, C. and B. Nordman, "Communication of Energy 962 Price Information", draft-jennings-energy-pricing-01 (work 963 in progress), July 2011. 965 [I-D.kivinen-ipsecme-ikev2-minimal] 966 Kivinen, T., "Minimal IKEv2", 967 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 968 February 2011. 970 [I-D.routing-architecture-iot] 971 Hui, J. and J. Vasseur, "Routing Architecture in Low-Power 972 and Lossy Networks (LLNs)", 973 draft-routing-architecture-iot-00 (work in progress), 974 March 2011. 976 [LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 977 Group", http://datatracker.ietf.org/wg/lwig/charter/ , 978 June 2011. 980 [RECIPE] "Reducing Energy Consumption with Internet Protocols 981 Exploration (RECIPE) Mailing List", 982 https://www.ietf.org/mailman/listinfo/recipe , June 2011. 984 [RFC2222] Myers, J., "Simple Authentication and Security Layer 985 (SASL)", RFC 2222, October 1997. 987 [RFC2743] Linn, J., "Generic Security Service Application Program 988 Interface Version 2, Update 1", RFC 2743, January 2000. 990 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 991 Text on Security Considerations", BCP 72, RFC 3552, 992 July 2003. 994 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 995 Demand Distance Vector (AODV) Routing", RFC 3561, 996 July 2003. 998 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 999 Levkowetz, "Extensible Authentication Protocol (EAP)", 1000 RFC 3748, June 2004. 1002 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1003 June 2005. 1005 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1006 June 2007. 1008 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1009 "Routing Requirements for Urban Low-Power and Lossy 1010 Networks", RFC 5548, May 2009. 1012 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1013 Framework", RFC 5582, September 2009. 1015 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1016 "Industrial Routing Requirements in Low-Power and Lossy 1017 Networks", RFC 5673, October 2009. 1019 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1020 Routing Requirements in Low-Power and Lossy Networks", 1021 RFC 5826, April 2010. 1023 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1024 "Building Automation Routing Requirements in Low-Power and 1025 Lossy Networks", RFC 5867, June 2010. 1027 [Schoenwaelde] 1028 Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol 1029 Profiles for Constrained Devices", IAB Interconnecting 1030 Smart Objects with the Internet Workshop, Prague, Czech Re 1031 public, http://www.iab.org/wp-content/IAB-uploads/2011/03/ 1032 Schoenwaelder.pdf, March 2011. 1034 [Wasserman] 1035 Wasserman, M., "It's Not Easy Being "Green"", IAB 1036 Interconnecting Smart Objects with the Internet Workshop, 1037 Prague, Czech Republic, http://www.iab.org/wp-content/ 1038 IAB-uploads/2011/03/Wasserman.pdf, March 2011. 1040 [enroll] "IETF Credential and Provisioning Working Group Mailing 1041 List", http://mailman.mit.edu/pipermail/ietf-enroll/ , 1042 June 2011. 1044 [irtf-discuss] 1045 "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http: 1046 //www.ietf.org/mail-archive/web/irtf-discuss/current/ 1047 msg00041.html , May 2011. 1049 Appendix A. Program Committee 1051 The following persons are responsible for the organization of the 1052 associated workshop and are responsible also for this event: Jari 1053 Arkko, Hannes Tschofenig, Bernard Aboba,Carsten Bormann, David 1054 Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph 1055 Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo 1056 Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen 1057 Jennings, Manfred Hauswirth, and Lukas Kencl. 1059 Appendix B. Published Workshop Material 1061 Information about the workshop can be found at the IAB webpage: 1062 http://www.iab.org/about/workshops/smartobjects/ 1064 71 position papers were submitted to the workshop: 1066 1. Deployment Experience with Low Power Lossy Wireless Sensor 1067 Networks by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. 1068 Philipp, and G. Wittenburg 1070 2. CoAP improvements to meet embedded device hardware constraints 1071 by Davide Barbieri 1073 3. Unified Device Networking Protocols for Smart Objects by Daniel 1074 Barisic and Anton Pfefferseder 1076 4. Simplified neighbour cache implementation in RPL/6LoWPAN by 1077 Dominique Barthel 1079 5. Home Control in a consumer's perspective by Anders Brandt 1081 6. Authoring Place-based Experiences with an Internet of Things: 1082 Tussles of Expressive, Operational, and Participatory Goals by 1083 Jeff Burke 1085 7. A Dynamic Distributed Federated Approach for the Internet of 1086 Things by Diego Casado Mansilla, Juan Ramon Velasco Perez, and 1087 Mario Lopez-Ramos 1089 8. Quickly interoperable Internet of Things using simple 1090 transparent gateways by Angelo P. Castellani, Salvatore Loreto, 1091 Nicola Bui, and Michele Zorzi 1093 9. Position Paper of the Brno University of Technology Department 1094 of Telecommunications by Vladimir Cervenka, Lubomir Mraz, Milan 1095 Simek, Karel Pavlata 1097 10. Secure Access to IOT Network: An Application-based Group Key 1098 Approach by Samita Chakrabarti, and Wassim Haddad 1100 11. Domain-Insulated Autonomous Network Architecture (DIANA) by W. 1101 Chun 1103 12. Yet Another Definition on Name, Address, ID, and Locator 1104 (YANAIL) by W. Chun 1106 13. The Challenge of Mobility in Low Power Networks by E. Davies 1108 14. If the routing protocol is so smart, why should neighbour 1109 discovery be so dumb? by Nicolas Dejean 1111 15. Making Smart Objects IPv6 Ready: Where are we? by M. Durvy and 1112 M. Valente 1114 16. Position Paper on "Interconnecting Smart Objects with the 1115 Internet" by Mehmet Ersue, and Jouni Korhonen 1117 17. The Real-time Enterprise: IoT-enabled Business Processes by 1118 Stephan Haller, and Carsten Magerkurth 1120 18. Making Internet-Connected Objects readily useful by Manfred 1121 Hauswirth, Dennis Pfisterer, Stefan Decker 1123 19. Some Considerations on Routing in Particular and Lossy 1124 Environments by Thomas Clausen, and Ulrich Herberg 1126 20. A Security Protocol Adaptation Layer for the IP-based Internet 1127 of Things by Rene Hummen, Tobias Heer, and Klaus Wehrle 1129 21. Simplified SIP Approach for the Smart Object by Ryota Ishibashi, 1130 Takumi Ohba, Arata Koike, and Akira Kurokawa 1132 22. Mobility support for the small and smart Future Internet devices 1133 by Antonio J. Jara, and Antonio F. G. Skarmeta 1135 23. The Need for Efficient Reliable Multicast in Smart Grid Networks 1136 by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk 1138 24. Lightweight Cryptography for the Internet of Things by Masanobu 1139 Katagi, and Shiho Moriai 1141 25. Thoughts on Reliability in the Internet of Things by James 1142 Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli 1144 26. IKEv2 and Smart Objects by Tero Kivinen 1146 27. Position Paper on Thing Name Service (TNS) for the Internet of 1147 Things (IoT) by Ning Kong, and Shuo Shen 1149 28. Connecting Smart Objects to Wireless WANs by Suresh Krishnan 1151 29. Towards an Information-Centric Internet with more Things by D. 1152 Kutscher, and S. Farrell 1154 30. Application of 6LoWPAN for the Real-Time Positioning of 1155 Manufacturing Assets by Jaacan Martinez and Jose L. M. Lastra 1157 31. Lighting interface to wireless network by Jaroslav Meduna 1159 32. Social-driven Internet of Connected Objects by Paulo Mendes 1161 33. Protocols should go forward that are required by non IP based 1162 protocols by Tsuyoshi Momose 1164 34. Web services for Wireless Sensor and Actuator Networks by Guido 1165 Moritz 1167 35. Connecting BT-LE sensors to the Internet using Ipv6 by Markus 1168 Isomaeki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, 1169 Basavaraj Patil, Teemu Savolainen, and Zach Shelby 1171 36. Building Networks by Bruce Nordman 1173 37. Issues and Challenges in Provisioning Keys to Smart Objects by 1174 Yoshihiro Ohba, and Subir Das 1176 38. Challenges and Solutions of Secure Smart Environments by Eila 1177 Ovaska and Antti Evesti 1179 39. Research Experiences about Internetworking Mechanisms to 1180 Integrate Embedded Wireless Networks into Traditional Networks 1181 by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar 1183 40. Scalable Video Coding in Networked Environment by Naeem Ramzan, 1184 Tomas Piatrik, and Ebroul Izquierdo 1186 41. Challenges in Opportunistic Networking by Mikko Pitkaenen, and 1187 Teemu Kaerkkaeinen 1189 42. Position Statement by Neeli R. Prasad, and Sateesh Addepalli 1191 43. A Gateway Architecture for Interconnecting Smart Objects to the 1192 Internet by Akbar Rahman, Dorothy Gellert, Dale Seed 1194 44. Routing Challenges and Directions for Smart Objects in Future 1195 Internet of Things by T. A. Ramrekha, E. Panaousis, and C. 1196 Politis 1198 45. 6LoWPAN Extension for IPsec by Shahid Raza, Thiemo Voigt, and 1199 Utz Roedig 1201 46. Connected Vehicle as Smart Object(s) by Ryuji Wakikawa 1203 47. Problem and possible approach of development and operation of 1204 Smart Objects by Shoichi Sakane 1206 48. Connecting Passive RFID Tags to the Internet of Things by Sandra 1207 Dominikus, and Joern-Marc Schmidt 1209 49. Protocol Profiles for Constrained Devices by Juergen 1210 Schoenwaelde, Tina Tsou, and Behcet Sarikaya 1212 50. Multihoming for Sensor Networks by J. Soininen 1214 51. Internet Objects for Building Control by Peter van der Stok, and 1215 Nicolas Riou 1217 52. Optimal information placement for Smart Objects by Shigeya 1218 Suzuki 1220 53. Multi-National Initiative for Cloud Computing in Health Care 1221 (MUNICH) by Christoph Thuemmler 1223 54. The time of the hourglass has elapsed by Laurent Toutain, 1224 Nicolas Montavont, and Dominique Barthel 1226 55. Sensor and Actuator Resource Architecture by Vlasios Tsiatsis, 1227 Jan Hoeller, and Richard Gold 1229 56. IT'S NOT EASY BEING "GREEN" by Margaret Wasserman 1231 57. Trustworthy Wireless Industrial Sensor Networks by Markus 1232 Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis 1233 Olivereau, and Oualha Nouha 1235 58. Interconnecting smart objects through an overlay networking 1236 architecture by Anastasios Zafeiropoulos, Athanassios 1237 Liakopoulos and Panagiotis Gouvas 1239 59. Building trust among Virtual Interconnecting Smart Objects in 1240 the Future Internet by Theodore Zahariadic, Helen C. Leligou, 1241 Panagiotis Trakadas, and Mischa Dohler 1243 60. Experience and Challenges of Integrating Smart Devices with the 1244 Mobile Internet by Zhen Cao, and Hui Deng 1246 61. The "mesh-under" versus "route over" debate in IP Smart Objects 1247 Networks by JP Vasseur, and Jonathan Hui 1249 62. Identification and Authentication of IoT Devices by Alper Yegin 1251 63. Security Challenges For the Internet of Things by Tim Polk, and 1252 Sean Turner 1254 64. Application Communications Requirements for 'The Internet of 1255 Things' by Bob Dolin 1257 65. Interoperability Concerns in the Internet of Things by Jari 1258 Arkko 1260 66. Privacy in Ubiquitous Computing by Ivan Gudymenko, and Katrin 1261 Borcea-Pfitzmann 1263 67. The 10 Laws of Smart Object Security Design by Hannes 1264 Tschofenig, and Bernard Aboba 1266 68. Position Paper on "In-Network Object Cloud" Architecture and 1267 Design Goals by Alex Galis, and Stuart Clayman 1269 69. Temptations and Difficulties of Protocols for Smart Objects and 1270 the Internet by Alexandru Petrescu 1272 70. The Internet of Things - Challenge for a New Architecture from 1273 Problems by Gyu Myoung Lee, and Noel Crespi 1275 71. Garrulity and Fluff by Carsten Bormann, and Klaus Hartke 1277 These papers can be retrieved from: 1278 http://www.iab.org/about/workshops/smartobjects/papers/ 1280 The slides are available for download at the following webpage: 1281 http://www.iab.org/about/workshops/smartobjects/agenda.html 1283 Detailed meeting minutes are published here: 1284 http://www.iab.org/about/workshops/smartobjects/minutes.html 1286 Appendix C. Workshop Participants 1288 We would like to than the following workshop participants for 1289 attending the workshop: 1291 o Adrian Farrel 1293 o Akbar Rahman 1295 o Alissa Cooper 1297 o Alper Yegin 1299 o Anastasios Zafeiropoulos 1301 o Anders Brandt 1303 o Angelo P. Castellani 1305 o Antonio F. G. Skarmeta 1307 o Antonio Jara 1309 o Arvind Ramrekha 1311 o Behcet Sarikaya 1313 o Bernard Aboba 1315 o Bruce Nordman 1317 o Carsten Bormann 1319 o Cullen Jennings 1321 o Daniel Barisic 1323 o Dave Thaler 1325 o Davide Barbieri 1327 o Diego Casado Mansilla 1329 o Dirk Kutscher 1331 o Dominique Barthel 1332 o Dorothy Gellert 1334 o Elwyn Davis 1336 o Emmanuel Baccelli 1338 o Fred Baker 1340 o Guido Moritz 1342 o Gyu Myoung Lee 1344 o Hannes Tschofenig 1346 o Hui Deng 1348 o Ivan Gudymenko 1350 o Jaacan Martinez 1352 o Jari Arkko 1354 o Jaroslav Meduna 1356 o Jeff Burke 1358 o Johanna Nieminen 1360 o Jonathan Hui 1362 o Jonne Soininen 1364 o Jouni Korhonen 1366 o JP Vasseur 1368 o Karel Pavlata 1370 o Klaus Hartke 1372 o Lars Eggert 1374 o Laura Gheorghe 1376 o Laurent Toutain 1378 o Lukas Kencl 1379 o Marcelo Bagnulo 1381 o Marco Valente 1383 o Margaret Wasserman 1385 o Markus Isomaki 1387 o Markus Wehner 1389 o Masanobu Katagi 1391 o Mathilde Durvy 1393 o Mehmet Ersue 1395 o Mikko Pitkaenen 1397 o Milan Simek 1399 o Neeli R. Prasad 1401 o Nicolas Dejean 1403 o Ning Kong 1405 o Pascal Thubert 1407 o Paulo Mendes 1409 o Pete Resnick 1411 o Peter van der Stok 1413 o Ralph Droms 1415 o Rene Hummen 1417 o Ross Callon 1419 o Ruediger Martin 1421 o Russ Housley 1423 o Ryota Ishibashi 1425 o Ryuji Wakikawa 1426 o Samita Chakrabarti 1428 o Sandra Dominikus 1430 o Sean Shen 1432 o Sean Turner 1434 o Shahid Raza 1436 o Shoichi Sakane 1438 o Spencer Dawkins 1440 o Stephan Haller 1442 o Stephen Farrell 1444 o Stewart Bryant 1446 o Subir Das 1448 o Suresh Krishnan 1450 o Tea Sang Choi 1452 o Tero Kivinen 1454 o Theodore Zahariadis 1456 o Thomas Clausen 1458 o Tim Polk 1460 o Tina Tsou 1462 o Tsuyoshi Momose 1464 o Vladimir Cervenka 1466 o Wassim Haddad 1468 o Woojik Chun 1470 o Zach Shelby 1472 Authors' Addresses 1474 Hannes Tschofenig 1475 Nokia Siemens Networks 1476 Linnoitustie 6 1477 Espoo 02600 1478 Finland 1480 Phone: +358 (50) 4871445 1481 Email: Hannes.Tschofenig@gmx.net 1482 URI: http://www.tschofenig.priv.at 1484 Jari Arkko 1485 Ericsson 1486 Jorvas 02420 1487 Finland 1489 Email: jari.arkko@piuha.net