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