idnits 2.17.1 draft-iab-smart-object-workshop-09.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 (January 18, 2012) is 4475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2222' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC5582' is defined on line 1063, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 8 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: July 21, 2012 Ericsson 6 January 18, 2012 8 Report from the 'Interconnecting Smart Objects with the Internet' 9 Workshop, 25th March 2011, Prague 10 draft-iab-smart-object-workshop-09.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 Note that this document is a report on the proceedings of the 24 workshop. The views and positions documented in this report are 25 those of the workshop participants and do not necessarily reflect IAB 26 views and positions. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 21, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 5 64 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 7 67 3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 8 68 3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10 69 3.2. Sleep Nodes . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 17 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 76 8. Informative References . . . . . . . . . . . . . . . . . . . . 24 77 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29 78 Appendix B. Workshop Materials . . . . . . . . . . . . . . . . . 30 79 Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 31 80 Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 36 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 83 1. Introduction 85 The Internet Architecture Board (IAB) holds occasional workshops 86 designed to consider long-term issues and strategies for the 87 Internet, and to suggest future directions for the Internet 88 architecture. This long-term planning function of the IAB is 89 complementary to the ongoing engineering efforts performed by working 90 groups of the Internet Engineering Task Force (IETF), under the 91 leadership of the Internet Engineering Steering Group (IESG) and area 92 directorates. 94 Today's Internet is experienced by users as a set of applications, 95 such as email, instant messaging, and services on the Web. While 96 these applications do not require users to be present at the time of 97 service execution, in many cases they are. There are also 98 substantial differences in performance among the various end devices, 99 but in general end devices participating in the Internet are 100 considered to have high performance. 102 There are, however, a large number of deployed embedded devices and 103 there is substantial value in interconnecting them with the Internet. 104 The term "Internet of Things" denotes a trend where a large number of 105 devices employ communication services offered by the Internet 106 Protocols. Many of these devices are not directly operated by 107 humans, but exist as components in buildings, vehicles, and the 108 environment. There is a large variation in the computing power, 109 available memory, (electrical) power, and communications bandwidth 110 between different types of devices. 112 Many of these devices offer a range of new possibilities or provide 113 additional value for previously unconnected devices. Some devices 114 have been connected using proprietary communication networks in the 115 past but are now migrating to the use of the Internet Protocol suite 116 in order to share the same communication network between all 117 applications and to enable rich communications services. 119 Much of this development can simply run on existing Internet 120 protocols. For instance, home entertainment and monitoring systems 121 often offer a web interface to the end user. In many cases the new, 122 constrained environments can benefit from additional protocols and 123 protocol extensions that help optimize the communications and lower 124 the computational requirements. Examples of currently ongoing 125 standardization efforts targeted for these environments include the 126 "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN 127 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 128 the "Light-Weight Implementation Guidance (LWIG)" working groups at 129 the IETF. 131 This workshop explored the experiences of researchers and developers 132 when considering the characteristics of constrained devices. 133 Engineers know that many design considerations need to be taken into 134 account when developing protocols and architecture. Balancing 135 between the conflicting goals of code size, economic incentives, 136 power consumption, usability and security is often difficult, as 137 illustrated by Clark, et al. in "Tussle in Cyberspace: Defining 138 Tomorrow's Internet" [Tussle]. 140 Participants at the workshop discussed the experience and approaches 141 taken when designing protocols and architectures for interconnecting 142 smart objects to the Internet. The scope of the investigations 143 included constrained nodes as well as constrained networks. 145 The call for position papers suggested investigating the area of 146 integration with the Internet in the following categories: 148 o Scalability 150 o Power efficiency 152 o Interworking between different technologies and network domains 154 o Usability and manageability 156 o Security and Privacy 158 The goals of the workshop can be summarized as follows: 160 As many deployed smart objects demonstrate, running protocols like 161 the Internet Protocol Version 4 [RFC0791] and Version 6 [RFC2460], 162 the User Datagram Protocol (UDP) [RFC0768], the Transmission 163 Control Protocol (TCP) [RFC0793], the Hypertext Transfer Protocol 164 (HTTP) [RFC2616], etc., on constrained devices is clearly 165 possible. Still, protocol designers, system architects and 166 developers have to keep various limitations in mind. The 167 organizers were interested to discuss the experience with 168 deploying IETF protocols in different constrained environments. 170 Furthermore, the organizers were seeking to identify either issues 171 where current implementers do not yet have solutions or where 172 researchers predict potential issues. 174 The workshop served as a venue to identify problems and to 175 discover common interests that may turn into new work or into 176 changes in direction of already ongoing work at the IETF and or 177 the Internet Research Task Force (IRTF). 179 2. Constrained Nodes and Networks 181 The workshop was spurred by the increasing presence of constrained 182 devices on the network. It is quite natural to ask how these 183 limitations impact the design of the affected nodes. Note that not 184 all nodes suffer from the same set of limitations. 186 Energy constraints: 188 Since wireless communication can be a large portion of the power- 189 budget for wireless devices, reducing unnecessary communication 190 can significantly increase the battery life of a low-end device. 191 The choice of low-power radio can also significantly impact the 192 overall energy consumption, as can sleeping periodically, when the 193 device is not in use. In some cases, these nodes will only wake 194 periodically to handle needed communications. This constraint is 195 quite in contrast to the "always on" paradigm found in regular 196 Internet hosts. Even in the case of non-battery operated devices, 197 power is a constraint with respect to energy efficiency goals. 199 Bandwidth constraints: 201 Various low power radio networks offer only ~100 kbit/s or even 202 only a few KBits/s, and show high packet loss as well as high link 203 quality variability. Nodes may be used in usually highly unstable 204 radio environments. The physical layer packet size may be limited 205 (~100 bytes). 207 Memory constraints: 209 The amount of volatile and persistent storage impacts the program 210 execution has important implications for the functionality of the 211 protocol stack. The Arduino UNO board, for example, provides a 212 developer with 2 KByte RAM and 32 KByte flash memory (without any 213 extensions, such as microSD cards). 215 A system designer also needs to consider CPU constraints, which often 216 relate to energy constraints: a processor with lower performance 217 consumes less energy. As described later in this document, the 218 design of the mainboard may allow certain components to be put to 219 sleep to further lower energy consumption. In general, embedded 220 systems are often purpose built with only the hardware components 221 needed for the given task while general purpose personal computers 222 are less constrained with regard to their mainboard layout and 223 typically offer a huge number of optional plug-in peripherals to be 224 connected. A factor that also has to be taken into consideration is 225 the intended usage environment. For example, a humidity sensor 226 deployed outside a building may need to deal with temperatures from 227 -50 C to +85 C. There are often physical size limitations for smart 228 objects. While traditional mainboards are rather large, such as the 229 Advanced Technology eXtended (ATX) design with a board size of 305 x 230 244 mm available in many PCs or the mini-ITX design typically found 231 in home theater PCs with 170 x 170 mm, mainboard layouts for embedded 232 systems are typically much smaller, such as the CoreExpress layout 233 with 58 x 65 mm, or even smaller. In addition to the plain mainboard 234 additional sensors, peripherals, a power adapter/battery, and a case 235 have to be taken into consideration. Finally, there are cost 236 restrictions as well. 238 The situation becomes more challenging when not only the hosts are 239 constrained but also the network nodes themselves. 241 While there are constantly improvements being made, Moore's law tends 242 to be less effective in the embedded system space than in personal 243 computing devices: Gains made available by increases in transistor 244 count and density are more likely to be invested in reductions of 245 cost and power requirements than into continual increases in 246 computing power. 248 3. Workshop Structure 250 With the ongoing work on connecting smart objects to the Internet 251 there are many challenges the workshop participants raised in more 252 than 70 accepted position papers. With a single workshop day 253 discussions had to be focused and priority was given to those topics 254 that had been raised by many authors. A summary of the identified 255 issues are captured in the subsections below. 257 3.1. Architecture 259 A number of architectural questions were brought up in the workshop. 260 This is natural, as the architectural choices affect the required 261 technical solutions and the need for standards. At this workshop 262 questions regarding the separation of traffic, the need for profiling 263 for application specific domains, the demand for data model specific 264 standardization, as well as the design choices of the layer at which 265 functionality should be put were discussed and are briefly summarized 266 below. 268 3.1.1. One Internet vs. Islands 270 Devices that used to be in proprietary or application-specific 271 networks are today migrating to IP networks. There is, however, the 272 question of whether these smart objects are now on the same IP 273 network as any other application. Controlled applications, like the 274 fountains in front of the Bellagio hotel in Las Vegas that are 275 operated as a distributed control system [Dolin], probably are not 276 exchanging their control messages over the same network that is also 277 used by hotel guests for their Internet traffic. The same had been 278 argued for smart grids, which are described as "A smart grid is a 279 digitally enabled electrical grid that gathers, distributes, and acts 280 on information about the behavior of all participants (suppliers and 281 consumers) in order to improve the efficiency, reliability, 282 economics, and sustainability of electricity services." [SmartGrid]. 283 The question that was raised during the workshop is therefore in what 284 sense are we talking about one Internet or about using IP technology 285 for a separate, walled garden network that is independent of the 286 Internet? 288 Cullen Jennings compared the current state of smart object deployment 289 with the evolution of voice-over-IP: "Initially, many vendors 290 recommended to run VoIP over a separate VLAN or a separate 291 infrastructure. Nobody could imagine how to make the type of real- 292 time guarantees, how to debug it, and how to get it to work because 293 the Internet is not ideally suited for making any types of guarantees 294 for real-time systems. As time went on people got better at making 295 voice work across that type of IP network. They suddenly noticed 296 that having voice running on a separate virtual network than their 297 other applications was a disaster. They couldn't decide if a PC was 298 running a softphone and whether it went on a voice or a data network. 299 At that point people realized that they needed a converged network 300 and all moved to one. I wouldn't be surprised to see the same 301 happens here. Initially, we will see very separated networks. Then, 302 those will be running over the same hardware to take advantage of the 303 cost benefits of not having to deploy multiple sets of wires around 304 buildings. Over time there will be strong needs to directly 305 communicate with each other. We need to be designing the system for 306 the long run. Assume everything will end up on the same network even 307 if you initially plan to run it in separate networks." 309 It is clearly possible to let sensors in a building communicate 310 through the wireless access points and through the same 311 infrastructure used for Internet access, if you want to. Those who 312 want separation at the physical layer can do so as well. What is 313 important is to make sure that these different deployment 314 philosophies do not force loss of interoperability. 316 The level of interoperability that IP accomplished fostered 317 innovation at the application layer. Ralph Droms reinforced this 318 message by saying: "Bright people will take a phone, build an 319 application and connect it, with the appropriate security controls in 320 place, to the things in my house in ways we have never thought about 321 before. Otherwise we are just building another telephone network." 323 3.1.2. Domain Specific Stacks and Profiles 325 Imagine a building network scenario where a new light bulb is 326 installed that should, out of the box without further configuration, 327 interoperate with the already present light switch from a different 328 vendor in the room. For many this is the desired level of 329 interoperability in the area of smart object design. To accomplish 330 this level of interoperability it is not sufficient to provide 331 interoperability only at the network layer. Even running the same 332 transport protocol and application layer protocol (e.g., HTTP) is 333 insufficient since both devices need to understand the semantics of 334 the payloads for "Turn the light on" as well. 336 Standardizing the entire protocol stack for this specific "light 337 switch/light bulb" scenario is possible. A possible stack would, for 338 example, use IPv6 with a specific address configuration mechanism 339 (such as stateless address autoconfiguration), a network access 340 authentication security mechanism such as Protocol for carrying 341 Authentication for Network Access (PANA) [RFC5191], a service 342 discovery mechanism (e.g., multicast DNS with DNS-SD 343 [I-D.cheshire-dnsext-dns-sd]), an application layer protocol, for 344 example, Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] 345 (which uses UDP), and the syntax and semantic for the light on/off 346 functionality. 348 As this list shows there is already some amount of protocol 349 functionality that has to be agreed on by various stakeholders to 350 make this scenario work seamlessly. As we approach more complex 351 protocol interactions the functionality quickly becomes more complex: 352 IPv4 and IPv6 on the network layer, various options at the transport 353 layer (such as UDP, TCP, the Stream Control Transmission Protocol 354 (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) 355 [RFC4340]), and there are plenty of choices at the application layer 356 with respect to communication protocols, data formats and data 357 models. Different requirements have led to the development of a 358 variety of communication protocols: client-server protocols in the 359 style of the original HTTP, publish-subscribe protocols (like Session 360 Initiation Protocol (SIP) [RFC3261] or Extensible Messaging and 361 Presence Protocol (XMPP) [RFC3921]), store-and-forward messaging 362 (borrowed from the delay tolerant networking community). Along with 363 the different application layer communication protocols come various 364 identity and security mechanisms. 366 With the smart object constraints it feels natural to develop these 367 stacks since each application domain (e.g., health-care, smart grids, 368 building networking) will have their unique requirements and their 369 own community involved in the design process. How likely are these 370 profiles going to be the right match for the future, specifically for 371 the new innovations that will come? How many of these stacks are we 372 going to have? Will the differences in the profiles purely be the 373 result of different requirements coming from the individual 374 application domains or will these mismatches reflect the spirit, 375 understanding and preferences of the community designing them? How 376 many stacks will multi-purpose devices have to implement? 378 Standardizing profiles independently for each application is not the 379 only option. Another option is to let many different applications 380 utilize a common foundation, i.e., a protocol stack that is 381 implemented and utilized by every device. This, however, requires 382 various application domains to be analyzed for their common 383 characteristics and to identify requirements that are common across 384 all of them. The level of difficulty for finding an agreement of how 385 such a foundation stack should look depends on how many layers it 386 covers and how lightweight it has to be. 388 From the discussions at the workshop it was clear that the available 389 options are not ideal and further discussions are needed. 391 3.1.3. Which Layer? 393 The end-to-end principle states that functionality should be put into 394 the end points instead of into the networks. An additional 395 recommendation, which is equally important, is to put functionality 396 higher up in the protocol stack. While it is useful to make common 397 functionality available as building blocks to higher layers the wide 398 range of requirements by different applications led to a model where 399 lower layers provide only very basic functionality and more 400 sophisticated features were made available by various applications. 401 Still, there has been the desire to put application layer 402 functionality into the lower layers of the networking stack. A 403 common belief is that performance benefits can be gained if 404 functionality is placed at the lower layers of the protocol stack. 405 This new functionality may be offered in the form of a gateway, which 406 bridges different communication technologies, acts on behalf of other 407 nodes, and offers more generic functionality (such as name-based 408 routing and caching). 410 Two examples of functionality offered at the network layer discussed 411 during the workshops were location and name-based routing: 413 Location: 415 The notion of location gives each network node the understanding 416 of proximity (e.g., 'I am a light bulb and in the same room as the 417 light switch.'). Today, a router may provide information as to 418 whether other nodes belong to the same subnet or they may provide 419 location information (for example, in the form of GPS based 420 coordinates). However, providing a sense of the specific 421 environment (e.g., a room, building, campus, etc.) is not possible 422 without manual configuration. While it has been a desirable 423 feature for many ubiquitous computing applications to know this 424 type of information and to use it for richer application layer 425 interactions, widespread deployment has not happened yet. 427 Name-based Routing: 429 With the work on recent clean slate architecture proposals, such 430 as named data networking, flexible naming concepts are being 431 researched to allow application developers to express their 432 application layer concepts in a way that they can be used natively 433 by the underlying networking stack without translation. For 434 example, Jeff Burke provided the example of his work in a theater 435 with a distributed control system of technical equipment (such as 436 projectors, dimmers, and light systems). Application developers 437 name their equipment with human readable identifiers, which may 438 change after the end of a rehearsal, and address them using these 439 names. These variable length based naming concepts raise 440 questions regarding scalability. 442 The workshop participants were not able to come to an agreement about 443 what functionality should be moved from the application layer to the 444 network layer. 446 3.2. Sleep Nodes 448 One limitation of smart objects is their available energy. To extend 449 battery life, for example of a watch battery or single AAA battery 450 for months, these low power devices have to sleep 99% to 99.5% of 451 their time. For example, a light sensor may only wake up to check 452 whether it is night-time to turn on light bulbs. Most parts of the 453 system, particularly communication components, are put into a 454 sleeping state (e.g., WLAN radio interface) and selected components, 455 such as sensors, periodically check for relevant events and, if 456 necessary, turn on other hardware modules. Every bit is precious, as 457 is every round trip, and every millisecond of radio activity. 459 Many IETF protocols are implicitly designed to be always-on, i.e., 460 the protocol implementation waits for and reacts to incoming 461 messages, and may maintain session state (at various layers of the 462 stack). These protocols work well when energy consumption is not a 463 concern and where receiving and sending messages happens at a low 464 cost. It should be understood that energy is consumed both in 465 transmitting messages (and often more importantly) in keeping the 466 receiver awake. Allowing devices to sleep most of the time preserves 467 energy but creates challenges for protocol designs. 469 The inherent issue encountered by a stationary node resuming from 470 sleep is that another node may have chosen the same address while the 471 node was asleep. A number of steps have to be taken before sending a 472 packet. A new address may have to be obtained, for example using the 473 Dynamic Host Configuration Protocol (DHCP) or stateless address 474 autoconfiguration. Optionally, Detecting Network Attachment (DNA) 475 procedures (see [RFC4436] and [RFC6059]) can be used to utilized to 476 shorten the setup time by noticing that the node is using the same 477 default gateway. 479 The issue with a mobile node that is sleeping is that the node may 480 have been moved to another network (e.g., a sleeping laptop being 481 transported to a new environment) where on resumption it may discover 482 that its address has become invalid. 484 The following design considerations should be taken into account when 485 energy efficiency is a concern: 487 1. Rethink the Always-On Assumption 489 When designing a protocol that assumes that the nodes are always 490 on, alternatives need to be considered. This could involve 491 eliminating functionality (e.g., not implementing DNA or 492 duplicate address detection) or considering the use of a sleep 493 proxy. While sleep proxies (e.g., proxZzzy [proxZzzy]) enable 494 periodic messages to be sent on behalf of sleeping nodes, this 495 approach assumes that that energy management constraints do not 496 apply to the sleep proxy, which may not always be the case (e.g., 497 if the entire network is deployed in the field without access to 498 power). Yet another option is for devices to explicitly 499 communicate sleep cycles so that they can only check for messages 500 periodically (be it measured in msec, sec, or hours). This is 501 the approach taken in IEEE 802.11, which supports multiple energy 502 conservation mechanisms designed to enable a station to spend a 503 large fraction of the time sleeping. 505 2. Lower Network Attachment Costs 507 As noted above, the procedures for obtaining an address and 508 assuring its uniqueness can be costly. In a network where nodes 509 spend a large fraction of the time sleeping, but are not 510 necessarily mobile, are all of these procedures really necessary? 512 Can we find ways to reduce the number of protocol interactions 513 without sacrificing correctness? The main focus of past 514 investigations has been on IPv6 and ND but other protocols do 515 also deserve a deeper investigation, such as DNS, and DHCP. 517 3. Avoid Verbose Protocols 519 Protocols which were originally designed for communication 520 between humans and devices are now being potentially considered 521 for device to device communications. Examples include HTTP, SIP 522 and XMPP. 524 The problem is that protocols involving multiple roundtrips 525 and/or lengthy messages with verbose encodings (e.g., XML) are 526 not always well suited for device to device communication. Low- 527 power nodes utilizing verbose protocols have to use more power in 528 sending messages and have to stay powered on for a longer period 529 of time as they wait for the protocol exchanges to complete. 531 The best way to address these problems is to ensure that the 532 simplest possible protocol exchanges are used when the protocols 533 in question are designed. However, in some cases alternative 534 encoding formats and compression may also help. 536 4. System-wide efficiency 538 While energy efficiency is critical for low-power devices powered 539 by batteries, it is also beneficial for other devices as well, 540 including notebooks, desktops and smartphones. However, if the 541 goal is energy efficiency as opposed to battery life extension 542 for low-power devices, then it is important to consider the total 543 energy consumption of all the elements of the system. 545 For example, consider energy consumption in a home environment. 546 In these scenarios it is important to evaluate the energy usage 547 of the entire system. A light bulb utilizing Internet technology 548 described in this document may use less power but there is also 549 the device that controls the bulb that may consume a lot of 550 energy. If the goal is to reduce overall energy usage, then it 551 is important to consider these two devices (and potentially many 552 others) 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) 577 [AES]) as a building block for all cryptographic functions with the 578 benefit of a smaller footprint of the overall solution, specifically 579 with respect to hardware limitations (e.g., the hardware architecture 580 of 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 [ECC] to find 587 deployment can partially be attributed to its IPR situation. The 588 reuse of libraries providing cryptographic functions is clearly an 589 important way to use available memory resources in a more efficient 590 way. To deal with the performance and footprint concerns 591 investigations into offloading certain resource-hungry functions to 592 parties that possess more cryptographic power have been considered. 593 For example, the ability to delegate certificate validation to 594 servers has been standardized in the IETF before; for the support of 595 the Online Certificate Status Protocol (OCSP) in the Internet Key 596 Exchange protocol version 2 (IKEv2) and in Transport Layer Security 597 (TLS), see [RFC4806] and [RFC3546], respectively. 599 Focusing only on the cryptographic primitives would be shortsighted; 600 many would argue that this is the easy part of a smart object 601 security solution. Key management and credential enrollment, 602 however, are considered a big challenge by many particularly when 603 usability requirements have to be taken into account. Another group 604 of challenges concern privacy; with smart grids, for example, some 605 have voiced concerns regarding the ability of third parties to keep 606 track of an individual's energy consumption (and draw associated 607 conclusions). As another example, it is easy to see how a scale that 608 is connected to the Internet for uploading weight information to a 609 social network could lead to privacy concerns. While security 610 mechanisms used to offer protection of the communication between 611 different parties also provide a certain degree of privacy protection 612 they are clearly not enough to address all concerns. Even with the 613 best communication security and access control mechanisms in place 614 one still needs additional safeguards against the concerns mentioned 615 in the examples. 617 While a lot can be said about how desirable it would be to deploy 618 more security protocols on the entire Internet, practical 619 considerations regarding usability and the incentives of the 620 stakeholders involved have often lead to slower adoption. 622 3.4. Routing 624 A smart object network environment may also employ routers under 625 similar constraints as the end devices. Currently two approaches to 626 routing in these low power and lossy networks are under 627 consideration, namely mesh-under and route-over. The so-called mesh- 628 under approach places routing functions at the link layer and 629 consequently all devices appear as immediate neighbors at the network 630 layer. With the route-over approach routing is done at the IP layer 631 and none in the link layer. Each physical hop appears as a single IP 632 hop (ignoring devices that just extend the physical range of 633 signaling, such as repeaters). Routing in this context means running 634 a routing protocol. IPv6 Routing Protocol for Low power and Lossy 635 Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the 636 route-over category. 638 From an architectural point of view there are several questions that 639 arise from where routing is provided, for example: 641 o Protocols often assume that link characteristics are predictable 642 when communicating with any device attached to the same link. 643 Latency, throughput, and reliability may vary considerably between 644 different devices that are multiple link layer hops away. What 645 timeout should be used? What happens if a device is unreachable? 646 In case of default router selection two advertised routers may be 647 a different number of hops away. Should a device have visibility 648 into the path to make a decision and what path characteristics 649 would be useful to have? 651 o Scoped message delivery to a neighboring IP hop (via link-local 652 addressing) allows certain types of IP protocols to communicate 653 with their immediate neighbors and to therefore scope their 654 recipients. A link-local multicast message will be received by 655 all nodes in the same IP link local realm unless some special 656 optimizations are provided by the link layer. 658 o When path computations are done at the link layer as well as on 659 the network layer then what coordination needs to take place? 661 When multiple different link layer technologies are involved in a 662 network design, routing at layer 3 has to be provided in any case. 663 [I-D.routing-architecture-iot] talks about these tradeoffs between 664 route-over and mesh-under in detail. Furthermore, those who decide 665 about the deployment have to determine how to connect smart objects 666 to the Internet infrastructure and a number of wired and wireless 667 technologies may be suitable for a specific deployment. Depending on 668 the chosen technologies the above-mentioned mesh-under vs. route-over 669 approach will have to be decided and further decisions will have to 670 be made about the choice of a specific routing protocol. 672 In 2008 the IETF formed the Routing Over Low power and Lossy networks 673 (ROLL) working group to specify a routing solution for smart object 674 environments. During its first year of existence, the working group 675 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 modes, energy 698 consumption), to focus on some details of the protocol stack 699 (neighbor 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 sacrificing the 715 overall security level, taking the usability of the entire system 716 into 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 residential 737 networks but was terminated prematurely due to lack of 738 progress. The email archive still exists and is available 740 [enroll] and may provide useful historical information. 742 * Standardized authentication and key exchange mechanisms should 743 be surveyed for suitability in smart object environments with 744 respect to message size, computational performance, number of 745 messages, codesize, and main memory requirements. A starting 746 point of such an investigation (in case of IKEv2) was provided 747 by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a 748 suitable venue for discussion could be the recently established 749 Light-Weight Implementation Guidance (LWIG) working group 750 [LWIG]. 752 * Research has to be done in the area of lightweight 753 cryptographic primitives, namely block ciphers, stream ciphers, 754 and cryptographic hash functions. Worthwhile to mention is 755 early work with the National Institute of Standards and 756 Technology (NIST) new cryptographic hash algorithm 'SHA-3' 757 competition [SHA3]. A suitable forum for discussion is the 758 IRTF Crypto Forum Research Group (CFRG) [CFRG]. 760 The difficulty and impact of choosing specialised algorithms for 761 smart objects should not be underestimated. Issues that arise 762 include the additional specification complexity (e.g., TLS already 763 has 100's of ciphersuites defined, most of which are unused in 764 practice), the long latency in terms of roll out (many hosts are 765 still using deprecated algorithms 5-10 years after those 766 algorithms were deprecated) and the barriers that IPR-encumbered 767 schemes present to widespread deployment. While research on this 768 topic within CFRG and the cryptographic research community is a 769 very worthwhile goal, any such algorithms will likely have to 770 offer very significant benefits before they will be broadly 771 adopted. 20% less CPU is unlikely to be a winning argument no 772 matter what an algorithm inventor believes. 774 Energy Design Considerations: 776 One part of the workshop was focused on the discussion of energy 777 implications for IETF protocol design with proposals being made 778 about how to extend protocols to better support nodes that are 779 mostly sleeping. Discussion are encouraged to take place at the 780 RECIPE mailing list [RECIPE]. The workshop position paper 781 [Wasserman] by Margaret Wasserman provides a good starting point 782 for further investigations. 784 Information/Content Centric Networking: 786 Information/Content Centric Networking is about accessing named 787 content and a number of research projects have emerged around this 788 theme. At this point in time the work is not yet ready for 789 standardization in the IETF. Instead, the formation of an IRTF 790 research group has been proposed and more details are available on 791 the IRTF DISCUSS mailing list [irtf-discuss]. 793 Architectural Guidelines: 795 Participants suggested developing an architectural write-up about 796 what can be done with the IETF protocols we have today and how 797 these different elements may be combined to offer an explanation 798 for the broader community. This would be a task for the Internet 799 Architecture Board (IAB). An example of prior work that serves as 800 input is [RFC6272]. 802 Network Management: 804 While this topic did not make it onto the workshop agenda it was 805 considered useful to start a discussion about how to implement 806 network management protocols, such as Network Configuration 807 Protocol (NETCONF) [RFC6241], on smart objects. The following 808 position papers may be useful as a starting point for further 809 discussions [Ersue], [Schoenwaelde]. An IETF draft is also 810 available [I-D.hamid-6lowpan-snmp-optimizations]. 812 Congestion Control: 814 When smart objects transmit sensor readings to some server on the 815 Internet then these protocol interactions often carry a small 816 amount of data and happen infrequently, although regularly. With 817 the work on new application protocols, like the CoAP 818 [I-D.ietf-core-coap], the question of whether a congestion control 819 mechanism should be used at the underlying transport protocol or 820 by the application protocol itself arises. 821 [I-D.eggert-core-congestion-control] is a starting point for the 822 CoAP protocol but further work is needed. 824 Data Models: 826 Standardization of application layer protocols is important but 827 does not ensure that, for example, a light switch and a light bulb 828 are able to interact with each other. One area where participants 829 saw the need for further work was in the area of data models. 830 While prior IETF standardization work on, for example, location 831 [GEOPRIV] can be re-used the question was raised where the IETF 832 should focus its standardization efforts since domain expertise in 833 each area will be needed. As a potential example, energy pricing 834 was discussed, with an example provided by 835 [I-D.jennings-energy-pricing]. 837 Discovery: 839 Additional extensions to developed discovery protocols (such as 840 mDNS) may be needed for the smart object environment. 842 Building Networking: 844 Network architectures in residential as well as commercial 845 buildings should take the presence of smart objects and dedicated 846 subnetworks focusing on smart objects into account. A new working 847 group, Home Networking (HOMENET) [FUN], has been created after the 848 workshop to look at this topic. 850 Routing: 852 Changing radio conditions and link fluctuation may lead to the 853 need for re-numbering. Workshop participants argued that work 854 should be started on the multi-link subnetworks to mitigate this 855 problem, i.e., to extend the notion of a subnet to be able to span 856 multiple links. With the publication of RFC 4903 [RFC4903] the 857 Internet Architecture Board had looked into this topic already and 858 provided pros and cons. 860 The applicability of specific routing protocols designed for smart 861 object networks needs further investigation. The ROLL working 862 group is chartered with the task of constructing an applicability 863 document for the RPL protocol, for instance. 865 5. Security Considerations 867 The workshop discussions covered a range of potential engineering 868 activities, each with its own security considerations. As the IETF 869 community begins to pursue specific avenues arising out of this 870 workshop, addressing relevant security requirements will be crucial. 872 As described in this report part of the agenda was focused on the 873 discussion of security, see Section 3.3. 875 6. Acknowledgements 877 We would like to thank all the participants for their position 878 papers. The authors of the accepted position papers were invited to 879 the workshop. 881 Big thanks to Elwyn Davies for helping us to fix language bugs. We 882 would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas 883 Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, 884 and Henning Schulzrinne for their review comments. 886 Additionally, we would like to thank Ericsson and Nokia Siemens 887 Networks for their financial support. 889 7. IANA Considerations 891 This document does not require actions by IANA. 893 8. Informative References 895 [AES] "Wikipedia Entry for 'Advanced Encryption Standard'", 896 http://en.wikipedia.org/wiki/ 897 Advanced_Encryption_Standard , Dec 2011. 899 [CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group 900 (CFRG)", http://irtf.org/cfrg , June 2011. 902 [Clausen] Clausen, T. and U. Herberg, "Some Considerations on 903 Routing in Particular and Lossy Environments", IAB 904 Interconnecting Smart Objects with the Internet Workshop, 905 Prague, Czech Republic, http://www.iab.org/wp-content/ 906 IAB-uploads/2011/03/Clausen.pdf, March 2011. 908 [Dolin] Dolin, B., "Application Communications Requirements for 909 'The Internet of Things'", IAB Interconnecting Smart 910 Objects with the Internet Workshop, Prague, Czech Republic 911 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 912 Ersue.pdf, March 2011. 914 [ECC] "Wikipedia Entry for 'Elliptic Curve Cryptography'", 915 http://en.wikipedia.org/wiki/Elliptic_curve_cryptography , 916 Dec 2011. 918 [Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object 919 Workshop Position Paper", IAB Interconnecting Smart 920 Objects with the Internet Workshop, Prague, Czech Republic 921 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 922 Ersue.pdf, March 2011. 924 [FUN] "FUture home Networking (FUN) Mailing List", 925 https://www.ietf.org/mailman/listinfo/fun , June 2011. 927 [GEOPRIV] "IETF Geographic Location/Privacy Working Group", 928 http://datatracker.ietf.org/wg/geopriv/ , June 2011. 930 [I-D.cheshire-dnsext-dns-sd] 931 Cheshire, S. and M. Krochmal, "DNS-Based Service 932 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 933 progress), December 2011. 935 [I-D.eggert-core-congestion-control] 936 Eggert, L., "Congestion Control for the Constrained 937 Application Protocol (CoAP)", 938 draft-eggert-core-congestion-control-01 (work in 939 progress), January 2011. 941 [I-D.hamid-6lowpan-snmp-optimizations] 942 Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP 943 Optimizations for Constrained Devices", 944 draft-hamid-6lowpan-snmp-optimizations-03 (work in 945 progress), October 2010. 947 [I-D.ietf-core-coap] 948 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 949 "Constrained Application Protocol (CoAP)", 950 draft-ietf-core-coap-08 (work in progress), October 2011. 952 [I-D.ietf-roll-protocols-survey] 953 Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview 954 of Existing Routing Protocols for Low Power and Lossy 955 Networks", draft-ietf-roll-protocols-survey-07 (work in 956 progress), April 2009. 958 [I-D.ietf-roll-rpl] 959 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 960 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 961 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 962 Lossy Networks", draft-ietf-roll-rpl-19 (work in 963 progress), March 2011. 965 [I-D.jennings-energy-pricing] 966 Jennings, C. and B. Nordman, "Communication of Energy 967 Price Information", draft-jennings-energy-pricing-01 (work 968 in progress), July 2011. 970 [I-D.kivinen-ipsecme-ikev2-minimal] 971 Kivinen, T., "Minimal IKEv2", 972 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 973 February 2011. 975 [I-D.routing-architecture-iot] 976 Hui, J. and J. Vasseur, "Routing Architecture in Low-Power 977 and Lossy Networks (LLNs)", 978 draft-routing-architecture-iot-00 (work in progress), 979 March 2011. 981 [LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 982 Group", http://datatracker.ietf.org/wg/lwig/charter/ , 983 June 2011. 985 [RECIPE] "Reducing Energy Consumption with Internet Protocols 986 Exploration (RECIPE) Mailing List", 987 https://www.ietf.org/mailman/listinfo/recipe , June 2011. 989 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 990 August 1980. 992 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 993 September 1981. 995 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 996 RFC 793, September 1981. 998 [RFC2222] Myers, J., "Simple Authentication and Security Layer 999 (SASL)", RFC 2222, October 1997. 1001 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1002 (IPv6) Specification", RFC 2460, December 1998. 1004 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1005 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1006 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1008 [RFC2743] Linn, J., "Generic Security Service Application Program 1009 Interface Version 2, Update 1", RFC 2743, January 2000. 1011 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1012 A., Peterson, J., Sparks, R., Handley, M., and E. 1013 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1014 June 2002. 1016 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1017 and T. Wright, "Transport Layer Security (TLS) 1018 Extensions", RFC 3546, June 2003. 1020 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1021 Text on Security Considerations", BCP 72, RFC 3552, 1022 July 2003. 1024 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1025 Demand Distance Vector (AODV) Routing", RFC 3561, 1026 July 2003. 1028 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1029 Levkowetz, "Extensible Authentication Protocol (EAP)", 1030 RFC 3748, June 2004. 1032 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1033 Protocol (XMPP): Instant Messaging and Presence", 1034 RFC 3921, October 2004. 1036 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1037 June 2005. 1039 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1040 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1042 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1043 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1045 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 1046 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 1047 February 2007. 1049 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1050 June 2007. 1052 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1053 RFC 4960, September 2007. 1055 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1056 Yegin, "Protocol for Carrying Authentication for Network 1057 Access (PANA)", RFC 5191, May 2008. 1059 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1060 "Routing Requirements for Urban Low-Power and Lossy 1061 Networks", RFC 5548, May 2009. 1063 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1064 Framework", RFC 5582, September 2009. 1066 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1067 "Industrial Routing Requirements in Low-Power and Lossy 1068 Networks", RFC 5673, October 2009. 1070 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1071 Routing Requirements in Low-Power and Lossy Networks", 1072 RFC 5826, April 2010. 1074 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1075 "Building Automation Routing Requirements in Low-Power and 1076 Lossy Networks", RFC 5867, June 2010. 1078 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1079 Detecting Network Attachment in IPv6", RFC 6059, 1080 November 2010. 1082 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1083 Bierman, "Network Configuration Protocol (NETCONF)", 1084 RFC 6241, June 2011. 1086 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 1087 Grid", RFC 6272, June 2011. 1089 [SHA3] "NIST Cryptographic Hash Algorithm Competition", 1090 http://csrc.nist.gov/groups/ST/hash/sha-3/index.html , 1091 Dec 2011. 1093 [Schoenwaelde] 1094 Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol 1095 Profiles for Constrained Devices", IAB Interconnecting 1096 Smart Objects with the Internet Workshop, Prague, Czech Re 1097 public, http://www.iab.org/wp-content/IAB-uploads/2011/03/ 1098 Schoenwaelder.pdf, March 2011. 1100 [SmartGrid] 1101 "Wikipedia Entry for 'Smart Grid'", 1102 http://en.wikipedia.org/wiki/Smart_grid , Dec 2011. 1104 [Tussle] Clark, D., Wroslawski, J., Sollins, K., and R. Braden, 1105 "Tussle in Cyberspace: Defining Tomorrow's Internet", In 1106 Proc. ACM SIGCOMM , 1107 http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html, 1108 2002. 1110 [Wasserman] 1111 Wasserman, M., "It's Not Easy Being "Green"", IAB 1112 Interconnecting Smart Objects with the Internet Workshop, 1113 Prague, Czech Republic, http://www.iab.org/wp-content/ 1114 IAB-uploads/2011/03/Wasserman.pdf, March 2011. 1116 [enroll] "IETF Credential and Provisioning Working Group Mailing 1117 List", http://mailman.mit.edu/pipermail/ietf-enroll/ , 1118 June 2011. 1120 [irtf-discuss] 1121 "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http: 1122 //www.ietf.org/mail-archive/web/irtf-discuss/current/ 1123 msg00041.html , May 2011. 1125 [proxZzzy] 1126 ECMA, "proxZZZyTM for sleeping hosts, ECMA-393", http:// 1127 www.ecma-international.org/publications/standards/ 1128 Ecma-393.htm , Feb 2010. 1130 Appendix A. Program Committee 1132 The following persons are responsible for the organization of the 1133 associated workshop and are responsible also for this event: Jari 1134 Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David 1135 Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph 1136 Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo 1137 Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen 1138 Jennings, Manfred Hauswirth, and Lukas Kencl. 1140 Appendix B. Workshop Materials 1142 Information about the workshop can be found at the IAB webpage: 1143 http://www.iab.org/about/workshops/smartobjects/ 1145 The position papers can be retrieved from: 1146 http://www.iab.org/about/workshops/smartobjects/papers/ 1148 The slides are available for download at the following webpage: 1149 http://www.iab.org/about/workshops/smartobjects/agenda.html 1151 Detailed meeting minutes are published here: 1152 http://www.iab.org/about/workshops/smartobjects/minutes.html 1154 Appendix C. Accepted Position Papers 1156 1. Deployment Experience with Low Power Lossy Wireless Sensor 1157 Networks by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. 1158 Philipp, and G. Wittenburg 1160 2. CoAP improvements to meet embedded device hardware constraints 1161 by Davide Barbieri 1163 3. Unified Device Networking Protocols for Smart Objects by Daniel 1164 Barisic and Anton Pfefferseder 1166 4. Simplified neighbour cache implementation in RPL/6LoWPAN by 1167 Dominique Barthel 1169 5. Home Control in a consumer's perspective by Anders Brandt 1171 6. Authoring Place-based Experiences with an Internet of Things: 1172 Tussles of Expressive, Operational, and Participatory Goals by 1173 Jeff Burke 1175 7. A Dynamic Distributed Federated Approach for the Internet of 1176 Things by Diego Casado Mansilla, Juan Ramon Velasco Perez, and 1177 Mario Lopez-Ramos 1179 8. Quickly interoperable Internet of Things using simple 1180 transparent gateways by Angelo P. Castellani, Salvatore Loreto, 1181 Nicola Bui, and Michele Zorzi 1183 9. Position Paper of the Brno University of Technology Department 1184 of Telecommunications by Vladimir Cervenka, Lubomir Mraz, Milan 1185 Simek, Karel Pavlata 1187 10. Secure Access to IOT Network: An Application-based Group Key 1188 Approach by Samita Chakrabarti, and Wassim Haddad 1190 11. Domain-Insulated Autonomous Network Architecture (DIANA) by W. 1191 Chun 1193 12. Yet Another Definition on Name, Address, ID, and Locator 1194 (YANAIL) by W. Chun 1196 13. The Challenge of Mobility in Low Power Networks by E. Davies 1198 14. If the routing protocol is so smart, why should neighbour 1199 discovery be so dumb? by Nicolas Dejean 1201 15. Making Smart Objects IPv6 Ready: Where are we? by M. Durvy and 1202 M. Valente 1204 16. Position Paper on "Interconnecting Smart Objects with the 1205 Internet" by Mehmet Ersue, and Jouni Korhonen 1207 17. The Real-time Enterprise: IoT-enabled Business Processes by 1208 Stephan Haller, and Carsten Magerkurth 1210 18. Making Internet-Connected Objects readily useful by Manfred 1211 Hauswirth, Dennis Pfisterer, Stefan Decker 1213 19. Some Considerations on Routing in Particular and Lossy 1214 Environments by Thomas Clausen, and Ulrich Herberg 1216 20. A Security Protocol Adaptation Layer for the IP-based Internet 1217 of Things by Rene Hummen, Tobias Heer, and Klaus Wehrle 1219 21. Simplified SIP Approach for the Smart Object by Ryota Ishibashi, 1220 Takumi Ohba, Arata Koike, and Akira Kurokawa 1222 22. Mobility support for the small and smart Future Internet devices 1223 by Antonio J. Jara, and Antonio F. G. Skarmeta 1225 23. The Need for Efficient Reliable Multicast in Smart Grid Networks 1226 by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk 1228 24. Lightweight Cryptography for the Internet of Things by Masanobu 1229 Katagi, and Shiho Moriai 1231 25. Thoughts on Reliability in the Internet of Things by James 1232 Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli 1234 26. IKEv2 and Smart Objects by Tero Kivinen 1236 27. Position Paper on Thing Name Service (TNS) for the Internet of 1237 Things (IoT) by Ning Kong, and Shuo Shen 1239 28. Connecting Smart Objects to Wireless WANs by Suresh Krishnan 1241 29. Towards an Information-Centric Internet with more Things by D. 1242 Kutscher, and S. Farrell 1244 30. Application of 6LoWPAN for the Real-Time Positioning of 1245 Manufacturing Assets by Jaacan Martinez and Jose L. M. Lastra 1247 31. Lighting interface to wireless network by Jaroslav Meduna 1248 32. Social-driven Internet of Connected Objects by Paulo Mendes 1250 33. Protocols should go forward that are required by non IP based 1251 protocols by Tsuyoshi Momose 1253 34. Web services for Wireless Sensor and Actuator Networks by Guido 1254 Moritz 1256 35. Connecting BT-LE sensors to the Internet using Ipv6 by Markus 1257 Isomaeki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, 1258 Basavaraj Patil, Teemu Savolainen, and Zach Shelby 1260 36. Building Networks by Bruce Nordman 1262 37. Issues and Challenges in Provisioning Keys to Smart Objects by 1263 Yoshihiro Ohba, and Subir Das 1265 38. Challenges and Solutions of Secure Smart Environments by Eila 1266 Ovaska and Antti Evesti 1268 39. Research Experiences about Internetworking Mechanisms to 1269 Integrate Embedded Wireless Networks into Traditional Networks 1270 by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar 1272 40. Scalable Video Coding in Networked Environment by Naeem Ramzan, 1273 Tomas Piatrik, and Ebroul Izquierdo 1275 41. Challenges in Opportunistic Networking by Mikko Pitkaenen, and 1276 Teemu Kaerkkaeinen 1278 42. Position Statement by Neeli R. Prasad, and Sateesh Addepalli 1280 43. A Gateway Architecture for Interconnecting Smart Objects to the 1281 Internet by Akbar Rahman, Dorothy Gellert, Dale Seed 1283 44. Routing Challenges and Directions for Smart Objects in Future 1284 Internet of Things by T. A. Ramrekha, E. Panaousis, and C. 1285 Politis 1287 45. 6LoWPAN Extension for IPsec by Shahid Raza, Thiemo Voigt, and 1288 Utz Roedig 1290 46. Connected Vehicle as Smart Object(s) by Ryuji Wakikawa 1292 47. Problem and possible approach of development and operation of 1293 Smart Objects by Shoichi Sakane 1295 48. Connecting Passive RFID Tags to the Internet of Things by Sandra 1296 Dominikus, and Joern-Marc Schmidt 1298 49. Protocol Profiles for Constrained Devices by Juergen 1299 Schoenwaelde, Tina Tsou, and Behcet Sarikaya 1301 50. Multihoming for Sensor Networks by J. Soininen 1303 51. Internet Objects for Building Control by Peter van der Stok, and 1304 Nicolas Riou 1306 52. Optimal information placement for Smart Objects by Shigeya 1307 Suzuki 1309 53. Multi-National Initiative for Cloud Computing in Health Care 1310 (MUNICH) by Christoph Thuemmler 1312 54. The time of the hourglass has elapsed by Laurent Toutain, 1313 Nicolas Montavont, and Dominique Barthel 1315 55. Sensor and Actuator Resource Architecture by Vlasios Tsiatsis, 1316 Jan Hoeller, and Richard Gold 1318 56. IT'S NOT EASY BEING "GREEN" by Margaret Wasserman 1320 57. Trustworthy Wireless Industrial Sensor Networks by Markus 1321 Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis 1322 Olivereau, and Oualha Nouha 1324 58. Interconnecting smart objects through an overlay networking 1325 architecture by Anastasios Zafeiropoulos, Athanassios 1326 Liakopoulos and Panagiotis Gouvas 1328 59. Building trust among Virtual Interconnecting Smart Objects in 1329 the Future Internet by Theodore Zahariadic, Helen C. Leligou, 1330 Panagiotis Trakadas, and Mischa Dohler 1332 60. Experience and Challenges of Integrating Smart Devices with the 1333 Mobile Internet by Zhen Cao, and Hui Deng 1335 61. The "mesh-under" versus "route over" debate in IP Smart Objects 1336 Networks by JP Vasseur, and Jonathan Hui 1338 62. Identification and Authentication of IoT Devices by Alper Yegin 1340 63. Security Challenges For the Internet of Things by Tim Polk, and 1341 Sean Turner 1343 64. Application Communications Requirements for 'The Internet of 1344 Things' by Bob Dolin 1346 65. Interoperability Concerns in the Internet of Things by Jari 1347 Arkko 1349 66. Privacy in Ubiquitous Computing by Ivan Gudymenko, and Katrin 1350 Borcea-Pfitzmann 1352 67. The 10 Laws of Smart Object Security Design by Hannes 1353 Tschofenig, and Bernard Aboba 1355 68. Position Paper on "In-Network Object Cloud" Architecture and 1356 Design Goals by Alex Galis, and Stuart Clayman 1358 69. Temptations and Difficulties of Protocols for Smart Objects and 1359 the Internet by Alexandru Petrescu 1361 70. The Internet of Things - Challenge for a New Architecture from 1362 Problems by Gyu Myoung Lee, and Noel Crespi 1364 71. Garrulity and Fluff by Carsten Bormann, and Klaus Hartke 1366 Appendix D. Workshop Participants 1368 We would like to than the following workshop participants for 1369 attending the workshop: 1371 Adrian Farrel 1372 Akbar Rahman 1373 Alissa Cooper 1374 Alper Yegin 1375 Anastasios Zafeiropoulos 1376 Anders Brandt 1377 Angelo P. Castellani 1378 Antonio F. G. Skarmeta 1379 Antonio Jara 1380 Arvind Ramrekha 1381 Behcet Sarikaya 1382 Bernard Aboba 1383 Bruce Nordman 1384 Carsten Bormann 1385 Cullen Jennings 1386 Daniel Barisic 1387 Dave Thaler 1388 Davide Barbieri 1389 Diego Casado Mansilla 1390 Dirk Kutscher 1391 Dominique Barthel 1392 Dorothy Gellert 1393 Elwyn Davis 1394 Emmanuel Baccelli 1395 Fred Baker 1396 Guido Moritz 1397 Gyu Myoung Lee 1398 Hannes Tschofenig 1399 Hui Deng 1400 Ivan Gudymenko 1401 Jaacan Martinez 1402 Jari Arkko 1403 Jaroslav Meduna 1404 Jeff Burke 1405 Johanna Nieminen 1406 Jonathan Hui 1407 Jonne Soininen 1408 Jouni Korhonen 1409 JP Vasseur 1410 Karel Pavlata 1411 Klaus Hartke 1412 Lars Eggert 1413 Laura Gheorghe 1414 Laurent Toutain 1415 Lukas Kencl 1416 Marcelo Bagnulo 1417 Marco Valente 1418 Margaret Wasserman 1419 Markus Isomaki 1420 Markus Wehner 1421 Masanobu Katagi 1422 Mathilde Durvy 1423 Mehmet Ersue 1424 Mikko Pitkaenen 1425 Milan Simek 1426 Neeli R. Prasad 1427 Nicolas Dejean 1428 Ning Kong 1429 Pascal Thubert 1430 Paulo Mendes 1431 Pete Resnick 1432 Peter van der Stok 1433 Ralph Droms 1434 Rene Hummen 1435 Ross Callon 1436 Ruediger Martin 1437 Russ Housley 1438 Ryota Ishibashi 1439 Ryuji Wakikawa 1440 Samita Chakrabarti 1441 Sandra Dominikus 1442 Sean Shen 1443 Sean Turner 1444 Shahid Raza 1445 Shoichi Sakane 1446 Spencer Dawkins 1447 Stephan Haller 1448 Stephen Farrell 1449 Stewart Bryant 1450 Subir Das 1451 Suresh Krishnan 1452 Tea Sang Choi 1453 Tero Kivinen 1454 Theodore Zahariadis 1455 Thomas Clausen 1456 Tim Polk 1457 Tina Tsou 1458 Tsuyoshi Momose 1459 Vladimir Cervenka 1460 Wassim Haddad 1461 Woojik Chun 1462 Zach Shelby 1464 Authors' Addresses 1466 Hannes Tschofenig 1467 Nokia Siemens Networks 1468 Linnoitustie 6 1469 Espoo 02600 1470 Finland 1472 Phone: +358 (50) 4871445 1473 Email: Hannes.Tschofenig@gmx.net 1474 URI: http://www.tschofenig.priv.at 1476 Jari Arkko 1477 Ericsson 1478 Jorvas 02420 1479 Finland 1481 Email: jari.arkko@piuha.net