idnits 2.17.1 draft-iab-smart-object-workshop-10.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 29, 2012) is 4464 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2222' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC5582' is defined on line 1059, 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: August 1, 2012 Ericsson 6 January 29, 2012 8 Report from the 'Interconnecting Smart Objects with the Internet' 9 Workshop, 25th March 2011, Prague 10 draft-iab-smart-object-workshop-10.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 August 1, 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. Sleeping 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. Sleeping 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 shorten the 476 setup time by noticing that the node is using the same default 477 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. Reduce 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 neighbor discovery but other 515 protocols do also deserve a deeper investigation, such as DNS, 516 and DHCP. 518 3. Avoid Verbose Protocols 520 Protocols involving multiple roundtrips and/or lengthy messages 521 with verbose encodings (e.g., XML) are not always well suited for 522 constrained environments. Low-power nodes utilizing verbose 523 protocols have to use more energy in sending messages and have to 524 stay powered on for a longer period of time as they wait for the 525 multi-roundtrip protocol exchanges to complete. 527 The best way to address these problems is to ensure that the 528 simplest possible protocol exchanges are used when the protocols 529 in question are designed. In some cases alternative encoding 530 formats and compression may also help. 532 4. Think about System-Wide Efficiency 534 While energy efficiency is critical for low-power devices running 535 on batteries, it is also beneficial for other devices as well, 536 including notebooks, desktops and smartphones. However, if the 537 goal is energy efficiency as opposed to battery life extension 538 for low-power devices, then it is important to consider the total 539 energy consumption of all the elements of the system. 541 For example, consider energy consumption in a home environment. 542 In these scenarios it is important to evaluate the energy usage 543 of the entire system. A light bulb utilizing Internet technology 544 described in this document may use less power but there is also 545 the device that controls the bulb that may consume a lot of 546 energy. If the goal is to reduce overall energy usage, then it 547 is important to consider these two devices (and potentially many 548 others) together. 550 3.3. Security 552 In the development of smart object applications, as with any other 553 protocol application solution, security has to be considered early in 554 the design process. As such, the recommendations currently provided 555 to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 556 [RFC4101], apply also to the smart object space. 558 While there are additional constraints, as described in Section 2, 559 security has to be a mandatory part of the solution. The hope is 560 that this will lead to implementations that provide security 561 features, deployments that utilize these, and finally that this leads 562 to use of better security mechanisms. It is important to point out 563 that the lack of direct user interaction will place hard requirements 564 on deployment models, configuration mechanisms, and software upgrade/ 565 crypto agility mechanisms. 567 Since many of the security mechanisms allow for customization, 568 particularly with regard to the cryptographic primitives utilized, 569 many believe that IETF security solutions are usable without 570 modifications in a large part of the smart object domain. Others 571 call for new work on cryptographic primitives that make use of a 572 single primitive (such as the Advanced Encryption Standard (AES) 573 [AES]) as a building block for all cryptographic functions with the 574 benefit of a smaller footprint of the overall solution, specifically 575 with respect to hardware limitations (e.g., the hardware architecture 576 of certain embedded devices prevents pipelining from being used). In 577 the excitement for new work on optimizations of cryptograhpic 578 primitives other factors have to be taken into consideration that 579 influence successful deployment, such as widespread support in 580 libraries, as well as intellectual property rights (IPR). As an 581 example of the latter aspect, the struggle of Elliptic Curve 582 Cryptography (ECC)-based cryptographic algorithms [ECC] to find 583 deployment can partially be attributed to its IPR situation. The 584 reuse of libraries providing cryptographic functions is clearly an 585 important way to use available memory resources in a more efficient 586 way. To deal with the performance and footprint concerns 587 investigations into offloading certain resource-hungry functions to 588 parties that possess more cryptographic power have been considered. 589 For example, the ability to delegate certificate validation to 590 servers has been standardized in the IETF before; for the support of 591 the Online Certificate Status Protocol (OCSP) in the Internet Key 592 Exchange protocol version 2 (IKEv2) and in Transport Layer Security 593 (TLS), see [RFC4806] and [RFC3546], respectively. 595 Focusing only on the cryptographic primitives would be shortsighted; 596 many would argue that this is the easy part of a smart object 597 security solution. Key management and credential enrollment, 598 however, are considered a big challenge by many particularly when 599 usability requirements have to be taken into account. Another group 600 of challenges concern privacy; with smart grids, for example, some 601 have voiced concerns regarding the ability of third parties to keep 602 track of an individual's energy consumption (and draw associated 603 conclusions). As another example, it is easy to see how a scale that 604 is connected to the Internet for uploading weight information to a 605 social network could lead to privacy concerns. While security 606 mechanisms used to offer protection of the communication between 607 different parties also provide a certain degree of privacy protection 608 they are clearly not enough to address all concerns. Even with the 609 best communication security and access control mechanisms in place 610 one still needs additional safeguards against the concerns mentioned 611 in the examples. 613 While a lot can be said about how desirable it would be to deploy 614 more security protocols on the entire Internet, practical 615 considerations regarding usability and the incentives of the 616 stakeholders involved have often lead to slower adoption. 618 3.4. Routing 620 A smart object network environment may also employ routers under 621 similar constraints as the end devices. Currently two approaches to 622 routing in these low power and lossy networks are under 623 consideration, namely mesh-under and route-over. The so-called mesh- 624 under approach places routing functions at the link layer and 625 consequently all devices appear as immediate neighbors at the network 626 layer. With the route-over approach routing is done at the IP layer 627 and none in the link layer. Each physical hop appears as a single IP 628 hop (ignoring devices that just extend the physical range of 629 signaling, such as repeaters). Routing in this context means running 630 a routing protocol. IPv6 Routing Protocol for Low power and Lossy 631 Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the 632 route-over category. 634 From an architectural point of view there are several questions that 635 arise from where routing is provided, for example: 637 o Protocols often assume that link characteristics are predictable 638 when communicating with any device attached to the same link. 639 Latency, throughput, and reliability may vary considerably between 640 different devices that are multiple link layer hops away. What 641 timeout should be used? What happens if a device is unreachable? 642 In case of default router selection two advertised routers may be 643 a different number of hops away. Should a device have visibility 644 into the path to make a decision and what path characteristics 645 would be useful to have? 647 o Scoped message delivery to a neighboring IP hop (via link-local 648 addressing) allows certain types of IP protocols to communicate 649 with their immediate neighbors and to therefore scope their 650 recipients. A link-local multicast message will be received by 651 all nodes in the same IP link local realm unless some special 652 optimizations are provided by the link layer. 654 o When path computations are done at the link layer as well as on 655 the network layer then what coordination needs to take place? 657 When multiple different link layer technologies are involved in a 658 network design, routing at layer 3 has to be provided in any case. 659 [I-D.routing-architecture-iot] talks about these tradeoffs between 660 route-over and mesh-under in detail. Furthermore, those who decide 661 about the deployment have to determine how to connect smart objects 662 to the Internet infrastructure and a number of wired and wireless 663 technologies may be suitable for a specific deployment. Depending on 664 the chosen technologies the above-mentioned mesh-under vs. route-over 665 approach will have to be decided and further decisions will have to 666 be made about the choice of a specific routing protocol. 668 In 2008 the IETF formed the Routing Over Low power and Lossy networks 669 (ROLL) working group to specify a routing solution for smart object 670 environments. During its first year of existence, the working group 671 studied routing requirements in detail (see [RFC5867], [RFC5826], 672 [RFC5673], [RFC5548]), worked on a protocol survey comparing a number 673 of existing routing protocols, including Ad hoc On-Demand Distance 674 Vector (AODV)-style of protocols [RFC3561], against the identified 675 requirements. The protocol survey [I-D.ietf-roll-protocols-survey] 676 was inconclusive and abandoned without giving rise to publication of 677 an RFC. 679 The ROLL WG concluded that a new routing protocol satisfying the 680 documented requirements has to be developed and the work on the RPL 681 was started as the IETF routing protocol for smart object networks. 682 Nevertheless, controversial discussions at the workshop about which 683 routing protocols is best in a given environment are still ongoing. 684 Thomas Clausen, for example, argued for using an AODV-like routing 685 protocol in [Clausen]. 687 4. Conclusions and Next Steps 689 The workshop allowed the participants to get exposed to interesting 690 applications and their requirements (buildings, fountains, theater, 691 etc.), to have discussions about radically different architectures 692 and their issues (e.g., information centric networking), to look at 693 existing technology from a new angle (sleeping nodes, energy 694 consumption), to focus on some details of the protocol stack 695 (neighbor discovery, security, routing) and to learn about 696 implementation experience. 698 One goal of the workshop was to identify areas that require further 699 investigation. The list below reflects the thoughts of the workshop 700 participants as expressed on the day of the workshop. Note that the 701 suggested items concern potential work by the IETF and the IRTF and 702 the order does not imply a particular preference. 704 Security: 706 A discussion of security is provided in Section 3.3. In general, 707 security related protocol exchanges and the required amount of 708 computational resource requirements can contribute significantly 709 to the overall processing. Therefore, it remains a challenge to 710 accomplish performance improvements without sacrificing the 711 overall security level, taking the usability of the entire system 712 into consideration. 714 Another challenge is how to balance the security and performance 715 needs of smart objects with the interoperability requirements of 716 hosts on the Internet since different suites of algorithms may 717 tend to be chosen for these different environments. This involves 718 trade-offs between performance on the smart objects versus end-to- 719 end security. Solutions that mandate a "trusted" middlebox whose 720 only role is to terminate security associations tend to be frowned 721 upon from the security perspective, especially since end-users of 722 challenged devices (where those exist) are unlikely to understand 723 the security consequences of such middleboxes. 725 The discussion concluded with the following recommendations: 727 * Investigate usability in cryptographic protocol design with 728 regard to credential management. As an example, the Bluetooth 729 pairing mechanism was mentioned as a simple and yet reasonably 730 secure method of introducing devices into a new environment. 731 In fact, the IETF working group 'Credential and Provisioning 732 (ENROLL)' was established years ago to deal with residential 733 networks but was terminated prematurely due to lack of 734 progress. The email archive still exists and is available 736 [enroll] and may provide useful historical information. 738 * Standardized authentication and key exchange mechanisms should 739 be surveyed for suitability in smart object environments with 740 respect to message size, computational performance, number of 741 messages, codesize, and main memory requirements. A starting 742 point of such an investigation (in case of IKEv2) was provided 743 by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a 744 suitable venue for discussion could be the recently established 745 Light-Weight Implementation Guidance (LWIG) working group 746 [LWIG]. 748 * Research has to be done in the area of lightweight 749 cryptographic primitives, namely block ciphers, stream ciphers, 750 and cryptographic hash functions. Worthwhile to mention is 751 early work with the National Institute of Standards and 752 Technology (NIST) new cryptographic hash algorithm 'SHA-3' 753 competition [SHA3]. A suitable forum for discussion is the 754 IRTF Crypto Forum Research Group (CFRG) [CFRG]. 756 The difficulty and impact of choosing specialised algorithms for 757 smart objects should not be underestimated. Issues that arise 758 include the additional specification complexity (e.g., TLS already 759 has 100's of ciphersuites defined, most of which are unused in 760 practice), the long latency in terms of roll out (many hosts are 761 still using deprecated algorithms 5-10 years after those 762 algorithms were deprecated) and the barriers that IPR-encumbered 763 schemes present to widespread deployment. While research on this 764 topic within CFRG and the cryptographic research community is a 765 very worthwhile goal, any such algorithms will likely have to 766 offer very significant benefits before they will be broadly 767 adopted. 20% less CPU is unlikely to be a winning argument no 768 matter what an algorithm inventor believes. 770 Energy Design Considerations: 772 One part of the workshop was focused on the discussion of energy 773 implications for IETF protocol design with proposals being made 774 about how to extend protocols to better support nodes that are 775 mostly sleeping. Discussion are encouraged to take place at the 776 RECIPE mailing list [RECIPE]. The workshop position paper 777 [Wasserman] by Margaret Wasserman provides a good starting point 778 for further investigations. 780 Information/Content Centric Networking: 782 Information/Content Centric Networking is about accessing named 783 content and a number of research projects have emerged around this 784 theme. At this point in time the work is not yet ready for 785 standardization in the IETF. Instead, the formation of an IRTF 786 research group has been proposed and more details are available on 787 the IRTF DISCUSS mailing list [irtf-discuss]. 789 Architectural Guidelines: 791 Participants suggested developing an architectural write-up about 792 what can be done with the IETF protocols we have today and how 793 these different elements may be combined to offer an explanation 794 for the broader community. This would be a task for the Internet 795 Architecture Board (IAB). An example of prior work that serves as 796 input is [RFC6272]. 798 Network Management: 800 While this topic did not make it onto the workshop agenda it was 801 considered useful to start a discussion about how to implement 802 network management protocols, such as Network Configuration 803 Protocol (NETCONF) [RFC6241], on smart objects. The following 804 position papers may be useful as a starting point for further 805 discussions [Ersue], [Schoenwaelde]. An IETF draft is also 806 available [I-D.hamid-6lowpan-snmp-optimizations]. 808 Congestion Control: 810 When smart objects transmit sensor readings to some server on the 811 Internet then these protocol interactions often carry a small 812 amount of data and happen infrequently, although regularly. With 813 the work on new application protocols, like the CoAP 814 [I-D.ietf-core-coap], the question of whether a congestion control 815 mechanism should be used at the underlying transport protocol or 816 by the application protocol itself arises. 817 [I-D.eggert-core-congestion-control] is a starting point for the 818 CoAP protocol but further work is needed. 820 Data Models: 822 Standardization of application layer protocols is important but 823 does not ensure that, for example, a light switch and a light bulb 824 are able to interact with each other. One area where participants 825 saw the need for further work was in the area of data models. 826 While prior IETF standardization work on, for example, location 827 [GEOPRIV] can be re-used the question was raised where the IETF 828 should focus its standardization efforts since domain expertise in 829 each area will be needed. As a potential example, energy pricing 830 was discussed, with an example provided by 831 [I-D.jennings-energy-pricing]. 833 Discovery: 835 Additional extensions to developed discovery protocols (such as 836 mDNS) may be needed for the smart object environment. 838 Building Networking: 840 Network architectures in residential as well as commercial 841 buildings should take the presence of smart objects and dedicated 842 subnetworks focusing on smart objects into account. A new working 843 group, Home Networking (HOMENET) [FUN], has been created after the 844 workshop to look at this topic. 846 Routing: 848 Changing radio conditions and link fluctuation may lead to the 849 need for re-numbering. Workshop participants argued that work 850 should be started on the multi-link subnetworks to mitigate this 851 problem, i.e., to extend the notion of a subnet to be able to span 852 multiple links. With the publication of RFC 4903 [RFC4903] the 853 Internet Architecture Board had looked into this topic already and 854 provided pros and cons. 856 The applicability of specific routing protocols designed for smart 857 object networks needs further investigation. The ROLL working 858 group is chartered with the task of constructing an applicability 859 document for the RPL protocol, for instance. 861 5. Security Considerations 863 The workshop discussions covered a range of potential engineering 864 activities, each with its own security considerations. As the IETF 865 community begins to pursue specific avenues arising out of this 866 workshop, addressing relevant security requirements will be crucial. 868 As described in this report part of the agenda was focused on the 869 discussion of security, see Section 3.3. 871 6. Acknowledgements 873 We would like to thank all the participants for their position 874 papers. The authors of the accepted position papers were invited to 875 the workshop. 877 Big thanks to Elwyn Davies for helping us to fix language bugs. We 878 would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas 879 Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, 880 and Henning Schulzrinne for their review comments. 882 Additionally, we would like to thank Ericsson and Nokia Siemens 883 Networks for their financial support. 885 7. IANA Considerations 887 This document does not require actions by IANA. 889 8. Informative References 891 [AES] "Wikipedia Entry for 'Advanced Encryption Standard'", 892 http://en.wikipedia.org/wiki/ 893 Advanced_Encryption_Standard , Dec 2011. 895 [CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group 896 (CFRG)", http://irtf.org/cfrg , June 2011. 898 [Clausen] Clausen, T. and U. Herberg, "Some Considerations on 899 Routing in Particular and Lossy Environments", IAB 900 Interconnecting Smart Objects with the Internet Workshop, 901 Prague, Czech Republic, http://www.iab.org/wp-content/ 902 IAB-uploads/2011/03/Clausen.pdf, March 2011. 904 [Dolin] Dolin, B., "Application Communications Requirements for 905 'The Internet of Things'", IAB Interconnecting Smart 906 Objects with the Internet Workshop, Prague, Czech Republic 907 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 908 Ersue.pdf, March 2011. 910 [ECC] "Wikipedia Entry for 'Elliptic Curve Cryptography'", 911 http://en.wikipedia.org/wiki/Elliptic_curve_cryptography , 912 Dec 2011. 914 [Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object 915 Workshop Position Paper", IAB Interconnecting Smart 916 Objects with the Internet Workshop, Prague, Czech Republic 917 , http://www.iab.org/wp-content/IAB-uploads/2011/03/ 918 Ersue.pdf, March 2011. 920 [FUN] "FUture home Networking (FUN) Mailing List", 921 https://www.ietf.org/mailman/listinfo/fun , June 2011. 923 [GEOPRIV] "IETF Geographic Location/Privacy Working Group", 924 http://datatracker.ietf.org/wg/geopriv/ , June 2011. 926 [I-D.cheshire-dnsext-dns-sd] 927 Cheshire, S. and M. Krochmal, "DNS-Based Service 928 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 929 progress), December 2011. 931 [I-D.eggert-core-congestion-control] 932 Eggert, L., "Congestion Control for the Constrained 933 Application Protocol (CoAP)", 934 draft-eggert-core-congestion-control-01 (work in 935 progress), January 2011. 937 [I-D.hamid-6lowpan-snmp-optimizations] 938 Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP 939 Optimizations for Constrained Devices", 940 draft-hamid-6lowpan-snmp-optimizations-03 (work in 941 progress), October 2010. 943 [I-D.ietf-core-coap] 944 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 945 "Constrained Application Protocol (CoAP)", 946 draft-ietf-core-coap-08 (work in progress), October 2011. 948 [I-D.ietf-roll-protocols-survey] 949 Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview 950 of Existing Routing Protocols for Low Power and Lossy 951 Networks", draft-ietf-roll-protocols-survey-07 (work in 952 progress), April 2009. 954 [I-D.ietf-roll-rpl] 955 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 956 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 957 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 958 Lossy Networks", draft-ietf-roll-rpl-19 (work in 959 progress), March 2011. 961 [I-D.jennings-energy-pricing] 962 Jennings, C. and B. Nordman, "Communication of Energy 963 Price Information", draft-jennings-energy-pricing-01 (work 964 in progress), July 2011. 966 [I-D.kivinen-ipsecme-ikev2-minimal] 967 Kivinen, T., "Minimal IKEv2", 968 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 969 February 2011. 971 [I-D.routing-architecture-iot] 972 Hui, J. and J. Vasseur, "Routing Architecture in Low-Power 973 and Lossy Networks (LLNs)", 974 draft-routing-architecture-iot-00 (work in progress), 975 March 2011. 977 [LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 978 Group", http://datatracker.ietf.org/wg/lwig/charter/ , 979 June 2011. 981 [RECIPE] "Reducing Energy Consumption with Internet Protocols 982 Exploration (RECIPE) Mailing List", 983 https://www.ietf.org/mailman/listinfo/recipe , June 2011. 985 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 986 August 1980. 988 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 989 September 1981. 991 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 992 RFC 793, September 1981. 994 [RFC2222] Myers, J., "Simple Authentication and Security Layer 995 (SASL)", RFC 2222, October 1997. 997 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 998 (IPv6) Specification", RFC 2460, December 1998. 1000 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1001 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1002 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1004 [RFC2743] Linn, J., "Generic Security Service Application Program 1005 Interface Version 2, Update 1", RFC 2743, January 2000. 1007 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1008 A., Peterson, J., Sparks, R., Handley, M., and E. 1009 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1010 June 2002. 1012 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1013 and T. Wright, "Transport Layer Security (TLS) 1014 Extensions", RFC 3546, June 2003. 1016 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1017 Text on Security Considerations", BCP 72, RFC 3552, 1018 July 2003. 1020 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1021 Demand Distance Vector (AODV) Routing", RFC 3561, 1022 July 2003. 1024 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1025 Levkowetz, "Extensible Authentication Protocol (EAP)", 1026 RFC 3748, June 2004. 1028 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1029 Protocol (XMPP): Instant Messaging and Presence", 1030 RFC 3921, October 2004. 1032 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1033 June 2005. 1035 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1036 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1038 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1039 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1041 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 1042 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 1043 February 2007. 1045 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1046 June 2007. 1048 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1049 RFC 4960, September 2007. 1051 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1052 Yegin, "Protocol for Carrying Authentication for Network 1053 Access (PANA)", RFC 5191, May 2008. 1055 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1056 "Routing Requirements for Urban Low-Power and Lossy 1057 Networks", RFC 5548, May 2009. 1059 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1060 Framework", RFC 5582, September 2009. 1062 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1063 "Industrial Routing Requirements in Low-Power and Lossy 1064 Networks", RFC 5673, October 2009. 1066 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1067 Routing Requirements in Low-Power and Lossy Networks", 1068 RFC 5826, April 2010. 1070 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1071 "Building Automation Routing Requirements in Low-Power and 1072 Lossy Networks", RFC 5867, June 2010. 1074 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1075 Detecting Network Attachment in IPv6", RFC 6059, 1076 November 2010. 1078 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1079 Bierman, "Network Configuration Protocol (NETCONF)", 1080 RFC 6241, June 2011. 1082 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 1083 Grid", RFC 6272, June 2011. 1085 [SHA3] "NIST Cryptographic Hash Algorithm Competition", 1086 http://csrc.nist.gov/groups/ST/hash/sha-3/index.html , 1087 Dec 2011. 1089 [Schoenwaelde] 1090 Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol 1091 Profiles for Constrained Devices", IAB Interconnecting 1092 Smart Objects with the Internet Workshop, Prague, Czech Re 1093 public, http://www.iab.org/wp-content/IAB-uploads/2011/03/ 1094 Schoenwaelder.pdf, March 2011. 1096 [SmartGrid] 1097 "Wikipedia Entry for 'Smart Grid'", 1098 http://en.wikipedia.org/wiki/Smart_grid , Dec 2011. 1100 [Tussle] Clark, D., Wroslawski, J., Sollins, K., and R. Braden, 1101 "Tussle in Cyberspace: Defining Tomorrow's Internet", In 1102 Proc. ACM SIGCOMM , 1103 http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html, 1104 2002. 1106 [Wasserman] 1107 Wasserman, M., "It's Not Easy Being "Green"", IAB 1108 Interconnecting Smart Objects with the Internet Workshop, 1109 Prague, Czech Republic, http://www.iab.org/wp-content/ 1110 IAB-uploads/2011/03/Wasserman.pdf, March 2011. 1112 [enroll] "IETF Credential and Provisioning Working Group Mailing 1113 List", http://mailman.mit.edu/pipermail/ietf-enroll/ , 1114 June 2011. 1116 [irtf-discuss] 1117 "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http: 1118 //www.ietf.org/mail-archive/web/irtf-discuss/current/ 1119 msg00041.html , May 2011. 1121 [proxZzzy] 1122 ECMA, "proxZZZyTM for sleeping hosts, ECMA-393", http:// 1123 www.ecma-international.org/publications/standards/ 1124 Ecma-393.htm , Feb 2010. 1126 Appendix A. Program Committee 1128 The following persons are responsible for the organization of the 1129 associated workshop and are responsible also for this event: Jari 1130 Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David 1131 Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph 1132 Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo 1133 Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen 1134 Jennings, Manfred Hauswirth, and Lukas Kencl. 1136 Appendix B. Workshop Materials 1138 Information about the workshop can be found at the IAB webpage: 1139 http://www.iab.org/about/workshops/smartobjects/ 1141 The position papers can be retrieved from: 1142 http://www.iab.org/about/workshops/smartobjects/papers/ 1144 The slides are available for download at the following webpage: 1145 http://www.iab.org/about/workshops/smartobjects/agenda.html 1147 Detailed meeting minutes are published here: 1148 http://www.iab.org/about/workshops/smartobjects/minutes.html 1150 Appendix C. Accepted Position Papers 1152 1. Deployment Experience with Low Power Lossy Wireless Sensor 1153 Networks by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. 1154 Philipp, and G. Wittenburg 1156 2. CoAP improvements to meet embedded device hardware constraints 1157 by Davide Barbieri 1159 3. Unified Device Networking Protocols for Smart Objects by Daniel 1160 Barisic and Anton Pfefferseder 1162 4. Simplified neighbour cache implementation in RPL/6LoWPAN by 1163 Dominique Barthel 1165 5. Home Control in a consumer's perspective by Anders Brandt 1167 6. Authoring Place-based Experiences with an Internet of Things: 1168 Tussles of Expressive, Operational, and Participatory Goals by 1169 Jeff Burke 1171 7. A Dynamic Distributed Federated Approach for the Internet of 1172 Things by Diego Casado Mansilla, Juan Ramon Velasco Perez, and 1173 Mario Lopez-Ramos 1175 8. Quickly interoperable Internet of Things using simple 1176 transparent gateways by Angelo P. Castellani, Salvatore Loreto, 1177 Nicola Bui, and Michele Zorzi 1179 9. Position Paper of the Brno University of Technology Department 1180 of Telecommunications by Vladimir Cervenka, Lubomir Mraz, Milan 1181 Simek, Karel Pavlata 1183 10. Secure Access to IOT Network: An Application-based Group Key 1184 Approach by Samita Chakrabarti, and Wassim Haddad 1186 11. Domain-Insulated Autonomous Network Architecture (DIANA) by W. 1187 Chun 1189 12. Yet Another Definition on Name, Address, ID, and Locator 1190 (YANAIL) by W. Chun 1192 13. The Challenge of Mobility in Low Power Networks by E. Davies 1194 14. If the routing protocol is so smart, why should neighbour 1195 discovery be so dumb? by Nicolas Dejean 1197 15. Making Smart Objects IPv6 Ready: Where are we? by M. Durvy and 1198 M. Valente 1200 16. Position Paper on "Interconnecting Smart Objects with the 1201 Internet" by Mehmet Ersue, and Jouni Korhonen 1203 17. The Real-time Enterprise: IoT-enabled Business Processes by 1204 Stephan Haller, and Carsten Magerkurth 1206 18. Making Internet-Connected Objects readily useful by Manfred 1207 Hauswirth, Dennis Pfisterer, Stefan Decker 1209 19. Some Considerations on Routing in Particular and Lossy 1210 Environments by Thomas Clausen, and Ulrich Herberg 1212 20. A Security Protocol Adaptation Layer for the IP-based Internet 1213 of Things by Rene Hummen, Tobias Heer, and Klaus Wehrle 1215 21. Simplified SIP Approach for the Smart Object by Ryota Ishibashi, 1216 Takumi Ohba, Arata Koike, and Akira Kurokawa 1218 22. Mobility support for the small and smart Future Internet devices 1219 by Antonio J. Jara, and Antonio F. G. Skarmeta 1221 23. The Need for Efficient Reliable Multicast in Smart Grid Networks 1222 by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk 1224 24. Lightweight Cryptography for the Internet of Things by Masanobu 1225 Katagi, and Shiho Moriai 1227 25. Thoughts on Reliability in the Internet of Things by James 1228 Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli 1230 26. IKEv2 and Smart Objects by Tero Kivinen 1232 27. Position Paper on Thing Name Service (TNS) for the Internet of 1233 Things (IoT) by Ning Kong, and Shuo Shen 1235 28. Connecting Smart Objects to Wireless WANs by Suresh Krishnan 1237 29. Towards an Information-Centric Internet with more Things by D. 1238 Kutscher, and S. Farrell 1240 30. Application of 6LoWPAN for the Real-Time Positioning of 1241 Manufacturing Assets by Jaacan Martinez and Jose L. M. Lastra 1243 31. Lighting interface to wireless network by Jaroslav Meduna 1244 32. Social-driven Internet of Connected Objects by Paulo Mendes 1246 33. Protocols should go forward that are required by non IP based 1247 protocols by Tsuyoshi Momose 1249 34. Web services for Wireless Sensor and Actuator Networks by Guido 1250 Moritz 1252 35. Connecting BT-LE sensors to the Internet using Ipv6 by Markus 1253 Isomaeki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, 1254 Basavaraj Patil, Teemu Savolainen, and Zach Shelby 1256 36. Building Networks by Bruce Nordman 1258 37. Issues and Challenges in Provisioning Keys to Smart Objects by 1259 Yoshihiro Ohba, and Subir Das 1261 38. Challenges and Solutions of Secure Smart Environments by Eila 1262 Ovaska and Antti Evesti 1264 39. Research Experiences about Internetworking Mechanisms to 1265 Integrate Embedded Wireless Networks into Traditional Networks 1266 by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar 1268 40. Scalable Video Coding in Networked Environment by Naeem Ramzan, 1269 Tomas Piatrik, and Ebroul Izquierdo 1271 41. Challenges in Opportunistic Networking by Mikko Pitkaenen, and 1272 Teemu Kaerkkaeinen 1274 42. Position Statement by Neeli R. Prasad, and Sateesh Addepalli 1276 43. A Gateway Architecture for Interconnecting Smart Objects to the 1277 Internet by Akbar Rahman, Dorothy Gellert, Dale Seed 1279 44. Routing Challenges and Directions for Smart Objects in Future 1280 Internet of Things by T. A. Ramrekha, E. Panaousis, and C. 1281 Politis 1283 45. 6LoWPAN Extension for IPsec by Shahid Raza, Thiemo Voigt, and 1284 Utz Roedig 1286 46. Connected Vehicle as Smart Object(s) by Ryuji Wakikawa 1288 47. Problem and possible approach of development and operation of 1289 Smart Objects by Shoichi Sakane 1291 48. Connecting Passive RFID Tags to the Internet of Things by Sandra 1292 Dominikus, and Joern-Marc Schmidt 1294 49. Protocol Profiles for Constrained Devices by Juergen 1295 Schoenwaelde, Tina Tsou, and Behcet Sarikaya 1297 50. Multihoming for Sensor Networks by J. Soininen 1299 51. Internet Objects for Building Control by Peter van der Stok, and 1300 Nicolas Riou 1302 52. Optimal information placement for Smart Objects by Shigeya 1303 Suzuki 1305 53. Multi-National Initiative for Cloud Computing in Health Care 1306 (MUNICH) by Christoph Thuemmler 1308 54. The time of the hourglass has elapsed by Laurent Toutain, 1309 Nicolas Montavont, and Dominique Barthel 1311 55. Sensor and Actuator Resource Architecture by Vlasios Tsiatsis, 1312 Jan Hoeller, and Richard Gold 1314 56. IT'S NOT EASY BEING "GREEN" by Margaret Wasserman 1316 57. Trustworthy Wireless Industrial Sensor Networks by Markus 1317 Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis 1318 Olivereau, and Oualha Nouha 1320 58. Interconnecting smart objects through an overlay networking 1321 architecture by Anastasios Zafeiropoulos, Athanassios 1322 Liakopoulos and Panagiotis Gouvas 1324 59. Building trust among Virtual Interconnecting Smart Objects in 1325 the Future Internet by Theodore Zahariadic, Helen C. Leligou, 1326 Panagiotis Trakadas, and Mischa Dohler 1328 60. Experience and Challenges of Integrating Smart Devices with the 1329 Mobile Internet by Zhen Cao, and Hui Deng 1331 61. The "mesh-under" versus "route over" debate in IP Smart Objects 1332 Networks by JP Vasseur, and Jonathan Hui 1334 62. Identification and Authentication of IoT Devices by Alper Yegin 1336 63. Security Challenges For the Internet of Things by Tim Polk, and 1337 Sean Turner 1339 64. Application Communications Requirements for 'The Internet of 1340 Things' by Bob Dolin 1342 65. Interoperability Concerns in the Internet of Things by Jari 1343 Arkko 1345 66. Privacy in Ubiquitous Computing by Ivan Gudymenko, and Katrin 1346 Borcea-Pfitzmann 1348 67. The 10 Laws of Smart Object Security Design by Hannes 1349 Tschofenig, and Bernard Aboba 1351 68. Position Paper on "In-Network Object Cloud" Architecture and 1352 Design Goals by Alex Galis, and Stuart Clayman 1354 69. Temptations and Difficulties of Protocols for Smart Objects and 1355 the Internet by Alexandru Petrescu 1357 70. The Internet of Things - Challenge for a New Architecture from 1358 Problems by Gyu Myoung Lee, and Noel Crespi 1360 71. Garrulity and Fluff by Carsten Bormann, and Klaus Hartke 1362 Appendix D. Workshop Participants 1364 We would like to than the following workshop participants for 1365 attending the workshop: 1367 Adrian Farrel 1368 Akbar Rahman 1369 Alissa Cooper 1370 Alper Yegin 1371 Anastasios Zafeiropoulos 1372 Anders Brandt 1373 Angelo P. Castellani 1374 Antonio F. G. Skarmeta 1375 Antonio Jara 1376 Arvind Ramrekha 1377 Behcet Sarikaya 1378 Bernard Aboba 1379 Bruce Nordman 1380 Carsten Bormann 1381 Cullen Jennings 1382 Daniel Barisic 1383 Dave Thaler 1384 Davide Barbieri 1385 Diego Casado Mansilla 1386 Dirk Kutscher 1387 Dominique Barthel 1388 Dorothy Gellert 1389 Elwyn Davis 1390 Emmanuel Baccelli 1391 Fred Baker 1392 Guido Moritz 1393 Gyu Myoung Lee 1394 Hannes Tschofenig 1395 Hui Deng 1396 Ivan Gudymenko 1397 Jaacan Martinez 1398 Jari Arkko 1399 Jaroslav Meduna 1400 Jeff Burke 1401 Johanna Nieminen 1402 Jonathan Hui 1403 Jonne Soininen 1404 Jouni Korhonen 1405 JP Vasseur 1406 Karel Pavlata 1407 Klaus Hartke 1408 Lars Eggert 1409 Laura Gheorghe 1410 Laurent Toutain 1411 Lukas Kencl 1412 Marcelo Bagnulo 1413 Marco Valente 1414 Margaret Wasserman 1415 Markus Isomaki 1416 Markus Wehner 1417 Masanobu Katagi 1418 Mathilde Durvy 1419 Mehmet Ersue 1420 Mikko Pitkaenen 1421 Milan Simek 1422 Neeli R. Prasad 1423 Nicolas Dejean 1424 Ning Kong 1425 Pascal Thubert 1426 Paulo Mendes 1427 Pete Resnick 1428 Peter van der Stok 1429 Ralph Droms 1430 Rene Hummen 1431 Ross Callon 1432 Ruediger Martin 1433 Russ Housley 1434 Ryota Ishibashi 1435 Ryuji Wakikawa 1436 Samita Chakrabarti 1437 Sandra Dominikus 1438 Sean Shen 1439 Sean Turner 1440 Shahid Raza 1441 Shoichi Sakane 1442 Spencer Dawkins 1443 Stephan Haller 1444 Stephen Farrell 1445 Stewart Bryant 1446 Subir Das 1447 Suresh Krishnan 1448 Tea Sang Choi 1449 Tero Kivinen 1450 Theodore Zahariadis 1451 Thomas Clausen 1452 Tim Polk 1453 Tina Tsou 1454 Tsuyoshi Momose 1455 Vladimir Cervenka 1456 Wassim Haddad 1457 Woojik Chun 1458 Zach Shelby 1460 Authors' Addresses 1462 Hannes Tschofenig 1463 Nokia Siemens Networks 1464 Linnoitustie 6 1465 Espoo 02600 1466 Finland 1468 Phone: +358 (50) 4871445 1469 Email: Hannes.Tschofenig@gmx.net 1470 URI: http://www.tschofenig.priv.at 1472 Jari Arkko 1473 Ericsson 1474 Jorvas 02420 1475 Finland 1477 Email: jari.arkko@piuha.net