| Network Working Group | H. Tschofenig |
| Internet-Draft | Nokia Siemens Networks |
| Intended status: Informational | J. Arkko |
| Ericsson | |
| 2011 |
Report from the 'Interconnecting Smart Objects with the Internet' Workshop, 25th March 2011, Prague
draft-iab-smart-object-workshop-07.txt
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on March, 25th. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
Today's Internet is experienced by users as a set of applications, such as email, instant messaging, and services on the Web. While these applications do not require users to be present at the time of service execution, in many cases they are. There are also substantial differences in performance among the various end devices, but in general end devices participating in the Internet are considered to have high performance.
There are, however, a large number of deployed embedded devices and there is substantial value in interconnecting them with the Internet. The term "Internet of Things" denotes a trend where a large number of devices employ communication services offered by the Internet Protocols. Many of these devices are not directly operated by humans, but exist as components in buildings, vehicles, and the environment. There is a large variation in the computing power, available memory, (electrical) power, and communications bandwidth between different types of devices.
Many of these devices offer a range of new possibilities or provide additional value for previously unconnected devices. Some devices have been connected using proprietary communication networks in the past but are now migrating to the use of the Internet Protocol suite in order to share the same communication network between all applications and to enable rich communications services.
Much of this development can simply run on existing Internet protocols. For instance, home entertainment and monitoring systems often offer a web interface to the end user. In many cases the new, constrained environments can benefit from additional protocols and protocol extensions that help optimize the communications and lower the computational requirements. Examples of currently ongoing standardization efforts targeted for these environments include the "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and the "Light-Weight Implementation Guidance (LWIG)" working groups at the IETF.
This workshop explored the experiences of researchers and developers when considering the characteristics of constrained devices. Engineers know that many design considerations need to be taken into account when developing protocols and architecture. Balancing between the conflicting goals of code size, economic incentives, power consumption, usability and security is often difficult, as illustrated by Clark, et al. in "Tussle in Cyberspace: Defining Tomorrow's Internet" [Tussle].
Participants at the workshop discussed the experience and approaches taken when designing protocols and architectures for interconnecting smart objects to the Internet. The scope of the investigations included constrained nodes as well as constrained networks.
The call for position papers suggested investigating the area of integration with the Internet in the following categories:
The goals of the workshop can be summarized as follows:
The workshop was spurred by the increasing presence of constrained devices on the network. It is quite natural to ask how these limitations impact the design of the affected nodes. Note that not all nodes suffer from the same set of limitations.
A system designer also needs to consider CPU constraints, which often relate to energy constraints: a processor with lower performance consumes less energy. As described later in this document, the design of the mainboard may allow certain components to be put to sleep to further lower energy consumption. In general, embedded systems are often purpose built with only the hardware components needed for the given task while general purpose personal computers are less constrained with regard to their mainboard layout and typically offer a huge number of optional plug-in peripherals to be connected. A factor that also has to be taken into consideration is the intended usage environment. For example, a humidity sensor deployed outside a building may need to deal with temperatures from -50 C to +85 C. There are often physical size limitations for smart objects. While traditional mainboards are rather large, such as the Advanced Technology eXtended (ATX) design with a board size of 305 × 244 mm available in many PCs or the mini-ITX design typically found in home theater PCs with 170 × 170 mm, mainboard layouts for embedded systems are typically much smaller, such as the CoreExpress layout with 58 × 65 mm, or even smaller. In addition to the plain mainboard additional sensors, peripherals, a power adapter/battery, and a case have to be taken into consideration. Finally, there are cost restrictions as well.
The situation becomes more challenging when not only the hosts are constrained but also the network nodes themselves.
While there are constantly improvements being made, Moore's law tends to be less effective in the embedded system space than in personal computing devices: Gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power.
With the ongoing work on connecting smart objects to the Internet there are many challenges the workshop participants raised in more than 70 accepted position papers. With a single workshop day discussions had to be focused and priority was given to those topics that had been raised by many authors. A summary of the identified issues are captured in the subsections below.
A number of architectural questions were brought up in the workshop. This is natural, as the architectural choices affect the required technical solutions and the need for standards. At this workshop questions regarding the separation of traffic, the need for profiling for application specific domains, the demand for data model specific standardization, as well as the design choices of the layer at which functionality should be put were discussed and are briefly summarized below.
Devices that used to be in proprietary or application-specific networks are today migrating to IP networks. There is, however, the question of whether these smart objects are now on the same IP network as any other application. Controlled applications, like the fountains in front of the Bellagio hotel in Las Vegas that are operated as a distributed control system [Dolin], probably are not exchanging their control messages over the same network that is also used by hotel guests for their Internet traffic. The same had been argued for smart grids [SmartGrid]. The question that was raised during the workshop is therefore in what sense are we talking about one Internet or about using IP technology for a separate, walled garden network that is independent of the Internet?
Cullen Jennings compared the current state of smart object deployment with the evolution of voice-over-IP: "Initially, many vendors recommended to run VoIP over a separate VLAN or a separate infrastructure. Nobody could imagine how to make the type of real-time guarantees, how to debug it, and how to get it to work because the Internet is not ideally suited for making any types of guarantees for real-time systems. As time went on people got better at making voice work across that type of IP network. They suddenly noticed that having voice running on a separate virtual network than their other applications was a disaster. They couldn't decide if a PC was running a softphone and whether it went on a voice or a data network. At that point people realized that they needed a converged network and all moved to one. I wouldn't be surprised to see the same happens here. Initially, we will see very separated networks. Then, those will be running over the same hardware to take advantage of the cost benefits of not having to deploy multiple sets of wires around buildings. Over time there will be strong needs to directly communicate with each other. We need to be designing the system for the long run. Assume everything will end up on the same network even if you initially plan to run it in separate networks."
It is clearly possible to let sensors in a building communicate through the wireless access points and through the same infrastructure used for Internet access, if you want to. Those who want separation at the physical layer can do so as well. What is important is to make sure that these different deployment philosophies do not force loss of interoperability.
The level of interoperability that IP accomplished fostered innovation at the application layer. Ralph Droms reinforced this message by saying: "Bright people will take a phone, build an application and connect it, with the appropriate security controls in place, to the things in my house in ways we have never thought about before. Otherwise we are just building another telephone network."
Imagine a building network scenario where a new light bulb is installed that should, out of the box without further configuration, interoperate with the already present light switch from a different vendor in the room. For many this is the desired level of interoperability in the area of smart object design. To accomplish this level of interoperability it is not sufficient to provide interoperability only at the network layer. Even running the same transport protocol (e.g., TCP) and application layer protocol (e.g., HTTP) is insufficient since both devices need to understand the semantics of the payloads for "Turn the light on" as well.
Standardizing the entire protocol stack for this specific "light switch/light bulb" scenario is possible. A possible stack would, for example, use IPv6 with a specific address configuration mechanism (such as stateless address autoconfiguration), a network access authentication security mechanism such as Protocol for carrying Authentication for Network Access (PANA) [RFC5191], a service discovery mechanism (e.g., multicast DNS with DNS-SD [I-D.cheshire-dnsext-dns-sd]), an application layer protocol, for example, Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] (which uses UDP), and the syntax and semantic for the light on/off functionality.
As this list shows there is already some amount of protocol functionality that has to be agreed on by various stakeholders to make this scenario work seamlessly. As we approach more complex protocol interactions the functionality quickly becomes more complex: IPv4 and IPv6 on the network layer, various options at the transport layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices at the application layer with respect to communication protocols, data formats and data models. Different requirements have led to the development of a variety of communication protocols: client-server protocols in the style of the original HTTP, publish-subscribe protocols (like Session Initiation Protocol (SIP) [RFC3261] or Extensible Messaging and Presence Protocol (XMPP) [RFC3921]), store-and-forward messaging (borrowed from the delay tolerant networking community). Along with the different application layer communication protocols come various identity and security mechanisms.
With the smart object constraints it feels natural to develop these stacks since each application domain (e.g., health-care, smart grids, building networking) will have their unique requirements and their own community involved in the design process. How likely are these profiles going to be the right match for the future, specifically for the new innovations that will come? How many of these stacks are we going to have? Will the differences in the profiles purely be the result of different requirements coming from the individual application domains or will these mismatches reflect the spirit, understanding and preferences of the community designing them? How many stacks will multi-purpose devices have to implement?
Standardizing profiles independently for each application is not the only option. Another option is to let many different applications utilize a common foundation, i.e., a protocol stack that is implemented and utilized by every device. This, however, requires various application domains to be analyzed for their common characteristics and to identify requirements that are common across all of them. The level of difficulty for finding an agreement of how such a foundation stack should look depends on how many layers it covers and how lightweight it has to be.
From the discussions at the workshop it was clear that the available options are not ideal and further discussions are needed.
The end-to-end principle states that functionality should be put into the end points instead of into the networks. An additional recommendation, which is equally important, is to put functionality higher up in the protocol stack. While it is useful to make common functionality available as building blocks to higher layers the wide range of requirements by different applications led to a model where lower layers provide only very basic functionality and more sophisticated features were made available by various applications. Still, there has been the desire to put application layer functionality into the lower layers of the networking stack. A common belief is that performance benefits can be gained if functionality is placed at the lower layers of the protocol stack. This new functionality may be offered in the form of a gateway, which bridges different communication technologies, acts on behalf of other nodes, and offers more generic functionality (such as name-based routing and caching).
Two examples of functionality offered at the network layer discussed during the workshops were location and name-based routing:
The workshop participants were not able to come to an agreement about what functionality should be moved from the application layer to the network layer.
One limitation of smart objects is their available energy. To extend battery life, for example of a watch battery or single AAA battery for months, these small, low power devices have to sleep from 99% to 99.5% of their time. For example, a light sensor may wake up to check whether it is night-time to turn on light bulbs. Most parts of the system are off-line most of the time and particularly communication components are put into a sleeping state (e.g., WLAN radio interface) and only very few components of an embedded system board, such as sensors, are triggered periodically. When interesting events happen, these components wake up other parts of the system, for example a radio interface to connect to the Internet. Every bit is precious, as is every round trip, and every millisecond of radio activity.
Many IETF protocols implicitly assume that nodes in a network are always-on and respond to messages, i.e., to maintain a persistent presence on the network in order to respond to periodic messages that are required in order to maintain persistent sessions, connections, security associations, or state. These protocols work well on networks with sufficient network bandwidth, where there is a low cost to receiving/sending messages, and nodes are persistently available on the network.
In the early days a machine had been allocated a specific IP address and it could use it when it wanted to send an IP packet. The machine might need to execute an ARP exchange first before sending the packet, but it could keep the mapping in the cache for 15 minutes.
Nowadays a number of steps have to be taken before sending a packet. We want to make sure that we are on the right network before we send an IP packet. We run neighbor discovery. We cannot keep neighbor discovery for 15 minutes and so when a node wakes up again it essentially has to re-do it to refresh the cache. We want to run Detecting Network Attachment (DNA) procedures, see [RFC4436] and [RFC6059], to check that hosts are on the same network either by re-obtaining an address using the Dynamic Host Configuration Protocol (DHCP) or by noticing that the node is using the same default gateway because of a received Router Advertisement (RA).
However, these protocols do not work well, if at all, when the cost of sending/receiving those messages is high (in terms of bandwidth or battery life) or in cases where nodes sleep periodically and are not persistently available to receive those messages. A number of issues arise from these almost-always-off nodes.
Many protocols are also becoming more chatty. Keeping the receiver up for an additional roundtrip costs extra energy. Protocol messages can also be lengthy, e.g., many protocols carry XML-based payloads.
There are a couple of ways to think about how to make the situation less worse:
One can argue that certain features are not useful in an environment where most nodes are sleeping. The main focus of past investigations has been on IPv6 and ND but other protocols do also deserve a deeper investigation, such as DNS, and DHCP.
During the protocol design phase certain protocols were assumed to be used in a human-to-device context and therefore it was argued that the verbose encoding is helpful. Examples are HTTP, SIP, and XMPP. Nowadays these protocols are also being considered and used in device-to-device communication and the verbose nature is not helpful.
While the principles seem to be most useful for low-power, battery powered devices they would also be useful for other devices as well. Energy efficiency is useful for normal devices as well, such as notebooks, desktops and smart phones.
For example, consider energy consumption in a home environment. The question is whether it will save more energy than it uses and therefore one has to consider the overall energy consumption of the entire solution. This is not always an easy question to answer. IEEE 802.11 nodes, for example, use a lot of power if they cannot be made to sleep most of the time. A light bulb may use less power but there is also the device that controls the bulb that may consume a lot of energy all the time. In total, more energy may be consumed when considering these two devices together.
In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 [RFC4101], apply also to the smart object space.
While there are additional constraints, as described in Section 2, security has to be a mandatory part of the solution. The hope is that this will lead to implementations that provide security features, deployments that utilize these, and finally that this leads to use of better security mechanisms. It is important to point out that the lack of direct user interaction will place hard requirements on deployment models, configuration mechanisms, and software upgrade/crypto agility mechanisms.
Since many of the security mechanisms allow for customization, particularly with regard to the cryptographic primitives utilized, many believe that IETF security solutions are usable without modifications in a large part of the smart object domain. Others call for new work on cryptographic primitives that make use of a single primitive (such as the Advanced Encryption Standard (AES) [AES]) as a building block for all cryptographic functions with the benefit of a smaller footprint of the overall solution, specifically with respect to hardware limitations (e.g., the hardware architecture of certain embedded devices prevents pipelining from being used). In the excitement for new work on optimizations of cryptograhpic primitives other factors have to be taken into consideration that influence successful deployment, such as widespread support in libraries, as well as intellectual property rights (IPR). As an example of the latter aspect, the struggle of Elliptic Curve Cryptography (ECC)-based cryptographic algorithms [ECC] to find deployment can partially be attributed to its IPR situation. The reuse of libraries providing cryptographic functions is clearly an important way to use available memory resources in a more efficient way. To deal with the performance and footprint concerns investigations into offloading certain resource-hungry functions to parties that possess more cryptographic power have been considered. For example, the ability to delegate certificate validation to servers has been standardized in the IETF before; for the support of the Online Certificate Status Protocol (OCSP) in the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Layer Security (TLS) see see [RFC4806] and [RFC3546], respectively.
Focusing only on the cryptographic primitives would be shortsighted; many would argue that this is the easy part of a smart object security solution. Key management and credential enrollment, however, are considered a big challenge by many particularly when usability requirements have to be taken into account. Another group of challenges concern privacy; with smart grids, for example, some have voiced concerns regarding the ability of third parties to keep track of an individual's energy consumption (and draw associated conclusions). As another example, it is easy to see how a scale that is connected to the Internet for uploading weight information to a social network could lead to privacy concerns. While security mechanisms used to offer protection of the communication between different parties also provide a certain degree of privacy protection they are clearly not enough to address all concerns. Even with the best communication security and access control mechanisms in place one still needs additional safeguards against the concerns mentioned in the examples.
While a lot can be said about how desirable it would be to deploy more security protocols on the entire Internet, practical considerations regarding usability and the incentives of the stakeholders involved have often lead to slower adoption.
A smart object network environment may also employ routers under similar constraints as the end devices. Currently two approaches to routing in these low power and lossy networks are under consideration, namely mesh-under and route-over. The so-called mesh-under approach places routing functions at the link layer and consequently all devices appear as immediate neighbors at the network layer. With the route-over approach routing is done at the IP layer and none in the link layer. Each physical hop appears as a single IP hop (ignoring devices that just extend the physical range of signaling, such as repeaters). Routing in this context means running a routing protocol. IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the route-over category.
From an architectural point of view there are several questions that arise from where routing is provided, for example:
When multiple different link layer technologies are involved in a network design, routing at layer 3 has to be provided in any case. [I-D.routing-architecture-iot] talks about these tradeoffs between route-over and mesh-under in detail. Furthermore, those who decide about the deployment have to determine how to connect smart objects to the Internet infrastructure and a number of wired and wireless technologies may be suitable for a specific deployment. Depending on the chosen technologies the above-mentioned mesh-under vs. route-over approach will have to be decided and further decisions will have to be made about the choice of a specific routing protocol.
In 2008 the IETF formed the Routing Over Low power and Lossy networks (ROLL) working group to specify a routing solution for smart object environments. During its first year of existence, the working group studied routing requirements in detail (see [RFC5867], [RFC5826], [RFC5673], [RFC5548]), worked on a protocol survey comparing a number of existing routing protocols, including Ad hoc On-Demand Distance Vector (AODV)-style of protocols [RFC3561], against the identified requirements. The protocol survey [I-D.ietf-roll-protocols-survey] was inconclusive and abandoned without giving rise to publication of an RFC.
The ROLL WG concluded that a new routing protocol satisfying the documented requirements has to be developed and the work on the RPL was started as the IETF routing protocol for smart object networks. Nevertheless, controversial discussions at the workshop about which routing protocols is best in a given environment are still ongoing. Thomas Clausen, for example, argued for using an AODV-like routing protocol in [Clausen].
The workshop allowed the participants to get exposed to interesting applications and their requirements (buildings, fountains, theater, etc.), to have discussions about radically different architectures and their issues (e.g., information centric networking), to look at existing technology from a new angle (sleep modes, energy consumption), to focus on some details of the protocol stack (neighbor discovery, security, routing) and to learn about implementation experience.
One goal of the workshop was to identify areas that require further investigation. The list below reflects the thoughts of the workshop participants as expressed on the day of the workshop. Note that the suggested items concern potential work by the IETF and the IRTF and the order does not imply a particular preference.
The difficulty and impact of choosing specialised algorithms for smart objects should not be underestimated. Issues that arise include the additional specification complexity (e.g., TLS already has 100's of ciphersuites defined, most of which are unused in practice), the long latency in terms of roll out (many hosts are still using deprecated algorithms 5-10 years after those algorithms were deprecated) and the barriers that IPR-encumbered schemes present to widespread deployment. While research on this topic within CFRG and the cryptographic research community is a very worthwhile goal, any such algorithms will likely have to offer very significant benefits before they will be broadly adopted. 20% less CPU is unlikely to be a winning argument no matter what an algorithm inventor believes.
The workshop discussions covered a range of potential engineering activities, each with its own security considerations. As the IETF community begins to pursue specific avenues arising out of this workshop, addressing relevant security requirements will be crucial.
As described in this report part of the agenda was focused on the discussion of security, see Section 3.3.
We would like to thank all the participants for their position papers. The authors of the position papers were invited to the workshop.
Big thanks to Elwyn Davies for helping us to fix language bugs. We would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, and Henning Schulzrinne for their review comments.
Additionally, we would like to thank Ericsson and Nokia Siemens Networks for their financial support.
This document does not require actions by IANA.
| [RFC5582] | Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. |
| [RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. |
| [RFC4101] | Rescorla, E., IAB, "Writing Protocol Models", RFC 4101, June 2005. |
| [RFC3748] | Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. |
| [RFC2743] | Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. |
| [RFC2222] | Myers, J.G., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. |
| [RFC4903] | Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. |
| [I-D.baker-ietf-core] | Baker, F and D Meyer, "Internet Protocols for the Smart Grid", Internet-Draft draft-baker-ietf-core-15, April 2011. |
| [I-D.kivinen-ipsecme-ikev2-minimal] | Kivinen, T, "Minimal IKEv2", Internet-Draft draft-kivinen-ipsecme-ikev2-minimal-00, February 2011. |
| [I-D.hamid-6lowpan-snmp-optimizations] | Schoenwaelder, J, Mukhtar, H, Joo, S and K Kim, "SNMP Optimizations for Constrained Devices", Internet-Draft draft-hamid-6lowpan-snmp-optimizations-03, October 2010. |
| [I-D.eggert-core-congestion-control] | Eggert, L, "Congestion Control for the Constrained Application Protocol (CoAP)", Internet-Draft draft-eggert-core-congestion-control-01, January 2011. |
| [I-D.jennings-energy-pricing] | Jennings, C and B Nordman, "Communication of Energy Price Information", Internet-Draft draft-jennings-energy-pricing-01, July 2011. |
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-08, October 2011. |
| [I-D.ietf-roll-rpl] | Winter, T, Thubert, P, Brandt, A, Clausen, T, Hui, J, Kelsey, R, Levis, P, Pister, K, Struik, R and J Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Internet-Draft draft-ietf-roll-rpl-19, March 2011. |
| [RFC3561] | Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. |
| [I-D.routing-architecture-iot] | Hui, J and J Vasseur, "Routing Architecture in Low-Power and Lossy Networks (LLNs)", Internet-Draft draft-routing-architecture-iot-00, March 2011. |
| [RFC5867] | Martocci, J., De Mil, P., Riou, N. and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. |
| [RFC5826] | Brandt, A., Buron, J. and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. |
| [RFC5673] | Pister, K., Thubert, P., Dwars, S. and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. |
| [RFC5548] | Dohler, M., Watteyne, T., Winter, T. and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. |
| [I-D.ietf-roll-protocols-survey] | Tavakoli, A, Dawson-Haggerty, S and P Levis, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Internet-Draft draft-ietf-roll-protocols-survey-07, April 2009. |
| [CFRG] | McGrew (Chair), D., "IRTF Crypto Forum Research Group (CFRG)", http://irtf.org/cfrg , June 2011. |
| [LWIG] | IETF Light-Weight Implementation Guidance (LWIG) Working Group ", http://datatracker.ietf.org/wg/lwig/charter/ , June 2011. | , "
| [enroll] | IETF Credential and Provisioning Working Group Mailing List ", http://mailman.mit.edu/pipermail/ietf-enroll/ , June 2011. | , "
| [RECIPE] | Reducing Energy Consumption with Internet Protocols Exploration (RECIPE) Mailing List", https://www.ietf.org/mailman/listinfo/recipe , June 2011. | , "
| [FUN] | FUture home Networking (FUN) Mailing List", https://www.ietf.org/mailman/listinfo/fun , June 2011. | , "
| [GEOPRIV] | IETF Geographic Location/Privacy Working Group", http://datatracker.ietf.org/wg/geopriv/ , June 2011. | , "
| [Ersue] | Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object Workshop Position Paper ", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, http://www.iab.org/wp-content/IAB-uploads/2011/03/Ersue.pdf, March 2011. |
| [Dolin] | Dolin, B., "Application Communications Requirements for ‘The Internet of Things’", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, http://www.iab.org/wp-content/IAB-uploads/2011/03/Ersue.pdf, March 2011. |
| [Clausen] | Clausen, T. and U. Herberg, "Some Considerations on Routing in Particular and Lossy Environments", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, http://www.iab.org/wp-content/IAB-uploads/2011/03/Clausen.pdf, March 2011. |
| [Schoenwaelde] | Schoenwaelde, J., Tsou, T. and B. Sarikaya, "Protocol Profiles for Constrained Devices", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, http://www.iab.org/wp-content/IAB-uploads/2011/03/Schoenwaelder.pdf, March 2011. |
| [Wasserman] | Wasserman, M., "It's Not Easy Being "Green"", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, http://www.iab.org/wp-content/IAB-uploads/2011/03/Wasserman.pdf, March 2011. |
| [Tussle] | Clark, D., Wroslawski, J., Sollins, K. and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", In Proc. ACM SIGCOMM , http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html, 2002. |
| [irtf-discuss] | Draft ICN RG Charter on IRTF DISCUSS Mailing List", http://www.ietf.org/mail-archive/web/irtf-discuss/current/msg00041.html , May 2011. | , "
| [SmartGrid] | Wikipedia Entry for 'Smart Grid'", http://en.wikipedia.org/wiki/Smart_grid , Dec 2011. | , "
| [AES] | Wikipedia Entry for 'Advanced Encryption Standard'", http://en.wikipedia.org/wiki/Advanced_Encryption_Standard , Dec 2011. | , "
| [ECC] | Wikipedia Entry for 'Elliptic Curve Cryptography'", http://en.wikipedia.org/wiki/Elliptic_curve_cryptography , Dec 2011. | , "
| [SHA3] | NIST Cryptographic Hash Algorithm Competition", http://csrc.nist.gov/groups/ST/hash/sha-3/index.html , Dec 2011. | , "
| [RFC5191] | Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. |
| [I-D.cheshire-dnsext-dns-sd] | Cheshire, S and M Krochmal, "DNS-Based Service Discovery", Internet-Draft draft-cheshire-dnsext-dns-sd-10, February 2011. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC3921] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. |
| [RFC4436] | Aboba, B., Carlson, J. and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. |
| [RFC6059] | Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010. |
| [RFC3546] | Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. |
| [RFC4806] | Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. |
The following persons are responsible for the organization of the associated workshop and are responsible also for this event: Jari Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Jennings, Manfred Hauswirth, and Lukas Kencl.
Information about the workshop can be found at the IAB webpage: http://www.iab.org/about/workshops/smartobjects/
71 position papers were submitted to the workshop:
These papers can be retrieved from: http://www.iab.org/about/workshops/smartobjects/papers/
The slides are available for download at the following webpage: http://www.iab.org/about/workshops/smartobjects/agenda.html
Detailed meeting minutes are published here: http://www.iab.org/about/workshops/smartobjects/minutes.html
We would like to than the following workshop participants for attending the workshop: