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